Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1287751ybt; Tue, 7 Jul 2020 11:55:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxZNuZM2LUTZJKIcEZZyzrQ1B0bejWn3I7JUdK5rC37381pTFyNjTmVz6NQ4dW+fbu4ZrCg X-Received: by 2002:a17:906:2714:: with SMTP id z20mr48661128ejc.469.1594148151160; Tue, 07 Jul 2020 11:55:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594148151; cv=none; d=google.com; s=arc-20160816; b=qeLPW0u2/rGd+CuN4v5qaG8nMjmtyb/scPaYBIcrtk4cW33eLC+kaETsM/2rwetdtz LQkcS/IDC5m4SkOxU0Iv3Qh8soRZzKLGu7qeW4nb7tlrHMdIE0ketmyianX/YXsfrMuv UFN8KbFmqc4rMVVoOyvYqQG43z8EqCQL2vo0Kt9DMRVmsBJMz9SA3d51XeQ+AXoXd0q6 M0mWUuYyCG2kEiSIKhmbaWOAf41VTvkrEVCxyb/3iNKNiK6w2TbFRZqStScMKikXT6dX hqEB938XHSHIMLzC2VHAqsdRNmW+9ipsLx77kfQD7eQoHqURwIT17mwx92RDO3LgQNTN xVyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=RMd8tTCfjNB1oolYgjCGnbvueA8plaMd/4ysVp4hew8=; b=FUFbiepHbi8/xCQGUUAsKF0HGaAEawvP7zqrSaT7JCeFLqThJOIlt8dZDPJZrWhuzW K9EfEx0hX6WYZcAMzasuYcZ8u0nKv9hv3QTIMrejPhk/kfdGk7rmKQg/Ny8H9Cg+2O41 Ovy/pifs5dRZc49guH5zCCrXFwBDnG1LeNOYPsV3LeGKRWAMVjIP6NbTXf4uMapVFNR1 /br9C4dTdSFVlLQOBEt3vIVw5Yr1mHxowrWYXe/WuyL/b5dZ45rghYYcS60HD9rz7CzQ Mus584o54ItcEAg+D8xUHzntups0h3A++9JE64KzkuCjIIPG76MQ9xKMjjlxAVeSTrPR Zl1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@googlemail.com header.s=20161025 header.b=MSqOBX8i; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d21si14072102eje.437.2020.07.07.11.55.27; Tue, 07 Jul 2020 11:55:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@googlemail.com header.s=20161025 header.b=MSqOBX8i; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728677AbgGGSzS (ORCPT + 99 others); Tue, 7 Jul 2020 14:55:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37592 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728029AbgGGSzR (ORCPT ); Tue, 7 Jul 2020 14:55:17 -0400 Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [IPv6:2a00:1450:4864:20::642]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4CD8BC061755; Tue, 7 Jul 2020 11:55:17 -0700 (PDT) Received: by mail-ej1-x642.google.com with SMTP id y10so47719109eje.1; Tue, 07 Jul 2020 11:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RMd8tTCfjNB1oolYgjCGnbvueA8plaMd/4ysVp4hew8=; b=MSqOBX8iZf3N6uIy8Wnm5L4m29/XEr8WCDGWKf500fbPsnl0xzYC6LVlONOf42h0CR I4Rd/idVHgRuoGFtY+arKp+gSn5l1NRpVZPWVHS7fUt71j1qB3v2jBGggVQKiUaXawDQ qNM+I9ABuRJwyg5qaqOAP2v7E/mgtgDyAf07ig2saLp6YrXGZCFFphghvpbv74afVMS8 hgukBbVyPl5VtFibxfDALfdkB8feg3dsrXD3cpQ8FTKR3WiUU7+WwLET7Fw8fB0Y9Ntx fJHk1hgmFv1SXz42n9wzYn1nyBLlwu2BiOkVLXgOydApO9SPolevYiuOnuXVadp33hpE sucw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RMd8tTCfjNB1oolYgjCGnbvueA8plaMd/4ysVp4hew8=; b=EI62LqfxVmuWGRR0riabauCOYQMb4pWuSeGO6Vwy3Sm/tF38c1j1InDDIDN2+uYtRb Bw2u14sPc85z2UnwPVqXcMP762pEF7XFlFRlDKRVmr43PcD5PHgtlas6Y9NY279IoKW8 7CLVIkWIC+D0EOnUXhmYpR/yYk8oL68LecFc7BVlIelTbzuY0S0IulqE6+ow+7FhzXRz QnUD6FaaesDykqb84NymO7yoJDnvREnXIzp2GWoMtrfA986EyXqRZ8k4o/NcaC46Dmux haieheaV1l4GWN0m2TKarMJfHzEyKg5R7rhJw6CGsWSo3SWFNyM4SVdM+OEkZbyLGEJa 083A== X-Gm-Message-State: AOAM532e/2irmO3SuowHNQiiybJuDkAjP0mmHGxNzzZue2q4SzFcudtR rXr38tnsOduxVbKxFnVW+siAJuTZtjNgg4jdgtE= X-Received: by 2002:a17:906:2287:: with SMTP id p7mr49705831eja.537.1594148115920; Tue, 07 Jul 2020 11:55:15 -0700 (PDT) MIME-Version: 1.0 References: <20200616140717.28465-2-amelie.delaunay@st.com> <20200704174219.612060-1-martin.blumenstingl@googlemail.com> <05a81997-5ddb-ea81-7a89-8078b8a2b610@st.com> In-Reply-To: <05a81997-5ddb-ea81-7a89-8078b8a2b610@st.com> From: Martin Blumenstingl Date: Tue, 7 Jul 2020 20:55:05 +0200 Message-ID: Subject: Re: [PATCH 1/3] usb: dwc2: override PHY input signals with usb role switch support To: Amelie DELAUNAY Cc: Alexandre TORGUE , "balbi@kernel.org" , "devicetree@vger.kernel.org" , Fabrice GASNIER , "gregkh@linuxfoundation.org" , "hminas@synopsys.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-stm32@st-md-mailman.stormreply.com" , "linux-usb@vger.kernel.org" , "mcoquelin.stm32@gmail.com" , "robh+dt@kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Amelie, On Tue, Jul 7, 2020 at 6:13 PM Amelie DELAUNAY wrote: > > Hi Martin, > > On 7/4/20 7:42 PM, Martin Blumenstingl wrote: > > Hello Amelie, > > > > thank you for this patch - I am hoping that it will help us on Amlogic > > Meson8, Meson8b, Meson8m2 and GXBB SoCs as well. > > On these SoCs the ID detection is performed by the PHY IP and needs to > > be polled. > > I think usb_role_switch is the perfect framework for this on dwc2 side. > > For the PHY driver I'm going to implement the cable state using the > > extcon framework and then having a new usb-conn-extcon driver. This is > > just to give you an overview why I'm interested in this. > > > > I'm wondering, why use extcon framework and not the usb role switch API > ? This patch on dwc2 is tested on STM32MP157C-DK2 board with STUSB160x > Type-C controller driver recently pushed with usb role switch. You can > have a look here https://lore.kernel.org/patchwork/patch/1256238/. one of the boards that I'm working on is for example the Odroid-C1. It has a Micro-USB port and there's no Type-C controller present. in the next few days I'll try to send my idea as RFC, but this is the .dts I've come up with so far: &usb0 { dr_mode = "otg"; usb-role-switch; connector { compatible = "extcon-usb-b-connector", "usb-b-connector"; type = "micro"; extcon = <&usb0_phy>; vbus-supply = <&usb_vbus>; }; }; I did this for two reasons: 1. I think the PHY is not a connector and thus it's driver shouldn't implement any connector specific logic (managing VBUS) 2. without the connector there would be a circular dependency: the USB controller needs the PHY to initialize but the PHY would need the USB controller so it can manage the role switch (or in other words: the connector replaces the Type-C controller in this case) > > [...] > >> +static int dwc2_drd_role_sw_set(struct usb_role_switch *sw, enum usb_role role) > >> +{ > >> + struct dwc2_hsotg *hsotg = usb_role_switch_get_drvdata(sw); > >> + unsigned long flags; > >> + > >> + /* Skip session not in line with dr_mode */ > >> + if ((role == USB_ROLE_DEVICE && hsotg->dr_mode == USB_DR_MODE_HOST) || > >> + (role == USB_ROLE_HOST && hsotg->dr_mode == USB_DR_MODE_PERIPHERAL)) > >> + return -EINVAL; > >> + > >> + /* Skip session if core is in test mode */ > >> + if (role == USB_ROLE_NONE && hsotg->test_mode) { > >> + dev_dbg(hsotg->dev, "Core is in test mode\n"); > >> + return -EBUSY; > >> + } > >> + > >> + spin_lock_irqsave(&hsotg->lock, flags); > > due to this spin_lock_irqsave() ... > > > >> + if (role == USB_ROLE_HOST) { > >> + if (dwc2_ovr_avalid(hsotg, true)) > >> + goto unlock; > >> + > >> + if (hsotg->dr_mode == USB_DR_MODE_OTG) > >> + /* > >> + * This will raise a Connector ID Status Change > >> + * Interrupt - connID A > >> + */ > >> + dwc2_force_mode(hsotg, true); > > ... we cannot sleep in here. the call flow is: > > dwc2_drd_role_sw_set > > spin_lock_irqsave > > dwc2_force_mode > > dwc2_wait_for_mode > > usleep_range > > > > In fact, with the avalid or bvalid overriding + the debounce filter > bypass, GINTSTS_CURMOD is already in the expected mode, so that we exit > the loop directly, without running into usleep_range. on my Amlogic SoC this is not the case: The kernel complains because of that usleep_range from within the spinlock context Please let me know if/how I can help debug this. [...] > > +int dwc2_drd_init(struct dwc2_hsotg *hsotg) > > +{ > > + struct usb_role_switch_desc role_sw_desc = {0}; > > + struct usb_role_switch *role_sw; > > + int ret; > > + > > + if (!device_property_read_bool(hsotg->dev, "usb-role-switch")) > > + return 0; > > should we also return early here if dr_mode != "otg"? > > > > No, because when VBUS is not connected to the controller, you also need > to get the usb_role_none from the usb-role-switch to catch the > unattached state (also in Peripheral or Host only mode). I see - thank you for the explanation! Best regards, Martin