USB3 regression in RK3399

USB3 regression in RK3399

[Vicente Bergas]

Hello,
testing on the Sapphire board, which uses the RK3399 SoC, a regression
has been found in v4.16-rc2 wrt v4.15.4 regarding the USB3 type-A port:
In v4.15.4 it works in USB2-only mode.
In v4.16-rc2 it does not work.

It has been tested with a USB2 hub with 3 devices connected:
a keyboard (USB1.1), a mouse (USB2) and a rtlwifi dongle (USB2).

It has also been tested with a USB3-to-SATA converter. This one is not
working in v4.15.4 nor in v4.16-rc2.

I have also tried the 6-patch series from Enric Balletbo i Serra
"[PATCH v3 3/6] phy: rockchip-typec: enable usb3 host during usb3 phy power on"
with the same result.

During boot, the following message appears a few times:
"dwc3: failed to initialize core"

The kernel configuration is:
https://archlinuxarm.org/packages/aarch64/linux-aarch64-rc/files/config

Is that a configuration issue, a bug in the kernel or something else?
If it is a configuration issue, what should be changed?
If it is a bug, can it be fixed?

Regards,
  Vicente.

Re: USB3 regression in RK3399

[Heiko Stuebner]

Hi Vicente,

Am Mittwoch, 21. Februar 2018, 22:58:35 CET schrieb Vicente Bergas:
> testing on the Sapphire board, which uses the RK3399 SoC, a regression
> has been found in v4.16-rc2 wrt v4.15.4 regarding the USB3 type-A port:
> In v4.15.4 it works in USB2-only mode.
> In v4.16-rc2 it does not work.
> 
> It has been tested with a USB2 hub with 3 devices connected:
> a keyboard (USB1.1), a mouse (USB2) and a rtlwifi dongle (USB2).
> 
> It has also been tested with a USB3-to-SATA converter. This one is not
> working in v4.15.4 nor in v4.16-rc2.
> 
> I have also tried the 6-patch series from Enric Balletbo i Serra
> "[PATCH v3 3/6] phy: rockchip-typec: enable usb3 host during usb3 phy power on"
> with the same result.
> 
> During boot, the following message appears a few times:
> "dwc3: failed to initialize core"
> 
> The kernel configuration is:
> https://archlinuxarm.org/packages/aarch64/linux-aarch64-rc/files/config
> 
> Is that a configuration issue, a bug in the kernel or something else?
> If it is a configuration issue, what should be changed?
> If it is a bug, can it be fixed?

