| Message ID | 1525159453-32489-1-git-send-email-eyalr@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tuesday 01 May 2018 12:54 PM, Eyal Reizer wrote: > enable mmc3 used for wlan and uart1 used for bluetooth > configure the gpios used for wlan and bluetooth controls > add fixed voltage regulator used for wlan power control > > Signed-off-by: Eyal Reizer <eyalr@ti.com> ARM should be capitalized in subject line. > + > +&mmc3 { > + status = "okay"; > + /* > + * these are on the crossbar and are outlined in the > + * xbar-event-map element > + */ > + dmas = <&edma_xbar 30 0 1>, > + <&edma_xbar 31 0 2>; > + dma-names = "tx", "rx"; > + vmmc-supply = <&vmmcwl_fixed>; > + bus-width = <4>; > + pinctrl-names = "default", "sleep"; > + pinctrl-0 = <&mmc3_pins_default>; > + pinctrl-1 = <&mmc3_pins_sleep>; > + cap-power-off-card; > + keep-power-in-suspend; > + ti,non-removable; > + > + #address-cells = <1>; > + #size-cells = <0>; > + wlcore: wlcore@0 { wlcore@2 > + compatible = "ti,wl1835"; > + pinctrl-names = "default", "sleep"; > + pinctrl-0 = <&wlan_pins_default>; > + pinctrl-1 = <&wlan_pins_sleep>; > + reg = <2>; > + interrupt-parent = <&gpio4>; > + interrupts = <13 IRQ_TYPE_LEVEL_HIGH>; > + }; > +}; Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > ARM should be capitalized in subject line. OK, will be fixed in v2 > > > + > > +&mmc3 { > > + status = "okay"; > > + /* > > + * these are on the crossbar and are outlined in the > > + * xbar-event-map element > > + */ > > + dmas = <&edma_xbar 30 0 1>, > > + <&edma_xbar 31 0 2>; > > + dma-names = "tx", "rx"; > > + vmmc-supply = <&vmmcwl_fixed>; > > + bus-width = <4>; > > + pinctrl-names = "default", "sleep"; > > + pinctrl-0 = <&mmc3_pins_default>; > > + pinctrl-1 = <&mmc3_pins_sleep>; > > + cap-power-off-card; > > + keep-power-in-suspend; > > + ti,non-removable; > > + > > + #address-cells = <1>; > > + #size-cells = <0>; > > + wlcore: wlcore@0 { > > wlcore@2 > Will be fixed in v2 > > + compatible = "ti,wl1835"; > > + pinctrl-names = "default", "sleep"; > > + pinctrl-0 = <&wlan_pins_default>; > > + pinctrl-1 = <&wlan_pins_sleep>; > > + reg = <2>; > > + interrupt-parent = <&gpio4>; > > + interrupts = <13 IRQ_TYPE_LEVEL_HIGH>; > > + }; > > +}; > Best Regards, Eyal
* Eyal Reizer <eyalreizer@gmail.com> [180501 00:26]: > enable mmc3 used for wlan and uart1 used for bluetooth > configure the gpios used for wlan and bluetooth controls > add fixed voltage regulator used for wlan power control ... > / { > model = "TI AM437x SK EVM"; > @@ -158,6 +159,22 @@ > }; > }; > }; > + > + vmmcwl_fixed: fixedregulator-mmcwl { > + /* > + * WL_EN is not SDIO standard compliant. It is an out of band > + * signal and hard to be dealt with in a standard way by the > + * SDIO core driver. > + * So modelling the WL_EN line as a regulator was a natural > + * choice as the MMC core already deals with MMC supplies. > + */ > + compatible = "regulator-fixed"; > + regulator-name = "vmmcwl_fixed"; > + regulator-min-microvolt = <1800000>; > + regulator-max-microvolt = <1800000>; > + gpio = <&gpio4 8 GPIO_ACTIVE_HIGH>; > + enable-active-high; > + }; > }; Interesting that it needs much longer delay here compared to the earlier? BTW, I do have a patch in work to add pwrseq support for wlcore that allows leaving out the regulator here. It still needs a bit more work though. And I also have a series in work to make wlcore use runtime PM that needs even more work, just FYI to avoid any duplicate work. Hmm you don't happen to have a patch series somewhere making wlcore use the SDIO dat lien interrupt? I think we should use that when idle rather than the (edge) gpio interrupt as the SDIO dat interrupt is level sensitive and wired to the always on gpio bank for most SDIO controller instances. On runtime PM wakeup, there's no status anywhere to been with the GPIO edge interrupt. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > * Eyal Reizer <eyalreizer@gmail.com> [180501 00:26]: > > enable mmc3 used for wlan and uart1 used for bluetooth > > configure the gpios used for wlan and bluetooth controls > > add fixed voltage regulator used for wlan power control > ... > > / { > > model = "TI AM437x SK EVM"; > > @@ -158,6 +159,22 @@ > > }; > > }; > > }; > > + > > + vmmcwl_fixed: fixedregulator-mmcwl { > > + /* > > + * WL_EN is not SDIO standard compliant. It is an out of band > > + * signal and hard to be dealt with in a standard way by the > > + * SDIO core driver. > > + * So modelling the WL_EN line as a regulator was a natural > > + * choice as the MMC core already deals with MMC supplies. > > + */ > > + compatible = "regulator-fixed"; > > + regulator-name = "vmmcwl_fixed"; > > + regulator-min-microvolt = <1800000>; > > + regulator-max-microvolt = <1800000>; > > + gpio = <&gpio4 8 GPIO_ACTIVE_HIGH>; > > + enable-active-high; > > + }; > > }; > > Interesting that it needs much longer delay here compared to the > earlier? Where do you see a delay in here? There is no startup-delay-us value used in this patch. > > BTW, I do have a patch in work to add pwrseq support for wlcore that > allows leaving out the regulator here. It still needs a bit more > work though. > > And I also have a series in work to make wlcore use runtime PM that > needs even more work, just FYI to avoid any duplicate work. > > Hmm you don't happen to have a patch series somewhere making > wlcore use the SDIO dat lien interrupt? wilink has always used out of band interrupt (using wlan_irq gpio). in-band interrupts was not supported. See section 10.5.2 in this the wl18xx hardware integration guide: http://www.ti.com/lit/ug/swru437/swru437.pdf > > I think we should use that when idle rather than the (edge) gpio > interrupt as the SDIO dat interrupt is level sensitive and wired > to the always on gpio bank for most SDIO controller instances. > On runtime PM wakeup, there's no status anywhere to been with the > GPIO edge interrupt. > I agree that it would have been better, especially for cases such as wake On wlan, but again, in-band interrupt was something that was talked about way back but it was never implemented. Best Regards, Eyal -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Reizer, Eyal <eyalr@ti.com> [180503 06:43]: > > > > * Eyal Reizer <eyalreizer@gmail.com> [180501 00:26]: > > > enable mmc3 used for wlan and uart1 used for bluetooth > > > configure the gpios used for wlan and bluetooth controls > > > add fixed voltage regulator used for wlan power control > > ... > > > / { > > > model = "TI AM437x SK EVM"; > > > @@ -158,6 +159,22 @@ > > > }; > > > }; > > > }; > > > + > > > + vmmcwl_fixed: fixedregulator-mmcwl { > > > + /* > > > + * WL_EN is not SDIO standard compliant. It is an out of band > > > + * signal and hard to be dealt with in a standard way by the > > > + * SDIO core driver. > > > + * So modelling the WL_EN line as a regulator was a natural > > > + * choice as the MMC core already deals with MMC supplies. > > > + */ > > > + compatible = "regulator-fixed"; > > > + regulator-name = "vmmcwl_fixed"; > > > + regulator-min-microvolt = <1800000>; > > > + regulator-max-microvolt = <1800000>; > > > + gpio = <&gpio4 8 GPIO_ACTIVE_HIGH>; > > > + enable-active-high; > > > + }; > > > }; > > > > Interesting that it needs much longer delay here compared to the > > earlier? > > Where do you see a delay in here? > There is no startup-delay-us value used in this patch. Oops sorry, I misread the voltage above as the startup-delay-us value :) > > BTW, I do have a patch in work to add pwrseq support for wlcore that > > allows leaving out the regulator here. It still needs a bit more > > work though. > > > > And I also have a series in work to make wlcore use runtime PM that > > needs even more work, just FYI to avoid any duplicate work. > > > > Hmm you don't happen to have a patch series somewhere making > > wlcore use the SDIO dat lien interrupt? > wilink has always used out of band interrupt (using wlan_irq gpio). > in-band interrupts was not supported. > See section 10.5.2 in this the wl18xx hardware integration guide: > http://www.ti.com/lit/ug/swru437/swru437.pdf Hmm yeah I've been wondering about that. Why not follow the SDIO standard here though? Do you have links to documentation explaining that? > > I think we should use that when idle rather than the (edge) gpio > > interrupt as the SDIO dat interrupt is level sensitive and wired > > to the always on gpio bank for most SDIO controller instances. > > On runtime PM wakeup, there's no status anywhere to been with the > > GPIO edge interrupt. > > > I agree that it would have been better, especially for cases such as wake > On wlan, but again, in-band interrupt was something that was talked > about way back but it was never implemented. I think we can have both if performance is the reason for the out of band interrupt. We could still use SDIO dat line interrupt during idle for wake-up events. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > * Reizer, Eyal <eyalr@ti.com> [180503 06:43]: > > > > > > * Eyal Reizer <eyalreizer@gmail.com> [180501 00:26]: > > > > enable mmc3 used for wlan and uart1 used for bluetooth > > > > configure the gpios used for wlan and bluetooth controls > > > > add fixed voltage regulator used for wlan power control > > > ... > > > > / { > > > > model = "TI AM437x SK EVM"; > > > > @@ -158,6 +159,22 @@ > > > > }; > > > > }; > > > > }; > > > > + > > > > + vmmcwl_fixed: fixedregulator-mmcwl { > > > > + /* > > > > + * WL_EN is not SDIO standard compliant. It is an out of band > > > > + * signal and hard to be dealt with in a standard way by the > > > > + * SDIO core driver. > > > > + * So modelling the WL_EN line as a regulator was a natural > > > > + * choice as the MMC core already deals with MMC supplies. > > > > + */ > > > > + compatible = "regulator-fixed"; > > > > + regulator-name = "vmmcwl_fixed"; > > > > + regulator-min-microvolt = <1800000>; > > > > + regulator-max-microvolt = <1800000>; > > > > + gpio = <&gpio4 8 GPIO_ACTIVE_HIGH>; > > > > + enable-active-high; > > > > + }; > > > > }; > > > > > > Interesting that it needs much longer delay here compared to the > > > earlier? > > > > Where do you see a delay in here? > > There is no startup-delay-us value used in this patch. > > Oops sorry, I misread the voltage above as the startup-delay-us > value :) > No issue :) > > > BTW, I do have a patch in work to add pwrseq support for wlcore that > > > allows leaving out the regulator here. It still needs a bit more > > > work though. > > > > > > And I also have a series in work to make wlcore use runtime PM that > > > needs even more work, just FYI to avoid any duplicate work. > > > > > > Hmm you don't happen to have a patch series somewhere making > > > wlcore use the SDIO dat lien interrupt? > > wilink has always used out of band interrupt (using wlan_irq gpio). > > in-band interrupts was not supported. > > See section 10.5.2 in this the wl18xx hardware integration guide: > > http://www.ti.com/lit/ug/swru437/swru437.pdf > > Hmm yeah I've been wondering about that. Why not follow the SDIO > standard here though? Do you have links to documentation explaining > that? > I will try to see what I can find out and why it has always been used only With out-of band interrupts and whether there is a real hardware Limitation behind it . In the past also the omap-hsmmc driver was not really supporting in-band sdio interrupt out of the box. Not sure what is the state of it tofday. > > > I think we should use that when idle rather than the (edge) gpio > > > interrupt as the SDIO dat interrupt is level sensitive and wired > > > to the always on gpio bank for most SDIO controller instances. > > > On runtime PM wakeup, there's no status anywhere to been with the > > > GPIO edge interrupt. > > > > > I agree that it would have been better, especially for cases such as wake > > On wlan, but again, in-band interrupt was something that was talked > > about way back but it was never implemented. > > I think we can have both if performance is the reason for the > out of band interrupt. We could still use SDIO dat line interrupt > during idle for wake-up events. Correct, assuming we can make in-band interrupt work with wilink8. Best Regards, Eyal -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Reizer, Eyal <eyalr@ti.com> [180506 07:47]: > I will try to see what I can find out and why it has always been used only > With out-of band interrupts and whether there is a real hardware > Limitation behind it . > In the past also the omap-hsmmc driver was not really supporting in-band > sdio interrupt out of the box. > Not sure what is the state of it tofday. Yeah my guess is that the reason for the separate GPIO interrupt was that on omap3 we did not have SDIO interrupt working for years. This was because of the issues related to padconf interrupts for off mode. We now have Linux generic wakeirq support working with SDIO and it has been confirmed to work also for off mode with mwifiex at least. So there should be no reason to not also use the SDIO interrupt. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Tony, > > Yeah my guess is that the reason for the separate GPIO interrupt was > that on omap3 we did not have SDIO interrupt working for years. This was > because of the issues related to padconf interrupts for off mode. > > We now have Linux generic wakeirq support working with SDIO and it has > been confirmed to work also for off mode with mwifiex at least. So > there should be no reason to not also use the SDIO interrupt. > There is more to this than just the padconf. Using in-band interrupt instead of the out of band one requires Supporting a feature called "Asynchronous interrupts in 4Bit mode" Which is part of SDIO 3.0 spec: https://www.sdcard.org/downloads/pls/pdf/index.php?p=PartE1_SDIO_Simplified_Specification_Ver3.00.jpg&f=PartE1_SDIO_Simplified_Specification_Ver3.00.pdf&e=EN_SSE1 Take a look at page 41 at the bottom part of the table. Wilink8 supports this feature but AFAIK this support is still not part of the mmc/sdio core in the Linux kernel. If we want wilink8 to trigger a host wakeup using the in-band interrupt instead Of the wlan_irq pin we would need to enable/use this feature. I did use it internally in the past and was able to patch the Ubuntu kernel (3.5.0 at that time) to use wilink8 in a standard SD Card slot of an Ubuntu Laptop while removing the use of wlan_irq pin completely. However this was an experimental patch set written by a third party that was not up-steamtable at that time. I do have this patch set somewhere... It is similar to the following patch which is not upstream as well for some reason: https://gitlab.com/k2wl/g2_kernel/commit/5c4970fdaa50422d7ea7220efa20fb35148a4bca It is not the only patch needed, there are a couple of additional patches needed for fully using it from driver. I did check latest Linux-next and don't see this support there. Not sure why. Best Regards, Eyal -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Reizer, Eyal <eyalr@ti.com> [180507 06:57]: > Hi Tony, > > > > > Yeah my guess is that the reason for the separate GPIO interrupt was > > that on omap3 we did not have SDIO interrupt working for years. This was > > because of the issues related to padconf interrupts for off mode. > > > > We now have Linux generic wakeirq support working with SDIO and it has > > been confirmed to work also for off mode with mwifiex at least. So > > there should be no reason to not also use the SDIO interrupt. > > > > There is more to this than just the padconf. > Using in-band interrupt instead of the out of band one requires > Supporting a feature called "Asynchronous interrupts in 4Bit mode" > Which is part of SDIO 3.0 spec: > https://www.sdcard.org/downloads/pls/pdf/index.php?p=PartE1_SDIO_Simplified_Specification_Ver3.00.jpg&f=PartE1_SDIO_Simplified_Specification_Ver3.00.pdf&e=EN_SSE1 > > Take a look at page 41 at the bottom part of the table. > Wilink8 supports this feature but AFAIK this support is still not part of the > mmc/sdio core in the Linux kernel. > If we want wilink8 to trigger a host wakeup using the in-band interrupt instead > Of the wlan_irq pin we would need to enable/use this feature. Well the SDIO dat line interrupt is working just fine with mwifiex_sdio driver and runtime PM like I said :) > I did use it internally in the past and was able to patch the Ubuntu kernel > (3.5.0 at that time) to use wilink8 in a standard SD Card slot of an Ubuntu Laptop > while removing the use of wlan_irq pin completely. > However this was an experimental patch set written by a third party > that was not up-steamtable at that time. > I do have this patch set somewhere... > > It is similar to the following patch which is not upstream as well for some reason: > https://gitlab.com/k2wl/g2_kernel/commit/5c4970fdaa50422d7ea7220efa20fb35148a4bca > It is not the only patch needed, there are a couple of additional patches needed > for fully using it from driver. > I did check latest Linux-next and don't see this support there. Not sure why. Hmm not sure if this is needed here. When things enter idle, the whole SDIO block is off and the SDIO dat interrupt is delivered as wakeirq to the pinctrl-single driver instead that manages padconf wake events. Then we have runtime PM wake up MMC subsystem and the SDIO dat line interrupt is still there and will trigger as it's level sensitive. So the test to do would be simply configure wlcore to use SDIO dat line interrupt instead of the GPIO interrupt and configure a wakeirq for the board on the SDIO dat line. Sounds like I need to get my wlcore runtime PM patches ready though as that is needed for using the wakeirq. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts index 16d9db0..afffdb1 100644 --- a/arch/arm/boot/dts/am437x-sk-evm.dts +++ b/arch/arm/boot/dts/am437x-sk-evm.dts @@ -15,6 +15,7 @@ #include <dt-bindings/pwm/pwm.h> #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/input/input.h> +#include <dt-bindings/interrupt-controller/irq.h> / { model = "TI AM437x SK EVM"; @@ -158,6 +159,22 @@ }; }; }; + + vmmcwl_fixed: fixedregulator-mmcwl { + /* + * WL_EN is not SDIO standard compliant. It is an out of band + * signal and hard to be dealt with in a standard way by the + * SDIO core driver. + * So modelling the WL_EN line as a regulator was a natural + * choice as the MMC core already deals with MMC supplies. + */ + compatible = "regulator-fixed"; + regulator-name = "vmmcwl_fixed"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + gpio = <&gpio4 8 GPIO_ACTIVE_HIGH>; + enable-active-high; + }; }; &am43xx_pinmux { @@ -424,6 +441,62 @@ AM4372_IOPAD(0xac4, PIN_OUTPUT | MUX_MODE0) /* usb0_drvvbus.usb0_drvvbus */ >; }; + + mmc3_pins_default: pinmux_mmc3_pins_default { + pinctrl-single,pins = < + AM4372_IOPAD(0x9f0, PIN_INPUT_PULLUP | MUX_MODE3) /* (AD21) cam1_data2.mmc2_clk */ + AM4372_IOPAD(0x9f4, PIN_INPUT_PULLUP | MUX_MODE3) /* (AE22) cam1_data3.mmc2_cmd */ + AM4372_IOPAD(0x9f8, PIN_INPUT_PULLUP | MUX_MODE3) /* (AD22) cam1_data4.mmc2_dat0 */ + AM4372_IOPAD(0x9fc, PIN_INPUT_PULLUP | MUX_MODE3) /* (AE23) cam1_data5.mmc2_dat1 */ + AM4372_IOPAD(0xa00, PIN_INPUT_PULLUP | MUX_MODE3) /* (AD23) cam1_data6.mmc2_dat2 */ + AM4372_IOPAD(0xa04, PIN_INPUT_PULLUP | MUX_MODE3) /* (AE24) cam1_data7.mmc2_dat3 */ + >; + }; + + mmc3_pins_sleep: pinmux_mmc3_pins_sleep { + pinctrl-single,pins = < + AM4372_IOPAD(0x9f0, PIN_INPUT_PULLDOWN | MUX_MODE7) /* (AD21) cam1_data2.mmc2_clk */ + AM4372_IOPAD(0x9f4, PIN_INPUT_PULLDOWN | MUX_MODE7) /* (AE22) cam1_data3.mmc2_cmd */ + AM4372_IOPAD(0x9f8, PIN_INPUT_PULLDOWN | MUX_MODE7) /* (AD22) cam1_data4.mmc2_dat0 */ + AM4372_IOPAD(0x9fc, PIN_INPUT_PULLDOWN | MUX_MODE7) /* (AE23) cam1_data5.mmc2_dat1 */ + AM4372_IOPAD(0xa00, PIN_INPUT_PULLDOWN | MUX_MODE7) /* (AD23) cam1_data6.mmc2_dat2 */ + AM4372_IOPAD(0xa04, PIN_INPUT_PULLDOWN | MUX_MODE7) /* (AE24) cam1_data7.mmc2_dat3 */ + >; + }; + + wlan_pins_default: pinmux_wlan_pins_default { + pinctrl-single,pins = < + AM4372_IOPAD(0x9d0, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* cam1_data8.gpio4_8 WL_EN */ + AM4372_IOPAD(0x9e4, PIN_INPUT | WAKEUP_ENABLE | MUX_MODE7) /* cam1_wen.gpio4_13 WL_IRQ */ + >; + }; + + wlan_pins_sleep: pinmux_wlan_pins_sleep { + pinctrl-single,pins = < + AM4372_IOPAD(0x9d0, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* cam1_data8.gpio4_8 WL_EN */ + AM4372_IOPAD(0x9e4, PIN_INPUT | WAKEUP_ENABLE | MUX_MODE7) /* cam1_wen.gpio4_13 WL_IRQ */ + >; + }; + + uart1_bt_pins_default: pinmux_uart1_bt_pins_default { + pinctrl-single,pins = < + AM4372_IOPAD(0x980, PIN_INPUT | MUX_MODE0) /* uart1_rxd.uart1_rxd */ + AM4372_IOPAD(0x984, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* uart1_txd.uart1_txd */ + AM4372_IOPAD(0x978, PIN_INPUT_PULLUP | MUX_MODE0) /* uart1_ctsn.uart1_ctsn */ + AM4372_IOPAD(0x97c, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* uart1_rtsn.uart1_rtsn */ + AM4372_IOPAD(0x9cc, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* cam1_data9.gpio4_7 BT_EN */ + >; + }; + + uart1_bt_pins_sleep: pinmux_uart1_bt_pins_sleep { + pinctrl-single,pins = < + AM4372_IOPAD(0x980, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* uart1_rxd.uart1_rxd */ + AM4372_IOPAD(0x984, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* uart1_txd.uart1_txd */ + AM4372_IOPAD(0x978, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* uart1_ctsn.uart1_ctsn */ + AM4372_IOPAD(0x97c, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* uart1_rtsn.uart1_rtsn */ + AM4372_IOPAD(0x9cc, PIN_OUTPUT_PULLUP | MUX_MODE7) /* cam1_data9.gpio4_7 BT_EN */ + >; + }; }; &i2c0 { @@ -606,6 +679,10 @@ status = "okay"; }; +&gpio4 { + status = "okay"; +}; + &gpio5 { status = "okay"; }; @@ -620,6 +697,44 @@ cd-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>; }; +&uart1 { + status = "okay"; + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&uart1_bt_pins_default>; + pinctrl-1 = <&uart1_bt_pins_sleep>; +}; + +&mmc3 { + status = "okay"; + /* + * these are on the crossbar and are outlined in the + * xbar-event-map element + */ + dmas = <&edma_xbar 30 0 1>, + <&edma_xbar 31 0 2>; + dma-names = "tx", "rx"; + vmmc-supply = <&vmmcwl_fixed>; + bus-width = <4>; + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&mmc3_pins_default>; + pinctrl-1 = <&mmc3_pins_sleep>; + cap-power-off-card; + keep-power-in-suspend; + ti,non-removable; + + #address-cells = <1>; + #size-cells = <0>; + wlcore: wlcore@0 { + compatible = "ti,wl1835"; + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&wlan_pins_default>; + pinctrl-1 = <&wlan_pins_sleep>; + reg = <2>; + interrupt-parent = <&gpio4>; + interrupts = <13 IRQ_TYPE_LEVEL_HIGH>; + }; +}; + &usb2_phy1 { status = "okay"; };
enable mmc3 used for wlan and uart1 used for bluetooth configure the gpios used for wlan and bluetooth controls add fixed voltage regulator used for wlan power control Signed-off-by: Eyal Reizer <eyalr@ti.com> --- arch/arm/boot/dts/am437x-sk-evm.dts | 115 ++++++++++++++++++++++++++++++++++++ 1 file changed, 115 insertions(+)