[Letux-kernel] Status of JZ4780/CI20 upstream support

Paul Boddie paul at boddie.org.uk
Fri Jul 12 18:50:37 CEST 2019

On Tuesday 9. July 2019 02.57.11 Maarten ter Huurne wrote:
> On Tuesday, 9 July 2019 00:22:18 CEST Paul Boddie wrote:
> > ohci-jz4740.c needs to be brought in from 3.18 (or elsewhere, maybe)
> > and included within ohci-hcd.c in a not particularly pleasant
> > fashion, but this just seems to be the way things are done with the
> > OHCI support.
> I removed ohci-jz4740.c from mainline 3 years ago, because it is not
> needed to be able to use the OHCI controller on the JZ47xx SoCs: the
> generic OHCI platform driver can be used instead.

That is very useful to know, thanks!

> Details can be found in these commits:
> commit b071c5d7998a79919e83565ddfb98fdf6fa804bc
> Author: Maarten ter Huurne <maarten at treewalker.org>
> Date:   Mon Apr 18 20:58:53 2016 +0200
>     USB: ohci-jz4740: Remove obsolete driver
>     The ohci-platform driver can control the clock, while usb-nop-xceiv
>     as the PHY can control the vbus regulator. So this JZ4740-specific
>     glue is not needed anymore.

I had a look at the PHY and regulator, but I think that I probably need to 
figure out some more things. With the PHY, it seems that the following might 
be plausible:

        usb_phy: usb-phy {
                compatible = "usb-nop-xceiv";
                vcc-supply = <&usb_regulator>;
                #phy-cells = <0>;

Meanwhile, a reasonable candidate for the regulator seems to be one based on a 

        usb_regulator: usb-regulator {
                compatible = "regulator-gpio";

                regulator_name = "usb-vbus-supply";
                enable-gpio = <&gpf 15 0>;


The enable-gpio property replaces a driver-specific property found in the 
board device tree for the CI20-specific kernel which appears to be serviced by 
the JZ4780-specific EHCI driver:

&ehci {
        ingenic,vbus-gpio = <&gpf 15 0>;

This property is also associated with the OHCI-related nodes, but since it is 
ohci-jz4740 that acts as the driver for that kernel, and since that driver 
only recognises a regulator specified using the vbus property, I can't see how 
the above property would make any sense in an OHCI context. Of course, it 
wouldn't make any sense with the OHCI platform driver.

(The CI20-specific 3.18 kernel appears to rely on a dedicated driver for the 
regulator present in its device tree, setting the Low Power Control register 
(LCR) that also happens to be present in the JZ4740, but it doesn't seem to 
have an obvious connection to the USB devices.)

> commit 9d1e7875fafc45dbcbe3d816b022aa1f17219f32
> Author: Maarten ter Huurne <maarten at treewalker.org>
> Date:   Mon Apr 18 20:58:52 2016 +0200
>     MIPS: JZ4740: Probe OHCI platform device via DT
>     The DT fragment will select the ohci-platform driver, since that can
>     handle the JZ4740 OHCI just fine. While I don't have a JZ4740-based
>     board with anything connected to the USB host controller, I did test
>     the generic OHCI driver successfully on a JZ4770-based board.
>     The device is disabled by default; boards that want to use it can
>     override the "status" property. The mass-production Qi LB60 boards
>     don't use the USB host controller.

I do also wonder whether the EHCI platform driver might be relevant, but one 
thing at a time, I suppose. (It was too bad that those AVT2 boards never led 
to a new NanoNote model.)

> Example DeviceTree fragments can be found here:
> Define OHCI in SoC file:
> https://github.com/gcwnow/linux/blob/jz-4.9-wip/arch/mips/boot/dts/
> ingenic/jz4770.dtsi#L101
> Enable OHCI in device file:
> https://github.com/gcwnow/linux/blob/jz-4.9-wip/arch/mips/boot/dts/
> ingenic/gcw0.dts#L453

Thanks once again for the information! I'll continue to try and figure this 
out, which is one of the reasons why I have been rather slow in responding.


More information about the Letux-kernel mailing list