[PATCH 0/3] ARM: dts: sun4i: USB DRC and voltage-scaling for pcDuino1/2

[PATCH 0/3] ARM: dts: sun4i: USB DRC and voltage-scaling for pcDuino1/2

[Siarhei Siamashka]

Hello,

This brings LinkSprite pcDuino1/2 boards up to date with the latest
kernel features. And the first patch in this set is a bugfix for the
PH3/PH6 pins misuse.

There is currently a single dts file for pcDuino1 and pcDuino2 boards.
They obviously had been designed to be compatible with each other, but
have some minor differences, as can be seen when comparing schematics:
    https://s3.amazonaws.com/pcduino/Hardware/PC+Duino_V01-20130128.pdf
    https://s3.amazonaws.com/pcduino/Hardware/v2/pcDuino_v2_sch.pdf

Siarhei Siamashka (3):
  ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2
  ARM: dts: sun4i: Enable USB DRC on pcDuino1/2
  ARM: dts: sun4i: Add AXP209 PMU regulators for pcDuino1/2

 arch/arm/boot/dts/sun4i-a10-pcduino.dts | 56 +++++++++++++++++++++++++++------
 1 file changed, 46 insertions(+), 10 deletions(-)

-- 
2.4.9

[PATCH 0/3] ARM: dts: sun4i: USB DRC and voltage-scaling for pcDuino1/2

[Siarhei Siamashka]

Hello,

This brings LinkSprite pcDuino1/2 boards up to date with the latest
kernel features. And the first patch in this set is a bugfix for the
PH3/PH6 pins misuse.

There is currently a single dts file for pcDuino1 and pcDuino2 boards.
They obviously had been designed to be compatible with each other, but
have some minor differences, as can be seen when comparing schematics:
    https://s3.amazonaws.com/pcduino/Hardware/PC+Duino_V01-20130128.pdf
    https://s3.amazonaws.com/pcduino/Hardware/v2/pcDuino_v2_sch.pdf

Siarhei Siamashka (3):
  ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2
  ARM: dts: sun4i: Enable USB DRC on pcDuino1/2
  ARM: dts: sun4i: Add AXP209 PMU regulators for pcDuino1/2

 arch/arm/boot/dts/sun4i-a10-pcduino.dts | 56 +++++++++++++++++++++++++++------
 1 file changed, 46 insertions(+), 10 deletions(-)

-- 
2.4.9

[PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2

[Siarhei Siamashka]

The pcDuino1 board does not use any power switches at all for its
two USB host ports and the VBUS pins are always connected to 5V.

The pcDuino2 board uses the RT9701GB power switch for its single
USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
resistor. So that the USB power is still enabled by default even
if nobody bothers to configure the PD2 pin or runs the pcDuino1
firmware.

The current dts file unnecessarily meddles with the PH3 and PH6
pins. But the PH6 pin is available on the J11 expansion header
and may have a better use for other purposes. This patch fixes
the problem and now the PH6 pin can be used with the GPIO sysfs
interface. Tested on a pcDuino2 board and confirmed the voltage
on the PH6 pin with a multimeter:

    echo 230 > /sys/class/gpio/export
    echo "out" > /sys/class/gpio/gpio230/direction
    echo 0 > /sys/class/gpio/gpio230/value
    echo 1 > /sys/class/gpio/gpio230/value

USB still works as expected too.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 arch/arm/boot/dts/sun4i-a10-pcduino.dts | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/arch/arm/boot/dts/sun4i-a10-pcduino.dts b/arch/arm/boot/dts/sun4i-a10-pcduino.dts
index 4e3e1b9..fdc074c 100644
--- a/arch/arm/boot/dts/sun4i-a10-pcduino.dts
+++ b/arch/arm/boot/dts/sun4i-a10-pcduino.dts
@@ -180,14 +180,6 @@
 	};
 };
 
-&reg_usb1_vbus {
-	status = "okay";
-};
-
-&reg_usb2_vbus {
-	status = "okay";
-};
-
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pins_a>;
@@ -195,7 +187,5 @@
 };
 
 &usbphy {
-	usb1_vbus-supply = <&reg_usb1_vbus>;
-	usb2_vbus-supply = <&reg_usb2_vbus>;
 	status = "okay";
 };
-- 
2.4.9

[PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2

[Siarhei Siamashka]

The pcDuino1 board does not use any power switches at all for its
two USB host ports and the VBUS pins are always connected to 5V.

The pcDuino2 board uses the RT9701GB power switch for its single
USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
resistor. So that the USB power is still enabled by default even
if nobody bothers to configure the PD2 pin or runs the pcDuino1
firmware.

The current dts file unnecessarily meddles with the PH3 and PH6
pins. But the PH6 pin is available on the J11 expansion header
and may have a better use for other purposes. This patch fixes
the problem and now the PH6 pin can be used with the GPIO sysfs
interface. Tested on a pcDuino2 board and confirmed the voltage
on the PH6 pin with a multimeter:

    echo 230 > /sys/class/gpio/export
    echo "out" > /sys/class/gpio/gpio230/direction
    echo 0 > /sys/class/gpio/gpio230/value
    echo 1 > /sys/class/gpio/gpio230/value

USB still works as expected too.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
---
 arch/arm/boot/dts/sun4i-a10-pcduino.dts | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/arch/arm/boot/dts/sun4i-a10-pcduino.dts b/arch/arm/boot/dts/sun4i-a10-pcduino.dts
index 4e3e1b9..fdc074c 100644
--- a/arch/arm/boot/dts/sun4i-a10-pcduino.dts
+++ b/arch/arm/boot/dts/sun4i-a10-pcduino.dts
@@ -180,14 +180,6 @@
 	};
 };
 
-&reg_usb1_vbus {
-	status = "okay";
-};
-
-&reg_usb2_vbus {
-	status = "okay";
-};
-
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pins_a>;
@@ -195,7 +187,5 @@
 };
 
 &usbphy {
-	usb1_vbus-supply = <&reg_usb1_vbus>;
-	usb2_vbus-supply = <&reg_usb2_vbus>;
 	status = "okay";
 };
-- 
2.4.9

[PATCH 2/3] ARM: dts: sun4i: Enable USB DRC on pcDuino1/2

[Siarhei Siamashka]

Enable the otg/drc usb controller on the pcDuino1/2 board. Note
that the pcDuino2 FEX file from the vendor contains the following
information:

    [usbc0]
    usb_used = 1
    usb_port_type = 0
    usb_detect_type = 1
    usb_id_gpio = port:PH04<0><1><default><default>
    usb_det_vbus_gpio = port:PH05<0><0><default><default>
    usb_drv_vbus_gpio = port:PD02<1><0><default><0>
    usb_host_init_state = 0

