Grant, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Grant Likely > Sent: Tuesday, April 06, 2010 8:47 AM > To: Herring Robert-RA7055 > Cc: [email protected] > Subject: Re: devicetree platform bus bindings > > Hi Rob, > > On Tue, Apr 6, 2010 at 6:45 AM, Herring Robert-RA7055 > <[email protected]> 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 _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
