Message-ID: <20231121-vocation-clunky-17e2c77e64fa@wendy>
Date:   Tue, 21 Nov 2023 13:03:07 +0000
From:   Conor Dooley <conor.dooley@...rochip.com>
To:     Inochi Amaoto <inochiama@...look.com>
CC:     Conor Dooley <conor@...nel.org>, Guo Ren <guoren@...nel.org>,
        Chen Wang <unicorn_wang@...look.com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Anup Patel <anup@...infault.org>,
        Samuel Holland <samuel.holland@...ive.com>,
        Jisheng Zhang <jszhang@...nel.org>,
        <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-riscv@...ts.infradead.org>
Subject: Re: [PATCH v4 1/2] dt-bindings: timer: thead,c900-aclint-mtimer:
 separate mtime and mtimecmp regs

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@...look.com>
> >> Fixes: 4734449f7311 ("dt-bindings: timer: Add Sophgo sg2042 CLINT timer")
> >> Link: https://lists.infradead.org/pipermail/opensbi/2023-October/005693.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-mtimer.yaml
> >> index fbd235650e52..053488fb1286 100644
> >> --- a/Documentation/devicetree/bindings/timer/thead,c900-aclint-mtimer.yaml
> >> +++ b/Documentation/devicetree/bindings/timer/thead,c900-aclint-mtimer.yaml
> >> @@ -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?
> >
> 
> 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.
> >
> 
> 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.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists