devicetree platform bus bindings

[Herring Robert-RA7055]

Grant,

> -----Original Message-----
> From: glikely at secretlab.ca [mailto:glikely at secretlab.ca] On 
> Behalf Of Grant Likely
> Sent: Tuesday, April 06, 2010 8:47 AM
> To: Herring Robert-RA7055
> Cc: devicetree-discuss at lists.ozlabs.org
> Subject: Re: devicetree platform bus bindings
> 
> Hi Rob,
> 
> On Tue, Apr 6, 2010 at 6:45 AM, Herring Robert-RA7055
> <ra7055 at freescale.com> wrote:
> > Grant,
> >
> >> > Do you plan to have generic DT parsing to platform device
> >> creation code or
> >> > will this remain platform specific?
> >>
> >> I'm actively developing this.  A while ago I decided I was 
> not going
> >> to port of_platform_bus_type bus to any new architectures 
> because it
> >> is effectively just platform_bus_type with a slightly different
> >> matching scheme.  So I wrote a patch that generates 
> platform devices
> >> from the device tree instead.
> >>
> >> However, since then I took on the task of removing
> >> of_platform_bus_type entirely and just using 
> platform_bus_type on ppc,
> >> mb & sparc, so arm will be able to use the same code.  The 
> patches I
> >> just pushed out to my experimental branch show my WIP code and how
> >> both the versatile and omap platforms are modified to use 
> the common
> >> code.
> >>
> >> Word of warning though, this is highly experimental code 
> and I cannot
> >> promise it won't break spectacularly.
> >>
> >
> > I've updated to your latest tree and have MX51 working with 
> DT. I've got
> > a few issues with bus_id/name+id. Is your goal that 
> existing platform
> > drivers work unmodified? If so, the current <address>.<name> bus_id
> > scheme doesn't really work. The platform matching code needs
> > platform_device.name to be just a name without any instance 
> id. I was
> > thinking this would be the compatible field. There are also 
> dependencies
> > on the bus_id being name.id in the clock code for example. I was
> > planning to use cell-index property for the id.
> 
> As much as possible, I'd prefer drivers to use OF style matching for
> the OF use case so that driver bindings are explicit.  For this to
> work an OF match table needs to be added to the driver (which is
> trivial).  The code to do this is already in my tree, but I don't yet
> know if it works.
> 
Adding the table may be trivial, but if there are other dependencies on name, id or dev_name, then more changes are needed. For example, id could be used as an array index to driver data. The imx uart driver is one example of this:

sport->port.line = pdev->id;
...
imx_ports[pdev->id] = sport;


> I'm also playing with the platform bus code to test the compatible
> list against the platform_driver's .id_table list, but I haven't
> pushed any of that code out yet.  Either way, the of-style binding
> string would need to be added to the driver.  I don't want to
> reproduce the nasty hack that spi and i2c are using right now to
> derive a single device name from the compatible list.
> 
> > How do you see adding platform_data to the devices working?
> 
> I'm hoping to avoid it as much as possible and get drivers to decode
> their own platform_data from the device tree properties.  This does
> require driver changes too, but again it is contained and can co-exist
> with the existing platform_data method.  In the few cases where
> platform data is unavoidable (such as function pointers), I'm thinking
> about using platform-specific hooks or notifiers so that platform code
> can modify device registrations before the device gets bound to a
> driver (where modify =3D=3D add pdata at device registration time).
> However, that approach is both opaque and still has the non-type-safe
> problems of current pdata, and I'd rather avoid it unless absolutely
> necessary.
> 
I agree that static data should be in the device tree. As long as there is a hook for setting platform_data, then this transisition can be done over time. I think it is important that drivers not require changes to ease adoption of device trees on ARM. On i.MX for example we have lots of chips with common drivers, but I don't want to have to move all platforms at once to device trees.

Rob