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.
Attachment:
signature.asc
Description: Digital signature