Hmm, I'd guess the main issue would be a missing typec-phy driver
in your kernel (see drivers/phy/rockchip/phy-rockchip-typec.c

But even with this driver, I realize that we'll be missing the extcon
driver telling the driver about the cable state. ChromeOS devices
get the cable-state from the embedded controller via the extcon
interface and while other boards seem to use the fusb302 chip
for power-delivery, the driver currently does not seem to
utilize the extcon interface for something like this.

Also, right now the rockchip typec-phy does fail probing when no
extcon is detected, but shouldn't it just fall back to working in host-
mode if it cannot get the extcon, or the device just routes everything
to a standard usb3 port?

Heiko

Re: USB3 regression in RK3399

[Vicente Bergas]

On Wed, Feb 21, 2018 at 11:17 PM, Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> wrote:
> Hi Vicente,
>
> Am Mittwoch, 21. Februar 2018, 22:58:35 CET schrieb Vicente Bergas:
>> testing on the Sapphire board, which uses the RK3399 SoC, a regression
>> has been found in v4.16-rc2 wrt v4.15.4 regarding the USB3 type-A port:
>> In v4.15.4 it works in USB2-only mode.
>> In v4.16-rc2 it does not work.
>>
>> It has been tested with a USB2 hub with 3 devices connected:
>> a keyboard (USB1.1), a mouse (USB2) and a rtlwifi dongle (USB2).
>>
>> It has also been tested with a USB3-to-SATA converter. This one is not
>> working in v4.15.4 nor in v4.16-rc2.
>>
>> I have also tried the 6-patch series from Enric Balletbo i Serra
>> "[PATCH v3 3/6] phy: rockchip-typec: enable usb3 host during usb3 phy power on"
>> with the same result.
>>
>> During boot, the following message appears a few times:
>> "dwc3: failed to initialize core"
>>
>> The kernel configuration is:
>> https://archlinuxarm.org/packages/aarch64/linux-aarch64-rc/files/config
>>
>> Is that a configuration issue, a bug in the kernel or something else?
>> If it is a configuration issue, what should be changed?
>> If it is a bug, can it be fixed?
>
> Hmm, I'd guess the main issue would be a missing typec-phy driver
> in your kernel (see drivers/phy/rockchip/phy-rockchip-typec.c
>
> But even with this driver, I realize that we'll be missing the extcon
> driver telling the driver about the cable state. ChromeOS devices
> get the cable-state from the embedded controller via the extcon
> interface and while other boards seem to use the fusb302 chip
> for power-delivery, the driver currently does not seem to
> utilize the extcon interface for something like this.
>
> Also, right now the rockchip typec-phy does fail probing when no
> extcon is detected, but shouldn't it just fall back to working in host-
> mode if it cannot get the extcon, or the device just routes everything
> to a standard usb3 port?
>
> Heiko

Hi Heiko,
by comparison the kernel configuration that works (partially,
usb2-only) with v4.15.4 is
https://archlinuxarm.org/packages/aarch64/linux-aarch64/files/config
all the parameters CONFIG_*TYPEC*, CONFIG_*FUSB302*,
CONFIG_*PHY*ROCKCHIP* and CONFIG_*EXTCON* are the same among the two.
So, I suspect the difference should lay somewhere else.
Has Type-C anything to do with Type-A?

Regards,
  Vicente.

Re: USB3 regression in RK3399

[Enric Balletbo i Serra]

Hi Vincente,

On 22/02/18 00:04, Vicente Bergas wrote:
> On Wed, Feb 21, 2018 at 11:17 PM, Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> wrote:
>> Hi Vicente,
>>
>> Am Mittwoch, 21. Februar 2018, 22:58:35 CET schrieb Vicente Bergas:
>>> testing on the Sapphire board, which uses the RK3399 SoC, a regression
>>> has been found in v4.16-rc2 wrt v4.15.4 regarding the USB3 type-A port:
>>> In v4.15.4 it works in USB2-only mode.
>>> In v4.16-rc2 it does not work.
>>>
>>> It has been tested with a USB2 hub with 3 devices connected:
>>> a keyboard (USB1.1), a mouse (USB2) and a rtlwifi dongle (USB2).
>>>
>>> It has also been tested with a USB3-to-SATA converter. This one is not
>>> working in v4.15.4 nor in v4.16-rc2.
>>>
>>> I have also tried the 6-patch series from Enric Balletbo i Serra
>>> "[PATCH v3 3/6] phy: rockchip-typec: enable usb3 host during usb3 phy power on"
>>> with the same result.
>>>
>>> During boot, the following message appears a few times:
>>> "dwc3: failed to initialize core"
>>>
>>> The kernel configuration is:
>>> https://archlinuxarm.org/packages/aarch64/linux-aarch64-rc/files/config
>>>
>>> Is that a configuration issue, a bug in the kernel or something else?
>>> If it is a configuration issue, what should be changed?
>>> If it is a bug, can it be fixed?
>>
>> Hmm, I'd guess the main issue would be a missing typec-phy driver
>> in your kernel (see drivers/phy/rockchip/phy-rockchip-typec.c
>>
>> But even with this driver, I realize that we'll be missing the extcon
>> driver telling the driver about the cable state. ChromeOS devices
>> get the cable-state from the embedded controller via the extcon
>> interface and while other boards seem to use the fusb302 chip
>> for power-delivery, the driver currently does not seem to
>> utilize the extcon interface for something like this.
>>
>> Also, right now the rockchip typec-phy does fail probing when no
>> extcon is detected, but shouldn't it just fall back to working in host-
>> mode if it cannot get the extcon, or the device just routes everything
>> to a standard usb3 port?
>>
>> Heiko
> 
> Hi Heiko,
> by comparison the kernel configuration that works (partially,
> usb2-only) with v4.15.4 is
> https://archlinuxarm.org/packages/aarch64/linux-aarch64/files/config
> all the parameters CONFIG_*TYPEC*, CONFIG_*FUSB302*,
> CONFIG_*PHY*ROCKCHIP* and CONFIG_*EXTCON* are the same among the two.
> So, I suspect the difference should lay somewhere else.
> Has Type-C anything to do with Type-A?
> 
> Regards,
>   Vicente.
> 

I suspect that what Heiko says is right and typec-phy fails probing. Could you
copy your dmesg output somewhere?

Thanks,
  Enric

Re: USB3 regression in RK3399

[Vicente Bergas]

On Thu, Feb 22, 2018 at 10:10 AM, Enric Balletbo i Serra
<enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> wrote:
> Hi Vincente,
>
> On 22/02/18 00:04, Vicente Bergas wrote:
>> On Wed, Feb 21, 2018 at 11:17 PM, Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> wrote:
>>> Hi Vicente,
>>>
>>> Am Mittwoch, 21. Februar 2018, 22:58:35 CET schrieb Vicente Bergas:
>>>> testing on the Sapphire board, which uses the RK3399 SoC, a regression
>>>> has been found in v4.16-rc2 wrt v4.15.4 regarding the USB3 type-A port:
>>>> In v4.15.4 it works in USB2-only mode.
>>>> In v4.16-rc2 it does not work.
>>>>
>>>> It has been tested with a USB2 hub with 3 devices connected:
>>>> a keyboard (USB1.1), a mouse (USB2) and a rtlwifi dongle (USB2).
>>>>
>>>> It has also been tested with a USB3-to-SATA converter. This one is not
>>>> working in v4.15.4 nor in v4.16-rc2.
>>>>
>>>> I have also tried the 6-patch series from Enric Balletbo i Serra
>>>> "[PATCH v3 3/6] phy: rockchip-typec: enable usb3 host during usb3 phy power on"
>>>> with the same result.
>>>>
>>>> During boot, the following message appears a few times:
>>>> "dwc3: failed to initialize core"
>>>>
>>>> The kernel configuration is:
>>>> https://archlinuxarm.org/packages/aarch64/linux-aarch64-rc/files/config
>>>>
>>>> Is that a configuration issue, a bug in the kernel or something else?
>>>> If it is a configuration issue, what should be changed?
>>>> If it is a bug, can it be fixed?
>>>
>>> Hmm, I'd guess the main issue would be a missing typec-phy driver
>>> in your kernel (see drivers/phy/rockchip/phy-rockchip-typec.c
>>>
>>> But even with this driver, I realize that we'll be missing the extcon
>>> driver telling the driver about the cable state. ChromeOS devices
>>> get the cable-state from the embedded controller via the extcon
>>> interface and while other boards seem to use the fusb302 chip
>>> for power-delivery, the driver currently does not seem to
>>> utilize the extcon interface for something like this.
>>>
>>> Also, right now the rockchip typec-phy does fail probing when no
>>> extcon is detected, but shouldn't it just fall back to working in host-
>>> mode if it cannot get the extcon, or the device just routes everything
>>> to a standard usb3 port?
>>>
>>> Heiko
>>
>> Hi Heiko,
>> by comparison the kernel configuration that works (partially,
>> usb2-only) with v4.15.4 is
>> https://archlinuxarm.org/packages/aarch64/linux-aarch64/files/config
>> all the parameters CONFIG_*TYPEC*, CONFIG_*FUSB302*,
>> CONFIG_*PHY*ROCKCHIP* and CONFIG_*EXTCON* are the same among the two.
>> So, I suspect the difference should lay somewhere else.
>> Has Type-C anything to do with Type-A?
>>
>> Regards,
>>   Vicente.
>>
>
> I suspect that what Heiko says is right and typec-phy fails probing. Could you
> copy your dmesg output somewhere?
>
> Thanks,
>   Enric

Hi Enric,

the dmesg for v4.15.4:
https://pastebin.com/vbAMUnnL

the dmesg for v4.16-rc2:
https://pastebin.com/EL2V7u8j

Note that the rootfs is on a SATA disk connected to the USB2 type-A
port. That works on both kernel versions.
There are 3 other devices on a usb hub connected to the USB3 type-A
port. That is only recognized by v4.15.4.
The preferred setup is to have the disk at the usb3 port at usb3
speed, but that does not work in either version.

Regards,
  Vicente.

Re: USB3 regression in RK3399

[Vicente Bergas]

(cut)
>>>>> testing on the Sapphire board, which uses the RK3399 SoC, a regression
>>>>> has been found in v4.16-rc2 wrt v4.15.4 regarding the USB3 type-A port:
>>>>> In v4.15.4 it works in USB2-only mode.
>>>>> In v4.16-rc2 it does not work.
(cut)
>>>> Hmm, I'd guess the main issue would be a missing typec-phy driver
>>>> in your kernel (see drivers/phy/rockchip/phy-rockchip-typec.c
(cut)
>> I suspect that what Heiko says is right and typec-phy fails probing. Could you
(cut)

Hello,
this is the patch to blame for the regression:

From c301b327aea898af558b2387252a2f5fc0117dee Mon Sep 17 00:00:00 2001
From: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Date: Fri, 15 Dec 2017 12:00:03 +0100
Subject: [PATCH] arm64: dts: rockchip: add usb3-phy otg-port support for rk3399

Add the usb3 phyter for the USB3.0 OTG controller.

Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Signed-off-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index b4511503878b..7aa2144e0d47 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -411,8 +411,8 @@
             reg = <0x0 0xfe800000 0x0 0x100000>;
             interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
             dr_mode = "otg";
-            phys = <&u2phy0_otg>;
-            phy-names = "usb2-phy";
+            phys = <&u2phy0_otg>, <&tcphy0_usb3>;
+            phy-names = "usb2-phy", "usb3-phy";
             phy_type = "utmi_wide";
             snps,dis_enblslpm_quirk;
             snps,dis-u2-freeclk-exists-quirk;
@@ -444,8 +444,8 @@
             reg = <0x0 0xfe900000 0x0 0x100000>;
             interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>;
             dr_mode = "otg";
-            phys = <&u2phy1_otg>;
-            phy-names = "usb2-phy";
+            phys = <&u2phy1_otg>, <&tcphy1_usb3>;
+            phy-names = "usb2-phy", "usb3-phy";
             phy_type = "utmi_wide";
             snps,dis_enblslpm_quirk;
             snps,dis-u2-freeclk-exists-quirk;
-- 
2.16.2


Before that patch, in dwc3_core_get_phy in drivers/usb/dwc3/core.c
  if (IS_ERR(dwc->usb3_generic_phy)) {
    ret = PTR_ERR(dwc->usb3_generic_phy);
    if (ret == -ENOSYS || ret == -ENODEV) {
      dwc->usb3_generic_phy = NULL;
      // USB3 phy not in device tree, OK, continue without.
    } else if (ret == -EPROBE_DEFER) {
    } else {
    }
  }


After that patch, in dwc3_core_get_phy in drivers/usb/dwc3/core.c
  if (IS_ERR(dwc->usb3_generic_phy)) {
    ret = PTR_ERR(dwc->usb3_generic_phy);
    if (ret == -ENOSYS || ret == -ENODEV) {
      // USB3 phy is in device tree now, this branch is no longer taken.
    } else if (ret == -EPROBE_DEFER) {
      return ret;
      // No usb3_phy found, ERROR, bail out.
      // At this point it could continue in degraded usb2 mode,
      //   but it does not.
    } else {
    }
  }

An usb3 phy is not found because no usb3 phy is being registered.
No usb3 phy is being registered because no usb3 phy is being probed at all.
I do not know why it is not being probed.
In the configuration file, CONFIG_PHY_ROCKCHIP_TYPEC is set to y.

So, all in all, there are two bugs:
 1.- The regression: usb3 mode is new and does not work, BUT this
     makes the usb2 mode to be discarded.
 2.- The new feature: usb3 mode does not work.

Regards,
  Vicente.

Re: USB3 regression in RK3399

[Enric Balletbo i Serra]

Hi Vicente,

On 25/02/18 11:03, Vicente Bergas wrote:
> (cut)
>>>>>> testing on the Sapphire board, which uses the RK3399 SoC, a regression
>>>>>> has been found in v4.16-rc2 wrt v4.15.4 regarding the USB3 type-A port:
>>>>>> In v4.15.4 it works in USB2-only mode.
>>>>>> In v4.16-rc2 it does not work.
> (cut)
>>>>> Hmm, I'd guess the main issue would be a missing typec-phy driver
>>>>> in your kernel (see drivers/phy/rockchip/phy-rockchip-typec.c
> (cut)
>>> I suspect that what Heiko says is right and typec-phy fails probing. Could you
> (cut)
> 
> Hello,
> this is the patch to blame for the regression:
> 
> From c301b327aea898af558b2387252a2f5fc0117dee Mon Sep 17 00:00:00 2001
> From: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> Date: Fri, 15 Dec 2017 12:00:03 +0100
> Subject: [PATCH] arm64: dts: rockchip: add usb3-phy otg-port support for rk3399
> 
> Add the usb3 phyter for the USB3.0 OTG controller.
> 
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> Signed-off-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
> ---
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index b4511503878b..7aa2144e0d47 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -411,8 +411,8 @@
>              reg = <0x0 0xfe800000 0x0 0x100000>;
>              interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
>              dr_mode = "otg";
> -            phys = <&u2phy0_otg>;
> -            phy-names = "usb2-phy";
> +            phys = <&u2phy0_otg>, <&tcphy0_usb3>;
> +            phy-names = "usb2-phy", "usb3-phy";
>              phy_type = "utmi_wide";
>              snps,dis_enblslpm_quirk;
>              snps,dis-u2-freeclk-exists-quirk;
> @@ -444,8 +444,8 @@
>              reg = <0x0 0xfe900000 0x0 0x100000>;
>              interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>;
>              dr_mode = "otg";
> -            phys = <&u2phy1_otg>;
> -            phy-names = "usb2-phy";
> +            phys = <&u2phy1_otg>, <&tcphy1_usb3>;
> +            phy-names = "usb2-phy", "usb3-phy";
>              phy_type = "utmi_wide";
>              snps,dis_enblslpm_quirk;
>              snps,dis-u2-freeclk-exists-quirk;
> 

(cut)

> An usb3 phy is not found because no usb3 phy is being registered.
> No usb3 phy is being registered because no usb3 phy is being probed at all.
> I do not know why it is not being probed.
> In the configuration file, CONFIG_PHY_ROCKCHIP_TYPEC is set to y.
>

Probably the problem here is that the phyter is disabled in the DT, if you apply
the following patch it will probably pass but then there is the problem that
Heiko pointed, we'll be missing the extcon driver telling the driver about the
cable state. I suspect that is the fusb302 who should implement the extcon
interface.

I'll try to look a bit on this.

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
index f7157c1d768b..617d362eb8af 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
@@ -569,6 +569,14 @@
        status = "okay";
 };

+&tcphy0 {
+       status = "okay";
+};
+
+&tcphy1 {
+       status = "okay";
+};
+
 &u2phy0 {
        status = "okay";

Cheers,
 Enric


> So, all in all, there are two bugs:
>  1.- The regression: usb3 mode is new and does not work, BUT this
>     makes the usb2 mode to be discarded.
>  2.- The new feature: usb3 mode does not work.
>
> Regards,
>   Vicente.

Re: USB3 regression in RK3399

[Enric Balletbo i Serra]

Hi Vicente,

On 25/02/18 11:03, Vicente Bergas wrote:
> (cut)
>>>>>> testing on the Sapphire board, which uses the RK3399 SoC, a regression
>>>>>> has been found in v4.16-rc2 wrt v4.15.4 regarding the USB3 type-A port:
>>>>>> In v4.15.4 it works in USB2-only mode.
>>>>>> In v4.16-rc2 it does not work.
> (cut)
>>>>> Hmm, I'd guess the main issue would be a missing typec-phy driver
>>>>> in your kernel (see drivers/phy/rockchip/phy-rockchip-typec.c
> (cut)
>>> I suspect that what Heiko says is right and typec-phy fails probing. Could you
> (cut)
> 
> Hello,
> this is the patch to blame for the regression:
> 
> From c301b327aea898af558b2387252a2f5fc0117dee Mon Sep 17 00:00:00 2001
> From: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> Date: Fri, 15 Dec 2017 12:00:03 +0100
> Subject: [PATCH] arm64: dts: rockchip: add usb3-phy otg-port support for rk3399
> 
> Add the usb3 phyter for the USB3.0 OTG controller.
> 
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> Signed-off-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
> ---
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index b4511503878b..7aa2144e0d47 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -411,8 +411,8 @@
>              reg = <0x0 0xfe800000 0x0 0x100000>;
>              interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
>              dr_mode = "otg";
> -            phys = <&u2phy0_otg>;
> -            phy-names = "usb2-phy";
> +            phys = <&u2phy0_otg>, <&tcphy0_usb3>;
> +            phy-names = "usb2-phy", "usb3-phy";
>              phy_type = "utmi_wide";
>              snps,dis_enblslpm_quirk;
>              snps,dis-u2-freeclk-exists-quirk;
> @@ -444,8 +444,8 @@
>              reg = <0x0 0xfe900000 0x0 0x100000>;
>              interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>;
>              dr_mode = "otg";
> -            phys = <&u2phy1_otg>;
> -            phy-names = "usb2-phy";
> +            phys = <&u2phy1_otg>, <&tcphy1_usb3>;
> +            phy-names = "usb2-phy", "usb3-phy";
>              phy_type = "utmi_wide";
>              snps,dis_enblslpm_quirk;
>              snps,dis-u2-freeclk-exists-quirk;
> 

Can you try if the following patch solves the issue for you?

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
index f7157c1d768b..617d362eb8af 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
@@ -569,6 +569,14 @@
 	status = "okay";
 };

+&tcphy0 {
+	status = "okay";
+};
+
+&tcphy1 {
+	status = "okay";
+};
+
 &u2phy0 {
 	status = "okay";

diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c
b/drivers/phy/rockchip/phy-rockchip-typec.c
index 1c79785a5439..6af1ec262fcb 100644
--- a/drivers/phy/rockchip/phy-rockchip-typec.c
+++ b/drivers/phy/rockchip/phy-rockchip-typec.c
@@ -821,6 +821,9 @@ static int tcphy_get_mode(struct rockchip_typec_phy *tcphy)
 	u8 mode;
 	int ret;

+	if (!edev)
+		return MODE_DFP_USB;
+
 	ufp = extcon_get_state(edev, EXTCON_USB);
 	dp = extcon_get_state(edev, EXTCON_DISP_DP);

@@ -1159,9 +1162,9 @@ static int rockchip_typec_phy_probe(struct platform_device
*pdev)

 	tcphy->extcon = extcon_get_edev_by_phandle(dev, 0);
 	if (IS_ERR(tcphy->extcon)) {
-		if (PTR_ERR(tcphy->extcon) != -EPROBE_DEFER)
-			dev_err(dev, "Invalid or missing extcon\n");
-		return PTR_ERR(tcphy->extcon);
+		if (PTR_ERR(tcphy->extcon) == -EPROBE_DEFER)
+			return PTR_ERR(tcphy->extcon);
+		tcphy->extcon = NULL;
 	}

 	pm_runtime_enable(dev);


Best regards,
 Enric

Re: USB3 regression in RK3399

[Vicente Bergas]

On Mon, Feb 26, 2018 at 5:34 PM, Enric Balletbo i Serra
<enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> wrote:
> Hi Vicente,
>
> On 25/02/18 11:03, Vicente Bergas wrote:
>> (cut)
>>>>>>> testing on the Sapphire board, which uses the RK3399 SoC, a regression
>>>>>>> has been found in v4.16-rc2 wrt v4.15.4 regarding the USB3 type-A port:
>>>>>>> In v4.15.4 it works in USB2-only mode.
>>>>>>> In v4.16-rc2 it does not work.
>> (cut)
>>>>>> Hmm, I'd guess the main issue would be a missing typec-phy driver
>>>>>> in your kernel (see drivers/phy/rockchip/phy-rockchip-typec.c
>> (cut)
>>>> I suspect that what Heiko says is right and typec-phy fails probing. Could you
>> (cut)
>>
>> Hello,
>> this is the patch to blame for the regression:
>>
>> From c301b327aea898af558b2387252a2f5fc0117dee Mon Sep 17 00:00:00 2001
>> From: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
>> Date: Fri, 15 Dec 2017 12:00:03 +0100
>> Subject: [PATCH] arm64: dts: rockchip: add usb3-phy otg-port support for rk3399
>>
>> Add the usb3 phyter for the USB3.0 OTG controller.
>>
>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
>> Signed-off-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
>> ---
>>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 8 ++++----
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> index b4511503878b..7aa2144e0d47 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> @@ -411,8 +411,8 @@
>>              reg = <0x0 0xfe800000 0x0 0x100000>;
>>              interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
>>              dr_mode = "otg";
>> -            phys = <&u2phy0_otg>;
>> -            phy-names = "usb2-phy";
>> +            phys = <&u2phy0_otg>, <&tcphy0_usb3>;
>> +            phy-names = "usb2-phy", "usb3-phy";
>>              phy_type = "utmi_wide";
>>              snps,dis_enblslpm_quirk;
>>              snps,dis-u2-freeclk-exists-quirk;
>> @@ -444,8 +444,8 @@
>>              reg = <0x0 0xfe900000 0x0 0x100000>;
>>              interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>;
>>              dr_mode = "otg";
>> -            phys = <&u2phy1_otg>;
>> -            phy-names = "usb2-phy";
>> +            phys = <&u2phy1_otg>, <&tcphy1_usb3>;
>> +            phy-names = "usb2-phy", "usb3-phy";
>>              phy_type = "utmi_wide";
>>              snps,dis_enblslpm_quirk;
>>              snps,dis-u2-freeclk-exists-quirk;
>>
>
> Can you try if the following patch solves the issue for you?

Hi Enric,
with this patch the usb3 type-A port works fine in both usb2-mode and
usb-3 mode!
Now I am getting 350Mbytes/s read bandwidth to the SSD, that's a big
improvement.

Type-C not tested.

Regards,
  Vicente.

> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
> index f7157c1d768b..617d362eb8af 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
> @@ -569,6 +569,14 @@
>         status = "okay";
>  };
>
> +&tcphy0 {
> +       status = "okay";
> +};
> +
> +&tcphy1 {
> +       status = "okay";
> +};
> +
>  &u2phy0 {
>         status = "okay";
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c
> b/drivers/phy/rockchip/phy-rockchip-typec.c
> index 1c79785a5439..6af1ec262fcb 100644
> --- a/drivers/phy/rockchip/phy-rockchip-typec.c
> +++ b/drivers/phy/rockchip/phy-rockchip-typec.c
> @@ -821,6 +821,9 @@ static int tcphy_get_mode(struct rockchip_typec_phy *tcphy)
>         u8 mode;
>         int ret;
>
> +       if (!edev)
> +               return MODE_DFP_USB;
> +
>         ufp = extcon_get_state(edev, EXTCON_USB);
>         dp = extcon_get_state(edev, EXTCON_DISP_DP);
>
> @@ -1159,9 +1162,9 @@ static int rockchip_typec_phy_probe(struct platform_device
> *pdev)
>
>         tcphy->extcon = extcon_get_edev_by_phandle(dev, 0);
>         if (IS_ERR(tcphy->extcon)) {
> -               if (PTR_ERR(tcphy->extcon) != -EPROBE_DEFER)
> -                       dev_err(dev, "Invalid or missing extcon\n");
> -               return PTR_ERR(tcphy->extcon);
> +               if (PTR_ERR(tcphy->extcon) == -EPROBE_DEFER)
> +                       return PTR_ERR(tcphy->extcon);
> +               tcphy->extcon = NULL;
>         }
>
>         pm_runtime_enable(dev);
>
>
> Best regards,
>  Enric

[PATCH 0/4] arm64: dts: Sapphire board: miscelaneous fixes

[Vicente Bergas]

Hi,
i have just tested the USB3 Type-C port on the Sapphire board for the
first time and it did not work.
After some checks i found a few things to improve, hence this patch
series.
Before applying, the USB3 Type-C port is unpowered.
After applying, the port is powered, but no peripherals detected.
Can this issue be related to the missing fusb302 driver in the dts?
Regards,
  Vicenç.

Vicente Bergas (4):
  arm64: dts: Sapphire board: re-order vcc_sys
  arm64: dts: Sapphire board: Fix VCC5V0_HOST_EN
  arm64: dts: Sapphire board has DVS2 disabled
  arm64: dts: Sapphire board: Fix Type-C port supply

 .../boot/dts/rockchip/rk3399-sapphire.dtsi    | 45 +++++++++++--------
 1 file changed, 27 insertions(+), 18 deletions(-)

-- 
2.18.0


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH 1/4] arm64: dts: Sapphire board: re-order vcc_sys

[Vicente Bergas]

Fix alphabetical order.

Signed-off-by: Vicente Bergas <vicencb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 .../boot/dts/rockchip/rk3399-sapphire.dtsi    | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
index 941b62709..dac7c331b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
@@ -140,16 +140,6 @@
 		vin-supply = <&vcc_sys>;
 	};
 
-	vcc_sys: vcc-sys {
-		compatible = "regulator-fixed";
-		regulator-name = "vcc_sys";
-		regulator-always-on;
-		regulator-boot-on;
-		regulator-min-microvolt = <5000000>;
-		regulator-max-microvolt = <5000000>;
-		vin-supply = <&dc_12v>;
-	};
-
 	vcc5v0_host: vcc5v0-host-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
@@ -161,6 +151,16 @@
 		vin-supply = <&vcc_sys>;
 	};
 
+	vcc_sys: vcc-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&dc_12v>;
+	};
+
 	vdd_log: vdd-log {
 		compatible = "pwm-regulator";
 		pwms = <&pwm2 0 25000 1>;
-- 
2.18.0

Re: [PATCH 1/4] arm64: dts: Sapphire board: re-order vcc_sys

[Heiko Stuebner]

Am Samstag, 8. September 2018, 21:00:45 CEST schrieb Vicente Bergas:
> Fix alphabetical order.
> 
> Signed-off-by: Vicente Bergas <vicencb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

applied for 4.20

[PATCH 2/4] arm64: dts: Sapphire board: Fix VCC5V0_HOST_EN

[Vicente Bergas]

The reference is the schematic, page 15:
https://dl.vamrs.com/products/sapphire_excavator/RK_SAPPHIRE_SOCBOARD_RK3399_LPDDR3D178P232SD8_V12_20161109HXS.pdf
(alternate link)
http://opensource.rock-chips.com/images/f/f0/RK_Sapphire_RK3399.rar

Signed-off-by: Vicente Bergas <vicencb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
index dac7c331b..68b497ad3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
@@ -143,7 +143,7 @@
 	vcc5v0_host: vcc5v0-host-regulator {
 		compatible = "regulator-fixed";
 		enable-active-high;
-		gpio = <&gpio1 RK_PD1 GPIO_ACTIVE_HIGH>;
+		gpio = <&gpio4 RK_PD1 GPIO_ACTIVE_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&vcc5v0_host_en>;
 		regulator-name = "vcc5v0_host";
-- 
2.18.0

Re: [PATCH 2/4] arm64: dts: Sapphire board: Fix VCC5V0_HOST_EN

[Heiko Stuebner]

Am Samstag, 8. September 2018, 21:00:46 CEST schrieb Vicente Bergas:
> The reference is the schematic, page 15:
> https://dl.vamrs.com/products/sapphire_excavator/RK_SAPPHIRE_SOCBOARD_RK3399_LPDDR3D178P232SD8_V12_20161109HXS.pdf
> (alternate link)
> http://opensource.rock-chips.com/images/f/f0/RK_Sapphire_RK3399.rar
> 
> Signed-off-by: Vicente Bergas <vicencb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

applied for 4.20

[PATCH 3/4] arm64: dts: Sapphire board has DVS2 disabled

[Vicente Bergas]

The reference is the schematic, page 16:
https://dl.vamrs.com/products/sapphire_excavator/RK_SAPPHIRE_SOCBOARD_RK3399_LPDDR3D178P232SD8_V12_20161109HXS.pdf
(alternate link)
http://opensource.rock-chips.com/images/f/f0/RK_Sapphire_RK3399.rar

Signed-off-by: Vicente Bergas <vicencb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
index 68b497ad3..b1cb50595 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
@@ -241,7 +241,7 @@
 		#clock-cells = <1>;
 		clock-output-names = "xin32k", "rk808-clkout2";
 		pinctrl-names = "default";
-		pinctrl-0 = <&pmic_int_l &pmic_dvs2>;
+		pinctrl-0 = <&pmic_int_l>;
 		rockchip,system-power-controller;
 		wakeup-source;
 
@@ -489,11 +489,6 @@
 				<1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
 		};
 
-		pmic_dvs2: pmic-dvs2 {
-			rockchip,pins =
-				<1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_down>;
-		};
-
 		vsel1_gpio: vsel1-gpio {
 			rockchip,pins = <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_down>;
 		};
-- 
2.18.0

Re: [PATCH 3/4] arm64: dts: Sapphire board has DVS2 disabled

[Heiko Stuebner]

Am Samstag, 8. September 2018, 21:00:47 CEST schrieb Vicente Bergas:
> The reference is the schematic, page 16:
> https://dl.vamrs.com/products/sapphire_excavator/RK_SAPPHIRE_SOCBOARD_RK3399_LPDDR3D178P232SD8_V12_20161109HXS.pdf
> (alternate link)
> http://opensource.rock-chips.com/images/f/f0/RK_Sapphire_RK3399.rar
> 
> Signed-off-by: Vicente Bergas <vicencb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

applied for 4.20

For patches 1-3 I did modify the subject to match the regular scheme
(arm64: dts: rockchip: foo) and added actual words to the commit messages.

Heiko

[PATCH 4/4] arm64: dts: Sapphire board: Fix Type-C port supply

[Vicente Bergas]

The reference is the schematic, page 11:
https://dl.vamrs.com/products/sapphire_excavator/RK_SAPPHIRE_SOCBOARD_RK3399_LPDDR3D178P232SD8_V12_20161109HXS.pdf
(alternate link)
http://opensource.rock-chips.com/images/f/f0/RK_Sapphire_RK3399.rar

Signed-off-by: Vicente Bergas <vicencb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 .../arm64/boot/dts/rockchip/rk3399-sapphire.dtsi | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
index b1cb50595..1188c8717 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
@@ -151,6 +151,16 @@
 		vin-supply = <&vcc_sys>;
 	};
 
+	vcc5v0_typec0: vcc5v0-typec0-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio2 RK_PA0 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_typec0_en>;
+		regulator-name = "vcc5v0_typec0";
+		vin-supply = <&vcc_sys>;
+	};
+
 	vcc_sys: vcc-sys {
 		compatible = "regulator-fixed";
 		regulator-name = "vcc_sys";
@@ -503,6 +513,10 @@
 			rockchip,pins =
 				<4 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
 		};
+		vcc5v0_typec0_en: vcc5v0-typec0-en {
+			rockchip,pins =
+				<2 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
 	};
 };
 
@@ -564,7 +578,7 @@
 	};
 
 	u2phy0_host: host-port {
-		phy-supply = <&vcc5v0_host>;
+		phy-supply = <&vcc5v0_typec0>;
 		status = "okay";
 	};
 };
