[Letux-kernel] Strange problem with non-LPAE letux-4.20-rc kernels on 4GB Pyra only - PARTUUID not found

[H. Nikolaus Schaller]

> Am 16.12.2018 um 12:24 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> 
>> Am 16.12.2018 um 12:13 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 
>>> So this means WP and CD are (basically) working (besides the
>>> known problem of missing pull-up which should be almost harmless
>>> if the card is inserted - it may only write-protect the card
>>> unexpectedly).
>> 
>> I have cross-checked: with reverting the offending patch I can
>> boot this board with letux-4.20-rc6.
>> 
>> Next idea to check: is the polarity definition of the CD gpio
>> ignored or wrong for the new code?
> 
> It looks as if the olarity is wrong!
> 
> [    3.605536] sr_init: No PMIC hook to init smartreflex
> [    3.611647] vmmcsdio_fixed: disabling
> [    3.616972] ldo3: disabling
> [    3.620801] ldo8: disabling
> [    3.631429] ALSA device list:
> [    3.634550]   No soundcards found.
> [    3.638541] Waiting for root device PARTUUID=c8a507cd-02...
> [    3.844591] omap_hsmmc 480b4000.mmc: local_mmc_gpio_get_cd: ret = -38
> [    4.084753] omap_hsmmc 4809c000.mmc: local_mmc_gpio_get_cd: ret = 0
> [    4.964663] omap_hsmmc 480b4000.mmc: local_mmc_gpio_get_cd: ret = -38
> [    5.124680] omap_hsmmc 4809c000.mmc: local_mmc_gpio_get_cd: ret = 0
> [    6.084634] omap_hsmmc 480b4000.mmc: local_mmc_gpio_get_cd: ret = -38
> [    6.164596] omap_hsmmc 4809c000.mmc: local_mmc_gpio_get_cd: ret = 0
> [    7.204623] omap_hsmmc 480b4000.mmc: local_mmc_gpio_get_cd: ret = -38
> [    7.204685] omap_hsmmc 4809c000.mmc: local_mmc_gpio_get_cd: ret = 0
> [    8.244695] omap_hsmmc 4809c000.mmc: local_mmc_gpio_get_cd: ret = 0
> [    8.324464] omap_hsmmc 480b4000.mmc: local_mmc_gpio_get_cd: ret = -38
> [    9.284692] omap_hsmmc 4809c000.mmc: local_mmc_gpio_get_cd: ret = 0
> [    9.444473] omap_hsmmc 480b4000.mmc: local_mmc_gpio_get_cd: ret = -38
> [   10.324687] omap_hsmmc 4809c000.mmc: local_mmc_gpio_get_cd: ret = 0
> [   10.564536] omap_hsmmc 480b4000.mmc: local_mmc_gpio_get_cd: ret = -38
> [   11.364649] omap_hsmmc 4809c000.mmc: local_mmc_gpio_get_cd: ret = 0
> [   11.684575] omap_hsmmc 480b4000.mmc: local_mmc_gpio_get_cd: ret = -38
> 
> --- here I removed the card
> 
> [   12.404685] omap_hsmmc 4809c000.mmc: local_mmc_gpio_get_cd: ret = 1
> [   12.804522] omap_hsmmc 480b4000.mmc: local_mmc_gpio_get_cd: ret = -38
> [   13.524717] omap_hsmmc 4809c000.mmc: local_mmc_gpio_get_cd: ret = 1
> [   13.924531] omap_hsmmc 480b4000.mmc: local_mmc_gpio_get_cd: ret = -38
> [   14.644709] omap_hsmmc 4809c000.mmc: local_mmc_gpio_get_cd: ret = 1
> [   15.044620] omap_hsmmc 480b4000.mmc: local_mmc_gpio_get_cd: ret = -38
> [   15.764612] omap_hsmmc 4809c000.mmc: local_mmc_gpio_get_cd: ret = 1
> [   16.164613] omap_hsmmc 480b4000.mmc: local_mmc_gpio_get_cd: ret = -38
> 
> So it looks as if the gpio used by the mmc framework should report "1"
> for inserted SD card and "0" for not inserted. And the logic level on
> the GPIO pin is reversed since there is a pull-up and a switch to GND...
> 
> This also explains why we don't see the effect on the GTA04. The GTA04
> has no CD gpio at all...
> 
> Still unclear is why the other SD slot works. Maybe the polarity defintion
> is correct.
> 
> And unclear is why the older Pyra works. Maybe that device has a broken
> GPIO?

Ok, I think I have found it...

And a full explanation:
Older Pyra (v5.0 or v5.1 CPU board) has gpio cd disabled and uses polling.

Latest Pyra (v5.2 and v5.3) uses this definition:

&mmc1 { /* first SD slot */
	pinctrl-names = "default";
	pinctrl-0 = <&mmc1_pins>;
	cd-gpios = <&gpio8 4 0>;	/* gpio8_228 */
	wp-gpios = <&gpio8 5 0>;	/* gpio8_229 */
};


For the other SD slot which is working it uses this:

&mmc4 { /* second (u)SD slot (SDIO capable) */
	vmmc-supply = <&ldo2_reg>;
	pinctrl-names = "default";
	pinctrl-0 = <&mmc4_pins>;
	bus-width = <4>;
	cd-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>;	/* gpio3_77 */
	wp-gpios = <&gpio3 15 GPIO_ACTIVE_HIGH>;	/* gpio3_79 */
};

So mmc4 properly defines GPIO_ACTIVE_LOW and GPIO_ACTIVE_HIGH.
Transferring this to the mmc1 definition makes it work again.

Phew...

I always knew it must be something that simple... But we have to understand
it first.

BR,
Nikolaus