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 [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
