On Thursday 05 February 2009 03:28:17 Guennadi Liakhovetski wrote: > On Wed, 4 Feb 2009, Mike Frysinger wrote: > > if the smallest increment you can do is 8bits, then you should be > > rejecting anything that isnt a multiple of it rather than holding the > > user's hand. as for the assumption that "more than 32bits means do 32bit > > transfers", that sounds plain wrong to me. u-boot should do exactly as > > instructed and nothing more/less. so if the user tries to send 40bits, > > that better be 40bits and not 64bits. > > That's what my patch would do, but it is actually unclear to me what you > should do for 40 bits? Do you want to send 32 + 8 or 20 + 20 or?.. In > fact, I would reject if (bitlen > 32 && (bitlen & 31)). But, for example, > mpc8xxx_spi.c also first sends data in 32-bit chunks, and then the rest. > But I just noticed there is another bug in my driver, the bit-length in > the control register is set wrongly if (bitlen > 32). Also, the function > can be simplified by putting the 32-bit loop bofore residue transfer. I'll > change both in the next revision.
sending out in 32bit chunks and then sending out the remainder with the correct size sounds like the most efficient. there is no requirement in terms of how bits get grouped as any sane SPI device should operate properly as data is only read when the clock is asserted, and the clock is only asserted when actual bits are being shifted. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
