Re: [PATCH v2 0/6] dt-bindings: Convert SP804 to Json-schema (and fix users)

[Emmanuel Vadot <manu@bidouilliste.com>]

On Fri, 28 Aug 2020 16:44:28 +0100
André Przywara <andre.przywara@arm.com> wrote:

> On 28/08/2020 15:54, Linus Walleij wrote:
> 
> Hi,
> 
> > On Fri, Aug 28, 2020 at 4:20 PM Andre Przywara <andre.przywara@arm.com> wrote:
> > 
> >> This is the second attempt at converting the SP804 timer binding to yaml.
> >> Compared to v1, I forbid additional properties, and included the primecell
> >> binding. Also the clock-names property is now listed, although without
> >> further requirements on the names. Changelog below.
> > 
> > The series:
> > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> > 
> >> I couldn't test any of those DT files on actual machines, but tried
> >> to make the changes in a way that would be transparent to at least the
> >> Linux driver. The only other SP804 DT user I could find is FreeBSD,
> >> but they seem to use a different binding (no clocks, but a
> >> clock-frequency property).
> > 
> > That's annoying. I suppose FreeBSD just made that up and doesn't
> > even have a binding document for it?
> 
> I couldn't find bindings at all in their git tree.

 That's because I don't merge the bindings in the main branch.

> I don't think they
> treat this very formally, it seems to be more use-case driven.
> Their SP804 driver does not know how to handle clock properties, so most
> of the DTs (in sys/gnu/dts, so apparently copied from Linux) would not
> work really well, because the driver assumes a hardcoded frequency of
> 1MHz by default.

 In addition to sys/gnu/dts we also have sys/dts/ which are our own DTs
before we used the Linux ones (a long time ago but some platform
weren't converted, they will just die sometime in the futur if nobody
takes care of them I guess).

> There is only one DT (Annapurna Alpine with Cortex-A15) that provides
> this clock-frequency property. The Linux DT does not mention the SP804
> in there at all, interestingly.

 I'm not familiar with this platform at all, it was done under
contract by Semihalf and I'm sure that if something fails and their
client starts to complain they will fix it.

> > In an ideal world I suppose we should go and fix FreeBSD but I have
> > no idea how easy or hard that is.
> 
> It seems to be messy, at least in this case, and I guess unifying DTs
> means some work on drivers as well.

 I wouldn't worry about us on this case, this binding requirements
seems to have be done a long time ago before we had any clock framework
and if our drivers needs to be updated we will do it when we imports
DTS from whatever Linux version this will be merged in.

> But AFAIK most of the more modern platforms copy the DTs (and thus
> implicitly the bindings) from Linux, so there is probably much less
> deviation for many more relevant boards.

 Yes, I (and others) insist on using the DTs from Linux and not doing
any patches to it without sending them to the Linux ML.

> Cheers,
> Andre

 Cheers,

> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
Emmanuel Vadot <manu@bidouilliste.com>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel