diff mbox

[4/5] ARM: dts: sun5i: Add dts file for the Empire Electronix D709 tablet

Message ID 1450611782-9494-4-git-send-email-hdegoede@redhat.com (mailing list archive)
State New, archived
Headers show

Commit Message

Hans de Goede Dec. 20, 2015, 11:43 a.m. UTC
The Empire Electronix D709 tablet is a fairly standard 7" A13 tablet,
featuring usb-wifi, a micro-sd slot, micro-usb otg and headphone jack.

Empire Electronix is written on the back of the tablet, the D709 model
info can be found in the about tablet menu in android.

The PCB has no markings to speak of.

This dts file does not add support for the ft5x touchscreen found at
i2c bus 1, addr 0x38, irq PG11, because it does not work out of the box.
It seems it has been flashed with the wrong firmware and needs to have
alternative firmware uploaded at boot to make the touchscreen work
properly, when hot-booting from android into an upstream kernel the
touchscreen does work.

The Memsic MXC622X accelerometer at i2c bus 1, addr 0x15 also is not
enabled as there is no driver for it.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 arch/arm/boot/dts/Makefile                         |   1 +
 .../boot/dts/sun5i-a13-empire-electronix-d709.dts  | 241 +++++++++++++++++++++
 2 files changed, 242 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts

Comments

Chen-Yu Tsai Dec. 21, 2015, 6:09 a.m. UTC | #1
Hi,

On Sun, Dec 20, 2015 at 7:43 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> The Empire Electronix D709 tablet is a fairly standard 7" A13 tablet,
> featuring usb-wifi, a micro-sd slot, micro-usb otg and headphone jack.
>
> Empire Electronix is written on the back of the tablet, the D709 model
> info can be found in the about tablet menu in android.
>
> The PCB has no markings to speak of.
>
> This dts file does not add support for the ft5x touchscreen found at
> i2c bus 1, addr 0x38, irq PG11, because it does not work out of the box.
> It seems it has been flashed with the wrong firmware and needs to have
> alternative firmware uploaded at boot to make the touchscreen work
> properly, when hot-booting from android into an upstream kernel the
> touchscreen does work.
>
> The Memsic MXC622X accelerometer at i2c bus 1, addr 0x15 also is not
> enabled as there is no driver for it.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>  arch/arm/boot/dts/Makefile                         |   1 +
>  .../boot/dts/sun5i-a13-empire-electronix-d709.dts  | 241 +++++++++++++++++++++

The contents seem the same as sun5i-q8-common.dtsi and sun5i-a13-q8-tablet.dts.
Any chance you could use those instead?

On the side, any thoughts on how to handle the differences between various "Q8"
tablets, like different I2C-based sensors and WiFi chips?

I'm asking because with Maxime's couple-regulator we should be able to get the
RTL8723BS on the Q8 A23/33 v1.5 working.

Regards
ChenYu

>  2 files changed, 242 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
Hans de Goede Dec. 21, 2015, 10:46 a.m. UTC | #2
Hi,

On 21-12-15 07:09, Chen-Yu Tsai wrote:
> Hi,
>
> On Sun, Dec 20, 2015 at 7:43 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> The Empire Electronix D709 tablet is a fairly standard 7" A13 tablet,
>> featuring usb-wifi, a micro-sd slot, micro-usb otg and headphone jack.
>>
>> Empire Electronix is written on the back of the tablet, the D709 model
>> info can be found in the about tablet menu in android.
>>
>> The PCB has no markings to speak of.
>>
>> This dts file does not add support for the ft5x touchscreen found at
>> i2c bus 1, addr 0x38, irq PG11, because it does not work out of the box.
>> It seems it has been flashed with the wrong firmware and needs to have
>> alternative firmware uploaded at boot to make the touchscreen work
>> properly, when hot-booting from android into an upstream kernel the
>> touchscreen does work.
>>
>> The Memsic MXC622X accelerometer at i2c bus 1, addr 0x15 also is not
>> enabled as there is no driver for it.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>>   arch/arm/boot/dts/Makefile                         |   1 +
>>   .../boot/dts/sun5i-a13-empire-electronix-d709.dts  | 241 +++++++++++++++++++++
>
> The contents seem the same as sun5i-q8-common.dtsi and sun5i-a13-q8-tablet.dts.
> Any chance you could use those instead?