The ID pin is indeed PH4. The PD2 pin can be used to switch power
on/off for the USB Type A receptacle, but it has nothing to do with
the MicroUSB OTG receptacle. The VBUS pin of the MicroUSB receptacle
is always connected to 5V according to the schematics and confirmed
by doing some tests with the device. The PH5 pin is just one of the
pins on the J8 expansion header and has nothing to do with USB OTG.
There is also the PB9 pin labelled as USB0-DRV on the schematics.
This PB9 pin is pulled up and connected to the N_VBUSEN pin of AXP209
PMIC, while the VBUS pin of AXP209 only has a capacitor between it
and the ground (this pin is not used for anything else).

To sum it up. Only the ID pin (PH4) works as expected. And 5V voltage
is always served to the MicroUSB OTG receptacle no matter what is the
state of the PB9/PD2 pins.

This patch has been tested to work fine in a host role with a USB
keyboard connected via an OTG cable. It also works fine in a device
role (cdc_ether) with a regular Micro-B cable connected to a desktop
PC.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 arch/arm/boot/dts/sun4i-a10-pcduino.dts | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-pcduino.dts b/arch/arm/boot/dts/sun4i-a10-pcduino.dts
index fdc074c..c9b9330 100644
--- a/arch/arm/boot/dts/sun4i-a10-pcduino.dts
+++ b/arch/arm/boot/dts/sun4i-a10-pcduino.dts
@@ -164,6 +164,10 @@
 	status = "okay";
 };
 
+&otg_sram {
+	status = "okay";
+};
+
 &pio {
 	led_pins_pcduino: led_pins@0 {
 		allwinner,pins = "PH15", "PH16";
@@ -178,6 +182,13 @@
 		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
 		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
 	};
+
+	usb0_id_detect_pin: usb0_id_detect_pin@0 {
+		allwinner,pins = "PH4";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+	};
 };
 
 &uart0 {
@@ -186,6 +197,14 @@
 	status = "okay";
 };
 
+&usb_otg {
+	dr_mode = "otg";
+	status = "okay";
+};
+
 &usbphy {
+	pinctrl-names = "default";
+	pinctrl-0 = <&usb0_id_detect_pin>;
+	usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
 	status = "okay";
 };
-- 
2.4.9

[PATCH 2/3] ARM: dts: sun4i: Enable USB DRC on pcDuino1/2

[Siarhei Siamashka]

Enable the otg/drc usb controller on the pcDuino1/2 board. Note
that the pcDuino2 FEX file from the vendor contains the following
information:

    [usbc0]
    usb_used = 1
    usb_port_type = 0
    usb_detect_type = 1
    usb_id_gpio = port:PH04<0><1><default><default>
    usb_det_vbus_gpio = port:PH05<0><0><default><default>
    usb_drv_vbus_gpio = port:PD02<1><0><default><0>
    usb_host_init_state = 0

The ID pin is indeed PH4. The PD2 pin can be used to switch power
on/off for the USB Type A receptacle, but it has nothing to do with
the MicroUSB OTG receptacle. The VBUS pin of the MicroUSB receptacle
is always connected to 5V according to the schematics and confirmed
by doing some tests with the device. The PH5 pin is just one of the
pins on the J8 expansion header and has nothing to do with USB OTG.
There is also the PB9 pin labelled as USB0-DRV on the schematics.
This PB9 pin is pulled up and connected to the N_VBUSEN pin of AXP209
PMIC, while the VBUS pin of AXP209 only has a capacitor between it
and the ground (this pin is not used for anything else).

To sum it up. Only the ID pin (PH4) works as expected. And 5V voltage
is always served to the MicroUSB OTG receptacle no matter what is the
state of the PB9/PD2 pins.

This patch has been tested to work fine in a host role with a USB
keyboard connected via an OTG cable. It also works fine in a device
role (cdc_ether) with a regular Micro-B cable connected to a desktop
PC.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
---
 arch/arm/boot/dts/sun4i-a10-pcduino.dts | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-pcduino.dts b/arch/arm/boot/dts/sun4i-a10-pcduino.dts
index fdc074c..c9b9330 100644
--- a/arch/arm/boot/dts/sun4i-a10-pcduino.dts
+++ b/arch/arm/boot/dts/sun4i-a10-pcduino.dts
@@ -164,6 +164,10 @@
 	status = "okay";
 };
 
+&otg_sram {
+	status = "okay";
+};
+
 &pio {
 	led_pins_pcduino: led_pins at 0 {
 		allwinner,pins = "PH15", "PH16";
@@ -178,6 +182,13 @@
 		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
 		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
 	};
+
+	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
+		allwinner,pins = "PH4";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+	};
 };
 
 &uart0 {
@@ -186,6 +197,14 @@
 	status = "okay";
 };
 
+&usb_otg {
+	dr_mode = "otg";
+	status = "okay";
+};
+
 &usbphy {
+	pinctrl-names = "default";
+	pinctrl-0 = <&usb0_id_detect_pin>;
+	usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
 	status = "okay";
 };
-- 
2.4.9

[PATCH 3/3] ARM: dts: sun4i: Add AXP209 PMU regulators for pcDuino1/2

[Siarhei Siamashka]

This allows voltage-scaling with cpufreq-dt. The reliability of
voltage-scaling has been checked by reducing the voltage of all
operating points by 0.025V (for extra safety headroom) and running
libjpeg-turbo decoding tests on 5 pcDuino2 boards. It means that
the standard sun4i voltages should be perfectly fine too.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 arch/arm/boot/dts/sun4i-a10-pcduino.dts | 35 +++++++++++++++++++++++++++++----
 1 file changed, 31 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/sun4i-a10-pcduino.dts b/arch/arm/boot/dts/sun4i-a10-pcduino.dts
index c9b9330..55714d0 100644
--- a/arch/arm/boot/dts/sun4i-a10-pcduino.dts
+++ b/arch/arm/boot/dts/sun4i-a10-pcduino.dts
@@ -104,6 +104,10 @@
 	};
 };
 
+&cpu0 {
+	cpu-supply = <&reg_dcdc2>;
+};
+
 &ehci0 {
 	status = "okay";
 };
@@ -129,12 +133,8 @@
 	status = "okay";
 
 	axp209: pmic@34 {
-		compatible = "x-powers,axp209";
 		reg = <0x34>;
 		interrupts = <0>;
-
-		interrupt-controller;
-		#interrupt-cells = <1>;
 	};
 };
 
@@ -191,6 +191,33 @@
 	};
 };
 
