Re: [PATCH v2 4/6] mmc: host: sdhci-esdhc-imx.c: disable auto-tuning when necessary

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thank you Haibo for pointing me here from https://www.spinics.net/lists/linux-mmc/msg73270.html.

On 2021-08-18 07:16, haibo.chen@xxxxxxx wrote:
Add a method to enable/disable auto-tuning function. auto-tuning function
is conflict with sdio interrupt. For sdio device with sdio interrupt,
need to disable auto-tuning function.

I tested this patch on an imx8mm system and it made things completely unstable. I was never really able to log into the system properly and just got lots of messages similar to the following:

[   31.946640] rcu: INFO: rcu_preempt self-detected stall on CPU
[ 31.952422] rcu: 0-....: (2106 ticks this GP) idle=849/1/0x4000000000000000 softirq=902/904 fqs=743
[   31.961663]  (t=2100 jiffies g=33 q=1158)
[   31.965682] Task dump for CPU 0:
[ 31.968915] task:kworker/0:1 state:R running task stack: 0 pid: 33 ppid: 2 flags:0x0000000a
[   31.978859] Workqueue:  0x0 (pm)

While working on this I also came across https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/uSDHC-auto-tuning-and-possible-SDIO-failures/ta-p/1352855 which seems to address the same issue as your proposed patch.

That article suggests only enabling auto tuning for one data line as a workaround. I tried this method and so far it seems to have addressed the -84 errors I was seeing with SDIO communication to a WiFi module.

Some thoughts / questions:

Why does this proposed patch make my system unstable? (I was testing with a v5.16 mainline based kernel, but I did not see anything in later versions of sdhci-esdhc-imx that seemed like this should be a problem.)

Why does this patch try to disable auto tune entirely vs just setting it up for one data bit as suggested in the NXP knowledge base article?

As some other have suggested it seems like it would be nicer if the workaround could be applied automatically if the device using the SDIO interface enabled IRQs. Having to include a non standard entry in the DT for a hardware bug you may not know about or understand seems error prone. I guess maybe some device could generate an IRQ before they actually enable IRQs? In that case maybe a DT entry is required, but maybe the driver could generate a warning if IRQs are enabled without the DT entry?


Thanks,
Kevin



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux