Well, why do this?if (!spi->max_speed_hz)Suggest not to hardcode values here.
spi->max_speed_hz = 500 * 1000;
/* nsecs = max(50, (clock period)/2), be optimistic */
cs->nsecs = (1000000000/2) / (spi->max_speed_hz);
if (cs->nsecs < 50)
cs->nsecs = 50;
I suppose it'd make sense to just fail if max_speed_hz is invalid,
and if there's some board that an bitbang at over 10MHz we should
avoid getting in its way.
Ok./* protocol tweaks before next transfer */Suggest nsecs here as well.
if (t->delay_usecs)
udelay(t->delay_usecs);
The relevant chip delays seem to be specified in usecs ... I don't
like using nsecs for the clock timings, but without doing that it'd
be impractical to define rates at the levels the hardware actually
uses. There are still some "nsec" leakages out of the real-bitbang
code up to the next level, fixable over time.
Agreed :)
/* FIXME if bitbang->use_dma, dma_map_single()please *please* *_please_*!!! don't do it! :)
* before the transfer, and dma_unmap_single()
* afterwards, for either or both buffers...
*/
Let the controller driver do it *only in case it's not working in PIO!*
OK. That'd be more work for the controller driver, but you're
right that a lot of the drivers using these utilities are rather
likely to be PIO-oriented. If they want DMA speedups, they can
do the mappings themselves (in cases where the driver didn't
do them already).
Oh sorry, of course I meant "I just don't feel comfortable..."
Another one: I just feel comfortabel with using 'bitbang' term for the variety of SPI stuff which this library suits.
You _do_ feel comfortable with it? I actually feel a bit odd, since
only one of the three driver types is really bitbanging. And in fact
it still bothers me that the other two tie down a task, but that's
the price for reusing common infrastructure.