[PATCH v2 06/11] dt-bindings: timer: Add Sophgo sg2042 clint

[Inochi Amaoto]

>
>On Wed, Sep 20, 2023 at 08:08:49PM +0530, Anup Patel wrote:
>> On Wed, Sep 20, 2023 at 6:28 PM Conor Dooley <conor at kernel.org> wrote:
>>>
>>> On Wed, Sep 20, 2023 at 08:40:07PM +0800, Inochi Amaoto wrote:
>>>>> On 20/09/2023 14:15, Inochi Amaoto wrote:
>>>>>>> On 20/09/2023 08:39, Chen Wang wrote:
>>>>>>>> From: Inochi Amaoto <inochiama at outlook.com>
>>>>>>>>
>>>>>>>> Add two new compatible string formatted like `C9xx-clint-xxx` to identify
>>>>>>>> the timer and ipi device separately, and do not allow c900-clint as the
>>>>>>>
>>>>>>> Why?
>>>>>>>
>>>>>>
>>>>>> If use the same compatible, SBI will process this twice in both ipi and
>>>>>> timer, use different compatible will allow SBI to treat these as different.
>>>>>> AFAIK, the aclint in SBI use the same concepts, which make hard to use the
>>>>>> second register range. I have explained in another response.
>>>>>
>>>>> What is a SBI? Linux driver? If so, why some intermediate Linux driver
>>>>> choice should affect bindings?
>>>>> Best regards,
>>>>> Krzysztof
>>>>>
>>>>
>>>> SBI (Supervisor Binary Interface) is defined by riscv, which is an interface
>>>> between the Supervisor Execution Environment (SEE) and the supervisor. The
>>>> detailed documentation can be found in [1].
>>>>
>>>> The implement of SBI needs fdt info of the platform, which is provided by
>>>> kernel. So we need a dt-bindings for these devices, and these will be
>>>> processed by SBI.
>>>>
>>>> [1] https://github.com/riscv-non-isa/riscv-sbi-doc
>>>
>>> Yeah, this is the unfortunate problem of half-baked bindings (IMO)
>>> ending up in OpenSBI (which likely means they also ended up in QEMU).
>>> This T-Head stuff is coming across our (metaphorical) desks, so we are
>>> obviously going to try to do things correctly. I may end up speaking to
>>> Anup later today, if I do I will point him at this thread (if he hasn't
>>> seen it already).
>>
>> RISC-V ACLINT is one of those unfortunate non-ISA specs (like
>> SiFive PLIC) which is implemented by various organizations but
>> not officially ratified by RVI.
>
>Yeah, I brought this stuff up at the weekly pw sync call, and Paul
>pointed that out.
>
>> The SiFive CLINT has flexibility related limitations which makes it
>> not useful for multi-socket and mult-die systems. The SiFive CLINT
>> is also not useful for systems with AIA because with AIA M-mode has
>> a new way of doing M-mode IPIs. Due to this reasons, the RISC-V
>> ACLINT spec breaks down traditional SiFive CLINT into two separate
>> devices namely mtimer and mswi. This allows platforms to implement
>> only the required set of devices. The mtimer as defined by the ACLINT
>> specifications also allows platforms to place mtime and mtimecmp
>> registers at different locations.
>>
>> Refer, https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc
>>
>> We need a separate DT bindings document for ACLINT MTIMER
>> and ACLINT MSWI because these are separate devices. The
>> Sophgo sg2042 SoC should add their implementation specific
>> compatible strings in this document.
>
>If the spec isn't frozen, I'm not accepting a binding for the "generic"
>version of it. Bindings for this specific implemtnation are okay.
>For sure though, squeezing this into the sifive,plic binding isn't
>appropriate.
>

It seems I have missed a point. I wonder whether it is better to add a
"aclint" binding firstly and then add sg2042 to it, or just use sg2042
specific binding? If use "aclint" binding, I wonder it is OK to add
thead quirks as compatible specific properties, or left this to the SBI to
handle? e.g. T-HEAD timer is not 64bit timer, and we should identify this.

>What was pointed out, I think by Samuel, that the reason that this may
>need to be split is the fact that there are many possible MTIMER
>register ranges & possibly sswi stuff too that would need to be
>differentiated.
>
>>
>> Regards,
>> Anup
>