+#include "axp209.dtsi"
+
+&reg_dcdc2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1000000>;
+	regulator-max-microvolt = <1400000>;
+	regulator-name = "vdd-cpu";
+};
+
+&reg_dcdc3 {
+	regulator-always-on;
+	regulator-min-microvolt = <1000000>;
+	regulator-max-microvolt = <1400000>;
+	regulator-name = "vdd-int-dll";
+};
+
+&reg_ldo1 {
+	regulator-name = "vdd-rtc";
+};
+
+&reg_ldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "avcc";
+};
+
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pins_a>;
-- 
2.4.9

[PATCH 3/3] ARM: dts: sun4i: Add AXP209 PMU regulators for pcDuino1/2

[Siarhei Siamashka]

This allows voltage-scaling with cpufreq-dt. The reliability of
voltage-scaling has been checked by reducing the voltage of all
operating points by 0.025V (for extra safety headroom) and running
libjpeg-turbo decoding tests on 5 pcDuino2 boards. It means that
the standard sun4i voltages should be perfectly fine too.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
---
 arch/arm/boot/dts/sun4i-a10-pcduino.dts | 35 +++++++++++++++++++++++++++++----
 1 file changed, 31 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/sun4i-a10-pcduino.dts b/arch/arm/boot/dts/sun4i-a10-pcduino.dts
index c9b9330..55714d0 100644
--- a/arch/arm/boot/dts/sun4i-a10-pcduino.dts
+++ b/arch/arm/boot/dts/sun4i-a10-pcduino.dts
@@ -104,6 +104,10 @@
 	};
 };
 
+&cpu0 {
+	cpu-supply = <&reg_dcdc2>;
+};
+
 &ehci0 {
 	status = "okay";
 };
@@ -129,12 +133,8 @@
 	status = "okay";
 
 	axp209: pmic at 34 {
-		compatible = "x-powers,axp209";
 		reg = <0x34>;
 		interrupts = <0>;
-
-		interrupt-controller;
-		#interrupt-cells = <1>;
 	};
 };
 
@@ -191,6 +191,33 @@
 	};
 };
 
+#include "axp209.dtsi"
+
+&reg_dcdc2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1000000>;
+	regulator-max-microvolt = <1400000>;
+	regulator-name = "vdd-cpu";
+};
+
+&reg_dcdc3 {
+	regulator-always-on;
+	regulator-min-microvolt = <1000000>;
+	regulator-max-microvolt = <1400000>;
+	regulator-name = "vdd-int-dll";
+};
+
+&reg_ldo1 {
+	regulator-name = "vdd-rtc";
+};
+
+&reg_ldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "avcc";
+};
+
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pins_a>;
-- 
2.4.9

