On Wed, 17 Jul 2019 at 14:36, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > On Wed, 17 Jul 2019 at 12:16, Jean Nicolas GRAUX > <jean-nicolas.graux@xxxxxx> wrote: > > > > Hello Ulf, all, > > > > For testing purpose, I cherry-picked your patch on top of a 4.19.30 basis. > > (I apologize as it's a bit old. I miss time to do a rebase on current > > linux-next right now.) > > No worries about the old kernel, for this change, I think it should be > suufient good as base. > > > > > Unfortunately, I got a kernel crash applying it :( > > Huh. > > Is it crashing because it fails to mount the rootfs on the SD/MMC card? > > > > > As you may know, ST sta1295/sta1385 SoC embeds the same pl08x variant > > than one in U8500. > > So It looks like double-checking again mmci status to make sure busy > > flag is still set > > just before proceeding for busy end is required in our case. > > Yeah, actually I have a u8500 on my desk now, so I will also test the > patch to see what goes on. Didn't have the time to do it earlier. > > My guess is that, at the point when we received the IRQ for a command > that has been sent, and then reading the MMCISTATUS register in > mmci_irq(), the card has not yet started to signal busy on DAT1 and > hence the busy status bit isn't set yet. This leads to that we will > never enable the busy end mask, but just completing the request > directly. > > Anyway, let me check and see if I can confirm it. Problem confirmed. Moreover, even before my changes it looks like the similar problem is there. In other words, even if we re-read the status register a few cycles later in mmci_cmd_irq() there is still a chance that we end up to by-pass the busy detection, because the card haven't yet started to signal busy. Just during boot of ux500, I found this to occur three times, but luckily the card detection works anyway. [...] I am working on fix, let's see what I can come up with. Likely to be posted tomorrow. Kind regards Uffe
