Linux USB
 help / color / mirror / Atom feed
From: Marco Felsch <m.felsch@pengutronix.de>
To: Peter Chen <peter.chen@nxp.com>
Cc: "jun.li@freescale.com" <jun.li@freescale.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"stern@rowland.harvard.edu" <stern@rowland.harvard.edu>,
	dl-linux-imx <linux-imx@nxp.com>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 0/3] USB IMX Chipidea fix gpio vbus control
Date: Fri, 28 Feb 2020 08:48:56 +0100	[thread overview]
Message-ID: <20200228074856.gomzgtoxwzj4eele@pengutronix.de> (raw)
In-Reply-To: <20200228025129.GA31815@b29397-desktop>

Hi Peter,

On 20-02-28 02:51, Peter Chen wrote:

...

> > > CI_HDRC_TURN_VBUS_EARLY_ON is introduced by fixing a bug that some i.mx USB
> > > controllers PHY's power is sourced from VBUS, the PHY's power need to be on before
> > > touch some ehci registers, otherwise, the USB signal will be wrong at some low speed
> > > devices use case. So, this flag can't be deleted, it may cause regression.
> > 
> > Pls check my archeological findings and again pls check my patches. I
> > deleted the flag because isn't required anymore afterwards.
> 
> I have already checked your patch, your patch deletes CI_HDRC_TURN_VBUS_EARLY_ON
> quirk, and it may cause regression.

Arg, sorry now I see what you mean. Thanks for your explanation :)
Since the 'struct ehci_ci_priv' contains now an enabled state we can
git rid of the flag. To get it right, the writing the ehci PORT_POWER
must be done before or after we enabled the VBUS? I'm asking because
we can drop the 1st patch of this series.

> > > The solution I see is your may need to implement chipidea VBUS control flow by considering
> > > pm_qos_no_power_off at suspend situation. You may add .suspend API for ci_role_driver,
> > > and called by ci_controller_suspend/ci_controller_resume, of cos, better solution is welcome.
> > 
> > I fixed it within the core [1] and here at the chipidea side.
> > 
> > [1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2020%2F2%2F27%2F669&amp;data=02%7C01%7Cpeter.chen%40nxp.com%7Cad9b3833ae2f433d93ef08d7bb92d4a0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637184111614326500&amp;sdata=SPwwBEGBco6IdP8ufmAnJeeRxuAXGLa0xzYlzFA%2FAvg%3D&amp;reserved=0
> > 
> > You will never enter the ehci_ci_portpower() during suspend without [1]
> > if you are using a vanilla kernel. So IMHO this case can't be tested,
> > sorry.
> > 
> 
> Through set pm_qos_no_power_off as 0, the VBUS will be off. You
> never need to call .ehci_ci_portpower again. You may try my second
> suggestion for fix chipidea issue. I will reply your RFC patch for
> USB core.

Many thanks for testing =)

Regards,
  Marco

> -- 
> 
> Thanks,
> Peter Chen

  reply	other threads:[~2020-02-28  7:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27 10:42 [PATCH 0/3] USB IMX Chipidea fix gpio vbus control Marco Felsch
2020-02-27 10:42 ` [PATCH 1/3] USB: ehci-hub: let port_power() override the ehci_port_power() Marco Felsch
2020-02-27 10:42 ` [PATCH 2/3] Partially Revert "usb: chipidea: host: turn on vbus before add hcd if early vbus on is required" Marco Felsch
2020-02-27 10:42 ` [PATCH 3/3] Revert "usb: chipidea: add a flag for turn on vbus early for host" Marco Felsch
2020-02-27 11:18 ` [PATCH 0/3] USB IMX Chipidea fix gpio vbus control Peter Chen
2020-02-27 11:35   ` Marco Felsch
2020-02-27 12:20     ` Peter Chen
2020-02-27 12:44       ` Marco Felsch
2020-02-27 13:30         ` Peter Chen
2020-02-27 13:59           ` Peter Chen
2020-02-27 14:39           ` Marco Felsch
2020-02-28  2:51             ` Peter Chen
2020-02-28  7:48               ` Marco Felsch [this message]
2020-02-28  9:40                 ` Peter Chen

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=20200228074856.gomzgtoxwzj4eele@pengutronix.de \
    --to=m.felsch@pengutronix.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=jun.li@freescale.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=peter.chen@nxp.com \
    --cc=shawnguo@kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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