All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Andreas Kemnade <andreas@kemnade.info>
Cc: Bin Liu <b-liu@ti.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, linux-omap@vger.kernel.org,
	letux-kernel@openphoenux.org
Subject: Re: [PATCH] usb: musb: Check devctl status again for a spurious session request
Date: Fri, 28 May 2021 08:57:56 +0300	[thread overview]
Message-ID: <YLCGZEan87yp9Eeq@atomide.com> (raw)
In-Reply-To: <20210527211501.70d176b4@aktux>

Hi,

* Andreas Kemnade <andreas@kemnade.info> [210527 19:15]:
> Hi,
> 
> On Tue, 18 May 2021 18:06:15 +0300
> Tony Lindgren <tony@atomide.com> wrote:
> 
> > On start-up, we can get a spurious session request interrupt with nothing
> > connected. After that the devctl session bit will silently clear, but the
> > musb hardware is never idled until a cable is plugged in, or the glue
> > layer module is reloaded.
> > 
> > Let's just check the session bit again in 3 seconds in peripheral mode
> > to catch the issue.
> > 
> Tested this together with the other musb patch you sent on gta04.
> This has some interesting side effects.
> 
> Test done:
> - loading kernel+ramdisk via usb-dfu
> - disconnecting usb cable
> - loading omap_hdq (to see battery status)
> - idling serial ports
> - checking battery current 1.
> - loading omap2430, phy-twl4030-usb, g_ether
> - checking battery current 2 (again with idled serial ports).
> - rtcwake -s 20 -m mem
> - checking current during suspend (3)
> 
> Without your patches: current 2 is current 1 + approx 15 mA, current 3
> is near current 1.
> With your patches: current 2 is near current 1, current 3 is approx
> 15mA higher.

Interesting, so power consumption is now better for runtime with cable
disconnected, and after booting, but now somehow is now worse for
suspended state. I'll try to reproduce.

> Another strange thing I have hit (I have not done this test before, no
> idea yet if it is related, but it is also about musb):
> Connecting a usb cable while serial ports are idle (not in system
> supend), console serial port does not wake up by input, it reacts again
> if I unplug usb. If I give usb0 an IP address, I can ping it. No
> intensive debugging done there yet. Just stumbled across it.

Hmm so if you have a usb cable connected and gta04 is a b-device, and
there is vbus, musb should not currently idle at all.

Maybe your uart3 wakeirq is not using the uart3_rx.uart3_rx
pad but uses some alternative pad and the wakeirq is not working?

Or the twl4030 usb phy is somehow interfering with the uart3 pins
when usb is in use. Worth checking the schematics again for the
uart3 rx pin used? Sorry I don't remember if omap3 has multiple
alternative pins for uart3, but I think it does.

Regards,

Tony


  reply	other threads:[~2021-05-28  5:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-18 15:06 [PATCH] usb: musb: Check devctl status again for a spurious session request Tony Lindgren
2021-05-27 19:15 ` Andreas Kemnade
2021-05-28  5:57   ` Tony Lindgren [this message]
2021-05-28  9:37     ` Andreas Kemnade
2021-06-02  5:41       ` Tony Lindgren
2021-06-03 21:22         ` Andreas Kemnade
2021-06-04  8:35     ` Andreas Kemnade
2021-06-04  9:39       ` Tony Lindgren
2021-06-04  9:59         ` Andreas Kemnade
2021-06-04 10:08           ` Tony Lindgren
2021-06-04 10:20             ` Andreas Kemnade
2021-06-04 14:45         ` Andreas Kemnade
2021-06-04 16:59         ` Andreas Kemnade
2021-06-05  5:18           ` Tony Lindgren
2021-06-05 14:20             ` Andreas Kemnade
2021-06-06  6:01               ` Tony Lindgren

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=YLCGZEan87yp9Eeq@atomide.com \
    --to=tony@atomide.com \
    --cc=andreas@kemnade.info \
    --cc=b-liu@ti.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=letux-kernel@openphoenux.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-usb@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.