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

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

[Adam Van Ymeren]

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@vany.ca>

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>;
 		states = <1800000 0x1
 			  3300000 0x0>;
 		regulator-name = "vcc_sdio";

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

[Adam Van Ymeren]

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@vany.ca>

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>;
 		states = <1800000 0x1
 			  3300000 0x0>;
 		regulator-name = "vcc_sdio";

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Robin Murphy]

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@vany.ca>
> 
> 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.

Robin.

>   		states = <1800000 0x1
>   			  3300000 0x0>;
>   		regulator-name = "vcc_sdio";
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
> 

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

[Robin Murphy]

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@vany.ca>
> 
> 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.

Robin.

>   		states = <1800000 0x1
>   			  3300000 0x0>;
>   		regulator-name = "vcc_sdio";
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Adam Van Ymeren]

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@vany.ca>
>>
>> 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?

[1]
https://github.com/FireflyTeam/kernel/blob/rk3328/firefly/arch/arm64/boot/dts/rockchip/rk3328-firefly-core.dtsi#L89


Thanks for the review!

-Adam


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Robin Murphy]

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@vany.ca>
>>>
>>> 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.

Robin.

>
> [1]
> https://github.com/FireflyTeam/kernel/blob/rk3328/firefly/arch/arm64/boot/dts/rockchip/rk3328-firefly-core.dtsi#L89
> 
> 
> Thanks for the review!
> 
> -Adam
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Adam Van Ymeren]

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@vany.ca>
>>>>
>>>> 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-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Peter Geis]

On Sat, Feb 1, 2020 at 5:10 PM Adam Van Ymeren <adam-M8Nx6PV4agg@public.gmane.org> wrote:
>
>
> 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-M8Nx6PV4agg@public.gmane.org>
> >>>>
> >>>> 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).

I'm interested in this, since I've encountered some oddities with the
sdcard on this board.
With the recent addition of support for ddr4 tpl init in u-boot I
started playing with it again.
I couldn't get the sdcard to detect leaving tpl into spl, causing a
boot failure.
The exact same image works when flashed to the emmc though.

Once we are in the kernel the sdcard detects fine.

I noticed u-boot doesn't have a grf-gpio driver, so the 3.3v/1.8v
regulator is unavailable.

root@firefly:/sys/kernel/debug/mmc1# cat ios
clock:          150000000 Hz
actual clock:   150000000 Hz
vdd:            21 (3.3 ~ 3.4 V)
bus mode:       2 (push-pull)
chip select:    0 (don't care)
power mode:     2 (on)
bus width:      2 (4 bits)
timing spec:    6 (sd uhs SDR104)
signal voltage: 1 (1.80 V)
driver type:    0 (driver type B)

root@firefly:/sys/kernel/debug# cat gpio
gpiochip0: GPIOs 0-31, parent: platform/pinctrl, gpio0:
 gpio-0   (                    |vcc-host-5v-regulato) out hi
 gpio-30  (                    |sdmmc-regulator     ) out lo ACTIVE LOW

gpiochip1: GPIOs 32-63, parent: platform/pinctrl, gpio1:
 gpio-50  (                    |snps,reset          ) out hi ACTIVE LOW
 gpio-58  (                    |vcc-host1-5v-regulat) out hi

gpiochip2: GPIOs 64-95, parent: platform/pinctrl, gpio2:

gpiochip3: GPIOs 96-127, parent: platform/pinctrl, gpio3:

gpiochip5: GPIOs 509-510, parent: platform/rk805-pinctrl, rk805-gpio, can sleep:
 gpio-509 (                    |?                   ) out hi ACTIVE LOW
 gpio-510 (                    |?                   ) out hi ACTIVE LOW

gpiochip4: GPIOs 511-511, parent: platform/ff100000.syscon:grf-gpio,
ff100000.syscon:grf-gpio:
 gpio-511 (                    |vcc_sdio            ) out hi

>
>
> Thanks again!
>
> -Adam
>
> |
>
> |
>
> ||
>
> |
>
> |
>
> |
>
> |||
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

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

[Peter Geis]

On Sat, Feb 1, 2020 at 5:10 PM Adam Van Ymeren <adam@vany.ca> wrote:
>
>
> 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@vany.ca>
> >>>>
> >>>> 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).

I'm interested in this, since I've encountered some oddities with the
sdcard on this board.
With the recent addition of support for ddr4 tpl init in u-boot I
started playing with it again.
I couldn't get the sdcard to detect leaving tpl into spl, causing a
boot failure.
The exact same image works when flashed to the emmc though.

Once we are in the kernel the sdcard detects fine.

I noticed u-boot doesn't have a grf-gpio driver, so the 3.3v/1.8v
regulator is unavailable.

root@firefly:/sys/kernel/debug/mmc1# cat ios
clock:          150000000 Hz
actual clock:   150000000 Hz
vdd:            21 (3.3 ~ 3.4 V)
bus mode:       2 (push-pull)
chip select:    0 (don't care)
power mode:     2 (on)
bus width:      2 (4 bits)
timing spec:    6 (sd uhs SDR104)
signal voltage: 1 (1.80 V)
driver type:    0 (driver type B)

root@firefly:/sys/kernel/debug# cat gpio
gpiochip0: GPIOs 0-31, parent: platform/pinctrl, gpio0:
 gpio-0   (                    |vcc-host-5v-regulato) out hi
 gpio-30  (                    |sdmmc-regulator     ) out lo ACTIVE LOW

gpiochip1: GPIOs 32-63, parent: platform/pinctrl, gpio1:
 gpio-50  (                    |snps,reset          ) out hi ACTIVE LOW
 gpio-58  (                    |vcc-host1-5v-regulat) out hi

gpiochip2: GPIOs 64-95, parent: platform/pinctrl, gpio2:

gpiochip3: GPIOs 96-127, parent: platform/pinctrl, gpio3:

gpiochip5: GPIOs 509-510, parent: platform/rk805-pinctrl, rk805-gpio, can sleep:
 gpio-509 (                    |?                   ) out hi ACTIVE LOW
 gpio-510 (                    |?                   ) out hi ACTIVE LOW

gpiochip4: GPIOs 511-511, parent: platform/ff100000.syscon:grf-gpio,
ff100000.syscon:grf-gpio:
 gpio-511 (                    |vcc_sdio            ) out hi

>
>
> Thanks again!
>
> -Adam
>
> |
>
> |
>
> ||
>
> |
>
> |
>
> |
>
> |||
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Adam Van Ymeren]

On 2020-02-04 10:15 a.m., Peter Geis wrote:
> I'm interested in this, since I've encountered some oddities with the
> sdcard on this board.
> With the recent addition of support for ddr4 tpl init in u-boot I
> started playing with it again.
> I couldn't get the sdcard to detect leaving tpl into spl, causing a
> boot failure.
> The exact same image works when flashed to the emmc though.

Awesome I was hoping to get mainline u-boot loading this board as well. 
However I don't know how to setup the sdram-params for the dd4 on this
board.  Do you have the appropriate config?  Would be great not to
require the vendor's blob for booting.

>
> Once we are in the kernel the sdcard detects fine.
>
> I noticed u-boot doesn't have a grf-gpio driver, so the 3.3v/1.8v
> regulator is unavailable.
>
> root@firefly:/sys/kernel/debug/mmc1# cat ios
> clock:          150000000 Hz
> actual clock:   150000000 Hz
> vdd:            21 (3.3 ~ 3.4 V)
> bus mode:       2 (push-pull)
> chip select:    0 (don't care)
> power mode:     2 (on)
> bus width:      2 (4 bits)
> timing spec:    6 (sd uhs SDR104)
> signal voltage: 1 (1.80 V)
> driver type:    0 (driver type B)
>
> root@firefly:/sys/kernel/debug# cat gpio
> gpiochip0: GPIOs 0-31, parent: platform/pinctrl, gpio0:
>  gpio-0   (                    |vcc-host-5v-regulato) out hi
>  gpio-30  (                    |sdmmc-regulator     ) out lo ACTIVE LOW
>
> gpiochip1: GPIOs 32-63, parent: platform/pinctrl, gpio1:
>  gpio-50  (                    |snps,reset          ) out hi ACTIVE LOW
>  gpio-58  (                    |vcc-host1-5v-regulat) out hi
>
> gpiochip2: GPIOs 64-95, parent: platform/pinctrl, gpio2:
>
> gpiochip3: GPIOs 96-127, parent: platform/pinctrl, gpio3:
>
> gpiochip5: GPIOs 509-510, parent: platform/rk805-pinctrl, rk805-gpio, can sleep:
>  gpio-509 (                    |?                   ) out hi ACTIVE LOW
>  gpio-510 (                    |?                   ) out hi ACTIVE LOW
>
> gpiochip4: GPIOs 511-511, parent: platform/ff100000.syscon:grf-gpio,
> ff100000.syscon:grf-gpio:
>  gpio-511 (                    |vcc_sdio            ) out hi


On my board I tried every combination of GPIO_ACTIVE_HIGH/LOW,
enable-active-high or not, and state = <18... 0x1 33... 0x0> vs state =
<18... 0x0 33...0x1> for the vcc_sdio regulator.  None of those allowed
my kernel to detect the SD Card.  The only reliable method so far seem
to be setting the gpio of the regulator to some non existent pin, but
that clearly isn't the corrent answer.  Both gpios = <&gpio0 25
GPIO_ACTIVE_HIGH> and gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH> allow the
board to board, both of which are non-existent pins from my reading of
the datasheet.

I'm beginning to suspect that it may be a bug in the gpio-syscon driver,
or that the actual circuit on the board just doesn't work as the vendor
intended.

In my dmesg I see

[    0.406830] gpio-syscon ff100000.syscon:grf-gpio: can't read the data
register offset!

which is awfully suspicious.  But this doesn't appear to be a fatal
error for the driver, logging _regmap_write calls shows that it appears
to be updating the correct register (0x428)


From gpio-syscon.c:134

|

static void rockchip_gpio_set(struct gpio_chip *chip, unsigned int offset,
			      int val)
{
	struct syscon_gpio_priv *priv = gpiochip_get_data(chip);
	unsigned int offs;
	u8 bit;
	u32 data;
	int ret;

	offs = priv->dreg_offset + priv->data->dat_bit_offset + offset;
	bit = offs % SYSCON_REG_BITS;
	data = (val ? BIT(bit) : 0) | BIT(bit + 16);
	ret = regmap_write(priv->syscon,
			   (offs / SYSCON_REG_BITS) * SYSCON_REG_SIZE,
			   data);
	if (ret < 0)
		dev_err(chip->parent, "gpio write failed ret(%d)\n", ret);
}

Calling regmap_write seems wrong, as we end up setting all bits in the register, so this should probably be regmap_update_bits.  The top 16-bits are write-enable for the lower 16-bits, but I can't find documentation if it works to set both the write enable bit and the target bit at the same time.

Tonight I will try splitting that into two calls to update the high bit first as well as changing to regmap_update_bits.  Any other ideas welcome.

Sorry if this was too verbose or too much context, I'm new to this kind of work.

|


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Peter Geis]

