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

[Sathyanarayanan Kuppuswamy]

Hi Octavian,

On 04/27/2015 07:23 PM, Octavian Purdila wrote:
> On Tue, Apr 28, 2015 at 12:57 AM, sathyanarayanan kuppuswamy
> <sathyanarayanan.kuppuswamy@xxxxxxxxxxxxxxx> wrote:
> > Hi
> >
> > On 04/27/2015 08:54 AM, Octavian Purdila wrote:
> > > On Mon, Apr 27, 2015 at 6:42 PM, Kuppuswamy Sathyanarayanan
> > > <sathyanarayanan.kuppuswamy@xxxxxxxxxxxxxxx> wrote:
> > > > 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.
Since your main issue is, device tree lacking ABI to specify location
information, you should consider fixing it there. Let's wait for others
comment on this.

If you think mounting matrix provides more information than what is 
supported
by _PLD,  then we should consider implementing another ABI. AFAIK, that 
is not
the case here.

Adding adding a new ABI to represent the information that can be derived
from existing ABI does not seem to be useful.
> > 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.
>
> 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.
I agree that location information is used differently at different
sub systems. But my question is why we need  a new ABI ?

Why not handle it in user space ?

--
--
Sathyanarayanan KN
Android Kernel Developer

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/