On Tue, Jun 11, 2013 at 11:39:37AM +0100, Nick Dyer wrote:

Mark Brown wrote:

quoted

I don't think you're using the usual definition of "register map" here.
You seem to be switching between talking about this object model the
device has and device registers - perhaps the objects are also registers
sometimes?

Yes, in Atmel Object Protocol "instances" of "objects" do each have an
assigned register range (they do also correspond to modules of code in the
firmware).

OK, so you're talking about the objects which happen to be implemented
in terms of the register map here.  I think this is confusing to me
because you are moving between the abstraction levels.

Essentially, the device is designed (and tested) on the assumption that
touch processing can be going on whilst various parameters are changed in a
live fashion. If poking around in the register map caused it to lock up or
behave oddly then that would be considered a firmware bug. In general it
will fail gracefully - for example if you write a configuration that is
invalid it will just stop and emit a CFGERR message.

That's not really it, it's the fact that this is being done with no
abstraction - exposing the entire device register map directly to
application layer so the application can totally ignore what's going on
in the kernel doesn't seem like awesome design.

The absolute worst thing that I can think of is that you can try to beat
the interrupt handler to reading the "message processor" registers, which
would possibly leave touches stuck on screen. But even that operation is
useful in debugging interrupt line issues.

Well, there's also the potential issues with standard application layer
code either not being able to do things that the hardware supports or
getting into a fight with the magic custom stuff.

quoted

Won't the driver end up getting into a fight with the magic userspace
stuff if the driver has no idea what the magic userspace is doing?  How
would suspend and resume work?

On suspend the driver puts chip into "deep sleep" where touch acquisition
is halted and minimal power consumed. But it will still come out of its
sleep state temporarily to service I2C comms if necessary (although one
particular family requires that I2C retry for this case).

So these errors are just part of waking the chip up - in that case
shouldn't the driver be waking the chip up automatically?