Re: [PATCH 3/3] iio: Add PAT9125 optical tracker sensor

From: Alexandre
Date: Tue Apr 23 2019 - 04:57:48 EST

Hi Jonathan,

On 4/22/19 10:42, Jonathan Cameron wrote:
On Tue, 16 Apr 2019 14:49:19 +0200
Alexandre <amergnat@xxxxxxxxxxxx> wrote:

Hello Jonathan,

On 4/7/19 12:20, Jonathan Cameron wrote:
Hi Alexandre,

So I have no problem with this as an IIO driver, but for devices that
are somewhat 'on the edge' I always like to get a clear answer to the
question: Why not input?

I would also argue that, to actually be 'useful' we would typically need
some representation of the 'mechanicals' that are providing the motion
being measured. Looking at the datasheet this includes, rotating shafts
(side or end on), disk edges and flat surface tracking (mouse like).

That's easy enough to do with the iio in kernel consumer interface. These
are similar to when we handle analog electronic front ends.

I you can, please describe what it is being used for in your application
as that may give us somewhere to start!

+ CC Dmitry and linux-input.
I developed this driver to detect the board movement which can't be
detected by accelerometer (very slow motion). I admit this use case can
be handled by an input, and I'm agree with you, PAT9125 driver could be
an input. But, like you said, this chip is able to track different kind
of motion, and additionally have an interrupt GPIO, so using it like
input limit the driver potential. This chip is designed to work in
industrial measurement or embedded systems, and the IIO API match with
these environments, so it's the best way to exploit the entire potential
of this chip.

As I understand (from
https://www.kernel.org/doc/html/v4.12/input/event-codes.html#mice ),
mouse driver must report values when the device move. This feature
souldn't be mandatory for an optical tracker driver, specially for cases
where user prefers to use buffer or poll only when he need data.

If 1 or 2, I would suggest that you provide absolute position to
Linux. So add the value to a software counter and provide that.
32 bits should be plenty of resolution for that.
I can't provide absolute position, only relative. Do you mean using
input driver to do that ? If not, how is built the position data?
Sorry, I should have been clearer on this.
I mean absolute relative to the start point. So on startup you assume
absolute position is 0 and go from there. What I can't work out is
if the device does internal tracking, or whether each time you read
it effectively resets it's internal counters to 0 so the next measurement
is relative to the previous one.
Each time you read that reset internal counters to 0.
Silly question for you. What happens if you set the delta values to 0?
Do we get an interrupt which is effectively data ready?
If we do, you might want to think about a scheme where that is an option.
As things currently stand we have a confusing interface where changing this
threshold effects the buffered data output. That should only be the
case if this interface is for a trigger, not an event.
I'm not sure to understand your question. Is it possible to read delta_x
and delta_y = 0 in special/corner case because internal value continue
to be updated after toggled motion_detect pin (used for IRQ) until
values registers are read and then motion_detect pin is released:

* Chip move (i.e. +2 on X axis and 0 on Y axis)
* Motion_detect IRQ trigger and internal reg value is updated (i.e.
delta_x = 2 and delta_y = 0.
* GPIO IRQ handled but read_value isn't executed yet (timing reason)
* Chip move back to it origin point (i.e. -2 on X axis and 0 on Y axis)
* Motion_detect IRQ still low because it hasn't been reset by read
value and internal reg value is updated (i.e. delta_x = 0 and
delta_y = 0)
* Read_value is executed, we get delta values = 0.
Again, I was unclear. Is it possible to set the device to interrupt
every time it evaluates whether motion has occured? Not only when it
concludes that there has been some motion. That would allow the interrupt
to be used as a signal that the device has taken a measurement (data
ready signal in other sensors).

I don't know, the datasheet don't describe the role of each bit in registers and I don't found documentation which provide that. I had to do research on example code to retrieve some bits, but got nothing on motion detection pin configuration.

If it is actually not possible to report the two channels separately
then don't report them at all except via the buffered interface and
set the available scan masks so that both are on.
I found a way to keep the consistency between delta x and delta y
(without losing data). The first part is to reset a value only when user
read it (also when it's buffered). The second part is to add the new
value to the old value. With these two mechanism, X and Y will always be
consistent:

* as possible during a move.
* perfectly when move is finished.
Ah. This adding old value to a new value point is what I was getting
at (I think) with 'absolute' position above.

In industrial control for example you have absolute position by using
limit switches to set your baseline. Measurement devices are then
capable of either reporting relative position, which is the movement
since the last reading was taken, or 'absolute' position which is
referenced to some known point. It was this form of absolute position
that I was suggesting you use. If you use such a system without a
limit switch it is normally called unreference motion. You can do
it but then the 0 is where ever your device was at power on.
For some systems it doesn't actually matter (conveyor belts for
instance where the positions you care about are between things
on the belt, not the position of the belt itself).

Ok, I decided to return delta between last read/buffering to stay closer to the hardware mechanism and still coherent with "IIO_CHAN_INFO_RAW". If user want absolute position, he can make an addition of all received value in user space, and that allow him to reset/replace the initial position when he want it.

Thanks,

Jonathan


Regards,

Alexandre


Thanks for your comments,

Alexandre