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

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

[Wolfram Sang]

[-- Attachment #1.1: Type: text/plain, Size: 945 bytes --]


> > 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. 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?

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Detlef Vollmann]

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

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

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:00 Sat 16 Jul     , Detlef Vollmann wrote:
> 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.
So I'm sorry but this is clear I'm not going to keep the header
out-of-tree drivers are not an enough reason to keep it

Best Regards,
J.