Given the special needs of the touchscreen I do not think that that is a good idea.

> On the side, any thoughts on how to handle the differences between various "Q8"
> tablets, like different I2C-based sensors and WiFi chips?

For i2c based sensors the plan is to use devicetree overlays + an in kernel
overlay manager which probes the i2c bus (checking known touchscreen / accelerometer
addresses) and then picks the right touchscreen + accelerometer overlays.

Wifi is somewhat more tricky I must admit, esp. since there seem to be q8 a23 based
tablet variants with usb wifi and others with sdio wifi. Since both busses are
discoverable I'm tempted to just enable both in devicetree, and let the kernel probe
and see what is actually there. This assume that the way the wifichip is powered
is the same on all boards, or at least that it is safe to enable the necessary
regulators on all boards ...

> I'm asking because with Maxime's couple-regulator we should be able to get the
> RTL8723BS on the Q8 A23/33 v1.5 working.

So this means enabled the sdio controller (should be safe on all boards?) and
enabling 2 regulators to power the wifi-chip. I think it will be safe to do this
even on boards where those regulators are not used, what do you think ?

Regards,

Hans
Maxime Ripard Dec. 21, 2015, 4:10 p.m. UTC | #3
On Sun, Dec 20, 2015 at 12:43:01PM +0100, Hans de Goede wrote:
> The Empire Electronix D709 tablet is a fairly standard 7" A13 tablet,
> featuring usb-wifi, a micro-sd slot, micro-usb otg and headphone jack.
> 
> Empire Electronix is written on the back of the tablet, the D709 model
> info can be found in the about tablet menu in android.
> 
> The PCB has no markings to speak of.
> 
> This dts file does not add support for the ft5x touchscreen found at
> i2c bus 1, addr 0x38, irq PG11, because it does not work out of the box.
> It seems it has been flashed with the wrong firmware and needs to have
> alternative firmware uploaded at boot to make the touchscreen work
> properly, when hot-booting from android into an upstream kernel the
> touchscreen does work.
> 
> The Memsic MXC622X accelerometer at i2c bus 1, addr 0x15 also is not
> enabled as there is no driver for it.
> 
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Applied, thanks!
Maxime
Maxime Ripard Dec. 21, 2015, 4:11 p.m. UTC | #4
Hi,x

On Mon, Dec 21, 2015 at 11:46:18AM +0100, Hans de Goede wrote:
> >On the side, any thoughts on how to handle the differences between various "Q8"
> >tablets, like different I2C-based sensors and WiFi chips?
> 
> For i2c based sensors the plan is to use devicetree overlays + an in kernel
> overlay manager which probes the i2c bus (checking known touchscreen / accelerometer
> addresses) and then picks the right touchscreen + accelerometer overlays.
> 
> Wifi is somewhat more tricky I must admit, esp. since there seem to be q8 a23 based
> tablet variants with usb wifi and others with sdio wifi. Since both busses are
> discoverable I'm tempted to just enable both in devicetree, and let the kernel probe
> and see what is actually there. This assume that the way the wifichip is powered
> is the same on all boards, or at least that it is safe to enable the necessary
> regulators on all boards ...
> 
> >I'm asking because with Maxime's couple-regulator we should be able to get the
> >RTL8723BS on the Q8 A23/33 v1.5 working.
> 
> So this means enabled the sdio controller (should be safe on all boards?) and
> enabling 2 regulators to power the wifi-chip. I think it will be safe to do this
> even on boards where those regulators are not used, what do you think ?

Wouldn't that introduce some useless power drain on those boards?

Thanks!
Maxime
Hans de Goede Dec. 21, 2015, 7:36 p.m. UTC | #5
Hi,

