From mboxrd@z Thu Jan 1 00:00:00 1970 From: balbi@ti.com (Felipe Balbi) Date: Thu, 21 Jul 2011 12:09:19 +0300 Subject: [PATCH 3/4] dt: omap3: add generic board file for dt support In-Reply-To: <4E27E967.7090501@ti.com> References: <1310592975-25773-1-git-send-email-manjugk@ti.com> <1310592975-25773-4-git-send-email-manjugk@ti.com> <20110718090710.GZ5783@atomide.com> <20110719213458.GO6848@ponder.secretlab.ca> <4E27E967.7090501@ti.com> Message-ID: <20110721090918.GI23253@legolas.emea.dhcp.ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 [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: