From mboxrd@z Thu Jan 1 00:00:00 1970 From: Santosh Shilimkar Subject: Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency Date: Sat, 16 Feb 2013 15:01:29 +0530 Message-ID: <511F51F1.1000601@ti.com> References: <20130215101610.GR17852@n2100.arm.linux.org.uk> <511E3797.2070802@ti.com> <20130215132726.GT17852@n2100.arm.linux.org.uk> <511E38C3.7080404@ti.com> <20130215163031.GA5724@atomide.com> <20130215164235.GA20840@arwen.pp.htv.fi> <511F20B1.8010502@ti.com> <20130216085528.GA19639@arwen.pp.htv.fi> <511F4EB9.2020408@ti.com> <20130216092236.GB20007@arwen.pp.htv.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from bear.ext.ti.com ([192.94.94.41]:53653 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752861Ab3BPJaS (ORCPT ); Sat, 16 Feb 2013 04:30:18 -0500 In-Reply-To: <20130216092236.GB20007@arwen.pp.htv.fi> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: balbi@ti.com Cc: Tony Lindgren , rafael.j.wysocki@intel.com, Russell King - ARM Linux , Paul Walmsley , Linux OMAP Mailing List , Linux ARM Kernel Mailing List On Saturday 16 February 2013 02:52 PM, Felipe Balbi wrote: > Hi, > > On Sat, Feb 16, 2013 at 02:47:45PM +0530, Santosh Shilimkar wrote: >>> On Sat, Feb 16, 2013 at 11:31:21AM +0530, Santosh Shilimkar wrote: >>>>>> The main goal is to avoid duplicating data both in hwmod and DT. >>>>>> That's pretty much solved as we can have the driver probe populate >>>>>> the common data for hwmod from DT as Santosh has already demonstrated. >>>>>> >>>>>> Then we also want the driver specific idle and reset code to be done >>>>>> in the drivers rather than in hwmod and glue it together with hwmod >>>>>> using runtime PM. The biggest issue there is how do we reset and idle >>>>>> some piece of hardware for PM purposes when there's no driver loaded. >>>>> >>>>> right, this will be a tough nut to crack. >>>>> >>>>> I guess the only way would be reset all IPs early in the boot process, >>>>> before even creating the platform-devices. Can we do that ? I mean, from >>>>> omap_device_build_from_dt() we have access to address space of all >>>>> devices, through ti,hwmods we can figure out which hwmods are linked to >>>>> that particular device, so whenever you build a device, you could just >>>>> call _reset(). >>>>> >>>> Thats what we do today and it works perfectly. As per Tony's suggestion, >>>> we need to move the non-probed devices reset and idle setup to late_init >>>> which is also doable. >>>> >>>> In that case when probed driver calls runtime_get(), we reset that >>>> device and setup the idle settings. And remainder of the devices >>>> are managed in late_init(). >>> >>> what's the point in moving it to late_initcall() ? It makes no >>> difference, if no driver binds to that device it will stay in reset >>> anyway. Maybe what we're missing is properly idling (not exactly) all >>> devices before driver probe kicks in. >>> >> I think it is largely reducing the early init dependencies and also >> reducing the role of platform code who today takes care of every >> device idle and reset initialization. That way late_init() will >> only have to care about the devices which are not probed by >> drivers. >> >> Tony, Is that right ? > > Makes not much difference, except that you will have to keep track of > which devices have gotten a driver probed and which haven't. > > IMO, it sounds a lot better to reset everything early on, so we know > we're starting at a known stage (and thus drop all bootloader > dependencies) then to follow the other route. > I tend to agree with you. This was exactly the reason Paul and Benoit added that support first up as part of early init code. >>> The difficult part is handling special reset requirements for devices >>> without drivers as there'd be no ->runtime_reset() to call. >>> >> I don't think that requirement exists so if we address the driver >> requirement, we are good. Even otherwise also, it can be managed > > Look back at what you want to do at late_initcall() time. You want to > reset all devices which haven't gotten a driver bound to them. > >> from platform code. > > right, the you will need even more data in hwmod to let it know about > the special devices. /me wonders when the amount of data will actually > decrease. > Well that is already supported. There is no need to add any additional information. Device which are initialized, there state is set as initialized. So the late_init() will just have to iterate over un-initialised devices. Just to be clear, I am also in favor of just keeping that part as it is today but we were exploring other options based on comments from Tony during OMAP5 data review. Regards, Santosh From mboxrd@z Thu Jan 1 00:00:00 1970 From: santosh.shilimkar@ti.com (Santosh Shilimkar) Date: Sat, 16 Feb 2013 15:01:29 +0530 Subject: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency In-Reply-To: <20130216092236.GB20007@arwen.pp.htv.fi> References: <20130215101610.GR17852@n2100.arm.linux.org.uk> <511E3797.2070802@ti.com> <20130215132726.GT17852@n2100.arm.linux.org.uk> <511E38C3.7080404@ti.com> <20130215163031.GA5724@atomide.com> <20130215164235.GA20840@arwen.pp.htv.fi> <511F20B1.8010502@ti.com> <20130216085528.GA19639@arwen.pp.htv.fi> <511F4EB9.2020408@ti.com> <20130216092236.GB20007@arwen.pp.htv.fi> Message-ID: <511F51F1.1000601@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Saturday 16 February 2013 02:52 PM, Felipe Balbi wrote: > Hi, > > On Sat, Feb 16, 2013 at 02:47:45PM +0530, Santosh Shilimkar wrote: >>> On Sat, Feb 16, 2013 at 11:31:21AM +0530, Santosh Shilimkar wrote: >>>>>> The main goal is to avoid duplicating data both in hwmod and DT. >>>>>> That's pretty much solved as we can have the driver probe populate >>>>>> the common data for hwmod from DT as Santosh has already demonstrated. >>>>>> >>>>>> Then we also want the driver specific idle and reset code to be done >>>>>> in the drivers rather than in hwmod and glue it together with hwmod >>>>>> using runtime PM. The biggest issue there is how do we reset and idle >>>>>> some piece of hardware for PM purposes when there's no driver loaded. >>>>> >>>>> right, this will be a tough nut to crack. >>>>> >>>>> I guess the only way would be reset all IPs early in the boot process, >>>>> before even creating the platform-devices. Can we do that ? I mean, from >>>>> omap_device_build_from_dt() we have access to address space of all >>>>> devices, through ti,hwmods we can figure out which hwmods are linked to >>>>> that particular device, so whenever you build a device, you could just >>>>> call _reset(). >>>>> >>>> Thats what we do today and it works perfectly. As per Tony's suggestion, >>>> we need to move the non-probed devices reset and idle setup to late_init >>>> which is also doable. >>>> >>>> In that case when probed driver calls runtime_get(), we reset that >>>> device and setup the idle settings. And remainder of the devices >>>> are managed in late_init(). >>> >>> what's the point in moving it to late_initcall() ? It makes no >>> difference, if no driver binds to that device it will stay in reset >>> anyway. Maybe what we're missing is properly idling (not exactly) all >>> devices before driver probe kicks in. >>> >> I think it is largely reducing the early init dependencies and also >> reducing the role of platform code who today takes care of every >> device idle and reset initialization. That way late_init() will >> only have to care about the devices which are not probed by >> drivers. >> >> Tony, Is that right ? > > Makes not much difference, except that you will have to keep track of > which devices have gotten a driver probed and which haven't. > > IMO, it sounds a lot better to reset everything early on, so we know > we're starting at a known stage (and thus drop all bootloader > dependencies) then to follow the other route. > I tend to agree with you. This was exactly the reason Paul and Benoit added that support first up as part of early init code. >>> The difficult part is handling special reset requirements for devices >>> without drivers as there'd be no ->runtime_reset() to call. >>> >> I don't think that requirement exists so if we address the driver >> requirement, we are good. Even otherwise also, it can be managed > > Look back at what you want to do at late_initcall() time. You want to > reset all devices which haven't gotten a driver bound to them. > >> from platform code. > > right, the you will need even more data in hwmod to let it know about > the special devices. /me wonders when the amount of data will actually > decrease. > Well that is already supported. There is no need to add any additional information. Device which are initialized, there state is set as initialized. So the late_init() will just have to iterate over un-initialised devices. Just to be clear, I am also in favor of just keeping that part as it is today but we were exploring other options based on comments from Tony during OMAP5 data review. Regards, Santosh