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 X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2D9A6C47088 for ; Wed, 26 May 2021 17:32:24 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 567CD613C7 for ; Wed, 26 May 2021 17:32:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 567CD613C7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 242BF82C97; Wed, 26 May 2021 19:32:20 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id ED14282D1B; Wed, 26 May 2021 19:32:18 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id 156AC82AF4 for ; Wed, 26 May 2021 19:32:16 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=andre.przywara@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4041F13A1; Wed, 26 May 2021 10:32:14 -0700 (PDT) Received: from slackpad.fritz.box (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 12DAA3F73B; Wed, 26 May 2021 10:32:12 -0700 (PDT) Date: Wed, 26 May 2021 18:31:55 +0100 From: Andre Przywara To: Jagan Teki Cc: U-Boot-Denx , Paul Kocialkowski , Jernej Skrabec , Samuel Holland , Icenowy Zheng , linux-sunxi@lists.linux.dev Subject: Re: [PATCH] phy: sun4i-usb: Fix PHY0 routing and passby configuration for MUSB Message-ID: <20210526183155.26eb331a@slackpad.fritz.box> In-Reply-To: References: <20210526005718.23767-1-andre.przywara@arm.com> Organization: Arm Ltd. X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.31; x86_64-slackware-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.102.4 at phobos.denx.de X-Virus-Status: Clean On Wed, 26 May 2021 22:37:14 +0530 Jagan Teki wrote: Hi Jagan, thanks for having a look! > On Wed, May 26, 2021 at 6:27 AM Andre Przywara wrote: > > > > From: Paul Kocialkowski > > > > Recent Allwinner platforms (starting with the H3) only use the MUSB > > controller for peripheral mode and use HCI for host mode. As a result, > > extra steps need to be taken to properly route USB signals to one or > > the other. More precisely, the following is required: > > * Routing the pins to either HCI/MUSB (controlled by PHY); > > * Enabling USB PHY passby in HCI mode (controlled by PMU). > > > > The current code will enable passby for each PHY and reroute PHY0 to > > MUSB, which is inconsistent and results in broken USB host support > > for port 0. > > > > Passby on PHY0 must only be enabled when we want to use HCI. Since > > host/device mode detection is not available from the PHY code and > > because U-Boot does not support changing the mode dynamically anyway, > > we can just mux the controller to MUSB if it is enabled and mux it to > > HCI otherwise. > > > > This fixes USB host support for port 0 on platforms with PHY0 dual-route, > > especially on boards like Pine64 (with only USB-A host ports) and > > TV boxes without OTG ports. > > > > Signed-off-by: Paul Kocialkowski > > [Andre: tweak commit message, use IS_ENABLED()] > > Signed-off-by: Andre Przywara > > --- > > Hi, > > > > for H6 boards to work this requires a DT update (to get the <&usbphy 0> > > links between HCI and PHY), which I will send later. > > Tested on Pine H64, Pine64-LTS, OrangePi Zero, OrangePi PC 2, BananaPi M64, > > BananaPi M1. > > > > Cheers, > > Andre > > > > drivers/phy/allwinner/phy-sun4i-usb.c | 16 ++++++++++++++-- > > 1 file changed, 14 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c b/drivers/phy/allwinner/phy-sun4i-usb.c > > index 5723c980323..e6ceafc7648 100644 > > --- a/drivers/phy/allwinner/phy-sun4i-usb.c > > +++ b/drivers/phy/allwinner/phy-sun4i-usb.c > > @@ -313,9 +313,21 @@ static int sun4i_usb_phy_init(struct phy *phy) > > data->cfg->disc_thresh, PHY_DISCON_TH_LEN); > > } > > > > - sun4i_usb_phy_passby(phy, true); > > + if (IS_ENABLED(CONFIG_USB_MUSB_SUNXI)) { > > I believe i did comment this before to use driver_data flag as this is > full dm driver instead of macro style. Which driver_data field would that be? This is not about a particular SoC's PHY, this is about whether we use peripheral or host mode for controller 0. As Paul mentioned in the commit message above: "... Since host/device mode detection is not available from the PHY code and because U-Boot does not support changing the mode dynamically anyway, ...." So a possible alternative would be to look up the dr_mode property in the DT node. BUT: this property lives in the musb DT node, not in this node the PHY driver knows about. Happy to take a patch that makes the connection and looks that up. But I am not sure that covers all cases. Meanwhile a equivalent and MUCH simpler solution is to use the Kconfig symbol for the MUSB driver: as Paul correctly mentioned, this is a static decision: only one of them can be effectively active in a build, and inclusion of the MUSB driver wins over the host controller. So using this symbol as a switch seems to be the best solution to me. Cheers, Andre