devicetree platform bus bindings

[Grant Likely]

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.

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.

Cheers,
g.