Re: [PATCH 3/4] dt: omap3: add generic board file for dt support

[Grant Likely <grant.likely@secretlab.ca>]

On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote:
> * Grant Likely <grant.likely@secretlab.ca> [110716 22:08]:
> > 
> > The way I see it, you've got two options:
> > 
> > 1) modify the of_platform_bus_create() to call some kind of
> > of_platform_bus_create_omap() for devices that match "ti,omap3-device"
> > or something.
> > 
> > 2) Leave of_platform_bus_create(), and instead us a notifier to attach
> > hwmod data to normal platform devices.  omap_device_build() is
> > actually pretty simple.  It allocated a device, it attaches
> > platform_data and hwmod pointers to the device and registers it.
> > omap_device_register() is just a wrapper around
> > platform_device_register().
> > 
> > My preference is definitely #2, but there is a wrinkle in this
> > approach.  Unfortunately omap_devices are not simply plain
> > platform_devices with extra data attached, an omap_device actually
> > embeds the platform_device inside it, which cannot be attached after
> > the fact.  I think I had talked with Kevin (cc'd) about eliminating
> > the embedding, but I cannot remember clearly on this point.  As long
> > as platform_device remains embedded inside struct omap_device, #2
> > won't work.
> > 
> > In either case, looking up the correct hwmod data should be easy for
> > any device provided the omap code maintains a lookup table of
> > compatible strings and base addresses of devices (much like auxdata).
> > In fact, I'd be okay with extending auxdata to include OMAP fields if
> > that would be easiest since the whole point of auxdata is to ease the
> > transition to DT support.  When a matching device is created, the
> > hwmod pointer can easily be attached.  This should work transparently
> > for all omap devices, not just the i2c bus.
> 
> Well we should be able to automgagically build the omap_device for
> each device tree entry.
> 
> And then the device driver probe and runtime PM should be able to take
> care of the rest for the driver. And then there's no more driver
> specific platform init code needed ;)

Right!  That's the solution I'd like to see.

> How about if we just have the hwmod code call omap_device_build for
> each device tree entry?

I think that is pretty much equivalent to suggestion #1 above, only
I'm suggesting to take advantage of the infrastructure already
available in driver/of/platform.c in the form of
of_platform_populate().  The "of_platform_bus_create_omap()" function
suggested above I assumed would directly call omap_device_build().

There are already hooks in the _populate call path to handle the
creation of amba_devices.  I have no problem doing the same thing for
omap devices.

g.