On Tue, Feb 4, 2020 at 11:14 AM Adam Van Ymeren [off-list ref] wrote:

On 2020-02-04 10:15 a.m., Peter Geis wrote:

quoted

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.

quoted

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