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@xxxxxxxxxxxx> [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
Attachment:
signature.asc
Description: Digital signature