-- 
2.18.0

Re: [PATCH 4/4] arm64: dts: Sapphire board: Fix Type-C port supply

[Heiko Stuebner]

Am Samstag, 8. September 2018, 21:00:48 CEST schrieb Vicente Bergas:
> The reference is the schematic, page 11:
> https://dl.vamrs.com/products/sapphire_excavator/RK_SAPPHIRE_SOCBOARD_RK3399_LPDDR3D178P232SD8_V12_20161109HXS.pdf
> (alternate link)
> http://opensource.rock-chips.com/images/f/f0/RK_Sapphire_RK3399.rar
> 
> Signed-off-by: Vicente Bergas <vicencb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>  .../arm64/boot/dts/rockchip/rk3399-sapphire.dtsi | 16 +++++++++++++++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
> index b1cb50595..1188c8717 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
> @@ -151,6 +151,16 @@
>  		vin-supply = <&vcc_sys>;
>  	};
>  
> +	vcc5v0_typec0: vcc5v0-typec0-regulator {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio2 RK_PA0 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&vcc5v0_typec0_en>;
> +		regulator-name = "vcc5v0_typec0";
> +		vin-supply = <&vcc_sys>;
> +	};
> +
>  	vcc_sys: vcc-sys {
>  		compatible = "regulator-fixed";
>  		regulator-name = "vcc_sys";
> @@ -503,6 +513,10 @@
>  			rockchip,pins =
>  				<4 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
>  		};
> +		vcc5v0_typec0_en: vcc5v0-typec0-en {
> +			rockchip,pins =
> +				<2 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
>  	};
>  };
>  
> @@ -564,7 +578,7 @@
>  	};
>  
>  	u2phy0_host: host-port {
> -		phy-supply = <&vcc5v0_host>;
> +		phy-supply = <&vcc5v0_typec0>;

Hmm, I'm not sure if that is correct.

Reading schematics and also the phy port assignments, you can see
u2phy0_host being connected to "usb_host0_ehci: usb@fe380000".

So I guess the vcc5v0_host should be the correct one for it?
Did you mean to add the py-supply to u2phy0_otg instead? Which is one
of the ports used by the dwc3?


Heiko

Re: [PATCH 4/4] arm64: dts: Sapphire board: Fix Type-C port supply

[Vicente Bergas]

On Mon, Sep 10, 2018 at 2:23 PM, Heiko Stuebner <heiko@sntech.de> wrote:
> Am Samstag, 8. September 2018, 21:00:48 CEST schrieb Vicente Bergas:
>> The reference is the schematic, page 11:
>> https://dl.vamrs.com/products/sapphire_excavator/RK_SAPPHIRE_SOCBOARD_RK3399_LPDDR3D178P232SD8_V12_20161109HXS.pdf
>> (alternate link)
>> http://opensource.rock-chips.com/images/f/f0/RK_Sapphire_RK3399.rar
>>
>> Signed-off-by: Vicente Bergas <vicencb@gmail.com>
>> ---
>>  .../arm64/boot/dts/rockchip/rk3399-sapphire.dtsi | 16 +++++++++++++++-
>>  1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
>> index b1cb50595..1188c8717 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
>> @@ -151,6 +151,16 @@
>>               vin-supply = <&vcc_sys>;
>>       };
>>
>> +     vcc5v0_typec0: vcc5v0-typec0-regulator {
>> +             compatible = "regulator-fixed";
>> +             enable-active-high;
>> +             gpio = <&gpio2 RK_PA0 GPIO_ACTIVE_HIGH>;
>> +             pinctrl-names = "default";
>> +             pinctrl-0 = <&vcc5v0_typec0_en>;
>> +             regulator-name = "vcc5v0_typec0";
>> +             vin-supply = <&vcc_sys>;
>> +     };
>> +
>>       vcc_sys: vcc-sys {
>>               compatible = "regulator-fixed";
>>               regulator-name = "vcc_sys";
>> @@ -503,6 +513,10 @@
>>                       rockchip,pins =
>>                               <4 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
>>               };
>> +             vcc5v0_typec0_en: vcc5v0-typec0-en {
>> +                     rockchip,pins =
>> +                             <2 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
>> +             };
>>       };
>>  };
>>
>> @@ -564,7 +578,7 @@
>>       };
>>
>>       u2phy0_host: host-port {
>> -             phy-supply = <&vcc5v0_host>;
>> +             phy-supply = <&vcc5v0_typec0>;
>
> Hmm, I'm not sure if that is correct.
>
> Reading schematics and also the phy port assignments, you can see
> u2phy0_host being connected to "usb_host0_ehci: usb@fe380000".
>
> So I guess the vcc5v0_host should be the correct one for it?
> Did you mean to add the py-supply to u2phy0_otg instead? Which is one
> of the ports used by the dwc3?
>
>
> Heiko
>
Hi,
from the schematic these are the connections for the USB ports:

##### PHY0 #####
U1000S is the RK3399 PHY0 used for the USB3 Type-C connector.
The USB3 Type-C connector is the one labeled J8902.
From there, the VBUS pin is connected to the VBUS_TYPEC net.
The VBUS_TYPEC supply is U8905, which has an enable input
  connected to the GPIO2_A0/CIF_D0 net.
The GPIO2_A0/CIF_D0 net is driven by the
  GPIO2_A0/VOP_D0/CIF_D0/I2C2_SDA_u pin of U1000L, which is
  the RK3399.
################

##### PHY1 #####
U1000T is the RK3399 PHY1 used for the USB3 Type-A connector.
The USB3 Type-A connector is the one labeled CON602.
From there, the VBUS pin is connected to the VCC5V0_HOST2 net.
The VCC5V0_HOST2 supply is U1902, which has an enable input
  connected to the VCC5V0_HOST_EN net.
The VCC5V0_HOST_EN net is driven by the
  GPIO4_D1/DP_HOTPLUG_d pin of U1000K, which is the RK3399.
################

So, it is clear that GPIO2_A0 controls the VBUS of PHY0 and
  GPIO4_D1 controls the VBUS of PHY1.

At this point, i am not sure how to translate this information
from the schematic into the DTS. I don't know if it should be
applied to the "otg" or the "host" side as you are suggesting.
But it looks quite clear to me that VCC5V0_HOST(GPIO4_D1) is not
applicaple to the PHY0.

As stated in the email 0/4, this patch only powers-up the Type-C
port, but it is still non-working. So, either this patch is wrong
or more changes are needed like the fusb302.

The reference should be the one from the manufacturer:
https://github.com/rockchip-linux/kernel/blob/release-4.4/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
but it contains the same bugs.

So, any help will be appreciated.

Regards,
  Vicenç.

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH 4/4] arm64: dts: Sapphire board: Fix Type-C port supply