On Tue, Feb 4, 2020 at 11:14 AM Adam Van Ymeren <adam-M8Nx6PV4agg@public.gmane.org> wrote:
>
>
> On 2020-02-04 10:15 a.m., Peter Geis wrote:
> > I'm interested in this, since I've encountered some oddities with the
> > sdcard on this board.
> > With the recent addition of support for ddr4 tpl init in u-boot I
> > started playing with it again.
> > I couldn't get the sdcard to detect leaving tpl into spl, causing a
> > boot failure.
> > The exact same image works when flashed to the emmc though.
>
> Awesome I was hoping to get mainline u-boot loading this board as well.
> However I don't know how to setup the sdram-params for the dd4 on this
> board.  Do you have the appropriate config?  Would be great not to
> require the vendor's blob for booting.
>
> >
> > Once we are in the kernel the sdcard detects fine.
> >
> > I noticed u-boot doesn't have a grf-gpio driver, so the 3.3v/1.8v
> > regulator is unavailable.
> >
> > root@firefly:/sys/kernel/debug/mmc1# cat ios
> > clock:          150000000 Hz
> > actual clock:   150000000 Hz
> > vdd:            21 (3.3 ~ 3.4 V)
> > bus mode:       2 (push-pull)
> > chip select:    0 (don't care)
> > power mode:     2 (on)
> > bus width:      2 (4 bits)
> > timing spec:    6 (sd uhs SDR104)
> > signal voltage: 1 (1.80 V)
> > driver type:    0 (driver type B)
> >
> > root@firefly:/sys/kernel/debug# cat gpio
> > gpiochip0: GPIOs 0-31, parent: platform/pinctrl, gpio0:
> >  gpio-0   (                    |vcc-host-5v-regulato) out hi
> >  gpio-30  (                    |sdmmc-regulator     ) out lo ACTIVE LOW
> >
> > gpiochip1: GPIOs 32-63, parent: platform/pinctrl, gpio1:
> >  gpio-50  (                    |snps,reset          ) out hi ACTIVE LOW
> >  gpio-58  (                    |vcc-host1-5v-regulat) out hi
> >
> > gpiochip2: GPIOs 64-95, parent: platform/pinctrl, gpio2:
> >
> > gpiochip3: GPIOs 96-127, parent: platform/pinctrl, gpio3:
> >
> > gpiochip5: GPIOs 509-510, parent: platform/rk805-pinctrl, rk805-gpio, can sleep:
> >  gpio-509 (                    |?                   ) out hi ACTIVE LOW
> >  gpio-510 (                    |?                   ) out hi ACTIVE LOW
> >
> > gpiochip4: GPIOs 511-511, parent: platform/ff100000.syscon:grf-gpio,
> > ff100000.syscon:grf-gpio:
> >  gpio-511 (                    |vcc_sdio            ) out hi
>
>
> On my board I tried every combination of GPIO_ACTIVE_HIGH/LOW,
> enable-active-high or not, and state = <18... 0x1 33... 0x0> vs state =
> <18... 0x0 33...0x1> for the vcc_sdio regulator.  None of those allowed
> my kernel to detect the SD Card.  The only reliable method so far seem
> to be setting the gpio of the regulator to some non existent pin, but
> that clearly isn't the corrent answer.  Both gpios = <&gpio0 25
> GPIO_ACTIVE_HIGH> and gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH> allow the
> board to board, both of which are non-existent pins from my reading of
> the datasheet.

First question, which kernel are you running?
Current mainline (5.4.17) works out of the box for the rk3328-roc-cc.

Second question, do you have the libre board or the team firefly board?

Third question, what is the current state of the grf-gpio pin?
Also, what is the state of the regmap for register 428 at
/sys/kernel/debug/regmap/dummy-syscon@ff100000/registers

Also, it likely works because those GPIOs don't exist, as such it is
leaving the grf registers as is from u-boot.

>
> I'm beginning to suspect that it may be a bug in the gpio-syscon driver,
> or that the actual circuit on the board just doesn't work as the vendor
> intended.
>
> In my dmesg I see
>
> [    0.406830] gpio-syscon ff100000.syscon:grf-gpio: can't read the data
> register offset!
>
> which is awfully suspicious.  But this doesn't appear to be a fatal
> error for the driver, logging _regmap_write calls shows that it appears
> to be updating the correct register (0x428)

I get the same error, it doesn't appear to affect the end behavior.

>
>
> From gpio-syscon.c:134
>
> |
>
> static void rockchip_gpio_set(struct gpio_chip *chip, unsigned int offset,
>                               int val)
> {
>         struct syscon_gpio_priv *priv = gpiochip_get_data(chip);
>         unsigned int offs;
>         u8 bit;
>         u32 data;
>         int ret;
>
>         offs = priv->dreg_offset + priv->data->dat_bit_offset + offset;
>         bit = offs % SYSCON_REG_BITS;
>         data = (val ? BIT(bit) : 0) | BIT(bit + 16);
>         ret = regmap_write(priv->syscon,
>                            (offs / SYSCON_REG_BITS) * SYSCON_REG_SIZE,
>                            data);
>         if (ret < 0)
>                 dev_err(chip->parent, "gpio write failed ret(%d)\n", ret);
> }
>
> Calling regmap_write seems wrong, as we end up setting all bits in the register, so this should probably be regmap_update_bits.  The top 16-bits are write-enable for the lower 16-bits, but I can't find documentation if it works to set both the write enable bit and the target bit at the same time.

data = (val ? BIT(bit) : 0) | BIT(bit + 16); handles setting both the
bit and the write bit.

>
> Tonight I will try splitting that into two calls to update the high bit first as well as changing to regmap_update_bits.  Any other ideas welcome.
>
> Sorry if this was too verbose or too much context, I'm new to this kind of work.

I hate to say it, but you probably have something else going on here.
From my ouya porting experience, sdmmc can be very touchy in odd configurations.
I would try reducing the clock rate and trying again, also you can
limit the timing spec mode as well.

Could you send the data from the following sources?
/sys/kernel/debug/mmc1/ios
/sys/kernel/debug/gpio

Also, try reseating the sdcard.
I submitted a patch in October which fixes the sdcard on boot.
Recently gpio functionality on the rk3328 was fixed which allowed
vcc_sd to shut down during boot.
Reseating the card would trigger card detection, which powers the
regulator back up and the card enumerates.
Check that regulator-boot-on; is under the vcc_sd: sdmmc-regulator.

>
> |
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

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

[Peter Geis]

On Tue, Feb 4, 2020 at 11:14 AM Adam Van Ymeren <adam@vany.ca> wrote:
>
>
> On 2020-02-04 10:15 a.m., Peter Geis wrote:
> > I'm interested in this, since I've encountered some oddities with the
> > sdcard on this board.
> > With the recent addition of support for ddr4 tpl init in u-boot I
> > started playing with it again.
> > I couldn't get the sdcard to detect leaving tpl into spl, causing a
> > boot failure.
> > The exact same image works when flashed to the emmc though.
>
> Awesome I was hoping to get mainline u-boot loading this board as well.
> However I don't know how to setup the sdram-params for the dd4 on this
> board.  Do you have the appropriate config?  Would be great not to
> require the vendor's blob for booting.
>
> >
> > Once we are in the kernel the sdcard detects fine.
> >
> > I noticed u-boot doesn't have a grf-gpio driver, so the 3.3v/1.8v
> > regulator is unavailable.
> >
> > root@firefly:/sys/kernel/debug/mmc1# cat ios
> > clock:          150000000 Hz
> > actual clock:   150000000 Hz
> > vdd:            21 (3.3 ~ 3.4 V)
> > bus mode:       2 (push-pull)
> > chip select:    0 (don't care)
> > power mode:     2 (on)
> > bus width:      2 (4 bits)
> > timing spec:    6 (sd uhs SDR104)
> > signal voltage: 1 (1.80 V)
> > driver type:    0 (driver type B)
> >
> > root@firefly:/sys/kernel/debug# cat gpio
> > gpiochip0: GPIOs 0-31, parent: platform/pinctrl, gpio0:
> >  gpio-0   (                    |vcc-host-5v-regulato) out hi
> >  gpio-30  (                    |sdmmc-regulator     ) out lo ACTIVE LOW
> >
> > gpiochip1: GPIOs 32-63, parent: platform/pinctrl, gpio1:
> >  gpio-50  (                    |snps,reset          ) out hi ACTIVE LOW
> >  gpio-58  (                    |vcc-host1-5v-regulat) out hi
> >
> > gpiochip2: GPIOs 64-95, parent: platform/pinctrl, gpio2:
> >
> > gpiochip3: GPIOs 96-127, parent: platform/pinctrl, gpio3:
> >
> > gpiochip5: GPIOs 509-510, parent: platform/rk805-pinctrl, rk805-gpio, can sleep:
> >  gpio-509 (                    |?                   ) out hi ACTIVE LOW
> >  gpio-510 (                    |?                   ) out hi ACTIVE LOW
> >
> > gpiochip4: GPIOs 511-511, parent: platform/ff100000.syscon:grf-gpio,
> > ff100000.syscon:grf-gpio:
> >  gpio-511 (                    |vcc_sdio            ) out hi
>
>
> On my board I tried every combination of GPIO_ACTIVE_HIGH/LOW,
> enable-active-high or not, and state = <18... 0x1 33... 0x0> vs state =
> <18... 0x0 33...0x1> for the vcc_sdio regulator.  None of those allowed
> my kernel to detect the SD Card.  The only reliable method so far seem
> to be setting the gpio of the regulator to some non existent pin, but
> that clearly isn't the corrent answer.  Both gpios = <&gpio0 25
> GPIO_ACTIVE_HIGH> and gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH> allow the
> board to board, both of which are non-existent pins from my reading of
> the datasheet.

First question, which kernel are you running?
Current mainline (5.4.17) works out of the box for the rk3328-roc-cc.

Second question, do you have the libre board or the team firefly board?

Third question, what is the current state of the grf-gpio pin?
Also, what is the state of the regmap for register 428 at
/sys/kernel/debug/regmap/dummy-syscon@ff100000/registers

Also, it likely works because those GPIOs don't exist, as such it is
leaving the grf registers as is from u-boot.

>
> I'm beginning to suspect that it may be a bug in the gpio-syscon driver,
> or that the actual circuit on the board just doesn't work as the vendor
> intended.
>
> In my dmesg I see
>
> [    0.406830] gpio-syscon ff100000.syscon:grf-gpio: can't read the data
> register offset!
>
> which is awfully suspicious.  But this doesn't appear to be a fatal
> error for the driver, logging _regmap_write calls shows that it appears
> to be updating the correct register (0x428)

I get the same error, it doesn't appear to affect the end behavior.

>
>
> From gpio-syscon.c:134
>
> |
>
> static void rockchip_gpio_set(struct gpio_chip *chip, unsigned int offset,
>                               int val)
> {
>         struct syscon_gpio_priv *priv = gpiochip_get_data(chip);
>         unsigned int offs;
>         u8 bit;
>         u32 data;
>         int ret;
>
>         offs = priv->dreg_offset + priv->data->dat_bit_offset + offset;
>         bit = offs % SYSCON_REG_BITS;
>         data = (val ? BIT(bit) : 0) | BIT(bit + 16);
>         ret = regmap_write(priv->syscon,
>                            (offs / SYSCON_REG_BITS) * SYSCON_REG_SIZE,
>                            data);
>         if (ret < 0)
>                 dev_err(chip->parent, "gpio write failed ret(%d)\n", ret);
> }
>
> Calling regmap_write seems wrong, as we end up setting all bits in the register, so this should probably be regmap_update_bits.  The top 16-bits are write-enable for the lower 16-bits, but I can't find documentation if it works to set both the write enable bit and the target bit at the same time.

data = (val ? BIT(bit) : 0) | BIT(bit + 16); handles setting both the
bit and the write bit.

>
> Tonight I will try splitting that into two calls to update the high bit first as well as changing to regmap_update_bits.  Any other ideas welcome.
>
> Sorry if this was too verbose or too much context, I'm new to this kind of work.

I hate to say it, but you probably have something else going on here.
From my ouya porting experience, sdmmc can be very touchy in odd configurations.
I would try reducing the clock rate and trying again, also you can
limit the timing spec mode as well.

Could you send the data from the following sources?
/sys/kernel/debug/mmc1/ios
/sys/kernel/debug/gpio

Also, try reseating the sdcard.
I submitted a patch in October which fixes the sdcard on boot.
Recently gpio functionality on the rk3328 was fixed which allowed
vcc_sd to shut down during boot.
Reseating the card would trigger card detection, which powers the
regulator back up and the card enumerates.
Check that regulator-boot-on; is under the vcc_sd: sdmmc-regulator.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Adam Van Ymeren]

Thanks for the ideas Peter!

On 2020-02-04 12:25 p.m., Peter Geis wrote:
> On Tue, Feb 4, 2020 at 11:14 AM Adam Van Ymeren <adam@vany.ca> wrote:
>>
>> On 2020-02-04 10:15 a.m., Peter Geis wrote:
>>> I'm interested in this, since I've encountered some oddities with the
>>> sdcard on this board.
>>> With the recent addition of support for ddr4 tpl init in u-boot I
>>> started playing with it again.
>>> I couldn't get the sdcard to detect leaving tpl into spl, causing a
>>> boot failure.
>>> The exact same image works when flashed to the emmc though.
>> Awesome I was hoping to get mainline u-boot loading this board as well.
>> However I don't know how to setup the sdram-params for the dd4 on this
>> board.  Do you have the appropriate config?  Would be great not to
>> require the vendor's blob for booting.
>>
>>> Once we are in the kernel the sdcard detects fine.
>>>
>>> I noticed u-boot doesn't have a grf-gpio driver, so the 3.3v/1.8v
>>> regulator is unavailable.
>>>
>>> root@firefly:/sys/kernel/debug/mmc1# cat ios
>>> clock:          150000000 Hz
>>> actual clock:   150000000 Hz
>>> vdd:            21 (3.3 ~ 3.4 V)
>>> bus mode:       2 (push-pull)
>>> chip select:    0 (don't care)
>>> power mode:     2 (on)
>>> bus width:      2 (4 bits)
>>> timing spec:    6 (sd uhs SDR104)
>>> signal voltage: 1 (1.80 V)
>>> driver type:    0 (driver type B)
>>>
>>> root@firefly:/sys/kernel/debug# cat gpio
>>> gpiochip0: GPIOs 0-31, parent: platform/pinctrl, gpio0:
>>>  gpio-0   (                    |vcc-host-5v-regulato) out hi
>>>  gpio-30  (                    |sdmmc-regulator     ) out lo ACTIVE LOW
>>>
>>> gpiochip1: GPIOs 32-63, parent: platform/pinctrl, gpio1:
>>>  gpio-50  (                    |snps,reset          ) out hi ACTIVE LOW
>>>  gpio-58  (                    |vcc-host1-5v-regulat) out hi
>>>
>>> gpiochip2: GPIOs 64-95, parent: platform/pinctrl, gpio2:
>>>
>>> gpiochip3: GPIOs 96-127, parent: platform/pinctrl, gpio3:
>>>
>>> gpiochip5: GPIOs 509-510, parent: platform/rk805-pinctrl, rk805-gpio, can sleep:
>>>  gpio-509 (                    |?                   ) out hi ACTIVE LOW
>>>  gpio-510 (                    |?                   ) out hi ACTIVE LOW
>>>
>>> gpiochip4: GPIOs 511-511, parent: platform/ff100000.syscon:grf-gpio,
>>> ff100000.syscon:grf-gpio:
>>>  gpio-511 (                    |vcc_sdio            ) out hi
>>
>> On my board I tried every combination of GPIO_ACTIVE_HIGH/LOW,
>> enable-active-high or not, and state = <18... 0x1 33... 0x0> vs state =
>> <18... 0x0 33...0x1> for the vcc_sdio regulator.  None of those allowed
>> my kernel to detect the SD Card.  The only reliable method so far seem
>> to be setting the gpio of the regulator to some non existent pin, but
>> that clearly isn't the corrent answer.  Both gpios = <&gpio0 25
>> GPIO_ACTIVE_HIGH> and gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH> allow the
>> board to board, both of which are non-existent pins from my reading of
>> the datasheet.
> First question, which kernel are you running?
> Current mainline (5.4.17) works out of the box for the rk3328-roc-cc.

Not from my experience.  I'm trying 5.5, but I also tried a fresh build
ot 5.4.17 and neither will load from the sdcard in their default
configuration.  If you have this working can you share your kernel config?

>
> Second question, do you have the libre board or the team firefly board?

The libre.computer board.

>
> Third question, what is the current state of the grf-gpio pin?
> Also, what is the state of the regmap for register 428 at
> /sys/kernel/debug/regmap/dummy-syscon@ff100000/registers
>
> Also, it likely works because those GPIOs don't exist, as such it is
> leaving the grf registers as is from u-boot.

Makes sense.  If I remove vcc_sdio from the device tree, and remove the
vqmmc entry from the sdmmc node, then the kernel continues to boot.  In
that case I have

# cat /sys/kernel/debug/regmap/dummy-syscon\@ff100000/registers | grep 428

428: 0000f800

# cat /sys/kernel/debug/mmc1/ios 
clock:        0 Hz
vdd:        0 (invalid)
bus mode:    2 (push-pull)
chip select:    0 (don't care)
power mode:    0 (off)
bus width:    0 (1 bits)
timing spec:    0 (legacy)
signal voltage:    0 (3.30 V)
driver type:    0 (driver type B)

# cat /sys/kernel/debug/gpio 
gpiochip0: GPIOs 0-31, parent: platform/pinctrl, gpio0:
 gpio-30  (                    |sdmmc-regulator     ) out lo ACTIVE LOW
 
gpiochip1: GPIOs 32-63, parent: platform/pinctrl, gpio1:
 gpio-58  (                    |vcc-host1-5v-regulat) out hi 
 
gpiochip2: GPIOs 64-95, parent: platform/pinctrl, gpio2:
 
gpiochip3: GPIOs 96-127, parent: platform/pinctrl, gpio3:
 
gpiochip4: GPIOs 511-511, parent: platform/ff100000.syscon:grf-gpio,
ff100000.syscon:grf-gpio:


I notice that I don't have the entry for vcc-host-5v-regulator.  In fact
vcc-host-5v-regulator doesn't appear in the device tree anywhere that I
can find.  It only appears in the rock64 device tree.  What device
tree/kernel version are you using?

$ grep -R vcc-host-5v-regulat linux-5.5/
linux-5.5/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts:   
vcc_host_5v: vcc-host-5v-regulator {

$ grep -R vcc-host-5v-regulat linux-5.4.17/
linux-5.4.17/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts:   
vcc_host_5v: vcc-host-5v-regulator {

>>
>> Calling regmap_write seems wrong, as we end up setting all bits in the register, so this should probably be regmap_update_bits.  The top 16-bits are write-enable for the lower 16-bits, but I can't find documentation if it works to set both the write enable bit and the target bit at the same time.
> data = (val ? BIT(bit) : 0) | BIT(bit + 16); handles setting both the
> bit and the write bit.
Right I saw that, I was more wondering if it's legal to set both in the
same operation, or if the chip requires you to set the write bit, and
then the data bit in a subsequent write.
>> Tonight I will try splitting that into two calls to update the high bit first as well as changing to regmap_update_bits.  Any other ideas welcome.
>>
>> Sorry if this was too verbose or too much context, I'm new to this kind of work.
> I hate to say it, but you probably have something else going on here.
> From my ouya porting experience, sdmmc can be very touchy in odd configurations.
> I would try reducing the clock rate and trying again, also you can
> limit the timing spec mode as well.

Any advice on how to reduce the clock rate/timing spec mode?  I also
just found a PDF showing the position of the components on the board, so
I should be able to find a test point to see if the regulator is
producing 1.8V vs 3.3V as its supposed to.

>
> Could you send the data from the following sources?
> /sys/kernel/debug/mmc1/ios
> /sys/kernel/debug/gpio


Pasted above.


> Also, try reseating the sdcard.
> I submitted a patch in October which fixes the sdcard on boot.
> Recently gpio functionality on the rk3328 was fixed which allowed
> vcc_sd to shut down during boot.
> Reseating the card would trigger card detection, which powers the
> regulator back up and the card enumerates.
> Check that regulator-boot-on; is under the vcc_sd: sdmmc-regulator.

I've re-seated the sdcard a bunch. If I do nothing but reboot the board
and toggle between the stock device tree and one with vcc_sdio/vqmmc
removed I can reliably boot vs not-boot the board.  regulator-boot-on is
there for vcc_sd.


I really appreciate the help!


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Robin Murphy]

On 05/02/2020 4:14 pm, Adam Van Ymeren wrote:
[...]
>>> Calling regmap_write seems wrong, as we end up setting all bits in the register, so this should probably be regmap_update_bits.  The top 16-bits are write-enable for the lower 16-bits, but I can't find documentation if it works to set both the write enable bit and the target bit at the same time.
>> data = (val ? BIT(bit) : 0) | BIT(bit + 16); handles setting both the
>> bit and the write bit.
> Right I saw that, I was more wondering if it's legal to set both in the
> same operation, or if the chip requires you to set the write bit, and
> then the data bit in a subsequent write.

The point of this particular hardware idiom is that the mask indicates 
which data bits to update, and both mask and data are part of a single 
write, thus there is no need for a non-atomic read-modify-write 
sequence. For example:

- register value is 0x00000000
- write 0xffffffff (mask all set, data all 1s)
- register value is now 0x0000ffff
- write 0x00090000 (mask bits 0 and 3 set, corresponding data bit values 0)
- register value is now 0x0000fff6


FWIW I've confirmed on my box that there doesn't seem to be any problem 
with the grf-gpio driver itself - setting the value to 1 or 0 from 
userspace shows up as the enable pin on the audio line driver (per the 
RK3328 reference design) going high and low respectively.

One thing I did notice, though, is that GPIO_MUTE seems to have some 
inherent coupling to the analog codec, as the value automatically goes 
high when starting to play audio, and low again when stopping (but can 
still be manually toggled in between). Thus unless there's some secret 
to disabling that behaviour then it might not be safe to enable analog 
audio on these ROC-CC boards for fear of messing up peoples' SD cards.

Robin.

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

[Robin Murphy]

On 05/02/2020 4:14 pm, Adam Van Ymeren wrote:
[...]
>>> Calling regmap_write seems wrong, as we end up setting all bits in the register, so this should probably be regmap_update_bits.  The top 16-bits are write-enable for the lower 16-bits, but I can't find documentation if it works to set both the write enable bit and the target bit at the same time.
>> data = (val ? BIT(bit) : 0) | BIT(bit + 16); handles setting both the
>> bit and the write bit.
> Right I saw that, I was more wondering if it's legal to set both in the
> same operation, or if the chip requires you to set the write bit, and
> then the data bit in a subsequent write.

The point of this particular hardware idiom is that the mask indicates 
which data bits to update, and both mask and data are part of a single 
write, thus there is no need for a non-atomic read-modify-write 
sequence. For example:

- register value is 0x00000000
- write 0xffffffff (mask all set, data all 1s)
- register value is now 0x0000ffff
- write 0x00090000 (mask bits 0 and 3 set, corresponding data bit values 0)
- register value is now 0x0000fff6


FWIW I've confirmed on my box that there doesn't seem to be any problem 
with the grf-gpio driver itself - setting the value to 1 or 0 from 
userspace shows up as the enable pin on the audio line driver (per the 
RK3328 reference design) going high and low respectively.

One thing I did notice, though, is that GPIO_MUTE seems to have some 
inherent coupling to the analog codec, as the value automatically goes 
high when starting to play audio, and low again when stopping (but can 
still be manually toggled in between). Thus unless there's some secret 
to disabling that behaviour then it might not be safe to enable analog 
audio on these ROC-CC boards for fear of messing up peoples' SD cards.

Robin.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Peter Geis]

> > First question, which kernel are you running?
> > Current mainline (5.4.17) works out of the box for the rk3328-roc-cc.
>
> Not from my experience.  I'm trying 5.5, but I also tried a fresh build
> ot 5.4.17 and neither will load from the sdcard in their default
> configuration.  If you have this working can you share your kernel config?

Considering all of the components to boot off emmc (which you are
clearly doing since you boot at all) are the same as the ones required
for sdmmc I doubt it's a configuration issue.
But to answer your question, I used the defconfig, stripped all of the
non rockchip components out, and made the base drivers builtin.

>
> >
> > Second question, do you have the libre board or the team firefly board?
>
> The libre.computer board.
>
> >
> > Third question, what is the current state of the grf-gpio pin?
> > Also, what is the state of the regmap for register 428 at
> > /sys/kernel/debug/regmap/dummy-syscon@ff100000/registers
> >
> > Also, it likely works because those GPIOs don't exist, as such it is
> > leaving the grf registers as is from u-boot.
>
> Makes sense.  If I remove vcc_sdio from the device tree, and remove the
> vqmmc entry from the sdmmc node, then the kernel continues to boot.  In
> that case I have
>
> # cat /sys/kernel/debug/regmap/dummy-syscon\@ff100000/registers | grep 428
>
> 428: 0000f800

As it should be, this should mean your mute pin is off (default state)
and the vqmmc voltage should be 3.3v.

>
> # cat /sys/kernel/debug/mmc1/ios
> clock:        0 Hz
> vdd:        0 (invalid)
> bus mode:    2 (push-pull)
> chip select:    0 (don't care)
> power mode:    0 (off)
> bus width:    0 (1 bits)
> timing spec:    0 (legacy)
> signal voltage:    0 (3.30 V)
> driver type:    0 (driver type B)

It's not detecting anything at all.
You say you booted off this card?

Could you run a `dmesg | grep mmc` and send all the results?

>
> # cat /sys/kernel/debug/gpio
> gpiochip0: GPIOs 0-31, parent: platform/pinctrl, gpio0:
>  gpio-30  (                    |sdmmc-regulator     ) out lo ACTIVE LOW
>
> gpiochip1: GPIOs 32-63, parent: platform/pinctrl, gpio1:
>  gpio-58  (                    |vcc-host1-5v-regulat) out hi
>
> gpiochip2: GPIOs 64-95, parent: platform/pinctrl, gpio2:
>
> gpiochip3: GPIOs 96-127, parent: platform/pinctrl, gpio3:
>
> gpiochip4: GPIOs 511-511, parent: platform/ff100000.syscon:grf-gpio,
> ff100000.syscon:grf-gpio:
>
>
> I notice that I don't have the entry for vcc-host-5v-regulator.  In fact
> vcc-host-5v-regulator doesn't appear in the device tree anywhere that I
> can find.  It only appears in the rock64 device tree.  What device
> tree/kernel version are you using?

I've got usb 2 and 3 fully working, that regulator is part of the usb subsystem.

>
> $ grep -R vcc-host-5v-regulat linux-5.5/
> linux-5.5/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts:
> vcc_host_5v: vcc-host-5v-regulator {
>
> $ grep -R vcc-host-5v-regulat linux-5.4.17/
> linux-5.4.17/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts:
> vcc_host_5v: vcc-host-5v-regulator {
>
> >>
> >> Calling regmap_write seems wrong, as we end up setting all bits in the register, so this should probably be regmap_update_bits.  The top 16-bits are write-enable for the lower 16-bits, but I can't find documentation if it works to set both the write enable bit and the target bit at the same time.
> > data = (val ? BIT(bit) : 0) | BIT(bit + 16); handles setting both the
> > bit and the write bit.
> Right I saw that, I was more wondering if it's legal to set both in the
> same operation, or if the chip requires you to set the write bit, and
> then the data bit in a subsequent write.
> >> Tonight I will try splitting that into two calls to update the high bit first as well as changing to regmap_update_bits.  Any other ideas welcome.
> >>
> >> Sorry if this was too verbose or too much context, I'm new to this kind of work.
> > I hate to say it, but you probably have something else going on here.
> > From my ouya porting experience, sdmmc can be very touchy in odd configurations.
> > I would try reducing the clock rate and trying again, also you can
> > limit the timing spec mode as well.
>
> Any advice on how to reduce the clock rate/timing spec mode?  I also
> just found a PDF showing the position of the components on the board, so
> I should be able to find a test point to see if the regulator is
> producing 1.8V vs 3.3V as its supposed to.

Documentation/devicetree/bindings/mmc/mmc-controller.yaml
max-frequency for frequency cap.
sd-uhs-sdr12 through sd-uhs-ddr50 set sd card modes.
You can also try bus-width = <1>;

>
> >
> > Could you send the data from the following sources?
> > /sys/kernel/debug/mmc1/ios
> > /sys/kernel/debug/gpio
>
>
> Pasted above.
>
>
> > Also, try reseating the sdcard.
> > I submitted a patch in October which fixes the sdcard on boot.
> > Recently gpio functionality on the rk3328 was fixed which allowed
> > vcc_sd to shut down during boot.
> > Reseating the card would trigger card detection, which powers the
> > regulator back up and the card enumerates.
> > Check that regulator-boot-on; is under the vcc_sd: sdmmc-regulator.
>
> I've re-seated the sdcard a bunch. If I do nothing but reboot the board
> and toggle between the stock device tree and one with vcc_sdio/vqmmc
> removed I can reliably boot vs not-boot the board.  regulator-boot-on is
> there for vcc_sd.
>
>
> I really appreciate the help!
>

I hate to ask the dumb questions, but I have a few just for clarity.
With no emmc attached, does your board boot off the sdcard?
Are you sure the sdcard is good?

> One thing I did notice, though, is that GPIO_MUTE seems to have some
> inherent coupling to the analog codec, as the value automatically goes
> high when starting to play audio, and low again when stopping (but can
> still be manually toggled in between). Thus unless there's some secret
> to disabling that behaviour then it might not be safe to enable analog
> audio on these ROC-CC boards for fear of messing up peoples' SD cards.

Robin,
Do you know if that is the SOC doing that or the drivers?

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

[Peter Geis]

> > First question, which kernel are you running?
> > Current mainline (5.4.17) works out of the box for the rk3328-roc-cc.
>
> Not from my experience.  I'm trying 5.5, but I also tried a fresh build
> ot 5.4.17 and neither will load from the sdcard in their default
> configuration.  If you have this working can you share your kernel config?

Considering all of the components to boot off emmc (which you are
clearly doing since you boot at all) are the same as the ones required
for sdmmc I doubt it's a configuration issue.
But to answer your question, I used the defconfig, stripped all of the
non rockchip components out, and made the base drivers builtin.

>
> >
> > Second question, do you have the libre board or the team firefly board?
>
> The libre.computer board.
>
> >
> > Third question, what is the current state of the grf-gpio pin?
> > Also, what is the state of the regmap for register 428 at
> > /sys/kernel/debug/regmap/dummy-syscon@ff100000/registers
> >
> > Also, it likely works because those GPIOs don't exist, as such it is
> > leaving the grf registers as is from u-boot.
>
> Makes sense.  If I remove vcc_sdio from the device tree, and remove the
> vqmmc entry from the sdmmc node, then the kernel continues to boot.  In
> that case I have
>
> # cat /sys/kernel/debug/regmap/dummy-syscon\@ff100000/registers | grep 428
>
> 428: 0000f800

As it should be, this should mean your mute pin is off (default state)
and the vqmmc voltage should be 3.3v.

>
> # cat /sys/kernel/debug/mmc1/ios
> clock:        0 Hz
> vdd:        0 (invalid)
> bus mode:    2 (push-pull)
> chip select:    0 (don't care)
> power mode:    0 (off)
> bus width:    0 (1 bits)
> timing spec:    0 (legacy)
> signal voltage:    0 (3.30 V)
> driver type:    0 (driver type B)

It's not detecting anything at all.
You say you booted off this card?

Could you run a `dmesg | grep mmc` and send all the results?

>
> # cat /sys/kernel/debug/gpio
> gpiochip0: GPIOs 0-31, parent: platform/pinctrl, gpio0:
>  gpio-30  (                    |sdmmc-regulator     ) out lo ACTIVE LOW
>
> gpiochip1: GPIOs 32-63, parent: platform/pinctrl, gpio1:
>  gpio-58  (                    |vcc-host1-5v-regulat) out hi
>
> gpiochip2: GPIOs 64-95, parent: platform/pinctrl, gpio2:
>
> gpiochip3: GPIOs 96-127, parent: platform/pinctrl, gpio3:
>
> gpiochip4: GPIOs 511-511, parent: platform/ff100000.syscon:grf-gpio,
> ff100000.syscon:grf-gpio:
>
>
> I notice that I don't have the entry for vcc-host-5v-regulator.  In fact
> vcc-host-5v-regulator doesn't appear in the device tree anywhere that I
> can find.  It only appears in the rock64 device tree.  What device
> tree/kernel version are you using?

I've got usb 2 and 3 fully working, that regulator is part of the usb subsystem.

>
> $ grep -R vcc-host-5v-regulat linux-5.5/
> linux-5.5/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts:
> vcc_host_5v: vcc-host-5v-regulator {
>
> $ grep -R vcc-host-5v-regulat linux-5.4.17/
> linux-5.4.17/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts:
> vcc_host_5v: vcc-host-5v-regulator {
>
> >>
> >> Calling regmap_write seems wrong, as we end up setting all bits in the register, so this should probably be regmap_update_bits.  The top 16-bits are write-enable for the lower 16-bits, but I can't find documentation if it works to set both the write enable bit and the target bit at the same time.
> > data = (val ? BIT(bit) : 0) | BIT(bit + 16); handles setting both the
> > bit and the write bit.
> Right I saw that, I was more wondering if it's legal to set both in the
> same operation, or if the chip requires you to set the write bit, and
> then the data bit in a subsequent write.
> >> Tonight I will try splitting that into two calls to update the high bit first as well as changing to regmap_update_bits.  Any other ideas welcome.
> >>
> >> Sorry if this was too verbose or too much context, I'm new to this kind of work.
> > I hate to say it, but you probably have something else going on here.
> > From my ouya porting experience, sdmmc can be very touchy in odd configurations.
> > I would try reducing the clock rate and trying again, also you can
> > limit the timing spec mode as well.
>
> Any advice on how to reduce the clock rate/timing spec mode?  I also
> just found a PDF showing the position of the components on the board, so
> I should be able to find a test point to see if the regulator is
> producing 1.8V vs 3.3V as its supposed to.

Documentation/devicetree/bindings/mmc/mmc-controller.yaml
max-frequency for frequency cap.
sd-uhs-sdr12 through sd-uhs-ddr50 set sd card modes.
You can also try bus-width = <1>;

>
> >
> > Could you send the data from the following sources?
> > /sys/kernel/debug/mmc1/ios
> > /sys/kernel/debug/gpio
>
>
> Pasted above.
>
>
> > Also, try reseating the sdcard.
> > I submitted a patch in October which fixes the sdcard on boot.
> > Recently gpio functionality on the rk3328 was fixed which allowed
> > vcc_sd to shut down during boot.
> > Reseating the card would trigger card detection, which powers the
> > regulator back up and the card enumerates.
> > Check that regulator-boot-on; is under the vcc_sd: sdmmc-regulator.
>
> I've re-seated the sdcard a bunch. If I do nothing but reboot the board
> and toggle between the stock device tree and one with vcc_sdio/vqmmc
> removed I can reliably boot vs not-boot the board.  regulator-boot-on is
> there for vcc_sd.
>
>
> I really appreciate the help!
>

I hate to ask the dumb questions, but I have a few just for clarity.
With no emmc attached, does your board boot off the sdcard?
Are you sure the sdcard is good?

> One thing I did notice, though, is that GPIO_MUTE seems to have some
> inherent coupling to the analog codec, as the value automatically goes
> high when starting to play audio, and low again when stopping (but can
> still be manually toggled in between). Thus unless there's some secret
> to disabling that behaviour then it might not be safe to enable analog
> audio on these ROC-CC boards for fear of messing up peoples' SD cards.

Robin,
Do you know if that is the SOC doing that or the drivers?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Robin Murphy]

On 05/02/2020 6:43 pm, Peter Geis wrote:
[...]
>> One thing I did notice, though, is that GPIO_MUTE seems to have some
>> inherent coupling to the analog codec, as the value automatically goes
>> high when starting to play audio, and low again when stopping (but can
>> still be manually toggled in between). Thus unless there's some secret
>> to disabling that behaviour then it might not be safe to enable analog
>> audio on these ROC-CC boards for fear of messing up peoples' SD cards.
> 
> Robin,
> Do you know if that is the SOC doing that or the drivers?

Ha, once again I hastily jump to a conclusion without fully 
investigating... I'm really not doing too well in this thread :)

You're absolutely right; on closer inspection rk3328_analog_output() in 
the codec driver is poking GRF_SOC_CON10 directly. That should be 
straightforward enough to sort out, phew!

Cheers,
Robin.

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

[Robin Murphy]

On 05/02/2020 6:43 pm, Peter Geis wrote:
[...]
>> One thing I did notice, though, is that GPIO_MUTE seems to have some
>> inherent coupling to the analog codec, as the value automatically goes
>> high when starting to play audio, and low again when stopping (but can
>> still be manually toggled in between). Thus unless there's some secret
>> to disabling that behaviour then it might not be safe to enable analog
>> audio on these ROC-CC boards for fear of messing up peoples' SD cards.
> 
> Robin,
> Do you know if that is the SOC doing that or the drivers?

Ha, once again I hastily jump to a conclusion without fully 
investigating... I'm really not doing too well in this thread :)

You're absolutely right; on closer inspection rk3328_analog_output() in 
the codec driver is poking GRF_SOC_CON10 directly. That should be 
straightforward enough to sort out, phew!

Cheers,
Robin.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Thomas McKahan]

On 2/5/2020 2:02 PM, Robin Murphy wrote:
> On 05/02/2020 6:43 pm, Peter Geis wrote:
> [...]
>>> One thing I did notice, though, is that GPIO_MUTE seems to have some
>>> inherent coupling to the analog codec, as the value automatically goes
>>> high when starting to play audio, and low again when stopping (but can
>>> still be manually toggled in between). Thus unless there's some secret
>>> to disabling that behaviour then it might not be safe to enable analog
>>> audio on these ROC-CC boards for fear of messing up peoples' SD cards.
>>
>> Robin,
>> Do you know if that is the SOC doing that or the drivers?
>
> Ha, once again I hastily jump to a conclusion without fully 
> investigating... I'm really not doing too well in this thread :)
>
> You're absolutely right; on closer inspection rk3328_analog_output() 
> in the codec driver is poking GRF_SOC_CON10 directly. That should be 
> straightforward enough to sort out, phew!
>
> Cheers,
> Robin.
>
I've had random reports of SD problems from people using our mainline 
images with Armbian on RK3328, I recently enabled the audio codec since 
it looked like all the pieces were in place. I'll take a look at the 
GPIO_MUTE patchset I saw just landed.

-Tony

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

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

[Thomas McKahan]

On 2/5/2020 2:02 PM, Robin Murphy wrote:
> On 05/02/2020 6:43 pm, Peter Geis wrote:
> [...]
>>> One thing I did notice, though, is that GPIO_MUTE seems to have some
>>> inherent coupling to the analog codec, as the value automatically goes
>>> high when starting to play audio, and low again when stopping (but can
>>> still be manually toggled in between). Thus unless there's some secret
>>> to disabling that behaviour then it might not be safe to enable analog
>>> audio on these ROC-CC boards for fear of messing up peoples' SD cards.
>>
>> Robin,
>> Do you know if that is the SOC doing that or the drivers?
>
> Ha, once again I hastily jump to a conclusion without fully 
> investigating... I'm really not doing too well in this thread :)
>
> You're absolutely right; on closer inspection rk3328_analog_output() 
> in the codec driver is poking GRF_SOC_CON10 directly. That should be 
> straightforward enough to sort out, phew!
>
> Cheers,
> Robin.
>
I've had random reports of SD problems from people using our mainline 
images with Armbian on RK3328, I recently enabled the audio codec since 
it looked like all the pieces were in place. I'll take a look at the 
GPIO_MUTE patchset I saw just landed.

-Tony

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Adam Van Ymeren]

Got it working. Robin you were right, it just needed enable-active-high;
added to the regulator, updated patch at the end of this message.

I went back over my config with a fine tooth comb and found a few
rockchip drivers I was missing including PINCTRL_RK805 which seems
related but I honestly can't figure out how.  I will try to narrow down
which specific driver was missing.  It was odd because it would find the
mmc host but just fail notice that a card was present.  It seemed to set
the register correctly and identify the mmc host, but failed to notice
any card present.

I haven't yet tested this with a high speed card yet to verify 1.8v
signaling works but I'll find one and give it a shot.

Thanks a ton to both of your for the help


On 2020-02-05 1:43 p.m., Peter Geis wrote:
>>> First question, which kernel are you running?
>>> Current mainline (5.4.17) works out of the box for the rk3328-roc-cc.
>> Not from my experience.  I'm trying 5.5, but I also tried a fresh build
>> ot 5.4.17 and neither will load from the sdcard in their default
>> configuration.  If you have this working can you share your kernel config?
> Considering all of the components to boot off emmc (which you are
> clearly doing since you boot at all) are the same as the ones required
> for sdmmc I doubt it's a configuration issue.
> But to answer your question, I used the defconfig, stripped all of the
> non rockchip components out, and made the base drivers builtin.

So I wasn't booting off of emmc.  I was booting from the sdcard, it
would work so long as I prevented the kernel from trying to initialize
the vcc_sdio regulator (by removing it or changing the gpio pin),
presumably as u-boot left it in a reasonable state.

> Makes sense. If I remove vcc_sdio from the device tree, and remove the
>> vqmmc entry from the sdmmc node, then the kernel continues to boot.  In
>> that case I have
>>
>> # cat /sys/kernel/debug/regmap/dummy-syscon\@ff100000/registers | grep 428
>>
>> 428: 0000f800
> As it should be, this should mean your mute pin is off (default state)
> and the vqmmc voltage should be 3.3v.

Gotcha.  I also managed to verify this works as expected on my board
with a multimeter and toggling the register from the u-boot shell.

>
>> # cat /sys/kernel/debug/mmc1/ios
>> clock:        0 Hz
>> vdd:        0 (invalid)
>> bus mode:    2 (push-pull)
>> chip select:    0 (don't care)
>> power mode:    0 (off)
>> bus width:    0 (1 bits)
>> timing spec:    0 (legacy)
>> signal voltage:    0 (3.30 V)
>> driver type:    0 (driver type B)
> It's not detecting anything at all.
> You say you booted off this card?
So this is booting when I disabled vcc_sdio and just left it in the
state that u-boot left it in, which is probably where the nonsensical
output comes from.
>
> Could you run a `dmesg | grep mmc` and send all the results?

Here's a slightly scrubbed log of one of my failed boots.  I left in my
traces of register writes to 428 and gpio-regulator state changes.

[    0.000000] Kernel command line: earlycon=uart8250,mmio32,0xff130000
console=ttyS2,1500000 rw root=/dev/mmcblk0p5 init=/sbin/init
kgdboc=ttyS2,1500000 dynamic_debug.verbose=1 loglevel=7 dyndbg="module
dw_mmc +p ; module dw_mmc_rockchip +p ; module mmc_core +p"
<snip>
[    0.793750] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit
address mode.
[    0.794402] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller.
[    0.798582] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a
[    0.801194] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq
29,32 bit host data width,256 deep fifo
[    0.815437] dwmmc_rockchip ff520000.dwmmc: IDMAC supports 32-bit
address mode.
[    0.820273] dwmmc_rockchip ff520000.dwmmc: Version ID is 270a
[    0.822904] dwmmc_rockchip ff520000.dwmmc: DW MMC controller at irq
30,32 bit host data width,256 deep fifo
[    0.825527] mmc_host mmc0: card is non-removable.
[    0.838770] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req
400000Hz, actual 400000HZ div = 0)
[    0.888886] ADAMVY Regmap write 428 <= 2f802
[    0.904218] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit
address mode.
[    0.904870] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller.
[    0.909055] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a
[    0.911637] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq
29,32 bit host data width,256 deep fifo
[    0.913954] ADAMVY Setting gpio regulator to value 3300000 state 0
[    0.914503] ADAMVY Regmap write 428 <= 2f800
[    0.927612] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req
400000Hz, actual 400000HZ div = 0)
[    0.950160] VFS: Cannot open root device "mmcblk0p5" or
unknown-block(0,0): error -6



Finally here's an updated patch for the device tree with Robin's
original suggestion.


Index: 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
+++ linux-5.5/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -45,6 +45,7 @@
 	vcc_sdio: sdmmcio-regulator {
 		compatible = "regulator-gpio";
 		gpios = <&grf_gpio 0 GPIO_ACTIVE_HIGH>;
+                enable-active-high;
 		states = <1800000 0x1
 			  3300000 0x0>;
 		regulator-name = "vcc_sdio";



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

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

[Adam Van Ymeren]

Got it working. Robin you were right, it just needed enable-active-high;
added to the regulator, updated patch at the end of this message.

I went back over my config with a fine tooth comb and found a few
rockchip drivers I was missing including PINCTRL_RK805 which seems
related but I honestly can't figure out how.  I will try to narrow down
which specific driver was missing.  It was odd because it would find the
mmc host but just fail notice that a card was present.  It seemed to set
the register correctly and identify the mmc host, but failed to notice
any card present.

I haven't yet tested this with a high speed card yet to verify 1.8v
signaling works but I'll find one and give it a shot.

Thanks a ton to both of your for the help


On 2020-02-05 1:43 p.m., Peter Geis wrote:
>>> First question, which kernel are you running?
>>> Current mainline (5.4.17) works out of the box for the rk3328-roc-cc.
>> Not from my experience.  I'm trying 5.5, but I also tried a fresh build
>> ot 5.4.17 and neither will load from the sdcard in their default
>> configuration.  If you have this working can you share your kernel config?
> Considering all of the components to boot off emmc (which you are
> clearly doing since you boot at all) are the same as the ones required
> for sdmmc I doubt it's a configuration issue.
> But to answer your question, I used the defconfig, stripped all of the
> non rockchip components out, and made the base drivers builtin.

So I wasn't booting off of emmc.  I was booting from the sdcard, it
would work so long as I prevented the kernel from trying to initialize
the vcc_sdio regulator (by removing it or changing the gpio pin),
presumably as u-boot left it in a reasonable state.

> Makes sense. If I remove vcc_sdio from the device tree, and remove the
>> vqmmc entry from the sdmmc node, then the kernel continues to boot.  In
>> that case I have
>>
>> # cat /sys/kernel/debug/regmap/dummy-syscon\@ff100000/registers | grep 428
>>
>> 428: 0000f800
> As it should be, this should mean your mute pin is off (default state)
> and the vqmmc voltage should be 3.3v.

Gotcha.  I also managed to verify this works as expected on my board
with a multimeter and toggling the register from the u-boot shell.

>
>> # cat /sys/kernel/debug/mmc1/ios
>> clock:        0 Hz
>> vdd:        0 (invalid)
>> bus mode:    2 (push-pull)
>> chip select:    0 (don't care)
>> power mode:    0 (off)
>> bus width:    0 (1 bits)
>> timing spec:    0 (legacy)
>> signal voltage:    0 (3.30 V)
>> driver type:    0 (driver type B)
> It's not detecting anything at all.
> You say you booted off this card?
So this is booting when I disabled vcc_sdio and just left it in the
state that u-boot left it in, which is probably where the nonsensical
output comes from.
>
> Could you run a `dmesg | grep mmc` and send all the results?

Here's a slightly scrubbed log of one of my failed boots.  I left in my
traces of register writes to 428 and gpio-regulator state changes.

[    0.000000] Kernel command line: earlycon=uart8250,mmio32,0xff130000
console=ttyS2,1500000 rw root=/dev/mmcblk0p5 init=/sbin/init
kgdboc=ttyS2,1500000 dynamic_debug.verbose=1 loglevel=7 dyndbg="module
dw_mmc +p ; module dw_mmc_rockchip +p ; module mmc_core +p"
<snip>
[    0.793750] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit
address mode.
[    0.794402] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller.
[    0.798582] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a
[    0.801194] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq
29,32 bit host data width,256 deep fifo
[    0.815437] dwmmc_rockchip ff520000.dwmmc: IDMAC supports 32-bit
address mode.
[    0.820273] dwmmc_rockchip ff520000.dwmmc: Version ID is 270a
[    0.822904] dwmmc_rockchip ff520000.dwmmc: DW MMC controller at irq
30,32 bit host data width,256 deep fifo
[    0.825527] mmc_host mmc0: card is non-removable.
[    0.838770] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req
400000Hz, actual 400000HZ div = 0)
[    0.888886] ADAMVY Regmap write 428 <= 2f802
[    0.904218] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit
address mode.
[    0.904870] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller.
[    0.909055] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a
[    0.911637] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq
29,32 bit host data width,256 deep fifo
[    0.913954] ADAMVY Setting gpio regulator to value 3300000 state 0
[    0.914503] ADAMVY Regmap write 428 <= 2f800
[    0.927612] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req
400000Hz, actual 400000HZ div = 0)
[    0.950160] VFS: Cannot open root device "mmcblk0p5" or
unknown-block(0,0): error -6



Finally here's an updated patch for the device tree with Robin's
original suggestion.


Index: 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
+++ linux-5.5/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -45,6 +45,7 @@
 	vcc_sdio: sdmmcio-regulator {
 		compatible = "regulator-gpio";
 		gpios = <&grf_gpio 0 GPIO_ACTIVE_HIGH>;
+                enable-active-high;
 		states = <1800000 0x1
 			  3300000 0x0>;
 		regulator-name = "vcc_sdio";



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Robin Murphy]

On 09/02/2020 1:07 am, Adam Van Ymeren wrote:
> Got it working. Robin you were right, it just needed enable-active-high;
> added to the regulator, updated patch at the end of this message.

Weird... after my initial excitement I went back and looked more closely 
at the binding and gpiolib-of code, only to realise that that property 
is only supposed to apply to specific 'enable' GPIOs (of which there are 
none here since it's always-on), and that the 'state' GPIOs were a 
separate thing and I'd jumped to the wrong conclusion. So now I'm doubly 
surprised that it actually makes a difference :/

> I went back over my config with a fine tooth comb and found a few
> rockchip drivers I was missing including PINCTRL_RK805 which seems
> related but I honestly can't figure out how.  I will try to narrow down
> which specific driver was missing.  It was odd because it would find the
> mmc host but just fail notice that a card was present.  It seemed to set
> the register correctly and identify the mmc host, but failed to notice
> any card present.

PINCTRL_RK805 should only be for the couple of GPIO pins on the PMIC 
itself which IIRC the reference design uses for the ethernet LEDs, so I 
wouldn't expect it to be relevant.

Those symptoms make sense for the voltages being backwards (or just 
stuck at 1.8V) though - when the I/O domain is configured to expect 
3.3V, 1.8V is too low to register as a logic high, so Linux will always 
think that something is inserted in the slot, but not talking back.

Robin.

> I haven't yet tested this with a high speed card yet to verify 1.8v
> signaling works but I'll find one and give it a shot.
> 
> Thanks a ton to both of your for the help
> 
> 
> On 2020-02-05 1:43 p.m., Peter Geis wrote:
>>>> First question, which kernel are you running?
>>>> Current mainline (5.4.17) works out of the box for the rk3328-roc-cc.
>>> Not from my experience.  I'm trying 5.5, but I also tried a fresh build
>>> ot 5.4.17 and neither will load from the sdcard in their default
>>> configuration.  If you have this working can you share your kernel config?
>> Considering all of the components to boot off emmc (which you are
>> clearly doing since you boot at all) are the same as the ones required
>> for sdmmc I doubt it's a configuration issue.
>> But to answer your question, I used the defconfig, stripped all of the
>> non rockchip components out, and made the base drivers builtin.
> 
> So I wasn't booting off of emmc.  I was booting from the sdcard, it
> would work so long as I prevented the kernel from trying to initialize
> the vcc_sdio regulator (by removing it or changing the gpio pin),
> presumably as u-boot left it in a reasonable state.
> 
>> Makes sense. If I remove vcc_sdio from the device tree, and remove the
>>> vqmmc entry from the sdmmc node, then the kernel continues to boot.  In
>>> that case I have
>>>
>>> # cat /sys/kernel/debug/regmap/dummy-syscon\@ff100000/registers | grep 428
>>>
>>> 428: 0000f800
>> As it should be, this should mean your mute pin is off (default state)
>> and the vqmmc voltage should be 3.3v.
> 
> Gotcha.  I also managed to verify this works as expected on my board
> with a multimeter and toggling the register from the u-boot shell.
> 
>>
>>> # cat /sys/kernel/debug/mmc1/ios
>>> clock:        0 Hz
>>> vdd:        0 (invalid)
>>> bus mode:    2 (push-pull)
>>> chip select:    0 (don't care)
>>> power mode:    0 (off)
>>> bus width:    0 (1 bits)
>>> timing spec:    0 (legacy)
>>> signal voltage:    0 (3.30 V)
>>> driver type:    0 (driver type B)
>> It's not detecting anything at all.
>> You say you booted off this card?
> So this is booting when I disabled vcc_sdio and just left it in the
> state that u-boot left it in, which is probably where the nonsensical
> output comes from.
>>
>> Could you run a `dmesg | grep mmc` and send all the results?
> 
> Here's a slightly scrubbed log of one of my failed boots.  I left in my
> traces of register writes to 428 and gpio-regulator state changes.
> 
> [    0.000000] Kernel command line: earlycon=uart8250,mmio32,0xff130000
> console=ttyS2,1500000 rw root=/dev/mmcblk0p5 init=/sbin/init
> kgdboc=ttyS2,1500000 dynamic_debug.verbose=1 loglevel=7 dyndbg="module
> dw_mmc +p ; module dw_mmc_rockchip +p ; module mmc_core +p"
> <snip>
> [    0.793750] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit
> address mode.
> [    0.794402] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller.
> [    0.798582] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a
> [    0.801194] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq
> 29,32 bit host data width,256 deep fifo
> [    0.815437] dwmmc_rockchip ff520000.dwmmc: IDMAC supports 32-bit
> address mode.
> [    0.820273] dwmmc_rockchip ff520000.dwmmc: Version ID is 270a
> [    0.822904] dwmmc_rockchip ff520000.dwmmc: DW MMC controller at irq
> 30,32 bit host data width,256 deep fifo
> [    0.825527] mmc_host mmc0: card is non-removable.
> [    0.838770] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req
> 400000Hz, actual 400000HZ div = 0)
> [    0.888886] ADAMVY Regmap write 428 <= 2f802
> [    0.904218] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit
> address mode.
> [    0.904870] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller.
> [    0.909055] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a
> [    0.911637] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq
> 29,32 bit host data width,256 deep fifo
> [    0.913954] ADAMVY Setting gpio regulator to value 3300000 state 0
> [    0.914503] ADAMVY Regmap write 428 <= 2f800
> [    0.927612] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req
> 400000Hz, actual 400000HZ div = 0)
> [    0.950160] VFS: Cannot open root device "mmcblk0p5" or
> unknown-block(0,0): error -6
> 
> 
> 
> Finally here's an updated patch for the device tree with Robin's
> original suggestion.
> 
> 
> Index: 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
> +++ linux-5.5/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
> @@ -45,6 +45,7 @@
>   	vcc_sdio: sdmmcio-regulator {
>   		compatible = "regulator-gpio";
>   		gpios = <&grf_gpio 0 GPIO_ACTIVE_HIGH>;
> +                enable-active-high;
>   		states = <1800000 0x1
>   			  3300000 0x0>;
>   		regulator-name = "vcc_sdio";
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Adam Van Ymeren]

On 2020-02-10 8:37 a.m., Robin Murphy wrote:
> On 09/02/2020 1:07 am, Adam Van Ymeren wrote:
>> Got it working. Robin you were right, it just needed enable-active-high;
>> added to the regulator, updated patch at the end of this message.
>
> Weird... after my initial excitement I went back and looked more
> closely at the binding and gpiolib-of code, only to realise that that
> property is only supposed to apply to specific 'enable' GPIOs (of
> which there are none here since it's always-on), and that the 'state'
> GPIOs were a separate thing and I'd jumped to the wrong conclusion. So
> now I'm doubly surprised that it actually makes a difference :/

Yeah you're right, it doesn't make a difference, it was just
coincidence.  It just seems to be really flaky, it's booting
successfully about 20-30% of the time, I kept drawing conclusions based
on one or two successful boots, but from now on I'll try 10 boots
before  With no changes and just unplugging/replugging the board, the
kernel only finds mmcblk1 20-30% of the time.  What's weird though is
that the first stage idbloader and u-boot so far have worked 100% of the
time on the same sdcard.


As I said early in the thread, if I remove vcc_sdio/vqmmc from the
device tree, then the kernel finds mmcblk1 every time I've attempted it
so far, although I haven't done extensive tests to see if i/o is
stable.  So there seems to be _something_ about how the kernel is
interacting with the regulator and/or the mmc host, otherwise I see no
explanation for why the kernel would fail where u-boot had succeeded.


I logged writes to register 0x428, and voltage changes in
gpio-regulator, with the default device tree when asking for 3.3V it
sets 0x428 to 0x20000, which is as expected, I verified the output of
the voltage regulator with a multimeter and it does appear to be 3.3V. 
I notice however that early in the gpio setup it first writes 0x20002 to
0x428 before later writing 0x20000 what initializing the mmc driver


[    0.545007] ADAMVY regmap 428 <= 20002
[    0.549348] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit
address mode.
[    0.550012] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller.
[    0.550615] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a
[    0.551154] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq
29,32 bit host data width,256 deep fifo
[    0.552527] ADAMVY: gpio_regulator_set_voltage vcc_sdio: uv: 3300000
state: 0
[    0.553158] ADAMVY regmap 428 <= 20000
[    0.566133] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req
400000Hz, actual 400000HZ div = 0)


My best guess is there's some sort of race condition?  Maybe a capacitor
is still charging and holding the voltage low just long enough that the
kernel gives up?  Or maybe the kernel is just not waiting long enough
for the mmc host to finish initializing.  In about 50% of my failed
boots I see this debug messages about mmc1 mixed into the kernel panic
like so.

[    0.662428] VFS: Cannot open root device "mmcblk1p5" or
unknown-block(0,0): error -6
[    0.663107] Please append a correct "root=" boot option; here are the
available partitions:
[    0.663847] Kernel panic - not syncing: VFS: Unable to mount root fs
on unknown-block(0,0)
[    0.663872] mmc1: starting CMD6 arg 00fffff0 flags 000000b5
[    0.664578] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.5.0 #37
[    0.665061] mmc1:     blksz 64 blocks 1 flags 00000200 tsac 100 ms nsac 0
[    0.665572] Hardware name: Firefly roc-rk3328-cc (DT)
[    0.666600] Call trace:
[    0.666832]  dump_backtrace+0x0/0x1b4
[    0.667161]  show_stack+0x14/0x1c
[    0.667461]  dump_stack+0xb4/0x100
[    0.667768]  panic+0x120/0x2f4
[    0.668046]  mount_block_root+0x2a0/0x328
[    0.668401]  mount_root+0x7c/0x88
[    0.668457] mmc1: req done (CMD6): 0: 00000900 00000000 00000000 00000000
[    0.668700]  prepare_namespace+0x154/0x164
[    0.669288] mmc1:     64 bytes transferred: 0
[    0.669642]  kernel_init_freeable+0x1d0/0x254
[    0.670040] mmc1: clock 25000000Hz busmode 2 powermode 2 cs 0 Vdd 21
width 1 timing 0
[    0.670404]  kernel_init+0x10/0xf8
[    0.671131] mmc_host mmc1: Bus speed (slot 0) = 25000000Hz (slot req
25000000Hz, actual 25000000HZ div = 0)
[    0.671378]  ret_from_fork+0x10/0x18
[    0.672230] mmc1: starting CMD55 arg af530000 flags 00000095

suggesting that the kernel is still doing stuff with mmc1 after it's
already given up on finding the root device.


Here's dmesg from a successful boot | grep mmc


$ grep mmc success.txt
[    0.000000] Kernel command line: earlycon=uart8250,mmio32,0xff130000
console=ttyS2,1500000 rw root=/dev/mmcblk1p5 init=/sbin/init
kgdboc=ttyS2,1500000 loglevel=7 dyndbg="module dw_mmc +p ; module
dw_mmc_rockchip +p ; module mmc_core +p"
[    0.123714] ADAMVY gpio fixed regulator quirks device:
sdmmc-regulator active_low: 1
[    0.485215] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit
address mode.
[    0.485879] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller.
[    0.486482] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a
[    0.487054] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq
29,32 bit host data width,256 deep fifo
[    0.489495] dwmmc_rockchip ff520000.dwmmc: IDMAC supports 32-bit
address mode.
[    0.490153] dwmmc_rockchip ff520000.dwmmc: Using internal DMA controller.
[    0.490758] dwmmc_rockchip ff520000.dwmmc: Version ID is 270a
[    0.491313] dwmmc_rockchip ff520000.dwmmc: DW MMC controller at irq
30,32 bit host data width,256 deep fifo
[    0.492952] mmc_host mmc0: card is non-removable.
[    0.506161] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req
400000Hz, actual 400000HZ div = 0)
[    0.559169] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit
address mode.
[    0.559834] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller.
[    0.560437] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a
[    0.560980] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq
29,32 bit host data width,256 deep fifo
[    0.575968] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req
400000Hz, actual 400000HZ div = 0)
[    0.650647] mmc_host mmc1: Bus speed (slot 0) = 25000000Hz (slot req
25000000Hz, actual 25000000HZ div = 0)
[    0.657873] mmc1: new SD card at address af53
[    0.659091] mmcblk1: mmc1:af53 SU02G 1.84 GiB
[    0.677231]  mmcblk1: p1 p2 p3 p4 p5
[    0.695708] EXT4-fs (mmcblk1p5): warning: mounting unchecked fs,
running e2fsck is recommended
[    0.700796] EXT4-fs (mmcblk1p5): mounted filesystem without journal.
Opts: (null)
[    1.029332] dwmmc_rockchip ff520000.dwmmc: Busy; trying anyway
[    1.529858] mmc_host mmc0: Timeout sending command (cmd 0x202000 arg
0x0 status 0x80202000)
[    1.544526] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req
300000Hz, actual 300000HZ div = 0)
[    2.067046] dwmmc_rockchip ff520000.dwmmc: Busy; trying anyway
[    2.567565] mmc_host mmc0: Timeout sending command (cmd 0x202000 arg
0x0 status 0x80202000)
[    2.582199] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req
200000Hz, actual 200000HZ div = 0)
[    3.107353] dwmmc_rockchip ff520000.dwmmc: Busy; trying anyway
[    3.607889] mmc_host mmc0: Timeout sending command (cmd 0x202000 arg
0x0 status 0x80202000)
[    3.622620] mmc_host mmc0: Bus speed (slot 0) = 100000Hz (slot req
100000Hz, actual 100000HZ div = 0)
[    4.155300] dwmmc_rockchip ff520000.dwmmc: Busy; trying anyway
[    4.655839] mmc_host mmc0: Timeout sending command (cmd 0x202000 arg
0x0 status 0x80202000)

and for a failed boot

$ grep mmc fail.txt
[    0.000000] Kernel command line: earlycon=uart8250,mmio32,0xff130000
console=ttyS2,1500000 rw root=/dev/mmcblk1p5 init=/sbin/init
kgdboc=ttyS2,1500000 loglevel=7 dyndbg="module dw_mmc +p ; module
dw_mmc_rockchip +p ; module mmc_core +p"
[    0.123799] ADAMVY gpio fixed regulator quirks device:
sdmmc-regulator active_low: 1
[    0.485295] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit
address mode.
[    0.485955] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller.
[    0.486560] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a
[    0.487128] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq
29,32 bit host data width,256 deep fifo
[    0.489584] dwmmc_rockchip ff520000.dwmmc: IDMAC supports 32-bit
address mode.
[    0.490243] dwmmc_rockchip ff520000.dwmmc: Using internal DMA controller.
[    0.490849] dwmmc_rockchip ff520000.dwmmc: Version ID is 270a
[    0.491400] dwmmc_rockchip ff520000.dwmmc: DW MMC controller at irq
30,32 bit host data width,256 deep fifo
[    0.493043] mmc_host mmc0: card is non-removable.
[    0.506248] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req
400000Hz, actual 400000HZ div = 0)
[    0.559249] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit
address mode.
[    0.559960] dwmmc_rockchip ff500000.dwmmc: Using internal DMA controller.
[    0.560564] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a
[    0.561108] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq
29,32 bit host data width,256 deep fifo
[    1.063521] dwmmc_rockchip ff520000.dwmmc: Busy; trying anyway
[    1.564049] mmc_host mmc0: Timeout sending command (cmd 0x202000 arg
0x0 status 0x80202000)
[    1.564925] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req
400000Hz, actual 400000HZ div = 0)
[    1.579671] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req
300000Hz, actual 300000HZ div = 0)
[    2.109484] dwmmc_rockchip ff520000.dwmmc: Busy; trying anyway
[    2.610015] mmc_host mmc0: Timeout sending command (cmd 0x202000 arg
0x0 status 0x80202000)
[    2.612411] VFS: Cannot open root device "mmcblk1p5" or
unknown-block(0,0): error -6


