[PATCH] SPI: bcm2835: move to the transfer_one driver model

Mark Brown broonie at kernel.org
Thu Mar 26 10:35:11 PDT 2015


On Thu, Mar 26, 2015 at 11:08:36AM +0100, Martin Sperl wrote:
> This also allows for GPIO-CS to get used removing the limitation of
> 2/3 SPI devises on the SPI bus.

This doesn't apply against current code, please check and resend.  As
previously mentioned please use subject lines matching the style for the
subsystem.  A few other things below but it's basically all good.

> So the question is if we should depreciate native chip-selects for this
> driver with one of those future improvements listed below.

Given that this driver is only going to be used with a single SoC (or
perhaps a very limited set of SoCs, I don't know if it's the same driver
in the Pi 2) even if the DT specifies a hardware chip select we should
be able to look up which pin that's brought out to and put it into GPIO
mode if that's the most sensible thing for the driver.

> * multiple spi_transfers handled in interrupt alone without waking up the
>   worker-thread (for some transfers) to reduce context switching
>   overheads and the corresponding latencies.

This in particular is something the framework should have: it's
generally useful and we should be able to do it with either a new
transfer_irq_safe() (or something) operation or a refactoring of the
existing one.

> +	/* error in the case of native CS requested with CS-id > 2 */
> +	dev_err(&spi->dev,
> +		"setup: only three native chip-selects are supported\n"
> +		);

The indentation here is weird - at least the last ); should be with the
string.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20150326/c0594d10/attachment.sig>


More information about the linux-rpi-kernel mailing list