* [PATCH 0/3] ARM: dts: sun8i: Add dt nodes for sdio wifi @ 2016-08-26 14:52 ` Hans de Goede 0 siblings, 0 replies; 26+ messages in thread From: Hans de Goede @ 2016-08-26 14:52 UTC (permalink / raw) To: linux-arm-kernel Hi Maxime, Now that Ulf has merged the post-power-on-delay-ms mmc-pwrseq patches in his mmc/next tree and Rob Herring has accepted the esp8089 dt bindings (and specifically the esp,crystal-26M-en property), these are ready for merging. Thanks & Regards, Hans ^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 0/3] ARM: dts: sun8i: Add dt nodes for sdio wifi @ 2016-08-26 14:52 ` Hans de Goede 0 siblings, 0 replies; 26+ messages in thread From: Hans de Goede @ 2016-08-26 14:52 UTC (permalink / raw) To: Chen-Yu Tsai, Maxime Ripard; +Cc: devicetree, linux-arm-kernel Hi Maxime, Now that Ulf has merged the post-power-on-delay-ms mmc-pwrseq patches in his mmc/next tree and Rob Herring has accepted the esp8089 dt bindings (and specifically the esp,crystal-26M-en property), these are ready for merging. Thanks & Regards, Hans ^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 1/3] ARM: dts: sun8i: Add dt node for esp8089 wifi chip on polaroid-mid2407 2016-08-26 14:52 ` Hans de Goede @ 2016-08-26 14:52 ` Hans de Goede -1 siblings, 0 replies; 26+ messages in thread From: Hans de Goede @ 2016-08-26 14:52 UTC (permalink / raw) To: linux-arm-kernel The polaroid-mid2407 tablet has an esp8089 wifi chip, add a dt node describing it. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- .../boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts | 42 ++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/arch/arm/boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts b/arch/arm/boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts index e300442..4789aac 100644 --- a/arch/arm/boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts +++ b/arch/arm/boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts @@ -47,4 +47,46 @@ / { model = "Polaroid MID2407PXE03 tablet"; compatible = "polaroid,mid2407pxe03", "allwinner,sun8i-a23"; + + aliases { + ethernet0 = &esp8089; + }; + + wifi_pwrseq: wifi_pwrseq { + compatible = "mmc-pwrseq-simple"; + pinctrl-names = "default"; + pinctrl-0 = <&wifi_pwrseq_pin_mid2407>; + reset-gpios = <&r_pio 0 6 GPIO_ACTIVE_LOW>; /* PL6 */ + /* The esp8089 needs 200 ms after driving wifi-en high */ + post-power-on-delay-ms = <200>; + }; +}; + +&mmc1 { + pinctrl-names = "default"; + pinctrl-0 = <&mmc1_pins_a>; + vmmc-supply = <®_dldo1>; + mmc-pwrseq = <&wifi_pwrseq>; + bus-width = <4>; + non-removable; + status = "okay"; + + esp8089: sdio_wifi at 1 { + compatible = "esp,esp8089"; + reg = <1>; + esp,crystal-26M-en = <2>; + }; +}; + +&mmc1_pins_a { + allwinner,pull = <SUN4I_PINCTRL_PULL_UP>; +}; + +&r_pio { + wifi_pwrseq_pin_mid2407: wifi_pwrseq_pin at 0 { + allwinner,pins = "PL6"; + allwinner,function = "gpio_out"; + allwinner,drive = <SUN4I_PINCTRL_10_MA>; + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; + }; }; -- 2.9.3 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH 1/3] ARM: dts: sun8i: Add dt node for esp8089 wifi chip on polaroid-mid2407 @ 2016-08-26 14:52 ` Hans de Goede 0 siblings, 0 replies; 26+ messages in thread From: Hans de Goede @ 2016-08-26 14:52 UTC (permalink / raw) To: Chen-Yu Tsai, Maxime Ripard; +Cc: devicetree, linux-arm-kernel, Hans de Goede The polaroid-mid2407 tablet has an esp8089 wifi chip, add a dt node describing it. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- .../boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts | 42 ++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/arch/arm/boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts b/arch/arm/boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts index e300442..4789aac 100644 --- a/arch/arm/boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts +++ b/arch/arm/boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts @@ -47,4 +47,46 @@ / { model = "Polaroid MID2407PXE03 tablet"; compatible = "polaroid,mid2407pxe03", "allwinner,sun8i-a23"; + + aliases { + ethernet0 = &esp8089; + }; + + wifi_pwrseq: wifi_pwrseq { + compatible = "mmc-pwrseq-simple"; + pinctrl-names = "default"; + pinctrl-0 = <&wifi_pwrseq_pin_mid2407>; + reset-gpios = <&r_pio 0 6 GPIO_ACTIVE_LOW>; /* PL6 */ + /* The esp8089 needs 200 ms after driving wifi-en high */ + post-power-on-delay-ms = <200>; + }; +}; + +&mmc1 { + pinctrl-names = "default"; + pinctrl-0 = <&mmc1_pins_a>; + vmmc-supply = <®_dldo1>; + mmc-pwrseq = <&wifi_pwrseq>; + bus-width = <4>; + non-removable; + status = "okay"; + + esp8089: sdio_wifi@1 { + compatible = "esp,esp8089"; + reg = <1>; + esp,crystal-26M-en = <2>; + }; +}; + +&mmc1_pins_a { + allwinner,pull = <SUN4I_PINCTRL_PULL_UP>; +}; + +&r_pio { + wifi_pwrseq_pin_mid2407: wifi_pwrseq_pin@0 { + allwinner,pins = "PL6"; + allwinner,function = "gpio_out"; + allwinner,drive = <SUN4I_PINCTRL_10_MA>; + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; + }; }; -- 2.9.3 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH 1/3] ARM: dts: sun8i: Add dt node for esp8089 wifi chip on polaroid-mid2407 @ 2016-08-26 22:35 ` Maxime Ripard 0 siblings, 0 replies; 26+ messages in thread From: Maxime Ripard @ 2016-08-26 22:35 UTC (permalink / raw) To: linux-arm-kernel On Fri, Aug 26, 2016 at 04:52:34PM +0200, Hans de Goede wrote: > The polaroid-mid2407 tablet has an esp8089 wifi chip, > add a dt node describing it. > > Signed-off-by: Hans de Goede <hdegoede@redhat.com> Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160827/6fec7e29/attachment.sig> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 1/3] ARM: dts: sun8i: Add dt node for esp8089 wifi chip on polaroid-mid2407 @ 2016-08-26 22:35 ` Maxime Ripard 0 siblings, 0 replies; 26+ messages in thread From: Maxime Ripard @ 2016-08-26 22:35 UTC (permalink / raw) To: Hans de Goede Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree [-- Attachment #1: Type: text/plain, Size: 372 bytes --] On Fri, Aug 26, 2016 at 04:52:34PM +0200, Hans de Goede wrote: > The polaroid-mid2407 tablet has an esp8089 wifi chip, > add a dt node describing it. > > Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 2/3] ARM: dts: sun8i: Add dt node for esp8089 wifi chip on polaroid-mid2809 2016-08-26 14:52 ` Hans de Goede @ 2016-08-26 14:52 ` Hans de Goede -1 siblings, 0 replies; 26+ messages in thread From: Hans de Goede @ 2016-08-26 14:52 UTC (permalink / raw) To: linux-arm-kernel The polaroid-mid2809 tablet has an esp8089 wifi chip, add a dt node describing it. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- .../boot/dts/sun8i-a23-polaroid-mid2809pxe04.dts | 42 ++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/arch/arm/boot/dts/sun8i-a23-polaroid-mid2809pxe04.dts b/arch/arm/boot/dts/sun8i-a23-polaroid-mid2809pxe04.dts index 6d06e24..c9213ca 100644 --- a/arch/arm/boot/dts/sun8i-a23-polaroid-mid2809pxe04.dts +++ b/arch/arm/boot/dts/sun8i-a23-polaroid-mid2809pxe04.dts @@ -47,4 +47,46 @@ / { model = "Polaroid MID2809PXE04 tablet"; compatible = "polaroid,mid2809pxe04", "allwinner,sun8i-a23"; + + aliases { + ethernet0 = &esp8089; + }; + + wifi_pwrseq: wifi_pwrseq { + compatible = "mmc-pwrseq-simple"; + pinctrl-names = "default"; + pinctrl-0 = <&wifi_pwrseq_pin_mid2809>; + reset-gpios = <&r_pio 0 6 GPIO_ACTIVE_LOW>; /* PL6 */ + /* The esp8089 needs 200 ms after driving wifi-en high */ + post-power-on-delay-ms = <200>; + }; +}; + +&mmc1 { + pinctrl-names = "default"; + pinctrl-0 = <&mmc1_pins_a>; + vmmc-supply = <®_dldo1>; + mmc-pwrseq = <&wifi_pwrseq>; + bus-width = <4>; + non-removable; + status = "okay"; + + esp8089: sdio_wifi at 1 { + compatible = "esp,esp8089"; + reg = <1>; + esp,crystal-26M-en = <2>; + }; +}; + +&mmc1_pins_a { + allwinner,pull = <SUN4I_PINCTRL_PULL_UP>; +}; + +&r_pio { + wifi_pwrseq_pin_mid2809: wifi_pwrseq_pin at 0 { + allwinner,pins = "PL6"; + allwinner,function = "gpio_out"; + allwinner,drive = <SUN4I_PINCTRL_10_MA>; + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; + }; }; -- 2.9.3 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH 2/3] ARM: dts: sun8i: Add dt node for esp8089 wifi chip on polaroid-mid2809 @ 2016-08-26 14:52 ` Hans de Goede 0 siblings, 0 replies; 26+ messages in thread From: Hans de Goede @ 2016-08-26 14:52 UTC (permalink / raw) To: Chen-Yu Tsai, Maxime Ripard; +Cc: devicetree, linux-arm-kernel, Hans de Goede The polaroid-mid2809 tablet has an esp8089 wifi chip, add a dt node describing it. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- .../boot/dts/sun8i-a23-polaroid-mid2809pxe04.dts | 42 ++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/arch/arm/boot/dts/sun8i-a23-polaroid-mid2809pxe04.dts b/arch/arm/boot/dts/sun8i-a23-polaroid-mid2809pxe04.dts index 6d06e24..c9213ca 100644 --- a/arch/arm/boot/dts/sun8i-a23-polaroid-mid2809pxe04.dts +++ b/arch/arm/boot/dts/sun8i-a23-polaroid-mid2809pxe04.dts @@ -47,4 +47,46 @@ / { model = "Polaroid MID2809PXE04 tablet"; compatible = "polaroid,mid2809pxe04", "allwinner,sun8i-a23"; + + aliases { + ethernet0 = &esp8089; + }; + + wifi_pwrseq: wifi_pwrseq { + compatible = "mmc-pwrseq-simple"; + pinctrl-names = "default"; + pinctrl-0 = <&wifi_pwrseq_pin_mid2809>; + reset-gpios = <&r_pio 0 6 GPIO_ACTIVE_LOW>; /* PL6 */ + /* The esp8089 needs 200 ms after driving wifi-en high */ + post-power-on-delay-ms = <200>; + }; +}; + +&mmc1 { + pinctrl-names = "default"; + pinctrl-0 = <&mmc1_pins_a>; + vmmc-supply = <®_dldo1>; + mmc-pwrseq = <&wifi_pwrseq>; + bus-width = <4>; + non-removable; + status = "okay"; + + esp8089: sdio_wifi@1 { + compatible = "esp,esp8089"; + reg = <1>; + esp,crystal-26M-en = <2>; + }; +}; + +&mmc1_pins_a { + allwinner,pull = <SUN4I_PINCTRL_PULL_UP>; +}; + +&r_pio { + wifi_pwrseq_pin_mid2809: wifi_pwrseq_pin@0 { + allwinner,pins = "PL6"; + allwinner,function = "gpio_out"; + allwinner,drive = <SUN4I_PINCTRL_10_MA>; + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; + }; }; -- 2.9.3 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH 2/3] ARM: dts: sun8i: Add dt node for esp8089 wifi chip on polaroid-mid2809 2016-08-26 14:52 ` Hans de Goede @ 2016-08-26 22:36 ` Maxime Ripard -1 siblings, 0 replies; 26+ messages in thread From: Maxime Ripard @ 2016-08-26 22:36 UTC (permalink / raw) To: linux-arm-kernel On Fri, Aug 26, 2016 at 04:52:35PM +0200, Hans de Goede wrote: > The polaroid-mid2809 tablet has an esp8089 wifi chip, > add a dt node describing it. > > Signed-off-by: Hans de Goede <hdegoede@redhat.com> Applied, Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160827/192cfdd3/attachment.sig> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 2/3] ARM: dts: sun8i: Add dt node for esp8089 wifi chip on polaroid-mid2809 @ 2016-08-26 22:36 ` Maxime Ripard 0 siblings, 0 replies; 26+ messages in thread From: Maxime Ripard @ 2016-08-26 22:36 UTC (permalink / raw) To: Hans de Goede; +Cc: devicetree, Chen-Yu Tsai, linux-arm-kernel [-- Attachment #1.1: Type: text/plain, Size: 343 bytes --] On Fri, Aug 26, 2016 at 04:52:35PM +0200, Hans de Goede wrote: > The polaroid-mid2809 tablet has an esp8089 wifi chip, > add a dt node describing it. > > Signed-off-by: Hans de Goede <hdegoede@redhat.com> Applied, Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 3/3] ARM: dts: sun8i-q8-common: Add support for SDIO wifi controllers 2016-08-26 14:52 ` Hans de Goede @ 2016-08-26 14:52 ` Hans de Goede -1 siblings, 0 replies; 26+ messages in thread From: Hans de Goede @ 2016-08-26 14:52 UTC (permalink / raw) To: linux-arm-kernel Most of the sun8i q8 boards have an usb wifi controller, on the variants which use an USB wifi controller, this will result in a couple of error msg-s in dmesg when proving the sdio bus and an used mmc controller. The best way to deal with wifi on this boards really is to simply let the kernel auto-detect usb or sdio wifi controllers, so we will just have to live with the few errors in dmesg. This has been tested on a23 based q8 tablets with ESP8089, RTL8703AS and RTL8189FTV wifi controllers. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- arch/arm/boot/dts/sun8i-q8-common.dtsi | 49 ++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi b/arch/arm/boot/dts/sun8i-q8-common.dtsi index 60fa958..29f837a 100644 --- a/arch/arm/boot/dts/sun8i-q8-common.dtsi +++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi @@ -42,10 +42,59 @@ #include "sunxi-reference-design-tablet.dtsi" #include "sun8i-reference-design-tablet.dtsi" +/ { + aliases { + serial0 = &r_uart; + /* Make u-boot set mac-address for wifi without an eeprom */ + ethernet0 = &sdio_wifi; + }; + + wifi_pwrseq: wifi_pwrseq { + compatible = "mmc-pwrseq-simple"; + /* + * Q8 boards use various PL# pins as wifi-en. On other boards + * these may be connected to a wifi module output pin. To avoid + * short-circuits we configure these as inputs with pull-ups via + * pinctrl, instead of listing them as active-low reset-gpios. + */ + pinctrl-names = "default"; + pinctrl-0 = <&wifi_pwrseq_pin_q8>; + /* The esp8089 needs 200 ms after driving wifi-en high */ + post-power-on-delay-ms = <200>; + }; +}; + &ehci0 { status = "okay"; }; +&mmc1 { + pinctrl-names = "default"; + pinctrl-0 = <&mmc1_pins_a>; + vmmc-supply = <®_dldo1>; + mmc-pwrseq = <&wifi_pwrseq>; + bus-width = <4>; + non-removable; + status = "okay"; + + sdio_wifi: sdio_wifi at 1 { + reg = <1>; + }; +}; + +&mmc1_pins_a { + allwinner,pull = <SUN4I_PINCTRL_PULL_UP>; +}; + +&r_pio { + wifi_pwrseq_pin_q8: wifi_pwrseq_pin at 0 { + allwinner,pins = "PL6", "PL7", "PL11"; + allwinner,function = "gpio_in"; + allwinner,drive = <SUN4I_PINCTRL_10_MA>; + allwinner,pull = <SUN4I_PINCTRL_PULL_UP>; + }; +}; + &usbphy { usb1_vbus-supply = <®_dldo1>; }; -- 2.9.3 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH 3/3] ARM: dts: sun8i-q8-common: Add support for SDIO wifi controllers @ 2016-08-26 14:52 ` Hans de Goede 0 siblings, 0 replies; 26+ messages in thread From: Hans de Goede @ 2016-08-26 14:52 UTC (permalink / raw) To: Chen-Yu Tsai, Maxime Ripard; +Cc: devicetree, linux-arm-kernel, Hans de Goede Most of the sun8i q8 boards have an usb wifi controller, on the variants which use an USB wifi controller, this will result in a couple of error msg-s in dmesg when proving the sdio bus and an used mmc controller. The best way to deal with wifi on this boards really is to simply let the kernel auto-detect usb or sdio wifi controllers, so we will just have to live with the few errors in dmesg. This has been tested on a23 based q8 tablets with ESP8089, RTL8703AS and RTL8189FTV wifi controllers. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- arch/arm/boot/dts/sun8i-q8-common.dtsi | 49 ++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi b/arch/arm/boot/dts/sun8i-q8-common.dtsi index 60fa958..29f837a 100644 --- a/arch/arm/boot/dts/sun8i-q8-common.dtsi +++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi @@ -42,10 +42,59 @@ #include "sunxi-reference-design-tablet.dtsi" #include "sun8i-reference-design-tablet.dtsi" +/ { + aliases { + serial0 = &r_uart; + /* Make u-boot set mac-address for wifi without an eeprom */ + ethernet0 = &sdio_wifi; + }; + + wifi_pwrseq: wifi_pwrseq { + compatible = "mmc-pwrseq-simple"; + /* + * Q8 boards use various PL# pins as wifi-en. On other boards + * these may be connected to a wifi module output pin. To avoid + * short-circuits we configure these as inputs with pull-ups via + * pinctrl, instead of listing them as active-low reset-gpios. + */ + pinctrl-names = "default"; + pinctrl-0 = <&wifi_pwrseq_pin_q8>; + /* The esp8089 needs 200 ms after driving wifi-en high */ + post-power-on-delay-ms = <200>; + }; +}; + &ehci0 { status = "okay"; }; +&mmc1 { + pinctrl-names = "default"; + pinctrl-0 = <&mmc1_pins_a>; + vmmc-supply = <®_dldo1>; + mmc-pwrseq = <&wifi_pwrseq>; + bus-width = <4>; + non-removable; + status = "okay"; + + sdio_wifi: sdio_wifi@1 { + reg = <1>; + }; +}; + +&mmc1_pins_a { + allwinner,pull = <SUN4I_PINCTRL_PULL_UP>; +}; + +&r_pio { + wifi_pwrseq_pin_q8: wifi_pwrseq_pin@0 { + allwinner,pins = "PL6", "PL7", "PL11"; + allwinner,function = "gpio_in"; + allwinner,drive = <SUN4I_PINCTRL_10_MA>; + allwinner,pull = <SUN4I_PINCTRL_PULL_UP>; + }; +}; + &usbphy { usb1_vbus-supply = <®_dldo1>; }; -- 2.9.3 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH 3/3] ARM: dts: sun8i-q8-common: Add support for SDIO wifi controllers 2016-08-26 14:52 ` Hans de Goede @ 2016-08-29 6:56 ` Maxime Ripard -1 siblings, 0 replies; 26+ messages in thread From: Maxime Ripard @ 2016-08-29 6:56 UTC (permalink / raw) To: linux-arm-kernel On Fri, Aug 26, 2016 at 04:52:36PM +0200, Hans de Goede wrote: > Most of the sun8i q8 boards have an usb wifi controller, on the > variants which use an USB wifi controller, this will result in a > couple of error msg-s in dmesg when proving the sdio bus and > an used mmc controller. > > The best way to deal with wifi on this boards really is to simply > let the kernel auto-detect usb or sdio wifi controllers, so we > will just have to live with the few errors in dmesg. No, because that grabs PINs that might or might not be supposed to be used for that, it leaves clocks and regulators enabled, which draw power, to no end. And that's even worth since most boards will not use it. You can put the definition of the nodes in the DTSI, but the final status will have to be in the (relevant) DTS. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160829/b1c25ce3/attachment.sig> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 3/3] ARM: dts: sun8i-q8-common: Add support for SDIO wifi controllers @ 2016-08-29 6:56 ` Maxime Ripard 0 siblings, 0 replies; 26+ messages in thread From: Maxime Ripard @ 2016-08-29 6:56 UTC (permalink / raw) To: Hans de Goede; +Cc: devicetree, Chen-Yu Tsai, linux-arm-kernel [-- Attachment #1.1: Type: text/plain, Size: 934 bytes --] On Fri, Aug 26, 2016 at 04:52:36PM +0200, Hans de Goede wrote: > Most of the sun8i q8 boards have an usb wifi controller, on the > variants which use an USB wifi controller, this will result in a > couple of error msg-s in dmesg when proving the sdio bus and > an used mmc controller. > > The best way to deal with wifi on this boards really is to simply > let the kernel auto-detect usb or sdio wifi controllers, so we > will just have to live with the few errors in dmesg. No, because that grabs PINs that might or might not be supposed to be used for that, it leaves clocks and regulators enabled, which draw power, to no end. And that's even worth since most boards will not use it. You can put the definition of the nodes in the DTSI, but the final status will have to be in the (relevant) DTS. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 3/3] ARM: dts: sun8i-q8-common: Add support for SDIO wifi controllers 2016-08-29 6:56 ` Maxime Ripard @ 2016-08-29 9:46 ` Hans de Goede -1 siblings, 0 replies; 26+ messages in thread From: Hans de Goede @ 2016-08-29 9:46 UTC (permalink / raw) To: linux-arm-kernel Hi, On 29-08-16 08:56, Maxime Ripard wrote: > On Fri, Aug 26, 2016 at 04:52:36PM +0200, Hans de Goede wrote: >> Most of the sun8i q8 boards have an usb wifi controller, on the >> variants which use an USB wifi controller, this will result in a >> couple of error msg-s in dmesg when proving the sdio bus and >> an used mmc controller. >> >> The best way to deal with wifi on this boards really is to simply >> let the kernel auto-detect usb or sdio wifi controllers, so we >> will just have to live with the few errors in dmesg. > > No, because that grabs PINs that might or might not be supposed to be > used for that, it leaves clocks and regulators enabled, which draw > power, to no end. And that's even worth since most boards will not use > it. > > You can put the definition of the nodes in the DTSI, but the final > status will have to be in the (relevant) DTS. This is again the q8-tablet thing where china produces a new variant every 2 weeks. So we've sun8i-a23-q8-tablet.dts and sun8i-a33-q8-tablet.dts which try to be generic dts files for these tablets, since creating a custom dts per variant is madness. This commit puts the node in sun8i-q8-common.dtsi because the A23 and A33 are pin compatible and we've tablets where the only difference is the SoC soldered on there, the use the _exact_ same PCB and components otherwise, so we have all the sun8i q8 stuff in a common place for sun8i-a23-q8-tablet.dts and sun8i-a33-q8-tablet.dts, those are the only users of this dtsi file. You've already merged the bits which handle the variants with an USB attached wifi module (enabling ehci0 also on boards where nothing is connected). This is the counter-part for PCB's which use a sdio wifi module (about 90% of all boards in my experience). As for turning a regulator on unnecessary, both the wifi and sdio wifi solution use the same regulator, so that is already turned on through the usb bits and it needs to be in either case. The only downside of this approach is that we either have the USB controller turned on unnecessarily (in most cases) or the mmc controller (in the rare A23 tablet which still uses an USB wifi module). This all actually fits neatly into the plans to do hardware autodetection for these tablets which I'm working on, in this case we can just let the kernel handle things without additional code (think the beaglebone capemanager) since both busses are discoverable. Once we have the q8-hardwaremgr I'm working on and hope to post an RFC of soon, we could even make that turn off the unused controller (as a future enhancement). I hope this explains things. Regards, Hans ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 3/3] ARM: dts: sun8i-q8-common: Add support for SDIO wifi controllers @ 2016-08-29 9:46 ` Hans de Goede 0 siblings, 0 replies; 26+ messages in thread From: Hans de Goede @ 2016-08-29 9:46 UTC (permalink / raw) To: Maxime Ripard Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree Hi, On 29-08-16 08:56, Maxime Ripard wrote: > On Fri, Aug 26, 2016 at 04:52:36PM +0200, Hans de Goede wrote: >> Most of the sun8i q8 boards have an usb wifi controller, on the >> variants which use an USB wifi controller, this will result in a >> couple of error msg-s in dmesg when proving the sdio bus and >> an used mmc controller. >> >> The best way to deal with wifi on this boards really is to simply >> let the kernel auto-detect usb or sdio wifi controllers, so we >> will just have to live with the few errors in dmesg. > > No, because that grabs PINs that might or might not be supposed to be > used for that, it leaves clocks and regulators enabled, which draw > power, to no end. And that's even worth since most boards will not use > it. > > You can put the definition of the nodes in the DTSI, but the final > status will have to be in the (relevant) DTS. This is again the q8-tablet thing where china produces a new variant every 2 weeks. So we've sun8i-a23-q8-tablet.dts and sun8i-a33-q8-tablet.dts which try to be generic dts files for these tablets, since creating a custom dts per variant is madness. This commit puts the node in sun8i-q8-common.dtsi because the A23 and A33 are pin compatible and we've tablets where the only difference is the SoC soldered on there, the use the _exact_ same PCB and components otherwise, so we have all the sun8i q8 stuff in a common place for sun8i-a23-q8-tablet.dts and sun8i-a33-q8-tablet.dts, those are the only users of this dtsi file. You've already merged the bits which handle the variants with an USB attached wifi module (enabling ehci0 also on boards where nothing is connected). This is the counter-part for PCB's which use a sdio wifi module (about 90% of all boards in my experience). As for turning a regulator on unnecessary, both the wifi and sdio wifi solution use the same regulator, so that is already turned on through the usb bits and it needs to be in either case. The only downside of this approach is that we either have the USB controller turned on unnecessarily (in most cases) or the mmc controller (in the rare A23 tablet which still uses an USB wifi module). This all actually fits neatly into the plans to do hardware autodetection for these tablets which I'm working on, in this case we can just let the kernel handle things without additional code (think the beaglebone capemanager) since both busses are discoverable. Once we have the q8-hardwaremgr I'm working on and hope to post an RFC of soon, we could even make that turn off the unused controller (as a future enhancement). I hope this explains things. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 3/3] ARM: dts: sun8i-q8-common: Add support for SDIO wifi controllers 2016-08-29 9:46 ` Hans de Goede @ 2016-09-01 20:37 ` Maxime Ripard -1 siblings, 0 replies; 26+ messages in thread From: Maxime Ripard @ 2016-09-01 20:37 UTC (permalink / raw) To: linux-arm-kernel Hi Hans, On Mon, Aug 29, 2016 at 11:46:14AM +0200, Hans de Goede wrote: > On 29-08-16 08:56, Maxime Ripard wrote: > >On Fri, Aug 26, 2016 at 04:52:36PM +0200, Hans de Goede wrote: > >>Most of the sun8i q8 boards have an usb wifi controller, on the > >>variants which use an USB wifi controller, this will result in a > >>couple of error msg-s in dmesg when proving the sdio bus and > >>an used mmc controller. > >> > >>The best way to deal with wifi on this boards really is to simply > >>let the kernel auto-detect usb or sdio wifi controllers, so we > >>will just have to live with the few errors in dmesg. > > > >No, because that grabs PINs that might or might not be supposed to be > >used for that, it leaves clocks and regulators enabled, which draw > >power, to no end. And that's even worth since most boards will not use > >it. > > > >You can put the definition of the nodes in the DTSI, but the final > >status will have to be in the (relevant) DTS. > > This is again the q8-tablet thing where china produces a new variant > every 2 weeks. So we've sun8i-a23-q8-tablet.dts and sun8i-a33-q8-tablet.dts > which try to be generic dts files for these tablets, since creating > a custom dts per variant is madness. This is almost unrelated, and probably some wishful thinking, but I'd really prefer to support *one* board properly, with all its features, rather than supporting every random Allwinner device with half baked support, because no one ever updated the DT, or there's simply no driver. But hey, I can't force you to work on something either :) > This commit puts the node in sun8i-q8-common.dtsi because the > A23 and A33 are pin compatible and we've tablets where the > only difference is the SoC soldered on there, the use the _exact_ > same PCB and components otherwise, so we have all the sun8i q8 > stuff in a common place for sun8i-a23-q8-tablet.dts and > sun8i-a33-q8-tablet.dts, those are the only users of this > dtsi file. > > You've already merged the bits which handle the variants with > an USB attached wifi module (enabling ehci0 also on boards > where nothing is connected). This is the counter-part for > PCB's which use a sdio wifi module (about 90% of all boards > in my experience). I'm confused. Are most boards using an USB wifi chip, like you were stating in your commit log, or an SDIO wifi chip like you just said? > As for turning a regulator on unnecessary, both the wifi and sdio > wifi solution use the same regulator, so that is already turned on > through the usb bits and it needs to be in either case. Ok, so indeed, that's not as bad as it sounds. > The only downside of this approach is that we either have > the USB controller turned on unnecessarily (in most cases) > or the mmc controller (in the rare A23 tablet which still > uses an USB wifi module). > > This all actually fits neatly into the plans to do hardware > autodetection for these tablets which I'm working on, in > this case we can just let the kernel handle things without > additional code (think the beaglebone capemanager) since > both busses are discoverable. > > Once we have the q8-hardwaremgr I'm working on and hope > to post an RFC of soon, we could even make that turn off > the unused controller (as a future enhancement). If that's on your to-do-list, that's fine by me. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160901/9ab81153/attachment.sig> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 3/3] ARM: dts: sun8i-q8-common: Add support for SDIO wifi controllers @ 2016-09-01 20:37 ` Maxime Ripard 0 siblings, 0 replies; 26+ messages in thread From: Maxime Ripard @ 2016-09-01 20:37 UTC (permalink / raw) To: Hans de Goede; +Cc: devicetree, Chen-Yu Tsai, linux-arm-kernel [-- Attachment #1.1: Type: text/plain, Size: 3500 bytes --] Hi Hans, On Mon, Aug 29, 2016 at 11:46:14AM +0200, Hans de Goede wrote: > On 29-08-16 08:56, Maxime Ripard wrote: > >On Fri, Aug 26, 2016 at 04:52:36PM +0200, Hans de Goede wrote: > >>Most of the sun8i q8 boards have an usb wifi controller, on the > >>variants which use an USB wifi controller, this will result in a > >>couple of error msg-s in dmesg when proving the sdio bus and > >>an used mmc controller. > >> > >>The best way to deal with wifi on this boards really is to simply > >>let the kernel auto-detect usb or sdio wifi controllers, so we > >>will just have to live with the few errors in dmesg. > > > >No, because that grabs PINs that might or might not be supposed to be > >used for that, it leaves clocks and regulators enabled, which draw > >power, to no end. And that's even worth since most boards will not use > >it. > > > >You can put the definition of the nodes in the DTSI, but the final > >status will have to be in the (relevant) DTS. > > This is again the q8-tablet thing where china produces a new variant > every 2 weeks. So we've sun8i-a23-q8-tablet.dts and sun8i-a33-q8-tablet.dts > which try to be generic dts files for these tablets, since creating > a custom dts per variant is madness. This is almost unrelated, and probably some wishful thinking, but I'd really prefer to support *one* board properly, with all its features, rather than supporting every random Allwinner device with half baked support, because no one ever updated the DT, or there's simply no driver. But hey, I can't force you to work on something either :) > This commit puts the node in sun8i-q8-common.dtsi because the > A23 and A33 are pin compatible and we've tablets where the > only difference is the SoC soldered on there, the use the _exact_ > same PCB and components otherwise, so we have all the sun8i q8 > stuff in a common place for sun8i-a23-q8-tablet.dts and > sun8i-a33-q8-tablet.dts, those are the only users of this > dtsi file. > > You've already merged the bits which handle the variants with > an USB attached wifi module (enabling ehci0 also on boards > where nothing is connected). This is the counter-part for > PCB's which use a sdio wifi module (about 90% of all boards > in my experience). I'm confused. Are most boards using an USB wifi chip, like you were stating in your commit log, or an SDIO wifi chip like you just said? > As for turning a regulator on unnecessary, both the wifi and sdio > wifi solution use the same regulator, so that is already turned on > through the usb bits and it needs to be in either case. Ok, so indeed, that's not as bad as it sounds. > The only downside of this approach is that we either have > the USB controller turned on unnecessarily (in most cases) > or the mmc controller (in the rare A23 tablet which still > uses an USB wifi module). > > This all actually fits neatly into the plans to do hardware > autodetection for these tablets which I'm working on, in > this case we can just let the kernel handle things without > additional code (think the beaglebone capemanager) since > both busses are discoverable. > > Once we have the q8-hardwaremgr I'm working on and hope > to post an RFC of soon, we could even make that turn off > the unused controller (as a future enhancement). If that's on your to-do-list, that's fine by me. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 3/3] ARM: dts: sun8i-q8-common: Add support for SDIO wifi controllers 2016-09-01 20:37 ` Maxime Ripard @ 2016-09-03 11:33 ` Hans de Goede -1 siblings, 0 replies; 26+ messages in thread From: Hans de Goede @ 2016-09-03 11:33 UTC (permalink / raw) To: linux-arm-kernel Hi Maxime, On 01-09-16 22:37, Maxime Ripard wrote: > Hi Hans, > > On Mon, Aug 29, 2016 at 11:46:14AM +0200, Hans de Goede wrote: >> On 29-08-16 08:56, Maxime Ripard wrote: >>> On Fri, Aug 26, 2016 at 04:52:36PM +0200, Hans de Goede wrote: >>>> Most of the sun8i q8 boards have an usb wifi controller, on the >>>> variants which use an USB wifi controller, this will result in a >>>> couple of error msg-s in dmesg when proving the sdio bus and >>>> an used mmc controller. >>>> >>>> The best way to deal with wifi on this boards really is to simply >>>> let the kernel auto-detect usb or sdio wifi controllers, so we >>>> will just have to live with the few errors in dmesg. >>> >>> No, because that grabs PINs that might or might not be supposed to be >>> used for that, it leaves clocks and regulators enabled, which draw >>> power, to no end. And that's even worth since most boards will not use >>> it. >>> >>> You can put the definition of the nodes in the DTSI, but the final >>> status will have to be in the (relevant) DTS. >> >> This is again the q8-tablet thing where china produces a new variant >> every 2 weeks. So we've sun8i-a23-q8-tablet.dts and sun8i-a33-q8-tablet.dts >> which try to be generic dts files for these tablets, since creating >> a custom dts per variant is madness. > > This is almost unrelated, and probably some wishful thinking, but I'd > really prefer to support *one* board properly, with all its features, > rather than supporting every random Allwinner device with half baked > support, because no one ever updated the DT, or there's simply no > driver. But hey, I can't force you to work on something either :) The q8 tablets are somewhat special, to the end consumer they are one board, but they differ a lot per badge. These are 40 (or less) usd tablets, which get whatever wifi / touchscreen-controller / accelerometer which is cheapest on the Chenzen market when the badge gets produces. For the end user to actually figure out what is in there requires opening the tablet, or poking around with adb to learn the exact internals / drivers used by android. I actually own 10 of these (3 a13, 5 a23, 2 a33) and have access to 2 more a33 models which friends of me have, and they are *all* different. For a list of all tablets I've see: https://github.com/jwrdegoede/sunxi-fedora-scripts/blob/master/hansg-tablet-info Given the price of these they are really nice to thinker with / turn into a little normal linux touch device, so I would like to support them as best as we can in a somewhat user-friendly way. Also see the RFC patch for the q8-hardwaremgr I posted recently. In the end these tablets are the "*one* board" which I'm trying to support properly, except that they are only one board on the outside not on the outside. TL;DR: q8 tablets are special, but also quite popular and I would like to support them properly, which requires some special handling. >> This commit puts the node in sun8i-q8-common.dtsi because the >> A23 and A33 are pin compatible and we've tablets where the >> only difference is the SoC soldered on there, the use the _exact_ >> same PCB and components otherwise, so we have all the sun8i q8 >> stuff in a common place for sun8i-a23-q8-tablet.dts and >> sun8i-a33-q8-tablet.dts, those are the only users of this >> dtsi file. >> >> You've already merged the bits which handle the variants with >> an USB attached wifi module (enabling ehci0 also on boards >> where nothing is connected). This is the counter-part for >> PCB's which use a sdio wifi module (about 90% of all boards >> in my experience). > > I'm confused. Are most boards using an USB wifi chip, like you were > stating in your commit log, or an SDIO wifi chip like you just said? My bad, the commit msg. is wrong of the 9 sun8i q8 tablets I've access to only 1 uses usb wifi. So the first part of the commit msg should read "Most of the sun8i q8 boards have a sdio wifi controller" >> As for turning a regulator on unnecessary, both the wifi and sdio >> wifi solution use the same regulator, so that is already turned on >> through the usb bits and it needs to be in either case. > > Ok, so indeed, that's not as bad as it sounds. > >> The only downside of this approach is that we either have >> the USB controller turned on unnecessarily (in most cases) >> or the mmc controller (in the rare A23 tablet which still >> uses an USB wifi module). >> >> This all actually fits neatly into the plans to do hardware >> autodetection for these tablets which I'm working on, in >> this case we can just let the kernel handle things without >> additional code (think the beaglebone capemanager) since >> both busses are discoverable. >> >> Once we have the q8-hardwaremgr I'm working on and hope >> to post an RFC of soon, we could even make that turn off >> the unused controller (as a future enhancement). > > If that's on your to-do-list, that's fine by me. I've just added it to my to-do list :) So I assume with that done, that you are ok with taking this patch now ? Please fixup the commit msg mistake, or let me know if you want a v2. Regards, Hans ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 3/3] ARM: dts: sun8i-q8-common: Add support for SDIO wifi controllers @ 2016-09-03 11:33 ` Hans de Goede 0 siblings, 0 replies; 26+ messages in thread From: Hans de Goede @ 2016-09-03 11:33 UTC (permalink / raw) To: Maxime Ripard Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree Hi Maxime, On 01-09-16 22:37, Maxime Ripard wrote: > Hi Hans, > > On Mon, Aug 29, 2016 at 11:46:14AM +0200, Hans de Goede wrote: >> On 29-08-16 08:56, Maxime Ripard wrote: >>> On Fri, Aug 26, 2016 at 04:52:36PM +0200, Hans de Goede wrote: >>>> Most of the sun8i q8 boards have an usb wifi controller, on the >>>> variants which use an USB wifi controller, this will result in a >>>> couple of error msg-s in dmesg when proving the sdio bus and >>>> an used mmc controller. >>>> >>>> The best way to deal with wifi on this boards really is to simply >>>> let the kernel auto-detect usb or sdio wifi controllers, so we >>>> will just have to live with the few errors in dmesg. >>> >>> No, because that grabs PINs that might or might not be supposed to be >>> used for that, it leaves clocks and regulators enabled, which draw >>> power, to no end. And that's even worth since most boards will not use >>> it. >>> >>> You can put the definition of the nodes in the DTSI, but the final >>> status will have to be in the (relevant) DTS. >> >> This is again the q8-tablet thing where china produces a new variant >> every 2 weeks. So we've sun8i-a23-q8-tablet.dts and sun8i-a33-q8-tablet.dts >> which try to be generic dts files for these tablets, since creating >> a custom dts per variant is madness. > > This is almost unrelated, and probably some wishful thinking, but I'd > really prefer to support *one* board properly, with all its features, > rather than supporting every random Allwinner device with half baked > support, because no one ever updated the DT, or there's simply no > driver. But hey, I can't force you to work on something either :) The q8 tablets are somewhat special, to the end consumer they are one board, but they differ a lot per badge. These are 40 (or less) usd tablets, which get whatever wifi / touchscreen-controller / accelerometer which is cheapest on the Chenzen market when the badge gets produces. For the end user to actually figure out what is in there requires opening the tablet, or poking around with adb to learn the exact internals / drivers used by android. I actually own 10 of these (3 a13, 5 a23, 2 a33) and have access to 2 more a33 models which friends of me have, and they are *all* different. For a list of all tablets I've see: https://github.com/jwrdegoede/sunxi-fedora-scripts/blob/master/hansg-tablet-info Given the price of these they are really nice to thinker with / turn into a little normal linux touch device, so I would like to support them as best as we can in a somewhat user-friendly way. Also see the RFC patch for the q8-hardwaremgr I posted recently. In the end these tablets are the "*one* board" which I'm trying to support properly, except that they are only one board on the outside not on the outside. TL;DR: q8 tablets are special, but also quite popular and I would like to support them properly, which requires some special handling. >> This commit puts the node in sun8i-q8-common.dtsi because the >> A23 and A33 are pin compatible and we've tablets where the >> only difference is the SoC soldered on there, the use the _exact_ >> same PCB and components otherwise, so we have all the sun8i q8 >> stuff in a common place for sun8i-a23-q8-tablet.dts and >> sun8i-a33-q8-tablet.dts, those are the only users of this >> dtsi file. >> >> You've already merged the bits which handle the variants with >> an USB attached wifi module (enabling ehci0 also on boards >> where nothing is connected). This is the counter-part for >> PCB's which use a sdio wifi module (about 90% of all boards >> in my experience). > > I'm confused. Are most boards using an USB wifi chip, like you were > stating in your commit log, or an SDIO wifi chip like you just said? My bad, the commit msg. is wrong of the 9 sun8i q8 tablets I've access to only 1 uses usb wifi. So the first part of the commit msg should read "Most of the sun8i q8 boards have a sdio wifi controller" >> As for turning a regulator on unnecessary, both the wifi and sdio >> wifi solution use the same regulator, so that is already turned on >> through the usb bits and it needs to be in either case. > > Ok, so indeed, that's not as bad as it sounds. > >> The only downside of this approach is that we either have >> the USB controller turned on unnecessarily (in most cases) >> or the mmc controller (in the rare A23 tablet which still >> uses an USB wifi module). >> >> This all actually fits neatly into the plans to do hardware >> autodetection for these tablets which I'm working on, in >> this case we can just let the kernel handle things without >> additional code (think the beaglebone capemanager) since >> both busses are discoverable. >> >> Once we have the q8-hardwaremgr I'm working on and hope >> to post an RFC of soon, we could even make that turn off >> the unused controller (as a future enhancement). > > If that's on your to-do-list, that's fine by me. I've just added it to my to-do list :) So I assume with that done, that you are ok with taking this patch now ? Please fixup the commit msg mistake, or let me know if you want a v2. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 3/3] ARM: dts: sun8i-q8-common: Add support for SDIO wifi controllers @ 2016-09-05 19:58 ` Maxime Ripard 0 siblings, 0 replies; 26+ messages in thread From: Maxime Ripard @ 2016-09-05 19:58 UTC (permalink / raw) To: linux-arm-kernel Hi, On Sat, Sep 03, 2016 at 01:33:50PM +0200, Hans de Goede wrote: > >On Mon, Aug 29, 2016 at 11:46:14AM +0200, Hans de Goede wrote: > >>On 29-08-16 08:56, Maxime Ripard wrote: > >>>On Fri, Aug 26, 2016 at 04:52:36PM +0200, Hans de Goede wrote: > >>>>Most of the sun8i q8 boards have an usb wifi controller, on the > >>>>variants which use an USB wifi controller, this will result in a > >>>>couple of error msg-s in dmesg when proving the sdio bus and > >>>>an used mmc controller. > >>>> > >>>>The best way to deal with wifi on this boards really is to simply > >>>>let the kernel auto-detect usb or sdio wifi controllers, so we > >>>>will just have to live with the few errors in dmesg. > >>> > >>>No, because that grabs PINs that might or might not be supposed to be > >>>used for that, it leaves clocks and regulators enabled, which draw > >>>power, to no end. And that's even worth since most boards will not use > >>>it. > >>> > >>>You can put the definition of the nodes in the DTSI, but the final > >>>status will have to be in the (relevant) DTS. > >> > >>This is again the q8-tablet thing where china produces a new variant > >>every 2 weeks. So we've sun8i-a23-q8-tablet.dts and sun8i-a33-q8-tablet.dts > >>which try to be generic dts files for these tablets, since creating > >>a custom dts per variant is madness. > > > >This is almost unrelated, and probably some wishful thinking, but I'd > >really prefer to support *one* board properly, with all its features, > >rather than supporting every random Allwinner device with half baked > >support, because no one ever updated the DT, or there's simply no > >driver. But hey, I can't force you to work on something either :) > > The q8 tablets are somewhat special, to the end consumer they > are one board, but they differ a lot per badge. These are 40 (or less) > usd tablets, which get whatever wifi / touchscreen-controller / > accelerometer which is cheapest on the Chenzen market when the > badge gets produces. > > For the end user to actually figure out what is in there requires > opening the tablet, or poking around with adb to learn the exact > internals / drivers used by android. > > I actually own 10 of these (3 a13, 5 a23, 2 a33) and have access > to 2 more a33 models which friends of me have, and they are *all* > different. For a list of all tablets I've see: > https://github.com/jwrdegoede/sunxi-fedora-scripts/blob/master/hansg-tablet-info > > Given the price of these they are really nice to thinker with / > turn into a little normal linux touch device, so I would like to > support them as best as we can in a somewhat user-friendly > way. Also see the RFC patch for the q8-hardwaremgr I posted > recently. In the end these tablets are the "*one* board" > which I'm trying to support properly, except that they are > only one board on the outside not on the outside. > > TL;DR: q8 tablets are special, but also quite popular and > I would like to support them properly, which requires > some special handling. > > >>This commit puts the node in sun8i-q8-common.dtsi because the > >>A23 and A33 are pin compatible and we've tablets where the > >>only difference is the SoC soldered on there, the use the _exact_ > >>same PCB and components otherwise, so we have all the sun8i q8 > >>stuff in a common place for sun8i-a23-q8-tablet.dts and > >>sun8i-a33-q8-tablet.dts, those are the only users of this > >>dtsi file. > >> > >>You've already merged the bits which handle the variants with > >>an USB attached wifi module (enabling ehci0 also on boards > >>where nothing is connected). This is the counter-part for > >>PCB's which use a sdio wifi module (about 90% of all boards > >>in my experience). > > > >I'm confused. Are most boards using an USB wifi chip, like you were > >stating in your commit log, or an SDIO wifi chip like you just said? > > My bad, the commit msg. is wrong of the 9 sun8i q8 tablets I've > access to only 1 uses usb wifi. > > So the first part of the commit msg should read > "Most of the sun8i q8 boards have a sdio wifi controller" > > >>As for turning a regulator on unnecessary, both the wifi and sdio > >>wifi solution use the same regulator, so that is already turned on > >>through the usb bits and it needs to be in either case. > > > >Ok, so indeed, that's not as bad as it sounds. > > > >>The only downside of this approach is that we either have > >>the USB controller turned on unnecessarily (in most cases) > >>or the mmc controller (in the rare A23 tablet which still > >>uses an USB wifi module). > >> > >>This all actually fits neatly into the plans to do hardware > >>autodetection for these tablets which I'm working on, in > >>this case we can just let the kernel handle things without > >>additional code (think the beaglebone capemanager) since > >>both busses are discoverable. > >> > >>Once we have the q8-hardwaremgr I'm working on and hope > >>to post an RFC of soon, we could even make that turn off > >>the unused controller (as a future enhancement). > > > >If that's on your to-do-list, that's fine by me. > > I've just added it to my to-do list :) > > So I assume with that done, that you are ok with taking this > patch now ? Please fixup the commit msg mistake, or let > me know if you want a v2. Yeah, I just applied it and fixed the commit log. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160905/e13d4468/attachment.sig> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 3/3] ARM: dts: sun8i-q8-common: Add support for SDIO wifi controllers @ 2016-09-05 19:58 ` Maxime Ripard 0 siblings, 0 replies; 26+ messages in thread From: Maxime Ripard @ 2016-09-05 19:58 UTC (permalink / raw) To: Hans de Goede Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree [-- Attachment #1: Type: text/plain, Size: 5543 bytes --] Hi, On Sat, Sep 03, 2016 at 01:33:50PM +0200, Hans de Goede wrote: > >On Mon, Aug 29, 2016 at 11:46:14AM +0200, Hans de Goede wrote: > >>On 29-08-16 08:56, Maxime Ripard wrote: > >>>On Fri, Aug 26, 2016 at 04:52:36PM +0200, Hans de Goede wrote: > >>>>Most of the sun8i q8 boards have an usb wifi controller, on the > >>>>variants which use an USB wifi controller, this will result in a > >>>>couple of error msg-s in dmesg when proving the sdio bus and > >>>>an used mmc controller. > >>>> > >>>>The best way to deal with wifi on this boards really is to simply > >>>>let the kernel auto-detect usb or sdio wifi controllers, so we > >>>>will just have to live with the few errors in dmesg. > >>> > >>>No, because that grabs PINs that might or might not be supposed to be > >>>used for that, it leaves clocks and regulators enabled, which draw > >>>power, to no end. And that's even worth since most boards will not use > >>>it. > >>> > >>>You can put the definition of the nodes in the DTSI, but the final > >>>status will have to be in the (relevant) DTS. > >> > >>This is again the q8-tablet thing where china produces a new variant > >>every 2 weeks. So we've sun8i-a23-q8-tablet.dts and sun8i-a33-q8-tablet.dts > >>which try to be generic dts files for these tablets, since creating > >>a custom dts per variant is madness. > > > >This is almost unrelated, and probably some wishful thinking, but I'd > >really prefer to support *one* board properly, with all its features, > >rather than supporting every random Allwinner device with half baked > >support, because no one ever updated the DT, or there's simply no > >driver. But hey, I can't force you to work on something either :) > > The q8 tablets are somewhat special, to the end consumer they > are one board, but they differ a lot per badge. These are 40 (or less) > usd tablets, which get whatever wifi / touchscreen-controller / > accelerometer which is cheapest on the Chenzen market when the > badge gets produces. > > For the end user to actually figure out what is in there requires > opening the tablet, or poking around with adb to learn the exact > internals / drivers used by android. > > I actually own 10 of these (3 a13, 5 a23, 2 a33) and have access > to 2 more a33 models which friends of me have, and they are *all* > different. For a list of all tablets I've see: > https://github.com/jwrdegoede/sunxi-fedora-scripts/blob/master/hansg-tablet-info > > Given the price of these they are really nice to thinker with / > turn into a little normal linux touch device, so I would like to > support them as best as we can in a somewhat user-friendly > way. Also see the RFC patch for the q8-hardwaremgr I posted > recently. In the end these tablets are the "*one* board" > which I'm trying to support properly, except that they are > only one board on the outside not on the outside. > > TL;DR: q8 tablets are special, but also quite popular and > I would like to support them properly, which requires > some special handling. > > >>This commit puts the node in sun8i-q8-common.dtsi because the > >>A23 and A33 are pin compatible and we've tablets where the > >>only difference is the SoC soldered on there, the use the _exact_ > >>same PCB and components otherwise, so we have all the sun8i q8 > >>stuff in a common place for sun8i-a23-q8-tablet.dts and > >>sun8i-a33-q8-tablet.dts, those are the only users of this > >>dtsi file. > >> > >>You've already merged the bits which handle the variants with > >>an USB attached wifi module (enabling ehci0 also on boards > >>where nothing is connected). This is the counter-part for > >>PCB's which use a sdio wifi module (about 90% of all boards > >>in my experience). > > > >I'm confused. Are most boards using an USB wifi chip, like you were > >stating in your commit log, or an SDIO wifi chip like you just said? > > My bad, the commit msg. is wrong of the 9 sun8i q8 tablets I've > access to only 1 uses usb wifi. > > So the first part of the commit msg should read > "Most of the sun8i q8 boards have a sdio wifi controller" > > >>As for turning a regulator on unnecessary, both the wifi and sdio > >>wifi solution use the same regulator, so that is already turned on > >>through the usb bits and it needs to be in either case. > > > >Ok, so indeed, that's not as bad as it sounds. > > > >>The only downside of this approach is that we either have > >>the USB controller turned on unnecessarily (in most cases) > >>or the mmc controller (in the rare A23 tablet which still > >>uses an USB wifi module). > >> > >>This all actually fits neatly into the plans to do hardware > >>autodetection for these tablets which I'm working on, in > >>this case we can just let the kernel handle things without > >>additional code (think the beaglebone capemanager) since > >>both busses are discoverable. > >> > >>Once we have the q8-hardwaremgr I'm working on and hope > >>to post an RFC of soon, we could even make that turn off > >>the unused controller (as a future enhancement). > > > >If that's on your to-do-list, that's fine by me. > > I've just added it to my to-do list :) > > So I assume with that done, that you are ok with taking this > patch now ? Please fixup the commit msg mistake, or let > me know if you want a v2. Yeah, I just applied it and fixed the commit log. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 0/3] ARM: dts: sun8i: Add dt nodes for sdio wifi 2016-08-26 14:52 ` Hans de Goede @ 2016-08-26 15:00 ` Icenowy Zheng -1 siblings, 0 replies; 26+ messages in thread From: Icenowy Zheng @ 2016-08-26 15:00 UTC (permalink / raw) To: linux-arm-kernel 26.08.2016, 22:58, "Hans de Goede" <hdegoede@redhat.com>: > Hi Maxime, > > Now that Ulf has merged the post-power-on-delay-ms mmc-pwrseq patches > in his mmc/next tree and Rob Herring has accepted the esp8089 dt > bindings (and specifically the esp,crystal-26M-en property), these > are ready for merging. Can the driver now work without broken-cd? > > Thanks & Regards, > > Hans > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 0/3] ARM: dts: sun8i: Add dt nodes for sdio wifi @ 2016-08-26 15:00 ` Icenowy Zheng 0 siblings, 0 replies; 26+ messages in thread From: Icenowy Zheng @ 2016-08-26 15:00 UTC (permalink / raw) To: Hans de Goede, Chen-Yu Tsai, Maxime Ripard Cc: devicetree, linux-arm-kernel@lists.infradead.org 26.08.2016, 22:58, "Hans de Goede" <hdegoede@redhat.com>: > Hi Maxime, > > Now that Ulf has merged the post-power-on-delay-ms mmc-pwrseq patches > in his mmc/next tree and Rob Herring has accepted the esp8089 dt > bindings (and specifically the esp,crystal-26M-en property), these > are ready for merging. Can the driver now work without broken-cd? > > Thanks & Regards, > > Hans > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 0/3] ARM: dts: sun8i: Add dt nodes for sdio wifi 2016-08-26 15:00 ` Icenowy Zheng @ 2016-08-26 15:52 ` Hans de Goede -1 siblings, 0 replies; 26+ messages in thread From: Hans de Goede @ 2016-08-26 15:52 UTC (permalink / raw) To: linux-arm-kernel Hi, On 26-08-16 17:00, Icenowy Zheng wrote: > > > 26.08.2016, 22:58, "Hans de Goede" <hdegoede@redhat.com>: >> Hi Maxime, >> >> Now that Ulf has merged the post-power-on-delay-ms mmc-pwrseq patches >> in his mmc/next tree and Rob Herring has accepted the esp8089 dt >> bindings (and specifically the esp,crystal-26M-en property), these >> are ready for merging. > > Can the driver now work without broken-cd? Sort-off, my fork of the esp8089 driver has a workaround so that it does not need broken-cd. I'm also working together with Ulf (the mmc maintainer) to come up with a clean upstream solution for this. Regards, Hans ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 0/3] ARM: dts: sun8i: Add dt nodes for sdio wifi @ 2016-08-26 15:52 ` Hans de Goede 0 siblings, 0 replies; 26+ messages in thread From: Hans de Goede @ 2016-08-26 15:52 UTC (permalink / raw) To: Icenowy Zheng, Chen-Yu Tsai, Maxime Ripard Cc: devicetree, linux-arm-kernel@lists.infradead.org Hi, On 26-08-16 17:00, Icenowy Zheng wrote: > > > 26.08.2016, 22:58, "Hans de Goede" <hdegoede@redhat.com>: >> Hi Maxime, >> >> Now that Ulf has merged the post-power-on-delay-ms mmc-pwrseq patches >> in his mmc/next tree and Rob Herring has accepted the esp8089 dt >> bindings (and specifically the esp,crystal-26M-en property), these >> are ready for merging. > > Can the driver now work without broken-cd? Sort-off, my fork of the esp8089 driver has a workaround so that it does not need broken-cd. I'm also working together with Ulf (the mmc maintainer) to come up with a clean upstream solution for this. Regards, Hans ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2016-09-05 19:58 UTC | newest] Thread overview: 26+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-08-26 14:52 [PATCH 0/3] ARM: dts: sun8i: Add dt nodes for sdio wifi Hans de Goede 2016-08-26 14:52 ` Hans de Goede 2016-08-26 14:52 ` [PATCH 1/3] ARM: dts: sun8i: Add dt node for esp8089 wifi chip on polaroid-mid2407 Hans de Goede 2016-08-26 14:52 ` Hans de Goede 2016-08-26 22:35 ` Maxime Ripard 2016-08-26 22:35 ` Maxime Ripard 2016-08-26 14:52 ` [PATCH 2/3] ARM: dts: sun8i: Add dt node for esp8089 wifi chip on polaroid-mid2809 Hans de Goede 2016-08-26 14:52 ` Hans de Goede 2016-08-26 22:36 ` Maxime Ripard 2016-08-26 22:36 ` Maxime Ripard 2016-08-26 14:52 ` [PATCH 3/3] ARM: dts: sun8i-q8-common: Add support for SDIO wifi controllers Hans de Goede 2016-08-26 14:52 ` Hans de Goede 2016-08-29 6:56 ` Maxime Ripard 2016-08-29 6:56 ` Maxime Ripard 2016-08-29 9:46 ` Hans de Goede 2016-08-29 9:46 ` Hans de Goede 2016-09-01 20:37 ` Maxime Ripard 2016-09-01 20:37 ` Maxime Ripard 2016-09-03 11:33 ` Hans de Goede 2016-09-03 11:33 ` Hans de Goede 2016-09-05 19:58 ` Maxime Ripard 2016-09-05 19:58 ` Maxime Ripard 2016-08-26 15:00 ` [PATCH 0/3] ARM: dts: sun8i: Add dt nodes for sdio wifi Icenowy Zheng 2016-08-26 15:00 ` Icenowy Zheng 2016-08-26 15:52 ` Hans de Goede 2016-08-26 15:52 ` Hans de Goede
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.