[Heiko Stuebner]

Hi,

Am Montag, 10. September 2018, 15:39:45 CEST schrieb Vicente Bergas:
> On Mon, Sep 10, 2018 at 2:23 PM, Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> wrote:
> > Am Samstag, 8. September 2018, 21:00:48 CEST schrieb Vicente Bergas:
> >> The reference is the schematic, page 11:
> >> https://dl.vamrs.com/products/sapphire_excavator/RK_SAPPHIRE_SOCBOARD_RK3399_LPDDR3D178P232SD8_V12_20161109HXS.pdf
> >> (alternate link)
> >> http://opensource.rock-chips.com/images/f/f0/RK_Sapphire_RK3399.rar
> >>
> >> Signed-off-by: Vicente Bergas <vicencb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> ---
> >>  .../arm64/boot/dts/rockchip/rk3399-sapphire.dtsi | 16 +++++++++++++++-
> >>  1 file changed, 15 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
> >> index b1cb50595..1188c8717 100644
> >> --- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
> >> +++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
> >> @@ -151,6 +151,16 @@
> >>               vin-supply = <&vcc_sys>;
> >>       };
> >>
> >> +     vcc5v0_typec0: vcc5v0-typec0-regulator {
> >> +             compatible = "regulator-fixed";
> >> +             enable-active-high;
> >> +             gpio = <&gpio2 RK_PA0 GPIO_ACTIVE_HIGH>;
> >> +             pinctrl-names = "default";
> >> +             pinctrl-0 = <&vcc5v0_typec0_en>;
> >> +             regulator-name = "vcc5v0_typec0";
> >> +             vin-supply = <&vcc_sys>;
> >> +     };
> >> +
> >>       vcc_sys: vcc-sys {
> >>               compatible = "regulator-fixed";
> >>               regulator-name = "vcc_sys";
> >> @@ -503,6 +513,10 @@
> >>                       rockchip,pins =
> >>                               <4 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
> >>               };
> >> +             vcc5v0_typec0_en: vcc5v0-typec0-en {
> >> +                     rockchip,pins =
> >> +                             <2 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
> >> +             };
> >>       };
> >>  };
> >>
> >> @@ -564,7 +578,7 @@
> >>       };
> >>
> >>       u2phy0_host: host-port {
> >> -             phy-supply = <&vcc5v0_host>;
> >> +             phy-supply = <&vcc5v0_typec0>;
> >
> > Hmm, I'm not sure if that is correct.
> >
> > Reading schematics and also the phy port assignments, you can see
> > u2phy0_host being connected to "usb_host0_ehci: usb@fe380000".
> >
> > So I guess the vcc5v0_host should be the correct one for it?
> > Did you mean to add the py-supply to u2phy0_otg instead? Which is one
> > of the ports used by the dwc3?
> >
> >
> > Heiko
> >
> Hi,
> from the schematic these are the connections for the USB ports:
> 
> ##### PHY0 #####
> U1000S is the RK3399 PHY0 used for the USB3 Type-C connector.
> The USB3 Type-C connector is the one labeled J8902.
> From there, the VBUS pin is connected to the VBUS_TYPEC net.
> The VBUS_TYPEC supply is U8905, which has an enable input
>   connected to the GPIO2_A0/CIF_D0 net.
> The GPIO2_A0/CIF_D0 net is driven by the
>   GPIO2_A0/VOP_D0/CIF_D0/I2C2_SDA_u pin of U1000L, which is
>   the RK3399.
> ################
> 
> ##### PHY1 #####
> U1000T is the RK3399 PHY1 used for the USB3 Type-A connector.
> The USB3 Type-A connector is the one labeled CON602.
> From there, the VBUS pin is connected to the VCC5V0_HOST2 net.
> The VCC5V0_HOST2 supply is U1902, which has an enable input
>   connected to the VCC5V0_HOST_EN net.
> The VCC5V0_HOST_EN net is driven by the
>   GPIO4_D1/DP_HOTPLUG_d pin of U1000K, which is the RK3399.
> ################
> 
> So, it is clear that GPIO2_A0 controls the VBUS of PHY0 and
>   GPIO4_D1 controls the VBUS of PHY1.

You have to account for the fact that each phy has two actual ports.
The host_ports are connected to the ehci/ohci controllers.
	u2phy0_host -> usb_host0_ehci + usb_host0_ohci
	u2phy1_host -> usb_host1_ehci + usb_host1_ohci

while the otg-ports supply the usb2-phy phys of the dwc3 controllers.
	u2phy0_otg -> usbdrd3_0
	u2phy1_otg -> usbdrd3_1

So most likely the usb_host supplies go to the host controllers,
while the otg ports will be the most likely candidate for controlling the
typec power.

> At this point, i am not sure how to translate this information
> from the schematic into the DTS. I don't know if it should be
> applied to the "otg" or the "host" side as you are suggesting.
> But it looks quite clear to me that VCC5V0_HOST(GPIO4_D1) is not
> applicaple to the PHY0.
> 
> As stated in the email 0/4, this patch only powers-up the Type-C
> port, but it is still non-working. So, either this patch is wrong
> or more changes are needed like the fusb302.

In general, you should see activity when connecting devices to the
type-c port ... meaning usb sticks and so on. With recent patches the
typec-phy should switch to host mode if no role detection is possible,
so on any non-ChromeOS device you will currently only get host function.

So I guess your best bet is to try a typec->usb3 adapter and a regular
stick right now.

Heiko

[PATCH v2] arm64: dts: rockchip: Fix Type-C port supply in Sapphire board

[Vicente Bergas]

The reference is the schematic, page 11:
https://dl.vamrs.com/products/sapphire_excavator/RK_SAPPHIRE_SOCBOARD_RK3399_LPDDR3D178P232SD8_V12_20161109HXS.pdf
(alternate link)
http://opensource.rock-chips.com/images/f/f0/RK_Sapphire_RK3399.rar

Changes in v2:
 The power supply is applied to the OTG port.

Signed-off-by: Vicente Bergas <vicencb@gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

Hi Heiko,
your approach makes sense, i just tried it and the Type-C port is
still powered-on, like with the previous patch.
But sadly still no data flow.

I have got a gru/kevin and also bought a USB-C to SATA bridge
for it. The bridge works fine on kevin with kernel 4.4, still not
tested with mainline.

But when plugged into the Sapphire there is an LED that shows it
is powered-on and nothing else. On the linux side, dmesg shows no
messages.

Comparing the USB portion of the DTS wrt Firefly i see no
significant differences.

Are there other Sapphire board users that can confirm if the
Type-C port works or not? That would help to discard a HW issue.

Regards,
  Vicenç.

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
index 941b62709..e1b590ca2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
@@ -140,6 +140,16 @@
 		vin-supply = <&vcc_sys>;
 	};
 
