[PATCH 4/7] at91: remove non used at91_spi.h

Detlef Vollmann dv at vollmann.ch
Sat Jul 16 10:00:58 EDT 2011


On 07/16/11 13:56, Wolfram Sang wrote:
>
>>> About the SPI driver:
>>>  From Documentation/spi/spi-summary:
>>> "At this writing, Linux has no slave side programming interface."
>>> So there's no SPI framwork that covers the slave side.
>> This what I mean use the SPI framework and add the SPI Slave support there
>
> [CCing spi-devel]
>
> If you talk about SPI slaves, be sure to have read Grant's comments in
>
> http://thread.gmane.org/gmane.linux.kernel.spi.devel/7401
>
> to see what would be needed for slave support.
I completely agree with Gran't comments here.

> Short note: Would be
> seperate subsystem, master subsystem is of limited use. I think a few
> slave-drivers would be nice to evaluate, so one can get a feeling if a
> subsystem makes sense and if so, how it could look like.
>
> Detlef, have you posted your slave driver so far?
No, and I didn't plan to do so.
Not because I don't want to publish it, if you want to look at it,
I'm happy to send the driver.
But I don't think it makes much sense to put my driver into mainline
Linux.
The reason for this is very simple: the protocol is specific for this
hardware, and the driver needs this specific protocol.
The Atmel hardware is not able to maintain information about frame
ends when running in DMA mode, so we need to put the length of the
frame to the beginning of the frame, and also need to put in some
extra information to be able to re-sync in case of transmission errors.

So this driver is very specific for this hardware, and I wrote SPI
slave drivers in the past for other hardware that were also very
specific.  I really doubt that an SPI slave framework really makes
sense.

And that's the reason why I'm keen that the hardware description
headers are available to out-of-tree drivers.

   Detlef



More information about the linux-arm-kernel mailing list