Hi Shimoda-san, > I talked Saito-san about this patch locally and we can drop these lines > because this driver can detect data timeout in Access End interrupt > and the driver didn't enable error related interrupts like CRCFAIL. I see. I already wondered why the BSP patch 6f7519552fbed1474561ff423acb967eb03994e3 did not have these lines. > The following commit [1] is a BSP local patch though, > we need to set -EILSEQ to retune a card for R-Car Gen3 [2] > by MMC core driver [3]. So, if there is a non-removable eMMC or a SD card inserted, then we need to EILSEQ to enforce a retune. Otherwise it is a data timeout. Is my understanding correct? I wonder, though, if "Gen3" is a complete description? There are SDHI instances on Gen2 which can also do SDR104. Won't they need the same treatment? Then we could say that every SDHI which has an SCC will need this treatment. > - The patch also change the tmio_mmc_cmd_irq() when CMDTIMEOUT happens for R-Car Gen3. > But, for upstream, we should make a separated patch for it. I am sorry. I don't fully understand. Why does the change to tmio_mmc_cmd_irq() need a seperate patch? > - These "for R-Car Gen3" means I'm thinking we need additional condition: > 1) to set -EILSRQ or -ETIMEDOUT for R-Car Gen3 > 2) to set -ETIMEDOUT anyway for other SoCs. > # These are complex conditions a little though... Well, from what I understood this sounds not too hard. Let's hope I just got it correctly :) However, there is something in this patch which makes mmc_test #15 work, though. We still want this in this series, or do you think it is better to move it to a seperate series? Kind regards, Wolfram
Attachment:
signature.asc
Description: PGP signature