+	vcc5v0_typec0: vcc5v0-typec0-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio2 RK_PA0 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_typec0_en>;
+		regulator-name = "vcc5v0_typec0";
+		vin-supply = <&vcc_sys>;
+	};
+
 	vcc_sys: vcc-sys {
 		compatible = "regulator-fixed";
 		regulator-name = "vcc_sys";
@@ -508,6 +518,10 @@
 			rockchip,pins =
 				<4 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
 		};
+		vcc5v0_typec0_en: vcc5v0-typec0-en {
+			rockchip,pins =
+				<2 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
 	};
 };
 
@@ -565,6 +579,7 @@
 	status = "okay";
 
 	u2phy0_otg: otg-port {
+		phy-supply = <&vcc5v0_typec0>;
 		status = "okay";
 	};
 
-- 
2.18.0


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH v2] arm64: dts: rockchip: Fix Type-C port supply in Sapphire board

[Heiko Stuebner]

Am Montag, 10. September 2018, 18:10:29 CEST schrieb Vicente Bergas:
> The reference is the schematic, page 11:
> https://dl.vamrs.com/products/sapphire_excavator/RK_SAPPHIRE_SOCBOARD_RK3399_LPDDR3D178P232SD8_V12_20161109HXS.pdf
> (alternate link)
> http://opensource.rock-chips.com/images/f/f0/RK_Sapphire_RK3399.rar
> 
> Changes in v2:
>  The power supply is applied to the OTG port.
> 
> Signed-off-by: Vicente Bergas <vicencb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

