Am Freitag, den 20.11.2015, 16:05 +0800 schrieb Peter Chen: > On Thu, Nov 19, 2015 at 11:26:50AM -0500, Alan Stern wrote: > > On Thu, 19 Nov 2015, Philipp Zabel wrote: > > > > > On Wed, Oct 21, 2015 at 10:39:00AM +0800, Peter Chen wrote: > > > > On Tue, Oct 20, 2015 at 02:09:38PM -0200, Fabio Estevam wrote: > > > > > Hi Peter, > > > > > > > > > > On Mon, Oct 19, 2015 at 12:50 AM, Peter Chen > > > > > <peter.c...@freescale.com> wrote: > > > > > > > > > > > Add linux-usb. > > > > > > > > > > > > Patryk, your problem is you may need to open 24M OSC for HUB 2514 > > > > > > manually, and you have used IMX6QDL_CLK_CKO for it in the design, > > > > > > but this clock is not controller's clock, controller's clock has > > > > > > already decided at SoC dts file (imx6qdl.dtsi), you don't need to > > > > > > override it at board's dts file. > > > > > > > > > > > > You can try delete clock property at imx6qdl-udoo.dtsi, if it still > > > > > > can't work, try to open IMX6QDL_CLK_CKO at one place to test. > > > > > > > > > > What is the appropriate place to acquire and enable the USB hub clock? > > > > > > > > > > This issue has appeared several times and it seems we don't have a > > > > > solution for this yet. > > > > > > > > > > Any suggestions? > > > > > > > > Add Alan. > > > > > > > > Hi Alan, we have several designs that the on-board HUB need to > > > > be reset by gpio pin and its clock is also from the board or > > > > the SoC. Any suggestions how to add these platform information > > > > for HUB device? > > > > > > How about putting it in the device tree? > > > http://www.firmware.org/1275/bindings/usb/usb-1_0.ps > > > clocks and reset-gpios properties could be added to the USB hub node. > > > > Something like this is necessary. Instead of making the hub driver > > take care of the reset gpio and the clock, I suggest you make the host > > controller's platform driver do these things. > > > > This is because USB hubs are generic devices, not specific to any > > platform and (usually) hot-pluggable. Associating platform-specific > > data with a hub is out of the ordinary, and it deserves to be handled > > by platform-specific code -- there is no such code in the hub driver. > > > If this on-board HUB is special, its reset pin needs to be toggled > after power on, no matter for Intel or ARM platforms, how we handle > it? It is not feasible we add this for all platform drivers.
Further whether the GPIO reset line is initially in asserted state and just needs to change to deasserted, or whether the GPIO reset line is initially in deasserted state and needs to be pulsed for a certain time is probably hub IC specific. regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
