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

[Tony Lindgren]

* Grant Likely <grant.likely at secretlab.ca> [110719 14:29]:
> On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote:
> > * Grant Likely <grant.likely at 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().

OK
 
> 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.

OK 

Regards,

Tony