Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp1705413rwb; Sun, 14 Aug 2022 10:02:22 -0700 (PDT) X-Google-Smtp-Source: AA6agR5IdQHGfS/1QUsv8CCM2AjY8HLanSxnWv5nHeHunQ9aI4Ohb4Lyuk/gsqf7DRlPFSa8dQGk X-Received: by 2002:a05:6402:34c3:b0:43d:d8d7:a328 with SMTP id w3-20020a05640234c300b0043dd8d7a328mr11512707edc.297.1660496542550; Sun, 14 Aug 2022 10:02:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660496542; cv=none; d=google.com; s=arc-20160816; b=ZK38TdVFIfp6/YckyPy0EeQ1A1Eh/uMfOzzrtnU7sGkYu5PgShv4M9CdrfOQeZWSxT 4W+tEEoG99i/RtR3UOxbY6C8EA+tanrIU7i1oCBDJzqMGrxj3dPoR/RBltgzMsenvyr7 jxyKcEm6hj9Z94ZYSrncuu6t4Ll35ie51ul0/nVrZIYELjWv2Yjf95xNQCCOi9lLMhUO UCGB/gHZdS9cq6xvnhJKmBn71R5DpxUIPc0kjSZ1L/MMEf6LW2kh+hrMq8AnYhfBLtuQ MiL2UdrSnSfc0fP2Lu4jia6Fw38GZSrQ2pw53NeiOoFanG4lPa+UW94SIdsw9j0Fq+q4 gBXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=2RYU+VGisHLhcCJuHr9JX+y4QbAj1v/csym28U4xODU=; b=Aduj62blneTHR4aO7KtidfF4YOOX/Ap/iDszaBuCfH12frxojZjg7NXqt4B3ehu7tz iT4kL9thK4vxKr7eoCyTrTc2zVhWeMf7i/hPDNx3KtH57sLFv+u0+tVkkpbOLgviD4uV cvcvHM7PoizD6xvUnEu7fnmrc1aqvkT+hclrF4dkl8fDI736OkCfWW64948M8mv+/HbX c7cju+J6eskvveeF1DkyfH7Zhde6JNCK/Cdl+68ZkdDA7dDc3qr7XWz9FU/epC7jchYR Hy0NbiHabaLJHAGpsUGXjGpbRR59G4N/R61DQ64MZ6gyfpkbIkkpiorJTUZA/cVk9Bxo CymA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=D9BtwFwu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d5-20020a50ea85000000b0043e42b0f87asi5902662edo.306.2022.08.14.10.01.57; Sun, 14 Aug 2022 10:02:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=D9BtwFwu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241157AbiHNQVn (ORCPT + 99 others); Sun, 14 Aug 2022 12:21:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52266 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231503AbiHNQVT (ORCPT ); Sun, 14 Aug 2022 12:21:19 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 41820BCAB; Sun, 14 Aug 2022 09:12:05 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DD51660F4E; Sun, 14 Aug 2022 16:12:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9DD51C433C1; Sun, 14 Aug 2022 16:12:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1660493524; bh=xTjMqD+IdoL1cpjFNN0IwBiI/zTHumM+62VySxWgwE8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=D9BtwFwuLZCIOcFsE8XcTPKPF0bsxRj+Le2Fu6fpsqSkDz8bx6I3WMCGMvbRfOogn pxFW7N3WIW/mHJVetpltFKKCIPKg9jpXvRXQYK2aog8h0Rx3KNgxVEZAh8dO/H1L7j XR47qTGXluq4KaYUXoioa27EG+gTFTnrPi/SX3U6Hwo5LKFEOKF76kFeKXwZ8jpZc2 Vi0UREx02oVqDhq7QPiOClxjSCmp61rQkiLHDBPo58rPptlZ/d8hLbyS/KRZxZq/0Z WMF6413ezVDjgMHxETzyuRCFUzMImqdpUSEmtA8cMGNX72PHeRxAh0UwriY9jRVeuC Sr4xX6trRFekg== Date: Sun, 14 Aug 2022 17:22:32 +0100 From: Jonathan Cameron To: Shreeya Patel Cc: lars@metafoo.de, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, krisman@collabora.com, kernel@collabora.com, alvaro.soliverez@collabora.com Subject: Re: [PATCH v2] iio: light: ltrf216a: Add raw attribute Message-ID: <20220814172232.4caeaf1c@jic23-huawei> In-Reply-To: <20220812100424.529425-1-shreeya.patel@collabora.com> References: <20220812100424.529425-1-shreeya.patel@collabora.com> X-Mailer: Claws Mail 4.1.0 (GTK 3.24.34; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 12 Aug 2022 15:34:24 +0530 Shreeya Patel wrote: > Add IIO_CHAN_INFO_RAW to the mask to be able to read raw values > from the light sensor. > > The userspace code for brightness control in steam deck uses the > in_illuminance_input value through sysfs and multiplies it > with a constant stored in BIOS at factory calibration time. > > The downstream driver for LTRF216A that we have been using > has incorrect formula for LUX calculation which we corrected > in the upstreamed driver. > > Now to be able to use the upstreamed driver, we need to add some > magic in userspace so that the brightness control works like before > even with the updated LUX formula. > > Hence, we need the raw data to calculate a constant that can be > added in userspace code. > > Downstream driver LUX formula :- > (greendata*8*LTRF216A_WIN_FAC) / (data->als_gain_fac*data->int_time_fac*10) > > Upstreamed driver LUX formula :- > (greendata*45*LTRF216A_WIN_FAC) / (data->als_gain_fac*data->int_time_fac) > > greendata is the ALS_DATA which we would like to get through sysfs using > the raw attribute. > > Signed-off-by: Shreeya Patel Hi Shreeya. Your description above makes me wonder though if we should support this as an intensity channel as we did for many of the early Ambient light sensors. Not sure why it's called 'greendata' btw! For those early tsl2583 IIRC and similar, we had two sensors with infrared vs visible+infrared (which is basically what clear is here). The readings given were of those two sensors then we did a bunch of maths to convert those to LUX (in simplest drivers we simply subtracted the infrared part from visible and applied a scale factor) That lead to IIO_TYPE_BOTH though we later added IIO_TYPE_CLEAR which is subtly different as that was for color sensors with RGB and clearish filters. The value you want here doesn't really correspond to any of those modifiers I guess that brings us back around to LIGHT(illuminance) + raw as you have it. or adding a 'visible' modifier which is also rather ugly and hard to define. Let's leave this on list a while longer to see if others comment. For now I'm inclined to just accept this as a dirty hack needed for this corner case. Jonathan > --- > > Changes in v2 > - Add a better commit message explaining why we want this change. > - Call ltrf216a_set_power_state(data, false) before return. > > > drivers/iio/light/ltrf216a.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/drivers/iio/light/ltrf216a.c b/drivers/iio/light/ltrf216a.c > index e6e24e70d2b9..4b8ef36b6912 100644 > --- a/drivers/iio/light/ltrf216a.c > +++ b/drivers/iio/light/ltrf216a.c > @@ -93,6 +93,7 @@ static const struct iio_chan_spec ltrf216a_channels[] = { > { > .type = IIO_LIGHT, > .info_mask_separate = > + BIT(IIO_CHAN_INFO_RAW) | > BIT(IIO_CHAN_INFO_PROCESSED) | > BIT(IIO_CHAN_INFO_INT_TIME), > .info_mask_separate_available = > @@ -259,6 +260,18 @@ static int ltrf216a_read_raw(struct iio_dev *indio_dev, > int ret; > > switch (mask) { > + case IIO_CHAN_INFO_RAW: > + ret = ltrf216a_set_power_state(data, true); > + if (ret) > + return ret; > + mutex_lock(&data->lock); > + ret = ltrf216a_read_data(data, LTRF216A_ALS_DATA_0); > + mutex_unlock(&data->lock); > + ltrf216a_set_power_state(data, false); > + if (ret < 0) > + return ret; > + *val = ret; > + return IIO_VAL_INT; > case IIO_CHAN_INFO_PROCESSED: > mutex_lock(&data->lock); > ret = ltrf216a_get_lux(data);