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

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

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