Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7;
Date:   Tue, 21 Nov 2023 13:03:07 +0000
From:   Conor Dooley <conor.dooley@microchip.com>
To:     Inochi Amaoto <inochiama@outlook.com>
CC:     Conor Dooley <conor@kernel.org>, Guo Ren <guoren@kernel.org>,
        Chen Wang <unicorn_wang@outlook.com>,
        Daniel Lezcano <daniel.lezcano@linaro.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Albert Ou <aou@eecs.berkeley.edu>,
        Anup Patel <anup@brainfault.org>,
        Samuel Holland <samuel.holland@sifive.com>,
        Jisheng Zhang <jszhang@kernel.org>,
        <linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
        <linux-riscv@lists.infradead.org>
Subject: Re: [PATCH v4 1/2] dt-bindings: timer: thead,c900-aclint-mtimer:
 separate mtime and mtimecmp regs
Message-ID: <20231121-vocation-clunky-17e2c77e64fa@wendy>
References: <20231120-banshee-traverse-554723cd9490@spud>
 <IA1PR20MB4953D36ABE26822B62415500BBBBA@IA1PR20MB4953.namprd20.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="L2eP2FSieLwYKUqy"
Content-Disposition: inline
In-Reply-To: <IA1PR20MB4953D36ABE26822B62415500BBBBA@IA1PR20MB4953.namprd20.prod.outlook.com>
Precedence: bulk

--L2eP2FSieLwYKUqy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 21, 2023 at 09:12:12AM +0800, Inochi Amaoto wrote:
> >Yo,
> >
> >On Sat, Nov 18, 2023 at 03:10:26PM +0800, Inochi Amaoto wrote:
> >> The timer registers of aclint don't follow the clint layout and can
> >> be mapped on any different offset. As sg2042 uses separated timer
> >> and mswi for its clint, it should follow the aclint spec and have
> >> separated registers.
> >>
> >> The previous patch introduced a new type of T-HEAD aclint timer which
> >> has clint timer layout. Although it has the clint timer layout, it
> >> should follow the aclint spec and uses the separated mtime and mtimecmp
> >> regs. So a ABI change is needed to make the timer fit the aclint spec.
> >>
> >> To make T-HEAD aclint timer more closer to the aclint spec, use
> >> regs-names to represent the mtimecmp register, which can avoid hack
> >> for unsupport mtime register of T-HEAD aclint timer.
> >>
> >> Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
> >> Fixes: 4734449f7311 ("dt-bindings: timer: Add Sophgo sg2042 CLINT time=
r")
> >> Link: https://lists.infradead.org/pipermail/opensbi/2023-October/00569=
3.html
> >> Link: https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc
> >> ---
> >>  .../timer/thead,c900-aclint-mtimer.yaml       | 42 ++++++++++++++++++-
> >>  1 file changed, 41 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/timer/thead,c900-aclint=
-mtimer.yaml b/Documentation/devicetree/bindings/timer/thead,c900-aclint-mt=
imer.yaml
> >> index fbd235650e52..053488fb1286 100644
> >> --- a/Documentation/devicetree/bindings/timer/thead,c900-aclint-mtimer=
=2Eyaml
> >> +++ b/Documentation/devicetree/bindings/timer/thead,c900-aclint-mtimer=
=2Eyaml
> >> @@ -17,7 +17,20 @@ properties:
> >>        - const: thead,c900-aclint-mtimer
> >>
> >>    reg:
> >> -    maxItems: 1
> >> +    oneOf:
> >> +      - items:
> >> +          - description: MTIME Registers
> >> +          - description: MTIMECMP Registers
> >> +      - items:
> >> +          - description: MTIMECMP Registers
> >> +
> >> +  reg-names:
> >> +    oneOf:
> >> +      - items:
> >> +          - const: mtime
> >> +          - const: mtimecmp
> >> +      - items:
> >> +          - const: mtimecmp
> >>
> >>    interrupts-extended:
> >>      minItems: 1
> >> @@ -28,8 +41,34 @@ additionalProperties: false
> >>  required:
> >>    - compatible
> >>    - reg
> >> +  - reg-names
> >>    - interrupts-extended
> >>
> >> +allOf:
> >> +  - if:
> >> +      properties:
> >> +        compatible:
> >> +          contains:
> >> +            const: thead,c900-aclint-mtimer
> >
> >Is this being the c900 compatible correct? You mention in your commit
> >message that this split is done on the sg2042, but the rule is applied
> >here for any c900 series "aclint". Do we know if this is a sophgo
> >specific thing (or even sg2042 specific), or if it applies generally?
> >
>=20
> This can be confirmed. The thead c900 series have no mtime support and
> there is no evidence that they will implement it. So I think it is OK
> to applied this restriction for the whole c900 series.

Okay, great.

> >> +    then:
> >> +      properties:
> >> +        reg:
> >> +          items:
> >> +            - description: MTIMECMP Registers
> >> +        reg-names:
> >> +          items:
> >> +            - const: mtimecmp
> >
> >> +    else:
> >> +      properties:
> >> +        reg:
> >> +          items:
> >> +            - description: MTIME Registers
> >> +            - description: MTIMECMP Registers
> >> +        reg-names:
> >> +          items:
> >> +            - const: mtime
> >> +            - const: mtimecmp
> >
> >If it applies generally, I would probably just delete this, but unless
> >someone can confirm this to be general, I'd probably leave the else
> >clause and swap for the specific sg2042 compatible above.
> >
>=20
> I suggest keeping this. By taking your advice, this binding has actually
> become the binding for aclint draft.

Right. It seemed to me from the reports (and the commit message) that this
was a configuration choice made by sophgo for the IP.

> So I think it is better to preserve
> this path, otherwise adding the mtime register seems meaningless.

Yeah, I mistakenly thought that there were cases where we actually had
systems with mtime and mtimecmp registers. I don't know if that was an
assumption I made due to previous commit messages or from reading the
opensbi threads, but clearly that is not the case.

> But if
> you think it is OK to add this when adding new compatible or converting it
> to a generic binding.

I'm a bit conflicted. Since this is c900 specific one part of me says
leave it with only one "reg" entry as that is what the only hardware
actually has & add "reg-names" to make lives easier when someone else
implements the unratified spec (or it gets ratified for some reason).

> Feel free to remove it.

I might've applied the other binding as it was in a series adding
initial support for the SoC, but usually these things go via the
subsystem maintainers with a DT maintainer ack/review.

--L2eP2FSieLwYKUqy
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZVyqiwAKCRB4tDGHoIJi
0jluAP0fYsqgIge8uXa8G+bCn2bcUbFIsGX/HEtgQr05f7kUTgEA2P/xhfSpfcsh
bBx01cguP1duoKHmUMurx4Wbd/lfXAU=
=8YV4
-----END PGP SIGNATURE-----

--L2eP2FSieLwYKUqy--