AM5728: SDHCI issue

Andrej,

below is an extract on how this section is supposed to look like our current AM57x processor SDK on am AM574x IDK board as an example.

[    3.097055] sdhci-pltfm: SDHCI platform and OF driver helper
[    3.103355] omap_gpio 4805d000.gpio: Could not set line 27 debounce to 200000 microseconds (-22)
[    3.112578] sdhci-omap 4809c000.mmc: Got CD GPIO
[    3.117409] sdhci-omap 4809c000.mmc: Linked as a consumer to regulator.26
[    3.124444] sdhci-omap 4809c000.mmc: Linked as a consumer to regulator.11
[    3.131327] sdhci-omap 4809c000.mmc: Dropping the link to regulator.11
[    3.137964] sdhci-omap 4809c000.mmc: Linked as a consumer to regulator.2
[    3.144881] sdhci-omap 4809c000.mmc: Linked as a consumer to regulator.11
[    3.151775] sdhci-omap 4809c000.mmc: no pinctrl state for ddr_3_3v mode
[    3.185052] mmc0: SDHCI controller on 4809c000.mmc [4809c000.mmc] using ADMA
[    3.193212] sdhci-omap 480b4000.mmc: Linked as a consumer to regulator.2
[    3.200046] sdhci-omap 480b4000.mmc: Dropping the link to regulator.2
[    3.206674] sdhci-omap 480b4000.mmc: Linked as a consumer to regulator.2
[    3.236457] mmc0: host does not support reading read-only switch, assuming write-enable
[    3.238987] mmc1: SDHCI controller on 480b4000.mmc [480b4000.mmc] using ADMA
[    3.246475] mmc0: new high speed SDHC card at address 0007
[    3.258593] ledtrig-cpu: registered to indicate activity on CPUs
[    3.268065] mmcblk0: mmc0:0007 SD16G 14.9 GiB
[    3.268674] NET: Registered protocol family 10
[    3.283497]  mmcblk0: p1 p2

Your error messages point to that there could be an issue with pinmux setup in the DTS, specifically it seems to be missing data related to "iodelay" data. Can you look at the below as an example to see how different board-specific DTS files each include sets of iodelay dtsi files. Do you have any of those included?

a0797059@jiji:~/git/linux.alt (HEAD detached from 5f8c1c6121da)
$ git grep 'dra7.*iodelay.dtsi'
arch/arm/boot/dts/am571x-idk.dts:#include "dra7-mmc-iodelay.dtsi"
arch/arm/boot/dts/am571x-idk.dts:#include "dra72x-mmc-iodelay.dtsi"
arch/arm/boot/dts/am572x-idk.dts:#include "dra7-mmc-iodelay.dtsi"
arch/arm/boot/dts/am572x-idk.dts:#include "dra74x-mmc-iodelay.dtsi"
arch/arm/boot/dts/am574x-idk.dts:#include "dra7-mmc-iodelay.dtsi"
arch/arm/boot/dts/am574x-idk.dts:#include "dra76x-mmc-iodelay.dtsi"
arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi:#include "dra74x-mmc-iodelay.dtsi"
arch/arm/boot/dts/dra7-evm.dts:#include "dra74x-mmc-iodelay.dtsi"
arch/arm/boot/dts/dra71-evm.dts:#include "dra7-mmc-iodelay.dtsi"
arch/arm/boot/dts/dra71-evm.dts:#include "dra72x-mmc-iodelay.dtsi"
arch/arm/boot/dts/dra72-evm-revc.dts:#include "dra72x-mmc-iodelay.dtsi"
arch/arm/boot/dts/dra72-evm.dts:#include "dra72x-mmc-iodelay.dtsi"
arch/arm/boot/dts/dra76-evm.dts:#include "dra76x-mmc-iodelay.dtsi"

Based on the above if the device you are using is an AM572x you probably need these includes...

#include "dra7-mmc-iodelay.dtsi"
#include "dra74x-mmc-iodelay.dtsi"

Regards, Andreas

Hi Andy,

Andrej Valek said:

Error was, that "mmc2_pins_ddr_3_3v" was renamed to "mmc2_pins_ddr_3_3v_rev11". Same for delays.

Ok thanks for confirming.

Andrej Valek said:

vmmc-supply = <&vdd_3v3>;
vqmmc-supply = <&ldo1_reg>;
Is it required? 
Isn't the "<&ldo1_reg>;enough?

This voltage rail is required and used for the I/O lines/structures involved in the MMC communication.

Andrej Valek said:

Are the ti-iodelay ok? Why they are there?

These are diagnostic prints from the drivers/pinctrl/ti/pinctrl-ti-iodelay.c driver. Since there are multiple sets of iodelay values dependent on MMCx transfer mode I'd expect those prints to appear when the driver switches the MMC access speed / transfer mode. Those prints essentially tell you that the driver is making use of the iodelay feature which is required to be used on AM57xx type of devices.

Regards, Andreas

Hello Andreas,

After some time I have brought the device back to me and tried some experiments. Device is booting via NFS as well, but not with flash itself.

[    1.983901] sdhci-omap 4809c000.mmc: Got CD GPIO
[    1.988688] sdhci-omap 4809c000.mmc: Linked as a consumer to regulator.27
[    1.995724] sdhci-omap 4809c000.mmc: Linked as a consumer to regulator.12
[    2.002590] sdhci-omap 4809c000.mmc: Dropping the link to regulator.12
[    2.009234] sdhci-omap 4809c000.mmc: Linked as a consumer to regulator.2
[    2.016170] sdhci-omap 4809c000.mmc: Linked as a consumer to regulator.12
[    2.023037] sdhci-omap 4809c000.mmc: no pinctrl state for ddr_3_3v mode
[    2.056396] mmc0: SDHCI controller on 4809c000.mmc [4809c000.mmc] using ADMA
[    2.064309] sdhci-omap 480b4000.mmc: Linked as a consumer to regulator.2
[    2.071121] sdhci-omap 480b4000.mmc: Dropping the link to regulator.2
[    2.077784] sdhci-omap 480b4000.mmc: Linked as a consumer to regulator.2
[    2.110864] mmc1: SDHCI controller on 480b4000.mmc [480b4000.mmc] using ADMA
[    2.119047] ledtrig-cpu: registered to indicate activity on CPUs
[    2.127212] hidraw: raw HID events driver (C) Jiri Kosina
[    2.132880] usbcore: registered new interface driver usbhid
[    2.138686] usbhid: USB HID core driver
[    2.177632] NET: Registered protocol family 10
[    2.182923] Segment Routing with IPv6
[    2.186770] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    2.193238] NET: Registered protocol family 17
[    2.197793] Key type dns_resolver registered
[    2.202214] ThumbEE CPU extension supported.
[    2.206600] Registering SWP/SWPB emulation handler
[    2.211492] omap_voltage_late_init: Voltage driver support not added
[    2.217986] Power Management for TI OMAP4+ devices.
[    2.224053] registered taskstats version 1
[    2.228523] mmc1: new DDR MMC card at address 0001
[    2.235251] mmcblk1: mmc1:0001 M52516 7.28 GiB
[    2.240072] mmcblk1boot0: mmc1:0001 M52516 partition 1 4.00 MiB
[    2.255310] mmcblk1boot1: mmc1:0001 M52516 partition 2 4.00 MiB
[    2.267465] mmcblk1rpmb: mmc1:0001 M52516 partition 3 4.00 MiB, chardev (246:0)
[    2.275294] dmm 4e000000.dmm: workaround for errata i878 in use
[    2.276234]  mmcblk1: p1 p2 p3 p4 < p5 >
[    2.288039] dmm 4e000000.dmm: initialized all PAT entries
[    2.294477] omapdss_dss 58000000.dss: Linked as a consumer to regulator.21
[    2.301546] DSS: OMAP DSS rev 6.1
[    2.305699] omapdss_dss 58000000.dss: bound 58001000.dispc (ops dispc_component_ops)
[    2.335372] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    2.342017] [drm] No driver support for vblank timestamp query.
[    2.356986] [drm] Enabling DMM ywrap scrolling
[    2.703125] Console: switching to colour frame buffer device 171x48
[    2.715388] omapdrm omapdrm.0: fb0: omapdrm frame buffer device
[    2.722308] [drm] Initialized omapdrm 1.0.0 20110917 for omapdrm.0 on minor 0
[    2.730975] input: gpio_keys as /devices/platform/gpio_keys/input/input0
[    2.738776] palmas-rtc 48070000.i2c:tps659038@58:tps659038_rtc: setting system clock to 2019-10-04 01:03:37 UTC (1570151017)
[    2.750565] vmmcwl_fixed: disabling
[    2.754068] aic_dvdd_fixed: disabling
[    2.758289] Waiting 1 sec before mounting root device...
[    3.845033] Waiting for root device /dev/mmcblk0p2...

