On Wed, Oct 23, 2013 at 09:57:58AM +0200, Thierry Reding wrote:
> On Tue, Oct 22, 2013 at 02:10:00PM -0700, Guenter Roeck wrote:
> [...]
> > Thinking about it, much of a hardware description can be seen as "use
> > case", at least when it comes to gpio pins or adc channels.
>
> There are many more examples where this is the case. Regulators are one
> example. A regulator is pretty much useless until you connect it up to
> some other device.
>
> The same goes for things like a backlight. Sure we can expose backlights
> via sysfs and tell people to use that interface to control the backlight
> but that just doesn't always work. Furthermore, backlights don't always
> need to be associated with display panels. They can be used together
> with keyboards too...
>
> In order to effectively make use of these basic building blocks we need
> some way to interconnect them, because they cannot be correlated to each
> other without some form of meta data.
>
Yes. I think the problem starts if the interconnect point is not another chip.
It is easy to say "this gpio pin is connected to the interrupt pin of chip X",
but things become murky if you need to express that a gpio pin connects to a
pushbutton or presence detect pin, or if you need to express that an ADC input
pin is used as voltage sensor.
The common theme nowadays seems to be "you can't do that, it is a use case".
It might be more helpful if the feedback was "you can not describe it that way,
let's find another binding that works".
> > > But on the other hand we do the same with other "resources". GPIOs for
> > > example are rather useless if you don't associate them with specific
> > > functionality. And we actually do that quite often. They are used in
> > > properties such as:
> > >
> > > foo {
> > > ...
> > > enable-gpios = <&gpio 42 0>;
> > > ...
> > > };
> > >
> > > I don't see how that is different to the ADC/sensor example above.
> > > Perhaps there's no real physical device that is the sensor, but if we
> > > can't even represent simple yet essential things like that in DT, then
> > > we definitely need something better.
> > >
> > I don't think the issue is "can". After all, the restriction that DT shall only
> > describe HW and not its use is purely arbitrary.
>
> That's what I was trying to say. "can" in the sense of "not able because
> we're arbitrarily restricting what we can express with DT".
>
ok.
> Now, I can even understand why it's a good idea to keep Linux-specifics
> out of the DT and not encode software policy within it, but all these
> examples aren't software policy nor Linux-specifics. In my opinion they
> describe hardware. They may not restrict themselves to the bare minimum,
> but they give meaning to the hardware so that an operating system can
> use it.
>
> If we cannot describe these things in DT but have to come up with some
> alternative method to describe it, then any other operating system would
> either need to copy that alternative method (in which case there's no
> point at all in keeping it separate from DT) or invent yet something
> different to describe those relationships.
>
> I've said above that I understand why it can be good to keep DT hardware
> specific, but I also think that if that's what we end up deciding, we'll
> still need to supplement it with something that can describe software
> policy. With our concept of DT right now we're regressing with respect
> to board files because some things can no longer be described.
>
Agreed.
> > > We do pretty much the same thing with regulators. We can have fixed
> > > regulators that control a GPIO, yet there's no physical device that one
> > > could associate with such regulators either.
> > >
> > > > Another example is my recent attempt to add dt support to gpio based connectors.
> > > > Even though a connector is as much hardware as it can get (or at least one
> > > > should think so), that was rejected because it isn't generic enough and,
> > > > after all, it describes the _use_ of gpio pins which apparently is already
> > > > borderline. So now I have my own out of tree driver (where I can add as many
> > > > bindings and as much functionality as I want and see fit, so I am not too
> > > > unhappy about that).
> > >
> > > That's odd. This sounds exactly like a variant of the above. Would you
> > > mind posting the binding (or a usage example here)? I'd be interested to
> > > understand why it would be inappropriate.
> > >
> >
> > Patch 4 and 5 of https://lkml.org/lkml/2013/8/30/23.
> >
> > The bindings I currently use are actually a bit more complex.
> > Here is an example.
> >
> > pic1 {
> > compatible = "jnpr,pic-connector";
> > presence-detect-gpios = <&gpio20 36 0x10013>;
> > request-button-gpios = <&gpio20 38 0x10013>;
> > power-enable-gpios = <&gpio20 42 0x0>;
> > power-status-gpios = <&gpio20 39 0x3>;
> > reset-gpios = <&gpio20 41 0x10000>;
> > power-enable-timeout = <2000>;
> > debounce-interval = <1>;
> > led-green = <&pic1_green>;
> > led-red = <&pic1_red>;
> >
> > i2c-bus {
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > i2c-parent = <&pic1i2c>;
> >
> > eeprom@55 {
> > compatible = "atmel,24c02";
> > reg = <0x55>;
> > ideeprom;
> > };
> > };
> > };
> >
> > [ Note this is preliminary, and I expect some of the bindings to change.
> > Also, I have no plan to even try to get this code upstream ;) ]
>
> This is rather complex, but then, describing relationships within one
> board is already difficult, so I'm not surprised that describing
> connections between boards is even more difficult. I suspect that the
> above could more traditionally be written as:
>
> pic1i2c: i2c-controller {
> ...
>
> eeprom@55 {
> /* insert all other properties here */
> };
> };
>
If I add the above to the i2c controller node, the kernel will try to
instantiate the eeprom when the system comes up. If no card is
inserted at that time, this will fail. The above describes the devices
which needs to be instantiated after a card is inserted into the connector,
and only then (and removed when the card is pulled).
In addition, I use the 'ideeprom' property to establish a callback
to be able to read the eeprom contents and trigger loading the DT overlay.
> But that breaks down once you start needing to represent more than just
> a single EEPROM behind the connector.
>
And if insertion is dynamic, triggered by card insertion.
There are actually several additional i2c devices on the same bus.
To instantiate those I use devicetree overlays, but that is done
after the eeprom is read and I know which overlay to load.
> > > > not the very least because DT isn't supported on x86 and I have to deal with
> > > > that situation as well (and, no, ACPI doesn't solve my problems there either).
> > >
> > > Actually DT is supported very well on x86. There's at least one platform
> > > in mainline that uses it (arch/x86/platform/ce4100/falconfalls.dts) and
> > > I've ported a platform that I worked on in the past to use DT on x86 as
> > > well.
> > >
> > But presumably that was DT only, or was it a system that needs to use
> > DT on top of ACPI ? If so, I would be very interested in that experience,
> > especially if you had any issues to get it working.
>
> I'm not quite sure I understand what you mean by "on top of ACPI". The
> device certainly did support ACPI, but I was using DT more as a
> supplement to describe what ACPI and PCI couldn't.
>
> To be somewhat more specific, the platform used an FPGA connected to the
> chipset using PCIe. That itself was excellent because all of a sudden
> devices were actually discoverable. So it was easy to just implement a
> GPIO, SPI or I2C controller and whatnot within that FPGA, but once a
> device behind SPI or I2C needed to be hooked up, you loose all benefits
> from having something like PCI and you're back to square one.
>
> One example where this became essential was that the touchscreen on the
> device was controlled by an I2C chip, and the touchscreen controller's
> interrupt pin was connected to the GPIO controller on the PCI bus. So
> what we ended up with looked roughly something like this:
>
> pci@3fc {
> [...bunch of nodes to describe PCI hierarchy...]
>
> pci@2,0 {
> /* GPIO expander */
> gpio: pci@0,0 {
> ...
> interrupt-controller;
> ...
> };
> };
>
> [...more nodes...]
>
> pci@8,0 {
> /* I2C controller */
> pci@0,0 {
> touchscreen@48 {
> ...
> interrupt-parent = <&gpio>;
> interrupts = <1 0x8>;
> ...
> };
> };
> };
> };
>
> That's a *very* simplified form. The complete device tree is much more
> complex because it requires the exact hierarchy of PCI to be represented
> in order for the right device nodes to end up attached to the right PCI
> devices.
>
> But perhaps that doesn't help you at all with the problems that you've
> encountered?
>
Actually, the use case sounds pretty similar, so maybe you have solved the
problem at least to some degree. In my case, I'll also need devicetree overlays,
since I also need to be able to handle OIR capable cards, but that is a separate
set of problems.
Was this just a matter of enabling OF on this platform, or do you have an
out-of-tree set of patches ? If the latter, is it available somewhere
to look at (including the complete devicetree from your above example) ?
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
