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
next prev 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: linkBe 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.