From: Alexander Stein <alexander.stein@ew.tq-group.com>
To: Peter Chen <peter.chen@kernel.org>, Jun Li <jun.li@nxp.com>
Cc: Peter Chen <hzpeterchen@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
dl-linux-imx <linux-imx@nxp.com>,
USB list <linux-usb@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: (EXT) RE: (EXT) Re: [RFC 1/1] usb: chipidea: ci_hdrc_imx: disable runtime pm for HSIC interface
Date: Wed, 04 May 2022 09:06:25 +0200 [thread overview]
Message-ID: <5566202.DvuYhMxLoT@steina-w> (raw)
In-Reply-To: <VI1PR04MB4333D96588BDAB546B61EADF89ED9@VI1PR04MB4333.eurprd04.prod.outlook.com>
Helllo,
Am Dienstag, 12. April 2022, 13:36:55 CEST schrieb Jun Li:
> > -----Original Message-----
> > From: Alexander Stein <alexander.stein@ew.tq-group.com>
> > Sent: Monday, April 11, 2022 9:52 PM
> > To: Peter Chen <peter.chen@kernel.org>; Jun Li <jun.li@nxp.com>
> > Cc: Peter Chen <hzpeterchen@gmail.com>; Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org>; Shawn Guo <shawnguo@kernel.org>; Sascha
> > Hauer <s.hauer@pengutronix.de>; Fabio Estevam <festevam@gmail.com>;
> > Pengutronix Kernel Team <kernel@pengutronix.de>; dl-linux-imx
> > <linux-imx@nxp.com>; USB list <linux-usb@vger.kernel.org>;
> > linux-arm-kernel@lists.infradead.org
> > Subject: Re: (EXT) RE: (EXT) Re: [RFC 1/1] usb: chipidea: ci_hdrc_imx:
> > disable runtime pm for HSIC interface
> >
> > Hi,
> >
> > Am Samstag, 9. April 2022, 06:49:54 CEST schrieb Jun Li:
> > > > -----Original Message-----
> > > > From: Peter Chen <peter.chen@kernel.org>
> > > > Sent: Saturday, April 9, 2022 10:20 AM
> > > > To: Alexander Stein <alexander.stein@ew.tq-group.com>
> > > > Cc: Peter Chen <hzpeterchen@gmail.com>; Greg Kroah-Hartman
> > > > <gregkh@linuxfoundation.org>; Shawn Guo <shawnguo@kernel.org>;
> > > > Sascha Hauer <s.hauer@pengutronix.de>; Fabio Estevam
> > > > <festevam@gmail.com>; Pengutronix Kernel Team
> > > > <kernel@pengutronix.de>; dl-linux-imx <linux-imx@nxp.com>; USB list
> > > > <linux-usb@vger.kernel.org>; linux-arm-kernel@lists.infradead.org
> > > > Subject: Re: (EXT) Re: [RFC 1/1] usb: chipidea: ci_hdrc_imx: disable
> > > > runtime pm for HSIC interface
> > > >
> > > > On 22-03-29 10:14:36, Alexander Stein wrote:
> > > > > Hello Peter,
> > > > >
> > > > > Am Dienstag, 15. März 2022, 02:23:23 CEST schrieb Peter Chen:
> > > > > > On Wed, Mar 2, 2022 at 5:42 PM Alexander Stein
> > > > > >
> > > > > > <alexander.stein@ew.tq-group.com> wrote:
> > > > > > > With the add of power-domain support in commit 02f8eb40ef7b
("ARM:
> > > > dts:
> > > > > > > imx7s: Add power domain for imx7d HSIC") runtime suspend will
> > > > > > > disable the power-domain. This prevents IRQs to occur when a
> > > > > > > new device is attached on a downstream hub.
> > > > > > >
> > > > > > > Signed-off-by: Alexander Stein
> > > > > > > <alexander.stein@ew.tq-group.com>
> > > > > > > ---
> > > > > > > Our board TQMa7x + MBa7x (i.MX7 based) uses a HSIC link to
> > > > > > > mounted
> > > >
> > > > USB HUB
> > > >
> > > > > > > on usbh device. Cold plugging an USB mass storage device is
> > > > > > > working
> > > >
> > > > fine.
> > > >
> > > > > > > But once the last non-HUB device is disconnected the ci_hdrc
> > > > > > > device
> > > >
> > > > goes
> > > >
> > > > > > > into runtime suspend.
> > > > > >
> > > > > > Would you please show the difference between cold boot and
> > > > > > runtime suspend after disconnecting the last USB device?
> > > > > >
> > > > > > - Power domain on/off status for HUB device
> > > > > > - Runtime suspend status at /sys entry for HUB device
> > > > > > - "/sys/..power/wakeup" /sys entry for HUB device
> > > > >
> > > > > I hope I got all entries you requested.
> > > > >
> > > > > For reference this is the bus topology:
> > > > > lsusb -t
> > > > > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ci_hdrc/1p, 480M
> > > > > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ci_hdrc/1p, 480M
> > > > >
> > > > > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
> > > > > |
> > > > > |__ Port 2: Dev 3, If 0, Class=Mass Storage,
> > > > >
> > > > > Driver=usb-storage,
> > > >
> > > > 480M
> > > >
> > > > > Bus 2 is a different connector and doesn't matter here. I'm
> > > > > disconnecting
> > > >
> > > > 'Dev
> > > >
> > > > > 3' in this scenario.
> > > > >
> > > > > After boot up with the bus as shown above:
> > > > > $ cat /sys/bus/usb/devices/1-1/power/wakeup
> > > > > disabled
> > > > > $ cat /sys/bus/usb/devices/1-1/power/runtime_status
> > > > > active
> > > > > $ cat /sys/kernel/debug/pm_genpd/usb-hsic-phy/current_state
> > > > > on
> > > > >
> > > > > After disconnecting Dev 3 from the bus ('usb 1-1.2: USB
> > > > > disconnect, device number 3' in dmesg) the status changes as
> > > > > follows (without the patch):
> > > > > $ cat /sys/bus/usb/devices/1-1/power/wakeup
> > > > > disabled
> > > > > $ cat /sys/bus/usb/devices/1-1/power/runtime_status
> > > > > suspended
> > > > > $ cat /sys/kernel/debug/pm_genpd/usb-hsic-phy/current_state
> > > > > off-0
> > > > >
> > > > > For the record, when applying the posted patch this changes into:
> > > > > $ cat /sys/bus/usb/devices/1-1/power/wakeup
> > > > > disabled
> > > > > $ cat /sys/bus/usb/devices/1-1/power/runtime_status
> > > > > suspended
> > > > > $ cat /sys/kernel/debug/pm_genpd/usb-hsic-phy/current_state
> > > > > on
> > > >
> > > > Okay, I think the problem here is the power domain for USB
> > > > controller is off at runtime, but USB controller/PHY needs to detect
> > > > the USB wakeup signal at runtime, so the USB controller/PHY's power
> > > > domain should be not off. The proper change may keep power domain on
> > > > at runtime, and the power domain could be off at system suspend.
> > >
> > > Can this "hsic phy power domain off breaks wakeup" be confirmed?
> > > Like with some hack to move hsic phy power domain on some other device
> > > node:
> > >
> > > non-usb-node {
> > >
> > > ...
> > > power-domains = <&pgc_hsic_phy>;
> > > status = "okay";
> > >
> > > };
> > >
> > > Just make sure this non-usb-node to be runtime active when do hsic hub
> > > test.
> >
> > Thanks for that suggestion. I apparently does work. Using the this small
> > patch
> >
> > --->8---
> > diff --git a/arch/arm/boot/dts/imx7-mba7.dtsi b/arch/arm/boot/dts/imx7-
> > mba7.dtsi index b05f662aa87b..cba2f9efa17e 100644
> > --- a/arch/arm/boot/dts/imx7-mba7.dtsi
> > +++ b/arch/arm/boot/dts/imx7-mba7.dtsi
> > @@ -580,6 +580,7 @@ &uart3 {
> >
> > assigned-clocks = <&clks IMX7D_UART3_ROOT_SRC>;
> > assigned-clock-parents = <&clks IMX7D_OSC_24M_CLK>;
> > status = "okay";
> >
> > + power-domains = <&pgc_hsic_phy>;
> >
> > };
> >
> > &uart4 {
> >
> > --->8---
> >
> > The HSIC power domain is also attached to to uart3.
> >
> > $ cat /sys/kernel/debug/pm_genpd/usb-hsic-phy/devices
> > /devices/platform/soc/30800000.bus/30800000.spba-bus/30880000.serial
> > /devices/platform/soc/30800000.bus/30b30000.usb
> > /devices/platform/soc/30800000.bus/30b30000.usb/ci_hdrc.1
> > $ cat /sys/kernel/debug/pm_genpd/usb-hsic-phy/current_state
> > on
> > $ echo on > /sys/devices/platform/soc/30800000.bus/30800000.spba-bus/
> > 30880000.serial/power/control
> > $ lsusb -t
> > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ci_hdrc/1p, 480M
> > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ci_hdrc/1p, 480M
> >
> > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
> > |
> > |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=, 480M [USB
> >
> > disconnect] $ cat /sys/kernel/debug/pm_genpd/usb-hsic-phy/current_state
> > on
>
> Just want to be sure this was done with hdrc imx runtime PM enabled.
>
> > [USB reconnect]
> > $ lsusb -t
> > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ci_hdrc/1p, 480M
> > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ci_hdrc/1p, 480M
> >
> > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
> > |
> > |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=, 480M
> >
> > Hot plug detecting still works as you can see the USB device number
> > increased.
> >
> > For the records, there is no difference to this patch in removing the
> > power
> > domain from USB HSIC device. I just wanted to keep the diff small.
>
> This is good enough to confirm this, thanks.
>
> I don't have a HW with HSIC enabled for test, and I am not sure the initial
> state of power domain is on, can something like below deserve a try?
>
> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
> index 3cb123016b3e..f5467ef18e33 100644
> --- a/drivers/soc/imx/gpcv2.c
> +++ b/drivers/soc/imx/gpcv2.c
> @@ -416,6 +416,7 @@ static const struct imx_pgc_domain imx7_pgc_domains[] =
> { [IMX7_POWER_DOMAIN_USB_HSIC_PHY] = {
> .genpd = {
> .name = "usb-hsic-phy",
> + .flags = GENPD_FLAG_RPM_ALWAYS_ON,
> },
> .bits = {
> .pxx = IMX7_USB_HSIC_PHY_SW_Pxx_REQ,
> @@ -930,7 +931,7 @@ static int imx_pgc_domain_probe(struct platform_device
> *pdev) regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
> domain->bits.map, domain->bits.map);
>
> - ret = pm_genpd_init(&domain->genpd, NULL, true);
> + ret = pm_genpd_init(&domain->genpd, NULL, !(domain->genpd.flags &
> GENPD_FLAG_RPM_ALWAYS_ON)); if (ret) {
> dev_err(domain->dev, "Failed to init power domain\n");
> goto out_domain_unmap;
This does indeed the trick. But AFAICS the downside is that the powerdomain is
enabled, even if USB is not used. Not sure if this is acceptable though.
Alexander
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-05-04 7:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-02 9:42 [RFC 1/1] usb: chipidea: ci_hdrc_imx: disable runtime pm for HSIC interface Alexander Stein
2022-03-15 1:23 ` Peter Chen
2022-03-29 8:14 ` (EXT) " Alexander Stein
2022-04-09 2:19 ` Peter Chen
2022-04-09 4:49 ` Jun Li
2022-04-11 13:52 ` (EXT) " Alexander Stein
2022-04-12 11:36 ` Jun Li
2022-05-04 7:06 ` Alexander Stein [this message]
2022-05-06 7:09 ` Jun Li
2022-05-06 7:38 ` (EXT) " Alexander Stein
2022-05-09 8:16 ` Jun Li
2022-05-09 9:27 ` Frieder Schrempf
2022-05-09 9:53 ` Jun Li
2022-05-09 10:53 ` (EXT) " Alexander Stein
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=5566202.DvuYhMxLoT@steina-w \
--to=alexander.stein@ew.tq-group.com \
--cc=festevam@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hzpeterchen@gmail.com \
--cc=jun.li@nxp.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@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@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