On 21-12-15 17:11, Maxime Ripard wrote:
> Hi,x
>
> On Mon, Dec 21, 2015 at 11:46:18AM +0100, Hans de Goede wrote:
>>> On the side, any thoughts on how to handle the differences between various "Q8"
>>> tablets, like different I2C-based sensors and WiFi chips?
>>
>> For i2c based sensors the plan is to use devicetree overlays + an in kernel
>> overlay manager which probes the i2c bus (checking known touchscreen / accelerometer
>> addresses) and then picks the right touchscreen + accelerometer overlays.
>>
>> Wifi is somewhat more tricky I must admit, esp. since there seem to be q8 a23 based
>> tablet variants with usb wifi and others with sdio wifi. Since both busses are
>> discoverable I'm tempted to just enable both in devicetree, and let the kernel probe
>> and see what is actually there. This assume that the way the wifichip is powered
>> is the same on all boards, or at least that it is safe to enable the necessary
>> regulators on all boards ...
>>
>>> I'm asking because with Maxime's couple-regulator we should be able to get the
>>> RTL8723BS on the Q8 A23/33 v1.5 working.
>>
>> So this means enabled the sdio controller (should be safe on all boards?) and
>> enabling 2 regulators to power the wifi-chip. I think it will be safe to do this
>> even on boards where those regulators are not used, what do you think ?
>
> Wouldn't that introduce some useless power drain on those boards?

If nothing is attached to those regulators (which I expect to be the case when
they are not used to power wifi) then I would expect the drain to be minimal,
my biggest worry is some board having tied these to ground, but I don't think
that is very likely.

Regards,

Hans
Chen-Yu Tsai Dec. 22, 2015, 4:29 a.m. UTC | #6
On Tue, Dec 22, 2015 at 3:36 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 21-12-15 17:11, Maxime Ripard wrote:
>>
>> Hi,x
>>
>> On Mon, Dec 21, 2015 at 11:46:18AM +0100, Hans de Goede wrote:
>>>>
>>>> On the side, any thoughts on how to handle the differences between
>>>> various "Q8"
>>>> tablets, like different I2C-based sensors and WiFi chips?
>>>
>>>
>>> For i2c based sensors the plan is to use devicetree overlays + an in
>>> kernel
>>> overlay manager which probes the i2c bus (checking known touchscreen /
>>> accelerometer
>>> addresses) and then picks the right touchscreen + accelerometer overlays.
>>>
>>> Wifi is somewhat more tricky I must admit, esp. since there seem to be q8
>>> a23 based
>>> tablet variants with usb wifi and others with sdio wifi. Since both
>>> busses are
>>> discoverable I'm tempted to just enable both in devicetree, and let the
>>> kernel probe
>>> and see what is actually there. This assume that the way the wifichip is
>>> powered
>>> is the same on all boards, or at least that it is safe to enable the
>>> necessary
>>> regulators on all boards ...
>>>
>>>> I'm asking because with Maxime's couple-regulator we should be able to
>>>> get the
>>>> RTL8723BS on the Q8 A23/33 v1.5 working.
>>>
>>>
>>> So this means enabled the sdio controller (should be safe on all boards?)
>>> and
>>> enabling 2 regulators to power the wifi-chip. I think it will be safe to
>>> do this
>>> even on boards where those regulators are not used, what do you think ?
>>
>>
>> Wouldn't that introduce some useless power drain on those boards?
>
>
> If nothing is attached to those regulators (which I expect to be the case
> when
> they are not used to power wifi) then I would expect the drain to be
> minimal,
> my biggest worry is some board having tied these to ground, but I don't
> think
> that is very likely.

AFAIK the AXP datasheets mention that unused DCDC outputs should be left
floating. Not sure if this applies to LDO outputs as well. But any used
outputs would have a bypass capacitor.

From the board designs I've seen, this seems to be the common case.
I'm not an electrical engineer, but I think we're covered here.

Another thing we need to deal with is the different power sequencing
requirements for the different SDIO chips.

Regards
ChenYu
Hans de Goede Dec. 22, 2015, 10:50 a.m. UTC | #7
Hi,

