All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.