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

[Conor Dooley]

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.

> 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?

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

> 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.

> >> 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.

Attachment: signature.asc
Description: PGP signature