[PATCH 00/21] Qualcomm generic board support

[Daniel Thompson]

On Tue, Dec 05, 2023 at 10:36:28AM +0000, ff wrote:
> > Le 5 déc. 2023 à 10:46, Sumit Garg <sumit.garg at linaro.org> a écrit :
> >
> > + U-boot custodians list
> >
> >> On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski
> >> <krzysztof.kozlowski at linaro.org> wrote:
> >>
> >> On 05/12/2023 08:13, Sumit Garg wrote:
> >>>>> @DT bindings maintainers,
> >>>>>
> >>>>> Given the ease of maintenance of DT bindings within Linux kernel
> >>>>> source tree, I don't have a specific objection there. But can we
> >>>>> ease DTS testing for firmware/bootloader projects by providing a
> >>>>> versioned release package for DT bindings? Or if someone else
> >>>>> has a better idea here please feel free to chime in.
> >>>>
> >>>> This doesn't work for you?:
> >>>>
> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
> >>>
> >>> Thanks, this is certainly a good step which I wasn't aware of.
> >>> Further simplification can be done to decouple devicetree source
> >>> files from DT bindings.
> >>
> >> Why?
> >
> > I suppose you are already aware that Linux DTS files are a subset of
> > what could be supported by devicetree schemas. There can be
> > firmware/bootloader specific properties (one example being [1])
> > which Linux kernel can simply ignore. Will you be willing to add all
> > of those DT properties to Linux DTS files and maintain them?
>
> A pre-existing effort to solve the same problem as [1] is System
> Device Tree, discussed in the context of Linaro supported OpenAMP
> project. It is not just about cherry picking devices that have
> bindings in Linux but also information about clock and power domains
> or devices that are not seen by Linux.  It is obvious that the
> resulting bindings should be maintained upstream in the DT repo
> regardless of the communities adopted solution.

This seems to be artificially linking two topics: system DT and DT
schema validation within u-boot. They are somewhat related but one of
not a precondition of the other.


> > However, DT bindings are something which should be common, the
> > hardware description of a device should be universal. IMO, splitting
> > DT bindings alone would ease the compliance process for u-boot
> > drivers in quite similar manner to Linux drivers.
>
> I remember a discussion with ST on that topic related to Framebuffer.
> U-Boot can need a very different representation of the same device to
> use it while Linux need an in-depth description of all shaders and «
> stuff » (another reason why [1] is addressing only a portion of the
> problem) So even if there is a single frame buffer binding, there
> should be two (at least) conformance tests.

I don't follow this, for two reasons.

1. DT describes the hardware, not how it is driven. Having a relationship
   between u-boot and linux DTs with different representation would
   imply that the hardware changes between u-boot and the kernel.

2. Even if we were to accept that there must be two device tree instances
   (beyond transient workarounds for missing features), why would there
   need to be two conformance tests rather than one conformance test run
   on the two DTs?


Daniel.