From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robin Murphy Subject: Re: [PATCH 5/5] arm64: dts: rockchip: Fix nanopi4 uSD card detect Date: Tue, 8 Jan 2019 23:22:01 +0000 Message-ID: References: <83098c7ecc471a77dd89564f5f98fcf30c1ed431.1546981251.git.robin.murphy@arm.com> <6925511.AQqqGbhmY3@phil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <6925511.AQqqGbhmY3@phil> Content-Language: en-GB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Heiko Stuebner Cc: linux-rockchip@lists.infradead.org, tomeu.vizoso@collabora.com, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org List-Id: devicetree@vger.kernel.org On 2019-01-08 10:42 pm, Heiko Stuebner wrote: > Am Dienstag, 8. Januar 2019, 22:57:27 CET schrieb Robin Murphy: >> For whatever reason, the sdmmc_dectn function isn't working properly >> as-is, and microSD insertion and removal goes unnoticed. Flipping the >> pin into GPIO mode, however, does do the job, so let's just handle it >> that way for now until someone feels inclined to figure out what GRF >> voodoo or otherwise is needed for correct 'native' operation. >> >> Signed-off-by: Robin Murphy >> --- >> arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi | 7 ++++++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi >> index 9c723038d8f8..2a183a6af150 100644 >> --- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi >> +++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi >> @@ -505,6 +505,10 @@ >> sdmmc0_pwr_h: sdmmc0-pwr-h { >> rockchip,pins = <0 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>; >> }; >> + >> + sdmmc0_det_l: sdmmc0-det-l { > > alphabetically by node-name please, > aka sdmmc0-det-* should be above sdmmc0-pwr-* Right you are, not sure how that one slipped through. > If you're respinning the whole series this should be fixed, > otherwise I can also do that when applying. I've fixed it up locally, although it might be worth holding off on this particular patch for the moment now that I've taken another look through the TRM and noticed those smoking-gun-looking bits in GRF_SIG_DETECT_CON{0,1} - I'll investigate... [ side note - do you reckon there'd be any value in bolting a debugfs interface onto the GRF driver, or is the realistic answer to just use /dev/mem like everyone else and stop having silly ideas? ] Thanks, Robin. > > > Heiko > >> + rockchip,pins = <0 RK_PA7 RK_FUNC_GPIO &pcfg_pull_up>; >> + }; >> }; >> >> sdio-pwrseq { >> @@ -563,9 +567,10 @@ >> bus-width = <4>; >> cap-sd-highspeed; >> cap-mmc-highspeed; >> + cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>; >> disable-wp; >> pinctrl-names = "default"; >> - pinctrl-0 = <&sdmmc_bus4 &sdmmc_cd &sdmmc_clk &sdmmc_cmd>; >> + pinctrl-0 = <&sdmmc_bus4 &sdmmc0_det_l &sdmmc_clk &sdmmc_cmd>; >> sd-uhs-sdr104; >> vmmc-supply = <&vcc3v0_sd>; >> vqmmc-supply = <&vcc_sdio>; >> > > > >