Re: [PATCH v2 1/3] ARM: sunxi: add support for H2+ SoC
Hi, On Tue, Nov 22, 2016 at 12:24:19AM +0800, Icenowy Zheng wrote: > Allwinner H2+ is a quad-core Cortex-A7 SoC. > > 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. > > Signed-off-by: Icenowy Zheng > --- > Documentation/arm/sunxi/README | 4 > Documentation/devicetree/bindings/arm/sunxi.txt | 1 + > arch/arm/mach-sunxi/sunxi.c | 1 + > 3 files changed, 6 insertions(+) > > diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README > 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%201.1.pdf > > + - 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" >- 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/Documentation/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 -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH 3/3] ARM: dts: sunxi: enable SDIO Wi-Fi on Orange Pi Zero
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
> ---
> 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 = <330>;
> + regulator-max-microvolt = <330>;
> + 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 = <®_vcc_wifi>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";
> +};
> +
> +&mmc1_pins_a {
> + allwinner,pull = ;
This should be bias-pull-up.
> +};
> +
> &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.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH] docs-rst: add documentation about how to insert images
Em Wed, 23 Nov 2016 08:34:11 +0100 Daniel Vetter escreveu: > On Mon, Nov 21, 2016 at 05:42:07PM -0200, Mauro Carvalho Chehab wrote: > > Em Mon, 21 Nov 2016 17:03:55 +0100 > > Daniel Vetter escreveu: > > > I'm a complete noob with buildsystems, but can't we do some magic that > > > just unconditionally converst all the .dot and .svg files, as needed? > > > > Well, we could call find to discover all *.svg files under Documentation, > > calling something like: > > find Documentation/ -name '*.svg' |grep -v /output > > > > However, there are some SVG files under two directories: > > > > Documentation/blockdev/drbd/ > > Documentation/RCU/ > > > > We might do something more complex that would grep the image names > > at the ReST file, but that would be too hacky, IMHO. > > > > That aren't part of the Sphinx build system yet. So, we would end > > by either needing to explicitly excluding them on the command shell > > or to create some files that would never be used. > > Yeah I considered this, but imo that's not too bad really. As long as we > clean up the resulting mess again (which we can again do with a find, once > we've made sure all the checked-in binaries are gone). It's not perfect, > but for documentation easy-of-use for adding new diagrams imo trumps that > slight issue. The patch doing that is really simple. See enclosed. I placed it on the top of the previous ones. You can get all of them at: https://git.linuxtv.org/mchehab/experimental.git/log/?h=svg-images-v2 This is the output of it, for pdfdocs make target: GENPDF Documentation/RCU/Design/Data-Structures/blkd_task.svg GENPDF Documentation/RCU/Design/Data-Structures/TreeMapping.svg GENPDF Documentation/RCU/Design/Data-Structures/HugeTreeClassicRCU.svg GENPDF Documentation/RCU/Design/Data-Structures/TreeLevel.svg GENPDF Documentation/RCU/Design/Data-Structures/BigTreeClassicRCU.svg GENPDF Documentation/RCU/Design/Data-Structures/BigTreePreemptRCUBHdyntickCB.svg GENPDF Documentation/RCU/Design/Data-Structures/nxtlist.svg GENPDF Documentation/RCU/Design/Data-Structures/BigTreeClassicRCUBHdyntick.svg GENPDF Documentation/RCU/Design/Data-Structures/TreeMappingLevel.svg GENPDF Documentation/RCU/Design/Data-Structures/BigTreeClassicRCUBH.svg GENPDF Documentation/RCU/Design/Requirements/ReadersPartitionGP1.svg GENPDF Documentation/RCU/Design/Data-Structures/BigTreePreemptRCUBHdyntick.svg GENPDF Documentation/RCU/Design/Requirements/GPpartitionReaders1.svg GENPDF Documentation/media/typical_media_device.svg GENPDF Documentation/media/uapi/dvb/dvbstb.svg GENPDF Documentation/media/uapi/v4l/bayer.svg GENPDF Documentation/media/uapi/v4l/subdev-image-processing-crop.svg GENPDF Documentation/media/uapi/v4l/fieldseq_bt.svg GENPDF Documentation/media/uapi/v4l/constraints.svg GENPDF Documentation/media/uapi/v4l/vbi_hsync.svg GENPDF Documentation/media/uapi/v4l/nv12mt_example.svg GENPDF Documentation/media/uapi/v4l/vbi_625.svg GENPDF Documentation/media/uapi/v4l/vbi_525.svg GENPDF Documentation/media/uapi/v4l/subdev-image-processing-full.svg GENPDF Documentation/media/uapi/v4l/nv12mt.svg GENPDF Documentation/media/uapi/v4l/fieldseq_tb.svg GENPDF Documentation/media/uapi/v4l/crop.svg GENPDF Documentation/media/uapi/v4l/subdev-image-processing-scaling-multi-source.svg GENPDF Documentation/media/uapi/v4l/selection.svg GENPDF Documentation/blockdev/drbd/DRBD-data-packets.svg GENPDF Documentation/blockdev/drbd/DRBD-8.3-data-packets.svg DOT Documentation/scsi/scsi_transport_srp/rport_state_diagram.dot DOT Documentation/media/uapi/v4l/pipeline.dot DOT Documentation/blockdev/drbd/conn-states-8.dot DOT Documentation/blockdev/drbd/drbd-connection-state-overview.dot DOT Documentation/blockdev/drbd/node-states-8.dot DOT Documentation/blockdev/drbd/disk-states-8.dot GENPDF Documentation/scsi/scsi_transport_srp/rport_state_diagram.svg GENPDF Documentation/media/uapi/v4l/pipeline.svg GENPDF Documentation/blockdev/drbd/drbd-connection-state-overview.svg GENPDF Documentation/blockdev/drbd/conn-states-8.svg GENPDF Documentation/blockdev/drbd/node-states-8.svg GENPDF Documentation/blockdev/drbd/disk-states-8.svg SPHINX latexdocs --> file:///devel/v4l/docs/Documentation/output/latex > > It could be simpler if someone would convert the stuff there to > > ReST. > > > > > A bit a hack, but would avoid the most of the above integration trickery. > > > And once we've resolved that, we could maybe do a small kernel-figure > > > extension, which does the alt tags automatically? > > > > That would indeed work better, as just adding the tag at sphinx would > > be enough, but I'm not familiar enough with Python to write it. > > Some day I may have enough reasons to dedicate some time to study > > Python, but such day didn't arrive yet, as I don't have any other > > demand that would require it. So, I
Re: [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
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
>> ---
>> 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 000..b428e47
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>> @@ -0,0 +1,137 @@
>> +/*
>> + * Copyright (C) 2016 Icenowy Zheng
>> + *
>> + * Based on sun8i-h3-orangepi-one.dts, which is:
>> + * Copyright (C) 2016 Hans de Goede
>> + *
>> + * 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
>> +#include
>> +#include
>> +
>> +/ {
>> +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_pin
Re: [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
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
> ---
> 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 000..b428e47
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
> @@ -0,0 +1,137 @@
> +/*
> + * Copyright (C) 2016 Icenowy Zheng
> + *
> + * Based on sun8i-h3-orangepi-one.dts, which is:
> + * Copyright (C) 2016 Hans de Goede
> + *
> + * 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
> +#include
> +#include
> +
> +/ {
> + 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 = <®_vcc3v3>;
> + bus-width = <4>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
> + cd-in
Re: [PATCH 3/3] ARM: dts: sunxi: enable SDIO Wi-Fi on Orange Pi Zero
Hi,
On 23-11-16 15:25, Chen-Yu Tsai wrote:
On Wed, Nov 23, 2016 at 3:59 PM, Maxime Ripard
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
---
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 = <330>;
+ regulator-max-microvolt = <330>;
+ 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 = <®_vcc_wifi>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+};
+
+&mmc1_pins_a {
+ allwinner,pull = ;
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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: sunxi: enable SDIO Wi-Fi on Orange Pi Zero
On Wed, Nov 23, 2016 at 3:59 PM, Maxime Ripard
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
>> ---
>> 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 = <330>;
>> + regulator-max-microvolt = <330>;
>> + 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 = <®_vcc_wifi>;
>> + mmc-pwrseq = <&wifi_pwrseq>;
>> + bus-width = <4>;
>> + non-removable;
>> + status = "okay";
>> +};
>> +
>> +&mmc1_pins_a {
>> + allwinner,pull = ;
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Documentation/sphinx: prevent generation of .pyc files in the source tree
Use PYTHONDONTWRITEBYTECODE=1 to prevent python from creating .pyc files in the source tree. Python 3.2 has a __pycache__ scheme [1], but before that the only alternative seems to be to copy the source files to the build tree to ensure the .pyc files are created there too. Just prevent .pyc file generation for simplicity. Considering the small amount of python code to compile (assuming sphinx itself has .pyc around), the impact on build is neglible. [1] http://stackoverflow.com/questions/3522079/changing-the-directory-where-pyc-files-are-created References: http://lkml.kernel.org/r/camuhmdvxqph7-9xj+ye_pgoa+-fe0969cskoehyh3uubycr...@mail.gmail.com Reported-by: Geert Uytterhoeven Signed-off-by: Jani Nikula --- v2: rebase --- Documentation/Makefile.sphinx | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx index a23d3c8b4848..b5330227c036 100644 --- a/Documentation/Makefile.sphinx +++ b/Documentation/Makefile.sphinx @@ -55,6 +55,7 @@ loop_cmd = $(echo-cmd) $(cmd_$(1)) quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath $(BUILDDIR)/$3/$4) cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/media $2;\ + PYTHONDONTWRITEBYTECODE=1 \ BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath $(srctree)/$(src)/$5/$(SPHINX_CONF)) \ $(SPHINXBUILD) \ -b $2 \ -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] mux controller abstraction and iio/i2c muxes
On 2016-11-22 21:58, Lars-Peter Clausen wrote: > On 11/21/2016 02:17 PM, Peter Rosin wrote: > [...] >> I have a piece of hardware that is using the same 3 GPIO pins >> to control four 8-way muxes. Three of them control ADC lines >> to an ADS1015 chip with an iio driver, and the last one >> controls the SDA line of an i2c bus. We have some deployed >> code to handle this, but you do not want to see it or ever >> hear about it. I'm not sure why I even mention it. Anyway, >> the situation has nagged me to no end for quite some time. >> >> So, after first getting more intimate with the i2c muxing code >> and later discovering the drivers/iio/inkern.c file and >> writing a couple of drivers making use of it, I came up with >> what I think is an acceptable solution; add a generic mux >> controller driver (and subsystem) that is shared between all >> instances, and combine that with an iio mux driver and a new >> generic i2c mux driver. The new i2c mux I called "simple" >> since it is only hooking the i2c muxing and the new mux >> controller (much like the alsa simple card driver does for ASoC). > > While abstracting this properly is all nice and good and the way it should > be done, but it also adds a lot of complexity and the devicetree adds a lot > of restrictions on what can actually be represented. This is a characterization without any specifics. But is the characterization true? You have two complaints, complexity and restrictions with bindings. > There is a certain point where the fabric on a PCB becomes so complex that > it deserves to be a device on its own (like the audio fabric drivers). > Especially when the hardware is built with a certain application in mind and > the driver is supposed to impose policy which reflects this application. The > latter can often not properly be described with the primitives the > devicetree can offer. > > And I think your setup is very borderline what can be done in a declarative > way only and it adds a lot of complexity over a more imperative solution in > form of a driver. I think it is worth investigating about having a driver > that is specific to your fabric and handles the interdependencies of the > discrete components. So, there are three "new" concepts: 1. Sticking a mux in front of an AD-converter. That's not all that novel, nor complex. Quite the opposite, I'd say. In fact, I find it a bit amazing that there is no in-kernel support for it. 2. Reusing the same GPIO-pins to drive different muxes. There are obviously chips that work this way (as Jonathan pointed out) and these will at some point get used in Linux devices. I guess they already are used, but that people handle them in userspace. Or something? If this is complex, which I question, it will still need support at some point. At least that's what I believe. 3. Using the same GPIO pins to mux things handled by different subsystems. Right, this is a bit crazy, and I'd rather not have this requirement, but this HW is what it is so I'll need to handle it in some way. It is also what stops me from falling back to a userspace solution, which is probably connected to why #1 and #2 is not supported by the kernel; everybody probably does muxing in userspace. Which is not necessarily a good idea, nor how it's supposed to be done... So, the only thing that's out of the ordinary (as I see it), is #3. The question that then needs an answer is how the in-kernel solution for #1 and #2 would look if we do not consider #3. And I claim that the desired solution to #1 and #2 is pretty close to my proposal. A. You do not want mux-controller drivers in every subsystem that needs them. B. You do not want every mux-consumer to know the specifics of how to operate every kind of mux; there are muxes that are not controlled with GPIO pins... C. When you implement muxing in a subsystem, there will in some cases be a need to handle parallel muxing, where there is a need to share mux-controllers. It just feels right to separate out the mux-controller and refer to it from where a mux is needed. It solves #1 and #2. And, of course, as a bonus #3 is also solved. But my bias is obvious. And that leads us to the restrictions with the bindings. And the same thing happens; the solution for #2 also solves #3. So how do you refer to a mux-controller from where it's needed? My first proposal used a dt phandle, for the second round I put them in the parent node. It would be super if it was possible for the mux- consumer to create the mux-controller device from the same dt node that is already bound to the mux-consumer. The problem is that the mux-consumer should not hard-code which mux-controller device it should create. The best I can think of is some kind of 'mux-compatible' attribute, that works like the standard 'compatible' attribute. That would simplify the bindings for the normal case (#1) where the mux- controller isn't shared (#2 and #3). Maybe it's possible to fix this issue somehow? I simply don't know? Cheers, P
