Jerome Brunet <jbrunet@xxxxxxxxxxxx> writes: > The goal of the patchset was mainly to address the following warning: > > WARNING: CPU: 0 PID: 0 at /usr/src/kernel/drivers/mmc/host/meson-gx-mmc.c:1025 meson_mmc_irq+0xc0/0x1e0 > Modules linked in: crc32_ce crct10dif_ce ipv6 overlay > CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.19.1 #1 > Hardware name: Some A113 Board (DT) > pstate: 40000085 (nZcv daIf -PAN -UAO) > pc : meson_mmc_irq+0xc0/0x1e0 > lr : __handle_irq_event_percpu+0x70/0x180 > sp : ffff000008003980 > x29: ffff000008003980 x28: 0000000000000000 > [...] > x1 : ffff80001a71bd40 x0 : 0000000000000000 > Call trace: > meson_mmc_irq+0xc0/0x1e0 > __handle_irq_event_percpu+0x70/0x180 > handle_irq_event_percpu+0x34/0x88 > handle_irq_event+0x48/0x78 > handle_fasteoi_irq+0xa0/0x180 > generic_handle_irq+0x24/0x38 > __handle_domain_irq+0x5c/0xb8 > gic_handle_irq+0x58/0xa8 > > This happens when using the chained descriptor mode. If there is an > error, we call mmc_request_done(), loosing any reference to the cmd. It > turns out that the chained descriptor does really stops when we do so, at I think you mean... s/does really stops/does not really stop/ > least not completly. Most of the time, it can be seen with this harmless > warning because the descriptor will raise another unexpected IRQ. On rare > occasion, it will completly break the MMC. > > This is mostly adressed by patch #1. > With this fixed, I took (yet) another look at the ultra-high speed modes > and the tuning. > > I came up with new settings in patch 3 and 4. I've tested them on eMMC, > sdcard and sdio on the following platforms: > * gxbb p200 > * gxl p230, libretech (eMMC only), kvim. > * axg s400 > > So far, these new settings seems to be working great but I think it > would be nice if others could test this and provide their feedback. > This why patch 3 and 4 are RFT tagged. For broader testing, I've added this to my v4.21/testing branch, which is included in my integ branch which gets a spin through kernelCI. Kevin
