All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Mark Pearson <markpearson@lenovo.com>,
	<linux-iio@vger.kernel.org>, Bastien Nocera <hadess@hadess.net>,
	Nitin Joshi1 <njoshi1@lenovo.com>, <linux-input@vger.kernel.org>
Subject: Re: [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace?
Date: Mon, 23 Nov 2020 16:07:29 +0000	[thread overview]
Message-ID: <20201123160729.000038dd@Huawei.com> (raw)
In-Reply-To: <aeb7bc51-0b27-198b-d3b5-50b18ad114e7@redhat.com>

On Mon, 23 Nov 2020 13:16:20 +0100
Hans de Goede <hdegoede@redhat.com> wrote:

> Hi,
> 
> On 11/20/20 10:59 AM, Jonathan Cameron wrote:
> > On Thu, 19 Nov 2020 16:39:07 +0100
> > Hans de Goede <hdegoede@redhat.com> wrote:  
> 
> >>>>>>>> On 2020-10-03 10:02 a.m., Hans de Goede wrote:    
> >>>>>>>>> Hi All,
> >>>>>>>>>
> >>>>>>>>> Modern laptops can have various sensors which are kinda
> >>>>>>>>> like proximity sensors, but not really (they are more
> >>>>>>>>> specific in which part of the laptop the user is
> >>>>>>>>> proximate to).
> >>>>>>>>>
> >>>>>>>>> Specifically modern Thinkpad's have 2 readings which we
> >>>>>>>>> want to export to userspace, and I'm wondering if we
> >>>>>>>>> could use the IIO framework for this since these readings
> >>>>>>>>> are in essence sensor readings:
> >>>>>>>>>
> >>>>>>>>> 1. These laptops have a sensor in the palm-rests to
> >>>>>>>>> check if a user is physically proximate to the device's
> >>>>>>>>> palm-rests. This info will be used by userspace for WWAN
> >>>>>>>>> functionality to control the transmission level safely.
> >>>>>>>>>
> >>>>>>>>> A patch adding a thinkpad_acpi specific sysfs API for this
> >>>>>>>>> is currently pending:
> >>>>>>>>> https://patchwork.kernel.org/patch/11722127/
> >>>>>>>>>
> >>>>>>>>> But I'm wondering if it would not be better to use
> >>>>>>>>> IIO to export this info.    
> 
> <snip>
> 
> >>> On newer ARM we use "label" attribute in DTS:
> >>>
> >>> arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> >>>
> >>>         ap_sar_sensor: proximity@28 {
> >>>                 compatible = "semtech,sx9310";
> >>>                 reg = <0x28>;
> >>>                 #io-channel-cells = <1>;
> >>>                 pinctrl-names = "default";
> >>>                 pinctrl-0 = <&p_sensor_int_l>;
> >>>
> >>>                 interrupt-parent = <&tlmm>;
> >>>                 interrupts = <24 IRQ_TYPE_LEVEL_LOW>;
> >>>
> >>>                 vdd-supply = <&pp3300_a>;
> >>>                 svdd-supply = <&pp1800_prox>;
> >>>
> >>>                 status = "disabled";
> >>>                 label = "proximity-wifi";
> >>>         };    
> >>
> >> Hmm, interesting. I did not know iio-devices could
> >> have a label sysfs attribute (nor that that could be
> >> set through device-tree). I was thinking about adding
> >> an in_proximity_location sysfs attribute. But using
> >> labels (and standardizing a set of label names) will
> >> work nicely too.  
> > 
> > It's fairly new.   Note we also have per channel labels
> > though they are 'very new'.  Might be handy if the sensors
> > appear as a single device despite being spread over the
> > laptop.  
> 
> Interesting, the thinkpad_acpi stuff currently has 2
> proximity(ish) sensors:
> 
> 1. Laptop is close to (on) someones lap
> 2. Someone's arms are resting on or close to the palmrest
> 
> Ideally we would indeed register 1 iio-dev with separate
> channels for this, rather then having to register 2
> (and the future maybe even more) iio-devs for this.
> 
> Can you give a pointer to docs / examples of using a
> label per channel ?

Docs if done with DT binding are at:
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/?h=testing&id=7f79711533a96b02e1e24e2e36a29b08734e36e2
ABI Docs
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/?h=testing&id=3079188f821cfbdbb0b12f668335931a87eb14c6
An example using it directly rather than via DT (it's not really
DT related though in some cases the label may come from there)
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/?h=testing&id=1f4877218f7e2c2b914aeb69a8a0f47d59c74717

Those will probably be in Linux-next later this week.

Jonathan

> 
> >> Is there a know set of labels which ChromeOS is currently
> >> using? If we are going to use labels for this it would
> >> be good IMHO to define a set of standard labels for
> >> this in say Documentation/ABI/testing/sysfs-bus-iio-labels.  
> > 
> > If you do want to do this, please just put it under sysfs-bus-iio
> > doc.  I want this to be in the top level doc.  
> 
> Ok, ack.
> 
> Dmitry, can you perhaps dig up a full-list of labels
> which ChromeOS is currently using to identify
> proximity sensors for e.g. SAR related use?
> 
> Regards,
> 
> Hans
> 


  reply	other threads:[~2020-11-23 16:08 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-03 14:02 Using IIO to export laptop palm-sensor and lap-mode info to userspace? Hans de Goede
2020-10-06  2:04 ` [External] " Mark Pearson
2020-10-07  8:36   ` Jonathan Cameron
2020-10-07  9:51     ` Hans de Goede
2020-10-07 11:35       ` Bastien Nocera
2020-10-07 13:08         ` Hans de Goede
2020-10-07 13:29           ` Bastien Nocera
2020-10-07 13:32             ` Hans de Goede
2020-10-08  0:14               ` Jeff LaBundy
2020-10-08  7:10                 ` Hans de Goede
2020-10-09  2:19                   ` Jeff LaBundy
2020-10-12 12:13                     ` Hans de Goede
2020-10-13 21:59                       ` Mark Pearson
2020-10-14  4:47                         ` Jeff LaBundy
2020-10-14  8:16                         ` Hans de Goede
2020-10-14 14:26                           ` Mark Pearson
2020-10-12 12:36                   ` Enrico Weigelt, metux IT consult
2020-10-13  1:12                     ` Mark Pearson
2020-10-13  8:38                     ` Hans de Goede
2020-11-12  6:23       ` Dmitry Torokhov
2020-11-12  9:50         ` Hans de Goede
2020-11-13  6:58           ` Dmitry Torokhov
2020-11-19 15:39             ` Hans de Goede
2020-11-19 16:11               ` Bastien Nocera
2020-11-20  9:59               ` Jonathan Cameron
2020-11-23 12:16                 ` Hans de Goede
2020-11-23 16:07                   ` Jonathan Cameron [this message]
2020-11-19 15:16         ` Bastien Nocera
2020-11-19 15:24           ` Hans de Goede
2020-11-19 15:58             ` Bastien Nocera

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201123160729.000038dd@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=hadess@hadess.net \
    --cc=hdegoede@redhat.com \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=markpearson@lenovo.com \
    --cc=njoshi1@lenovo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.