Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752201AbbEDPZq (ORCPT ); Mon, 4 May 2015 11:25:46 -0400 Received: from mga14.intel.com ([192.55.52.115]:42745 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750970AbbEDPZi (ORCPT ); Mon, 4 May 2015 11:25:38 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,366,1427785200"; d="scan'208";a="723352045" Message-ID: <1430753037.5506.18.camel@spandruv-DESK3.jf.intel.com> Subject: Re: [RFC PATCH 3/3] iio: derive the mounting matrix from ACPI _PLD objects From: Srinivas Pandruvada To: Octavian Purdila Cc: sathyanarayanan.kuppuswamy@linux.intel.com, Jonathan Cameron , Lars-Peter Clausen , Peter Meerwald , Robert Moore , Rafael J Wysocki , Len Brown , linux-api@vger.kernel.org, lkml , "linux-iio@vger.kernel.org" , "linux-acpi@vger.kernel.org" Date: Mon, 04 May 2015 08:23:57 -0700 In-Reply-To: References: <1430146908-27919-1-git-send-email-octavian.purdila@intel.com> <1430146908-27919-4-git-send-email-octavian.purdila@intel.com> <64714.10.254.87.235.1430149342.squirrel@linux.intel.com> <553EB0B3.5000707@linux.intel.com> <5546C72E.2040101@linux.intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3495 Lines: 91 On Mon, 2015-05-04 at 11:21 +0300, Octavian Purdila wrote: > On Mon, May 4, 2015 at 4:11 AM, Sathyanarayanan Kuppuswamy > wrote: > > Hi Octavian, > > > > On 04/27/2015 07:23 PM, Octavian Purdila wrote: > >> > >> On Tue, Apr 28, 2015 at 12:57 AM, sathyanarayanan kuppuswamy > >> wrote: > >>> > >>> Hi > >>> > >>> On 04/27/2015 08:54 AM, Octavian Purdila wrote: > >>>> > >>>> On Mon, Apr 27, 2015 at 6:42 PM, Kuppuswamy Sathyanarayanan > >>>> 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. > > AFAICS the ACPI _PLD information is not (yet) exported to userspace. This patch: > > http://marc.info/?t=140795040700003&r=1&w=2 > > does not seem to be merged upstream. So there is no existing ABI to > derive from :) I don't think there is any major objection to this patch. The author should just try and see if he can replace to device_* calls. Thanks, Srinivas > > >> > >> > >>> 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 ? > > > > - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/