From: Tony Lindgren <tony@atomide.com> To: Felipe Balbi <balbi@ti.com> Cc: 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: Thu, 14 Feb 2013 10:12:17 -0800 [thread overview] Message-ID: <20130214181217.GA11806@atomide.com> (raw) In-Reply-To: <20130214175650.GA25891@arwen.pp.htv.fi> * Felipe Balbi <balbi@ti.com> [130214 10:00]: > Hi, > > On Thu, Feb 14, 2013 at 09:12:53AM -0800, Tony Lindgren wrote: > > * Felipe Balbi <balbi@ti.com> [130214 03:19]: > > > Currently the omap-serial driver will not > > > work properly if booted via DT with CPUIDLE > > > enabled because it depends on function pointers > > > provided by hwmod to change its own SYSCONFIG > > > register. > > > > > > Remove that relyance on hwmod by moving SYSCONFIG > > > handling to driver itself. Note that this also > > > fixes a possible corner case bug where we could > > > be putting UART in Force Idle mode if we called > > > omap_serial_enable_wakeup(up, false) after setting > > > NOIDLE to the idle mode. This is because hwmod > > > has no protection against that situation. > > Any comments to these last two sentences ? Well I think all the driver handling should be done in the driver since we now have runtime PM. > > I agree the sysconfig stuff should be handled in the drivers. > > But considering that we need to also reset or idle hardware > > that may not have a driver loaded, it's best to put the > > reset/idle function in to the driver specific header as > > an inline function. > > that is likely to cause quite a few isues, don't you think? > > hwmod depending on driver code to reset particular IPs ? Seems like we > need a generic device_reset() hook which can be called by platform code, > no ? Not sure if that would help a lot though. > > > This way the hwmod code can idle or reset the unclaimed > > hardware in a late_initcall. > > The problem with this: > > my_driver.h: > > static inline void my_driver_reset(struct my_driver *drv) > { > writel(drv->regs, SYSS, RESET); > } > > how will hwmod provide drv pointer ? Even if we use void __iomem * it > would mean that hwmod would have to a) access driver's ioremaped area or > b) ioremap() the same area again. Well the ioremapping should only be done in the driver ideally. Currently we have a mess of both hwmod and driver doing the ioremapping. So in the long run, let's assume only the driver ioremaps for most of the cases where there is a driver available. And only in the case there is no driver, hwmod can parse the address space from DT for the unclaimed hardware in the late_initcall. So the shared inline function should just take the __iomem * and size instead of *drv so both the driver and hwmod code can tinker with the autoidle bit. > Note sure if any of those are acceptable. Hmm what issues do you see in the above suggestion? > > And probably the handling of sysconfig bits should be > > done using a common header in include/linux/omap-hwmod.h > > or something so it can be shared between drivers. > > That could be done, though I think the header name could be different. > Maybe it could match the document which define those registers, let me > just check if we're allowed to use that publicly :-p Cool yeah I have no preference where that header should be. Maybe something bus specific like include/linux/bus/omap-hwmod.h? Regards, Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren) To: linux-arm-kernel@lists.infradead.org Subject: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency Date: Thu, 14 Feb 2013 10:12:17 -0800 [thread overview] Message-ID: <20130214181217.GA11806@atomide.com> (raw) In-Reply-To: <20130214175650.GA25891@arwen.pp.htv.fi> * Felipe Balbi <balbi@ti.com> [130214 10:00]: > Hi, > > On Thu, Feb 14, 2013 at 09:12:53AM -0800, Tony Lindgren wrote: > > * Felipe Balbi <balbi@ti.com> [130214 03:19]: > > > Currently the omap-serial driver will not > > > work properly if booted via DT with CPUIDLE > > > enabled because it depends on function pointers > > > provided by hwmod to change its own SYSCONFIG > > > register. > > > > > > Remove that relyance on hwmod by moving SYSCONFIG > > > handling to driver itself. Note that this also > > > fixes a possible corner case bug where we could > > > be putting UART in Force Idle mode if we called > > > omap_serial_enable_wakeup(up, false) after setting > > > NOIDLE to the idle mode. This is because hwmod > > > has no protection against that situation. > > Any comments to these last two sentences ? Well I think all the driver handling should be done in the driver since we now have runtime PM. > > I agree the sysconfig stuff should be handled in the drivers. > > But considering that we need to also reset or idle hardware > > that may not have a driver loaded, it's best to put the > > reset/idle function in to the driver specific header as > > an inline function. > > that is likely to cause quite a few isues, don't you think? > > hwmod depending on driver code to reset particular IPs ? Seems like we > need a generic device_reset() hook which can be called by platform code, > no ? Not sure if that would help a lot though. > > > This way the hwmod code can idle or reset the unclaimed > > hardware in a late_initcall. > > The problem with this: > > my_driver.h: > > static inline void my_driver_reset(struct my_driver *drv) > { > writel(drv->regs, SYSS, RESET); > } > > how will hwmod provide drv pointer ? Even if we use void __iomem * it > would mean that hwmod would have to a) access driver's ioremaped area or > b) ioremap() the same area again. Well the ioremapping should only be done in the driver ideally. Currently we have a mess of both hwmod and driver doing the ioremapping. So in the long run, let's assume only the driver ioremaps for most of the cases where there is a driver available. And only in the case there is no driver, hwmod can parse the address space from DT for the unclaimed hardware in the late_initcall. So the shared inline function should just take the __iomem * and size instead of *drv so both the driver and hwmod code can tinker with the autoidle bit. > Note sure if any of those are acceptable. Hmm what issues do you see in the above suggestion? > > And probably the handling of sysconfig bits should be > > done using a common header in include/linux/omap-hwmod.h > > or something so it can be shared between drivers. > > That could be done, though I think the header name could be different. > Maybe it could match the document which define those registers, let me > just check if we're allowed to use that publicly :-p Cool yeah I have no preference where that header should be. Maybe something bus specific like include/linux/bus/omap-hwmod.h? Regards, Tony
next prev parent reply other threads:[~2013-02-14 18:12 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 [this message] 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 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=20130214181217.GA11806@atomide.com \ --to=tony@atomide.com \ --cc=balbi@ti.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ /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.