[PATCH v2 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board

Thu Apr 23 23:20:17 CEST 2020

On Thu, Apr 23, 2020 at 5:24 AM Chen-Yu Tsai <wens at kernel.org> wrote:
>
> Hi,
>
> On Tue, Apr 21, 2020 at 1:35 AM Peter Geis <pgwipeout at gmail.com> wrote:
> >
> > On Thu, Apr 16, 2020 at 5:53 AM Loic Devulder <LDevulder at suse.com> wrote:
> > >
> > > Hi Chen,
> > >
> > > I tested your patches and all work pretty well. I just had issues with
> > > USB2 that doesn't recognize any of my USB keys (it's OK on USB3).
> > >
> > > I also had these issues with XHCI driver:
> > > => usb reset
> > > resetting USB...
> > > BUG at drivers/usb/host/xhci-mem.c:84/xhci_ring_free()!
> > > BUG!
> > > �esetting ...
> > >
> > > => usb stop
> > > stopping USB..
> > > Host not halted after 16000 microseconds.
> > > XHCI: failed to set VBus supply
> > > device_remove: Device 'usb at ff600000' failed to remove, but children are
> > > gone
> > >
> > > But for the whole series: Tested-by: Loic Devulder <ldevulder at suse.com>
> > >
> > > On Sun, 2020-04-05 at 10:25 +0800, Chen-Yu Tsai wrote:
> > > > From: Chen-Yu Tsai <wens at csie.org>
> > > >
> > > > Hi everyone,
> > > >
> > > > This is v2 of my ROC-RK3328-CC series. Changes from v1 are mainly
> > > > dropping the custom board target, and dealing with the pinmuxing
> > > > through proper use of DM regulators / GPIO / pinctrl in SPL.
> > > >
> > > > This series adds proper support for Firefly / Libre Computer ROC-
> > > > RK3328-CC
> > > > single board computer.
> > > >
> > > > The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
> > > > card size development board based on the Rockchip RK3328 SoC, with:
> > > >
> > > >   - 1/2/4 GB DDR4 DRAM
> > > >   - eMMC connector for optional module
> > > >   - micro SD card slot
> > > >   - 1 x USB 3.0 host port
> > > >   - 2 x USB 2.0 host port
> > > >   - 1 x USB 2.0 OTG port
> > > >   - HDMI video output
> > > >   - TRRS connector with audio and composite video output
> > > >   - gigabit Ethernet
> > > >   - consumer IR receiver
> > > >   - debug UART pins
> > > >
> > > > Originally I started with Loic's patches, and syncing the device tree
> > > > files from Linux. That didn't get very far, with SPL failing to
> > > > detect
> > > > the SD card. Examining the schematics and internal state of GRF and
> > > > GPIOs, I realized that the logic for the SD card power enable switch
> > > > is opposite that of what the SD card controller's SDMMC0_PWREN pin
> > > > would use. Instead, directly using the GPIO is required.
> > > >
> > > > To deal with this, DM regulator and GPIO are enabled in SPL, and
> > > > various device nodes are marked with u-boot,dm-spl to have them work.
> > > > pinctrl properties are not stripped, so as to have the SDMMC0_PWREN
> > > > pin muxed over to GPIO.
> > > >
> > > > Along the way, there are some clean-ups of existing dts files, moving
> > > > U-boot only features to -u-boot.dtsi files, and then a wholesale sync
> > > > from Linux. Only boards already existing in U-boot are synced. DT
> > > > binding header files are synced separately as there is already one
> > > > patch floating around. The DT sync also includes clean-up changes
> > > > only
> > > > recently posted, and likely won't make it in for at least a few
> > > > weeks.
> > > >
> > > > Please have a look, and test if possible. I cc-ed a couple people
> > > > that
> > > > showed interest in this board on mailing lists recently.
> > > >
> > > > Regards
> > > > ChenYu
> > > >
> > > >
> > > > Chen-Yu Tsai (6):
> > > >   rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-
> > > > boot.dtsi
> > > >   rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-
> > > > boot.dtsi
> > > >   dt-bindings: clock: rk3328: sync from upstream Linux kernel
> > > >   dt-bindings: power: rk3328-power: sync from upstream Linux kernel
> > > >   rockchip: dts: rk3328: Sync device tree files from Linux
> > > >   rockchip: rk3328: Add support for ROC-RK3328-CC board
> > > >
> > > >  arch/arm/dts/Makefile                         |    1 +
> > > >  arch/arm/dts/rk3328-evb-u-boot.dtsi           |   39 +
> > > >  arch/arm/dts/rk3328-evb.dts                   |  220 +--
> > > >  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi        |   38 +
> > > >  .../{rk3328-rock64.dts => rk3328-roc-cc.dts}  |  135 +-
> > > >  arch/arm/dts/rk3328-rock64.dts                |  132 +-
> > > >  arch/arm/dts/rk3328.dtsi                      | 1420 +++++++++++--
> > > > ----
> > > >  board/rockchip/evb_rk3328/MAINTAINERS         |    7 +
> > > >  configs/roc-cc-rk3328_defconfig               |  103 ++
> > > >  doc/README.rockchip                           |    4 +-
> > > >  include/dt-bindings/clock/rk3328-cru.h        |  212 +--
> > > >  include/dt-bindings/power/rk3328-power.h      |   19 +
> > > >  12 files changed, 1578 insertions(+), 752 deletions(-)
> > > >  create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
> > > >  copy arch/arm/dts/{rk3328-rock64.dts => rk3328-roc-cc.dts} (68%)
> > > >  create mode 100644 configs/roc-cc-rk3328_defconfig
> > > >  create mode 100644 include/dt-bindings/power/rk3328-power.h
> > > >
> > > --
> > > Loic Devulder <ldevulder at suse.com> | ldevulder at irc
> > > 0x175A963893C85F55 | D220 DEF5 56A3 DE00 9DAA 78BA 175A 9638 93C8 5F55
> > > Senior QA Engineer | Container & Storage Solutions Quality Assurance
> > > team (qa-css)
> > > SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
> > > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB, 21284 (AG
> > > Nuernberg)
> >
> > Good Afternoon,
> >
> > I have tested this patch set against u-boot git as of 20 April 2020
> > and have some feedback.
> > The issue of booting off the sdmmc is fixed, thanks!
> >
> > The USB issues above come from a few issues:
> > vcc_host1_5v is set to regulator-always-on, which prevents USB from
> > resetting properly, remove this option allows xhci to clean up.
>
> This seems a little odd. I suppose it's because of how U-boot's USB
> stack works. On Linux, the XHCI is not supported. There seems to be
> an issue in that the controller never detects disconnects.

