From: Felipe Balbi <balbi@ti.com> To: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: balbi@ti.com, Tony Lindgren <tony@atomide.com>, rafael.j.wysocki@intel.com, Russell King - ARM Linux <linux@arm.linux.org.uk>, Paul Walmsley <paul@pwsan.com>, Linux OMAP Mailing List <linux-omap@vger.kernel.org>, Linux ARM Kernel Mailing List <linux-arm-kernel@lists.infradead.org> Subject: Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency Date: Sat, 16 Feb 2013 11:22:37 +0200 [thread overview] Message-ID: <20130216092236.GB20007@arwen.pp.htv.fi> (raw) In-Reply-To: <511F4EB9.2020408@ti.com> [-- Attachment #1: Type: text/plain, Size: 3027 bytes --] 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. > >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. -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: balbi@ti.com (Felipe Balbi) To: linux-arm-kernel@lists.infradead.org Subject: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency Date: Sat, 16 Feb 2013 11:22:37 +0200 [thread overview] Message-ID: <20130216092236.GB20007@arwen.pp.htv.fi> (raw) In-Reply-To: <511F4EB9.2020408@ti.com> 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. > >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. -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130216/6506aeec/attachment.sig>
next prev parent reply other threads:[~2013-02-16 9:22 UTC|newest] Thread overview: 142+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-02-14 11:15 [RFC/NOT FOR MERGING 1/3] arm: omap: use generic implementation if !od Felipe Balbi 2013-02-14 11:15 ` Felipe Balbi 2013-02-14 11:15 ` [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency Felipe Balbi 2013-02-14 17:12 ` Tony Lindgren 2013-02-14 17:12 ` Tony Lindgren 2013-02-14 17:56 ` Felipe Balbi 2013-02-14 17:56 ` Felipe Balbi 2013-02-14 18:12 ` Tony Lindgren 2013-02-14 18:12 ` Tony Lindgren 2013-02-14 19:27 ` Felipe Balbi 2013-02-14 19:27 ` Felipe Balbi 2013-02-14 19:39 ` Tony Lindgren 2013-02-14 19:39 ` Tony Lindgren 2013-02-14 20:47 ` Paul Walmsley 2013-02-14 20:47 ` Paul Walmsley 2013-02-14 21:40 ` Paul Walmsley 2013-02-14 21:40 ` Paul Walmsley 2013-02-14 22:47 ` Tony Lindgren 2013-02-14 22:47 ` Tony Lindgren 2013-02-15 6:46 ` Felipe Balbi 2013-02-15 6:46 ` Felipe Balbi 2013-02-15 7:29 ` Santosh Shilimkar 2013-02-15 7:29 ` Santosh Shilimkar 2013-02-19 15:30 ` Paul Walmsley 2013-02-19 15:30 ` Paul Walmsley 2013-02-19 15:45 ` Russell King - ARM Linux 2013-02-19 15:45 ` Russell King - ARM Linux 2013-02-19 16:30 ` Tony Lindgren 2013-02-19 16:30 ` Tony Lindgren 2013-02-19 18:22 ` Russell King - ARM Linux 2013-02-19 18:22 ` Russell King - ARM Linux 2013-02-19 19:31 ` Tony Lindgren 2013-02-19 19:31 ` Tony Lindgren 2013-02-19 19:43 ` hwmod data duplication (was: Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency) Felipe Balbi 2013-02-19 19:43 ` Felipe Balbi 2013-02-19 22:09 ` Tony Lindgren 2013-02-19 22:09 ` Tony Lindgren 2013-02-19 22:22 ` Felipe Balbi 2013-02-19 22:22 ` Felipe Balbi 2013-02-19 22:31 ` Tony Lindgren 2013-02-19 22:31 ` Tony Lindgren 2013-02-19 22:51 ` Felipe Balbi 2013-02-19 22:51 ` Felipe Balbi 2013-02-15 10:26 ` [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency Russell King - ARM Linux 2013-02-15 10:26 ` Russell King - ARM Linux 2013-02-14 21:56 ` Paul Walmsley 2013-02-14 21:56 ` Paul Walmsley 2013-02-14 22:22 ` Tony Lindgren 2013-02-14 22:22 ` Tony Lindgren 2013-02-15 6:53 ` Felipe Balbi 2013-02-15 6:53 ` Felipe Balbi 2013-02-15 7:27 ` Bedia, Vaibhav 2013-02-15 7:27 ` Bedia, Vaibhav 2013-02-19 15:27 ` Paul Walmsley 2013-02-19 15:27 ` Paul Walmsley 2013-02-19 16:38 ` Tony Lindgren 2013-02-19 16:38 ` Tony Lindgren 2013-02-19 16:57 ` Felipe Balbi 2013-02-19 16:57 ` Felipe Balbi 2013-02-19 17:43 ` Tony Lindgren 2013-02-19 17:43 ` Tony Lindgren 2013-02-19 18:34 ` Felipe Balbi 2013-02-19 18:34 ` Felipe Balbi 2013-02-19 19:16 ` Kevin Hilman 2013-02-19 19:16 ` Kevin Hilman 2013-02-19 19:32 ` Felipe Balbi 2013-02-19 19:32 ` Felipe Balbi 2013-02-19 19:50 ` Kevin Hilman 2013-02-19 19:50 ` Kevin Hilman 2013-02-19 20:10 ` OMAP reset requirements (was: Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency) ^[:x Felipe Balbi 2013-02-19 20:10 ` OMAP reset requirements (was: Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency)^[:x Felipe Balbi 2013-02-19 20:25 ` OMAP reset requirements Kevin Hilman 2013-02-19 20:25 ` Kevin Hilman 2013-02-20 6:26 ` [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency Santosh Shilimkar 2013-02-20 6:26 ` Santosh Shilimkar 2013-02-15 6:44 ` Felipe Balbi 2013-02-15 6:44 ` Felipe Balbi 2013-02-15 7:27 ` Bedia, Vaibhav 2013-02-15 7:27 ` Bedia, Vaibhav 2013-02-20 17:38 ` Paul Walmsley 2013-02-20 17:38 ` Paul Walmsley 2013-02-20 19:16 ` Felipe Balbi 2013-02-20 19:16 ` Felipe Balbi 2013-02-20 20:03 ` Paul Walmsley 2013-02-20 20:03 ` Paul Walmsley 2013-02-20 20:37 ` Russell King - ARM Linux 2013-02-20 20:37 ` Russell King - ARM Linux 2013-02-21 10:16 ` Peter De Schrijver 2013-02-21 10:16 ` Peter De Schrijver 2013-02-21 12:09 ` Peter Korsgaard 2013-02-21 12:09 ` Peter Korsgaard 2013-02-15 10:16 ` Russell King - ARM Linux 2013-02-15 10:16 ` Russell King - ARM Linux 2013-02-15 13:26 ` Santosh Shilimkar 2013-02-15 13:26 ` Santosh Shilimkar 2013-02-15 13:27 ` Russell King - ARM Linux 2013-02-15 13:27 ` Russell King - ARM Linux 2013-02-15 13:31 ` Santosh Shilimkar 2013-02-15 13:31 ` Santosh Shilimkar 2013-02-15 16:30 ` Tony Lindgren 2013-02-15 16:30 ` Tony Lindgren 2013-02-15 16:42 ` Felipe Balbi 2013-02-15 16:42 ` Felipe Balbi 2013-02-16 6:01 ` Santosh Shilimkar 2013-02-16 6:01 ` Santosh Shilimkar 2013-02-16 8:55 ` Felipe Balbi 2013-02-16 8:55 ` Felipe Balbi 2013-02-16 9:17 ` Santosh Shilimkar 2013-02-16 9:17 ` Santosh Shilimkar 2013-02-16 9:22 ` Felipe Balbi [this message] 2013-02-16 9:22 ` Felipe Balbi 2013-02-16 9:31 ` Santosh Shilimkar 2013-02-16 9:31 ` Santosh Shilimkar 2013-02-18 15:27 ` Kevin Hilman 2013-02-18 15:27 ` Kevin Hilman 2013-02-16 5:31 ` Santosh Shilimkar 2013-02-16 5:31 ` Santosh Shilimkar 2013-02-16 5:36 ` Nicolas Pitre 2013-02-16 5:36 ` Nicolas Pitre 2013-02-16 5:48 ` Santosh Shilimkar 2013-02-16 5:48 ` Santosh Shilimkar 2013-02-18 8:08 ` Bedia, Vaibhav 2013-02-18 8:08 ` Bedia, Vaibhav 2013-02-18 8:28 ` Santosh Shilimkar 2013-02-18 8:28 ` Santosh Shilimkar 2013-02-15 15:40 ` Kevin Hilman 2013-02-15 15:40 ` Kevin Hilman 2013-02-15 16:03 ` Felipe Balbi 2013-02-15 16:03 ` Felipe Balbi 2013-02-16 4:59 ` Santosh Shilimkar 2013-02-16 4:59 ` Santosh Shilimkar 2013-02-18 14:52 ` Kevin Hilman 2013-02-18 14:52 ` Kevin Hilman 2013-02-14 11:15 ` [RFC/NOT FOR MERGING 3/3] arm: boot: dts: omap: remove ti_hwmods from UART ports Felipe Balbi 2013-02-14 11:20 ` [RFC/NOT FOR MERGING 1/3] arm: omap: use generic implementation if !od Russell King - ARM Linux 2013-02-14 11:20 ` Russell King - ARM Linux 2013-02-14 17:57 ` Felipe Balbi 2013-02-14 17:57 ` Felipe Balbi 2013-02-15 15:28 ` Kevin Hilman 2013-02-15 15:28 ` Kevin Hilman 2013-02-15 16:04 ` Felipe Balbi 2013-02-15 16:04 ` Felipe Balbi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20130216092236.GB20007@arwen.pp.htv.fi \ --to=balbi@ti.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=paul@pwsan.com \ --cc=rafael.j.wysocki@intel.com \ --cc=santosh.shilimkar@ti.com \ --cc=tony@atomide.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.