On 22-12-15 05:29, Chen-Yu Tsai wrote:
> On Tue, Dec 22, 2015 at 3:36 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 21-12-15 17:11, Maxime Ripard wrote:
>>>
>>> Hi,x
>>>
>>> On Mon, Dec 21, 2015 at 11:46:18AM +0100, Hans de Goede wrote:
>>>>>
>>>>> On the side, any thoughts on how to handle the differences between
>>>>> various "Q8"
>>>>> tablets, like different I2C-based sensors and WiFi chips?
>>>>
>>>>
>>>> For i2c based sensors the plan is to use devicetree overlays + an in
>>>> kernel
>>>> overlay manager which probes the i2c bus (checking known touchscreen /
>>>> accelerometer
>>>> addresses) and then picks the right touchscreen + accelerometer overlays.
>>>>
>>>> Wifi is somewhat more tricky I must admit, esp. since there seem to be q8
>>>> a23 based
>>>> tablet variants with usb wifi and others with sdio wifi. Since both
>>>> busses are
>>>> discoverable I'm tempted to just enable both in devicetree, and let the
>>>> kernel probe
>>>> and see what is actually there. This assume that the way the wifichip is
>>>> powered
>>>> is the same on all boards, or at least that it is safe to enable the
>>>> necessary
>>>> regulators on all boards ...
>>>>
>>>>> I'm asking because with Maxime's couple-regulator we should be able to
>>>>> get the
>>>>> RTL8723BS on the Q8 A23/33 v1.5 working.
>>>>
>>>>
>>>> So this means enabled the sdio controller (should be safe on all boards?)
>>>> and
>>>> enabling 2 regulators to power the wifi-chip. I think it will be safe to
>>>> do this
>>>> even on boards where those regulators are not used, what do you think ?
>>>
>>>
>>> Wouldn't that introduce some useless power drain on those boards?
>>
>>
>> If nothing is attached to those regulators (which I expect to be the case
>> when
>> they are not used to power wifi) then I would expect the drain to be
>> minimal,
>> my biggest worry is some board having tied these to ground, but I don't
>> think
>> that is very likely.
>
> AFAIK the AXP datasheets mention that unused DCDC outputs should be left
> floating. Not sure if this applies to LDO outputs as well. But any used
> outputs would have a bypass capacitor.
>
>  From the board designs I've seen, this seems to be the common case.
> I'm not an electrical engineer, but I think we're covered here.
>
> Another thing we need to deal with is the different power sequencing
> requirements for the different SDIO chips.

In my experience there are not that much sequences, as simply making sure
all necessary resources are one before probing the sdio bus, I have yet to
see a case where the order in which the resources are enabled matters.

Regards,

Hans
Maxime Ripard Jan. 4, 2016, 10:11 a.m. UTC | #8
Hi,

On Tue, Dec 22, 2015 at 12:29:24PM +0800, Chen-Yu Tsai wrote:
> >>> So this means enabled the sdio controller (should be safe on all
> >>> boards?)  and enabling 2 regulators to power the wifi-chip. I
> >>> think it will be safe to do this even on boards where those
> >>> regulators are not used, what do you think ?
> >>
> >> Wouldn't that introduce some useless power drain on those boards?
> >
> >
> > If nothing is attached to those regulators (which I expect to be
> > the case when they are not used to power wifi) then I would expect
> > the drain to be minimal, my biggest worry is some board having
> > tied these to ground, but I don't think that is very likely.
> 
> AFAIK the AXP datasheets mention that unused DCDC outputs should be left
> floating. Not sure if this applies to LDO outputs as well. But any used
> outputs would have a bypass capacitor.
> 
> From the board designs I've seen, this seems to be the common case.
> I'm not an electrical engineer, but I think we're covered here.

Ok, I guess we're good then.

Thanks!
Maxime
diff mbox

Patch

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cdffcef..78882ae 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -612,6 +612,7 @@  dtb-$(CONFIG_MACH_SUN5I) += \
 	sun5i-a10s-olinuxino-micro.dtb \
 	sun5i-a10s-r7-tv-dongle.dtb \
 	sun5i-a10s-wobo-i5.dtb \
+	sun5i-a13-empire-electronix-d709.dtb \
 	sun5i-a13-hsg-h702.dtb \
 	sun5i-a13-inet-98v-rev2.dtb \
 	sun5i-a13-olinuxino.dtb \
