Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752911AbbFFUIx (ORCPT ); Sat, 6 Jun 2015 16:08:53 -0400 Received: from saturn.retrosnub.co.uk ([178.18.118.26]:42358 "EHLO saturn.retrosnub.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932211AbbFFUIn (ORCPT ); Sat, 6 Jun 2015 16:08:43 -0400 Message-ID: <5573615A.7010901@kernel.org> Date: Sat, 06 Jun 2015 22:08:42 +0100 From: Jonathan Cameron User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Daniel Baluta CC: Peter Meerwald , Hartmut Knaack , Lars-Peter Clausen , Linux Kernel Mailing List , "linux-iio@vger.kernel.org" , Vlad Dogaru , Tiberiu Breana Subject: Re: [PATCH v2] iio: light: Add support for ROHM RPR0521 sensor References: <1432810354-24745-1-git-send-email-daniel.baluta@intel.com>

In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2882 Lines: 85 On 06/03/2015 09:56 AM, Daniel Baluta wrote: > On Thu, May 28, 2015 at 5:17 PM, Daniel Baluta wrote: >> >> >>>>>> +static const struct iio_chan_spec rpr0521_channels[] = { >>>>>> + { >>>>>> + .type = IIO_INTENSITY, >>>>>> + .modified = 1, >>>>>> + .address = RPR0521_CHAN_ALS_DATA0, >>>>>> + .channel2 = IIO_MOD_LIGHT_BOTH, >>>>>> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | >>>>>> + BIT(IIO_CHAN_INFO_CALIBSCALE), >>>>> >>>>> why CALIBSCALE and not SCALE? >>>> >>>> Because this is used to set/get gain, which is used by the hardware >>>> to do proper scaling. >>>> >>>> AFAIK this should be calibscale. >>> >>> in sysfs-bus-iiof on CALIBSCALE: Hardware applied calibration scale factor >>> (assumed to fix production inaccuracies). >>> >>> this doesn't seem applicable here, it is a gain factor controlling >>> measurement resolution >> >> Ok, I see now and it makes sense :). >> >> # echo 1 > in_intensity_ir_calibscale >> # cat in_intensity_ir_raw >> 79 >> # echo 64 > in_intensity_ir_calibscale >> # cat in_intensity_ir_raw >> 5084 >> >> The user should get the same value regardless of the gain :), and in the >> above example for x64 gain it should have a 1/64 scale. >> >> >> >> >>>> Or we can consider that the chan->type is always valid? >>> >>> I'd think so; you also assume that chan->address is valid >>> >>> I suggest to use chan->address to point to a table containing the >>> address and the mask >> >> >> >>>> Which sensors? It means they do not agree with the ABI: >>>> >>>> http://lxr.free-electrons.com/source/Documentation/ABI/testing/sysfs-bus-iio#L1131 >>> >>> that 'clarification' was added recently, >>> 614e8842ddf5502f0e781f91695bfbc1e1e1d9b6 (with 3.18) >>> "Proximity measurement .. by observing reflectivity" >>> >>> high proximity <-> high reflectivity -- this is the reality of what most >>> sensors output (including yours) >>> >>> proximity and distance are opposite concepts; >>> high proximity <-> low distance, and vice versa >>> >>> the distance part doesn't make sense in the ABI description >> >> At least sx9500 uses this convention and userspace applications rely on this. > > OK, so wee need to agree on this part and to add a proper descriptor to the ABI. > > Jonathan, what do you say? > I agree that we need to agree one way or the other. Proximity being higher as you get closer seems slightly more logical to me (I wish now that I'd argued in favour of just doing distance, but such is hindsight). Still I'm happy with whatever consensus forms. > -- 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/