Re: [PATCH 3/3] spi: cadence-xspi: add ACMD mode support

["Nuno Sá" <nuno.sa@analog.com>]

On Thu, Oct 29, 2026 at 04:51:32PM +0000, Mark Brown wrote:
> > So far every operation goes through STIG mode, where the CPU builds
> > each command and drains the data. The controller also has an auto
> > command (ACMD) mode where it runs a whole read sequence on its own and,
> > with the internal DMA, writes the data straight to memory.
> 
> > +static int cdns_xspi_set_work_mode(struct cdns_xspi_dev *cdns_xspi, int mode)
> > +{
> > +	int ret;
> > +
> > +	if (cdns_xspi->cur_work_mode == mode)
> > +		return 0;
> 
> We need some suspend/resume handling to invalidate the configuration
> when the IP power goes so we set everything up again.  I'm not seeing
> anything here.

Yeah, I did saw sashiko complain (and my local LLM also raised it
actually) but I do wonder how can that happen? So we need to assume that
in suspend we might lose power (maybe because it's regulator powers down)
and need to do redo all the important initialization bits?

> 
> > @@ -677,6 +893,9 @@ static int cdns_xspi_adjust_mem_op_size(struct spi_mem *mem, struct spi_mem_op *
> >  	struct cdns_xspi_dev *cdns_xspi =
> >  		spi_controller_get_devdata(mem->spi->controller);
> >  
> > +	if (cdns_xspi_acmd_can_read(cdns_xspi, op))
> > +		return 0;
> 
> That function has a minimum size but not a maximum size...
> 
> > +
> >  	op->data.nbytes = clamp_val(op->data.nbytes, 0, cdns_xspi->sdmasize);
> 
> ...which we have here?

For ACMD, in theory we can just configure UINT32_MAX on the register so
not sure if it makes sense to clamp to that?

Unrelated question,

Conor is pushing against the new bindings and that it should be inferred
from the compatible. I tested this on [1] which is not an upstream
platform so I wonder if it's ok to add support for the complete
integration even if the SoC is not upstream?

Long term plan is definitely to upstream it but we do have a lot of debt that
needs clean up.

[1]: https://www.analog.com/en/products/adsp-sc846.html

- Nuno Sá
> 
> -- 
> Mark Brown <broonie@kernel.org>