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

[Felipe Balbi]

Hi,

On Thu, Jul 21, 2011 at 02:25:03PM +0530, Rajendra Nayak wrote:
> On 7/20/2011 3:04 AM, Grant Likely wrote:
> >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().
> 
> In fact a lot of what omap_device_build() does today might not even be
> needed anymore. A lot of what it does is populate the platform_device
> structure by looking up the hwmod structs.
> Most of that information would now come from DT and hence all of that
> can be taken off from the hwmod structs. What will still be needed in
> hwmod is other data needed to runtime enable/idle the devices. That
> data however still needs to be linked with the platform_device's that
> DT would create which is what I guess could be done in something
> like a of_platform_bus_create_omap().
> 
> Paul/Benoit, do you guys agree we can get rid of some of the data
> from hwmod, whatever would now get passed in from DT, and keep
> only the PRCM/OCP related stuff for runtime handling?

IMHO, all omap_hwmod_*_data.c files become pretty much useless if we
move completely to DT. All hwmod data is passing today, can be passed
via DT and in a similar Hierarchical manner.

Now WRT omap_device_build() and PM, I think that's still necessary
because it simplifies a lot PM handling. But the data files themselves
can "easily" be purged from kernel and converted into DT.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110721/ed02f2b1/attachment.sig>