>
>> I went back over my config with a fine tooth comb and found a few
>> rockchip drivers I was missing including PINCTRL_RK805 which seems
>> related but I honestly can't figure out how.  I will try to narrow down
>> which specific driver was missing.  It was odd because it would find the
>> mmc host but just fail notice that a card was present.  It seemed to set
>> the register correctly and identify the mmc host, but failed to notice
>> any card present.
>
> PINCTRL_RK805 should only be for the couple of GPIO pins on the PMIC
> itself which IIRC the reference design uses for the ethernet LEDs, so
> I wouldn't expect it to be relevant.
Indeed.  I was drawing connections that weren't there due to the flakiness.
>
> Those symptoms make sense for the voltages being backwards (or just
> stuck at 1.8V) though - when the I/O domain is configured to expect
> 3.3V, 1.8V is too low to register as a logic high, so Linux will
> always think that something is inserted in the slot, but not talking back.

Hmm.  I tried adding broken-cd, but I couldn't tell any significant
difference in the rate of successful boots.

I have an emmc module coming so hopefully I can have something reliable
to boot from and can iterate faster without having to physically move an
sdcard back and forth every time.

> Robin.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Adam Van Ymeren]

I'm dumb, I forgot about the rootwait kernel parameter...

15 successful boots in a row so far after adding that.  Sorry for all
the noise.

