On Fri, Jul 28, 2017 at 02:26:47PM +0300, Pantelis Antoniou wrote:
> Hi Rob,
>
> On Thu, 2017-07-27 at 18:00 -0500, Rob Herring wrote:
> > On Thu, Jul 27, 2017 at 4:46 PM, Pantelis Antoniou
> > <pantelis.antoniou@xxxxxxxxxxxx> wrote:
> > > Hi Frank,
> > >
> > > On Thu, 2017-07-27 at 13:22 -0700, Frank Rowand wrote:
> > >> Hi Pantelis,
> > >>
> > >> Keep in mind one of the reasons Linus says he is very direct is to
> > >> avoid leading a developer on, so that they don't waste a lot of time
> > >> trying to resolve the maintainer's issues instead of realizing that
> > >> the maintainer is saying "no". Please read my current answer as being
> > >> "no, not likely to ever be accepted", not "no, not in the current form".
> > >>
> > >> My first reaction is: no, this is not a good idea for the Linux kernel.
> > >>
> > >
> > > This has nothing to do with the kernel. It spits out valid DTBs that the
> > > kernel (or anything else) may use.
> >
> > Let me rephrase Frank's statement: this is not a good idea for the
> > main repository of dts files.
> >
>
> I absolutely agree. It is completely out of the question to convert the
> whole of the repository to a new format for no particular reason.
>
> I only ask for considering a source format change for new platforms that
> may find this new format more appealing.
>
> The kernel infrastructure will keep supporting the DTB format without
> any changes.
>
> > But sure, DTS is already not the only source of DTBs. It comes from
> > firmware on Power systems. If you want to create and maintain your own
> > source format, then that is perfectly fine. But based on the current
> > understanding, I'm not seeing a reason we'd convert DTS files to YAML.
> > Maybe you're not proposing that now, but if that is not the end goal I
> > don't see the point of a new format. If YAML solves a bunch of
> > problems, then of course we'd want to convert DTS files at some point.
> >
>
> What I take from this statement is that DTBs have been generated since
> for ever using a source format other than DTS, correct?
>
> So what is changing now? That the different source format is open source
> and out in the public eye?
Well, one point is that tools which can work at the dtb level have
advantages over tools which work only at the source level, since they
can handle dtbs from all origins.
> > >> On 07/27/17 11:58, Pantelis Antoniou wrote:
> > >> > On Thu, 2017-07-27 at 13:09 -0500, Rob Herring wrote:
> > >> >> On Thu, Jul 27, 2017 at 11:49 AM, Pantelis Antoniou
> > >> >> <pantelis.antoniou@xxxxxxxxxxxx> wrote:
> > >> >>> Hi all,
> > >> >>>
> > >> >>> This is a project I've been working on lately and it's finally in a
> > >> >>> usuable form.
> > >> >>>
> > >> >>> I'm introducing yamldt.
> > >> >>>
> > >> >>> A YAML to DT blob generator/compiler, utilizing a YAML schema that is
> > >> >>> functionaly equivalent to DTS and supports all DTS features.
> > >> >>
> > >> >> What problem are you trying to solve?
> > >> >>
> > >> >
> > >> > I am demonstrating that the DTS source format is not the only way to
> > >> > describe hardware and generate a DTB that is functionally equivalent.
> > >> >
> > >> > I feel that the reliance on DTS has been holding progress back in
> > >> > expressing modern hardware and having a tool that generates DTB as well
> > >> > will allow me to experiment in ways that things like overlays and
> > >> > portable overlays can be defined.
> > >>
> > >> That seems to be multiple things, that should be expressed as individual
> > >> issues and not lumped into a simple statement (and thus can be addressed
> > >> separately):
> > >>
> > >> 1) DTS format is holding progress back in expressing modern hardware
> > >>
> > >> What are the issues you have encountered?
> > >
> > > DTS syntax is archaic and makes expressing things like overlays (and
> > > portable connectors) extremely hard.
> >
> > That's a very vague statement. Can we have some examples of what you
> > can express with YAML that you can't with DTS? In the end, you are
> > still limited by the DTB format. If you're adding automagically
> > generated type information like what's been discussed recently for
> > phandles, that syntax in the DTB still has to be agreed on whether the
> > source is DTS or YAML.
> >
>
> Actually I can.
>
> Let me tackle two very common problems in reviewing DTS patches; the
> problem is a by product of using the DTS format as it is right now.
>
> The first is requirement that each node (and property) in the source
> format needs to have a unique name. While this maybe a requirement for
> the target system that will have to grok the DTB file it seeps in the
> source format by the means of the node names having unit address in
> them.
>
> So you have something like this peppered all over the sources:
>
>
> > gpio0: gpio@44e07000 {
> > compatible = "ti,omap4-gpio";
> > ti,hwmods = "gpio1";
> > gpio-controller;
> > #gpio-cells = <2>;
> > interrupt-controller;
> > #interrupt-cells = <2>;
> > reg = <0x44e07000 0x1000>;
> > interrupts = <96>;
> > };
> >
> > gpio1: gpio@4804c000 {
> > compatible = "ti,omap4-gpio";
> > ti,hwmods = "gpio2";
> > gpio-controller;
> > #gpio-cells = <2>;
> > interrupt-controller;
> > #interrupt-cells = <2>;
> > reg = <0x4804c000 0x1000>;
> > interrupts = <98>;
> > };
>
> The node names in general are not useful to the kernel. References to nodes are
> made using the labels and phandle references. But it is very easy for the
> node names to miss the unit address, or even worse having a wrong unit address.
>
> IMO this is an artificial problem. Having identical names in children of the nodes
> should not be a problem for the compiler; it's the DTB emit phase that can handle
> appending unit address names (whether in the case of a name clash or by default when
> having a ref property present).
Well, you have to know how to generate that unit name. That's
dependent on the parent bus, so you have to know a bunch about the
property semantics to do this correctly - that's why we don't do this
in dtc as yet. Note that in traditional OF, the unit name isn't
really a thing, it's generated on the fly from the "name" and "reg"
properties - but the assumption is that OF *does* know the semantics
of every property in every node, which isn't usually the case for
tools working with modern DTs.
> The second problem is the proliferation of almost identical device descriptions with minor
> changes that make the DTS sources so bulky. Macros help a bit but can't solve the underlying
> problem of not having a method of reusing parts of the source with a way to modify the changing
> bits.
>
> However YAML has method for handling just that, a merge operator.
>
> http://yaml.org/type/merge.html
>
> We could write the above DT part in YAML as follows:
>
> > gpio: &gpio0
> > compatible: "ti,omap4-gpio"
> > ti,hwmods: "gpio1"
> > gpio-controller: true
> > "#gpio-cells": 2
> > interrupt-controller: true
> > "#interrupt-cells": 2
> > reg: [ 0x44e07000, 0x1000 ]
> > interrupts: 96
> >
> > gpio: &gpio1
> > << : *gpio0
> > ti,hwmods: "gpio2"
> > reg: [ 0x4804c000, 0x1000 ]
> > interrupts: 98
That's pretty nice, I'll grant you. Does at least some of the stuff
that I wanted to achieve with node valued expressions in dtc, but
no-one ever had time to implement.
> This is good but we can do even better
>
> > gpio: &gpio0
> > compatible: "ti,omap4-gpio"
> > ti,hwmods: 'gpio', "1" # single quoted strings do not get the terminating \0
> > gpio-controller: true
> > "#gpio-cells": 2
> > interrupt-controller: true
> > "#interrupt-cells": 2
> > reg: [ 0x44e07000, 0x1000 ]
> > interrupts: 96
> >
> > gpio: &gpio1
> > << : *gpio0
> > ti,hwmods: ~. "2" # ~ is the null value, we interpret it as 'keep' when using the merge operator
> > reg: [ 0x4804c000, ~ ]
> > interrupts: 98
>
> These are problems that the YAML schema I'm proposing doesn't have. In
> fact I've taken an hour or so and implemented the automatic unit
> renaming for DTB output already:
>
>
> > am33xx.yaml:223:3: warning: renamed /ocp/gpio@44e07000 to include unit address
> > gpio: &gpio0
> > ^~~~~~~~~~~~
> > am33xx.yaml:233:3: warning: renamed /ocp/gpio@4804c000 to include unit address
> > gpio: &gpio1
> > ^~~~~~~~~~~~
>
> So things are mostly there already.
Well, for sufficiently simple buses. Looking at the code it won't get
it right for PCI. Or anything else with idiosyncratic unit naming,
but PCI is by far the most common.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
