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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 6B380C433F5 for ; Tue, 4 Jan 2022 08:32:18 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 7CFAC8192E; Tue, 4 Jan 2022 09:32:15 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; secure) header.d=walle.cc header.i=@walle.cc header.b="oKzlZqcp"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 44A148142D; Tue, 4 Jan 2022 09:32:08 +0100 (CET) Received: from ssl.serverraum.org (ssl.serverraum.org [IPv6:2a01:4f8:151:8464::1:2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id A4B3982EC6 for ; Tue, 4 Jan 2022 09:32:02 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=michael@walle.cc Received: from mwalle01.kontron.local. (unknown [213.135.10.150]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id 4463C22205; Tue, 4 Jan 2022 09:32:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1641285121; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+Sdxe+iqPN5soJ9n82mOPBL+f/pvXpD+hTmxb34OvzQ=; b=oKzlZqcpUX7/F+M41K5YxWkx1mCF1M6jDadhbsY17tf0A0KrYNw0tt9aPs8YRigfSkheRY xkpbmD961rKi6niALyQAUU47wFzE9innmaqScuThozc1upM34fKHs140QsG0jOKvtzIX1G e/+IYptLUprjCUbkTxiS/md5XP4L27Y= From: Michael Walle To: aford173@gmail.com Cc: festevam@denx.de, marex@denx.de, sjg@chromium.org, u-boot@lists.denx.de, Tim Harvey , Michael Walle Subject: Re: [PATCH V2] usb: ehci-mx6: Enable OTG detection on imx8mm and imx8mn Date: Tue, 4 Jan 2022 09:31:48 +0100 Message-Id: <20220104083148.1328623-1-michael@walle.cc> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20211223140756.304527-1-aford173@gmail.com> References: <20211223140756.304527-1-aford173@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.38 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.103.2 at phobos.denx.de X-Virus-Status: Clean Hi, > The imx8mm and imx8mn appear compatible with imx7d-usb > flags in the OTG driver. If the dr_mode is defined as > host or peripheral, the device appears to operate correctly, > however the auto host/peripheral detection results in an error. > > The solution isn't just adding checks for imx8mm and imx8mn to > the check for imx7, because the USB clock needs to be running > to read from the USBNC_PHY_STATUS_OFFSET register or it will hang. > > The init_type in both priv and plat data are the same, so it doesn't > make sense to configure the data in the plat data and copy the > data to priv when priv can be configured directly. Instead, rename > ehci_usb_of_to_plat to ehci_usb_dr_mode and call it from the > probe functions after the clocks are enabled, but before the data > is required. > > With that added, the additional checks for imx8mm and imx8mn will > allow reading the register to automatically determine the state > (host or device) of the OTG controller. > > Signed-off-by: Adam Ford > --- > V2: Rename ehci_usb_of_to_plat to ehci_usb_dr_mode and call it > from the probe after the clocks are enabled, but before > the data is needed. > > diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c > index 1bd6147c76..f2a34b7f06 100644 > --- a/drivers/usb/host/ehci-mx6.c > +++ b/drivers/usb/host/ehci-mx6.c .. > @@ -639,10 +639,8 @@ static int mx6_parse_dt_addrs(struct udevice *dev) > > static int ehci_usb_probe(struct udevice *dev) > { > - struct usb_plat *plat = dev_get_plat(dev); > struct usb_ehci *ehci = dev_read_addr_ptr(dev); > struct ehci_mx6_priv_data *priv = dev_get_priv(dev); > - enum usb_init_type type = plat->init_type; > struct ehci_hccr *hccr; > struct ehci_hcor *hcor; > int ret; > @@ -660,8 +658,6 @@ static int ehci_usb_probe(struct udevice *dev) > return ret; > > priv->ehci = ehci; > - priv->init_type = type; I'm not sure this is correct. There is also this: https://elixir.bootlin.com/u-boot/v2022.01-rc4/source/drivers/usb/host/usb-uclass.c#L407 Which won't work anymore. usb_setup_ehci_gadget() is called from usb_gadget_register_driver() in ci_udc.c. The latter is the one used on the imx, right? But I might be wrong. I'm still trying to figure out how this all works together, because I also try to get OTG running on the dwc3 driver. It looks like the ci_udc.c is special here, and I wonder how a transition to UCLASS_USB_GADGET_GENERIC might look like for this driver. -michael