applied for 4.20


> Hi Heiko,
> your approach makes sense, i just tried it and the Type-C port is
> still powered-on, like with the previous patch.
> But sadly still no data flow.
> 
> I have got a gru/kevin and also bought a USB-C to SATA bridge
> for it. The bridge works fine on kevin with kernel 4.4, still not
> tested with mainline.
> 
> But when plugged into the Sapphire there is an LED that shows it
> is powered-on and nothing else. On the linux side, dmesg shows no
> messages.
> 
> Comparing the USB portion of the DTS wrt Firefly i see no
> significant differences.
> 
> Are there other Sapphire board users that can confirm if the
> Type-C port works or not? That would help to discard a HW issue.

Enric was working on a similar board, maybe he remember some
peculiarities.

Re: [PATCH v2] arm64: dts: rockchip: Fix Type-C port supply in Sapphire board

[Vicente Bergas]

On Monday, September 10, 2018 7:19:20 PM CEST, Heiko Stuebner wrote:
> Am Montag, 10. September 2018, 18:10:29 CEST schrieb Vicente Bergas:
>> The reference is the schematic, page 11:
>> https://dl.vamrs.com/products/sapphire_excavator/RK_SAPPHIRE_SOCBOARD_RK3399_LPDDR3D178P232SD8_V12_20161109HXS.pdf
>> (alternate link)
>> http://opensource.rock-chips.com/images/f/f0/RK_Sapphire_RK3399.rar
>> 
>> Changes in v2:
>>  The power supply is applied to the OTG port.
>> 
>> Signed-off-by: Vicente Bergas <vicencb@gmail.com>
>
> applied for 4.20
>
>
>> Hi Heiko,
>> your approach makes sense, i just tried it and the Type-C port is
>> still powered-on, like with the previous patch.
>> But sadly still no data flow.
>> 
>> I have got a gru/kevin and also bought a USB-C to SATA bridge
>> for it. The bridge works fine on kevin with kernel 4.4, still not
>> tested with mainline.
>> 
>> But when plugged into the Sapphire there is an LED that shows it
>> is powered-on and nothing else. On the linux side, dmesg shows no
>> messages.
>> 
>> Comparing the USB portion of the DTS wrt Firefly i see no
>> significant differences.
>> 
>> Are there other Sapphire board users that can confirm if the
>> Type-C port works or not? That would help to discard a HW issue.
>
> Enric was working on a similar board, maybe he remember some
> peculiarities.

