On Sun, Feb 20, 2011 at 04:28:46PM -0800, Colin Cross wrote: > On Sun, Feb 20, 2011 at 3:57 PM, Colin Cross <ccross@xxxxxxxxxxx> wrote: > > On Sun, Feb 20, 2011 at 3:38 PM, Ben Dooks <ben-i2c@xxxxxxxxx> wrote: > > <snip> > > > >>> > you know, there's a readsl() function that does this. > >>> I think readsl can't handle the possibly unaligned buf pointer. > >> > >> it does. see arch/arm/lib/io-writesl.S for proof. > > You're right, I traced the wrong definition of readsl/writesl > > > >>> > this whole function gives me the creeps, is there any reason why > >>> > we can't use the readsl or similar functions for this? > >>> Same here - readsl can't handle the alignment requirements, readsb > >>> can't handle the required 32 bit register read, and the bytes in the > >>> same word but after the end buf may not be part of buf, so byte writes > >>> to buf are required. > >> > >> You'll find it can, too. arch/arm/lib/io-readsl.S. > > I still think readsl doesn't work here. It may need to read 7 bytes, > > requiring 2 calls to readl, but 1 word write and 3 byte writes to buf. > > Using readsl for the whole buffer would overwrite the 8th byte. I > > can use readsl for the main loop, but I will still need to write the > > last 1-3 bytes separately. I could use readl and memcpy to do the > > last writes. > > Actually, the same problem applies to writesl. If the buffer is not > aligned, reading an entire word to get the partial word at the end of > the buffer may cross a page boundary and fault. I'll have to use > writesl for the whole words and then handle the last partial word with > memcpy and writel. Hmm, that's an interesting one, however I suspect this is something that will never happen as the kernel over-allocates (rounds up) buffers when allocating memory blocks. -- Ben Dooks, ben@xxxxxxxxx, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html