Mainline Linux is missing the PHY driver, so you can enable the USB3
controller, but yes, connects/disconnects are not detected.
I've tried to port the downstream driver, but it is a mess and doesn't
trigger interrupts for 3.0 devices.

>
> > USB 2.0 Host does not work because there is no rockchip,rk3328-usb2phy yet.
> > This causes the generic ohci and ehci drivers to fail, removing
> > CONFIG_PHY from your defconfig resolves this.
>
> Removing CONFIG_PHY stops XHCI from working.

Odd, I never encountered that issue, maybe because I tagged all of the
phys to all of their devices.

>
> It seems easier to remove the phy properties using the -u-boot.dtsi file.
>
> > The USB-OTG port appears to not work because it's stuck in peripheral mode.
> > The vbus-supply = <&vcc_host1_5v> should be on all three USB
> > controllers, as it powers all three ports.
>
> I tried setting dr_mode = "host" in the device tree but it still timeouts.
> Setting vbus-supply doesn't help either as it is timing out during the
> initializing phase in the driver, before vbus is enabled. Since it worked
> before my patchset, I'm guessing it might be related to the assigned-clocks
> changes. I have to do some more tests to narrow it down.

I didn't test it, but it seemed to be the logical place to check.

>
>
> Some thoughts carried over from Linux regarding the always-on setting:
>
> For this particular board, since all ports share the same GPIO to control
> USB VCC, having it not always-on might result in other devices getting
> power cycled, since U-boot doesn't do reference counting for regulators.
>
> Another thing is that the bindings only allow the VBUS regulator to be
> tied to the USB PHY, which is not supported in U-boot, and not the host.
>
> To me it seems to make more sense to make enable/disable no-ops for
> always-on regulators, instead of returning errors.

Yes, but at least from my limited testing it seems U-Boot enables them
all en-mass during usb start.
It then shuts them all down during usb reset or usb stop.
It doesn't appear to implement runtime power management.

If you implement no-ops does that solve the issue of it not cleaning
up xhci on shutdown?

>
>
> Regards
> ChenYu
>
>
>
> > Overall, excellent work!
> > For the whole series: Tested-by: Peter Geis <pgwipeout at gmail.com>