ARM: shmobile: Add SDHI devices for Koelsch DTS
Subsystems (2)
PATCH v2 2/2 ARM: shmobile: Add SDHI devices for Koelsch DTS
From: Magnus Damm <[email protected]>
Add DT support for SDHI0, SDHI1 and SDHI2 on Koelsch.
The board specific handling of CD and WP pins are using GPIOs. SDHI0 and SDHI1 are hooked up to regular SD connectors while SDHI2 is using micro-SD which is lacking WP signal.
---
Changes since V1:
- Remove unclean misc caps that now are covered by the SDHI driver.
arch/arm/boot/dts/r8a7791-koelsch.dts | 119 +++++++++++++++++++++++++++++++++ 1 file changed, 119 insertions(+)
arch/arm/boot/dts/r8a7791-koelsch.dts +119 -0
@@ -102,6 +102,78 @@ gpios = <&gpio2 21 GPIO_ACTIVE_HIGH>; }; }; + + vcc_sdhi0: regulator@0 { + compatible = "regulator-fixed"; + + regulator-name = "SDHI0 Vcc"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + + gpio = <&gpio7 17 GPIO_ACTIVE_HIGH>; + enable-active-high; + }; + + vccq_sdhi0: regulator@1 { + compatible = "regulator-gpio"; + + regulator-name = "SDHI0 VccQ"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + + gpios = <&gpio2 12 GPIO_ACTIVE_HIGH>; + gpios-states = <1>; + states = <3300000 1 + 1800000 0>; + }; + + vcc_sdhi1: regulator@2 { + compatible = "regulator-fixed"; + + regulator-name = "SDHI1 Vcc"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + + gpio = <&gpio7 18 GPIO_ACTIVE_HIGH>; + enable-active-high; + }; + + vccq_sdhi1: regulator@3 { + compatible = "regulator-gpio"; + + regulator-name = "SDHI1 VccQ"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + + gpios = <&gpio2 13 GPIO_ACTIVE_HIGH>; + gpios-states = <1>; + states = <3300000 1 + 1800000 0>; + }; + + vcc_sdhi2: regulator@4 { + compatible = "regulator-fixed"; + + regulator-name = "SDHI2 Vcc"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + + gpio = <&gpio7 19 GPIO_ACTIVE_HIGH>; + enable-active-high; + }; + + vccq_sdhi2: regulator@5 { + compatible = "regulator-gpio"; + + regulator-name = "SDHI2 VccQ"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + + gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>; + gpios-states = <1>; + states = <3300000 1 + 1800000 0>; + }; }; &extal_clk {
@@ -122,6 +194,21 @@ renesas,function = "scif1"; }; + sdhi0_pins: sd0 { + renesas,gpios = "sdhi0_data4", "sdhi0_ctrl"; + renesas,function = "sdhi0"; + }; + + sdhi1_pins: sd1 { + renesas,gpios = "sdhi1_data4", "sdhi1_ctrl"; + renesas,function = "sdhi1"; + }; + + sdhi2_pins: sd2 { + renesas,gpios = "sdhi2_data4", "sdhi2_ctrl"; + renesas,function = "sdhi2"; + }; + qspi_pins: spi { renesas,groups = "qspi_ctrl", "qspi_data4"; renesas,function = "qspi";
@@ -132,6 +219,38 @@ status = "okay"; }; +&sdhi0 { + pinctrl-0 = <&sdhi0_pins>; + pinctrl-names = "default"; + + vmmc-supply = <&vcc_sdhi0>; + vqmmc-supply = <&vccq_sdhi0>; + cd-gpios = <&gpio6 6 GPIO_ACTIVE_LOW>; + wp-gpios = <&gpio6 7 GPIO_ACTIVE_HIGH>; + status = "okay"; +}; + +&sdhi1 { + pinctrl-0 = <&sdhi1_pins>; + pinctrl-names = "default"; + + vmmc-supply = <&vcc_sdhi1>; + vqmmc-supply = <&vccq_sdhi1>; + cd-gpios = <&gpio6 14 GPIO_ACTIVE_LOW>; + wp-gpios = <&gpio6 15 GPIO_ACTIVE_HIGH>; + status = "okay"; +}; + +&sdhi2 { + pinctrl-0 = <&sdhi2_pins>; + pinctrl-names = "default"; + + vmmc-supply = <&vcc_sdhi2>; + vqmmc-supply = <&vccq_sdhi2>; + cd-gpios = <&gpio6 22 GPIO_ACTIVE_LOW>; + status = "okay"; +}; + &spi { pinctrl-0 = <&qspi_pins>; pinctrl-names = "default";
Hello.
Quoted 6 lines · Magnus Damm
From: Magnus Damm <[email protected]>
Add DT support for SDHI0, SDHI1 and SDHI2 on Koelsch.
The board specific handling of CD and WP pins are
using GPIOs.
Frankly speaking, I didn't understand why. The native SDHI[012] CD/WP pins
are used in the legacy Koelsch code, why not do the same in the device tree?
Quoted 5 lines
SDHI0 and SDHI1 are hooked up to regular
SD connectors while SDHI2 is using micro-SD which
is lacking WP signal.Signed-off-by Magnus Damm <[email protected]>
PS: I've done some limited testing of the SDHI using the dedicated CD/WP pins on both Koelsch and Henninger boards; I haven't tested card insertion/removal since I only have remote access to the boards and it's holiday in Russia anyway. :-)
WBR, Sergei
Hello.
Quoted 9 lines · Sergei Shtylyov
Quoted 6 lines
From: Magnus Damm <[email protected]>
Add DT support for SDHI0, SDHI1 and SDHI2 on Koelsch.
The board specific handling of CD and WP pins are
using GPIOs.Frankly speaking, I didn't understand why. The native SDHI[012] CD/WP pins
are used in the legacy Koelsch code, why not do the same in the device tree?
Ah, after looking at the SDHI driver, it seems I've figured that out: it
only can use GPIO for the CD signal, and the WP signal is ignored for R-Car gen2 SoCs, so that only GPIO can actually work... Now I'm wondering how the legacy code manages to work. :-)
Quoted 5 lines
Quoted 5 lines
SDHI0 and SDHI1 are hooked up to regular
SD connectors while SDHI2 is using micro-SD which
is lacking WP signal.Signed-off-by Magnus Damm <[email protected]>
WBR, Sergei
Hi Sergei,
Quoted 21 lines · Sergei Shtylyov
Hello.
Quoted 6 lines · Sergei Shtylyov
Quoted 4 lines
From: Magnus Damm <[email protected]>
Add DT support for SDHI0, SDHI1 and SDHI2 on Koelsch.
Quoted 8 lines
Quoted 2 lines
The board specific handling of CD and WP pins are
using GPIOs.Frankly speaking, I didn't understand why. The native SDHI[012] CD/WP
pins
are used in the legacy Koelsch code, why not do the same in the device tree?
Quoted 4 lines
Ah, after looking at the SDHI driver, it seems I've figured that out: it
only can use GPIO for the CD signal, and the WP signal is ignored for R-Car gen2 SoCs, so that only GPIO can actually work... Now I'm wondering how the legacy code manages to work. :-)
I believe the WP and CD signals are not included on all SDHI implementations. Only some have it. So for the cases when no WP and CD are implemented by a certain SDHI instance or when more flexible pin assignment has been used GPIO is a good choice. Also, as you know, the WP signal is not used in case of micro-SD, so all these tend to be pretty board specific. And they are not exactly performance sensitive, so I think it is good to optimize for flexibility over performance for those signals.
Cheers,
/ magnus