Mark Brown wrote:

On Thu, Jun 06, 2013 at 12:00:54PM +0100, Nick Dyer wrote:

quoted

Mark Brown wrote:

quoted

quoted

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.

quoted

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.

quoted

quoted

Without seeing the address thing it's hard to comment.

quoted

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.

quoted

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.