> On 17 Nov 2017, at 14:19, Bin Meng <bmeng...@gmail.com> wrote: > > Hi Philipp, > > On Fri, Nov 17, 2017 at 5:43 PM, Dr. Philipp Tomsich > <philipp.toms...@theobroma-systems.com> wrote: >> Bin, >> >> On 17 Nov 2017, at 10:27, Bin Meng <bmeng...@gmail.com> wrote: >> >> Hi Philipp, >> >> On Tue, Nov 7, 2017 at 6:04 AM, Philipp Tomsich >> <philipp.toms...@theobroma-systems.com> wrote: >> >> When the FEAT_POWER flag is set/cleared for a port, power to this port >> should be enabled/disabled. As many embedded xHCI controllers do not >> expose a signal to control this, extra effort may be required. >> >> In order to link up setting/clearing FEAT_POWER with the regulator >> framework (so either a regulator or a GPIO modelled as a fixed >> regulator) can be switched, two callbacks are implemented in this >> change: if regulators are available an optional property >> 'xhci,port-power' can contain a stringlist with names of regulators >> that should be switched to control the power of ports (each entry in >> the stringlist corresponds to its respective regulator). >> >> For some versions of the RK3399-Q7 (at least revisions v1.1 and v1.2 >> are affected), we need to turn on the power for the port connected to >> the on-module USB hub only when FEAT_POWER is set to ensure that the >> hub does not enter a low-power mode that U-Boot's USB stack can't deal >> with. Note that Linux eventually manages to attach the hub even when >> it's in its low-power state after a few seconds. >> >> >> Please help me understand the problem. At first glance, I don't think >> such change should be put in the xHCI core codes. >> To me, this patch sounds like we use the regulator to enable/disable >> the power to an external on-board USB hub. For the xHC root port, this >> port power on/off is already configured by the xHC registers. >> >> >> The problem is that we have only a limited window of time between enabling >> the power to the USB hub and the USB controller starting its link-up >> procedure >> (i.e. reset of the port and waiting for a port-change), as the hub will >> otherwise >> go into a low-power mode and only come up for a short period of time every >> [I don’t remember the amount of time] milliseconds. >> > > Does the USB hub keep online all the time when the power is supplied > by the regulator? Is this entering low-power mode automatic? Can it be > turned off?
Once power starts probing for a link and (if it misses the link establishment) then goes into this low power mode where it wakes up every [x] milliseconds. So if we miss the initial active period for the attachment, then we’re pretty much lost within the constraints (i.e. w/o asynchronous port-change notifications) of the U-Boot USB stack. Turning this behaviour off requires an additional SPI flash for the USB hub, which may (as in “no new version has been scheduled yet”) be added in a future revision of the board. However, there are affected revisions of this product in the field that would benefit from fixing this (w/o this fix, only the dual-role port can be used from within U-Boot). > >> While this is no problem on Linux (the USB hub eventually gets detected >> after >> a delay of 2-3 seconds), the U-Boot USB stack (as it’s not interrupt driven) >> usually misses the port-change event (i.e. the probing has already moved on >> by the time the USB hub tries again). >> >> By having a callback directly from within the xHCI root-hub code, we can >> ensure that we always catch the USB hub. We can’t fix this from the board >> code, as the time between us enabling the regulator and the probing from >> within ‘usb start’ will be unpredictable. My first instinct was to have a >> call >> to a board-specific weak-function from xhci, but I finally settled on using >> the regulator-framework to have some that can be reused in the general >> case and also allows for on-demand power-on/off of on-board USB devices >> (if anybody has the need for it). >> > > If turning off the low-power mode is not possible, there is already a > weak function usb_hub_reset_devices() in current U-Boot USB stack. I > think you can use that existing one? I don’t think so, as the on-module hub won’t even show up on the bus if it’s in its low-power mode and usb_hub_configure (which in turn calls the usb_hub_reset_devices-hook) wouldn’t even be invoked for this case. Furthermore, usb_hub_reset_devices(int) only passes a port-number and we need to be selective on a specific root-port of a specific controller (we have 2 xHCIs active in our default DTS). > Regards, > Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
