* [PATCH] ARM: dts: imx6q-cm-fx6: add sdio wifi/bt nodes @ 2017-05-30 20:16 ` christopher.spinrath 0 siblings, 0 replies; 14+ messages in thread From: christopher.spinrath at rwth-aachen.de @ 2017-05-30 20:16 UTC (permalink / raw) To: linux-arm-kernel From: Christopher Spinrath <christopher.spinrath@rwth-aachen.de> The cm-fx6 module has an on-board AW-NH387 WiFi/BT module which is based on Marvell's SD8787 chip and is connected to the usdhc1 controller. Unfortunately, the chip gets unresponsive if the Bluetooth AMP (Alternate Mac/Phy) function gets probed but the loaded firmware doesn't support it. For instance, this is the case for the most recent firmware in linux-firmware (Version 14.66.35.p52). Thus, just add the required nodes but leave the usdhc1 node disabled explicitly. Users who disabled the Bluetooth (AMP) support of their OS can then conveniently enable WiFi (or even plain Bluetooth) support with a simple device tree overlay/bootloader configuration. Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de> --- Hi all, some more information on the Bluetooth AMP dilemma: the vendor (CompuLab) just remove Bluetooth AMP support from the kernel. However, this is not an option here, since it would introduce a regression for its actual users. Neither is degrading the firmware a good option: recent firmare (without AMP support) provides WiFi that is more stable (in particular, for access points). I wrote a RFC to linux-bluetooth [1] two weeks ago about this problem and the only feedback I got was that Marvell has to provide information about how to detect whether the firmware supports AMP properly -- but this is unlikely given Marvell's information policy (in particular, since the sd8787 seems to be unsupported as of now). IMHO this patch is currently the best option, since it allows users in a convenient way to enable WiFi support (e.g. no pinctrl handling in overlays), even when they are using distribution kernels/device trees. Furthermore, the hardware description is entirely accurate -- we have a driver/firmware problem here. Thanks, Christopher [1] https://www.spinics.net/lists/linux-bluetooth/msg70493.html arch/arm/boot/dts/imx6q-cm-fx6.dts | 41 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts index a8af382..fe6ab0a 100644 --- a/arch/arm/boot/dts/imx6q-cm-fx6.dts +++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts @@ -64,6 +64,14 @@ }; }; + awnh387_pwrseq: pwrseq { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_pwrseq>; + compatible = "mmc-pwrseq-sd8787"; + powerdown-gpios = <&gpio7 12 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio6 16 GPIO_ACTIVE_HIGH>; + }; + reg_pcie_power_on_gpio: regulator-pcie-power-on-gpio { compatible = "regulator-fixed"; regulator-name = "regulator-pcie-power-on-gpio"; @@ -304,6 +312,13 @@ >; }; + pinctrl_pwrseq: pwrseqgrp { + fsl,pins = < + MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0 + MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x1b0b0 + >; + }; + pinctrl_spdif: spdifgrp { fsl,pins = < MX6QDL_PAD_GPIO_16__SPDIF_IN 0x1b0b0 @@ -330,6 +345,17 @@ MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x130b0 >; }; + + pinctrl_usdhc1: usdhc1grp { + fsl,pins = < + MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17071 + MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10071 + MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17071 + MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17071 + MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17071 + MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17071 + >; + }; }; &pcie { @@ -382,3 +408,18 @@ dr_mode = "otg"; status = "okay"; }; + +&usdhc1 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_usdhc1>; + mmc-pwrseq = <&awnh387_pwrseq>; + non-removable; + /* + * If the OS probes the Bluetooth AMP function advertised on this bus + * but the firmware in place does not support it, the WiFi/BT module + * gets unresponsive. + * Users who configured their OS properly can enable this node to gain + * WiFi and/or plain Bluetooth support. + */ + status = "disabled"; +}; -- 2.10.2 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH] ARM: dts: imx6q-cm-fx6: add sdio wifi/bt nodes @ 2017-05-30 20:16 ` christopher.spinrath 0 siblings, 0 replies; 14+ messages in thread From: christopher.spinrath @ 2017-05-30 20:16 UTC (permalink / raw) To: shawnguo, kernel Cc: mark.rutland, devicetree, christopher.spinrath, linux, robh+dt, grinberg, fabio.estevam, linux-arm-kernel From: Christopher Spinrath <christopher.spinrath@rwth-aachen.de> The cm-fx6 module has an on-board AW-NH387 WiFi/BT module which is based on Marvell's SD8787 chip and is connected to the usdhc1 controller. Unfortunately, the chip gets unresponsive if the Bluetooth AMP (Alternate Mac/Phy) function gets probed but the loaded firmware doesn't support it. For instance, this is the case for the most recent firmware in linux-firmware (Version 14.66.35.p52). Thus, just add the required nodes but leave the usdhc1 node disabled explicitly. Users who disabled the Bluetooth (AMP) support of their OS can then conveniently enable WiFi (or even plain Bluetooth) support with a simple device tree overlay/bootloader configuration. Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de> --- Hi all, some more information on the Bluetooth AMP dilemma: the vendor (CompuLab) just remove Bluetooth AMP support from the kernel. However, this is not an option here, since it would introduce a regression for its actual users. Neither is degrading the firmware a good option: recent firmare (without AMP support) provides WiFi that is more stable (in particular, for access points). I wrote a RFC to linux-bluetooth [1] two weeks ago about this problem and the only feedback I got was that Marvell has to provide information about how to detect whether the firmware supports AMP properly -- but this is unlikely given Marvell's information policy (in particular, since the sd8787 seems to be unsupported as of now). IMHO this patch is currently the best option, since it allows users in a convenient way to enable WiFi support (e.g. no pinctrl handling in overlays), even when they are using distribution kernels/device trees. Furthermore, the hardware description is entirely accurate -- we have a driver/firmware problem here. Thanks, Christopher [1] https://www.spinics.net/lists/linux-bluetooth/msg70493.html arch/arm/boot/dts/imx6q-cm-fx6.dts | 41 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts index a8af382..fe6ab0a 100644 --- a/arch/arm/boot/dts/imx6q-cm-fx6.dts +++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts @@ -64,6 +64,14 @@ }; }; + awnh387_pwrseq: pwrseq { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_pwrseq>; + compatible = "mmc-pwrseq-sd8787"; + powerdown-gpios = <&gpio7 12 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio6 16 GPIO_ACTIVE_HIGH>; + }; + reg_pcie_power_on_gpio: regulator-pcie-power-on-gpio { compatible = "regulator-fixed"; regulator-name = "regulator-pcie-power-on-gpio"; @@ -304,6 +312,13 @@ >; }; + pinctrl_pwrseq: pwrseqgrp { + fsl,pins = < + MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0 + MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x1b0b0 + >; + }; + pinctrl_spdif: spdifgrp { fsl,pins = < MX6QDL_PAD_GPIO_16__SPDIF_IN 0x1b0b0 @@ -330,6 +345,17 @@ MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x130b0 >; }; + + pinctrl_usdhc1: usdhc1grp { + fsl,pins = < + MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17071 + MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10071 + MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17071 + MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17071 + MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17071 + MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17071 + >; + }; }; &pcie { @@ -382,3 +408,18 @@ dr_mode = "otg"; status = "okay"; }; + +&usdhc1 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_usdhc1>; + mmc-pwrseq = <&awnh387_pwrseq>; + non-removable; + /* + * If the OS probes the Bluetooth AMP function advertised on this bus + * but the firmware in place does not support it, the WiFi/BT module + * gets unresponsive. + * Users who configured their OS properly can enable this node to gain + * WiFi and/or plain Bluetooth support. + */ + status = "disabled"; +}; -- 2.10.2 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH] ARM: dts: imx6q-cm-fx6: add sdio wifi/bt nodes @ 2017-05-30 20:40 ` Fabio Estevam 0 siblings, 0 replies; 14+ messages in thread From: Fabio Estevam @ 2017-05-30 20:40 UTC (permalink / raw) To: linux-arm-kernel Hi Christopher, On Tue, May 30, 2017 at 5:16 PM, <christopher.spinrath@rwth-aachen.de> wrote: > + awnh387_pwrseq: pwrseq { > + pinctrl-names = "default"; > + pinctrl-0 = <&pinctrl_pwrseq>; > + compatible = "mmc-pwrseq-sd8787"; > + powerdown-gpios = <&gpio7 12 GPIO_ACTIVE_HIGH>; > + reset-gpios = <&gpio6 16 GPIO_ACTIVE_HIGH>; At least in the AW-NH387 datasheet I found it says: RESETn: Reset(active low at least 10ns) Please double check the polarity in device tree. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] ARM: dts: imx6q-cm-fx6: add sdio wifi/bt nodes @ 2017-05-30 20:40 ` Fabio Estevam 0 siblings, 0 replies; 14+ messages in thread From: Fabio Estevam @ 2017-05-30 20:40 UTC (permalink / raw) To: Christopher Spinrath Cc: Shawn Guo, Sascha Hauer, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Russell King - ARM Linux, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Igor Grinberg, Fabio Estevam, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org Hi Christopher, On Tue, May 30, 2017 at 5:16 PM, <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org> wrote: > + awnh387_pwrseq: pwrseq { > + pinctrl-names = "default"; > + pinctrl-0 = <&pinctrl_pwrseq>; > + compatible = "mmc-pwrseq-sd8787"; > + powerdown-gpios = <&gpio7 12 GPIO_ACTIVE_HIGH>; > + reset-gpios = <&gpio6 16 GPIO_ACTIVE_HIGH>; At least in the AW-NH387 datasheet I found it says: RESETn: Reset(active low at least 10ns) Please double check the polarity in device tree. -- 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] 14+ messages in thread
[parent not found: <8c7aee6cf7184c1cb914c1eef530e2de@rwthex-w1-a.rwth-ad.de>]
* [PATCH] ARM: dts: imx6q-cm-fx6: add sdio wifi/bt nodes @ 2017-05-30 21:23 ` Christopher Spinrath 0 siblings, 0 replies; 14+ messages in thread From: Christopher Spinrath @ 2017-05-30 21:23 UTC (permalink / raw) To: linux-arm-kernel Hi Fabio, thanks for the fast reply. On 05/30/2017 10:40 PM, Fabio Estevam wrote: > Hi Christopher, > > On Tue, May 30, 2017 at 5:16 PM, <christopher.spinrath@rwth-aachen.de> wrote: > >> + awnh387_pwrseq: pwrseq { >> + pinctrl-names = "default"; >> + pinctrl-0 = <&pinctrl_pwrseq>; >> + compatible = "mmc-pwrseq-sd8787"; >> + powerdown-gpios = <&gpio7 12 GPIO_ACTIVE_HIGH>; >> + reset-gpios = <&gpio6 16 GPIO_ACTIVE_HIGH>; > > At least in the AW-NH387 datasheet I found it says: > > RESETn: Reset(active low at least 10ns) The BSP device tree uses an active-low regulator called nreset, too, but strangly it has a startup delay of 10ms while the powerdown-regulator "starts up" immediately. (btw: the "regulator setup" is not able to handle resets correctly.) It seems to me that the pwrseq-sd8787 uses inverted logic: it first sets the -- in our case -- active-high gpio to high, waits, and then enables the powerdown-gpio. This coincides with the gpio being called "reset" in the pwrseq binding, neither "nreset" nor "RESETn" (beware the missing *n*ot). > Please double check the polarity in device tree. > I just double checked: high/high for powerdown/reset gpios is the only of the four possible combinations that works. So, all in all, I think the polarity is correct (or either the pwrseq driver or hardware invertes the polarity for some reason). Cheers, Christopher ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] ARM: dts: imx6q-cm-fx6: add sdio wifi/bt nodes @ 2017-05-30 21:23 ` Christopher Spinrath 0 siblings, 0 replies; 14+ messages in thread From: Christopher Spinrath @ 2017-05-30 21:23 UTC (permalink / raw) To: Fabio Estevam Cc: Shawn Guo, Sascha Hauer, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Russell King - ARM Linux, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Igor Grinberg, Fabio Estevam, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg Hi Fabio, thanks for the fast reply. On 05/30/2017 10:40 PM, Fabio Estevam wrote: > Hi Christopher, > > On Tue, May 30, 2017 at 5:16 PM, <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org> wrote: > >> + awnh387_pwrseq: pwrseq { >> + pinctrl-names = "default"; >> + pinctrl-0 = <&pinctrl_pwrseq>; >> + compatible = "mmc-pwrseq-sd8787"; >> + powerdown-gpios = <&gpio7 12 GPIO_ACTIVE_HIGH>; >> + reset-gpios = <&gpio6 16 GPIO_ACTIVE_HIGH>; > > At least in the AW-NH387 datasheet I found it says: > > RESETn: Reset(active low at least 10ns) The BSP device tree uses an active-low regulator called nreset, too, but strangly it has a startup delay of 10ms while the powerdown-regulator "starts up" immediately. (btw: the "regulator setup" is not able to handle resets correctly.) It seems to me that the pwrseq-sd8787 uses inverted logic: it first sets the -- in our case -- active-high gpio to high, waits, and then enables the powerdown-gpio. This coincides with the gpio being called "reset" in the pwrseq binding, neither "nreset" nor "RESETn" (beware the missing *n*ot). > Please double check the polarity in device tree. > I just double checked: high/high for powerdown/reset gpios is the only of the four possible combinations that works. So, all in all, I think the polarity is correct (or either the pwrseq driver or hardware invertes the polarity for some reason). Cheers, Christopher -- 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] 14+ messages in thread
* [PATCH] ARM: dts: imx6q-cm-fx6: add sdio wifi/bt nodes @ 2017-06-05 14:51 ` Shawn Guo 0 siblings, 0 replies; 14+ messages in thread From: Shawn Guo @ 2017-06-05 14:51 UTC (permalink / raw) To: linux-arm-kernel On Tue, May 30, 2017 at 10:16:01PM +0200, christopher.spinrath at rwth-aachen.de wrote: > From: Christopher Spinrath <christopher.spinrath@rwth-aachen.de> > > The cm-fx6 module has an on-board AW-NH387 WiFi/BT module which is > based on Marvell's SD8787 chip and is connected to the usdhc1 > controller. > > Unfortunately, the chip gets unresponsive if the Bluetooth AMP > (Alternate Mac/Phy) function gets probed but the loaded firmware > doesn't support it. For instance, this is the case for the most > recent firmware in linux-firmware (Version 14.66.35.p52). > > Thus, just add the required nodes but leave the usdhc1 node disabled > explicitly. Users who disabled the Bluetooth (AMP) support of their > OS can then conveniently enable WiFi (or even plain Bluetooth) support > with a simple device tree overlay/bootloader configuration. > > Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de> > --- > > Hi all, > > some more information on the Bluetooth AMP dilemma: the vendor (CompuLab) just > remove Bluetooth AMP support from the kernel. However, this is not an option > here, since it would introduce a regression for its actual users. > > Neither is degrading the firmware a good option: recent firmare (without AMP > support) provides WiFi that is more stable (in particular, for access points). > > I wrote a RFC to linux-bluetooth [1] two weeks ago about this problem and the > only feedback I got was that Marvell has to provide information about how to > detect whether the firmware supports AMP properly -- but this is unlikely given > Marvell's information policy (in particular, since the sd8787 seems to be > unsupported as of now). > > IMHO this patch is currently the best option, since it allows users in a > convenient way to enable WiFi support (e.g. no pinctrl handling in overlays), > even when they are using distribution kernels/device trees. Furthermore, the > hardware description is entirely accurate -- we have a driver/firmware problem > here. Hi Valentin, Igor, Are you guys fine with the patch? Shawn > > Thanks, > Christopher > > [1] https://www.spinics.net/lists/linux-bluetooth/msg70493.html > > arch/arm/boot/dts/imx6q-cm-fx6.dts | 41 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 41 insertions(+) > > diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts > index a8af382..fe6ab0a 100644 > --- a/arch/arm/boot/dts/imx6q-cm-fx6.dts > +++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts > @@ -64,6 +64,14 @@ > }; > }; > > + awnh387_pwrseq: pwrseq { > + pinctrl-names = "default"; > + pinctrl-0 = <&pinctrl_pwrseq>; > + compatible = "mmc-pwrseq-sd8787"; > + powerdown-gpios = <&gpio7 12 GPIO_ACTIVE_HIGH>; > + reset-gpios = <&gpio6 16 GPIO_ACTIVE_HIGH>; > + }; > + > reg_pcie_power_on_gpio: regulator-pcie-power-on-gpio { > compatible = "regulator-fixed"; > regulator-name = "regulator-pcie-power-on-gpio"; > @@ -304,6 +312,13 @@ > >; > }; > > + pinctrl_pwrseq: pwrseqgrp { > + fsl,pins = < > + MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0 > + MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x1b0b0 > + >; > + }; > + > pinctrl_spdif: spdifgrp { > fsl,pins = < > MX6QDL_PAD_GPIO_16__SPDIF_IN 0x1b0b0 > @@ -330,6 +345,17 @@ > MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x130b0 > >; > }; > + > + pinctrl_usdhc1: usdhc1grp { > + fsl,pins = < > + MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17071 > + MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10071 > + MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17071 > + MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17071 > + MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17071 > + MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17071 > + >; > + }; > }; > > &pcie { > @@ -382,3 +408,18 @@ > dr_mode = "otg"; > status = "okay"; > }; > + > +&usdhc1 { > + pinctrl-names = "default"; > + pinctrl-0 = <&pinctrl_usdhc1>; > + mmc-pwrseq = <&awnh387_pwrseq>; > + non-removable; > + /* > + * If the OS probes the Bluetooth AMP function advertised on this bus > + * but the firmware in place does not support it, the WiFi/BT module > + * gets unresponsive. > + * Users who configured their OS properly can enable this node to gain > + * WiFi and/or plain Bluetooth support. > + */ > + status = "disabled"; > +}; > -- > 2.10.2 > > > _______________________________________________ > 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] 14+ messages in thread
* Re: [PATCH] ARM: dts: imx6q-cm-fx6: add sdio wifi/bt nodes @ 2017-06-05 14:51 ` Shawn Guo 0 siblings, 0 replies; 14+ messages in thread From: Shawn Guo @ 2017-06-05 14:51 UTC (permalink / raw) To: christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg, Valentin Raevsky, Igor Grinberg Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ, mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-I+IVW8TIWO2tmTQ+vhA3Yw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, fabio.estevam-3arQi8VN3Tc, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Tue, May 30, 2017 at 10:16:01PM +0200, christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org wrote: > From: Christopher Spinrath <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org> > > The cm-fx6 module has an on-board AW-NH387 WiFi/BT module which is > based on Marvell's SD8787 chip and is connected to the usdhc1 > controller. > > Unfortunately, the chip gets unresponsive if the Bluetooth AMP > (Alternate Mac/Phy) function gets probed but the loaded firmware > doesn't support it. For instance, this is the case for the most > recent firmware in linux-firmware (Version 14.66.35.p52). > > Thus, just add the required nodes but leave the usdhc1 node disabled > explicitly. Users who disabled the Bluetooth (AMP) support of their > OS can then conveniently enable WiFi (or even plain Bluetooth) support > with a simple device tree overlay/bootloader configuration. > > Signed-off-by: Christopher Spinrath <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org> > --- > > Hi all, > > some more information on the Bluetooth AMP dilemma: the vendor (CompuLab) just > remove Bluetooth AMP support from the kernel. However, this is not an option > here, since it would introduce a regression for its actual users. > > Neither is degrading the firmware a good option: recent firmare (without AMP > support) provides WiFi that is more stable (in particular, for access points). > > I wrote a RFC to linux-bluetooth [1] two weeks ago about this problem and the > only feedback I got was that Marvell has to provide information about how to > detect whether the firmware supports AMP properly -- but this is unlikely given > Marvell's information policy (in particular, since the sd8787 seems to be > unsupported as of now). > > IMHO this patch is currently the best option, since it allows users in a > convenient way to enable WiFi support (e.g. no pinctrl handling in overlays), > even when they are using distribution kernels/device trees. Furthermore, the > hardware description is entirely accurate -- we have a driver/firmware problem > here. Hi Valentin, Igor, Are you guys fine with the patch? Shawn > > Thanks, > Christopher > > [1] https://www.spinics.net/lists/linux-bluetooth/msg70493.html > > arch/arm/boot/dts/imx6q-cm-fx6.dts | 41 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 41 insertions(+) > > diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts > index a8af382..fe6ab0a 100644 > --- a/arch/arm/boot/dts/imx6q-cm-fx6.dts > +++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts > @@ -64,6 +64,14 @@ > }; > }; > > + awnh387_pwrseq: pwrseq { > + pinctrl-names = "default"; > + pinctrl-0 = <&pinctrl_pwrseq>; > + compatible = "mmc-pwrseq-sd8787"; > + powerdown-gpios = <&gpio7 12 GPIO_ACTIVE_HIGH>; > + reset-gpios = <&gpio6 16 GPIO_ACTIVE_HIGH>; > + }; > + > reg_pcie_power_on_gpio: regulator-pcie-power-on-gpio { > compatible = "regulator-fixed"; > regulator-name = "regulator-pcie-power-on-gpio"; > @@ -304,6 +312,13 @@ > >; > }; > > + pinctrl_pwrseq: pwrseqgrp { > + fsl,pins = < > + MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0 > + MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x1b0b0 > + >; > + }; > + > pinctrl_spdif: spdifgrp { > fsl,pins = < > MX6QDL_PAD_GPIO_16__SPDIF_IN 0x1b0b0 > @@ -330,6 +345,17 @@ > MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x130b0 > >; > }; > + > + pinctrl_usdhc1: usdhc1grp { > + fsl,pins = < > + MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17071 > + MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10071 > + MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17071 > + MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17071 > + MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17071 > + MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17071 > + >; > + }; > }; > > &pcie { > @@ -382,3 +408,18 @@ > dr_mode = "otg"; > status = "okay"; > }; > + > +&usdhc1 { > + pinctrl-names = "default"; > + pinctrl-0 = <&pinctrl_usdhc1>; > + mmc-pwrseq = <&awnh387_pwrseq>; > + non-removable; > + /* > + * If the OS probes the Bluetooth AMP function advertised on this bus > + * but the firmware in place does not support it, the WiFi/BT module > + * gets unresponsive. > + * Users who configured their OS properly can enable this node to gain > + * WiFi and/or plain Bluetooth support. > + */ > + status = "disabled"; > +}; > -- > 2.10.2 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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] 14+ messages in thread
[parent not found: <3c63d7014b0b4bb596f328ea8018a4cb@rwthex-w1-a.rwth-ad.de>]
* [PATCH] ARM: dts: imx6q-cm-fx6: add sdio wifi/bt nodes @ 2017-06-15 21:23 ` Christopher Spinrath 0 siblings, 0 replies; 14+ messages in thread From: Christopher Spinrath @ 2017-06-15 21:23 UTC (permalink / raw) To: linux-arm-kernel Hi Shawn, On 06/05/2017 04:51 PM, Shawn Guo wrote: > On Tue, May 30, 2017 at 10:16:01PM +0200, christopher.spinrath at rwth-aachen.de wrote: >> From: Christopher Spinrath <christopher.spinrath@rwth-aachen.de> >> >> The cm-fx6 module has an on-board AW-NH387 WiFi/BT module which is >> based on Marvell's SD8787 chip and is connected to the usdhc1 >> controller. >> >> Unfortunately, the chip gets unresponsive if the Bluetooth AMP >> (Alternate Mac/Phy) function gets probed but the loaded firmware >> doesn't support it. For instance, this is the case for the most >> recent firmware in linux-firmware (Version 14.66.35.p52). >> >> Thus, just add the required nodes but leave the usdhc1 node disabled >> explicitly. Users who disabled the Bluetooth (AMP) support of their >> OS can then conveniently enable WiFi (or even plain Bluetooth) support >> with a simple device tree overlay/bootloader configuration. >> >> Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de> >> --- >> >> Hi all, >> >> some more information on the Bluetooth AMP dilemma: the vendor (CompuLab) just >> remove Bluetooth AMP support from the kernel. However, this is not an option >> here, since it would introduce a regression for its actual users. >> >> Neither is degrading the firmware a good option: recent firmare (without AMP >> support) provides WiFi that is more stable (in particular, for access points). >> >> I wrote a RFC to linux-bluetooth [1] two weeks ago about this problem and the >> only feedback I got was that Marvell has to provide information about how to >> detect whether the firmware supports AMP properly -- but this is unlikely given >> Marvell's information policy (in particular, since the sd8787 seems to be >> unsupported as of now). >> >> IMHO this patch is currently the best option, since it allows users in a >> convenient way to enable WiFi support (e.g. no pinctrl handling in overlays), >> even when they are using distribution kernels/device trees. Furthermore, the >> hardware description is entirely accurate -- we have a driver/firmware problem >> here. > > Hi Valentin, Igor, > > Are you guys fine with the patch? Do you have a specific question here? The devicetree additions are mostly identical to their counterparts in the BSP devicetree. The only real exception being that the usdhc1 regulators have been replaced by the sd8787 power sequence, which allows the mmc core to reset the wifi/bt chip (which is not possible with the regulator setup). Note that the sd8787 power sequence binding/driver has only recently been added to Linux (v4.11) and is not present in the BSP kernel. Furthermore, the Bluetooth AMP function is disabled in the BSP kernel by CompuLab [1] for the same reason we do not enable the usdhc1 node in this patch. (We cannot disable it in the driver because, as explained in the commit message, this would yield a regression.) Thanks, Christopher [1] https://github.com/utilite-computer/linux-kernel/commit/d2ef249cc37a61ec88bc0da0ffcc75799e12f25f.patch > Shawn > >> >> Thanks, >> Christopher >> >> [1] https://www.spinics.net/lists/linux-bluetooth/msg70493.html >> >> arch/arm/boot/dts/imx6q-cm-fx6.dts | 41 ++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 41 insertions(+) >> >> diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts >> index a8af382..fe6ab0a 100644 >> --- a/arch/arm/boot/dts/imx6q-cm-fx6.dts >> +++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts >> @@ -64,6 +64,14 @@ >> }; >> }; >> >> + awnh387_pwrseq: pwrseq { >> + pinctrl-names = "default"; >> + pinctrl-0 = <&pinctrl_pwrseq>; >> + compatible = "mmc-pwrseq-sd8787"; >> + powerdown-gpios = <&gpio7 12 GPIO_ACTIVE_HIGH>; >> + reset-gpios = <&gpio6 16 GPIO_ACTIVE_HIGH>; >> + }; >> + >> reg_pcie_power_on_gpio: regulator-pcie-power-on-gpio { >> compatible = "regulator-fixed"; >> regulator-name = "regulator-pcie-power-on-gpio"; >> @@ -304,6 +312,13 @@ >> >; >> }; >> >> + pinctrl_pwrseq: pwrseqgrp { >> + fsl,pins = < >> + MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0 >> + MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x1b0b0 >> + >; >> + }; >> + >> pinctrl_spdif: spdifgrp { >> fsl,pins = < >> MX6QDL_PAD_GPIO_16__SPDIF_IN 0x1b0b0 >> @@ -330,6 +345,17 @@ >> MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x130b0 >> >; >> }; >> + >> + pinctrl_usdhc1: usdhc1grp { >> + fsl,pins = < >> + MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17071 >> + MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10071 >> + MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17071 >> + MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17071 >> + MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17071 >> + MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17071 >> + >; >> + }; >> }; >> >> &pcie { >> @@ -382,3 +408,18 @@ >> dr_mode = "otg"; >> status = "okay"; >> }; >> + >> +&usdhc1 { >> + pinctrl-names = "default"; >> + pinctrl-0 = <&pinctrl_usdhc1>; >> + mmc-pwrseq = <&awnh387_pwrseq>; >> + non-removable; >> + /* >> + * If the OS probes the Bluetooth AMP function advertised on this bus >> + * but the firmware in place does not support it, the WiFi/BT module >> + * gets unresponsive. >> + * Users who configured their OS properly can enable this node to gain >> + * WiFi and/or plain Bluetooth support. >> + */ >> + status = "disabled"; >> +}; >> -- >> 2.10.2 >> >> >> _______________________________________________ >> 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] 14+ messages in thread
* Re: [PATCH] ARM: dts: imx6q-cm-fx6: add sdio wifi/bt nodes @ 2017-06-15 21:23 ` Christopher Spinrath 0 siblings, 0 replies; 14+ messages in thread From: Christopher Spinrath @ 2017-06-15 21:23 UTC (permalink / raw) To: Shawn Guo, Valentin Raevsky, Igor Grinberg Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ, mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-I+IVW8TIWO2tmTQ+vhA3Yw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, fabio.estevam-3arQi8VN3Tc, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Hi Shawn, On 06/05/2017 04:51 PM, Shawn Guo wrote: > On Tue, May 30, 2017 at 10:16:01PM +0200, christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org wrote: >> From: Christopher Spinrath <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org> >> >> The cm-fx6 module has an on-board AW-NH387 WiFi/BT module which is >> based on Marvell's SD8787 chip and is connected to the usdhc1 >> controller. >> >> Unfortunately, the chip gets unresponsive if the Bluetooth AMP >> (Alternate Mac/Phy) function gets probed but the loaded firmware >> doesn't support it. For instance, this is the case for the most >> recent firmware in linux-firmware (Version 14.66.35.p52). >> >> Thus, just add the required nodes but leave the usdhc1 node disabled >> explicitly. Users who disabled the Bluetooth (AMP) support of their >> OS can then conveniently enable WiFi (or even plain Bluetooth) support >> with a simple device tree overlay/bootloader configuration. >> >> Signed-off-by: Christopher Spinrath <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org> >> --- >> >> Hi all, >> >> some more information on the Bluetooth AMP dilemma: the vendor (CompuLab) just >> remove Bluetooth AMP support from the kernel. However, this is not an option >> here, since it would introduce a regression for its actual users. >> >> Neither is degrading the firmware a good option: recent firmare (without AMP >> support) provides WiFi that is more stable (in particular, for access points). >> >> I wrote a RFC to linux-bluetooth [1] two weeks ago about this problem and the >> only feedback I got was that Marvell has to provide information about how to >> detect whether the firmware supports AMP properly -- but this is unlikely given >> Marvell's information policy (in particular, since the sd8787 seems to be >> unsupported as of now). >> >> IMHO this patch is currently the best option, since it allows users in a >> convenient way to enable WiFi support (e.g. no pinctrl handling in overlays), >> even when they are using distribution kernels/device trees. Furthermore, the >> hardware description is entirely accurate -- we have a driver/firmware problem >> here. > > Hi Valentin, Igor, > > Are you guys fine with the patch? Do you have a specific question here? The devicetree additions are mostly identical to their counterparts in the BSP devicetree. The only real exception being that the usdhc1 regulators have been replaced by the sd8787 power sequence, which allows the mmc core to reset the wifi/bt chip (which is not possible with the regulator setup). Note that the sd8787 power sequence binding/driver has only recently been added to Linux (v4.11) and is not present in the BSP kernel. Furthermore, the Bluetooth AMP function is disabled in the BSP kernel by CompuLab [1] for the same reason we do not enable the usdhc1 node in this patch. (We cannot disable it in the driver because, as explained in the commit message, this would yield a regression.) Thanks, Christopher [1] https://github.com/utilite-computer/linux-kernel/commit/d2ef249cc37a61ec88bc0da0ffcc75799e12f25f.patch > Shawn > >> >> Thanks, >> Christopher >> >> [1] https://www.spinics.net/lists/linux-bluetooth/msg70493.html >> >> arch/arm/boot/dts/imx6q-cm-fx6.dts | 41 ++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 41 insertions(+) >> >> diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts >> index a8af382..fe6ab0a 100644 >> --- a/arch/arm/boot/dts/imx6q-cm-fx6.dts >> +++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts >> @@ -64,6 +64,14 @@ >> }; >> }; >> >> + awnh387_pwrseq: pwrseq { >> + pinctrl-names = "default"; >> + pinctrl-0 = <&pinctrl_pwrseq>; >> + compatible = "mmc-pwrseq-sd8787"; >> + powerdown-gpios = <&gpio7 12 GPIO_ACTIVE_HIGH>; >> + reset-gpios = <&gpio6 16 GPIO_ACTIVE_HIGH>; >> + }; >> + >> reg_pcie_power_on_gpio: regulator-pcie-power-on-gpio { >> compatible = "regulator-fixed"; >> regulator-name = "regulator-pcie-power-on-gpio"; >> @@ -304,6 +312,13 @@ >> >; >> }; >> >> + pinctrl_pwrseq: pwrseqgrp { >> + fsl,pins = < >> + MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0 >> + MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x1b0b0 >> + >; >> + }; >> + >> pinctrl_spdif: spdifgrp { >> fsl,pins = < >> MX6QDL_PAD_GPIO_16__SPDIF_IN 0x1b0b0 >> @@ -330,6 +345,17 @@ >> MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x130b0 >> >; >> }; >> + >> + pinctrl_usdhc1: usdhc1grp { >> + fsl,pins = < >> + MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17071 >> + MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10071 >> + MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17071 >> + MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17071 >> + MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17071 >> + MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17071 >> + >; >> + }; >> }; >> >> &pcie { >> @@ -382,3 +408,18 @@ >> dr_mode = "otg"; >> status = "okay"; >> }; >> + >> +&usdhc1 { >> + pinctrl-names = "default"; >> + pinctrl-0 = <&pinctrl_usdhc1>; >> + mmc-pwrseq = <&awnh387_pwrseq>; >> + non-removable; >> + /* >> + * If the OS probes the Bluetooth AMP function advertised on this bus >> + * but the firmware in place does not support it, the WiFi/BT module >> + * gets unresponsive. >> + * Users who configured their OS properly can enable this node to gain >> + * WiFi and/or plain Bluetooth support. >> + */ >> + status = "disabled"; >> +}; >> -- >> 2.10.2 >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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] 14+ messages in thread
* [PATCH] ARM: dts: imx6q-cm-fx6: add sdio wifi/bt nodes @ 2017-06-17 13:23 ` Shawn Guo 0 siblings, 0 replies; 14+ messages in thread From: Shawn Guo @ 2017-06-17 13:23 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jun 15, 2017 at 11:23:46PM +0200, Christopher Spinrath wrote: > > Hi Valentin, Igor, > > > > Are you guys fine with the patch? > > Do you have a specific question here? No, I don't. I just wanted to hear the voice of Compulab people. Okay, we haven't waited for time enough, so I just applied patch. > > The devicetree additions are mostly identical to their counterparts in > the BSP devicetree. The only real exception being that the usdhc1 > regulators have been replaced by the sd8787 power sequence, which allows > the mmc core to reset the wifi/bt chip (which is not possible with the > regulator setup). Note that the sd8787 power sequence binding/driver has > only recently been added to Linux (v4.11) and is not present in the BSP > kernel. > > Furthermore, the Bluetooth AMP function is disabled in the BSP kernel > by CompuLab [1] for the same reason we do not enable the usdhc1 node in > this patch. (We cannot disable it in the driver because, as explained in > the commit message, this would yield a regression.) Thanks for the comments. Shawn ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] ARM: dts: imx6q-cm-fx6: add sdio wifi/bt nodes @ 2017-06-17 13:23 ` Shawn Guo 0 siblings, 0 replies; 14+ messages in thread From: Shawn Guo @ 2017-06-17 13:23 UTC (permalink / raw) To: Christopher Spinrath Cc: Valentin Raevsky, Igor Grinberg, kernel-bIcnvbaLZ9MEGnE8C9+IrQ, mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-I+IVW8TIWO2tmTQ+vhA3Yw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, fabio.estevam-3arQi8VN3Tc, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Thu, Jun 15, 2017 at 11:23:46PM +0200, Christopher Spinrath wrote: > > Hi Valentin, Igor, > > > > Are you guys fine with the patch? > > Do you have a specific question here? No, I don't. I just wanted to hear the voice of Compulab people. Okay, we haven't waited for time enough, so I just applied patch. > > The devicetree additions are mostly identical to their counterparts in > the BSP devicetree. The only real exception being that the usdhc1 > regulators have been replaced by the sd8787 power sequence, which allows > the mmc core to reset the wifi/bt chip (which is not possible with the > regulator setup). Note that the sd8787 power sequence binding/driver has > only recently been added to Linux (v4.11) and is not present in the BSP > kernel. > > Furthermore, the Bluetooth AMP function is disabled in the BSP kernel > by CompuLab [1] for the same reason we do not enable the usdhc1 node in > this patch. (We cannot disable it in the driver because, as explained in > the commit message, this would yield a regression.) Thanks for the comments. Shawn -- 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] 14+ messages in thread
* [PATCH] ARM: dts: imx6q-cm-fx6: add sdio wifi/bt nodes 2017-06-17 13:23 ` Shawn Guo @ 2017-06-17 14:32 ` Shawn Guo -1 siblings, 0 replies; 14+ messages in thread From: Shawn Guo @ 2017-06-17 14:32 UTC (permalink / raw) To: linux-arm-kernel On Sat, Jun 17, 2017 at 09:23:31PM +0800, Shawn Guo wrote: > On Thu, Jun 15, 2017 at 11:23:46PM +0200, Christopher Spinrath wrote: > > > Hi Valentin, Igor, > > > > > > Are you guys fine with the patch? > > > > Do you have a specific question here? > > No, I don't. I just wanted to hear the voice of Compulab people. Okay, > we haven't waited for time enough, so I just applied patch. s/haven't/have ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] ARM: dts: imx6q-cm-fx6: add sdio wifi/bt nodes @ 2017-06-17 14:32 ` Shawn Guo 0 siblings, 0 replies; 14+ messages in thread From: Shawn Guo @ 2017-06-17 14:32 UTC (permalink / raw) To: Christopher Spinrath Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA, Valentin Raevsky, linux-I+IVW8TIWO2tmTQ+vhA3Yw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Igor Grinberg, kernel-bIcnvbaLZ9MEGnE8C9+IrQ, fabio.estevam-3arQi8VN3Tc, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Sat, Jun 17, 2017 at 09:23:31PM +0800, Shawn Guo wrote: > On Thu, Jun 15, 2017 at 11:23:46PM +0200, Christopher Spinrath wrote: > > > Hi Valentin, Igor, > > > > > > Are you guys fine with the patch? > > > > Do you have a specific question here? > > No, I don't. I just wanted to hear the voice of Compulab people. Okay, > we haven't waited for time enough, so I just applied patch. s/haven't/have -- 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] 14+ messages in thread
end of thread, other threads:[~2017-06-17 14:32 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-05-30 20:16 [PATCH] ARM: dts: imx6q-cm-fx6: add sdio wifi/bt nodes christopher.spinrath at rwth-aachen.de
2017-05-30 20:16 ` christopher.spinrath
2017-05-30 20:40 ` Fabio Estevam
2017-05-30 20:40 ` Fabio Estevam
[not found] ` <8c7aee6cf7184c1cb914c1eef530e2de@rwthex-w1-a.rwth-ad.de>
2017-05-30 21:23 ` Christopher Spinrath
2017-05-30 21:23 ` Christopher Spinrath
2017-06-05 14:51 ` Shawn Guo
2017-06-05 14:51 ` Shawn Guo
[not found] ` <3c63d7014b0b4bb596f328ea8018a4cb@rwthex-w1-a.rwth-ad.de>
2017-06-15 21:23 ` Christopher Spinrath
2017-06-15 21:23 ` Christopher Spinrath
2017-06-17 13:23 ` Shawn Guo
2017-06-17 13:23 ` Shawn Guo
2017-06-17 14:32 ` Shawn Guo
2017-06-17 14:32 ` Shawn Guo
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.