The main problem is, that MMC2 is now enumerated as mmcblk1 and not mmcblk0 since kernel upgrade from 4.4.113 -> 4.19.59. I can't change a u-boot environment to select flash.

So I would to fix MMC ordering. I have tried an aliases:

aliases {
	// first try
	mmcblk0 = &mmc2;
	mmcblk1 = &mmc1;

	// second try
	mmc0 = &mmc2;	/* Fixed to mmcblk0 for &mmc2 */
	mmc1 = &mmc1;	/* Fixed to mmcblk1 for &mmc1 */
};

Both of my tries didn't work. I think, some code for aliases is missing in mmc driver. How I can set fixed ordering here?

Thank you,
Andy

Hello Andreas,

I have tested booting with SDcard plugged in and it booted up. So isn't there an issue, that mmcblks are detected/moved, when card is in? I think, there should be static one.

On the other hand, I have tested your solution and it worked. But to be honest, I don't want to change a dra7.dtsi file. I think, it should be configurable in the higher layer.

Isn't possible to implement alias mechanism like this https://patchwork.kernel.org/patch/8685711/

Hi Andrej,

Andrej Valek said:

So isn't there an issue, that mmcblks are detected/moved, when card is in? I think, there should be static one.

Yes as you have found yourself searching the mailing lists you are not the only one that would like to see such a feature, which I agree can be helpful especially in an embedded environment.

Andrej Valek said:

On the other hand, I have tested your solution and it worked. But to be honest, I don't want to change a dra7.dtsi file. I think, it should be configurable in the higher layer.

Isn't possible to implement alias mechanism like this https://patchwork.kernel.org/patch/8685711/

There have been other attempts to get this feature implemented, but glancing over the link you found this seems to be one of the better solutions. I do not know why no progress was made on this upstream but since the Kernel is an open-source project where everybody is welcome to contribute there are a couple of things you could do:

1. Reply to the email thread for the patch you found or reach out to the patch author (Jaehoon Chung) privately to see what the status of this patch is (additional searching online might also shed some more light into this)
2. In case Jaehoon has no time/resources to complete upstreaming this patch, see if you can offer him to get it over the finish line by porting it to the latest Kernel, re-resting it, and re-posting it to the appropriate Kernel mailing list, all while giving him credit being the original author

Or, you could create your own solution (and post it upstream), potentially based on what is already present in the kernel for drivers/mmc/host/dw_mmc*

Regards, Andreas

Hello Andreas,

I have made a written an email to guy, who was trying to implement the alias mechanism. But no response :(.

Currently I have used your proposal to move "mmc" ordering in dra7.dts.

What about this one http://e2e.ti.com/support/processors/f/791/p/771076/2902059#2902059

Andrej,

Andrej Valek said:

I have made a written an email to guy, who was trying to implement the alias mechanism. But no response :(.

Glad you tried it. What you could still do if you really wanted to is to reply to that thread in the public mailing list (rather than privately), offering to take over the completion of this patch if there are no objections, and then doing such while giving credit to the original author. I don't see any reason why this wouldn't be a reasonable thing to do if done openly (soliciting feedback/comments) and politely.

Andrej Valek said:

Currently I have used your proposal to move "mmc" ordering in dra7.dts.

What about this one http://e2e.ti.com/support/processors/f/791/p/771076/2902059#2902059

Just a different approach. If what I proposed fits your basic needs I'd stick to that, this is what folks have been using for various other scenarios (such as network interfaces, etc.) and I think it is easier to maintain/migrate moving forward. Having to keep reverting different patches as outlined in the other solution will result in a bigger maintenance burden when you move Kernel versions (ever-increasing potential for conflicts applying/reverting patches).

Regards, Andreas