From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rajendra Nayak Subject: Re: [PATCH 3/4] dt: omap3: add generic board file for dt support Date: Thu, 21 Jul 2011 15:03:24 +0530 Message-ID: <4E27F264.4040409@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> <20110721090918.GI23253@legolas.emea.dhcp.ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110721090918.GI23253@legolas.emea.dhcp.ti.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: balbi@ti.com Cc: Kevin Hilman , Paul Walmsley , "Cousson, Benoit" , Tony Lindgren , "G, Manjunath Kondaiah" , devicetree-discuss@lists.ozlabs.org, Grant Likely , ben-linux@fluff.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org List-Id: devicetree@vger.kernel.org On 7/21/2011 2:39 PM, Felipe Balbi wrote: > 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. Would the data representation be equally readable? That's one of the problems I faced when I started looking at it initially trying to move a lot of these structures. > > 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. > From mboxrd@z Thu Jan 1 00:00:00 1970 From: rnayak@ti.com (Rajendra Nayak) Date: Thu, 21 Jul 2011 15:03:24 +0530 Subject: [PATCH 3/4] dt: omap3: add generic board file for dt support In-Reply-To: <20110721090918.GI23253@legolas.emea.dhcp.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> <20110721090918.GI23253@legolas.emea.dhcp.ti.com> Message-ID: <4E27F264.4040409@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 7/21/2011 2:39 PM, Felipe Balbi wrote: > 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. Would the data representation be equally readable? That's one of the problems I faced when I started looking at it initially trying to move a lot of these structures. > > 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. >