From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752660AbcEDMCH (ORCPT ); Wed, 4 May 2016 08:02:07 -0400 Received: from mailout1.w1.samsung.com ([210.118.77.11]:36184 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751249AbcEDMCE (ORCPT ); Wed, 4 May 2016 08:02:04 -0400 X-AuditID: cbfec7f4-f796c6d000001486-fa-5729e4b7180d Subject: Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization To: Rob Herring , Mark Brown References: <1461927591-7864-1-git-send-email-k.kozlowski@samsung.com> <1461927591-7864-2-git-send-email-k.kozlowski@samsung.com> <20160429113059.GX3217@sirena.org.uk> <57234BA2.6020304@samsung.com> <20160429164448.GY3217@sirena.org.uk> <57272298.50701@samsung.com> <20160502105501.GE6292@sirena.org.uk> <20160503180022.GA3008@rob-hp-laptop> Cc: Kukjin Kim , Chanwoo Choi , Liam Girdwood , Greg Kroah-Hartman , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-usb@vger.kernel.org, linux.amoon@gmail.com, tjakobi@math.uni-bielefeld.de, m.szyprowski@samsung.com, hverkuil@xs4all.nl, Bartlomiej Zolnierkiewicz , ulf.hansson@linaro.org From: Krzysztof Kozlowski X-Enigmail-Draft-Status: N1110 Message-id: <5729E4B5.2090702@samsung.com> Date: Wed, 04 May 2016 14:01:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-version: 1.0 In-reply-to: <20160503180022.GA3008@rob-hp-laptop> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsVy+t/xq7rbn2iGG5xpELTYOGM9q8XUh0/Y LK5/ec5qMf/IOVaL5sXr2SxOTX7GZPH6haFF/+PXzBbfrnQwWWx6fI3V4vKuOWwWM87vY7JY tKyV2WLdxlvsFmuP3GW3+L9nB7tF2+oPrBbH14Y7CHnsnHWX3WPTqk42jzvX9rB57J+7ht1j 85J6j3/H2D36tqxi9Pi8Sc7j1NfP7AGcUVw2Kak5mWWpRfp2CVwZL5pesxT0ClR83fmWuYHx KU8XIyeHhICJxM/nr5ghbDGJC/fWs3UxcnEICSxllNiy5iE7hPOMUaLr8V9WkCphgXiJGZ3L GUFsEQEniSk3LrNCFN1lkphw7BELiMMs8JtZYt3dX+wgVWwCxhKbly9hg9ghJ9HbPQmoiIOD V0BL4sPuYhCTRUBVYuV6Y5AKUYEIidXrroFdxCsgKPFj8j0WEJtTwEhi7f+n7CDlzAJ6Evcv aoGEmQXkJTavecs8gVFwFpKOWQhVs5BULWBkXsUomlqaXFCclJ5rqFecmFtcmpeul5yfu4kR EolfdjAuPmZ1iFGAg1GJh/eFt2a4EGtiWXFl7iFGCQ5mJRHe6gdAId6UxMqq1KL8+KLSnNTi Q4zSHCxK4rxzd70PERJITyxJzU5NLUgtgskycXBKNTCacdxgYzT/Pz35U0UL454V+17I7f99 Pzw/dNc9mWaOtfkd1+z/7fPbvnTXjnaZ64mbup8oLs68rzFJodvl5updX87ainqem3Nr8Soj pwUpyuLN5RyK1Z7iGid/KL2cPaW14lNd/b4su7Ne1TJ7OnOetN+SyWLWMvzfw3bWXLrp7gmd a0sefNmixFKckWioxVxUnAgAwrprIsACAAA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/03/2016 08:00 PM, Rob Herring wrote: > On Mon, May 02, 2016 at 11:55:01AM +0100, Mark Brown wrote: >> On Mon, May 02, 2016 at 11:49:12AM +0200, Krzysztof Kozlowski wrote: >> >>> This VDD regulator supply actually is not a usb3503 USB HUB regulator >>> supply... but a supply to the LAN attached to this HUB. Regulator off/on >>> is needed for LAN to show up. The hub will show up with typical reset >>> (which is also missing before my patchset btw). >> >>> The LAN, as a USB device, is auto-probed so it cannot take the regulator >>> and play with it. The simplest idea I have is to add it as "external >>> supply" to the parent: usb3503. >> >> This is common enough that that just isn't going to scale well I fear >> without some generic handling, either walking child devices at the bus >> level or at the device level with a pre-probe() callback to get the >> device to power on. The latter is more appropriate to things like >> Slimbus where the device is more likely to do active management at >> runtime, it's not clear people are building USB devices like that. > > There's a new binding and support in -next (.../usb/usb-device.txt) for > USB devices that should help here. Though, how to handle a hub on USB > and I2C buses would need to be worked out. This binding might help, especially with other idea we have - usage of pwrseq for the USB hub. The USB hub, without toggling the regulator off/on, appears as USB device only sometimes. Apparently there is some timing or other behavior. not yet known to me. When playing with regulator, the USB hub and child USB device (LAN) will appear correctly. This looks like pwrseq for MMC devices so the idea is to: 1. Move drivers/mmc/core/pwrseq* to separate directory (drivers/power/pwrseq ?) 2. Add support for pwrseq to USB core, 3. Add new pwrseq driver (or extend existing one): toggling the regulator. 4. Add pwrseq phandle to the DT node of USB hub (to the binding mentioned by Rob?). Does it look sensible? Best regards, Krzysztof From mboxrd@z Thu Jan 1 00:00:00 1970 From: Krzysztof Kozlowski Subject: Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization Date: Wed, 04 May 2016 14:01:57 +0200 Message-ID: <5729E4B5.2090702@samsung.com> References: <1461927591-7864-1-git-send-email-k.kozlowski@samsung.com> <1461927591-7864-2-git-send-email-k.kozlowski@samsung.com> <20160429113059.GX3217@sirena.org.uk> <57234BA2.6020304@samsung.com> <20160429164448.GY3217@sirena.org.uk> <57272298.50701@samsung.com> <20160502105501.GE6292@sirena.org.uk> <20160503180022.GA3008@rob-hp-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: In-reply-to: <20160503180022.GA3008@rob-hp-laptop> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Rob Herring , Mark Brown Cc: Kukjin Kim , Chanwoo Choi , Liam Girdwood , Greg Kroah-Hartman , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux.amoon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, tjakobi-o02PS0xoJP9W0yFyLvAVXMxlOr/tl8fh@public.gmane.org, m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org, hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org, Bartlomiej Zolnierkiewicz , ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org List-Id: devicetree@vger.kernel.org On 05/03/2016 08:00 PM, Rob Herring wrote: > On Mon, May 02, 2016 at 11:55:01AM +0100, Mark Brown wrote: >> On Mon, May 02, 2016 at 11:49:12AM +0200, Krzysztof Kozlowski wrote: >> >>> This VDD regulator supply actually is not a usb3503 USB HUB regulator >>> supply... but a supply to the LAN attached to this HUB. Regulator off/on >>> is needed for LAN to show up. The hub will show up with typical reset >>> (which is also missing before my patchset btw). >> >>> The LAN, as a USB device, is auto-probed so it cannot take the regulator >>> and play with it. The simplest idea I have is to add it as "external >>> supply" to the parent: usb3503. >> >> This is common enough that that just isn't going to scale well I fear >> without some generic handling, either walking child devices at the bus >> level or at the device level with a pre-probe() callback to get the >> device to power on. The latter is more appropriate to things like >> Slimbus where the device is more likely to do active management at >> runtime, it's not clear people are building USB devices like that. > > There's a new binding and support in -next (.../usb/usb-device.txt) for > USB devices that should help here. Though, how to handle a hub on USB > and I2C buses would need to be worked out. This binding might help, especially with other idea we have - usage of pwrseq for the USB hub. The USB hub, without toggling the regulator off/on, appears as USB device only sometimes. Apparently there is some timing or other behavior. not yet known to me. When playing with regulator, the USB hub and child USB device (LAN) will appear correctly. This looks like pwrseq for MMC devices so the idea is to: 1. Move drivers/mmc/core/pwrseq* to separate directory (drivers/power/pwrseq ?) 2. Add support for pwrseq to USB core, 3. Add new pwrseq driver (or extend existing one): toggling the regulator. 4. Add pwrseq phandle to the DT node of USB hub (to the binding mentioned by Rob?). Does it look sensible? Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: k.kozlowski@samsung.com (Krzysztof Kozlowski) Date: Wed, 04 May 2016 14:01:57 +0200 Subject: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization In-Reply-To: <20160503180022.GA3008@rob-hp-laptop> References: <1461927591-7864-1-git-send-email-k.kozlowski@samsung.com> <1461927591-7864-2-git-send-email-k.kozlowski@samsung.com> <20160429113059.GX3217@sirena.org.uk> <57234BA2.6020304@samsung.com> <20160429164448.GY3217@sirena.org.uk> <57272298.50701@samsung.com> <20160502105501.GE6292@sirena.org.uk> <20160503180022.GA3008@rob-hp-laptop> Message-ID: <5729E4B5.2090702@samsung.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 05/03/2016 08:00 PM, Rob Herring wrote: > On Mon, May 02, 2016 at 11:55:01AM +0100, Mark Brown wrote: >> On Mon, May 02, 2016 at 11:49:12AM +0200, Krzysztof Kozlowski wrote: >> >>> This VDD regulator supply actually is not a usb3503 USB HUB regulator >>> supply... but a supply to the LAN attached to this HUB. Regulator off/on >>> is needed for LAN to show up. The hub will show up with typical reset >>> (which is also missing before my patchset btw). >> >>> The LAN, as a USB device, is auto-probed so it cannot take the regulator >>> and play with it. The simplest idea I have is to add it as "external >>> supply" to the parent: usb3503. >> >> This is common enough that that just isn't going to scale well I fear >> without some generic handling, either walking child devices at the bus >> level or at the device level with a pre-probe() callback to get the >> device to power on. The latter is more appropriate to things like >> Slimbus where the device is more likely to do active management at >> runtime, it's not clear people are building USB devices like that. > > There's a new binding and support in -next (.../usb/usb-device.txt) for > USB devices that should help here. Though, how to handle a hub on USB > and I2C buses would need to be worked out. This binding might help, especially with other idea we have - usage of pwrseq for the USB hub. The USB hub, without toggling the regulator off/on, appears as USB device only sometimes. Apparently there is some timing or other behavior. not yet known to me. When playing with regulator, the USB hub and child USB device (LAN) will appear correctly. This looks like pwrseq for MMC devices so the idea is to: 1. Move drivers/mmc/core/pwrseq* to separate directory (drivers/power/pwrseq ?) 2. Add support for pwrseq to USB core, 3. Add new pwrseq driver (or extend existing one): toggling the regulator. 4. Add pwrseq phandle to the DT node of USB hub (to the binding mentioned by Rob?). Does it look sensible? Best regards, Krzysztof