Hi,
i have taken another look at the USB3 Type-C port of the Sapphire board
and made a little bit of progress. Now there is some data transfer, but
still not working.

Applying this patch:
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
@@ -112,6 +111,7 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&vcc5v0_typec0_en>;
 		regulator-name = "vcc5v0_typec0";
+		regulator-always-on;
 		vin-supply = <&vcc_sys>;
 	};
 
and having a memory stick plugged into the port from power-up, the 
following happens:
1.- The memory stick LED lights on and kernel reports:
[    4.782999] scsi 0:0:0:0: Direct-Access     USB      DISK             
PMAP PQ: 0 ANSI: 4
[    5.904580] sd 0:0:0:0: [sdb] 3913344 512-byte logical blocks: (2.00 
GB/1.87 GiB)
[    5.906860] sd 0:0:0:0: [sdb] Write Protect is off
[    5.908973] sd 0:0:0:0: [sdb] Mode Sense: 23 00 00 00
[    5.909122] sd 0:0:0:0: [sdb] No Caching mode page found
[    5.911214] sd 0:0:0:0: [sdb] Assuming drive cache: write through
[    5.951585]  sdb: sdb1
[    5.954816] sd 0:0:0:0: [sdb] Attached SCSI removable disk
2.- 4 seconds later the memory stick LED lights off and kernel reports:
[    9.082822] phy phy-ff770000.syscon:usb2-phy@e450.2: charger = 
USB_DCP_CHARGER
3.- After a minute the kernel reports:
[   71.666761] usb 5-1: USB disconnect, device number 2

