Re: [PATCH V2 2/2] spi/bcm63xx: work around inability to keep CS up

[Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>]

On Tue, 5 Feb 2013 16:00:04 +0100, Jonas Gorski <jogo-p3rKhJxN3npAfugRpC6u6w@public.gmane.org> wrote:
> On Tue, 05 Feb 2013 14:35:30 +0000
> Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> 
> > On Sun,  3 Feb 2013 15:15:13 +0100, Jonas Gorski <jogo-p3rKhJxN3npAfugRpC6u6w@public.gmane.org> wrote:
> > > This SPI controller does not support keeping CS asserted after sending
> > > a transfer.
> > > Since messages expected on this SPI controller are rather short, we can
> > > work around it for normal use cases by sending all transfers at once in
> > > a big full duplex stream.
> > > 
> > > This means that we cannot change the speed between transfers if they
> > > require CS to be kept asserted, but these would have been rejected
> > > before anyway because of the inability of keeping CS asserted.
> > > 
> > > Signed-off-by: Jonas Gorski <jogo-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
> > 
> > Are you checking the state of transfer->cs_change when merging
> > transfers? If cs_change is set, then the transfers cannot be merged.
> 
> Yes, I do; I "flush" on each cs_change and after the last transfer:

Okay, applied. Thanks.

g.


------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb