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 D2DBCC433F5 for ; Tue, 11 Jan 2022 14:20:54 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 2C39A83082; Tue, 11 Jan 2022 15:20:52 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="OKeA7ZyP"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 5500983039; Tue, 11 Jan 2022 15:20:50 +0100 (CET) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 126A183082 for ; Tue, 11 Jan 2022 15:20:47 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=aford173@gmail.com Received: by mail-ed1-x530.google.com with SMTP id c71so56269087edf.6 for ; Tue, 11 Jan 2022 06:20:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cfeOguArALP/9vzP0N1DQEQz3yck1b7cL2VnxOaVJCY=; b=OKeA7ZyP9AaL70CK1gPg/oyQv7YDaCdImyHguEazV+U/vq8p8+FCr7zu/tvaLOI4Ba GkQPLQ8AsZ8/5oP8e+9hKgUrtGV9I9LuzyJlLo3jqEveh0op7amcx/O3+pLT71vhITO+ ayVNq0XcMm9hIJmwXoWBNyRACoh/c4kR6e8n4c9YRKx+i1MD0lCz2nMmzfmk6iP1fpc/ BkngR66i52DKi8yRcbY5t4MvKBdcXLRTUWXowM+zdZW012yIuR1sTDd7x7TTMdMWZQI0 Xrfl10vAvTMmYPzhUBaDnZpFIgjn+qpnjeYwD9ukW7HsgklPuLuC9fH3/ciMa4DkaCZ5 FdNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cfeOguArALP/9vzP0N1DQEQz3yck1b7cL2VnxOaVJCY=; b=WlOHYXg0TCxrKLZMIKVXKwcTnbd5R5Jvo4nslesjRIjH35Sbw8GAwWjDgTLiJsTOJv rRMhKczDoDz/M1NQOtHlY5SbLbFSCnTgaf4yEp708A8blh+7qFJAdqVbAmnyjiWJ77WS Ippgi2Rhs6x/sRmf1G3XMkxBij7g4BXIsf00pLoSnAXwjfqDKOjs+N/se9YhhaDgFraF DtGLsYu9RptWR+xait/+RNj5tHO64aCS+6QJVE1Cpq+F+cC8mMmc0EU+AQForB21I4cy IZta9JWRGrY8sHiLw4+dQKMHalLEN4/FB7KFWKIb41pib1VN1zjn2hnBMTRjJHFYFArP t0Tw== X-Gm-Message-State: AOAM531OoletZMhxDTt0bJc5NpsKttwWv5VZBpXHrP/K7psEZVerMllO w/nh2ZdmaOlOAiKNf/r+l9bJijwLGs6RjuOEnws= X-Google-Smtp-Source: ABdhPJyTgiY/T8TCel6n3z6eV62ecCL4mVFJ0dVot+APIgpfkYMqPhsMPmB+B6Pz0x1h/xSjYn8imd+bkTw1l/GvHE4= X-Received: by 2002:a05:6402:84e:: with SMTP id b14mr4451072edz.200.1641910846091; Tue, 11 Jan 2022 06:20:46 -0800 (PST) MIME-Version: 1.0 References: <20211223140756.304527-1-aford173@gmail.com> <20220104083148.1328623-1-michael@walle.cc> In-Reply-To: <20220104083148.1328623-1-michael@walle.cc> From: Adam Ford Date: Tue, 11 Jan 2022 08:20:35 -0600 Message-ID: Subject: Re: [PATCH V2] usb: ehci-mx6: Enable OTG detection on imx8mm and imx8mn To: Michael Walle Cc: Fabio Estevam , Marek Vasut , Simon Glass , U-Boot Mailing List , Tim Harvey Content-Type: text/plain; charset="UTF-8" X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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 On Tue, Jan 4, 2022 at 2:32 AM Michael Walle wrote: > > 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; > Michael, > 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 > Further down in the code, you should see: priv->phy_type = usb_get_phy_mode(dev_ofnode(dev)); > > 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. This driver really isn't changing anything, it's just an order of operations. Previously there was a separate that was being called to determine the init_type as being either a peripheral or host. If it wasn't explicitly set in the device tree, the helper function would query a register, however, on the imx8mm and imx8mn platforms, the clocks were not running which resulted in a hang. What I've done is simply move the helper function into the probe and have it run after the clocks start. In theory the register values will be the same as they would be with the help function still in place. Both Tim Harvey and I have tested on an imx8mm and Fabio tested it on an imx7. For me, the peripheral mode worked when the ID pin of the USB-OTG was not grounded. When it was grounded, the system corrected identified it as a host and I was able to mount a USB drive. > > -michael