From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2EBC9C433EF for ; Mon, 11 Apr 2022 13:53:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=80DE1X/KdzUDdw3Lz6RS3c2xvN21rMof/EmhU1tZdS0=; b=i75ucRAP43D/Qd rwZ1I4xq98h8mTkRcuP+KigKaQ0itWH6bDaufGuommGwZv9DVo47AN3A3puCrC0xTQCcIDbN4UqNk Phqh3CqlHaO2lPxPbFePvZE7mi8X9YlzTBcwnPU5BZoNf0tj2e1TMHsFshxbWNhn32SEYsWy8gYnZ hQBs1NO5VzrtmIRpbGE0GjGC9zknDMDwBPVI9RstYqDA3zDmttxugVR3Lntc8HaJDGzksngMTP3hs Sf+SHLEx/xO1YMbzn2xbIX3UoRfLwAHhMoPZLgUVKaPKC7afCiqwHoxuIk4aptOd1/PsDXYAOP1vB CL8nysusmBUMfI8VMk7A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nduT6-009Dwm-Su; Mon, 11 Apr 2022 13:52:37 +0000 Received: from mx1.tq-group.com ([93.104.207.81]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nduT3-009DvA-6s for linux-arm-kernel@lists.infradead.org; Mon, 11 Apr 2022 13:52:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1649685153; x=1681221153; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=uVCp9lbl3DacKwiMLAKk56VKwcGscxXB3PdLEPb/B6g=; b=iWbxjUetBPg2S6FDv+nf9LH7UsrGQh3OYt02dNrwgxGZMaZlSsLSNr0S yC1E/3/gqN9N2++Xtd/7ySS+oZQs9JOqglVWM8FxxKGyRjTnbC9AV2qmA p55xzoItG5ySUetw2f66Zr/laNjjjVNSPSXMLwlZiXLmEvB8ODO7pfWhd 8vcIHO60TVVTKCsogzRb28XZJw7sngcx9APVtBVJQHbratpbSxbG4z6nm aW7daphbR6plFNR98KGvb6neyxgg5/c/KJocPh01GotWfYsKYFkudeUjl ch3l6d5F1HE2zYJzBPqRRuoA9nf1w+e57NNDIVOju5uG9utfhIComhsEE A==; X-IronPort-AV: E=Sophos;i="5.90,252,1643670000"; d="scan'208";a="23225291" Received: from unknown (HELO tq-pgp-pr1.tq-net.de) ([192.168.6.15]) by mx1-pgp.tq-group.com with ESMTP; 11 Apr 2022 15:52:28 +0200 Received: from mx1.tq-group.com ([192.168.6.7]) by tq-pgp-pr1.tq-net.de (PGP Universal service); Mon, 11 Apr 2022 15:52:28 +0200 X-PGP-Universal: processed; by tq-pgp-pr1.tq-net.de on Mon, 11 Apr 2022 15:52:28 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1649685148; x=1681221148; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=uVCp9lbl3DacKwiMLAKk56VKwcGscxXB3PdLEPb/B6g=; b=kuSKUmDZbUY3EYO+XPezpWqNRNIygz1gNqR6zMjCYdHnAz3aqiabQHlh 1L/qG9vSN2Pmpe4QCKCtu5i8cejmvIdngn/zGkEeDUevuTy5hkF/IXH68 eG/5qPGdX8V8P0PUSWXJFQS50xlfX+3jYzTvb4TdQpWRa0YOysPCp6zbv f1yJ8/SDp5A1Yv35Iq3BUYyaUr0S7Zrs3yDQ7ZLQfh4JQDUoTCV73eLku tlXcnBV9U2/DNrvYnFvZ4iNgtGXkhPIvA2bpZz9qwqwgIHcP3okCzTXTk 5PGDhSQuCeyq2funxYLY7UGs4xYtjLieW/hx5sP9eDjF6ofCrfpC6ehLH Q==; X-IronPort-AV: E=Sophos;i="5.90,252,1643670000"; d="scan'208";a="23225290" Received: from vtuxmail01.tq-net.de ([10.115.0.20]) by mx1.tq-group.com with ESMTP; 11 Apr 2022 15:52:28 +0200 Received: from steina-w.localnet (unknown [10.123.49.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by vtuxmail01.tq-net.de (Postfix) with ESMTPSA id 59A55280070; Mon, 11 Apr 2022 15:52:28 +0200 (CEST) From: Alexander Stein To: Peter Chen , Jun Li Cc: Peter Chen , Greg Kroah-Hartman , Shawn Guo , Sascha Hauer , Fabio Estevam , Pengutronix Kernel Team , dl-linux-imx , USB list , "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: Mon, 11 Apr 2022 15:52:27 +0200 Message-ID: <1911252.usQuhbGJ8B@steina-w> Organization: TQ-Systems GmbH In-Reply-To: References: <20220302094239.3075014-1-alexander.stein@ew.tq-group.com> <20220409021948.GA3618@Peter> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220411_065233_687030_FF8612A6 X-CRM114-Status: GOOD ( 39.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, Am Samstag, 9. April 2022, 06:49:54 CEST schrieb Jun Li: > > -----Original Message----- > > From: Peter Chen > > Sent: Saturday, April 9, 2022 10:20 AM > > To: Alexander Stein > > Cc: Peter Chen ; Greg Kroah-Hartman > > ; Shawn Guo ; Sascha > > Hauer ; Fabio Estevam ; > > Pengutronix Kernel Team ; dl-linux-imx > > ; USB list ; > > 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=E4rz 2022, 02:23:23 CEST schrieb Peter Chen: > > > > On Wed, Mar 2, 2022 at 5:42 PM Alexander Stein > > > > = > > > > 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 > > > > > --- > > > > > 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 worki= ng > > = > > fine. > > = > > > > > But once the last non-HUB device is disconnected the ci_hdrc devi= ce > > = > > 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=3Droot_hub, Driver=3Dci_hdrc/1p, 480M > > > /: Bus 01.Port 1: Dev 1, Class=3Droot_hub, Driver=3Dci_hdrc/1p, 480M > > > = > > > |__ Port 1: Dev 2, If 0, Class=3DHub, Driver=3Dhub/4p, 480M > > > | > > > |__ Port 2: Dev 3, If 0, Class=3DMass Storage, Driver=3Dusb-s= torage, > > = > > 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 =3D <&pgc_hsic_phy>; > status =3D "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 pa= tch --->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 =3D <&clks IMX7D_UART3_ROOT_SRC>; assigned-clock-parents =3D <&clks IMX7D_OSC_24M_CLK>; status =3D "okay"; + power-domains =3D <&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=3Droot_hub, Driver=3Dci_hdrc/1p, 480M /: Bus 01.Port 1: Dev 1, Class=3Droot_hub, Driver=3Dci_hdrc/1p, 480M |__ Port 1: Dev 2, If 0, Class=3DHub, Driver=3Dhub/4p, 480M |__ Port 2: Dev 3, If 0, Class=3DMass Storage, Driver=3D, 480M [USB disconnect] $ cat /sys/kernel/debug/pm_genpd/usb-hsic-phy/current_state on [USB reconnect] $ lsusb -t /: Bus 02.Port 1: Dev 1, Class=3Droot_hub, Driver=3Dci_hdrc/1p, 480M /: Bus 01.Port 1: Dev 1, Class=3Droot_hub, Driver=3Dci_hdrc/1p, 480M |__ Port 1: Dev 2, If 0, Class=3DHub, Driver=3Dhub/4p, 480M |__ Port 2: Dev 4, If 0, Class=3DMass Storage, Driver=3D, 480M Hot plug detecting still works as you can see the USB device number increas= ed. 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. Best regards, Alexander _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel