Mark Brown wrote: > On Thu, Jun 06, 2013 at 12:00:54PM +0100, Nick Dyer wrote: >> Mark Brown wrote: > >>> The retries can just be done further up the stack? All regmap is doing >>> with I/O errors is punting them straight back up to the caller so the >>> caller can retry just as well using regmap as it can using the raw I/O >>> protocol. > >> It would have to be put into users of the debugfs interface as well. >> There's quite tight timing required to make it work properly (see patch >> [40/53]). > > This is yet another reason for implementing the protocol properly > instead of trying to bodge around the kernel. It really seems like > the biggest problem here is the decision to try to bodge the entire > thing into userspace with no kernel support. With the interface I am proposing it is handled properly, in the kernel driver. >From an Atmel perspective, Linux is just another platform and we want to use our existing investment in tools and documentation to manage & debug chips embedded in Linux based devices. So providing a bridge using a relatively simple API between the tools and the kernel driver is the correct decision. I can't provide a 3D graph of live touch data in the kernel driver, for instance. >>> Without seeing the address thing it's hard to comment. > >> Patch [36/53]. If the T5 message processor is from address 100-110, you can >> do a read of 50 bytes starting at address 100, and it will return 10 >> messages, but anything in regmap that tries to do bounds checking would get >> confused, I think. > > That's just not going to be supported, sorry. You can implement custom > locks and access the device directly where you need to do stuff like > that while still using regmap for actual registers though. OK, fair enough. >> Also, we would like to implement address pointer caching. maXTouch allows >> us to skip the address part of the i2c transaction if the address pointer >> in the chip hasn't changed. This speeds up interrupt handler slightly. But >> it requires extra housekeeping at a low level to remember what the address >> pointer was on the previous transaction to know whether to send it or not. > > That sounded like what you were talking about, it's pretty common and is > sane enough for reads. The address pointer is shared between reads and writes on maXTouch, but I guess that's not a huge problem. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