The usb vbus is present all the time, so, it does not look
like an issue of the vcc5v0_typec0 regulator.

Please, can you help me debugging this issue?

Regards,
  Vicenç.


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH] arm64: rockchip: dts: sapphire: Fix USB3 Type-C.

[Vicente Bergas]

Before this patch, the Type-C port on the Sapphire board is dead.

Applying only the power supply part of this patch, makes the port work
for about 4 seconds at start-up. This is a sample trace with a memory
stick plugged in:
1.- The memory stick LED lights on and kernel reports:
[    4.782999] scsi 0:0:0:0: Direct-Access USB DISK PMAP PQ: 0 ANSI: 4
[    5.904580] sd 0:0:0:0: [sdb] 3913344 512-byte logical blocks: (2.00 GB/1.87 GiB)
[    5.906860] sd 0:0:0:0: [sdb] Write Protect is off
[    5.908973] sd 0:0:0:0: [sdb] Mode Sense: 23 00 00 00
[    5.909122] sd 0:0:0:0: [sdb] No Caching mode page found
[    5.911214] sd 0:0:0:0: [sdb] Assuming drive cache: write through
[    5.951585]  sdb: sdb1
[    5.954816] sd 0:0:0:0: [sdb] Attached SCSI removable disk
2.- 4 seconds later the memory stick LED lights off and kernel reports:
[    9.082822] phy phy-ff770000.syscon:usb2-phy@e450.2: charger = USB_DCP_CHARGER
3.- After a minute the kernel reports:
[   71.666761] usb 5-1: USB disconnect, device number 2
It has been checked that, although the LED is off, VBUS is present.

Applying the full patch makes it work.
It has only been tested in host mode.

Signed-off-by: Vicente Bergas <vicencb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
index 04623e52ac5d..72000a7b666f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
@@ -112,6 +112,7 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&vcc5v0_typec0_en>;
 		regulator-name = "vcc5v0_typec0";
+		regulator-always-on;
 		vin-supply = <&vcc_sys>;
 	};
 
@@ -565,12 +566,11 @@
 	status = "okay";
 
 	u2phy0_otg: otg-port {
-		phy-supply = <&vcc5v0_typec0>;
 		status = "okay";
 	};
 
 	u2phy0_host: host-port {
-		phy-supply = <&vcc5v0_host>;
+		phy-supply = <&vcc5v0_typec0>;
 		status = "okay";
 	};
 };
@@ -620,7 +620,7 @@
 
 &usbdrd_dwc3_0 {
 	status = "okay";
-	dr_mode = "otg";
+	dr_mode = "host";
 };
 
 &usbdrd3_1 {
-- 
2.21.0

Re: [PATCH] arm64: rockchip: dts: sapphire: Fix USB3 Type-C.

[Heiko Stuebner]

Hi Vicente,

Am Mittwoch, 22. Mai 2019, 17:07:17 CEST schrieb Vicente Bergas:
> Before this patch, the Type-C port on the Sapphire board is dead.
> 
> Applying only the power supply part of this patch, makes the port work
> for about 4 seconds at start-up. This is a sample trace with a memory
> stick plugged in:
> 1.- The memory stick LED lights on and kernel reports:
> [    4.782999] scsi 0:0:0:0: Direct-Access USB DISK PMAP PQ: 0 ANSI: 4
> [    5.904580] sd 0:0:0:0: [sdb] 3913344 512-byte logical blocks: (2.00 GB/1.87 GiB)
> [    5.906860] sd 0:0:0:0: [sdb] Write Protect is off
> [    5.908973] sd 0:0:0:0: [sdb] Mode Sense: 23 00 00 00
> [    5.909122] sd 0:0:0:0: [sdb] No Caching mode page found
> [    5.911214] sd 0:0:0:0: [sdb] Assuming drive cache: write through
> [    5.951585]  sdb: sdb1
> [    5.954816] sd 0:0:0:0: [sdb] Attached SCSI removable disk
> 2.- 4 seconds later the memory stick LED lights off and kernel reports:
> [    9.082822] phy phy-ff770000.syscon:usb2-phy@e450.2: charger = USB_DCP_CHARGER
> 3.- After a minute the kernel reports:
> [   71.666761] usb 5-1: USB disconnect, device number 2
> It has been checked that, although the LED is off, VBUS is present.
> 
> Applying the full patch makes it work.
> It has only been tested in host mode.
> 
> Signed-off-by: Vicente Bergas <vicencb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

having to set the regulator to always-on indicates more an issue
with the phy? Because in theory the phy-driver should just enable the
supplying regulator on power-on.

Like would it work to just add the regulator to the host-port of the
phy without enabling it all the time?

Thanks
Heiko

> ---
>  arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
> index 04623e52ac5d..72000a7b666f 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
> @@ -112,6 +112,7 @@
>  		pinctrl-names = "default";
>  		pinctrl-0 = <&vcc5v0_typec0_en>;
>  		regulator-name = "vcc5v0_typec0";
> +		regulator-always-on;
>  		vin-supply = <&vcc_sys>;
>  	};
>  
> @@ -565,12 +566,11 @@
>  	status = "okay";
>  
>  	u2phy0_otg: otg-port {
> -		phy-supply = <&vcc5v0_typec0>;
>  		status = "okay";
>  	};
>  
>  	u2phy0_host: host-port {
> -		phy-supply = <&vcc5v0_host>;
> +		phy-supply = <&vcc5v0_typec0>;
>  		status = "okay";
>  	};
>  };
> @@ -620,7 +620,7 @@
>  
>  &usbdrd_dwc3_0 {
>  	status = "okay";
> -	dr_mode = "otg";
> +	dr_mode = "host";
>  };
>  
>  &usbdrd3_1 {
>