From patchwork Tue Dec 22 03:32:20 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Chen X-Patchwork-Id: 7901771 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id B5FA2BEEE5 for ; Tue, 22 Dec 2015 03:34:55 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id B3EC420531 for ; Tue, 22 Dec 2015 03:34:54 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B063C20524 for ; Tue, 22 Dec 2015 03:34:53 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1aBDhD-0006qP-1T; Tue, 22 Dec 2015 03:33:07 +0000 Received: from mail-lb0-x233.google.com ([2a00:1450:4010:c04::233]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1aBDh9-0006po-BD for linux-arm-kernel@lists.infradead.org; Tue, 22 Dec 2015 03:33:04 +0000 Received: by mail-lb0-x233.google.com with SMTP id oh2so24418078lbb.3 for ; Mon, 21 Dec 2015 19:32:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=prquJWuiozNdAu+TsUgeEGMFjrDGmrM7IAU0cTV736g=; b=U1M5pWSBtfzwMhaycK2n7rFpnsqyKuyDoscJiLwH9C5XDj8+M+w4FjPmKwZXOIrcol wfm0Y/cvbOdvRg7kjV6HdG4eFDSF/DD59waRGeAHsCoSXn3WbLgsDDte1N/tlvBUWWOt eI9+dHeC/5yYLIzor6JxMrrocIzQDgY4h5XEJ/ARIA4EKO2hV7SSCrre8vX3MmEOE/2k X7qNeNTWWaH6lwE3PfT7zIua/9thp4YYNpqrRbXvAhqftDpRSZuxmPrD7JvcK01DPnyG wWJPMfwUu4ht4nGqzpo+4v0UGOlwA8VJbw3VdcPge1xz8BzgE80KxnrLQOCLhBiut8ER JX7w== X-Received: by 10.112.188.231 with SMTP id gd7mr7482912lbc.6.1450755160494; Mon, 21 Dec 2015 19:32:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.181.65 with HTTP; Mon, 21 Dec 2015 19:32:20 -0800 (PST) In-Reply-To: References: From: Peter Chen Date: Tue, 22 Dec 2015 11:32:20 +0800 Message-ID: Subject: Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver To: Alan Stern X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20151221_193303_609168_738CB8ED X-CRM114-Status: GOOD ( 20.44 ) X-Spam-Score: -2.7 (--) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , "devicetree@vger.kernel.org" , Pawel Moll , Arnd Bergmann , Greg Kroah-Hartman , Mathieu Poirier , Linux USB List , patryk@kowalczyk.ws, Felipe Balbi , Rob Herring , Peter Chen , "kernel@pengutronix.de" , Philipp Zabel , Fabio Estevam , Shawn Guo , "linux-arm-kernel@lists.infradead.org" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, Dec 22, 2015 at 3:40 AM, Alan Stern wrote: > On Mon, 21 Dec 2015, Peter Chen wrote: > >> There are two problems which needs device tree to support, I have >> below solutions for them, please help to see if it is reasonable. >> >> 1. The USB device can't work without external clock, power, reset operation. >> At device tree, we have a node to describe external signals like clocks, gpios >> for all onboard devices under this controller. And this node is as phandle for >> host controller, see below: >> >> --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi >> +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi >> @@ -108,6 +108,21 @@ >> default-brightness-level = <7>; >> status = "okay"; >> }; >> + >> + usbh1_pre_operation: usbh1_pre_operation { >> + clocks = <&clks IMX6QDL_CLK_1>, >> + <&clks IMX6QDL_CLK_2>, >> + <&clks IMX6QDL_CLK_3>, >> + <&clks IMX6QDL_CLK_4>, >> + <&clks IMX6QDL_CLK_5>, >> + <&clks IMX6QDL_CLK_6>; >> + reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>, >> + <&gpio4 7 GPIO_ACTIVE_LOW>, >> + <&gpio3 25 GPIO_ACTIVE_LOW>, >> + <&gpio3 27 GPIO_ACTIVE_LOW>, >> + <&gpio4 4 GPIO_ACTIVE_LOW>, >> + <&gpio4 6 GPIO_ACTIVE_LOW>; >> + }; >> }; >> >> &clks { >> @@ -590,6 +605,8 @@ >> &usbh1 { >> vbus-supply = <®_usb_h1_vbus>; >> status = "okay"; >> + >> + devices-pre-operation = <&usbh1_pre_operation> >> }; >> >> At code, we add one API of_usb_pre_operation to get clocks and gpios through >> host controller's device node, and this API is called at usb_add_hcd, >> and opposite >> operation is called at usb_remove_hcd. >> >> This solution is almost the same with MMC power sequence solution. >> (see drivers/mmc/core/pwrseq.c) > > That seems reasonable to me. > >> 2. There are MFD USB devices, which includes several interfaces under >> USB device, >> like i2c, gpios, etc. Due to lack of device tree support, USB >> class/device driver doesn't know >> which kinds of interfaces are needed for this board. >> >> This problem is hard to handle, I have a solution, but it can't cover >> two same devices >> under the same HUB ports. My solution is let USB know device node, the main idea >> is similar with PCIi's (see drivers/of/of_pci.c, drivers/pci/of.c), >> the most difficulty is >> find correct node for USB device after bus enumeration. Once the >> device is recognized, >> the USB core will create a USB device for it, since we know its parent >> device, and its parent >> device (eg, the host controller) has device node, and we can find all >> children nodes under >> this node, if the child's {vid, pid} is the same with {vid, pid} the >> device descriptor we read, we >> assign this node as usb device's node. > > I don't really understand this. However, you can always specify a USB > device by giving its port number on the parent hub, and the hub's port > number on _its_ parent hub, and so on back to the root hub and host > controller. That works even if you're not using DT or OF or ACPI. > Thanks, so the HUB's physical port number is the same with its logical port number which reported at its descriptor? If we assumed all HUBs follow it, then we can use port number to align the devices which we described at DT and detected by USB bus. If the host controller has DT supported, and there are two ports connects two different onboard devices. When the device is found by the bus, we will know its portnum and parent (see usb_alloc_dev), and we know parent's device node, so we will know two children node by iterate its parent, and match its port number (property "reg" at below dts node) with udev->portnum we assigned at usb_alloc_dev. Then we can let the device know DT. After USB device knows DT, it can handle DT properties at its driver. &usbh1 { vbus-supply = <®_usb_h1_vbus>; status = "okay"; devices-pre-operation = <&usbh1_pre_operation> #address-cells = <1>; #size-cells = <0>; usb: usb_mfd2415@01 { compatible = "usb multi-device"; reg = <0x01>; clocks = <&clks IMX6QDL_CLK_CKO>; reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>; reset-duration-us = <3000>; gpio-controller; #gpio-cells = <2>; }; usb: usb_mfd2415@02 { compatible = "usb multi-device"; reg = <0x02>; clocks = <&clks IMX6QDL_CLK_CKO2>; reset-gpios = <&gpio7 13 GPIO_ACTIVE_LOW>; reset-duration-us = <3000>; gpio-controller; #gpio-cells = <2>; }; }; --- a/drivers/usb/core/usb.c +++ b/drivers/usb/core/usb.c @@ -494,6 +494,8 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent, dev->portnum = port1; dev->bus = bus; dev->parent = parent; + if (parent->of_node) + dev->dev->of_node = find_node_by_bus(parent->of_node, dev->portnum); INIT_LIST_HEAD(&dev->filelist);