> On 31.03.2015, at 05:28, Stephen Warren <swar...@wwwdotorg.org> wrote:
>> +    /* check if we shall run in polling mode */
>> +    xfer_time_us = tfr->len * 9 * 1000000 / spi_used_hz;
> 
> Why 9 not 8; presumably thats bits per byte, and IIRC SPI doesn't have
> anything like I2C's ack bit per byte?

Well - the bcm2835 make a 1 cycle wait after each byte transferred.
Hence 9 bit actual length we need to account for.

Actually on top of that there are 3 more cycles when bringing the SPI
hardware active (at least with native CS) - but these are minimal
offsets.

Martin


--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to