Re: [PATCH v3 2/2] spi: atmel-quadspi: Add support for sama7g5 QSPI

[Alexander Dahl <ada@xxxxxxxxxxx>]

Hello,

Am Thu, Jan 09, 2025 at 05:27:58PM +0100 schrieb Alexander Dahl:
> Hello Bence,
> 
> I had another round of intense looking at the code, this time I
> focused on pm_runtime handling.  Although I just learned about the
> basic concepts, I think the ported patch has some mistakes.  I'll
> comment here, because I don't have a SAMA7G5 to test, and I'm not
> confident enough to fix the code, but I think it's worth reporting.
> See below.
> 
> Am Thu, Nov 28, 2024 at 06:43:15PM +0100 schrieb Csókás, Bence:
> > From: Tudor Ambarus <tudor.ambarus@xxxxxxxxxxxxx>
> > 

[…]

> > +	/* Release the chip-select. */
> > +	ret = atmel_qspi_reg_sync(aq);
> > +	if (ret) {
> > +		pm_runtime_mark_last_busy(&aq->pdev->dev);
> > +		pm_runtime_put_autosuspend(&aq->pdev->dev);
> > +		return ret;
> > +	}
> > +	atmel_qspi_write(QSPI_CR_LASTXFER, aq, QSPI_CR);
> > +
> > +	return atmel_qspi_wait_for_completion(aq, QSPI_SR_CSRA);
> > +}
> 
> This function atmel_qspi_sama7g5_transfer() seems to be called from
> atmel_qspi_exec_op() through ops->transfer() only.  I think the two
> lines in the error handling of atmel_qspi_reg_sync() lead to
> unbalanced calls of pm_runtime_xxx.  Compare with
> atmel_qspi_transfer() which has no calls to pm_runtime, everything is
> covered by atmel_qspi_exec_op() in this case where the pm_runtime
> calls surround ->set_cfg() and ->transfer().  Right?

This problem has been addressed in downstream kernel (linux4sam) by
Claudiu Beznea back in 2023 already:

https://github.com/linux4sam/linux-at91/commit/e59f646f516088fdab6d8213d8acda0c1063ec21

[…]

> The whole call tree from atmel_qspi_sama7g5_setup() downwards is not
> covered by pm_runtime get and put calls, although heavily doing i/o.
> Further down in atmel_qspi_setup() there's a write to QSPI_SCR which
> seems to be handled correctly.

Same for this:

https://github.com/linux4sam/linux-at91/commit/5ff0e74c1d548599fe85113e2f1817cb8a052b15

Some hunks of that seem to have made it to upstream, not sure?

Maybe Microchip should upstream those fixes, now that SAMA7G5 support
was ported to mainline?

Greets
Alex