Thanks for the help and patience,

-Adam


On 2020-02-10 8:37 a.m., Robin Murphy wrote:
> On 09/02/2020 1:07 am, Adam Van Ymeren wrote:
>> Got it working. Robin you were right, it just needed enable-active-high;
>> added to the regulator, updated patch at the end of this message.
>
> Weird... after my initial excitement I went back and looked more
> closely at the binding and gpiolib-of code, only to realise that that
> property is only supposed to apply to specific 'enable' GPIOs (of
> which there are none here since it's always-on), and that the 'state'
> GPIOs were a separate thing and I'd jumped to the wrong conclusion. So
> now I'm doubly surprised that it actually makes a difference :/
>
>> I went back over my config with a fine tooth comb and found a few
>> rockchip drivers I was missing including PINCTRL_RK805 which seems
>> related but I honestly can't figure out how.  I will try to narrow down
>> which specific driver was missing.  It was odd because it would find the
>> mmc host but just fail notice that a card was present.  It seemed to set
>> the register correctly and identify the mmc host, but failed to notice
>> any card present.
>
> PINCTRL_RK805 should only be for the couple of GPIO pins on the PMIC
> itself which IIRC the reference design uses for the ethernet LEDs, so
> I wouldn't expect it to be relevant.
>
> Those symptoms make sense for the voltages being backwards (or just
> stuck at 1.8V) though - when the I/O domain is configured to expect
> 3.3V, 1.8V is too low to register as a logic high, so Linux will
> always think that something is inserted in the slot, but not talking
> back.
>
> Robin.
>
>> I haven't yet tested this with a high speed card yet to verify 1.8v
>> signaling works but I'll find one and give it a shot.
>>
>> Thanks a ton to both of your for the help
>>
>>
>> On 2020-02-05 1:43 p.m., Peter Geis wrote:
>>>>> First question, which kernel are you running?
>>>>> Current mainline (5.4.17) works out of the box for the rk3328-roc-cc.
>>>> Not from my experience.  I'm trying 5.5, but I also tried a fresh
>>>> build
>>>> ot 5.4.17 and neither will load from the sdcard in their default
>>>> configuration.  If you have this working can you share your kernel
>>>> config?
>>> Considering all of the components to boot off emmc (which you are
>>> clearly doing since you boot at all) are the same as the ones required
>>> for sdmmc I doubt it's a configuration issue.
>>> But to answer your question, I used the defconfig, stripped all of the
>>> non rockchip components out, and made the base drivers builtin.
>>
>> So I wasn't booting off of emmc.  I was booting from the sdcard, it
>> would work so long as I prevented the kernel from trying to initialize
>> the vcc_sdio regulator (by removing it or changing the gpio pin),
>> presumably as u-boot left it in a reasonable state.
>>
>>> Makes sense. If I remove vcc_sdio from the device tree, and remove the
>>>> vqmmc entry from the sdmmc node, then the kernel continues to
>>>> boot.  In
>>>> that case I have
>>>>
>>>> # cat /sys/kernel/debug/regmap/dummy-syscon\@ff100000/registers |
>>>> grep 428
>>>>
>>>> 428: 0000f800
>>> As it should be, this should mean your mute pin is off (default state)
>>> and the vqmmc voltage should be 3.3v.
>>
>> Gotcha.  I also managed to verify this works as expected on my board
>> with a multimeter and toggling the register from the u-boot shell.
>>
>>>
>>>> # cat /sys/kernel/debug/mmc1/ios
>>>> clock:        0 Hz
>>>> vdd:        0 (invalid)
>>>> bus mode:    2 (push-pull)
>>>> chip select:    0 (don't care)
>>>> power mode:    0 (off)
>>>> bus width:    0 (1 bits)
>>>> timing spec:    0 (legacy)
>>>> signal voltage:    0 (3.30 V)
>>>> driver type:    0 (driver type B)
>>> It's not detecting anything at all.
>>> You say you booted off this card?
>> So this is booting when I disabled vcc_sdio and just left it in the
>> state that u-boot left it in, which is probably where the nonsensical
>> output comes from.
>>>
>>> Could you run a `dmesg | grep mmc` and send all the results?
>>
>> Here's a slightly scrubbed log of one of my failed boots.  I left in my
>> traces of register writes to 428 and gpio-regulator state changes.
>>
>> [    0.000000] Kernel command line: earlycon=uart8250,mmio32,0xff130000
>> console=ttyS2,1500000 rw root=/dev/mmcblk0p5 init=/sbin/init
>> kgdboc=ttyS2,1500000 dynamic_debug.verbose=1 loglevel=7 dyndbg="module
>> dw_mmc +p ; module dw_mmc_rockchip +p ; module mmc_core +p"
>> <snip>
>> [    0.793750] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit
>> address mode.
>> [    0.794402] dwmmc_rockchip ff500000.dwmmc: Using internal DMA
>> controller.
>> [    0.798582] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a
>> [    0.801194] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq
>> 29,32 bit host data width,256 deep fifo
>> [    0.815437] dwmmc_rockchip ff520000.dwmmc: IDMAC supports 32-bit
>> address mode.
>> [    0.820273] dwmmc_rockchip ff520000.dwmmc: Version ID is 270a
>> [    0.822904] dwmmc_rockchip ff520000.dwmmc: DW MMC controller at irq
>> 30,32 bit host data width,256 deep fifo
>> [    0.825527] mmc_host mmc0: card is non-removable.
>> [    0.838770] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req
>> 400000Hz, actual 400000HZ div = 0)
>> [    0.888886] ADAMVY Regmap write 428 <= 2f802
>> [    0.904218] dwmmc_rockchip ff500000.dwmmc: IDMAC supports 32-bit
>> address mode.
>> [    0.904870] dwmmc_rockchip ff500000.dwmmc: Using internal DMA
>> controller.
>> [    0.909055] dwmmc_rockchip ff500000.dwmmc: Version ID is 270a
>> [    0.911637] dwmmc_rockchip ff500000.dwmmc: DW MMC controller at irq
>> 29,32 bit host data width,256 deep fifo
>> [    0.913954] ADAMVY Setting gpio regulator to value 3300000 state 0
>> [    0.914503] ADAMVY Regmap write 428 <= 2f800
>> [    0.927612] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req
>> 400000Hz, actual 400000HZ div = 0)
>> [    0.950160] VFS: Cannot open root device "mmcblk0p5" or
>> unknown-block(0,0): error -6
>>
>>
>>
>> Finally here's an updated patch for the device tree with Robin's
>> original suggestion.
>>
>>
>> Index: 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
>> +++ linux-5.5/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
>> @@ -45,6 +45,7 @@
>>       vcc_sdio: sdmmcio-regulator {
>>           compatible = "regulator-gpio";
>>           gpios = <&grf_gpio 0 GPIO_ACTIVE_HIGH>;
>> +                enable-active-high;
>>           states = <1800000 0x1
>>                 3300000 0x0>;
>>           regulator-name = "vcc_sdio";
>>
>>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel