From patchwork Wed Mar 2 09:42:39 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Stein X-Patchwork-Id: 12765698 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 64FAEC433F5 for ; Wed, 2 Mar 2022 09:44:17 +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: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:In-Reply-To:References: List-Owner; bh=CzCtrj7PWgoo5QPYhAE4dH+A3/oVMX2mTLyNcs2s35c=; b=pWo3cQIITHkgqk MI9OnfqZz2NYaJZnBV5lFQbOY3iLdba9DjPxZa36MmOjTKBkwBZHaS3TsD66tsuXC4Tm00ORB2lNu 0ginsJ8FINSRY2GKiXETvcai33WQynQI3dnWCncUvkxT67Wn8fBlgudBGp54b/pOh23dtvxp+Kc9w /pMChgq6wtN+XTlD3SnIhmzzcUUiZA/1VZG6k/K6n/G6+f4VCy6Jd1sqzjs+ZJZEVHkKX9PxGFABJ XhJ4UbdOJ6ghySkuuPyZLHjw7FVyaJaW0LF01rf9GluutwjQ9W9Rk22GBtcp7Sx4+RPa2V0H0wvag kWv7m/5PXJMXVOjEDo3w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nPLVc-0025Xq-GC; Wed, 02 Mar 2022 09:43:00 +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 1nPLVZ-0025WL-D3 for linux-arm-kernel@lists.infradead.org; Wed, 02 Mar 2022 09:42:59 +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=1646214177; x=1677750177; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=65Ie3MJD5XZ2TfeYPPzg97lgs7XwJKgLkZgbIlbFNeQ=; b=MI2d2Jz5IzZbXvXFwxpl1QrFT3xeyxv3k+z3+bp5HqknnnixiOOHknW1 eZcTxNTdHOKyjSELKk9QKkHRNV7gV/sa1Tk4URQZCu07+fJz2qTrga5PY a4U5JjUwGqg1yaekyh+seZkBzpnycehk9FwEvgn63lflZvy16J7MqD4Gm AfShnGnDnBd20XIOh+cZAGOejXde1mBzC6+jhrKAzDe7IORTP58fZia3n 05mbEseh69Qfj561lcbB2YwkWXUurCvHMrCqKp+XvS11xSkvgOQlXqGRx B8OsnEAKcVxVhjCP9SE3sEw7De7K5MJlxAjgczkv+e8llJwq8veAYyNDZ g==; X-IronPort-AV: E=Sophos;i="5.90,148,1643670000"; d="scan'208";a="22401814" Received: from unknown (HELO tq-pgp-pr1.tq-net.de) ([192.168.6.15]) by mx1-pgp.tq-group.com with ESMTP; 02 Mar 2022 10:42:51 +0100 Received: from mx1.tq-group.com ([192.168.6.7]) by tq-pgp-pr1.tq-net.de (PGP Universal service); Wed, 02 Mar 2022 10:42:51 +0100 X-PGP-Universal: processed; by tq-pgp-pr1.tq-net.de on Wed, 02 Mar 2022 10:42:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1646214171; x=1677750171; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=65Ie3MJD5XZ2TfeYPPzg97lgs7XwJKgLkZgbIlbFNeQ=; b=Qv6NEsk9CspOSCE7zeJx13x6/fkawT6tad6L/lKz9hdUvraykuqA0q1O 2QENynztrpYAQLfBjL53h2cx5IGYyhAFiDGUHWVxBSqD7MVrinMrbVTI6 nHrlaZW5/1ZxZqg2sxltjIqWO8vobOICHMbWrITl0EQZUH+KqmnOubi0b PhxB3alMjkZ2bDj394ly3zLROEvXn5R+01HUYtuIZy8187+gDXP1j63AT oIh4bSO9B6K7I3hPIgE1H3zy1Ug8qB0yd+/eh+l/xXB+GQFnr3DHboIxB dYIRookJEUDe4ZGmDG1v7h4JtWb/xG+HWJDOQYGnttdfDRGX5ExElZ4SH A==; X-IronPort-AV: E=Sophos;i="5.90,148,1643670000"; d="scan'208";a="22401812" Received: from vtuxmail01.tq-net.de ([10.115.0.20]) by mx1.tq-group.com with ESMTP; 02 Mar 2022 10:42:51 +0100 Received: from steina-w.tq-net.de (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 BC4DB280074; Wed, 2 Mar 2022 10:42:50 +0100 (CET) From: Alexander Stein To: Peter Chen , Greg Kroah-Hartman , Shawn Guo , Sascha Hauer , Fabio Estevam Cc: Alexander Stein , Pengutronix Kernel Team , NXP Linux Team , linux-usb@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [RFC 1/1] usb: chipidea: ci_hdrc_imx: disable runtime pm for HSIC interface Date: Wed, 2 Mar 2022 10:42:39 +0100 Message-Id: <20220302094239.3075014-1-alexander.stein@ew.tq-group.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220302_014257_838811_92AEB112 X-CRM114-Status: GOOD ( 17.80 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 working fine. But once the last non-HUB device is disconnected the ci_hdrc device goes into runtime suspend. This will eventually also disable the 'pgc_hsic_phy' power domain. Results is that no more updates from USB hub is handled, neither HUB on HSIC link or HUB on that's downstream link. USB tree looks like this: /: 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 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 1: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M |__ Port 2: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M I noticed once the power domain is disabled, no IRQs appear if I attach a new mass storage, essentially preventing any runtime resume. I do not know if this is specific to i.MX7 only or if this is a general USB HSIC problem, so this diff might be too much. BTW: An udev rule with the same effect is: ACTION=="add", SUBSYSTEMS=="platform", DRIVER=="ci_hdrc", KERNELS=="30b30000.usb", TEST=="power/control", ATTR{power/control}="on" But I would like to get this fixed on driver level. Regards Alexander drivers/usb/chipidea/ci_hdrc_imx.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c index 097142ffb184..e5c22b70431c 100644 --- a/drivers/usb/chipidea/ci_hdrc_imx.c +++ b/drivers/usb/chipidea/ci_hdrc_imx.c @@ -344,6 +344,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev) if ((of_usb_get_phy_mode(dev->of_node) == USBPHY_INTERFACE_MODE_HSIC) && data->usbmisc_data) { pdata.flags |= CI_HDRC_IMX_IS_HSIC; + /* Runtime suspend is not supported for HSIC interface */ + pdata.flags &= ~CI_HDRC_SUPPORTS_RUNTIME_PM; data->usbmisc_data->hsic = 1; data->pinctrl = devm_pinctrl_get(dev); if (PTR_ERR(data->pinctrl) == -ENODEV)