| Message ID | cover.1571510481.git.hns@goldelico.com |
|---|---|
| Headers | show |
| Series | OpenPandora: make wl1251 connected to mmc3 sdio port of OpenPandora work again | expand |
* H. Nikolaus Schaller <hns@goldelico.com> [191019 18:43]: > --- a/arch/arm/mach-omap2/Makefile > +++ b/arch/arm/mach-omap2/Makefile > @@ -216,7 +216,6 @@ obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o > > # Platform specific device init code > > -omap-hsmmc-$(CONFIG_MMC_OMAP_HS) := hsmmc.o > obj-y += $(omap-hsmmc-m) $(omap-hsmmc-y) The related obj-y line can go now too, right? And looks like common.h also has struct omap2_hsmmc_info so maybe check by grepping for hsmmc_info to see it's gone. Regards, Tony
> Am 21.10.2019 um 16:30 schrieb Tony Lindgren <tony@atomide.com>: > > * H. Nikolaus Schaller <hns@goldelico.com> [191019 18:43]: >> --- a/arch/arm/mach-omap2/Makefile >> +++ b/arch/arm/mach-omap2/Makefile >> @@ -216,7 +216,6 @@ obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o >> >> # Platform specific device init code >> >> -omap-hsmmc-$(CONFIG_MMC_OMAP_HS) := hsmmc.o >> obj-y += $(omap-hsmmc-m) $(omap-hsmmc-y) > > The related obj-y line can go now too, right? Yes, I think so. It is a construction that I have never seen before :) Therefore I did not recognize that it is related. > And looks like common.h also has struct omap2_hsmmc_info > so maybe check by grepping for hsmmc_info to see it's gone. Yes, it is just a forward-declaration of the struct name with no user anywhere. Scheduled for v3. BTW: should this series go through your tree since it is an omap machine? BR and thanks, Nikolaus
* H. Nikolaus Schaller <hns@goldelico.com> [191021 17:08]: > > > Am 21.10.2019 um 16:30 schrieb Tony Lindgren <tony@atomide.com>: > > > > * H. Nikolaus Schaller <hns@goldelico.com> [191019 18:43]: > >> --- a/arch/arm/mach-omap2/Makefile > >> +++ b/arch/arm/mach-omap2/Makefile > >> @@ -216,7 +216,6 @@ obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o > >> > >> # Platform specific device init code > >> > >> -omap-hsmmc-$(CONFIG_MMC_OMAP_HS) := hsmmc.o > >> obj-y += $(omap-hsmmc-m) $(omap-hsmmc-y) > > > > The related obj-y line can go now too, right? > > Yes, I think so. It is a construction that I have never seen before :) > Therefore I did not recognize that it is related. > > > And looks like common.h also has struct omap2_hsmmc_info > > so maybe check by grepping for hsmmc_info to see it's gone. > > Yes, it is just a forward-declaration of the struct name with > no user anywhere. > > Scheduled for v3. > > BTW: should this series go through your tree since it is an > omap machine? Or MMC tree as that's where the code change really are. Regards, Tony
- Trimmed cc-list (could be a good idea for next submission as well) On Mon, 21 Oct 2019 at 19:11, Tony Lindgren <tony@atomide.com> wrote: > > * H. Nikolaus Schaller <hns@goldelico.com> [191021 17:08]: > > > > > Am 21.10.2019 um 16:30 schrieb Tony Lindgren <tony@atomide.com>: > > > > > > * H. Nikolaus Schaller <hns@goldelico.com> [191019 18:43]: > > >> --- a/arch/arm/mach-omap2/Makefile > > >> +++ b/arch/arm/mach-omap2/Makefile > > >> @@ -216,7 +216,6 @@ obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o > > >> > > >> # Platform specific device init code > > >> > > >> -omap-hsmmc-$(CONFIG_MMC_OMAP_HS) := hsmmc.o > > >> obj-y += $(omap-hsmmc-m) $(omap-hsmmc-y) > > > > > > The related obj-y line can go now too, right? > > > > Yes, I think so. It is a construction that I have never seen before :) > > Therefore I did not recognize that it is related. > > > > > And looks like common.h also has struct omap2_hsmmc_info > > > so maybe check by grepping for hsmmc_info to see it's gone. > > > > Yes, it is just a forward-declaration of the struct name with > > no user anywhere. > > > > Scheduled for v3. > > > > BTW: should this series go through your tree since it is an > > omap machine? > > Or MMC tree as that's where the code change really are. I am okay with that. I will have a look at the series and provide some comments. Kind regards Uffe
On Sat, 19 Oct 2019 at 20:42, H. Nikolaus Schaller <hns@goldelico.com> wrote: > > Pandora_wl1251_init_card was used to do special pdata based > setup of the sdio mmc interface. This does no longer work with > v4.7 and later. A fix requires a device tree based mmc3 setup. > > Therefore we move the special setup to omap_hsmmc.c instead > of calling some pdata supplied init_card function. > > The new code checks for a DT child node compatible to wl1251 > so it will not affect other MMC3 use cases. > > Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel") > > Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> > Cc: <stable@vger.kernel.org> # 4.7.0 > --- > drivers/mmc/host/omap_hsmmc.c | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) > > diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c > index 952fa4063ff8..03ba80bcf319 100644 > --- a/drivers/mmc/host/omap_hsmmc.c > +++ b/drivers/mmc/host/omap_hsmmc.c > @@ -1512,6 +1512,27 @@ static void omap_hsmmc_init_card(struct mmc_host *mmc, struct mmc_card *card) > > if (mmc_pdata(host)->init_card) > mmc_pdata(host)->init_card(card); > + else if (card->type == MMC_TYPE_SDIO || card->type == MMC_TYPE_SD_COMBO) { > + struct device_node *np = mmc_dev(mmc)->of_node; > + > + np = of_get_compatible_child(np, "ti,wl1251"); > + if (np) { > + /* > + * We have TI wl1251 attached to MMC3. Pass this information to > + * SDIO core because it can't be probed by normal methods. > + */ > + > + dev_info(host->dev, "found wl1251\n"); > + card->quirks |= MMC_QUIRK_NONSTD_SDIO; > + card->cccr.wide_bus = 1; > + card->cis.vendor = 0x104c; > + card->cis.device = 0x9066; > + card->cis.blksize = 512; > + card->cis.max_dtr = 24000000; > + card->ocr = 0x80; These things should really be figured out by the mmc core during SDIO card initialization itself, not via the host ops ->init_card() callback. That is just poor hack, which in the long run should go away. Moreover, I think we should add a subnode to the host node in the DT, to describe the embedded SDIO card, rather than parsing the subnode for the SDIO func - as that seems wrong to me. To add a subnode for the SDIO card, we already have a binding that I think we should extend. Please have a look at Documentation/devicetree/bindings/mmc/mmc-card.txt. If you want an example of how to implement this for your case, do a git grep "broken-hpi" in the driver/mmc/core/, I think it will tell you more of what I have in mind. > + of_node_put(np); > + } > + } > } > > static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable) > -- > 2.19.1 > Kind regards Uffe
On Sat, 19 Oct 2019 at 20:42, H. Nikolaus Schaller <hns@goldelico.com> wrote: > > Since v4.7 the dma initialization requires that there is a > device tree property for "rx" and "tx" channels which is > not provided by the pdata-quirks initialization. > > By conversion of the mmc3 setup to device tree this will > finally allows to remove the OpenPandora wlan specific omap3 > data-quirks. > > Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel") > > Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> > Cc: <stable@vger.kernel.org> # 4.7.0 > --- > arch/arm/boot/dts/omap3-pandora-common.dtsi | 37 +++++++++++++++++++-- > 1 file changed, 35 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi b/arch/arm/boot/dts/omap3-pandora-common.dtsi > index ec5891718ae6..c595b3eb314d 100644 > --- a/arch/arm/boot/dts/omap3-pandora-common.dtsi > +++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi > @@ -226,6 +226,18 @@ > gpio = <&gpio6 4 GPIO_ACTIVE_HIGH>; /* GPIO_164 */ > }; > > + /* wl1251 wifi+bt module */ > + wlan_en: fixed-regulator-wg7210_en { > + compatible = "regulator-fixed"; > + regulator-name = "vwlan"; > + regulator-min-microvolt = <1800000>; > + regulator-max-microvolt = <1800000>; I doubt these are correct. I guess this should be in the range of 2.7V-3.6V. > + startup-delay-us = <50000>; > + regulator-always-on; Always on? > + enable-active-high; > + gpio = <&gpio1 23 GPIO_ACTIVE_HIGH>; > + }; > + > /* wg7210 (wifi+bt module) 32k clock buffer */ > wg7210_32k: fixed-regulator-wg7210_32k { > compatible = "regulator-fixed"; > @@ -522,9 +534,30 @@ > /*wp-gpios = <&gpio4 31 GPIO_ACTIVE_HIGH>;*/ /* GPIO_127 */ > }; > > -/* mmc3 is probed using pdata-quirks to pass wl1251 card data */ > &mmc3 { > - status = "disabled"; > + vmmc-supply = <&wlan_en>; > + > + bus-width = <4>; > + non-removable; > + ti,non-removable; > + cap-power-off-card; > + > + pinctrl-names = "default"; > + pinctrl-0 = <&mmc3_pins>; > + > + #address-cells = <1>; > + #size-cells = <0>; > + > + wlan: wl1251@1 { > + compatible = "ti,wl1251"; > + > + reg = <1>; > + > + interrupt-parent = <&gpio1>; > + interrupts = <21 IRQ_TYPE_LEVEL_HIGH>; /* GPIO_21 */ > + > + ti,wl1251-has-eeprom; > + }; > }; > > /* bluetooth*/ > -- > 2.19.1 > Kind regards Uffe
Hi Ulf, > Am 30.10.2019 um 16:51 schrieb Ulf Hansson <ulf.hansson@linaro.org>: > >> + >> + np = of_get_compatible_child(np, "ti,wl1251"); >> + if (np) { >> + /* >> + * We have TI wl1251 attached to MMC3. Pass this information to >> + * SDIO core because it can't be probed by normal methods. >> + */ >> + >> + dev_info(host->dev, "found wl1251\n"); >> + card->quirks |= MMC_QUIRK_NONSTD_SDIO; >> + card->cccr.wide_bus = 1; >> + card->cis.vendor = 0x104c; >> + card->cis.device = 0x9066; >> + card->cis.blksize = 512; >> + card->cis.max_dtr = 24000000; >> + card->ocr = 0x80; > > These things should really be figured out by the mmc core during SDIO > card initialization itself, not via the host ops ->init_card() > callback. That is just poor hack, which in the long run should go > away. Yes, I agree. But I am just the poor guy who is trying to fix really broken code with as low effort as possible. I don't even have a significant clue what this code is exactly doing and what the magic values mean. They were setup by pandora_wl1251_init_card() in the same way so that I have just moved the code here and make it called in (almost) the same situation. > Moreover, I think we should add a subnode to the host node in the DT, > to describe the embedded SDIO card, rather than parsing the subnode > for the SDIO func - as that seems wrong to me. You mean a second subnode? The wl1251 is the child node of the mmc node and describes the SDIO card. We just check if it is a wl1251 or e.g. wl1837 or something else or even no child. > To add a subnode for the SDIO card, we already have a binding that I > think we should extend. Please have a look at > Documentation/devicetree/bindings/mmc/mmc-card.txt. > > If you want an example of how to implement this for your case, do a > git grep "broken-hpi" in the driver/mmc/core/, I think it will tell > you more of what I have in mind. So while I agree that it should be improved in the long run, we should IMHO fix the hack first (broken since v4.9!), even if it remains a hack for now. Improving this part seems to be quite independent and focussed on the mmc subsystem, while the other patches involve other subsystems. Maybe should we make a REVISIT note in the code? Or add something to the commit message about the idea how it should be done right? > >> + of_node_put(np); >> + } >> + } >> } >> >> static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable) >> -- >> 2.19.1 >> > > Kind regards > Uffe BR and thanks, Nikolaus
> Am 30.10.2019 um 17:44 schrieb Ulf Hansson <ulf.hansson@linaro.org>: > > On Sat, 19 Oct 2019 at 20:42, H. Nikolaus Schaller <hns@goldelico.com> wrote: >> >> Since v4.7 the dma initialization requires that there is a >> device tree property for "rx" and "tx" channels which is >> not provided by the pdata-quirks initialization. >> >> By conversion of the mmc3 setup to device tree this will >> finally allows to remove the OpenPandora wlan specific omap3 >> data-quirks. >> >> Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel") >> >> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> >> Cc: <stable@vger.kernel.org> # 4.7.0 >> --- >> arch/arm/boot/dts/omap3-pandora-common.dtsi | 37 +++++++++++++++++++-- >> 1 file changed, 35 insertions(+), 2 deletions(-) >> >> diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi b/arch/arm/boot/dts/omap3-pandora-common.dtsi >> index ec5891718ae6..c595b3eb314d 100644 >> --- a/arch/arm/boot/dts/omap3-pandora-common.dtsi >> +++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi >> @@ -226,6 +226,18 @@ >> gpio = <&gpio6 4 GPIO_ACTIVE_HIGH>; /* GPIO_164 */ >> }; >> >> + /* wl1251 wifi+bt module */ >> + wlan_en: fixed-regulator-wg7210_en { >> + compatible = "regulator-fixed"; >> + regulator-name = "vwlan"; >> + regulator-min-microvolt = <1800000>; >> + regulator-max-microvolt = <1800000>; > > I doubt these are correct. > > I guess this should be in the range of 2.7V-3.6V. Well, it is a gpio which enables some LDO inside the wifi chip. We do not really know the voltage it produces and it does not matter. The gpio voltage is 1.8V. Basically we use a fixed-regulator to "translate" a regulator into a control gpio because the mmc interface wants to see a vmmc-supply. > >> + startup-delay-us = <50000>; >> + regulator-always-on; > > Always on? Oops. Yes, that is something to check! > >> + enable-active-high; >> + gpio = <&gpio1 23 GPIO_ACTIVE_HIGH>; >> + }; >> + >> /* wg7210 (wifi+bt module) 32k clock buffer */ >> wg7210_32k: fixed-regulator-wg7210_32k { >> compatible = "regulator-fixed"; >> @@ -522,9 +534,30 @@ >> /*wp-gpios = <&gpio4 31 GPIO_ACTIVE_HIGH>;*/ /* GPIO_127 */ >> }; >> >> -/* mmc3 is probed using pdata-quirks to pass wl1251 card data */ >> &mmc3 { >> - status = "disabled"; >> + vmmc-supply = <&wlan_en>; >> + >> + bus-width = <4>; >> + non-removable; >> + ti,non-removable; >> + cap-power-off-card; >> + >> + pinctrl-names = "default"; >> + pinctrl-0 = <&mmc3_pins>; >> + >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + wlan: wl1251@1 { >> + compatible = "ti,wl1251"; >> + >> + reg = <1>; >> + >> + interrupt-parent = <&gpio1>; >> + interrupts = <21 IRQ_TYPE_LEVEL_HIGH>; /* GPIO_21 */ >> + >> + ti,wl1251-has-eeprom; >> + }; >> }; >> >> /* bluetooth*/ >> -- >> 2.19.1 >> BR and thanks, Nikolaus
On Wed, 30 Oct 2019 at 18:25, H. Nikolaus Schaller <hns@goldelico.com> wrote: > > Hi Ulf, > > > Am 30.10.2019 um 16:51 schrieb Ulf Hansson <ulf.hansson@linaro.org>: > > > >> + > >> + np = of_get_compatible_child(np, "ti,wl1251"); > >> + if (np) { > >> + /* > >> + * We have TI wl1251 attached to MMC3. Pass this information to > >> + * SDIO core because it can't be probed by normal methods. > >> + */ > >> + > >> + dev_info(host->dev, "found wl1251\n"); > >> + card->quirks |= MMC_QUIRK_NONSTD_SDIO; > >> + card->cccr.wide_bus = 1; > >> + card->cis.vendor = 0x104c; > >> + card->cis.device = 0x9066; > >> + card->cis.blksize = 512; > >> + card->cis.max_dtr = 24000000; > >> + card->ocr = 0x80; > > > > These things should really be figured out by the mmc core during SDIO > > card initialization itself, not via the host ops ->init_card() > > callback. That is just poor hack, which in the long run should go > > away. > > Yes, I agree. > > But I am just the poor guy who is trying to fix really broken code with > as low effort as possible. I see. Thanks for looking at this mess! In general, as long as we improve the code, I am happy to move forward. However, my main concern at this point, is to make sure we get the DT bindings and the DTS files updated correctly. We don't want to come back to this again. > > I don't even have a significant clue what this code is exactly doing and what > the magic values mean. They were setup by pandora_wl1251_init_card() in the > same way so that I have just moved the code here and make it called in (almost) > the same situation. Okay! > > > Moreover, I think we should add a subnode to the host node in the DT, > > to describe the embedded SDIO card, rather than parsing the subnode > > for the SDIO func - as that seems wrong to me. > > You mean a second subnode? > > The wl1251 is the child node of the mmc node and describes the SDIO card. > We just check if it is a wl1251 or e.g. wl1837 or something else or even > no child. The reason why I brought this up, was because there are sometimes cases where an SDIO card is shared between more than one SDIO func. WiFi+Bluetooth for example, but if I am correct, that is not the case for wl1251? That said, I am happy to continue with your approach. > > > To add a subnode for the SDIO card, we already have a binding that I > > think we should extend. Please have a look at > > Documentation/devicetree/bindings/mmc/mmc-card.txt. > > > > If you want an example of how to implement this for your case, do a > > git grep "broken-hpi" in the driver/mmc/core/, I think it will tell > > you more of what I have in mind. > > So while I agree that it should be improved in the long run, we should > IMHO fix the hack first (broken since v4.9!), even if it remains a hack > for now. Improving this part seems to be quite independent and focussed > on the mmc subsystem, while the other patches involve other subsystems. I agree. > > Maybe should we make a REVISIT note in the code? Or add something to > the commit message about the idea how it should be done right? Just add a note that we should move this DT parsing of the subnode to the mmc core, but that we are leaving that as a future improvement. That's good enough. Then I can have a look as a second step, and when I get some time, to move this to the mmc core. However, there is one thing I would like you to add to the series. That is: In the struct omap_hsmmc_platform_data, there is an ->init_card() callback. Beyond the changes of this series, there is no longer any users of that, unless I am mistaken. Going forward, let's make sure it doesn't get used again, so can you please remove it!? [...] Kind regards Uffe
On Wed, 30 Oct 2019 at 18:25, H. Nikolaus Schaller <hns@goldelico.com> wrote: > > > > Am 30.10.2019 um 17:44 schrieb Ulf Hansson <ulf.hansson@linaro.org>: > > > > On Sat, 19 Oct 2019 at 20:42, H. Nikolaus Schaller <hns@goldelico.com> wrote: > >> > >> Since v4.7 the dma initialization requires that there is a > >> device tree property for "rx" and "tx" channels which is > >> not provided by the pdata-quirks initialization. > >> > >> By conversion of the mmc3 setup to device tree this will > >> finally allows to remove the OpenPandora wlan specific omap3 > >> data-quirks. > >> > >> Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel") > >> > >> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> > >> Cc: <stable@vger.kernel.org> # 4.7.0 > >> --- > >> arch/arm/boot/dts/omap3-pandora-common.dtsi | 37 +++++++++++++++++++-- > >> 1 file changed, 35 insertions(+), 2 deletions(-) > >> > >> diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi b/arch/arm/boot/dts/omap3-pandora-common.dtsi > >> index ec5891718ae6..c595b3eb314d 100644 > >> --- a/arch/arm/boot/dts/omap3-pandora-common.dtsi > >> +++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi > >> @@ -226,6 +226,18 @@ > >> gpio = <&gpio6 4 GPIO_ACTIVE_HIGH>; /* GPIO_164 */ > >> }; > >> > >> + /* wl1251 wifi+bt module */ > >> + wlan_en: fixed-regulator-wg7210_en { > >> + compatible = "regulator-fixed"; > >> + regulator-name = "vwlan"; > >> + regulator-min-microvolt = <1800000>; > >> + regulator-max-microvolt = <1800000>; > > > > I doubt these are correct. > > > > I guess this should be in the range of 2.7V-3.6V. > > Well, it is a gpio which enables some LDO inside the > wifi chip. We do not really know the voltage it produces > and it does not matter. The gpio voltage is 1.8V. > > Basically we use a fixed-regulator to "translate" a > regulator into a control gpio because the mmc interface > wants to see a vmmc-supply. The vmmc supply represent the core power to the SDIO card (or SD/(e)MMC). Depending on what voltage range the vmmc supply supports, the so called OCR mask is created by the mmc core. The mask is then used to let the core negotiate the voltage level with the SDIO card, during the card initialization. This is not to confuse with the I/O voltage level, which is a different regulator. Anyway, according to the TI WiLink series specifications, it looks like vmmc should be a regulator supporting 3-3.3V (in many schematics it's called VBAT). Furthermore I decided to dig into various DTS files that specifies the vmmc regulator, of course for mmc nodes having a subnode specifying an SDIO card for a TI WiLink. In most cases a 1.8V fixed GPIO regulator is used. This looks wrong to me. The fixed GPIO regulator isn't really the one that should model vmmc. The proper solution, would rather be to use separate regulator for vmmc and instead use a so called mmc-pwrseq node to manage the GPIO. To conclude from my side, as we have lots of DTS that are wrong, I don't really care if we add another one in the way you suggest above. But feel free to look into the mmc-pwrseq option. > > > > >> + startup-delay-us = <50000>; > >> + regulator-always-on; > > > > Always on? > > Oops. Yes, that is something to check! As it's a GPIO regulator, for sure it's not always on. > > > > >> + enable-active-high; > >> + gpio = <&gpio1 23 GPIO_ACTIVE_HIGH>; > >> + }; > >> + > >> /* wg7210 (wifi+bt module) 32k clock buffer */ > >> wg7210_32k: fixed-regulator-wg7210_32k { > >> compatible = "regulator-fixed"; > >> @@ -522,9 +534,30 @@ > >> /*wp-gpios = <&gpio4 31 GPIO_ACTIVE_HIGH>;*/ /* GPIO_127 */ > >> }; > >> > >> -/* mmc3 is probed using pdata-quirks to pass wl1251 card data */ > >> &mmc3 { > >> - status = "disabled"; > >> + vmmc-supply = <&wlan_en>; > >> + > >> + bus-width = <4>; > >> + non-removable; > >> + ti,non-removable; > >> + cap-power-off-card; > >> + > >> + pinctrl-names = "default"; > >> + pinctrl-0 = <&mmc3_pins>; > >> + > >> + #address-cells = <1>; > >> + #size-cells = <0>; > >> + > >> + wlan: wl1251@1 { > >> + compatible = "ti,wl1251"; > >> + > >> + reg = <1>; > >> + > >> + interrupt-parent = <&gpio1>; > >> + interrupts = <21 IRQ_TYPE_LEVEL_HIGH>; /* GPIO_21 */ > >> + > >> + ti,wl1251-has-eeprom; > >> + }; > >> }; > >> > >> /* bluetooth*/ > >> -- > >> 2.19.1 > >> > > BR and thanks, > Nikolaus > Kind regards Uffe
* added acked-by for wl1251 patches - Kalle Valo <kvalo@codeaurora.org> * really removed old pdata-quirks code (not through #if 0) * splited out a partial revert of efdfeb079cc3b ("regulator: fixed: Convert to use GPIO descriptor only") because that was introduced after v4.19 and stops the removal of the pdata-quirks patch from cleanly applying to v4.9, v4.14, v4.19 - reported by Sasha Levin <sashal@kernel.org> * added a new patch to remove old omap hsmmc since pdata quirks were last user - suggested by Tony Lindgren <tony@atomide.com> PATCH V1 2019-10-18 22:25:39: Here we have a set of scattered patches to make the OpenPandora WiFi work again. v4.7 did break the pdata-quirks which made the mmc3 interface fail completely, because some code now assumes device tree based instantiation. Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel") v4.11 did break the sdio qirks for wl1251 which made the driver no longer load, although the device was found as an sdio client. Fixes: 884f38607897 ("mmc: core: move some sdio IDs out of quirks file") To solve these issues: * we convert mmc3 and wl1251 initialization from pdata-quirks to device tree * we make the wl1251 driver read properties from device tree * we fix the mmc core vendor ids and quirks * we fix the wl1251 (and wl1271) driver to use only vendor ids from header file instead of (potentially conflicting) local definitions H. Nikolaus Schaller (11): Documentation: dt: wireless: update wl1251 for sdio net: wireless: ti: wl1251 add device tree support DTS: ARM: pandora-common: define wl1251 as child node of mmc3 mmc: host: omap_hsmmc: add code for special init of wl1251 to get rid of pandora_wl1251_init_card omap: pdata-quirks: revert pandora specific gpiod additions omap: pdata-quirks: remove openpandora quirks for mmc3 and wl1251 omap: remove old hsmmc.[ch] and in Makefile mmc: sdio: fix wl1251 vendor id mmc: core: fix wl1251 sdio quirks net: wireless: ti: wl1251 use new SDIO_VENDOR_ID_TI_WL1251 definition net: wireless: ti: remove local VENDOR_ID and DEVICE_ID definitions .../bindings/net/wireless/ti,wl1251.txt | 26 +++ arch/arm/boot/dts/omap3-pandora-common.dtsi | 37 +++- arch/arm/mach-omap2/Makefile | 1 - arch/arm/mach-omap2/hsmmc.c | 171 ------------------ arch/arm/mach-omap2/hsmmc.h | 32 ---- arch/arm/mach-omap2/pdata-quirks.c | 105 ----------- drivers/mmc/core/quirks.h | 7 + drivers/mmc/host/omap_hsmmc.c | 21 +++ drivers/net/wireless/ti/wl1251/sdio.c | 23 ++- drivers/net/wireless/ti/wlcore/sdio.c | 8 - include/linux/mmc/sdio_ids.h | 2 + 11 files changed, 105 insertions(+), 328 deletions(-) delete mode 100644 arch/arm/mach-omap2/hsmmc.c delete mode 100644 arch/arm/mach-omap2/hsmmc.h