mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@ti.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: balbi@ti.com, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org, Greg Kroah-Hartman <gregkh@suse.de>,
	Jarkko Nikula <jarkko.nikula@bitmer.com>,
	stable@vger.kernel.org, Hema Kalliguddi <hemahk@ti.com>
Subject: Re: [PATCH] usb: musb: fix pm_runtime mismatch
Date: Fri, 16 Dec 2011 01:50:18 +0200	[thread overview]
Message-ID: <20111215235017.GA2242@legolas.emea.dhcp.ti.com> (raw)
In-Reply-To: <CAMP44s1JMwF95nOgZLvdL7ke6fYz-ar5SDv=Lu-5QJ==0bkH=Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2994 bytes --]

On Fri, Dec 16, 2011 at 01:31:02AM +0200, Felipe Contreras wrote:
> On Fri, Dec 16, 2011 at 1:01 AM, Felipe Balbi <balbi@ti.com> wrote:
> > On Fri, Dec 16, 2011 at 12:42:14AM +0200, Felipe Contreras wrote:
> >> In musb_init_controller() there's a pm_runtime_put(), but there's no
> >> pm_runtime_get(), which creates a mismatch that causes the driver to
> >> sleep when it shouldn't.
> >>
> >> This was introduced in 7acc619, but it wasn't triggered until 18a2689
> >> was merged to Linus' branch at point 6899608.
> >
> > you need to add the commit description (whatever was the mail's subject)
> > here too. And you should put in Cc the author or those commits too,
> > otherwise we can't poke into their brains to understand what they were
> > thinking when they originally wrote those patches.
> 
> True, but code is code, and even if you don't know what he was
> thinking, it's clear there's something wrong.
> 
> >> However, it seems most of the time this is used in a way that keeps the
> >> counter above 0, so nobody noticed. Also, it seems to depend on the
> >> configuration used.
> >>
> >> I found the problem by loading isp1704_charger before any usb gadgets:
> >> http://article.gmane.org/gmane.linux.kernel/1226122
> >>
> >> All versions after 2.6.39 are affected.
> >>
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> >> ---
> >>  drivers/usb/musb/musb_core.c |    2 --
> >>  1 files changed, 0 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> >> index b63ab15..920f04e 100644
> >> --- a/drivers/usb/musb/musb_core.c
> >> +++ b/drivers/usb/musb/musb_core.c
> >> @@ -2012,8 +2012,6 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
> >>       if (status < 0)
> >>               goto fail3;
> >>
> >> -     pm_runtime_put(musb->controller);
> >
> > To me the real fix would be add the missing pm_runtime_get_sync(). On
> > probe() we're actually accessing MUSB's address space which needs it's
> > clocks turned on. I guess it's only working now by chance, probably
> > because glue layer calls pm_runtime_get_sync() to access it's own
> > address space and that uses the same clocks.
> 
> Are you sure it's "musb-hdrc", and not "musb-omap2430" the one
> accessing the relevant address-space? From the runtime_pm
> documentation it looks like only the probe function should deal with
> this.
> 
> If "musb-hdrc" was truly accessing these registers, then I would get
> the same failure because the clocks are turned off, but I don't...

see musb_core_init(); You don't see any problems when accessing those
addresses because musb_platform_init() will fall into
omap2430_musb_init() which calls pm_runtime_get_sync(), and the same
clock actually enables both address spaces (musb-omap2430 and
musb-hdrc).

(now, this was all from memory, so it could be wrong ;-)

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2011-12-15 23:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-15 22:42 Felipe Contreras
2011-12-15 23:01 ` Felipe Balbi
2011-12-15 23:31   ` Felipe Contreras
2011-12-15 23:50     ` Felipe Balbi [this message]
2011-12-16  1:13       ` Felipe Contreras
2011-12-16  1:38         ` Felipe Balbi
2011-12-19 19:39           ` Felipe Contreras
2011-12-15 23:02 ` Greg KH
2011-12-15 23:11   ` Greg KH
2011-12-15 23:52     ` Felipe Balbi
2011-12-16 10:46 ` Sergei Shtylyov

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=20111215235017.GA2242@legolas.emea.dhcp.ti.com \
    --to=balbi@ti.com \
    --cc=felipe.contreras@gmail.com \
    --cc=gregkh@suse.de \
    --cc=hemahk@ti.com \
    --cc=jarkko.nikula@bitmer.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stable@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®