From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933726AbcKWIeD (ORCPT <rfc822;w@1wt.eu>);
        Wed, 23 Nov 2016 03:34:03 -0500
Received: from mail.free-electrons.com ([62.4.15.54]:51590 "EHLO
        mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S933363AbcKWIeA (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 23 Nov 2016 03:34:00 -0500
Date: Wed, 23 Nov 2016 08:59:50 +0100
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Icenowy Zheng <icenowy@aosc.xyz>
Cc: Jonathan Corbet <corbet@lwn.net>, Chen-Yu Tsai <wens@csie.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Russell King <linux@armlinux.org.uk>,
        Hans de Goede <hdegoede@redhat.com>,
        Vishnu Patekar <vishnupatekar0510@gmail.com>,
        Andre Przywara <andre.przywara@arm.com>, Arnd Bergmann <arnd@arndb.de>,
        linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 3/3] ARM: dts: sunxi: enable SDIO Wi-Fi on Orange Pi Zero
Message-ID: <20161123075950.fjtplylunwale6j4@lukather>
References: <20161121162421.800-1-icenowy@aosc.xyz>
 <20161121162421.800-3-icenowy@aosc.xyz>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="bjlgigef2u3ezvmr"
Content-Disposition: inline
In-Reply-To: <20161121162421.800-3-icenowy@aosc.xyz>
User-Agent: Mutt/1.6.2-neo (2016-08-21)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


--bjlgigef2u3ezvmr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Nov 22, 2016 at 12:24:21AM +0800, Icenowy Zheng wrote:
> There's a Allwinner's XR819 SDIO Wi-Fi module soldered on the board of
> Orange Pi Zero, which used a dedicated regulator to power.
>=20
> Add the device tree node of the regulator, the enable gpio (with
> mmc-pwrseq) and the sdio controller.
>=20
> There's a out-of-tree driver tested to work with this device tree.
>=20
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> New patch in the patchset, since a out-of-tree working xradio driver is d=
one.
>=20
> If there is any problem in this patch, it can be omitted.

No particular problem with this one, however it can and should be
merged with the previous one.

Minor comments below though.

>=20
>  arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 42 ++++++++++++++++++=
++++++
>  1 file changed, 42 insertions(+)
>=20
> diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/=
boot/dts/sun8i-h2plus-orangepi-zero.dts
> index b428e47..39cac26 100644
> --- a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
> +++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
> @@ -79,6 +79,24 @@
>  			gpios =3D <&pio 0 17 GPIO_ACTIVE_HIGH>;
>  		};
>  	};
> +
> +	reg_vcc_wifi: reg_vcc_wifi {
> +		compatible =3D "regulator-fixed";
> +		pinctrl-names =3D "default";
> +		pinctrl-0 =3D <&vcc_wifi_pin_opi0>;
> +		regulator-min-microvolt =3D <3300000>;
> +		regulator-max-microvolt =3D <3300000>;
> +		regulator-name =3D "vcc-wifi";
> +		enable-active-high;
> +		gpio =3D <&pio 0 20 GPIO_ACTIVE_HIGH>;
> +	};
> +
> +	wifi_pwrseq: wifi_pwrseq {
> +		compatible =3D "mmc-pwrseq-simple";
> +		pinctrl-names =3D "default";
> +		pinctrl-0 =3D <&wifi_pwrseq_pin_opi0>;
> +		reset-gpios =3D <&r_pio 0 7 GPIO_ACTIVE_LOW>;
> +	};
>  };
> =20
>  &ehci1 {
> @@ -95,6 +113,20 @@
>  	status =3D "okay";
>  };
> =20
> +&mmc1 {
> +	pinctrl-names =3D "default";
> +	pinctrl-0 =3D <&mmc1_pins_a>;
> +	vmmc-supply =3D <&reg_vcc_wifi>;
> +	mmc-pwrseq =3D <&wifi_pwrseq>;
> +	bus-width =3D <4>;
> +	non-removable;
> +	status =3D "okay";
> +};
> +
> +&mmc1_pins_a {
> +	allwinner,pull =3D <SUN4I_PINCTRL_PULL_UP>;

This should be bias-pull-up.

> +};
> +
>  &ohci1 {
>  	status =3D "okay";
>  };
> @@ -104,6 +136,11 @@
>  		pins =3D "PA17";
>  		function =3D "gpio_out";
>  	};
> +
> +	vcc_wifi_pin_opi0: vcc_wifi_pin@0 {
> +		allwinner,pins =3D "PA20";

This should be pins

> +		allwinner,function =3D "gpio_out";

This should be function

> +	};
>  };
> =20
>  &r_pio {
> @@ -111,6 +148,11 @@
>  		pins =3D "PL10";
>  		function =3D "gpio_out";
>  	};
> +
> +	wifi_pwrseq_pin_opi0: wifi_pwrseq_pin@0 {
> +		allwinner,pins =3D "PL7";
> +		allwinner,function =3D "gpio_out";

And same thing here.

Thanks!
Maxime

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

--bjlgigef2u3ezvmr
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJYNUx2AAoJEBx+YmzsjxAg3MgQAJl1ppzNHgy1TrCpaz0TlZ/X
tzphrmvYOJ8vkNOKCmCFVQRwXQbZcwClfugPJA/gUNm7gphZpMvERJniB8vi+tDS
bRBf456tBSb46Swfgk+5brPjmKr0fWl0o0LqMhRUb8yG8hwCA1SkhevGeSntO3Un
fXyUTAc+ZJ7h4ZLnsir7PUlJleB4CHU0jF3dK1Ggzcq9aYs8rf4GbE7NEP/flTLY
2/mcVNgG0MsDSn1Zp1pWqBEnMMULcebQFyhBHd5hnryovsoPABamYvPBi0sPoaEA
WAxw24ZMWrlHyI+ib6gncy4ypmuoWtgasEmrgMXL9B84NUw8lXTS/Ez3UmQ1YD9N
0XuV84eLpXXd9CfbZJRNdZfpz6pAbV/AGc3/OGcXn9GJ/QeaCCwHaqvZNYp2nk5M
mHLaOs0dieXNcQUX18+Ss2QPanvtLz+Nw3PyqSesmZnmAK1kp6j7pVsS87Lgo1ZQ
87WBSnsSu4wqEX1R+4AQQSVZurJTwLPdRHiu0DEasZ2f9Ei3UGrhZxI4II31SWo4
T4zz/EG3pOmTSWB7ioaVJnwWBawOLW86Rn0thh48P6L+P1QUvjxesKRqGGzZInc3
92P+47RVeTVWzU4azD2OIJX3au4tL32127HuCmeEW0umbNHDiHRVa+7BepD8Krxh
Hv8PgsfZmYFjqS9ldCus
=gv8O
-----END PGP SIGNATURE-----

--bjlgigef2u3ezvmr--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933675AbcKWIeD (ORCPT <rfc822;w@1wt.eu>);
        Wed, 23 Nov 2016 03:34:03 -0500
Received: from mail.free-electrons.com ([62.4.15.54]:51579 "EHLO
        mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S933224AbcKWIeA (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 23 Nov 2016 03:34:00 -0500
Date: Wed, 23 Nov 2016 08:57:13 +0100
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Icenowy Zheng <icenowy@aosc.xyz>
Cc: Jonathan Corbet <corbet@lwn.net>, Chen-Yu Tsai <wens@csie.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Russell King <linux@armlinux.org.uk>,
        Hans de Goede <hdegoede@redhat.com>,
        Vishnu Patekar <vishnupatekar0510@gmail.com>,
        Andre Przywara <andre.przywara@arm.com>, Arnd Bergmann <arnd@arndb.de>,
        linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero
 board
Message-ID: <20161123075713.ks6gmud3rszjbdsh@lukather>
References: <20161121162421.800-1-icenowy@aosc.xyz>
 <20161121162421.800-2-icenowy@aosc.xyz>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="qnhpomsqxvao6b3f"
Content-Disposition: inline
In-Reply-To: <20161121162421.800-2-icenowy@aosc.xyz>
User-Agent: Mutt/1.6.2-neo (2016-08-21)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


--qnhpomsqxvao6b3f
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 22, 2016 at 12:24:20AM +0800, Icenowy Zheng wrote:
> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC.
>=20
> Add a device tree file for it.
>=20
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> Changes since v2:
> - Use generic pinconf binding instead of legacy allwinner pinctrl binding.
> - removed uart3, which is not accessible on Orange Pi Zero.
> - Removed sun8i-h2plus.dtsi and make Orange Pi Zero dts directly include
>   sun8i-h3.dtsi.
> - Removed allwinner,sun8i-h3 compatible.
>=20
>  arch/arm/boot/dts/Makefile                       |   1 +
>  arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 137 +++++++++++++++++=
++++++

Ditto, h2-plus-orangepi-zero.

>  2 files changed, 138 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>=20
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 802a10d..51a1dd7 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -834,6 +834,7 @@ dtb-$(CONFIG_MACH_SUN8I) +=3D \
>  	sun8i-a33-sinlinx-sina33.dtb \
>  	sun8i-a83t-allwinner-h8homlet-v2.dtb \
>  	sun8i-a83t-cubietruck-plus.dtb \
> +	sun8i-h2plus-orangepi-zero.dtb \
>  	sun8i-h3-bananapi-m2-plus.dtb \
>  	sun8i-h3-nanopi-neo.dtb \
>  	sun8i-h3-orangepi-2.dtb \
> diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/=
boot/dts/sun8i-h2plus-orangepi-zero.dts
> new file mode 100644
> index 0000000..b428e47
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
> @@ -0,0 +1,137 @@
> +/*
> + * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
> + *
> + * Based on sun8i-h3-orangepi-one.dts, which is:
> + *   Copyright (C) 2016 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 "sun8i-h3.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> +
> +/ {
> +	model =3D "Xunlong Orange Pi Zero";
> +	compatible =3D "xunlong,orangepi-zero", "allwinner,sun8i-h2plus";
> +
> +	aliases {
> +		serial0 =3D &uart0;
> +	};
> +
> +	chosen {
> +		stdout-path =3D "serial0:115200n8";
> +	};
> +
> +	leds {
> +		compatible =3D "gpio-leds";
> +		pinctrl-names =3D "default";
> +		pinctrl-0 =3D <&leds_opi0>, <&leds_r_opi0>;
> +
> +		pwr_led {
> +			label =3D "orangepi:green:pwr";
> +			gpios =3D <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
> +			default-state =3D "on";
> +		};
> +
> +		status_led {
> +			label =3D "orangepi:red:status";
> +			gpios =3D <&pio 0 17 GPIO_ACTIVE_HIGH>;
> +		};
> +	};
> +};
> +
> +&ehci1 {
> +	status =3D "okay";
> +};
> +
> +&mmc0 {
> +	pinctrl-names =3D "default";
> +	pinctrl-0 =3D <&mmc0_pins_a>, <&mmc0_cd_pin>;
> +	vmmc-supply =3D <&reg_vcc3v3>;
> +	bus-width =3D <4>;
> +	cd-gpios =3D <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
> +	cd-inverted;
> +	status =3D "okay";
> +};
> +
> +&ohci1 {
> +	status =3D "okay";
> +};
> +
> +&pio {
> +	leds_opi0: led_pins@0 {
> +		pins =3D "PA17";
> +		function =3D "gpio_out";
> +	};
> +};
> +
> +&r_pio {
> +	leds_r_opi0: led_pins@0 {
> +		pins =3D "PL10";
> +		function =3D "gpio_out";
> +	};
> +};
> +
> +&uart0 {
> +	pinctrl-names =3D "default";
> +	pinctrl-0 =3D <&uart0_pins_a>;
> +	status =3D "okay";
> +};
> +
> +&uart1 {
> +	pinctrl-names =3D "default";
> +	pinctrl-0 =3D <&uart1_pins>;
> +	status =3D "disabled";
> +};
> +
> +&uart2 {
> +	pinctrl-names =3D "default";
> +	pinctrl-0 =3D <&uart2_pins>;
> +	status =3D "disabled";
> +};

I'm not sure you answered me on this one. Are those exposed on the
headers? why did you put them as disabled here?

Thanks!
Maxime

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

--qnhpomsqxvao6b3f
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJYNUvZAAoJEBx+YmzsjxAgAH0QAKQGtfMscpAu5UjeQ15rHnSH
9Y1QghQwZamjJ71HnTWsLHb+NN93XB43OeCoRPRQldlpYfw5fBOIuJ2/Fx37NmWX
ydaNWkcZW+hRacFVoz0Fbwvq9QdrCPOS2qAGE+/xoJsVdpjOysQeoj+ENjaHg65g
C+8/5DU/ta0cAsttcSdAaggKNUm3APIlVhyHm/a6woRrf0fig6bxYmDJaA5TPZHN
dihT1g/bhvuYy2XEus4IJpvNPrnz7/15sbDdlqc8cMhvarqDFjcemzmcjxD6jdG8
s9RAVSuTFbt4cF+1szTvZLQcxPN1GtyKQljAMXJpOhGflusdB4P1wXZHDC2/TNj+
qd4ibemhLdIG7EDzWl4kJBIxNG2t9ZVehi51+ETAbx05rrm4jokKIH+u18SIM+Fx
XuadidWDVMk7YKWfNkDtWHI3ja8MQyRPlNwyAvBdLjMP2M+Unxknqnls6mRtWHGQ
TjGBMQQ/tx7AMY2hDp/591MqtPD+zSvAlax8rG71/0bFMciOyGqqb6bpsvZzMl7C
Be7EZNMYWY/QkbRFfmQSyNts0QmVaoAtqsDmvo7VYUQMlGgiVohEV8fnWKgmLsSw
JYFwxQq+ZgGW57HzIn3dbJI/d9FQNAkglZm5XN02p4soZ1nvQiCq2vWhA64kz9/6
0Cz6CS6fjd9Oxt9YDUrq
=e9zM
-----END PGP SIGNATURE-----

--qnhpomsqxvao6b3f--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933636AbcKWIeC (ORCPT <rfc822;w@1wt.eu>);
        Wed, 23 Nov 2016 03:34:02 -0500
Received: from mail.free-electrons.com ([62.4.15.54]:51567 "EHLO
        mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S932982AbcKWId7 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 23 Nov 2016 03:33:59 -0500
Date: Wed, 23 Nov 2016 08:54:40 +0100
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Icenowy Zheng <icenowy@aosc.xyz>
Cc: Jonathan Corbet <corbet@lwn.net>, Chen-Yu Tsai <wens@csie.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Russell King <linux@armlinux.org.uk>,
        Hans de Goede <hdegoede@redhat.com>,
        Vishnu Patekar <vishnupatekar0510@gmail.com>,
        Andre Przywara <andre.przywara@arm.com>, Arnd Bergmann <arnd@arndb.de>,
        linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 1/3] ARM: sunxi: add support for H2+ SoC
Message-ID: <20161123075440.jyubhodklpaueupw@lukather>
References: <20161121162421.800-1-icenowy@aosc.xyz>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="m6di2pz3asjbl7wt"
Content-Disposition: inline
In-Reply-To: <20161121162421.800-1-icenowy@aosc.xyz>
User-Agent: Mutt/1.6.2-neo (2016-08-21)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


--m6di2pz3asjbl7wt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Nov 22, 2016 at 12:24:19AM +0800, Icenowy Zheng wrote:
> Allwinner H2+ is a quad-core Cortex-A7 SoC.
>=20
> It is very like H3, that they share the same SoC ID (0x1680), and H3
> memory maps as well as drivers works well on the SoC.
>=20
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
>  Documentation/arm/sunxi/README                  | 4 ++++
>  Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
>  arch/arm/mach-sunxi/sunxi.c                     | 1 +
>  3 files changed, 6 insertions(+)
>=20
> diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/REA=
DME
> index cd02433..1fe4d99c 100644
> --- a/Documentation/arm/sunxi/README
> +++ b/Documentation/arm/sunxi/README
> @@ -63,6 +63,10 @@ SunXi family
>          + User Manual
>            http://dl.linux-sunxi.org/A33/A33%20user%20manual%20release%20=
1.1.pdf
> =20
> +      - Allwinner H2+ (sun8i)
> +        + No document available now, but is known to be working properly=
 with
> +          H3 drivers and memory map.
> +

I'm not sure the phrasing is right here. I would prefer something like:

"No document publicly available now, but looks very similar to the H3"=20

>        - Allwinner H3 (sun8i)
>          + Datasheet
>            http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentat=
ion/devicetree/bindings/arm/sunxi.txt
> index 4d6467c..26b35a7 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> @@ -13,6 +13,7 @@ using one of the following compatible strings:
>    allwinner,sun8i-a33
>    allwinner,sun8i-a83t
>    allwinner,sun8i-h3
> +  allwinner,sun8i-h2plus

h2-plus please.

Thanks!
Maxime

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

--m6di2pz3asjbl7wt
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJYNUs9AAoJEBx+YmzsjxAgP0QQAIUc6g0Mevf4k5yAp+6f49mW
o9K3kZhpG0P3eKN3xMxxeqThN675r4AkdcNmyvPqD6c3HWfovToBe2h2VA9rOBh1
39cbXKzxYeNboHiPzHakea8X/dfBlRqJdSaC+Zf4h+Hk88Hxxqahp43rSx9aCuUZ
OkMW/WLnjg6mKrCJw009TvqA9Ty3rpwCwZvVLwgCkYA8/omzqYrSDpGcmwk2Idkl
qfd5CVXKfx6In4n8B4axAxOG9nnW4Ps7+Sq1r2djn0ulJRjwH9K0JBQ70Bylnh93
aeKH7LEMcu+mO6jmEoKpwFOV59OVI1XvbGHIQQH4wNu4/zZPcGZ44J8uBPZ0JpJQ
+lztZ+xml31zL5WT0/OabC9OnRD+FrTIw3SONwKsJrGcI3lvN9wkOpfI3oLMoK8+
5QNdpuEHa10vEXR/xuO8pWnLXvGZmSFygjsRgnsfceg5xWhRiqWoW1v8gyYDKnS9
Q9SLbpggv3iMawKVIxxTvkxsSDsRIjQabafrYwTdXsnyWsVTzpXCaGam/2bzK7oo
5E8MU41JHGRJNU6fOiurlL5chaS1N7xoBkLxTAZjP+TTj1f4UJpge2VPUZyOeXY2
17A56FIklu00lyy8FWyaO4NzTbQAQV3gFJTWMP3c7E4gJbdmdgcIonMrH51NnSSS
X0BoyZiQ6q5j9t3b1xdW
=i5iq
-----END PGP SIGNATURE-----

--m6di2pz3asjbl7wt--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S934645AbcKWJYT (ORCPT <rfc822;w@1wt.eu>);
        Wed, 23 Nov 2016 04:24:19 -0500
Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]:55076 "EHLO
        cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1756407AbcKWJXu (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 23 Nov 2016 04:23:50 -0500
Subject: Re: [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero
 board
To: Maxime Ripard <maxime.ripard@free-electrons.com>,
        Icenowy Zheng <icenowy@aosc.xyz>
References: <20161121162421.800-1-icenowy@aosc.xyz>
 <20161121162421.800-2-icenowy@aosc.xyz>
 <20161123075713.ks6gmud3rszjbdsh@lukather>
Cc: Jonathan Corbet <corbet@lwn.net>, Chen-Yu Tsai <wens@csie.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Russell King <linux@armlinux.org.uk>,
        Hans de Goede <hdegoede@redhat.com>,
        Vishnu Patekar <vishnupatekar0510@gmail.com>,
        Arnd Bergmann <arnd@arndb.de>, linux-doc@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        devicetree@vger.kernel.org
From: Andre Przywara <andre.przywara@arm.com>
Organization: ARM Ltd.
Message-ID: <a4393a37-5008-ec76-9886-05f8686dadd5@arm.com>
Date: Wed, 23 Nov 2016 09:23:49 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <20161123075713.ks6gmud3rszjbdsh@lukather>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Maxime,

On 23/11/16 07:57, Maxime Ripard wrote:
> On Tue, Nov 22, 2016 at 12:24:20AM +0800, Icenowy Zheng wrote:
>> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC.
>>
>> Add a device tree file for it.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ---
>> Changes since v2:
>> - Use generic pinconf binding instead of legacy allwinner pinctrl binding.
>> - removed uart3, which is not accessible on Orange Pi Zero.
>> - Removed sun8i-h2plus.dtsi and make Orange Pi Zero dts directly include
>>   sun8i-h3.dtsi.
>> - Removed allwinner,sun8i-h3 compatible.
>>
>>  arch/arm/boot/dts/Makefile                       |   1 +
>>  arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 137 +++++++++++++++++++++++
> 
> Ditto, h2-plus-orangepi-zero.
> 
>>  2 files changed, 138 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 802a10d..51a1dd7 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -834,6 +834,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>>  	sun8i-a33-sinlinx-sina33.dtb \
>>  	sun8i-a83t-allwinner-h8homlet-v2.dtb \
>>  	sun8i-a83t-cubietruck-plus.dtb \
>> +	sun8i-h2plus-orangepi-zero.dtb \
>>  	sun8i-h3-bananapi-m2-plus.dtb \
>>  	sun8i-h3-nanopi-neo.dtb \
>>  	sun8i-h3-orangepi-2.dtb \
>> diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>> new file mode 100644
>> index 0000000..b428e47
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>> @@ -0,0 +1,137 @@
>> +/*
>> + * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
>> + *
>> + * Based on sun8i-h3-orangepi-one.dts, which is:
>> + *   Copyright (C) 2016 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 "sun8i-h3.dtsi"
>> +#include "sunxi-common-regulators.dtsi"
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/input/input.h>
>> +#include <dt-bindings/pinctrl/sun4i-a10.h>
>> +
>> +/ {
>> +	model = "Xunlong Orange Pi Zero";
>> +	compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2plus";
>> +
>> +	aliases {
>> +		serial0 = &uart0;
>> +	};
>> +
>> +	chosen {
>> +		stdout-path = "serial0:115200n8";
>> +	};
>> +
>> +	leds {
>> +		compatible = "gpio-leds";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&leds_opi0>, <&leds_r_opi0>;
>> +
>> +		pwr_led {
>> +			label = "orangepi:green:pwr";
>> +			gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
>> +			default-state = "on";
>> +		};
>> +
>> +		status_led {
>> +			label = "orangepi:red:status";
>> +			gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
>> +		};
>> +	};
>> +};
>> +
>> +&ehci1 {
>> +	status = "okay";
>> +};
>> +
>> +&mmc0 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
>> +	vmmc-supply = <&reg_vcc3v3>;
>> +	bus-width = <4>;
>> +	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
>> +	cd-inverted;
>> +	status = "okay";
>> +};
>> +
>> +&ohci1 {
>> +	status = "okay";
>> +};
>> +
>> +&pio {
>> +	leds_opi0: led_pins@0 {
>> +		pins = "PA17";
>> +		function = "gpio_out";
>> +	};
>> +};
>> +
>> +&r_pio {
>> +	leds_r_opi0: led_pins@0 {
>> +		pins = "PL10";
>> +		function = "gpio_out";
>> +	};
>> +};
>> +
>> +&uart0 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&uart0_pins_a>;
>> +	status = "okay";
>> +};
>> +
>> +&uart1 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&uart1_pins>;
>> +	status = "disabled";
>> +};
>> +
>> +&uart2 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&uart2_pins>;
>> +	status = "disabled";
>> +};
> 
> I'm not sure you answered me on this one. Are those exposed on the
> headers? why did you put them as disabled here?

So they are on headers, though you have to solder the actual header pins
yourself [1]. But also these are the normal pins multiplexed with GPIOs
and other peripherals, so keeping them disabled is in line with the
existing policy, if I got this correctly.

I agree that the status="disabled" is redundant, since we have that
exact line already in the .dtsi. But I saw it in other DTs as well, most
prominently in the sun8i-h3-orangepi-one.dts.

So I think we should remove the "status=" lines here, dtc will generate
an identical dtb out of it. But we should keep the uart descriptions in
to make it easier for users to see which SoC pins are used for these
pins labeled UART[012] in the board description and schematic. Also all
it takes to enable those is to overwrite the status property, which can
easily be done inline (without resizing the dtb).

Cheers,
Andre.

[1] http://linux-sunxi.org/Xunlong_Orange_Pi_Zero

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S964944AbcKWO0Z (ORCPT <rfc822;w@1wt.eu>);
        Wed, 23 Nov 2016 09:26:25 -0500
Received: from smtp.csie.ntu.edu.tw ([140.112.30.61]:41006 "EHLO
        smtp.csie.ntu.edu.tw" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S964906AbcKWO0X (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 23 Nov 2016 09:26:23 -0500
MIME-Version: 1.0
In-Reply-To: <20161123075950.fjtplylunwale6j4@lukather>
References: <20161121162421.800-1-icenowy@aosc.xyz> <20161121162421.800-3-icenowy@aosc.xyz>
 <20161123075950.fjtplylunwale6j4@lukather>
From: Chen-Yu Tsai <wens@csie.org>
Date: Wed, 23 Nov 2016 22:25:57 +0800
X-Gmail-Original-Message-ID: <CAGb2v64taF9x9MDYW+KUEEUUoSx0bF68QNc7uZXQoNrsozMGtg@mail.gmail.com>
Message-ID: <CAGb2v64taF9x9MDYW+KUEEUUoSx0bF68QNc7uZXQoNrsozMGtg@mail.gmail.com>
Subject: Re: [PATCH 3/3] ARM: dts: sunxi: enable SDIO Wi-Fi on Orange Pi Zero
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Icenowy Zheng <icenowy@aosc.xyz>, Jonathan Corbet <corbet@lwn.net>,
        Chen-Yu Tsai <wens@csie.org>, Mark Rutland <mark.rutland@arm.com>,
        Russell King <linux@armlinux.org.uk>,
        Hans de Goede <hdegoede@redhat.com>,
        Vishnu Patekar <vishnupatekar0510@gmail.com>,
        Andre Przywara <andre.przywara@arm.com>, Arnd Bergmann <arnd@arndb.de>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        devicetree <devicetree@vger.kernel.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Nov 23, 2016 at 3:59 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Tue, Nov 22, 2016 at 12:24:21AM +0800, Icenowy Zheng wrote:
>> There's a Allwinner's XR819 SDIO Wi-Fi module soldered on the board of
>> Orange Pi Zero, which used a dedicated regulator to power.
>>
>> Add the device tree node of the regulator, the enable gpio (with
>> mmc-pwrseq) and the sdio controller.
>>
>> There's a out-of-tree driver tested to work with this device tree.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ---
>> New patch in the patchset, since a out-of-tree working xradio driver is done.
>>
>> If there is any problem in this patch, it can be omitted.
>
> No particular problem with this one, however it can and should be
> merged with the previous one.
>
> Minor comments below though.
>
>>
>>  arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 42 ++++++++++++++++++++++++
>>  1 file changed, 42 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>> index b428e47..39cac26 100644
>> --- a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>> +++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>> @@ -79,6 +79,24 @@
>>                       gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
>>               };
>>       };
>> +
>> +     reg_vcc_wifi: reg_vcc_wifi {
>> +             compatible = "regulator-fixed";
>> +             pinctrl-names = "default";
>> +             pinctrl-0 = <&vcc_wifi_pin_opi0>;
>> +             regulator-min-microvolt = <3300000>;
>> +             regulator-max-microvolt = <3300000>;
>> +             regulator-name = "vcc-wifi";
>> +             enable-active-high;
>> +             gpio = <&pio 0 20 GPIO_ACTIVE_HIGH>;
>> +     };
>> +
>> +     wifi_pwrseq: wifi_pwrseq {
>> +             compatible = "mmc-pwrseq-simple";
>> +             pinctrl-names = "default";
>> +             pinctrl-0 = <&wifi_pwrseq_pin_opi0>;
>> +             reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>;
>> +     };
>>  };
>>
>>  &ehci1 {
>> @@ -95,6 +113,20 @@
>>       status = "okay";
>>  };
>>
>> +&mmc1 {
>> +     pinctrl-names = "default";
>> +     pinctrl-0 = <&mmc1_pins_a>;
>> +     vmmc-supply = <&reg_vcc_wifi>;
>> +     mmc-pwrseq = <&wifi_pwrseq>;
>> +     bus-width = <4>;
>> +     non-removable;
>> +     status = "okay";
>> +};
>> +
>> +&mmc1_pins_a {
>> +     allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>
> This should be bias-pull-up.

IIRC I already added this for _all_ existing mmc pinmux settings?

>
>> +};
>> +
>>  &ohci1 {
>>       status = "okay";
>>  };
>> @@ -104,6 +136,11 @@
>>               pins = "PA17";
>>               function = "gpio_out";
>>       };
>> +
>> +     vcc_wifi_pin_opi0: vcc_wifi_pin@0 {
>> +             allwinner,pins = "PA20";
>
> This should be pins
>
>> +             allwinner,function = "gpio_out";
>
> This should be function
>
>> +     };
>>  };
>>
>>  &r_pio {
>> @@ -111,6 +148,11 @@
>>               pins = "PL10";
>>               function = "gpio_out";
>>       };
>> +
>> +     wifi_pwrseq_pin_opi0: wifi_pwrseq_pin@0 {
>> +             allwinner,pins = "PL7";
>> +             allwinner,function = "gpio_out";
>
> And same thing here.

Might we do away with the pinmux for gpio pins tradition?
Recent patches I've sent all omit them.

ChenYu

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S964853AbcKWO3q (ORCPT <rfc822;w@1wt.eu>);
        Wed, 23 Nov 2016 09:29:46 -0500
Received: from mx1.redhat.com ([209.132.183.28]:56896 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S964985AbcKWO3Q (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 23 Nov 2016 09:29:16 -0500
Subject: Re: [PATCH 3/3] ARM: dts: sunxi: enable SDIO Wi-Fi on Orange Pi Zero
To: Chen-Yu Tsai <wens@csie.org>,
        Maxime Ripard <maxime.ripard@free-electrons.com>
References: <20161121162421.800-1-icenowy@aosc.xyz>
 <20161121162421.800-3-icenowy@aosc.xyz>
 <20161123075950.fjtplylunwale6j4@lukather>
 <CAGb2v64taF9x9MDYW+KUEEUUoSx0bF68QNc7uZXQoNrsozMGtg@mail.gmail.com>
Cc: Icenowy Zheng <icenowy@aosc.xyz>, Jonathan Corbet <corbet@lwn.net>,
        Mark Rutland <mark.rutland@arm.com>,
        Russell King <linux@armlinux.org.uk>,
        Vishnu Patekar <vishnupatekar0510@gmail.com>,
        Andre Przywara <andre.przywara@arm.com>, Arnd Bergmann <arnd@arndb.de>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        devicetree <devicetree@vger.kernel.org>
From: Hans de Goede <hdegoede@redhat.com>
Message-ID: <fe4bbd2a-27ab-db30-4bb2-e9a0d1f4b84d@redhat.com>
Date: Wed, 23 Nov 2016 15:29:11 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CAGb2v64taF9x9MDYW+KUEEUUoSx0bF68QNc7uZXQoNrsozMGtg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 23 Nov 2016 14:29:16 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi,

On 23-11-16 15:25, Chen-Yu Tsai wrote:
> On Wed, Nov 23, 2016 at 3:59 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
>> Hi,
>>
>> On Tue, Nov 22, 2016 at 12:24:21AM +0800, Icenowy Zheng wrote:
>>> There's a Allwinner's XR819 SDIO Wi-Fi module soldered on the board of
>>> Orange Pi Zero, which used a dedicated regulator to power.
>>>
>>> Add the device tree node of the regulator, the enable gpio (with
>>> mmc-pwrseq) and the sdio controller.
>>>
>>> There's a out-of-tree driver tested to work with this device tree.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>>> ---
>>> New patch in the patchset, since a out-of-tree working xradio driver is done.
>>>
>>> If there is any problem in this patch, it can be omitted.
>>
>> No particular problem with this one, however it can and should be
>> merged with the previous one.
>>
>> Minor comments below though.
>>
>>>
>>>  arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 42 ++++++++++++++++++++++++
>>>  1 file changed, 42 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>>> index b428e47..39cac26 100644
>>> --- a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>>> +++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>>> @@ -79,6 +79,24 @@
>>>                       gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
>>>               };
>>>       };
>>> +
>>> +     reg_vcc_wifi: reg_vcc_wifi {
>>> +             compatible = "regulator-fixed";
>>> +             pinctrl-names = "default";
>>> +             pinctrl-0 = <&vcc_wifi_pin_opi0>;
>>> +             regulator-min-microvolt = <3300000>;
>>> +             regulator-max-microvolt = <3300000>;
>>> +             regulator-name = "vcc-wifi";
>>> +             enable-active-high;
>>> +             gpio = <&pio 0 20 GPIO_ACTIVE_HIGH>;
>>> +     };
>>> +
>>> +     wifi_pwrseq: wifi_pwrseq {
>>> +             compatible = "mmc-pwrseq-simple";
>>> +             pinctrl-names = "default";
>>> +             pinctrl-0 = <&wifi_pwrseq_pin_opi0>;
>>> +             reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>;
>>> +     };
>>>  };
>>>
>>>  &ehci1 {
>>> @@ -95,6 +113,20 @@
>>>       status = "okay";
>>>  };
>>>
>>> +&mmc1 {
>>> +     pinctrl-names = "default";
>>> +     pinctrl-0 = <&mmc1_pins_a>;
>>> +     vmmc-supply = <&reg_vcc_wifi>;
>>> +     mmc-pwrseq = <&wifi_pwrseq>;
>>> +     bus-width = <4>;
>>> +     non-removable;
>>> +     status = "okay";
>>> +};
>>> +
>>> +&mmc1_pins_a {
>>> +     allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>>
>> This should be bias-pull-up.
>
> IIRC I already added this for _all_ existing mmc pinmux settings?
>
>>
>>> +};
>>> +
>>>  &ohci1 {
>>>       status = "okay";
>>>  };
>>> @@ -104,6 +136,11 @@
>>>               pins = "PA17";
>>>               function = "gpio_out";
>>>       };
>>> +
>>> +     vcc_wifi_pin_opi0: vcc_wifi_pin@0 {
>>> +             allwinner,pins = "PA20";
>>
>> This should be pins
>>
>>> +             allwinner,function = "gpio_out";
>>
>> This should be function
>>
>>> +     };
>>>  };
>>>
>>>  &r_pio {
>>> @@ -111,6 +148,11 @@
>>>               pins = "PL10";
>>>               function = "gpio_out";
>>>       };
>>> +
>>> +     wifi_pwrseq_pin_opi0: wifi_pwrseq_pin@0 {
>>> +             allwinner,pins = "PL7";
>>> +             allwinner,function = "gpio_out";
>>
>> And same thing here.
>
> Might we do away with the pinmux for gpio pins tradition?
> Recent patches I've sent all omit them.

I'm in favor of doing away with them, except there were
we need to configure bias / strength.

Regards,

Hans

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S966454AbcKXV3f (ORCPT <rfc822;w@1wt.eu>);
        Thu, 24 Nov 2016 16:29:35 -0500
Received: from mail.free-electrons.com ([62.4.15.54]:50601 "EHLO
        mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S966118AbcKXV3d (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 24 Nov 2016 16:29:33 -0500
Date: Thu, 24 Nov 2016 22:29:30 +0100
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Andre Przywara <andre.przywara@arm.com>
Cc: Icenowy Zheng <icenowy@aosc.xyz>, Jonathan Corbet <corbet@lwn.net>,
        Chen-Yu Tsai <wens@csie.org>, Mark Rutland <mark.rutland@arm.com>,
        Russell King <linux@armlinux.org.uk>,
        Hans de Goede <hdegoede@redhat.com>,
        Vishnu Patekar <vishnupatekar0510@gmail.com>,
        Arnd Bergmann <arnd@arndb.de>, linux-doc@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        devicetree@vger.kernel.org
Subject: Re: [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero
 board
Message-ID: <20161124212930.truoiherpczbabh7@lukather>
References: <20161121162421.800-1-icenowy@aosc.xyz>
 <20161121162421.800-2-icenowy@aosc.xyz>
 <20161123075713.ks6gmud3rszjbdsh@lukather>
 <a4393a37-5008-ec76-9886-05f8686dadd5@arm.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="hiifsvkaxkwgukjb"
Content-Disposition: inline
In-Reply-To: <a4393a37-5008-ec76-9886-05f8686dadd5@arm.com>
User-Agent: Mutt/1.6.2-neo (2016-08-21)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


--hiifsvkaxkwgukjb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 23, 2016 at 09:23:49AM +0000, Andre Przywara wrote:
> Hi Maxime,
>=20
> On 23/11/16 07:57, Maxime Ripard wrote:
> > On Tue, Nov 22, 2016 at 12:24:20AM +0800, Icenowy Zheng wrote:
> >> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC.
> >>
> >> Add a device tree file for it.
> >>
> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> >> ---
> >> Changes since v2:
> >> - Use generic pinconf binding instead of legacy allwinner pinctrl bind=
ing.
> >> - removed uart3, which is not accessible on Orange Pi Zero.
> >> - Removed sun8i-h2plus.dtsi and make Orange Pi Zero dts directly inclu=
de
> >>   sun8i-h3.dtsi.
> >> - Removed allwinner,sun8i-h3 compatible.
> >>
> >>  arch/arm/boot/dts/Makefile                       |   1 +
> >>  arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 137 ++++++++++++++=
+++++++++
> >=20
> > Ditto, h2-plus-orangepi-zero.
> >=20
> >>  2 files changed, 138 insertions(+)
> >>  create mode 100644 arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
> >>
> >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >> index 802a10d..51a1dd7 100644
> >> --- a/arch/arm/boot/dts/Makefile
> >> +++ b/arch/arm/boot/dts/Makefile
> >> @@ -834,6 +834,7 @@ dtb-$(CONFIG_MACH_SUN8I) +=3D \
> >>  	sun8i-a33-sinlinx-sina33.dtb \
> >>  	sun8i-a83t-allwinner-h8homlet-v2.dtb \
> >>  	sun8i-a83t-cubietruck-plus.dtb \
> >> +	sun8i-h2plus-orangepi-zero.dtb \
> >>  	sun8i-h3-bananapi-m2-plus.dtb \
> >>  	sun8i-h3-nanopi-neo.dtb \
> >>  	sun8i-h3-orangepi-2.dtb \
> >> diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/a=
rm/boot/dts/sun8i-h2plus-orangepi-zero.dts
> >> new file mode 100644
> >> index 0000000..b428e47
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
> >> @@ -0,0 +1,137 @@
> >> +/*
> >> + * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
> >> + *
> >> + * Based on sun8i-h3-orangepi-one.dts, which is:
> >> + *   Copyright (C) 2016 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 "sun8i-h3.dtsi"
> >> +#include "sunxi-common-regulators.dtsi"
> >> +
> >> +#include <dt-bindings/gpio/gpio.h>
> >> +#include <dt-bindings/input/input.h>
> >> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> >> +
> >> +/ {
> >> +	model =3D "Xunlong Orange Pi Zero";
> >> +	compatible =3D "xunlong,orangepi-zero", "allwinner,sun8i-h2plus";
> >> +
> >> +	aliases {
> >> +		serial0 =3D &uart0;
> >> +	};
> >> +
> >> +	chosen {
> >> +		stdout-path =3D "serial0:115200n8";
> >> +	};
> >> +
> >> +	leds {
> >> +		compatible =3D "gpio-leds";
> >> +		pinctrl-names =3D "default";
> >> +		pinctrl-0 =3D <&leds_opi0>, <&leds_r_opi0>;
> >> +
> >> +		pwr_led {
> >> +			label =3D "orangepi:green:pwr";
> >> +			gpios =3D <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
> >> +			default-state =3D "on";
> >> +		};
> >> +
> >> +		status_led {
> >> +			label =3D "orangepi:red:status";
> >> +			gpios =3D <&pio 0 17 GPIO_ACTIVE_HIGH>;
> >> +		};
> >> +	};
> >> +};
> >> +
> >> +&ehci1 {
> >> +	status =3D "okay";
> >> +};
> >> +
> >> +&mmc0 {
> >> +	pinctrl-names =3D "default";
> >> +	pinctrl-0 =3D <&mmc0_pins_a>, <&mmc0_cd_pin>;
> >> +	vmmc-supply =3D <&reg_vcc3v3>;
> >> +	bus-width =3D <4>;
> >> +	cd-gpios =3D <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
> >> +	cd-inverted;
> >> +	status =3D "okay";
> >> +};
> >> +
> >> +&ohci1 {
> >> +	status =3D "okay";
> >> +};
> >> +
> >> +&pio {
> >> +	leds_opi0: led_pins@0 {
> >> +		pins =3D "PA17";
> >> +		function =3D "gpio_out";
> >> +	};
> >> +};
> >> +
> >> +&r_pio {
> >> +	leds_r_opi0: led_pins@0 {
> >> +		pins =3D "PL10";
> >> +		function =3D "gpio_out";
> >> +	};
> >> +};
> >> +
> >> +&uart0 {
> >> +	pinctrl-names =3D "default";
> >> +	pinctrl-0 =3D <&uart0_pins_a>;
> >> +	status =3D "okay";
> >> +};
> >> +
> >> +&uart1 {
> >> +	pinctrl-names =3D "default";
> >> +	pinctrl-0 =3D <&uart1_pins>;
> >> +	status =3D "disabled";
> >> +};
> >> +
> >> +&uart2 {
> >> +	pinctrl-names =3D "default";
> >> +	pinctrl-0 =3D <&uart2_pins>;
> >> +	status =3D "disabled";
> >> +};
> >=20
> > I'm not sure you answered me on this one. Are those exposed on the
> > headers? why did you put them as disabled here?
>=20
> So they are on headers, though you have to solder the actual header pins
> yourself [1]. But also these are the normal pins multiplexed with GPIOs
> and other peripherals, so keeping them disabled is in line with the
> existing policy, if I got this correctly.
>=20
> I agree that the status=3D"disabled" is redundant, since we have that
> exact line already in the .dtsi. But I saw it in other DTs as well, most
> prominently in the sun8i-h3-orangepi-one.dts.
>=20
> So I think we should remove the "status=3D" lines here, dtc will generate
> an identical dtb out of it. But we should keep the uart descriptions in
> to make it easier for users to see which SoC pins are used for these
> pins labeled UART[012] in the board description and schematic. Also all
> it takes to enable those is to overwrite the status property, which can
> easily be done inline (without resizing the dtb).

I'd rather have the status still in the DTS. It's true that it's
redundant, but it's also explicit. A node without any status would
give the impression that it is actually enabled, especially since a
node without a status is going to be probed.

Maxime

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

--hiifsvkaxkwgukjb
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJYN1u2AAoJEBx+YmzsjxAg8u8P/0Cly2RRsOg8sJfcUa2Sze6S
P/Qcgan+qNMi4eqJqNmlMlqyhS9fJ2eudq8MlThYJEy6t2jTM7hbx5zPiZ7wQRo8
pZZIozeEDP0mNTLti0kcelLgGp34lIZB4nFdVuLyPtFmu4fGbNWDwFgKBAhMzV9Y
oSltB0p0ayKr7hi6VrZ0iOmPGnzM7q2QuCQZJHhAbInLRRPLPBcZkGmJ/8im2o02
cJ0WDIlB8c8QBr/TXH+xXgH7fIBlukGJit9BgnN2yCk3Io9A+XNwrDvufQC/sOrX
4BBRBMU1f+n2EQ+qE4uZUvyfMz0c06OY3hhVpFkyfwjRXy4HyXz2//UvIfnSNEFX
6ueS0zrD2sx3Qxbn+yj4Waij44ZpzAaOZTiTKUz2Ts8cr9i9toKsoN/gcCvo8Xch
oYPqmZu1+lLv44bX/VaDZdS/OCEkmrdK7KDp0ld7S603G5P6iE9REihxhs6Q7CDi
AmE6KiLA9P9DkzgMvAgZcE27KYFe+ynq2HAKUuCklGCJG5rid+K43cXO4G3epkSj
J6pRS/nVEbDnPALEvCovLDQQbxECxGb78Kdppf8KONDqd+Wly5di6HE5FqcivlBy
rKFo4F3A6TGP5DVEow2j23p9pYUnevEku+RZKPufiKgb3pU3Jas1+ZWtU5eD8nJ/
WQuAteQ47pHvVDzP9MEU
=9+M2
-----END PGP SIGNATURE-----

--hiifsvkaxkwgukjb--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S966537AbcKXVbN (ORCPT <rfc822;w@1wt.eu>);
        Thu, 24 Nov 2016 16:31:13 -0500
Received: from mail.free-electrons.com ([62.4.15.54]:50614 "EHLO
        mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S966049AbcKXVaX (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 24 Nov 2016 16:30:23 -0500
Date: Thu, 24 Nov 2016 22:30:11 +0100
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Chen-Yu Tsai <wens@csie.org>
Cc: Icenowy Zheng <icenowy@aosc.xyz>, Jonathan Corbet <corbet@lwn.net>,
        Mark Rutland <mark.rutland@arm.com>,
        Russell King <linux@armlinux.org.uk>,
        Hans de Goede <hdegoede@redhat.com>,
        Vishnu Patekar <vishnupatekar0510@gmail.com>,
        Andre Przywara <andre.przywara@arm.com>, Arnd Bergmann <arnd@arndb.de>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        devicetree <devicetree@vger.kernel.org>
Subject: Re: [PATCH 3/3] ARM: dts: sunxi: enable SDIO Wi-Fi on Orange Pi Zero
Message-ID: <20161124213011.vyyfr6ikhgt3xath@lukather>
References: <20161121162421.800-1-icenowy@aosc.xyz>
 <20161121162421.800-3-icenowy@aosc.xyz>
 <20161123075950.fjtplylunwale6j4@lukather>
 <CAGb2v64taF9x9MDYW+KUEEUUoSx0bF68QNc7uZXQoNrsozMGtg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="egkksv3xq2ymvgum"
Content-Disposition: inline
In-Reply-To: <CAGb2v64taF9x9MDYW+KUEEUUoSx0bF68QNc7uZXQoNrsozMGtg@mail.gmail.com>
User-Agent: Mutt/1.6.2-neo (2016-08-21)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


--egkksv3xq2ymvgum
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 23, 2016 at 10:25:57PM +0800, Chen-Yu Tsai wrote:
> >>  &r_pio {
> >> @@ -111,6 +148,11 @@
> >>               pins =3D "PL10";
> >>               function =3D "gpio_out";
> >>       };
> >> +
> >> +     wifi_pwrseq_pin_opi0: wifi_pwrseq_pin@0 {
> >> +             allwinner,pins =3D "PL7";
> >> +             allwinner,function =3D "gpio_out";
> >
> > And same thing here.
>=20
> Might we do away with the pinmux for gpio pins tradition?
> Recent patches I've sent all omit them.

Oh, yes, that's true.

Thanks,
Maxime

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

--egkksv3xq2ymvgum
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJYN1vjAAoJEBx+YmzsjxAgfTkP/3igca1V4/zoyReXfrvFXCtM
506Ubsf4eEime7/44UYscdL9vNcWW3+r/NKaQUmuc9o2Kg2Q9etob3r+FXmmMlbX
g5Vzx7daMZE2ckPzLzCsij0THg5q+DZrDpYypNVA+NL7sgPralJP/R5m7VzqdXk8
/XAm0CxaVsCvpzD26zxsLob7jXs8yNeVwwZa57tNSI2DXN5KTwHTpahpJPQSQk/T
mhXI5I0XoWhVPmHBRDwP2IFe7RdUzCTJ6m50pdfTWTz7gg790C7V4fQFZcfg8qAr
GiZ615EikfIQkZ51m/NHNz8UGN7vHMIBbCdjh2isIDK4fIzIJCFaa6RHtRZ16R2O
e+u3vSYHNDRGv8/kvl8tz+IxkZnVMATAEXEue4pB6+V0C5exzXeO9qGFiCH0ZD1g
6/G+C8Y+fyG76A4Ff6SwhZIlf3+UqGHo4NbglOPIgDaRl6z9tNY+K5fP+YVRNs1z
b9JMfkH3agsMHaEiQaE8HwHY/HYHJRrql95tLWm0mAI8MXoszFN+MQaVZipFvLVS
AAP5Rk0Q1ZO5OI8ThQrZ+3ibXUewxIuuMS1DeZ96q2zIIDCaEaIBdAOiXm03QEHR
BLrEUuEXa2Yz8wKQZP4HONXj5z1ajSHf/GveKwruArPvopMmQDiOzBbWI4iK+eMw
5MV5TRVXZ2rWaJy1C4WZ
=rXMI
-----END PGP SIGNATURE-----

--egkksv3xq2ymvgum--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752810AbcK1Abs (ORCPT <rfc822;w@1wt.eu>);
        Sun, 27 Nov 2016 19:31:48 -0500
Received: from foss.arm.com ([217.140.101.70]:43250 "EHLO foss.arm.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751015AbcK1Abq (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Sun, 27 Nov 2016 19:31:46 -0500
Subject: Re: [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero
 board
To: Icenowy Zheng <icenowy@aosc.xyz>, Jonathan Corbet <corbet@lwn.net>,
        Maxime Ripard <maxime.ripard@free-electrons.com>,
        Chen-Yu Tsai <wens@csie.org>, Mark Rutland <mark.rutland@arm.com>,
        Russell King <linux@armlinux.org.uk>,
        Hans de Goede <hdegoede@redhat.com>
References: <20161121162421.800-1-icenowy@aosc.xyz>
 <20161121162421.800-2-icenowy@aosc.xyz> <5373671480239408@web31m.yandex.ru>
Cc: Vishnu Patekar <vishnupatekar0510@gmail.com>,
        Arnd Bergmann <arnd@arndb.de>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
From: =?UTF-8?Q?Andr=c3=a9_Przywara?= <andre.przywara@arm.com>
Organization: ARM Ltd.
Message-ID: <cdfd3c65-d473-badb-ea6a-035f7ab79217@arm.com>
Date: Mon, 28 Nov 2016 00:29:07 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <5373671480239408@web31m.yandex.ru>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 27/11/16 09:36, Icenowy Zheng wrote:

Hi,

> 22.11.2016, 00:26, "Icenowy Zheng" <icenowy@aosc.xyz>:
>> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC.
>>
>> Add a device tree file for it.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ---
>> Changes since v2:
>> - Use generic pinconf binding instead of legacy allwinner pinctrl binding.
>> - removed uart3, which is not accessible on Orange Pi Zero.
>> - Removed sun8i-h2plus.dtsi and make Orange Pi Zero dts directly include
>>   sun8i-h3.dtsi.
>> - Removed allwinner,sun8i-h3 compatible.
>>
>>  arch/arm/boot/dts/Makefile | 1 +
>>  arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 137 +++++++++++++++++++++++
>>  2 files changed, 138 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 802a10d..51a1dd7 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -834,6 +834,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>>          sun8i-a33-sinlinx-sina33.dtb \
>>          sun8i-a83t-allwinner-h8homlet-v2.dtb \
>>          sun8i-a83t-cubietruck-plus.dtb \
>> + sun8i-h2plus-orangepi-zero.dtb \
>>          sun8i-h3-bananapi-m2-plus.dtb \
>>          sun8i-h3-nanopi-neo.dtb \
>>          sun8i-h3-orangepi-2.dtb \
>> diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>> new file mode 100644
>> index 0000000..b428e47
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>> @@ -0,0 +1,137 @@
>> +/*
>> + * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
>> + *
>> + * Based on sun8i-h3-orangepi-one.dts, which is:
>> + * Copyright (C) 2016 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 "sun8i-h3.dtsi"
>> +#include "sunxi-common-regulators.dtsi"
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/input/input.h>
>> +#include <dt-bindings/pinctrl/sun4i-a10.h>
>> +
>> +/ {
>> + model = "Xunlong Orange Pi Zero";
>> + compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2plus";
>> +
>> + aliases {
>> + serial0 = &uart0;
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> + };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&leds_opi0>, <&leds_r_opi0>;
>> +
>> + pwr_led {
>> + label = "orangepi:green:pwr";
>> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
>> + default-state = "on";
>> + };
>> +
>> + status_led {
>> + label = "orangepi:red:status";
>> + gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
>> + };
>> + };
>> +};
>> +
>> +&ehci1 {
>> + status = "okay";
>> +};
>> +
>> +&mmc0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
>> + vmmc-supply = <&reg_vcc3v3>;
>> + bus-width = <4>;
>> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
>> + cd-inverted;
>> + status = "okay";
>> +};
>> +
>> +&ohci1 {
>> + status = "okay";
>> +};
>> +
>> +&pio {
>> + leds_opi0: led_pins@0 {
>> + pins = "PA17";
>> + function = "gpio_out";
>> + };
>> +};
>> +
>> +&r_pio {
>> + leds_r_opi0: led_pins@0 {
>> + pins = "PL10";
>> + function = "gpio_out";
>> + };
>> +};
>> +
>> +&uart0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart0_pins_a>;
>> + status = "okay";
>> +};
>> +
>> +&uart1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart1_pins>;
>> + status = "disabled";
>> +};
>> +
>> +&uart2 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart2_pins>;
>> + status = "disabled";
>> +};
>> +
>> +&usbphy {
>> + /* USB VBUS is always on */
>> + status = "okay";
>> +};
> 
> Something more interesting happened.
> 
> Xunlong made a add-on board for Orange Pi Zero, which exposes the two USB Controllers exported at expansion bus as USB Type-A connectors.
> 
> Also it exposes a analog A/V jack and a microphone.
> 
> Should I enable {e,o}hci{2.3} in the device tree?

Actually we should do this regardless of this extension board. The USB
pins are not multiplexed and are exposed on user accessible pins (just
not soldered, but that's a detail), so I think they qualify for DT
enablement. And even if a user can't use them, it doesn't hurt to have
them (since they are not multiplexed).

Cheers,
Andre.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1755466AbcK3CMJ (ORCPT <rfc822;w@1wt.eu>);
        Tue, 29 Nov 2016 21:12:09 -0500
Received: from mail-pf0-f194.google.com ([209.85.192.194]:36300 "EHLO
        mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752603AbcK3CMH (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 29 Nov 2016 21:12:07 -0500
Subject: Re: [PATCH 3/3] ARM: dts: sunxi: enable SDIO Wi-Fi on Orange Pi Zero
To: Icenowy Zheng <icenowy@aosc.xyz>
References: <20161129131922.JFbeipav@smtp2o.mail.yandex.net>
Cc: Mark Rutland <mark.rutland@arm.com>,
        Vishnu Patekar <vishnupatekar0510@gmail.com>,
        Andre Przywara <andre.przywara@arm.com>, devicetree@vger.kernel.org,
        linux-doc@vger.kernel.org, Hans de Goede <hdegoede@redhat.com>,
        Jonathan Corbet <corbet@lwn.net>, Arnd Bergmann <arnd@arndb.de>,
        Russell King <linux@armlinux.org.uk>,
        Maxime Ripard <maxime.ripard@free-electrons.com>,
        linux-arm-kernel@lists.infradead.org,
        LKML <linux-kernel@vger.kernel.org>, Chen-Yu Tsai <wens@csie.org>
From: Alexey Kardashevskiy <aik@ozlabs.ru>
Message-ID: <a7a3c242-f359-5b32-bff8-4641d8566d50@ozlabs.ru>
Date: Wed, 30 Nov 2016 13:11:58 +1100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <20161129131922.JFbeipav@smtp2o.mail.yandex.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 29/11/16 21:19, Icenowy Zheng wrote:
> 
> 2016年11月29日 15:16于 Alexey Kardashevskiy <aik@ozlabs.ru>写道：
>>
>>
>>
>> On Wed, Nov 23, 2016 at 6:59 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
>>>
>>> Hi,
>>>
>>> On Tue, Nov 22, 2016 at 12:24:21AM +0800, Icenowy Zheng wrote:
>>> > There's a Allwinner's XR819 SDIO Wi-Fi module soldered on the board of
>>> > Orange Pi Zero, which used a dedicated regulator to power.
>>> >
>>> > Add the device tree node of the regulator, the enable gpio (with
>>> > mmc-pwrseq) and the sdio controller.
>>> >
>>> > There's a out-of-tree driver tested to work with this device tree.
>>
>>
>> btw could you please give a pointer where to find a XR819 driver for
> relatively recent kernel (4.8 may be, just not 3.4)? Thanks.
> 
> https://github.com/Icenowy/xradio

Thanks!

I tried, cannot make it work though.

This compiles:

CONFIG_XRADIO=y
CONFIG_XRADIO_SDIO=y
CONFIG_XRADIO_NON_POWER_OF_TWO_BLOCKSIZES=y
# CONFIG_XRADIO_USE_GPIO_IRQ is not set
# CONFIG_XRADIO_5GHZ_SUPPORT is not set
# CONFIG_XRADIO_WAPI_SUPPORT is not set
CONFIG_XRADIO_USE_EXTENSIONS=y

But produces:

[    0.964793] [XRADIO] Driver Label:L34M.01.08.0002
[    0.969659] [XRADIO] Allocated hw_priv @ df684dc0
[    3.038167] [SBUS_ERR] sdio probe timeout!
[    3.046283] [XRADIO_ERR] sbus_sdio_init failed


If I enable CONFIG_XRADIO_USE_GPIO_IRQ (which Kconfig suggest to enable -
do I really need it?), it does not compile:

drivers/built-in.o: In function `sdio_irq_subscribe':
sunxi_sid.c:(.text+0x12dfe8): undefined reference to `xradio_request_gpio_irq'
sunxi_sid.c:(.text+0x12e06c): undefined reference to `xradio_free_gpio_irq'
sunxi_sid.c:(.text+0x12e080): undefined reference to `sunxi_mci_check_r1_ready'
drivers/built-in.o: In function `sdio_irq_unsubscribe':
sunxi_sid.c:(.text+0x12e3b0): undefined reference to `xradio_free_gpio_irq'
Makefile:962: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1


I am using recent upstream kernel and
https://patchwork.kernel.org/patch/9439759/
https://patchwork.kernel.org/patch/9439761/

and I added missing emac.

Basically, here is my current tree with all sun8xi support
https://github.com/aik/linux/commits/pizero

and I just did
git -C drivers/net/ethernet clone https://github.com/Icenowy/xradio

and compiled it into vmlinux (no modules).

What am I missing? Sorry I am a newbie with ARM. Thanks.


-- 
Alexey

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1756416AbcK3JYV (ORCPT <rfc822;w@1wt.eu>);
        Wed, 30 Nov 2016 04:24:21 -0500
Received: from foss.arm.com ([217.140.101.70]:39670 "EHLO foss.arm.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752818AbcK3JYS (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 30 Nov 2016 04:24:18 -0500
Subject: Re: [PATCH 3/3] ARM: dts: sunxi: enable SDIO Wi-Fi on Orange Pi Zero
To: Icenowy Zheng <icenowy@aosc.xyz>, Alexey Kardashevskiy <aik@ozlabs.ru>
References: <20161129131922.JFbeipav@smtp2o.mail.yandex.net>
Cc: Mark Rutland <mark.rutland@arm.com>,
        Vishnu Patekar <vishnupatekar0510@gmail.com>,
        devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
        Hans de Goede <hdegoede@redhat.com>, Jonathan Corbet <corbet@lwn.net>,
        Arnd Bergmann <arnd@arndb.de>, Russell King <linux@armlinux.org.uk>,
        Maxime Ripard <maxime.ripard@free-electrons.com>,
        linux-arm-kernel@lists.infradead.org,
        LKML <linux-kernel@vger.kernel.org>, Chen-Yu Tsai <wens@csie.org>
From: Andre Przywara <andre.przywara@arm.com>
Message-ID: <da84928a-25a2-1615-1d8e-e6570b1a6323@arm.com>
Date: Wed, 30 Nov 2016 09:25:01 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <20161129131922.JFbeipav@smtp2o.mail.yandex.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi,

On 29/11/16 10:19, Icenowy Zheng wrote:
> 
> 2016年11月29日 15:16于 Alexey Kardashevskiy <aik@ozlabs.ru>写道：
>>
>>
>>
>> On Wed, Nov 23, 2016 at 6:59 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
>>>
>>> Hi,
>>>
>>> On Tue, Nov 22, 2016 at 12:24:21AM +0800, Icenowy Zheng wrote:
>>> > There's a Allwinner's XR819 SDIO Wi-Fi module soldered on the board of
>>> > Orange Pi Zero, which used a dedicated regulator to power.
>>> >
>>> > Add the device tree node of the regulator, the enable gpio (with
>>> > mmc-pwrseq) and the sdio controller.
>>> >
>>> > There's a out-of-tree driver tested to work with this device tree.
>>
>>
>> btw could you please give a pointer where to find a XR819 driver for
> relatively recent kernel (4.8 may be, just not 3.4)? Thanks.
> 
> https://github.com/Icenowy/xradio

I was just curious, so pulled your tree and tried to just compile it. It
still threw warnings at me for ARM, and even more so for arm64.
I fixed all of them and put that on my github[1]. Feel free to just pick
them from there or wait till I manage to clean them up and send you a
pull request.
And also just a a test, I quickly put it in drivers/net/wireless/xradio,
where it compiled fine after registering it with the upper level Kconfig
and Makefile.

And while looking at it: This looks like typical AW code, not even
remotely upstreameable and probably far too complicated. Enabling some
Kconfig options made it complain about missing functions.
Has anyone checked if this is close to an existing WiFi chip? That
wouldn't be a first ;-)

Cheers,
Andre.

[1] https://github.com/apritzel/xradio/commits/quickfixes

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1755449AbcLAJhb (ORCPT <rfc822;w@1wt.eu>);
        Thu, 1 Dec 2016 04:37:31 -0500
Received: from mail.free-electrons.com ([62.4.15.54]:53026 "EHLO
        mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751388AbcLAJh3 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 1 Dec 2016 04:37:29 -0500
Date: Thu, 1 Dec 2016 10:36:19 +0100
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: =?iso-8859-1?Q?Andr=E9?= Przywara <andre.przywara@arm.com>
Cc: Icenowy Zheng <icenowy@aosc.xyz>, Jonathan Corbet <corbet@lwn.net>,
        Chen-Yu Tsai <wens@csie.org>, Mark Rutland <mark.rutland@arm.com>,
        Russell King <linux@armlinux.org.uk>,
        Hans de Goede <hdegoede@redhat.com>,
        Vishnu Patekar <vishnupatekar0510@gmail.com>,
        Arnd Bergmann <arnd@arndb.de>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero
 board
Message-ID: <20161201093619.gs6lmoxtlptp2jr6@lukather>
References: <20161121162421.800-1-icenowy@aosc.xyz>
 <20161121162421.800-2-icenowy@aosc.xyz>
 <5373671480239408@web31m.yandex.ru>
 <cdfd3c65-d473-badb-ea6a-035f7ab79217@arm.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="sobjbz35ztnadlxs"
Content-Disposition: inline
In-Reply-To: <cdfd3c65-d473-badb-ea6a-035f7ab79217@arm.com>
User-Agent: Mutt/1.6.2-neo (2016-08-21)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


--sobjbz35ztnadlxs
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 28, 2016 at 12:29:07AM +0000, Andr=E9 Przywara wrote:
> > Something more interesting happened.
> >=20
> > Xunlong made a add-on board for Orange Pi Zero, which exposes the
> > two USB Controllers exported at expansion bus as USB Type-A
> > connectors.
> >=20
> > Also it exposes a analog A/V jack and a microphone.
> >=20
> > Should I enable {e,o}hci{2.3} in the device tree?
>=20
> Actually we should do this regardless of this extension board. The USB
> pins are not multiplexed and are exposed on user accessible pins (just
> not soldered, but that's a detail), so I think they qualify for DT
> enablement. And even if a user can't use them, it doesn't hurt to have
> them (since they are not multiplexed).

My main concern about this is that we'll leave regulators enabled by
default, for a minority of users. And that minority will prevent to do
a proper power management when the times come since we'll have to keep
that behaviour forever.

Maxime

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

--sobjbz35ztnadlxs
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJYP+8PAAoJEBx+YmzsjxAgCSkQAIQGvIHsIV2oflWLBU9WTsQI
f8gUtQ799csf4yGXR0Qh14SOq9Yk0VSQiN5MmkjOlwLWDwUO9F54M1v/suMrAsQu
3hiaPH65MppAlTAgSW+UrR6Rz+X5VIMB6fS6WttRo8Xc3rQNt8xumzs0X57IDl5V
bH+dEVVR+Td4FIwDvDxb29QstU58ZCveDVjw1VdJlAN9sCJNHlyQ8uP3kEN8+LqO
cskGv2gTTt7wabjYeVlHt2wMR67m91cgC8nO6k7Y40EBrPeoWETv/HRNki0zDLz0
fcm887tZQn3ieaYW/Km4t21V8WBCHr4Z3U88VS/EcVH6PqE1ukX4mG6yfPr/BMKx
t4lUjC4HuiFjocrbUEiE4HOBiHxJsJo3aJNtbSdE9bm2INAQtytp+ZPjGOXppq8W
ocB+bZ2OKLie07sFtbXZPx63F+/CtDAe21u/LQ8qIAvS/gOhLf8BlcA/AOLvf4Il
nSfyo9UT3WDZIMNho2S8j9+m/9cPjo2P4wMgyXeMB44c/5yYKKa45eXs1In5YVaw
DLbhLiwxDyNP2KVwQUa/GVEDfTqUfrswGNtFkKTVjzWZYl+jvVDMLBIXhN3t5422
hbRz1d9QSSDfUj6H5j6B2E7hi8KV+tL196y5jJ14ryVyktUmh3ApDEFG1rj1I5Jr
pw8JYPdFwraxkCYXcjh4
=NjLr
-----END PGP SIGNATURE-----

--sobjbz35ztnadlxs--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1761072AbcLBOad (ORCPT <rfc822;w@1wt.eu>);
        Fri, 2 Dec 2016 09:30:33 -0500
Received: from mx1.redhat.com ([209.132.183.28]:57110 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1758563AbcLBOab (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 2 Dec 2016 09:30:31 -0500
Subject: Re: [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero
 board
To: Icenowy Zheng <icenowy@aosc.xyz>,
        Maxime Ripard <maxime.ripard@free-electrons.com>,
        =?UTF-8?Q?Andr=c3=a9_Przywara?= <andre.przywara@arm.com>
References: <20161121162421.800-1-icenowy@aosc.xyz>
 <20161121162421.800-2-icenowy@aosc.xyz> <5373671480239408@web31m.yandex.ru>
 <cdfd3c65-d473-badb-ea6a-035f7ab79217@arm.com>
 <20161201093619.gs6lmoxtlptp2jr6@lukather>
 <11498641480688550@web2g.yandex.ru>
Cc: Jonathan Corbet <corbet@lwn.net>, Chen-Yu Tsai <wens@csie.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Russell King <linux@armlinux.org.uk>,
        Vishnu Patekar <vishnupatekar0510@gmail.com>,
        Arnd Bergmann <arnd@arndb.de>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
From: Hans de Goede <hdegoede@redhat.com>
Message-ID: <efb30303-b9bb-7a7c-4478-af485991dd86@redhat.com>
Date: Fri, 2 Dec 2016 15:30:26 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <11498641480688550@web2g.yandex.ru>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Fri, 02 Dec 2016 14:30:30 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi,

On 02-12-16 15:22, Icenowy Zheng wrote:
>
>
> 01.12.2016, 17:36, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>> On Mon, Nov 28, 2016 at 12:29:07AM +0000, André Przywara wrote:
>>>  > Something more interesting happened.
>>>  >
>>>  > Xunlong made a add-on board for Orange Pi Zero, which exposes the
>>>  > two USB Controllers exported at expansion bus as USB Type-A
>>>  > connectors.
>>>  >
>>>  > Also it exposes a analog A/V jack and a microphone.
>>>  >
>>>  > Should I enable {e,o}hci{2.3} in the device tree?
>>>
>>>  Actually we should do this regardless of this extension board. The USB
>>>  pins are not multiplexed and are exposed on user accessible pins (just
>>>  not soldered, but that's a detail), so I think they qualify for DT
>>>  enablement. And even if a user can't use them, it doesn't hurt to have
>>>  them (since they are not multiplexed).
>>
>> My main concern about this is that we'll leave regulators enabled by
>> default, for a minority of users. And that minority will prevent to do
>> a proper power management when the times come since we'll have to keep
>> that behaviour forever.
>
> I think these users can add a 'fdt set /xxx/xxx status "disabled" ' .

I don't think that will be necessary I'm pretty sure these extra usb
ports do not have a regulator for the Vbus, they just hook directly
to the 5V rail, can someone with a schematic check ?

Regards,

Hans

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754038AbcLBQKD (ORCPT <rfc822;w@1wt.eu>);
        Fri, 2 Dec 2016 11:10:03 -0500
Received: from foss.arm.com ([217.140.101.70]:43730 "EHLO foss.arm.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751549AbcLBQKB (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 2 Dec 2016 11:10:01 -0500
Subject: Re: [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero
 board
To: Icenowy Zheng <icenowy@aosc.xyz>, Hans de Goede <hdegoede@redhat.com>,
        Maxime Ripard <maxime.ripard@free-electrons.com>
References: <20161121162421.800-1-icenowy@aosc.xyz>
 <20161121162421.800-2-icenowy@aosc.xyz> <5373671480239408@web31m.yandex.ru>
 <cdfd3c65-d473-badb-ea6a-035f7ab79217@arm.com>
 <20161201093619.gs6lmoxtlptp2jr6@lukather>
 <11498641480688550@web2g.yandex.ru>
 <efb30303-b9bb-7a7c-4478-af485991dd86@redhat.com>
 <11535601480689127@web2g.yandex.ru>
Cc: Jonathan Corbet <corbet@lwn.net>, Chen-Yu Tsai <wens@csie.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Russell King <linux@armlinux.org.uk>,
        Vishnu Patekar <vishnupatekar0510@gmail.com>,
        Arnd Bergmann <arnd@arndb.de>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
From: Andre Przywara <andre.przywara@arm.com>
Message-ID: <324c8820-aeea-3fad-0e02-1bdb8f675677@arm.com>
Date: Fri, 2 Dec 2016 16:10:46 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <11535601480689127@web2g.yandex.ru>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi,

On 02/12/16 14:32, Icenowy Zheng wrote:
> 
> 
> 02.12.2016, 22:30, "Hans de Goede" <hdegoede@redhat.com>:
>> Hi,
>>
>> On 02-12-16 15:22, Icenowy Zheng wrote:
>>>  01.12.2016, 17:36, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>>>>  On Mon, Nov 28, 2016 at 12:29:07AM +0000, André Przywara wrote:
>>>>>   > Something more interesting happened.
>>>>>   >
>>>>>   > Xunlong made a add-on board for Orange Pi Zero, which exposes the
>>>>>   > two USB Controllers exported at expansion bus as USB Type-A
>>>>>   > connectors.
>>>>>   >
>>>>>   > Also it exposes a analog A/V jack and a microphone.
>>>>>   >
>>>>>   > Should I enable {e,o}hci{2.3} in the device tree?
>>>>>
>>>>>   Actually we should do this regardless of this extension board. The USB
>>>>>   pins are not multiplexed and are exposed on user accessible pins (just
>>>>>   not soldered, but that's a detail), so I think they qualify for DT
>>>>>   enablement. And even if a user can't use them, it doesn't hurt to have
>>>>>   them (since they are not multiplexed).
>>>>
>>>>  My main concern about this is that we'll leave regulators enabled by
>>>>  default, for a minority of users. And that minority will prevent to do
>>>>  a proper power management when the times come since we'll have to keep
>>>>  that behaviour forever.
>>>
>>>  I think these users can add a 'fdt set /xxx/xxx status "disabled" ' .
>>
>> I don't think that will be necessary I'm pretty sure these extra usb
>> ports do not have a regulator for the Vbus, they just hook directly
>> to the 5V rail, can someone with a schematic check ?
> 
> We seems to have still no schematics for the add-on board.

>>From looking at the picture of that expansion board on the Aliexpress
page and chasing the tracks, there is clearly no voltage regulator on
there, it's just passive components. The 5V pin from the headers is
routed forth and back between the two layers via some vias directly to
the 5V pins of the USB sockets.

> But something is sure is that there's no any regulator-related pins
> on the add-on pinout. There's only USB DM and DP pins.
> 
> So the Vbus must be directly connected to +5V.

So yes, it is.

But I think the question is moot anyways, since we don't provide DT
support for that add-on board at that point anyways.
One could imagine another board, though, which has regulators switched
by GPIOs, but that would be their problem and they would have regulators
specified in their specific DT snippet, then.

So to summarize:
- For that specific Orange Pi Zero board which we discuss the DT for
there is no regulator support for the additional USB ports. Thus nothing
we could turn off to save power.
- A user could just take these USB brackets with pin headers that are so
common in PCs to connect additional USB ports to the back of the box.
One just needs to re-sort the pins, which is a matter of a minute.
- As long as we don't provide any easy way of handling DT changes, we
should enable the USB ports for the sake of the users of either those
brackets or the expansion board. Any more sophisticated USB expansion
board with regulators would need to amend the DT anyway.

Does that make sense?

Cheers,
Andre.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753073AbcLBQiE convert rfc822-to-8bit (ORCPT <rfc822;w@1wt.eu>);
        Fri, 2 Dec 2016 11:38:04 -0500
Received: from smtp.csie.ntu.edu.tw ([140.112.30.61]:40674 "EHLO
        smtp.csie.ntu.edu.tw" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750750AbcLBQiA (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 2 Dec 2016 11:38:00 -0500
MIME-Version: 1.0
In-Reply-To: <324c8820-aeea-3fad-0e02-1bdb8f675677@arm.com>
References: <20161121162421.800-1-icenowy@aosc.xyz> <20161121162421.800-2-icenowy@aosc.xyz>
 <5373671480239408@web31m.yandex.ru> <cdfd3c65-d473-badb-ea6a-035f7ab79217@arm.com>
 <20161201093619.gs6lmoxtlptp2jr6@lukather> <11498641480688550@web2g.yandex.ru>
 <efb30303-b9bb-7a7c-4478-af485991dd86@redhat.com> <11535601480689127@web2g.yandex.ru>
 <324c8820-aeea-3fad-0e02-1bdb8f675677@arm.com>
From: Chen-Yu Tsai <wens@csie.org>
Date: Sat, 3 Dec 2016 00:37:34 +0800
X-Gmail-Original-Message-ID: <CAGb2v64be0yUxn19A1qhR8J6xhZwLoZnWNmfXESsbu_Bv=8czg@mail.gmail.com>
Message-ID: <CAGb2v64be0yUxn19A1qhR8J6xhZwLoZnWNmfXESsbu_Bv=8czg@mail.gmail.com>
Subject: Re: [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
To: Andre Przywara <andre.przywara@arm.com>
Cc: Icenowy Zheng <icenowy@aosc.xyz>, Hans de Goede <hdegoede@redhat.com>,
        Maxime Ripard <maxime.ripard@free-electrons.com>,
        Jonathan Corbet <corbet@lwn.net>, Chen-Yu Tsai <wens@csie.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Russell King <linux@armlinux.org.uk>,
        Vishnu Patekar <vishnupatekar0510@gmail.com>,
        Arnd Bergmann <arnd@arndb.de>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, Dec 3, 2016 at 12:10 AM, Andre Przywara <andre.przywara@arm.com> wrote:
> Hi,
>
> On 02/12/16 14:32, Icenowy Zheng wrote:
>>
>>
>> 02.12.2016, 22:30, "Hans de Goede" <hdegoede@redhat.com>:
>>> Hi,
>>>
>>> On 02-12-16 15:22, Icenowy Zheng wrote:
>>>>  01.12.2016, 17:36, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>>>>>  On Mon, Nov 28, 2016 at 12:29:07AM +0000, André Przywara wrote:
>>>>>>   > Something more interesting happened.
>>>>>>   >
>>>>>>   > Xunlong made a add-on board for Orange Pi Zero, which exposes the
>>>>>>   > two USB Controllers exported at expansion bus as USB Type-A
>>>>>>   > connectors.
>>>>>>   >
>>>>>>   > Also it exposes a analog A/V jack and a microphone.
>>>>>>   >
>>>>>>   > Should I enable {e,o}hci{2.3} in the device tree?
>>>>>>
>>>>>>   Actually we should do this regardless of this extension board. The USB
>>>>>>   pins are not multiplexed and are exposed on user accessible pins (just
>>>>>>   not soldered, but that's a detail), so I think they qualify for DT
>>>>>>   enablement. And even if a user can't use them, it doesn't hurt to have
>>>>>>   them (since they are not multiplexed).
>>>>>
>>>>>  My main concern about this is that we'll leave regulators enabled by
>>>>>  default, for a minority of users. And that minority will prevent to do
>>>>>  a proper power management when the times come since we'll have to keep
>>>>>  that behaviour forever.
>>>>
>>>>  I think these users can add a 'fdt set /xxx/xxx status "disabled" ' .
>>>
>>> I don't think that will be necessary I'm pretty sure these extra usb
>>> ports do not have a regulator for the Vbus, they just hook directly
>>> to the 5V rail, can someone with a schematic check ?
>>
>> We seems to have still no schematics for the add-on board.
>
> From looking at the picture of that expansion board on the Aliexpress
> page and chasing the tracks, there is clearly no voltage regulator on
> there, it's just passive components. The 5V pin from the headers is
> routed forth and back between the two layers via some vias directly to
> the 5V pins of the USB sockets.
>
>> But something is sure is that there's no any regulator-related pins
>> on the add-on pinout. There's only USB DM and DP pins.
>>
>> So the Vbus must be directly connected to +5V.
>
> So yes, it is.
>
> But I think the question is moot anyways, since we don't provide DT
> support for that add-on board at that point anyways.
> One could imagine another board, though, which has regulators switched
> by GPIOs, but that would be their problem and they would have regulators
> specified in their specific DT snippet, then.
>
> So to summarize:
> - For that specific Orange Pi Zero board which we discuss the DT for
> there is no regulator support for the additional USB ports. Thus nothing
> we could turn off to save power.
> - A user could just take these USB brackets with pin headers that are so
> common in PCs to connect additional USB ports to the back of the box.
> One just needs to re-sort the pins, which is a matter of a minute.
> - As long as we don't provide any easy way of handling DT changes, we
> should enable the USB ports for the sake of the users of either those
> brackets or the expansion board. Any more sophisticated USB expansion
> board with regulators would need to amend the DT anyway.
>
> Does that make sense?

Sounds good to me.

ChenYu

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751668AbcLEIyM (ORCPT <rfc822;w@1wt.eu>);
        Mon, 5 Dec 2016 03:54:12 -0500
Received: from mail.free-electrons.com ([62.4.15.54]:42569 "EHLO
        mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750928AbcLEIw5 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 5 Dec 2016 03:52:57 -0500
Date: Mon, 5 Dec 2016 09:52:55 +0100
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Icenowy Zheng <icenowy@aosc.xyz>
Cc: =?iso-8859-1?Q?Andr=E9?= Przywara <andre.przywara@arm.com>,
        Jonathan Corbet <corbet@lwn.net>, Chen-Yu Tsai <wens@csie.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Russell King <linux@armlinux.org.uk>,
        Hans de Goede <hdegoede@redhat.com>,
        Vishnu Patekar <vishnupatekar0510@gmail.com>,
        Arnd Bergmann <arnd@arndb.de>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero
 board
Message-ID: <20161205085255.ij3du3if2ss3q3h5@lukather>
References: <20161121162421.800-1-icenowy@aosc.xyz>
 <20161121162421.800-2-icenowy@aosc.xyz>
 <5373671480239408@web31m.yandex.ru>
 <cdfd3c65-d473-badb-ea6a-035f7ab79217@arm.com>
 <20161201093619.gs6lmoxtlptp2jr6@lukather>
 <11498641480688550@web2g.yandex.ru>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="baavniebiyjrpcpi"
Content-Disposition: inline
In-Reply-To: <11498641480688550@web2g.yandex.ru>
User-Agent: Mutt/1.6.2-neo (2016-08-21)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


--baavniebiyjrpcpi
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 02, 2016 at 10:22:30PM +0800, Icenowy Zheng wrote:
>=20
>=20
> 01.12.2016, 17:36, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> > On Mon, Nov 28, 2016 at 12:29:07AM +0000, Andr=E9 Przywara wrote:
> >> =A0> Something more interesting happened.
> >> =A0>
> >> =A0> Xunlong made a add-on board for Orange Pi Zero, which exposes the
> >> =A0> two USB Controllers exported at expansion bus as USB Type-A
> >> =A0> connectors.
> >> =A0>
> >> =A0> Also it exposes a analog A/V jack and a microphone.
> >> =A0>
> >> =A0> Should I enable {e,o}hci{2.3} in the device tree?
> >>
> >> =A0Actually we should do this regardless of this extension board. The =
USB
> >> =A0pins are not multiplexed and are exposed on user accessible pins (j=
ust
> >> =A0not soldered, but that's a detail), so I think they qualify for DT
> >> =A0enablement. And even if a user can't use them, it doesn't hurt to h=
ave
> >> =A0them (since they are not multiplexed).
> >
> > My main concern about this is that we'll leave regulators enabled by
> > default, for a minority of users. And that minority will prevent to do
> > a proper power management when the times come since we'll have to keep
> > that behaviour forever.
>=20
> I think these users can add a 'fdt set /xxx/xxx status "disabled" ' .

You can't ask that from the majority of users. These users will take
debian or fedora, install it, and expect everything to work
properly. I would make the opposite argument actually. If someone is
knowledgeable enough to solder the USB pins a connector, then (s)he'll
be able to make that u-boot call.

Maxime

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

--baavniebiyjrpcpi
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJYRSrnAAoJEBx+YmzsjxAgQSkQAJZ9ZqtNLaO0DH0isgGVLgQg
FXI6nF+WKqxv0w0Q91iFu8IfJgAItXUQp45vATtnjDRzDRT9/ktJ4le3NgE40l1s
Bq1aQVZMYRciEpW84RgmR1pViZdnfnvGCdTZwgra6GY2QYt5SgcEZuW37X71e0Ow
dltb6ziSbiLVThK8FwgRRmHwqDnulwc1UAuy9YD54je+27tSOLs8HmYrDqNYLzh5
Ie2U6QhRpjSi6f9IaprvhvPcm8PtvOWnDHhKSWvk4FZCJZWVKqlqss7Hy8GPi/3g
Emtpj6kZ+ioGYihLgYkf6eU1IYV2fJTvkb+y/nyl//YpQMGhVnrC6/KuUVAawY+h
eou7dEQzPTnUwW0xUwRPetnx/alvtAQguCskW1b/ziB+nn5zdkxIFV52qXF/abK6
hUrbiu4oOu6t5sGeZkLTWwHJ7VcYxvl+yx6k/d/xEjaD+l8xFiVEXnfUkgqT5KoR
cJLJ2wjANrTolHAbSOHZYFlafptnfan9St2cI5Q9vR4xXoC2ut7iW8+WT19Y1KHE
/aIhGx2KXCz7prZhQPFP0wMOhqq9VUgR0LWuA1vHTIA69R45vz/7lQ40znVfykcK
n8cBZK8povn+Z7xFyITyyPA+5PhYRP+DPQ9Uek9u9QTPYY0tikNfaNJVypH3G+hS
qP2GaL0pCPYnNh2LxQZT
=4yTS
-----END PGP SIGNATURE-----

--baavniebiyjrpcpi--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752008AbcLEJFy (ORCPT <rfc822;w@1wt.eu>);
        Mon, 5 Dec 2016 04:05:54 -0500
Received: from mail.free-electrons.com ([62.4.15.54]:42965 "EHLO
        mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751127AbcLEJFd (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 5 Dec 2016 04:05:33 -0500
Date: Mon, 5 Dec 2016 10:05:30 +0100
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Andre Przywara <andre.przywara@arm.com>
Cc: Icenowy Zheng <icenowy@aosc.xyz>, Hans de Goede <hdegoede@redhat.com>,
        Jonathan Corbet <corbet@lwn.net>, Chen-Yu Tsai <wens@csie.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Russell King <linux@armlinux.org.uk>,
        Vishnu Patekar <vishnupatekar0510@gmail.com>,
        Arnd Bergmann <arnd@arndb.de>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero
 board
Message-ID: <20161205090530.oleu2n3a7g4qtgta@lukather>
References: <20161121162421.800-1-icenowy@aosc.xyz>
 <20161121162421.800-2-icenowy@aosc.xyz>
 <5373671480239408@web31m.yandex.ru>
 <cdfd3c65-d473-badb-ea6a-035f7ab79217@arm.com>
 <20161201093619.gs6lmoxtlptp2jr6@lukather>
 <11498641480688550@web2g.yandex.ru>
 <efb30303-b9bb-7a7c-4478-af485991dd86@redhat.com>
 <11535601480689127@web2g.yandex.ru>
 <324c8820-aeea-3fad-0e02-1bdb8f675677@arm.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="3zwp3rg36ovyqmya"
Content-Disposition: inline
In-Reply-To: <324c8820-aeea-3fad-0e02-1bdb8f675677@arm.com>
User-Agent: Mutt/1.6.2-neo (2016-08-21)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


--3zwp3rg36ovyqmya
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 02, 2016 at 04:10:46PM +0000, Andre Przywara wrote:
> Hi,
>=20
> On 02/12/16 14:32, Icenowy Zheng wrote:
> >=20
> >=20
> > 02.12.2016, 22:30, "Hans de Goede" <hdegoede@redhat.com>:
> >> Hi,
> >>
> >> On 02-12-16 15:22, Icenowy Zheng wrote:
> >>>  01.12.2016, 17:36, "Maxime Ripard" <maxime.ripard@free-electrons.com=
>:
> >>>>  On Mon, Nov 28, 2016 at 12:29:07AM +0000, Andr=E9 Przywara wrote:
> >>>>>   > Something more interesting happened.
> >>>>>   >
> >>>>>   > Xunlong made a add-on board for Orange Pi Zero, which exposes t=
he
> >>>>>   > two USB Controllers exported at expansion bus as USB Type-A
> >>>>>   > connectors.
> >>>>>   >
> >>>>>   > Also it exposes a analog A/V jack and a microphone.
> >>>>>   >
> >>>>>   > Should I enable {e,o}hci{2.3} in the device tree?
> >>>>>
> >>>>>   Actually we should do this regardless of this extension board. Th=
e USB
> >>>>>   pins are not multiplexed and are exposed on user accessible pins =
(just
> >>>>>   not soldered, but that's a detail), so I think they qualify for DT
> >>>>>   enablement. And even if a user can't use them, it doesn't hurt to=
 have
> >>>>>   them (since they are not multiplexed).
> >>>>
> >>>>  My main concern about this is that we'll leave regulators enabled by
> >>>>  default, for a minority of users. And that minority will prevent to=
 do
> >>>>  a proper power management when the times come since we'll have to k=
eep
> >>>>  that behaviour forever.
> >>>
> >>>  I think these users can add a 'fdt set /xxx/xxx status "disabled" ' .
> >>
> >> I don't think that will be necessary I'm pretty sure these extra usb
> >> ports do not have a regulator for the Vbus, they just hook directly
> >> to the 5V rail, can someone with a schematic check ?
> >=20
> > We seems to have still no schematics for the add-on board.
>=20
> From looking at the picture of that expansion board on the Aliexpress
> page and chasing the tracks, there is clearly no voltage regulator on
> there, it's just passive components. The 5V pin from the headers is
> routed forth and back between the two layers via some vias directly to
> the 5V pins of the USB sockets.
>=20
> > But something is sure is that there's no any regulator-related pins
> > on the add-on pinout. There's only USB DM and DP pins.
> >=20
> > So the Vbus must be directly connected to +5V.
>=20
> So yes, it is.
>=20
> But I think the question is moot anyways, since we don't provide DT
> support for that add-on board at that point anyways.
> One could imagine another board, though, which has regulators switched
> by GPIOs, but that would be their problem and they would have regulators
> specified in their specific DT snippet, then.
>=20
> So to summarize:
> - For that specific Orange Pi Zero board which we discuss the DT for
> there is no regulator support for the additional USB ports. Thus nothing
> we could turn off to save power.
> - A user could just take these USB brackets with pin headers that are so
> common in PCs to connect additional USB ports to the back of the box.
> One just needs to re-sort the pins, which is a matter of a minute.
> - As long as we don't provide any easy way of handling DT changes, we
> should enable the USB ports for the sake of the users of either those
> brackets or the expansion board. Any more sophisticated USB expansion
> board with regulators would need to amend the DT anyway.

I disagree with this. We already have different ways of changing the
DT at runtime, and even if we didn't I'd still disagree. Once you add
that, there's simply no going back. Saying "let's enable it and we'll
figure it out later" doesn't work, and is essentially a "enable it".

So what you're suggesting is to have those regulators enabled forever,
which might be the case on that board anyway, but definitely shouldn't
be policy.

Maxime

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

--3zwp3rg36ovyqmya
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJYRS3VAAoJEBx+YmzsjxAg0JsQAKI6o7G6Q6kjHeQfCyedZUph
Or0TlN4Kc/m5T+sPnxbPpNTNJtCjcX8Ws/+BTCNaM3ZkNSQOxGYjssaxyoolIy9d
IWp91RmTo1di9LrrfdX/4jR8/YjTLl/FlvTEEJVhpwIdaem1JQzF8VUGeWFkbC2/
er/5j2ZfREUa5JsFdie24+/N9m7nATEMUv7vY/cmA3UgMBQCdjquqibEU3Lff54a
ynPH9L1DwHFYQpN8A/E1NnW3qotfrnusX/CGXXYCbgA2ZdoTrVwJRiig0zI5TKEC
Xk6U1ngMeOBZQNdQQUe9gvLQE8AEjRym9O5iyvvddiU0EyABUd9IBvMZyOqT1WhP
yKFrs3vwLtE2aOBzmxv8WcEth2EzDoKKLCMvr/p6jB5fgVob0hgeNEyqXEOc+2a7
rrcfWIaIlPbO18z+tYp2nOeFcaoWcAOA9PjrMD7lFpxdf3DfHk6n8QDVFczysDit
klXQyK2V2luTw4056hAMh/xE9azRw4ndFAfRqWW7HY3n5NampIGDcQLmTRn6pSSe
ixlpLWOl98l7xSBkudnNNG4b1S5gn1ScgDBPN77HgurluublhJpWmoOca4yvR5oH
nGJpOA7y2EcYZNzAB0kHzi4kJbgZtIGoDCOYRPFZhIjhnCZ3Vu9G9Sna9zI0mtIJ
d76GfNPPoziCQqdeOvuO
=LK+5
-----END PGP SIGNATURE-----

--3zwp3rg36ovyqmya--