Re: [PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2

[Chen-Yu Tsai]

On Mon, Oct 5, 2015 at 2:58 AM, Siarhei Siamashka
<siarhei.siamashka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> The pcDuino1 board does not use any power switches at all for its
> two USB host ports and the VBUS pins are always connected to 5V.
>
> The pcDuino2 board uses the RT9701GB power switch for its single
> USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
> resistor. So that the USB power is still enabled by default even
> if nobody bothers to configure the PD2 pin or runs the pcDuino1
> firmware.

Seems like it would be better if you had a regulator controlled
by PD2. At least can shut down VBUS power when it wants to?

ChenYu

> The current dts file unnecessarily meddles with the PH3 and PH6
> pins. But the PH6 pin is available on the J11 expansion header
> and may have a better use for other purposes. This patch fixes
> the problem and now the PH6 pin can be used with the GPIO sysfs
> interface. Tested on a pcDuino2 board and confirmed the voltage
> on the PH6 pin with a multimeter:
>
>     echo 230 > /sys/class/gpio/export
>     echo "out" > /sys/class/gpio/gpio230/direction
>     echo 0 > /sys/class/gpio/gpio230/value
>     echo 1 > /sys/class/gpio/gpio230/value
>
> USB still works as expected too.
>
> Signed-off-by: Siarhei Siamashka <siarhei.siamashka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>  arch/arm/boot/dts/sun4i-a10-pcduino.dts | 10 ----------
>  1 file changed, 10 deletions(-)

[linux-sunxi] [PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2

[Chen-Yu Tsai]

On Mon, Oct 5, 2015 at 2:58 AM, Siarhei Siamashka
<siarhei.siamashka@gmail.com> wrote:
> The pcDuino1 board does not use any power switches at all for its
> two USB host ports and the VBUS pins are always connected to 5V.
>
> The pcDuino2 board uses the RT9701GB power switch for its single
> USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
> resistor. So that the USB power is still enabled by default even
> if nobody bothers to configure the PD2 pin or runs the pcDuino1
> firmware.

Seems like it would be better if you had a regulator controlled
by PD2. At least can shut down VBUS power when it wants to?

ChenYu

> The current dts file unnecessarily meddles with the PH3 and PH6
> pins. But the PH6 pin is available on the J11 expansion header
> and may have a better use for other purposes. This patch fixes
> the problem and now the PH6 pin can be used with the GPIO sysfs
> interface. Tested on a pcDuino2 board and confirmed the voltage
> on the PH6 pin with a multimeter:
>
>     echo 230 > /sys/class/gpio/export
>     echo "out" > /sys/class/gpio/gpio230/direction
>     echo 0 > /sys/class/gpio/gpio230/value
>     echo 1 > /sys/class/gpio/gpio230/value
>
> USB still works as expected too.
>
> Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
> ---
>  arch/arm/boot/dts/sun4i-a10-pcduino.dts | 10 ----------
>  1 file changed, 10 deletions(-)

Re: [PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2

[Siarhei Siamashka]

On Mon, 5 Oct 2015 09:55:28 +0800
Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:

> On Mon, Oct 5, 2015 at 2:58 AM, Siarhei Siamashka
> <siarhei.siamashka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > The pcDuino1 board does not use any power switches at all for its
> > two USB host ports and the VBUS pins are always connected to 5V.
> >
> > The pcDuino2 board uses the RT9701GB power switch for its single
> > USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
> > resistor. So that the USB power is still enabled by default even
> > if nobody bothers to configure the PD2 pin or runs the pcDuino1
> > firmware.
> 
> Seems like it would be better if you had a regulator controlled
> by PD2. At least can shut down VBUS power when it wants to?

That's a good question.

Describing the regulator controlled by PD2 in the dts file is surely
the right solution for pcDuino2 boards. But in the case of using this
dts for pcDuino1, the kernel would think that it can shut down VBUS
power, while in fact this is not true.

The RT9701GB switch also provides the current limiting feature in
addition to the ability to enable/disable the VBUS power. Probably
this was a real reason why it was added to the board.

Everything boils down to the question whether we want to have a
common dts file for pcDuino1 and pcDuino2 or decide to split them.
Based on the schematics comparison, there do not seem to be any
substantial differences between these boards if we ignore the PD2
pin altogether. LinkSprite says that "Ubuntu images are same for
both pcDuino1 and pcDuino2" at their website:
    http://www.linksprite.com/?page_id=809

And I actually like their decision to have the PD2 pin pulled-up.
If every devboard manufacturer did a similar thing and had USB power
always enabled by default without any need to configure anything (with
or without the possibility to switch it off if necessary), then we
would have a much easier job with generic device-independent bootable
SD card installer images for Allwinner boards:

    http://lists.denx.de/pipermail/u-boot/2015-January/202306.html

    "USB host ports use dedicated pins and only enabling/disabling power
     can be device specific. The missing USB power can be solved by
     using a powered USB hub, which is not very convenient, but
     still a workable solution."

-- 
Best regards,
Siarhei Siamashka

[linux-sunxi] [PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2

[Siarhei Siamashka]

On Mon, 5 Oct 2015 09:55:28 +0800
Chen-Yu Tsai <wens@csie.org> wrote:

> On Mon, Oct 5, 2015 at 2:58 AM, Siarhei Siamashka
> <siarhei.siamashka@gmail.com> wrote:
> > The pcDuino1 board does not use any power switches at all for its
> > two USB host ports and the VBUS pins are always connected to 5V.
> >
> > The pcDuino2 board uses the RT9701GB power switch for its single
> > USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
> > resistor. So that the USB power is still enabled by default even
> > if nobody bothers to configure the PD2 pin or runs the pcDuino1
> > firmware.
> 
> Seems like it would be better if you had a regulator controlled
> by PD2. At least can shut down VBUS power when it wants to?

That's a good question.

Describing the regulator controlled by PD2 in the dts file is surely
the right solution for pcDuino2 boards. But in the case of using this
dts for pcDuino1, the kernel would think that it can shut down VBUS
power, while in fact this is not true.

The RT9701GB switch also provides the current limiting feature in
addition to the ability to enable/disable the VBUS power. Probably
this was a real reason why it was added to the board.

Everything boils down to the question whether we want to have a
common dts file for pcDuino1 and pcDuino2 or decide to split them.
Based on the schematics comparison, there do not seem to be any
substantial differences between these boards if we ignore the PD2
pin altogether. LinkSprite says that "Ubuntu images are same for
both pcDuino1 and pcDuino2" at their website:
    http://www.linksprite.com/?page_id=809

And I actually like their decision to have the PD2 pin pulled-up.
If every devboard manufacturer did a similar thing and had USB power
always enabled by default without any need to configure anything (with
or without the possibility to switch it off if necessary), then we
would have a much easier job with generic device-independent bootable
SD card installer images for Allwinner boards:

    http://lists.denx.de/pipermail/u-boot/2015-January/202306.html

    "USB host ports use dedicated pins and only enabling/disabling power
     can be device specific. The missing USB power can be solved by
     using a powered USB hub, which is not very convenient, but
     still a workable solution."

-- 
Best regards,
Siarhei Siamashka

Re: [PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2

[Siarhei Siamashka]

On Mon, 5 Oct 2015 08:39:40 +0300
Siarhei Siamashka <siarhei.siamashka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On Mon, 5 Oct 2015 09:55:28 +0800
> Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> 
> > On Mon, Oct 5, 2015 at 2:58 AM, Siarhei Siamashka
> > <siarhei.siamashka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > The pcDuino1 board does not use any power switches at all for its
> > > two USB host ports and the VBUS pins are always connected to 5V.
> > >
> > > The pcDuino2 board uses the RT9701GB power switch for its single
> > > USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
> > > resistor. So that the USB power is still enabled by default even
> > > if nobody bothers to configure the PD2 pin or runs the pcDuino1
> > > firmware.
> > 
> > Seems like it would be better if you had a regulator controlled
> > by PD2. At least can shut down VBUS power when it wants to?
> 
> That's a good question.
> 
> Describing the regulator controlled by PD2 in the dts file is surely
> the right solution for pcDuino2 boards. But in the case of using this
> dts for pcDuino1, the kernel would think that it can shut down VBUS
> power, while in fact this is not true.
> 
> The RT9701GB switch also provides the current limiting feature in
> addition to the ability to enable/disable the VBUS power. Probably
> this was a real reason why it was added to the board.
> 
> Everything boils down to the question whether we want to have a
> common dts file for pcDuino1 and pcDuino2 or decide to split them.
> Based on the schematics comparison, there do not seem to be any
> substantial differences between these boards if we ignore the PD2
> pin altogether. LinkSprite says that "Ubuntu images are same for
> both pcDuino1 and pcDuino2" at their website:
>     http://www.linksprite.com/?page_id=809
> 
> And I actually like their decision to have the PD2 pin pulled-up.

I'm not sure if everyone would like this, but the following trick
works. If we configure the PD2 pin as input with pull-down on the SoC
side and read it, then it still reads as 1 on pcDuino2. Which means
that the pull-up is apparently stronger (by how much and whether this
is really reliable is another question). It should read as 0 on
pcDuino1 and we might use this to detect the board type at runtime.

Still it is probably an overkill for just this really minor thing :-)

-- 
Best regards,
Siarhei Siamashka

[linux-sunxi] [PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2

[Siarhei Siamashka]

On Mon, 5 Oct 2015 08:39:40 +0300
Siarhei Siamashka <siarhei.siamashka@gmail.com> wrote:

> On Mon, 5 Oct 2015 09:55:28 +0800
> Chen-Yu Tsai <wens@csie.org> wrote:
> 
> > On Mon, Oct 5, 2015 at 2:58 AM, Siarhei Siamashka
> > <siarhei.siamashka@gmail.com> wrote:
> > > The pcDuino1 board does not use any power switches at all for its
> > > two USB host ports and the VBUS pins are always connected to 5V.
> > >
> > > The pcDuino2 board uses the RT9701GB power switch for its single
> > > USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
> > > resistor. So that the USB power is still enabled by default even
> > > if nobody bothers to configure the PD2 pin or runs the pcDuino1
> > > firmware.
> > 
> > Seems like it would be better if you had a regulator controlled
> > by PD2. At least can shut down VBUS power when it wants to?
> 
> That's a good question.
> 
> Describing the regulator controlled by PD2 in the dts file is surely
> the right solution for pcDuino2 boards. But in the case of using this
> dts for pcDuino1, the kernel would think that it can shut down VBUS
> power, while in fact this is not true.
> 
> The RT9701GB switch also provides the current limiting feature in
> addition to the ability to enable/disable the VBUS power. Probably
> this was a real reason why it was added to the board.
> 
> Everything boils down to the question whether we want to have a
> common dts file for pcDuino1 and pcDuino2 or decide to split them.
> Based on the schematics comparison, there do not seem to be any
> substantial differences between these boards if we ignore the PD2
> pin altogether. LinkSprite says that "Ubuntu images are same for
> both pcDuino1 and pcDuino2" at their website:
>     http://www.linksprite.com/?page_id=809
> 
> And I actually like their decision to have the PD2 pin pulled-up.

I'm not sure if everyone would like this, but the following trick
works. If we configure the PD2 pin as input with pull-down on the SoC
side and read it, then it still reads as 1 on pcDuino2. Which means
that the pull-up is apparently stronger (by how much and whether this
is really reliable is another question). It should read as 0 on
pcDuino1 and we might use this to detect the board type at runtime.

Still it is probably an overkill for just this really minor thing :-)

-- 
Best regards,
Siarhei Siamashka

Re: [PATCH 0/3] ARM: dts: sun4i: USB DRC and voltage-scaling for pcDuino1/2

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

Hi,

On Sun, Oct 04, 2015 at 09:58:45PM +0300, Siarhei Siamashka wrote:
> Hello,
> 
> This brings LinkSprite pcDuino1/2 boards up to date with the latest
> kernel features. And the first patch in this set is a bugfix for the
> PH3/PH6 pins misuse.
> 
> There is currently a single dts file for pcDuino1 and pcDuino2 boards.
> They obviously had been designed to be compatible with each other, but
> have some minor differences, as can be seen when comparing schematics:
>     https://s3.amazonaws.com/pcduino/Hardware/PC+Duino_V01-20130128.pdf
>     https://s3.amazonaws.com/pcduino/Hardware/v2/pcDuino_v2_sch.pdf

Usually, the way we handle this is simply by including just the other
DT that will only hold those differences.

What are those differences exactly ?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 0/3] ARM: dts: sun4i: USB DRC and voltage-scaling for pcDuino1/2

[Maxime Ripard]

Hi,

On Sun, Oct 04, 2015 at 09:58:45PM +0300, Siarhei Siamashka wrote:
> Hello,
> 
> This brings LinkSprite pcDuino1/2 boards up to date with the latest
> kernel features. And the first patch in this set is a bugfix for the
> PH3/PH6 pins misuse.
> 
> There is currently a single dts file for pcDuino1 and pcDuino2 boards.
> They obviously had been designed to be compatible with each other, but
> have some minor differences, as can be seen when comparing schematics:
>     https://s3.amazonaws.com/pcduino/Hardware/PC+Duino_V01-20130128.pdf
>     https://s3.amazonaws.com/pcduino/Hardware/v2/pcDuino_v2_sch.pdf

Usually, the way we handle this is simply by including just the other
DT that will only hold those differences.

What are those differences exactly ?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151005/cc585a0a/attachment.sig>

Re: [PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]

On Mon, Oct 05, 2015 at 08:39:40AM +0300, Siarhei Siamashka wrote:
> On Mon, 5 Oct 2015 09:55:28 +0800
> Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> 
> > On Mon, Oct 5, 2015 at 2:58 AM, Siarhei Siamashka
> > <siarhei.siamashka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > The pcDuino1 board does not use any power switches at all for its
> > > two USB host ports and the VBUS pins are always connected to 5V.
> > >
> > > The pcDuino2 board uses the RT9701GB power switch for its single
> > > USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
> > > resistor. So that the USB power is still enabled by default even
> > > if nobody bothers to configure the PD2 pin or runs the pcDuino1
> > > firmware.
> > 
> > Seems like it would be better if you had a regulator controlled
> > by PD2. At least can shut down VBUS power when it wants to?
> 
> That's a good question.
> 
> Describing the regulator controlled by PD2 in the dts file is surely
> the right solution for pcDuino2 boards. But in the case of using this
> dts for pcDuino1, the kernel would think that it can shut down VBUS
> power, while in fact this is not true.

I do agree that this is the right solution for the pcduino1, but it's
definitely not the right one for the pcduino 2 then.

Declaring this as a regulator isn't just meant for the USB to be
working, it's also meant so that it keeps working. If the pin is not
claimed by anyone, the userspace and / or some other driver, will
actually be able to grab that pin and do whatever it wants with it,
effectively fiddling with the VBUS supply behind the USB driver's
back.

It also allows to disable the regulator if VBUS isn't going to be
used, for example because the driver has not be compiled in, or that
it's actually a module that might (or might not) be loaded later.

Finally, it also allows to keep track of who consumes what amount of
power in the system, which is a nice plus.

> The RT9701GB switch also provides the current limiting feature in
> addition to the ability to enable/disable the VBUS power. Probably
> this was a real reason why it was added to the board.
> 
> Everything boils down to the question whether we want to have a
> common dts file for pcDuino1 and pcDuino2 or decide to split them.

You don't have to split them, if this is really the only difference,
just create a new dts for the pcduino2 that includes the first one,
and add the supply there.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[linux-sunxi] [PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2

[Maxime Ripard]

On Mon, Oct 05, 2015 at 08:39:40AM +0300, Siarhei Siamashka wrote:
> On Mon, 5 Oct 2015 09:55:28 +0800
> Chen-Yu Tsai <wens@csie.org> wrote:
> 
> > On Mon, Oct 5, 2015 at 2:58 AM, Siarhei Siamashka
> > <siarhei.siamashka@gmail.com> wrote:
> > > The pcDuino1 board does not use any power switches at all for its
> > > two USB host ports and the VBUS pins are always connected to 5V.
> > >
> > > The pcDuino2 board uses the RT9701GB power switch for its single
> > > USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
> > > resistor. So that the USB power is still enabled by default even
> > > if nobody bothers to configure the PD2 pin or runs the pcDuino1
> > > firmware.
> > 
> > Seems like it would be better if you had a regulator controlled
> > by PD2. At least can shut down VBUS power when it wants to?
> 
> That's a good question.
> 
> Describing the regulator controlled by PD2 in the dts file is surely
> the right solution for pcDuino2 boards. But in the case of using this
> dts for pcDuino1, the kernel would think that it can shut down VBUS
> power, while in fact this is not true.

I do agree that this is the right solution for the pcduino1, but it's
definitely not the right one for the pcduino 2 then.

Declaring this as a regulator isn't just meant for the USB to be
working, it's also meant so that it keeps working. If the pin is not
claimed by anyone, the userspace and / or some other driver, will
actually be able to grab that pin and do whatever it wants with it,
effectively fiddling with the VBUS supply behind the USB driver's
back.

It also allows to disable the regulator if VBUS isn't going to be
used, for example because the driver has not be compiled in, or that
it's actually a module that might (or might not) be loaded later.

Finally, it also allows to keep track of who consumes what amount of
power in the system, which is a nice plus.

> The RT9701GB switch also provides the current limiting feature in
> addition to the ability to enable/disable the VBUS power. Probably
> this was a real reason why it was added to the board.
> 
> Everything boils down to the question whether we want to have a
> common dts file for pcDuino1 and pcDuino2 or decide to split them.

You don't have to split them, if this is really the only difference,
just create a new dts for the pcduino2 that includes the first one,
and add the supply there.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151005/3159b90f/attachment.sig>

Re: [PATCH 3/3] ARM: dts: sun4i: Add AXP209 PMU regulators for pcDuino1/2

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

On Sun, Oct 04, 2015 at 09:58:48PM +0300, Siarhei Siamashka wrote:
> This allows voltage-scaling with cpufreq-dt. The reliability of
> voltage-scaling has been checked by reducing the voltage of all
> operating points by 0.025V (for extra safety headroom) and running
> libjpeg-turbo decoding tests on 5 pcDuino2 boards. It means that
> the standard sun4i voltages should be perfectly fine too.
> 
> Signed-off-by: Siarhei Siamashka <siarhei.siamashka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Applied, thanks!

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 3/3] ARM: dts: sun4i: Add AXP209 PMU regulators for pcDuino1/2

[Maxime Ripard]

On Sun, Oct 04, 2015 at 09:58:48PM +0300, Siarhei Siamashka wrote:
> This allows voltage-scaling with cpufreq-dt. The reliability of
> voltage-scaling has been checked by reducing the voltage of all
> operating points by 0.025V (for extra safety headroom) and running
> libjpeg-turbo decoding tests on 5 pcDuino2 boards. It means that
> the standard sun4i voltages should be perfectly fine too.
> 
> Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Applied, thanks!

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151005/76e13837/attachment.sig>

Re: [PATCH 0/3] ARM: dts: sun4i: USB DRC and voltage-scaling for pcDuino1/2

[Siarhei Siamashka]

On Mon, 5 Oct 2015 14:38:48 +0200
Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:

> Hi,
> 
> On Sun, Oct 04, 2015 at 09:58:45PM +0300, Siarhei Siamashka wrote:
> > Hello,
> > 
> > This brings LinkSprite pcDuino1/2 boards up to date with the latest
> > kernel features. And the first patch in this set is a bugfix for the
> > PH3/PH6 pins misuse.
> > 
> > There is currently a single dts file for pcDuino1 and pcDuino2 boards.
> > They obviously had been designed to be compatible with each other, but
> > have some minor differences, as can be seen when comparing schematics:
> >     https://s3.amazonaws.com/pcduino/Hardware/PC+Duino_V01-20130128.pdf
> >     https://s3.amazonaws.com/pcduino/Hardware/v2/pcDuino_v2_sch.pdf
> 
> Usually, the way we handle this is simply by including just the other
> DT that will only hold those differences.
> 
> What are those differences exactly ?

For the exact differences, one might look into the pdf schematics
files (that's why I have provided links). But a short summary is
the following:

* pcDuino1 has two USB host receptacles, but pcDuino2 has one USB host
  receptacle and a USB WIFI chip.
* There is this difference with the USB_EN pin (PD2), which controls
  a USB power switch in pcDuino2. There is no USB power switch in
  pcDuino1 and the PD2 pin is apparently only connected to a test
  point on the PCB.
* The SZQ resistor is different, which might mean different DDR3
  tracks routing.
* The Ethernet transceiver is different (RTL8201CP in pcDuino1 and
  IP101A_LF in pcDuino2).
* An extra LED is connected to the WIFI chip, but can't be accessed
  in any other way.

Other than the PD2 pin, nothing else seems to be really relevant
to the dts file. And even the PD2 pin is pulled-up in pcDuino2,
making the USB host port powered by default just like in pcDuino1.

-- 
Best regards,
Siarhei Siamashka

[PATCH 0/3] ARM: dts: sun4i: USB DRC and voltage-scaling for pcDuino1/2

[Siarhei Siamashka]

On Mon, 5 Oct 2015 14:38:48 +0200
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:

> Hi,
> 
> On Sun, Oct 04, 2015 at 09:58:45PM +0300, Siarhei Siamashka wrote:
> > Hello,
> > 
> > This brings LinkSprite pcDuino1/2 boards up to date with the latest
> > kernel features. And the first patch in this set is a bugfix for the
> > PH3/PH6 pins misuse.
> > 
> > There is currently a single dts file for pcDuino1 and pcDuino2 boards.
> > They obviously had been designed to be compatible with each other, but
> > have some minor differences, as can be seen when comparing schematics:
> >     https://s3.amazonaws.com/pcduino/Hardware/PC+Duino_V01-20130128.pdf
> >     https://s3.amazonaws.com/pcduino/Hardware/v2/pcDuino_v2_sch.pdf
> 
> Usually, the way we handle this is simply by including just the other
> DT that will only hold those differences.
> 
> What are those differences exactly ?

For the exact differences, one might look into the pdf schematics
files (that's why I have provided links). But a short summary is
the following:

* pcDuino1 has two USB host receptacles, but pcDuino2 has one USB host
  receptacle and a USB WIFI chip.
* There is this difference with the USB_EN pin (PD2), which controls
  a USB power switch in pcDuino2. There is no USB power switch in
  pcDuino1 and the PD2 pin is apparently only connected to a test
  point on the PCB.
* The SZQ resistor is different, which might mean different DDR3
  tracks routing.
* The Ethernet transceiver is different (RTL8201CP in pcDuino1 and
  IP101A_LF in pcDuino2).
* An extra LED is connected to the WIFI chip, but can't be accessed
  in any other way.

Other than the PD2 pin, nothing else seems to be really relevant
to the dts file. And even the PD2 pin is pulled-up in pcDuino2,
making the USB host port powered by default just like in pcDuino1.

-- 
Best regards,
Siarhei Siamashka

Re: [PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2

[Siarhei Siamashka]

On Mon, 5 Oct 2015 14:49:49 +0200
Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:

> On Mon, Oct 05, 2015 at 08:39:40AM +0300, Siarhei Siamashka wrote:
> > On Mon, 5 Oct 2015 09:55:28 +0800
> > Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> > 
> > > On Mon, Oct 5, 2015 at 2:58 AM, Siarhei Siamashka
> > > <siarhei.siamashka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > The pcDuino1 board does not use any power switches at all for its
> > > > two USB host ports and the VBUS pins are always connected to 5V.
> > > >
> > > > The pcDuino2 board uses the RT9701GB power switch for its single
> > > > USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
> > > > resistor. So that the USB power is still enabled by default even
> > > > if nobody bothers to configure the PD2 pin or runs the pcDuino1
> > > > firmware.
> > > 
> > > Seems like it would be better if you had a regulator controlled
> > > by PD2. At least can shut down VBUS power when it wants to?
> > 
> > That's a good question.
> > 
> > Describing the regulator controlled by PD2 in the dts file is surely
> > the right solution for pcDuino2 boards. But in the case of using this
> > dts for pcDuino1, the kernel would think that it can shut down VBUS
> > power, while in fact this is not true.
> 
> I do agree that this is the right solution for the pcduino1, but it's
> definitely not the right one for the pcduino 2 then.
> 
> Declaring this as a regulator isn't just meant for the USB to be
> working, it's also meant so that it keeps working. If the pin is not
> claimed by anyone, the userspace and / or some other driver, will
> actually be able to grab that pin and do whatever it wants with it,
> effectively fiddling with the VBUS supply behind the USB driver's
> back.

OK. That's a very good point.

> It also allows to disable the regulator if VBUS isn't going to be
> used, for example because the driver has not be compiled in, or that
> it's actually a module that might (or might not) be loaded later.
> 
> Finally, it also allows to keep track of who consumes what amount of
> power in the system, which is a nice plus.
>
> > The RT9701GB switch also provides the current limiting feature in
> > addition to the ability to enable/disable the VBUS power. Probably
> > this was a real reason why it was added to the board.
> > 
> > Everything boils down to the question whether we want to have a
> > common dts file for pcDuino1 and pcDuino2 or decide to split them.
> 
> You don't have to split them, if this is really the only difference,
> just create a new dts for the pcduino2 that includes the first one,
> and add the supply there.

Well, we get two dts files instead of one as the end result. If "split"
is not a good description, then I should have probably used a different
word for it.

I don't mind having separate dts files for pcDuino1 and pcDuino2.
What are we going to do with testing on pcDuino1? I only have
pcDuino2 hardware myself.

-- 
Best regards,
Siarhei Siamashka

[linux-sunxi] [PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2

[Siarhei Siamashka]

On Mon, 5 Oct 2015 14:49:49 +0200
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:

> On Mon, Oct 05, 2015 at 08:39:40AM +0300, Siarhei Siamashka wrote:
> > On Mon, 5 Oct 2015 09:55:28 +0800
> > Chen-Yu Tsai <wens@csie.org> wrote:
> > 
> > > On Mon, Oct 5, 2015 at 2:58 AM, Siarhei Siamashka
> > > <siarhei.siamashka@gmail.com> wrote:
> > > > The pcDuino1 board does not use any power switches at all for its
> > > > two USB host ports and the VBUS pins are always connected to 5V.
> > > >
> > > > The pcDuino2 board uses the RT9701GB power switch for its single
> > > > USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
> > > > resistor. So that the USB power is still enabled by default even
> > > > if nobody bothers to configure the PD2 pin or runs the pcDuino1
> > > > firmware.
> > > 
> > > Seems like it would be better if you had a regulator controlled
> > > by PD2. At least can shut down VBUS power when it wants to?
> > 
> > That's a good question.
> > 
> > Describing the regulator controlled by PD2 in the dts file is surely
> > the right solution for pcDuino2 boards. But in the case of using this
> > dts for pcDuino1, the kernel would think that it can shut down VBUS
> > power, while in fact this is not true.
> 
> I do agree that this is the right solution for the pcduino1, but it's
> definitely not the right one for the pcduino 2 then.
> 
> Declaring this as a regulator isn't just meant for the USB to be
> working, it's also meant so that it keeps working. If the pin is not
> claimed by anyone, the userspace and / or some other driver, will
> actually be able to grab that pin and do whatever it wants with it,
> effectively fiddling with the VBUS supply behind the USB driver's
> back.

OK. That's a very good point.

> It also allows to disable the regulator if VBUS isn't going to be
> used, for example because the driver has not be compiled in, or that
> it's actually a module that might (or might not) be loaded later.
> 
> Finally, it also allows to keep track of who consumes what amount of
> power in the system, which is a nice plus.
>
> > The RT9701GB switch also provides the current limiting feature in
> > addition to the ability to enable/disable the VBUS power. Probably
> > this was a real reason why it was added to the board.
> > 
> > Everything boils down to the question whether we want to have a
> > common dts file for pcDuino1 and pcDuino2 or decide to split them.
> 
> You don't have to split them, if this is really the only difference,
> just create a new dts for the pcduino2 that includes the first one,
> and add the supply there.

Well, we get two dts files instead of one as the end result. If "split"
is not a good description, then I should have probably used a different
word for it.

I don't mind having separate dts files for pcDuino1 and pcDuino2.
What are we going to do with testing on pcDuino1? I only have
pcDuino2 hardware myself.

-- 
Best regards,
Siarhei Siamashka

Re: [PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2

[Siarhei Siamashka]

On Mon, 5 Oct 2015 08:58:53 +0300
Siarhei Siamashka <siarhei.siamashka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On Mon, 5 Oct 2015 08:39:40 +0300
> Siarhei Siamashka <siarhei.siamashka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
> > On Mon, 5 Oct 2015 09:55:28 +0800
> > Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> > 
> > > On Mon, Oct 5, 2015 at 2:58 AM, Siarhei Siamashka
> > > <siarhei.siamashka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > The pcDuino1 board does not use any power switches at all for its
> > > > two USB host ports and the VBUS pins are always connected to 5V.
> > > >
> > > > The pcDuino2 board uses the RT9701GB power switch for its single
> > > > USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
> > > > resistor. So that the USB power is still enabled by default even
> > > > if nobody bothers to configure the PD2 pin or runs the pcDuino1
> > > > firmware.
> > > 
> > > Seems like it would be better if you had a regulator controlled
> > > by PD2. At least can shut down VBUS power when it wants to?
> > 
> > That's a good question.
> > 
> > Describing the regulator controlled by PD2 in the dts file is surely
> > the right solution for pcDuino2 boards. But in the case of using this
> > dts for pcDuino1, the kernel would think that it can shut down VBUS
> > power, while in fact this is not true.
> > 
> > The RT9701GB switch also provides the current limiting feature in
> > addition to the ability to enable/disable the VBUS power. Probably
> > this was a real reason why it was added to the board.
> > 
> > Everything boils down to the question whether we want to have a
> > common dts file for pcDuino1 and pcDuino2 or decide to split them.
> > Based on the schematics comparison, there do not seem to be any
> > substantial differences between these boards if we ignore the PD2
> > pin altogether. LinkSprite says that "Ubuntu images are same for
> > both pcDuino1 and pcDuino2" at their website:
> >     http://www.linksprite.com/?page_id=809
> > 
> > And I actually like their decision to have the PD2 pin pulled-up.
> 
> I'm not sure if everyone would like this, but the following trick
> works. If we configure the PD2 pin as input with pull-down on the SoC
> side and read it, then it still reads as 1 on pcDuino2. Which means
> that the pull-up is apparently stronger (by how much and whether this
> is really reliable is another question). It should read as 0 on
> pcDuino1 and we might use this to detect the board type at runtime.
> 
> Still it is probably an overkill for just this really minor thing :-)

I few more details about this. I have actually measured the voltage
with/without pull-down on the SoC side (which competes with the 10K
pull-up resistor on the PCB) and the results are the following. The
voltage drops from 3.306V to 3.187V on one board and from 3.325V to
3.204V on another. Based on these numbers, we can in estimate
pull-down resistors used for GPIO inside of the A10 SoC as something
like ~270K Ohm.

As such, it looks like we can do reliable runtime detection of
pcDuino1 and pcDuino2 variants by probing this PD2 pin. The most
appropriate place to do the runtime detection is probably the board
type selection stub (sunxi-bootsetup), run as the initial part of
a Linux distribution installer. We are perfectly fine having
separate dts files for the pcDuino1/pcDuino2 boards and the
kernel does not need to become more complicated.

Probing for pull-up and pull-down resistors on the PCB can be
generalized beyond just PD2 and used to further narrow down the
selection of compatible boards (sunxi-bootsetup currently only
considers the SoC type, DRAM size and DRAM bus width for this).

Additional very interesting observation is that the reference
Allwinner schematics and Cubieboard/Cubietruck boards use 510K
pull-down resistor for the USB power switches. With 270K pull-up
by the SoC and 510K pull-down by a resistor on the PCB, the
resulting voltage is going to be around ~2.2V, which should be
enough to be interpreted as digital 1. And indeed, a quick test
shows that if we just configure either PH3 or PH6 pin as input
with pull-up, then the corresponding USB port gets powered up
on the Cubieboard :-)

There are two important consequences:
* As far as generic device independent code is concerned, we can
  reasonably safely enable USB power on the Cubieboard, Cubietruck
  and other device, which did not deviate from the reference
  Allwinner schematics and used 510K pull-down resistors. Configuring
  pins for input can't possibly do much harm (if any at all).
* By doing run-time checks, we can see the difference between the
  boards using 10K pull-down resistors (OLIMEX boards) and the boards
  using 510K pull-down resistors (CubieTech boards).

-- 
Best regards,
Siarhei Siamashka

[linux-sunxi] [PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2

[Siarhei Siamashka]

On Mon, 5 Oct 2015 08:58:53 +0300
Siarhei Siamashka <siarhei.siamashka@gmail.com> wrote:

> On Mon, 5 Oct 2015 08:39:40 +0300
> Siarhei Siamashka <siarhei.siamashka@gmail.com> wrote:
> 
> > On Mon, 5 Oct 2015 09:55:28 +0800
> > Chen-Yu Tsai <wens@csie.org> wrote:
> > 
> > > On Mon, Oct 5, 2015 at 2:58 AM, Siarhei Siamashka
> > > <siarhei.siamashka@gmail.com> wrote:
> > > > The pcDuino1 board does not use any power switches at all for its
> > > > two USB host ports and the VBUS pins are always connected to 5V.
> > > >
> > > > The pcDuino2 board uses the RT9701GB power switch for its single
> > > > USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
> > > > resistor. So that the USB power is still enabled by default even
> > > > if nobody bothers to configure the PD2 pin or runs the pcDuino1
> > > > firmware.
> > > 
> > > Seems like it would be better if you had a regulator controlled
> > > by PD2. At least can shut down VBUS power when it wants to?
> > 
> > That's a good question.
> > 
> > Describing the regulator controlled by PD2 in the dts file is surely
> > the right solution for pcDuino2 boards. But in the case of using this
> > dts for pcDuino1, the kernel would think that it can shut down VBUS
> > power, while in fact this is not true.
> > 
> > The RT9701GB switch also provides the current limiting feature in
> > addition to the ability to enable/disable the VBUS power. Probably
> > this was a real reason why it was added to the board.
> > 
> > Everything boils down to the question whether we want to have a
> > common dts file for pcDuino1 and pcDuino2 or decide to split them.
> > Based on the schematics comparison, there do not seem to be any
> > substantial differences between these boards if we ignore the PD2
> > pin altogether. LinkSprite says that "Ubuntu images are same for
> > both pcDuino1 and pcDuino2" at their website:
> >     http://www.linksprite.com/?page_id=809
> > 
> > And I actually like their decision to have the PD2 pin pulled-up.
> 
> I'm not sure if everyone would like this, but the following trick
> works. If we configure the PD2 pin as input with pull-down on the SoC
> side and read it, then it still reads as 1 on pcDuino2. Which means
> that the pull-up is apparently stronger (by how much and whether this
> is really reliable is another question). It should read as 0 on
> pcDuino1 and we might use this to detect the board type at runtime.
> 
> Still it is probably an overkill for just this really minor thing :-)

I few more details about this. I have actually measured the voltage
with/without pull-down on the SoC side (which competes with the 10K
pull-up resistor on the PCB) and the results are the following. The
voltage drops from 3.306V to 3.187V on one board and from 3.325V to
3.204V on another. Based on these numbers, we can in estimate
pull-down resistors used for GPIO inside of the A10 SoC as something
like ~270K Ohm.

As such, it looks like we can do reliable runtime detection of
pcDuino1 and pcDuino2 variants by probing this PD2 pin. The most
appropriate place to do the runtime detection is probably the board
type selection stub (sunxi-bootsetup), run as the initial part of
a Linux distribution installer. We are perfectly fine having
separate dts files for the pcDuino1/pcDuino2 boards and the
kernel does not need to become more complicated.

Probing for pull-up and pull-down resistors on the PCB can be
generalized beyond just PD2 and used to further narrow down the
selection of compatible boards (sunxi-bootsetup currently only
considers the SoC type, DRAM size and DRAM bus width for this).

Additional very interesting observation is that the reference
Allwinner schematics and Cubieboard/Cubietruck boards use 510K
pull-down resistor for the USB power switches. With 270K pull-up
by the SoC and 510K pull-down by a resistor on the PCB, the
resulting voltage is going to be around ~2.2V, which should be
enough to be interpreted as digital 1. And indeed, a quick test
shows that if we just configure either PH3 or PH6 pin as input
with pull-up, then the corresponding USB port gets powered up
on the Cubieboard :-)

There are two important consequences:
* As far as generic device independent code is concerned, we can
  reasonably safely enable USB power on the Cubieboard, Cubietruck
  and other device, which did not deviate from the reference
  Allwinner schematics and used 510K pull-down resistors. Configuring
  pins for input can't possibly do much harm (if any at all).
* By doing run-time checks, we can see the difference between the
  boards using 10K pull-down resistors (OLIMEX boards) and the boards
  using 510K pull-down resistors (CubieTech boards).

-- 
Best regards,
Siarhei Siamashka