All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adam Van Ymeren <adam-M8Nx6PV4agg@public.gmane.org>
To: Peter Geis <pgwipeout-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "open list:ARM/Rockchip SoC..."
	<linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>,
	Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH] arm64: dts: rockchip: Fix rk3328-roc-cc sdmmcio-regulator
Date: Sat, 8 Feb 2020 20:07:50 -0500	[thread overview]
Message-ID: <88ee95cc-4160-a1b2-ae38-6a1146cc2dde@vany.ca> (raw)
In-Reply-To: <CAMdYzYopKjRpVnyq2k84XZK0kmR_ZBH8KNjVyPz3upQjx0rLJQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

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

WARNING: multiple messages have this Message-ID (diff)
From: Adam Van Ymeren <adam@vany.ca>
To: Peter Geis <pgwipeout@gmail.com>
Cc: "open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Heiko Stuebner <heiko@sntech.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: dts: rockchip: Fix rk3328-roc-cc sdmmcio-regulator
Date: Sat, 8 Feb 2020 20:07:50 -0500	[thread overview]
Message-ID: <88ee95cc-4160-a1b2-ae38-6a1146cc2dde@vany.ca> (raw)
In-Reply-To: <CAMdYzYopKjRpVnyq2k84XZK0kmR_ZBH8KNjVyPz3upQjx0rLJQ@mail.gmail.com>

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

  parent reply	other threads:[~2020-02-09  1:07 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31 23:38 [PATCH] arm64: dts: rockchip: Fix rk3328-roc-cc sdmmcio-regulator Adam Van Ymeren
2020-01-31 23:38 ` Adam Van Ymeren
2020-02-01 10:51 ` Robin Murphy
2020-02-01 10:51   ` Robin Murphy
2020-02-01 15:41   ` Adam Van Ymeren
2020-02-01 17:46     ` Robin Murphy
2020-02-01 22:10       ` Adam Van Ymeren
     [not found]         ` <510d310b-30af-7b24-d472-907bc6b2ef46-M8Nx6PV4agg@public.gmane.org>
2020-02-04 15:15           ` Peter Geis
2020-02-04 15:15             ` Peter Geis
2020-02-04 16:14             ` Adam Van Ymeren
     [not found]               ` <7b36198e-25c0-4f3b-d871-6bd5aaf619d8-M8Nx6PV4agg@public.gmane.org>
2020-02-04 17:25                 ` Peter Geis
2020-02-04 17:25                   ` Peter Geis
2020-02-05 16:14                   ` Adam Van Ymeren
2020-02-05 17:39                     ` Robin Murphy
2020-02-05 17:39                       ` Robin Murphy
     [not found]                     ` <2f863743-f5fd-7702-ac22-762dbca834cb-M8Nx6PV4agg@public.gmane.org>
2020-02-05 18:43                       ` Peter Geis
2020-02-05 18:43                         ` Peter Geis
2020-02-05 19:02                         ` Robin Murphy
2020-02-05 19:02                           ` Robin Murphy
2020-02-06  3:05                           ` Thomas McKahan
2020-02-06  3:05                             ` Thomas McKahan
     [not found]                         ` <CAMdYzYopKjRpVnyq2k84XZK0kmR_ZBH8KNjVyPz3upQjx0rLJQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-02-09  1:07                           ` Adam Van Ymeren [this message]
2020-02-09  1:07                             ` Adam Van Ymeren
2020-02-10 13:37                             ` Robin Murphy
2020-02-11 21:32                               ` Adam Van Ymeren
2020-02-11 21:39                               ` Adam Van Ymeren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=88ee95cc-4160-a1b2-ae38-6a1146cc2dde@vany.ca \
    --to=adam-m8nx6pv4agg@public.gmane.org \
    --cc=heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=pgwipeout-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=robin.murphy-5wv7dgnIgG8@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.