[U-Boot] [PATCH 1/2] usb: xhci: implement FEAT_POWER hook for switching regulators for ports

[Bin Meng]

Hi Philipp,

On Fri, Nov 17, 2017 at 5:43 PM, Dr. Philipp Tomsich
<philipp.tomsich at theobroma-systems.com> wrote:
> Bin,
>
> On 17 Nov 2017, at 10:27, Bin Meng <bmeng.cn at gmail.com> wrote:
>
> Hi Philipp,
>
> On Tue, Nov 7, 2017 at 6:04 AM, Philipp Tomsich
> <philipp.tomsich at 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?

> 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?

Regards,
Bin