Re: [PATCH] spi/bcm63xx: fix multi transfer messages

[Florian Fainelli <florian-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>]

On Wednesday 28 November 2012 09:26:28 Mark Brown wrote:
> On Tue, Nov 27, 2012 at 09:41:43PM +0100, Florian Fainelli wrote:
> > Le lundi 26 novembre 2012 16:33:21, Mark Brown a écrit :
> > > On Mon, Nov 26, 2012 at 04:23:18PM +0100, Jonas Gorski wrote:
> 
> > > > having read/written that amount CS will be deasserted. There is no
> > > > possiblity of refilling the buffers before it deasserts CS. And this
> > > > usually leads to an aborted command if the device expected more data.
> 
> > > What, wait a minute.  Are you saying that this hardware can't do
> > > transfers of more than a single FIFO at all?  That's appaulingly crap,
> > > we need some way for client drivers to tell they're dealing with such
> > > controllers.  Things like regmap really need to know so they can provide
> > > fallbacks.
> 
> > No, the hardware cannot do transfers which are wider than a FIFO size, we 
> > could obviously workaround that by allocating a bounce buffer and re-fill the 
> > FIFO when the transfer is wider. You can call that crap, but that is just 
> > hardware out there now, so we need to cope with that.
> 
> Sorry, I'm confused now.  Your first comment above sounded like
> refilling the FIFO wasn't an option?

I realized this right after writing it, this would be a workaround, not a real
solution, because on the wire, this would still appear as a different SPI
transfer. Whenever your transfer spans accross a hardware FIFO size, you have
to generate as many distinct "hardware" SPI transfers at the controller level.

> 
> > If you meant something like allocating a kernel buffer and linearize the 
> > transfer list buffers there, I see no point in doing this considering the 
> > limitations mentionned before, we would end up with copying the entire kernel 
> > buffer back to the FIFO hardware buffer. The only advantage being that we do not 
> > have the FIFO size limitation.
> 
> That seems like a pretty big advantage to be honest - like I say, it's
> very difficult to run generic code on top of SPI controllers with random
> properties especially since they're non-discoverable.
> 
> > There are quite some quirky SPI controllers supported, yet that one is still 
> > pretty straight forward to be worked around.
> 
> Well, what you're saying is that it's just not possible to work around
> it at all.

Correct, the best we can do is add some kind of flag and tell the SPI subsystem
we don't support physical transfers more than N sized.
--
Florian


------------------------------------------------------------------------------
Keep yourself connected to Go Parallel: 
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general