Change Details

- Move `xhci_mv` to `xhci_fdt`, as the code there is pretty much for any generic XHCI controller, nothing Marvell specific really - Add DesignWare XHCI controller initialization code to `xhci_fdt`, imported from OpenBSD - Add a driver for the Rockchip glue node that wraps the DesignWare XHCI node --- At first, I couldn't test that this works on my Pine64 ROCKPro64, as the 5V USB power went down almost as soon as the loader jumped to the kernel (right before seeing any device attachment messages on the serial console). I've tried writing a driver for the USB 2 PHY that would turn that on, but the `vcc5v0_host` regulator is supposedly already enabled. I just can't figure that out. But today, I stumbled upon [[ https://www.cnx-software.com/2018/08/27/rockpro64-rk3399-board-linux-review-ubuntu-18-04/ | an article reviewing a Linux distro on this board ]], and saw this: ``` sudo cat /sys/kernel/debug/gpio […] GPIOs 128-159, platform/pinctrl, gpio4: gpio-154 ( |vcc5v0_host ) out hi ``` That made the workaround obvious: ``` gpioctl -f /dev/gpioc4 26 1 ``` With that command, the power is back on, and yes — the USB-A 3.0 port actually works!! :) Figuring out how to make the power come on without running that command is out of scope for this patch, and might not even be required on boards other than the ROCKPro64… What I've discovered is that pinctrl writes zero to that pin on boot, so probably the output is just late. Maybe `enable-active-high` support for fixed regulator is broken or something. ``` rk_pinctrl0: conf pin: bank 4 subbank 3 pin 26 function 0 bit 4 mask 3145728 reg 57388 rk_pinctrl0: conf pin: wrote 0 << 4 | 3145728 == 3145728 ```

- Add DesignWare XHCI controller initialization imported from OpenBSD - Add a driver for the Rockchip glue node that wraps the DesignWare XHCI node --- At first, I couldn't test that this works on my Pine64 ROCKPro64, as the 5V USB power went down almost as soon as the loader jumped to the kernel (right before seeing any device attachment messages on the serial console). I've tried writing a driver for the USB 2 PHY that would turn that on, but the `vcc5v0_host` regulator is supposedly already enabled. I just can't figure that out. But today, I stumbled upon [[ https://www.cnx-software.com/2018/08/27/rockpro64-rk3399-board-linux-review-ubuntu-18-04/ | an article reviewing a Linux distro on this board ]], and saw this: ``` sudo cat /sys/kernel/debug/gpio […] GPIOs 128-159, platform/pinctrl, gpio4: gpio-154 ( |vcc5v0_host ) out hi ``` That made the workaround obvious: ``` gpioctl -f /dev/gpioc4 26 1 ``` With that command, the power is back on, and yes — the USB-A 3.0 port actually works!! :) Figuring out how to make the power come on without running that command is out of scope for this patch, and might not even be required on boards other than the ROCKPro64… What I've discovered is that pinctrl writes zero to that pin on boot, so probably the output is just late. Maybe `enable-active-high` support for fixed regulator is broken or something. ``` rk_pinctrl0: conf pin: bank 4 subbank 3 pin 26 function 0 bit 4 mask 3145728 reg 57388 rk_pinctrl0: conf pin: wrote 0 << 4 | 3145728 == 3145728 ```

- Move `xhci_mv` to `xhci_fdt`, as the code there is pretty much for any generic XHCI controller, nothing Marvell specific really - Add DesignWare XHCI controller initialization code to `xhci_fdt`, imported from OpenBSD - Add a driver for the Rockchip glue node that wraps the DesignWare XHCI node --- At first, I couldn't test that this works on my Pine64 ROCKPro64, as the 5V USB power went down almost as soon as the loader jumped to the kernel (right before seeing any device attachment messages on the serial console). I've tried writing a driver for the USB 2 PHY that would turn that on, but the `vcc5v0_host` regulator is supposedly already enabled. I just can't figure that out. But today, I stumbled upon [[ https://www.cnx-software.com/2018/08/27/rockpro64-rk3399-board-linux-review-ubuntu-18-04/ | an article reviewing a Linux distro on this board ]], and saw this: ``` sudo cat /sys/kernel/debug/gpio […] GPIOs 128-159, platform/pinctrl, gpio4: gpio-154 ( |vcc5v0_host ) out hi ``` That made the workaround obvious: ``` gpioctl -f /dev/gpioc4 26 1 ``` With that command, the power is back on, and yes — the USB-A 3.0 port actually works!! :) Figuring out how to make the power come on without running that command is out of scope for this patch, and might not even be required on boards other than the ROCKPro64… What I've discovered is that pinctrl writes zero to that pin on boot, so probably the output is just late. Maybe `enable-active-high` support for fixed regulator is broken or something. ``` rk_pinctrl0: conf pin: bank 4 subbank 3 pin 26 function 0 bit 4 mask 3145728 reg 57388 rk_pinctrl0: conf pin: wrote 0 << 4 | 3145728 == 3145728 ```