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

[Adam Van Ymeren <adam@vany.ca>]

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