On 04/01/24 20:34:09, Adrian Hunter wrote: > On 3/01/24 11:20, Jorge Ramirez-Ortiz, Foundries wrote: > > On 03/01/24 10:03:38, Adrian Hunter wrote: > >> Thanks for doing that! That seems to explain the mystery. > >> > >> You could hack the test to get an idea of how many successful > >> iterations there are before getting an error. > >> > >> For SDHCI, one difference between tuning and re-tuning is the > >> setting of bit-7 "Sampling Clock Select" of "Host Control 2 Register". > >> It is initially 0 and then set to 1 after the successful tuning. > >> Essentially, leaving it set to 1 is meant to speed up the re-tuning. > >> You could try setting it to zero instead, and see if that helps. > >> e.g. > >> > >> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c > >> index c79f73459915..714d8cc39709 100644 > >> --- a/drivers/mmc/host/sdhci.c > >> +++ b/drivers/mmc/host/sdhci.c > >> @@ -2732,6 +2732,7 @@ void sdhci_start_tuning(struct sdhci_host *host) > >> ctrl |= SDHCI_CTRL_EXEC_TUNING; > >> if (host->quirks2 & SDHCI_QUIRK2_TUNING_WORK_AROUND) > >> ctrl |= SDHCI_CTRL_TUNED_CLK; > >> + ctrl &= ~SDHCI_CTRL_TUNED_CLK; > >> sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2); > >> > >> /* > >> > > > > > > Yes with that change, the re-tuning reliability test does pass. > > > > root@uz3cg-dwg-sec:/sys/kernel/debug/mmc0# echo 52 > /sys/kernel/debug/mmc0/mmc0\:0001/test > > [ 237.833585] mmc0: Starting tests of card mmc0:0001... > > [ 237.838759] mmc0: Test case 52. Re-tuning reliability... > > [ 267.845403] mmc0: Result: OK > > [ 267.848365] mmc0: Tests completed. > > > > > > Unfortunately I still see the error when looping on RPMB reads. > > > > For instance with this test script > > $ while true; do rpmb_read m4hash; usleep 300; done > > > > I can see the error triggering on the serial port after a minute or so. > > [ 151.682907] sdhci-arasan ff160000.mmc: __mmc_blk_ioctl_cmd: data error -84 > > > > Causing OP-TEE to panic since the RPMB read returns an error > > E/TC:? 0 > > E/TC:? 0 TA panicked with code 0xffff0000 > > E/LD: Status of TA 22250a54-0bf1-48fe-8002-7b20f1c9c9b1 > > E/LD: arch: aarch64 > > [...] > > > > if anything else springs to your mind I am happy to test of course - there are > > so many tunnables in this subsystem that experience is this area has exponential > > value (and I dont have much). > > > > Would it make sense if re-tuning requests are rejected unless a minimum number > > of jiffies have passed? should I try that as a change? > > > > or maybe delay a bit longer the RPMB access after a retune request? > > It seems re-tuning is not working properly, so ideally the > SoC vendor / driver implementer would provide a solution. Makes sense to me too. I am copying Michal on the DL. > > There is also mmc_doing_retune() which could be used to skip > tuning execution entirely in the case of re-tuning. >
