[PATCH 2/2] spi: rockchip: add an atomic transfer function

Mark Brown broonie at kernel.org
Mon Nov 9 14:02:46 PST 2026


> Rockchip SPI controllers are often used to handle SPI connected PMICs that
> also handle system power-off events, like the RK806.

> +static int rockchip_spi_transfer_atomic(struct spi_device *spi, struct spi_message *msg)
> +{
> +	struct spi_controller *ctlr = spi->controller;
> +	struct rockchip_spi *rs = spi_controller_get_devdata(ctlr);
> +	bool cs_en = (spi->mode & SPI_CS_HIGH) ? 1 : 0;
> +	struct spi_transfer *xfer;
> +	int ret = 0;
> +
> +	pm_runtime_get_sync(rs->dev);

The check in spi_in_atomic_sync_mode() is true for SYSTEM_RESTART and
SYSTEM_SUSPEND which would get rather messy if something ends up with a
device that tries to do something in there.  Not sure if that's worth
worrying about or not.

> +	rockchip_spi_set_cs(spi, cs_en);

This won't DTRT with GPIO chip selects, that's normally handled by the
core.

> +		while (rs->tx_left || rs->rx_left) {
> +			u32 status = readl_relaxed(rs->regs + ROCKCHIP_SPI_SR);
> +
> +			if (rs->tx_left && !(status & SR_TF_FULL))
> +				rockchip_spi_pio_writer(rs);
> +
> +			if (rs->rx_left && !(status & SR_RF_EMPTY))
> +				rockchip_spi_pio_reader(rs);
> +		}
> +
> +		wait_for_tx_idle(rs, false);

This uses jiffies which don't advance in poweroff, and there's no
overall timeout here.

> +		if (xfer->cs_change && !list_is_last(&xfer->transfer_list, &msg->transfers)) {
> +			rockchip_spi_set_cs(spi, !cs_en);
> +			ndelay(10 * NSEC_PER_USEC);

udelay().

> +static int rockchip_spi_power_off(struct sys_off_data *data)
> +{
> +	struct rockchip_spi *rs = data->cb_data;
> +
> +	/* enable controller for possible calls from shutdown handlers */
> +	return pm_runtime_get_sync(rs->dev);

Would it not be safer to just eat the error here rather than refuse
poweroff?  Also pm_runtime_resume_and_get() is the more modern thing.

> +	ctlr->transfer_atomic = rockchip_spi_transfer_atomic;

The driver supports target mode as well, probably best to only register
this for host mode.

-- 
Mark Brown <broonie at kernel.org>



More information about the Linux-rockchip mailing list