[Letux-kernel] [PATCH 00/20] A bunch of JZ4730 fixups for letux-kernel
H. Nikolaus Schaller
hns at goldelico.com
Sat Dec 12 16:20:12 CET 2020
> Am 12.12.2020 um 14:57 schrieb Paul Boddie <paul at boddie.org.uk>:
>
> On Saturday, 12 December 2020 12:04:31 CET H. Nikolaus Schaller wrote:
>>
>> Thanks for the patch!
>>
>> It has changed something:
>>
>> [ 0.157233] Waiting for root device /dev/mmcblk1p2...
>> [ 0.157380] mmc0: unrecognised SCR structure version 4
>> [ 0.162797] mmc0: error -22 whilst initialising SD card
>> [ 0.172349] mmc0: card never left busy state
>> [ 0.176875] mmc0: error -145 whilst initialising SD card
>> [ 0.192446] mmc0: card never left busy state
>> [ 0.196970] mmc0: error -145 whilst initialising SD card
>> [ 0.212861] mmc0: card never left busy state
>> [ 0.217387] mmc0: error -145 whilst initialising SD card
>>
>> The mmc0: messages are new.
>
> I guess these messages could easily occur with bad read operations where the
> transfers just produce nonsense or nothing, but there might be something else
> involved.
Exactly.
>
>> With some printk:
>>
>> [ 0.177922] ALSA device list:
>> [ 0.181085] No soundcards found.
>> [ 0.170902] mmc_gpio_set_rs
>> [ 0.169238] mmc_gpio_set_rs
>> [ 0.172284] mmc_gpiod_request_cd_irq
>> [ 0.177171] mmc_gpio_get_cd
>> [ 0.180338] jz4740-mmc 10021000.mmc: Ingenic SD/MMC card driver
>> registered
>> [ 0.170315] jz4740-mmc 10021000.mmc: Using DMA, 4-bit mode
>> [ 0.182508] Waiting for root device /dev/mmcblk1p2...
>> [ 0.182818] mmc0: unrecognised SCR structure version 4
>> [ 0.188236] mmc0: error -22 whilst initialising SD card
>> [ 0.177274] mmc_gpio_set_rs
>> [ 0.177907] mmc_gpio_set_rs
>> [ 0.197028] mmc0: card never left busy state
>> [ 0.201554] mmc0: error -145 whilst initialising SD card
>> [ 0.197475] mmc_gpio_set_rs
>> [ 0.197603] mmc_gpio_set_rs
>> [ 0.217022] mmc0: card never left busy state
>> [ 0.221546] mmc0: error -145 whilst initialising SD card
>> [ 0.217489] mmc_gpio_set_rs
>> [ 0.217598] mmc_gpio_set_rs
>> [ 0.237292] mmc0: card never left busy state
>> [ 0.241818] mmc0: error -145 whilst initialising SD card
>>
>> I think I should print some values from mmc_gpio_set_rs,
>> mmc_gpiod_request_cd_irq, mmc_gpio_get_cd.
>
> Yes, the mmc_gpio_set_rs calls are probably related to power cycling, done by
> mmc_power_up.
>
>> And it *may* be that it has something to do with:
>>
>> https://www.spinics.net/lists/arm-kernel/msg40834.html (they removed the
>> check for SCR structure version)
>
> I don't think this is likely to be the solution. :-)
Indeed...
>
>> https://www.at91.com/viewtopic.php?t=28764
>> https://unix.stackexchange.com/questions/492611/mmc0-warning-on-sd-card-boot
>> up-of-linux (here it did go away with kernel v4.20)
>> https://e2e.ti.com/support/processors/f/791/t/263734?System-sometimes-stuck
>> -at-Waiting-for-root-device-dev-mmcblk0p2-during-boot (here it was a CD
>> hardware issue)
>
> Yes, I think many of these just indicate that something else is going wrong.
>
>> Anyways the error comes from
>>
>> https://elixir.bootlin.com/linux/latest/source/drivers/mmc/core/sd.c#L184
>>
>> and is *after* trying to read something from the SD. Either the SD card pins
>> are not configured properly or our broken DMA makes problems.
>>
>> Do you know the location where the decision to choose DMA or not-DMA mode is
>> made?
>
> In drivers/mmc/host/jz4740_mmc.c within the function jz4740_mmc_probe:
>
> ret = jz4740_mmc_acquire_dma_channels(host);
> if (ret == -EPROBE_DEFER)
> goto err_free_irq;
> host->use_dma = !ret;
Ok, I see. With our bugs in the device tree and the dma driver we always got
ret == -EPROBE_DEFER and didn't get mmc.
Now we get ret == 0 and use_dma is active.
So the solution is simple: make jz4740_mmc_acquire_dma_channels() return e.g. -EINVAL.
Or overwrite host->use_dma = false;
>
> And in the function jz4740_mmc_acquire_dma_channels:
>
> host->dma_tx = dma_request_chan(mmc_dev(host->mmc), "tx");
> ...
> host->dma_rx = dma_request_chan(mmc_dev(host->mmc), "rx");
>
> If you do not get a message saying "Failed to get dma_tx channel" or similar,
> then the channels are acquired. Indeed, the "Using DMA, 4-bit mode" confirms
> this.
>
> It's probable that the DMA transfers aren't working.
Yes, that is the most likely reason.
> I guess I could try and
> investigate this in other environments just to see if I have paid attention to
> all the relevant details. My modifications to the driver are just tentative,
> after all.
I have now tried with host->use_dma = false; and a little more precise printk()
And ...
[ 0.153001] mmc_gpio_alloc
[ 0.156092] mmc_gpiod_request_cd dev=cd idx=0 override=0 debounce=200000
[ 0.145729] jz4740-mmc 10021000.mmc: Got CD GPIO
[ 0.150598] mmc_gpiod_request_ro dev=wp idx=0 debounce=0
[ 0.156330] jz4740-mmc 10021000.mmc: Got WP GPIO
[ 0.161328] jz4740-mmc 10021000.mmc: Looking up vmmc-supply from device tree
[ 0.152146] jz4740-mmc 10021000.mmc: Looking up vqmmc-supply from device tree
[ 0.160947] ledtrig-cpu: registered to indicate activity on CPUs
[ 0.157233] usbcore: registered new interface driver usbhid
[ 0.163056] usbhid: USB HID core driver
[ 0.160166] Initializing XFRM netlink socket
[ 0.164814] NET: Registered protocol family 17
[ 0.152808] NET: Registered protocol family 15
[ 0.157766] 9pnet: Installing 9P2000 support
[ 0.162357] Key type dns_resolver registered
[ 0.166845] oprofile: using timer interrupt.
[ 0.155679] Loading compiled-in X.509 certificates
[ 0.167279] clk: Not disabling unused clocks
[ 0.171810] ALSA device list:
[ 0.157483] No soundcards found.
[ 0.163091] jz4780_of_dma_xlate
[ 0.166466] jz4780_of_dma_xlate 1
[ 0.169966] jz4780_of_dma_xlate 4
[ 0.173658] jz4780_of_dma_xlate
[ 0.159825] jz4780_of_dma_xlate 1
[ 0.163358] jz4780_of_dma_xlate 4
[ 0.168288] mmc_gpio_set_rs state=1
[ 0.160258] mmc_gpio_set_rs state=0
[ 0.163998] mmc_gpiod_request_cd_irq
[ 0.168774] mmc_gpiod_request_cd_irq irq=33
[ 0.173270] jz4740-mmc 10021000.mmc: Ingenic SD/MMC card driver registered
[ 0.163011] jz4740-mmc 10021000.mmc: Using PIO, 4-bit mode
[ 0.172691] mmc_gpio_get_cd
[ 0.175739] mmc_gpio_get_cd = 1
[ 0.163646] Waiting for root device /dev/mmcblk1p2...
[ 0.237741] mmc0: error -145 whilst initialising SD card
[ 0.238130] mmc_gpio_set_rs state=1
[ 0.238474] mmc_gpio_set_rs state=0
[ 0.258004] mmc0: card never left busy state
[ 0.262529] mmc0: error -145 whilst initialising SD card
[ 0.257936] mmc_gpio_set_rs state=1
[ 0.258569] mmc_gpio_set_rs state=0
[ 0.278007] mmc0: card never left busy state
[ 0.282527] mmc0: error -145 whilst initialising SD card
[ 0.277965] mmc_gpio_set_rs state=1
[ 0.278341] mmc_gpio_set_rs state=0
[ 0.297803] mmc0: card never left busy state
[ 0.302326] mmc0: error -145 whilst initialising SD card
^H
hello
[ 0.619546] vmmc: disabling
[ 0.984047] random: crng init done
Some observations:
1. mmc_gpio_get_cd returns 1 which seems to be ok
2. there is now an error -145 (ETIMEDOUT) - i.e. the card does not respond
3. driver tries reset - which may indicate some power problem
4. this is tried 4 times
5. ejecting and reinserting the card does not seem to trigger an irq (although I have a printk for it)
6. I can type on the console - i.e. the kernel is not stuck but just waiting for a root device
7. what is strange is the [ 0.984047]
that was not 0.9 seconds after boot boot but ca. 20
so our system timer runs at wrong speed
8. the rs-gpio is not requested since we do not define it anywhere (neither does qi_lb60)
and calls to mmc_gpio_set_rshave no effect (which likely is ok)
So we know
- communication with the card does not work even or especially w/o DMA
- CD interrupts don't work
- time scale is not real time
maybe Lubomir can find something through his JTAG?
BR and thanks,
Nikolaus
More information about the Letux-kernel
mailing list