diff --git a/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts b/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
new file mode 100644
index 0000000..7fbb0b0
--- /dev/null
+++ b/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
@@ -0,0 +1,241 @@ 
+/*
+ * Copyright 2015 Hans de Goede <hdegoede@redhat.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun5i-a13.dtsi"
+#include "sunxi-common-regulators.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+#include <dt-bindings/pwm/pwm.h>
+
+/ {
+	model = "Empire Electronix D709 tablet";
+	compatible = "empire-electronix,d709", "allwinner,sun5i-a13";
+
+	aliases {
+		serial0 = &uart1;
+	};
+
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm 0 50000 PWM_POLARITY_INVERTED>;
+		brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+		default-brightness-level = <8>;
+		/* TODO: backlight uses axp gpio1 as enable pin */
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+};
+
+&cpu0 {
+	cpu-supply = <&reg_dcdc2>;
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_pins_a>;
+	status = "okay";
+
+	axp209: pmic@34 {
+		reg = <0x34>;
+		interrupts = <0>;
+	};
+};
+
+#include "axp209.dtsi"
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins_a>;
+	status = "okay";
+
+	pcf8563: rtc@51 {
+		compatible = "nxp,pcf8563";
+		reg = <0x51>;
+	};
+};
+
+&lradc {
+	vref-supply = <&reg_ldo2>;
+	status = "okay";
+
+	button@200 {
+		label = "Volume Up";
+		linux,code = <KEY_VOLUMEUP>;
+		channel = <0>;
+		voltage = <200000>;
+	};
+
+	button@400 {
+		label = "Volume Down";
+		linux,code = <KEY_VOLUMEDOWN>;
+		channel = <0>;
+		voltage = <400000>;
+	};
+};
+
+&mmc0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_inet98fv2>;
+	vmmc-supply = <&reg_vcc3v3>;
+	bus-width = <4>;
+	cd-gpios = <&pio 6 0 GPIO_ACTIVE_HIGH>; /* PG0 */
+	cd-inverted;
+	status = "okay";
+};
+
+&mmc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc2_pins_a>;
+	vmmc-supply = <&reg_vcc3v3>;
+	bus-width = <8>;
+	non-removable;
+	status = "okay";
+
+	mmccard: mmccard@0 {
+		reg = <0>;
+		compatible = "mmc-card";
+		broken-hpi;
+	};
+};
+
+&otg_sram {
+	status = "okay";
+};
+
+&pio {
+	mmc0_cd_pin_inet98fv2: mmc0_cd_pin@0 {
+		allwinner,pins = "PG0";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+	};
+
+	usb0_vbus_detect_pin: usb0_vbus_detect_pin@0 {
+		allwinner,pins = "PG1";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_PULL_DOWN>;
+	};
+
+	usb0_id_detect_pin: usb0_id_detect_pin@0 {
+		allwinner,pins = "PG2";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+	};
+};
+
+&pwm {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pwm0_pins>;
+	status = "okay";
+};
+
+&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 = <1250000>;
+	regulator-max-microvolt = <1250000>;
+	regulator-name = "vdd-int-pll";
+};
+
+&reg_ldo1 {
+	regulator-name = "vdd-rtc";
+};
+
+&reg_ldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "avcc";
+};
+
+&reg_ldo3 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-wifi";
+};
+
+&reg_usb0_vbus {
+	gpio = <&pio 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */
+	status = "okay";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1_pins_b>;
+	status = "okay";
+};
+
+&usb_otg {
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&usb0_vbus_pin_a {
+	allwinner,pins = "PG12";
+};
+
+&usbphy {
+	pinctrl-names = "default";
+	pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
+	usb0_id_det-gpio = <&pio 6 2 GPIO_ACTIVE_HIGH>; /* PG2 */
+	usb0_vbus_det-gpio = <&pio 6 1 GPIO_ACTIVE_HIGH>; /* PG1 */
+	usb0_vbus-supply = <&reg_usb0_vbus>;
+	usb1_vbus-supply = <&reg_ldo3>;
+	status = "okay";
+};