Re: [Ksummit-discuss] [TECH TOPIC] Driver model/resources, ACPI, DT, etc (sigh)

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

On Wednesday, May 14, 2014 02:06:10 PM Arnd Bergmann wrote:
> On Tuesday 13 May 2014 14:14:42 Olof Johansson wrote:
> > On Tue, May 06, 2014 at 03:35:41PM +0200, Arnd Bergmann wrote:
> > > On Tuesday 06 May 2014 14:18:56 Rafael J. Wysocki wrote:
> > > 
> > > We should definitely be able to have an interface like this for
> > > ACPI, but you don't have a 'struct device_node' pointer then.
> > > We can add a new
> > > 
> > > bool dev_property_read_bool(const struct device *dev,
> > >                             const char *propname);
> > 
> > > 
> > > that handles both, but then you have to change every driver
> > > that is already using of_property_read_bool() and that can
> > > get used with ACPI.
> > 
> > It's actually not that easy in practice. There's not a one-to-one
> > correspondence between device tree nodes and struct devices in the
> > kernel. There are many bindings that use subnodes for sections of their
> > information, and so on.
> 
> I also don't think we can have a grand unified solution to the general
> problem, but doing the above would solve a lot of individual problems
> for all the simple drivers that don't use sub-nodes in DT.
> 
> I really don't see any downsides to using a common named property
> API for simple values in drivers that can.

I agree.

> Devices with sub-nodes are by definition complex to handle, and
> I think we will always have cases that are too complex to use
> a common interface. At the moment, we can share drivers that
> have only memory and irq resources, which is a significant share
> already. We can over time extend this to drivers that use strings,
> booleans, integers, or arrays of those. We can also extend it
> for things like gpios and dma-channels (both of which partly work
> already but are limited when it comes to naming) and a few other
> things.

Yes.

> > > An advantage of the dev_property_read_bool()
> > > interface however is that it would also work for platform
> > > devices that are created in platform code using
> > > platform_device_register_full() or similar if we add a way
> > > to define simple properties in C code. That would also simplify
> > > a lot of drivers that use both (simple) platform_data and DT
> > > today.
> > 
> > I'm not a fan of this "grand unified abstraction layer". Driver writes are
> > already complaining that things are too complicated with the move to device
> > tree, and we're making things even more abstracted and complicated here. People
> > will need to peel back even more layers to figure out what's actually going on.
> > 
> > 
> > For the truly trivial stuff, there are some quite simple ways to handle this:
> > 
> > 1. Make sure that anything that can be a named IORESOURCE_* is so. Which could
> >    mean moving over GPIO and possibly clocks to that, and use those for lookup.
> 
> We are actually moving away from IORESOURCE_* for things that are not
> originally handled as resources. I don't think we should reverse that
> course.
> 
> For both the examples I mentioned above (GPIO and DMA), people have in the
> past put them into resource structures with a platform specific
> interpretation. With the move to DT, we have actually broken this
> because there is no longer a global number space for them in general.
> 
> Instead, you have a device pointer and a local name that you can use
> to resolve a pointer to a structure (gpio descriptor or dma channel).
> For GPIOs, we keep the integer based API for compatibility, but it would
> be nice to move to the descriptor interface over time.
> 
> If it were not so much work, we'd probably also move away from IRQ numbers
> towards passing IRQ descriptor pointers.
> 
> The way I see things moving forward for ACPI is to add a standard way to
> name things (GPIOs, IRQs, DMAs, ...) so we can have a generic 'give me
> a pointer to the X object for this device' for each subsystem we want to
> have it for. Note that this would probably not be a combined interface
> across subsystems though.

That's my idea too.

Rafael