Re: [PATCH] arm64: dts: rockchip: Fix rk3328-roc-cc sdmmcio-regulator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2020-02-01 12:46 p.m., Robin Murphy wrote:
> On 2020-02-01 3:41 pm, Adam Van Ymeren wrote:
>>
>> On 2020-02-01 5:51 a.m., Robin Murphy wrote:
>>> Hi Adam,
>>>
>>> On 2020-01-31 11:38 pm, Adam Van Ymeren wrote:
>>>> With this change the kernel successfully finds the SD Card and can
>>>> load
>>>> a rootfs from it.  Tested on hardware.
>>>>
>>>> Signed-off-by: Adam Van Ymeren <adam@xxxxxxx>
>>>>
>>>> diff -uprN -X linux-5.5/Documentation/dontdiff
>>>> linux-5.5-orig/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
>>>> linux-5.5/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
>>>> --- linux-5.5-orig/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
>>>> 2020-01-26 19:23:03.000000000 -0500
>>>> +++ linux-5.5/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
>>>> 2020-01-31 16:26:35.377075419 -0500
>>>> @@ -44,7 +44,7 @@
>>>>          vcc_sdio: sdmmcio-regulator {
>>>>            compatible = "regulator-gpio";
>>>> -        gpios = <&grf_gpio 0 GPIO_ACTIVE_HIGH>;
>>>> +        gpios = <&gpio0 RK_PD1 GPIO_ACTIVE_HIGH>;
>>>
>>> Given that the RK3328 datasheet has no mention of GPIO0_D1 existing at
>>> all, how sure are you that this is correct - have you tested cards in
>>> both 3.3V and 1.8V (UHS-1) signalling modes?
>>>
>>> The ROC-RK3328-CC schematics show GPIO_MUTE being used to bias the
>>> feedback pin of an adjustable regulator supplying the SDMMC0 I/O
>>> domain, so it seems more likely that the pin is correct but the states
>>> (or the polarity) are backwards.
>>
>>
>> Hmm yeah after reading the schematics this doesn't make sense.  I took
>> it from the vendors source tree[1], and it definitely allowed my system
>> to boot when it wouldn't before, but I only tried a 3.3V card.  I'll try
>> just changing the polarity.  I'll also find a UHS-1 card and test that,
>> any advice on how to verify that it's running in the 1.8V mode?
>
> My preferred method is to stick a meter on either the uSD socket pins
> or the regulator itself and wiggle the GPIO from userspace, but
> preferably only if the board can run without a card inserted.
>
> That said, I just suddenly remembered about regulator GPIOs being
> quirky for legacy ABI reasons - I'm now 99% sure that you should
> simply need to add the "enable-active-high" property to make it
> actually work as expected.
>

Whelp I did a whole bunch of tracing and debugging only to realize that
I didn't have CONFIG_GPIO_SYSCON enabled, so big suprise the gpio-syscon
driver needed for grf-gpio never came online.  After turning that on I get

[    1.277115] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req
400000Hz, actual 400000HZ div = 0)

in my dmesg, which is more than I used to get.  However it fails to
detect the SDCard.  I tried with and without enable-active-high; on the
sdmmcio-regulator entry, neither seemed to make a difference.  I'll do
some more debugging in a bit, its always possible I did something stupid
like use the wrong .dtb file (or build without CONFIG_GPIO_SYSCON).


Thanks again!

-Adam

|

|

||

|

|

|

|||


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-rockchip




[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux