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

[Inochi Amaoto]

>Yo,
>
>On Thu, Sep 21, 2023 at 04:18:57PM +0800, Inochi Amaoto wrote:
>>> On Thu, Sep 21, 2023 at 08:43:47AM +0800, Inochi Amaoto wrote:
>
>>>>>>>> but not one. In another word, there is no need to defined mtimer and ipi
>>>>>>>> device on the same base address.
>>>>>>>
>>>>>>> There's also no need to have two compatibles for the same interrupt
>>>>>>> controller, so I do not get this reasoning. What actually _requires_
>>>>>>> them to be split?
>>>>>>>
>>>>>>
>>>>>> Yes, it is one, but can be mapped into different address. So I think we
>>>>>> need two.
>>>>>
>>>>> Not two compatibles though, just two memory addresses that you need to
>>>>> locate (or maybe even 3, for SSWI?)
>>>>>
>>>>
>>>> We may need four (mtime, mtimecmp, mswi, sswi) if use register range.
>>>
>>> Why would you need 4? The first two certainly could be individual
>>> reg entries, no?
>>>
>>
>> After reading the aclint doc again, I found the all of them can be mapped
>> on the different address. (See the section 2.1 in that doc).
>
>Right, that's what I meant by individual reg entries. If there's some
>dynamic gap between them, then one reg entry would cover mtime and one
>would cover the base of the mtimecmp region.
>

Thanks.

>> But for now,
>> the mtime and mtimecmp have the same base address in any platform.
>
>How? The mtimecmp base address would have to be offset from the mtime
>base address. Is what you mean that, for example, mtime is at an offset
>of 0x0 from the base address & mtimecmp0 is at, for example, an offset
>of 0x8 so a single reg entry can cover both?
>

I mean "the same" is just what you said: use the offset to access mtime
and mtimecmp, and left one register range in the DT.
In your example, using a offset of 0x4 to mark the mtimecmp will allow us
to use one register range like DTs already in the riscv arch. But this way
does have problems when the timer is more complex.
In fact, I think two register range could do better, and will give us
more freedom to cover these regs.

>Also, "any platform"? I figure you mean in this one specific platform?
>

I mean the platforms already upstreamed in both of kernel and OpenSBI.
Not for this one.

>> Anyway,
>> the frozen spec in future will decided how many ranges we need.
>
>Isn't the spec abandoned? There may well be no frozen spec.
>

I guess it is. That is not a good thing.

>>>> Anyway, I will use a vendor spec implementation as a temporary solution.
>>>> I hope this will be corrected in a predictable future, and we can use a
>>>> standard way to resolve this at that time. :)
>>>
>>> If the spec doesn't get frozen, there'll not be a standard way merged.
>>> Hopefully not too many others go off an implement non-frozen specs, and
>>> we will not really need to worry all that much about it.
>
>Cheers,
>Conor.
>