On Saturday 16 February 2008, Atsushi Nemoto wrote: > Hi. Is it legal to use zero for 'len' field of struct spi_transfer? > I mean, len=0, tx_buf=rx_buf=NULL, delay_usecs!=0.
Yes that should work ... it's uncommon, but not illegal. Some controller drivers may even handle that right! If the delay were zero and cs_change didn't indicate a need to briefly deselect the chip, it might make sense to reject such a NOP transfer. But that's not the case you identify. > Some SPI devices need slightly long delay before first CLK edge after > CS assertion. For future reference ... could you identify a few such devices, and say what "long" is relative to the clock period? Some folk have just slowed down the clock in such cases, but that's rather sub-optimal. > To achieve this, I think inserting using a zero length > transfer before real transfers. But it seems some drivers do not > handle this case properly. Feel free to submit patches fixing those bugs. > Is this driver's bug, or we need additional delay field in struct > spi_device for such case? I'd like to avoid new parameters to cover case that can already be expressed in the programming interface. Cases that can't be expressed ... different issue. I suspect any patches updating timing parameters should use nanoseconds not microseconds, fwiw. - Dave ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
