On Tue, 2 Oct 2018 11:36:10 +0200 Boris Brezillon <boris.brezillon@xxxxxxxxxxx> wrote: > On Mon, 1 Oct 2018 22:15:28 +0000 > Chris Packham <Chris.Packham@xxxxxxxxxxxxxxxxxxx> wrote: > > > On 02/10/18 11:13, Boris Brezillon wrote: > > > On Mon, 1 Oct 2018 22:01:27 +0000 > > > Chris Packham <Chris.Packham@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > >> On 02/10/18 10:41, Boris Brezillon wrote: > > >>> On Mon, 1 Oct 2018 22:34:38 +0200 > > >>> Boris Brezillon <boris.brezillon@xxxxxxxxxxx> wrote: > > >>> > > >>>>> > > >>>>> I'd previously tried readl() based on the same hunch. No change. > > >>>>> > > >>>>> I think my snippet above might be misleading. While a delay between > > >>>>> readl_relaxed() and the if should not change the outcome, this is also a > > >>>>> delay between marvell_nfc_enable_int() and marvell_nfc_disable_int() > > >>>>> which is probably more significant. Sure enough if I move the delay to > > >>>>> just before the marvell_nfc_disable_int() the error is not seen. > > >>>> > > >>>> AFAICT, your timeout always happens when waiting for RDREQ, not RDYM. > > >>>> So maybe disabling MRDY too early has a side-effect on the RDREQ event. > > >>> > > >>> Can you try with this patch [1]? It should ensure that NDSR_RDY bits > > >>> are cleared before starting an operation. > > >>> > > >>> [1]http://code.bulix.org/lgs30c-468205 > > >>> > > >> > > >> No luck. I applied that on top of Daniel's and got the same result. > > >> > > >> One thing that does look promising is the following modification of > > >> Daniel's patch[1]. Which moves the RDY check to before where the > > >> interrupts are enabled. > > > > > > Except we still don't know why this is happening, and I'm not sure I > > > want to take a fix without understanding why it does fix the problem. > > > > Agreed. My only guess is that there is some interrupt that is missed in > > the short period they are disabled when calling complete(). > > Disabling interrupts when taking a spinlock means masking the IRQ line, > but the interrupt still exists and should be there when linux unmasks > the IRQ line. I don't think this is the problem we're chasing. > > Looks more like something Please ignore this email, I inadvertently hit the send button on a draft I started yesterday :-)
