Re: [RFC PATCH 3/3] iio: derive the mounting matrix from ACPI _PLD objects

On 28/04/15 03:23, Octavian Purdila wrote:

On Tue, Apr 28, 2015 at 12:57 AM, sathyanarayanan kuppuswamy
[off-list ref] wrote:

quoted

Hi

On 04/27/2015 08:54 AM, Octavian Purdila wrote:

quoted

On Mon, Apr 27, 2015 at 6:42 PM, Kuppuswamy Sathyanarayanan
[off-list ref] wrote:

quoted

Since Acpi framework already exports this info to user space, Why not do
this derivation in user space code ? Why do we need new ABI, if the same
can be derived from existing one.

The ABI was added in the previous patch so that we can present the
sensor orientation information to userspace even in the case of device
tree.

If the main reason for implementing a new ABI is to support DT platforms,
Why not implement a version of _PLD for device tree ? Don't you think it
would be much better than adding a new ABI to export redundant information ?

IMO the mounting matrix is more consistent with the IIO ABIs. Although
I have no issue with repicating _PLD for device tree if people agree
that it is better.

quoted

Also the location information of the device is not just specific to iio
drivers. You should consider that we would have similar requirements for
devices implemented as input or platform drivers.

The upstream standard for those sensors where the orientation matters
(accelerometer, gyro, compass) is IIO.

It's probably worth pull Dmitry in on this conversation as well (and maybe
the input list). cc'd.

For reference of those who haven't seen this before.  The question here is about
exposing the sensor mounting matrix ( orientation of the sensor frame of reference
relative to some 'magic' orientation - probably the PCB )

Note I'd also throw in here that I'd argue for a combined R T matrix
e.g. [R T] so as to cover cases where we care about the position as well as the
orientation relative to some reference point.  A class case in point would
be rotation measurement from offset accelerometers.

Could go with a full projective geometry matrix, but probably better to keep it
in some base scale e.g.
[R   T]
[000 1]
but not bother exporting the 000 1 as it'll always be the same.


Note I've written this email whilst without net access (free wifi at
Stansted airport is rubbish!) so haven't checked out the existing ACPI ABI.
Will try and remember to do this when I get a moment with working internet.

Jonathan  

Granted, there are other device types for which the orientation
information may be useful (e.g. camera). However the actual
interpretation and action to be taken is different for each subsystem
(e.g. in the camera case do the correction via V4L2_CID_HFLIP /
V4L2_CID_VFLIP) so I think it is better to expose it at the subsystem
level in a way consistent with the subsystem's ABIs.