All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Eugen Hristev <eugen.hristev@microchip.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
	<ludovic.desroches@microchip.com>,
	<alexandre.belloni@bootlin.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-iio@vger.kernel.org>, <linux-input@vger.kernel.org>,
	<nicolas.ferre@microchip.com>, <dmitry.torokhov@gmail.com>,
	<robh@kernel.org>
Subject: Re: [PATCH v3 03/11] iio: Add channel for Position Relative
Date: Wed, 18 Apr 2018 10:32:27 +0100	[thread overview]
Message-ID: <20180418103227.00003a2e@huawei.com> (raw)
In-Reply-To: <02533699-a2bc-7c0c-4d8a-c10bb0102667@microchip.com>

On Tue, 17 Apr 2018 10:30:46 +0300
Eugen Hristev <eugen.hristev@microchip.com> wrote:

> On 15.04.2018 22:29, Jonathan Cameron wrote:
> > On Tue, 10 Apr 2018 11:57:49 +0300
> > Eugen Hristev <eugen.hristev@microchip.com> wrote:
> >   
> >> Add new channel type for relative position on a pad.
> >>
> >> These type of analog sensor offers the position of a pen
> >> on a touchpad, and is represented as a voltage, which can be
> >> converted to a position on X and Y axis on the pad.
> >> The channel will hand the relative position on the pad in both directions.
> >>
> >> The channel can then be consumed by a touchscreen driver or
> >> read as-is for a raw indication of the touchpen on a touchpad.
> >>
> >> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> >> ---
> >> Changes in v2:
> >>   - modified channel name to relative position as suggested.
> >>   - modified kernel version to 4.18 (presumable)
> >>
> >>   Documentation/ABI/testing/sysfs-bus-iio | 12 ++++++++++++
> >>   drivers/iio/industrialio-core.c         |  1 +
> >>   include/uapi/linux/iio/types.h          |  1 +
> >>   tools/iio/iio_event_monitor.c           |  2 ++
> >>   4 files changed, 16 insertions(+)
> >>
> >> diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> >> index 6a5f34b..42a9287 100644
> >> --- a/Documentation/ABI/testing/sysfs-bus-iio
> >> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> >> @@ -190,6 +190,18 @@ Description:
> >>   		but should match other such assignments on device).
> >>   		Units after application of scale and offset are m/s^2.
> >>   
> >> +What:		/sys/bus/iio/devices/iio:deviceX/in_positionrelative_x_raw
> >> +What:		/sys/bus/iio/devices/iio:deviceX/in_positionrelative_y_raw
> >> +KernelVersion:	4.18
> >> +Contact:	linux-iio@vger.kernel.org
> >> +Description:
> >> +		Relative position in direction x or y on a pad (may be
> >> +		arbitrarily assigned but should match other such assignments on
> >> +		device).
> >> +		Units after application of scale and offset are milli percents
> >> +		from the pad's size in both directions. Should be calibrated by
> >> +		the consumer.  
> > I know the milli percent comes form the humidity equivalent, but I wonder
> > if we are right to follow that.  10^-5 is a pretty random base unit (though
> > I got argued into it being a standard choice for humidity sensors IIRC...
> > 
> > What do people think?  We could go with 1 for full range or just percent perhaps?
> > 
> > I'm not that fussed about staying consistent with humidity - we are unlikely
> > to end up with sensors doing both anytime soon so there shouldn't be
> > any confusion...
> > 
> > Jonathan  
> Hello Jonathan,
> 
> For my specific use case, percents are not enough, as this would mean 
> the resolution will be pretty low. If we have a touchpanel of a higher 
> resolution, having the position only ranged 0 to 100 is pretty bad.
> Having millipercents means we can have a resolution up to 100,000 points 
> in range, which is fine for the hardware as of this moment.
> Of course, specific drivers reporting these channels can define a 
> specific range if they desire (report just in the first percent if you 
> wish (0-1000) or so, which would mean a lower resolution.
> Centi-percent would work fine as well I believe (0-10,000 range), but to 
> keep consistent with your suggestion regarding relative humidity, I 
> picked this larger scale.
> In my specific case, since we have a 12 bit ADC, range is 0-4096 for 
> this value.
> Calibrating these values to the actual size of the touchpanel is left 
> for the consumer to do (map 4096x4096 to the actual resolution)
> 
> If you have a better idea than milli-percents I can change it, no problem.
> 

It doesn't actually matter what the defined 'base units' are from a question
of what we can represent.  That is just handled by suppling an appropriate
SCALE for the channel.  All this is about is trying to provide something
consistent rather than having any effect on the actual range.  Will let
this sit a while longer...

Jonathan

> Eugen
> >> +
> >>   [...]  
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Eugen Hristev <eugen.hristev@microchip.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
	ludovic.desroches@microchip.com, alexandre.belloni@bootlin.com,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
	linux-input@vger.kernel.org, nicolas.ferre@microchip.com,
	dmitry.torokhov@gmail.com, robh@kernel.org
Subject: Re: [PATCH v3 03/11] iio: Add channel for Position Relative
Date: Wed, 18 Apr 2018 10:32:27 +0100	[thread overview]
Message-ID: <20180418103227.00003a2e@huawei.com> (raw)
In-Reply-To: <02533699-a2bc-7c0c-4d8a-c10bb0102667@microchip.com>

On Tue, 17 Apr 2018 10:30:46 +0300
Eugen Hristev <eugen.hristev@microchip.com> wrote:

> On 15.04.2018 22:29, Jonathan Cameron wrote:
> > On Tue, 10 Apr 2018 11:57:49 +0300
> > Eugen Hristev <eugen.hristev@microchip.com> wrote:
> >   
> >> Add new channel type for relative position on a pad.
> >>
> >> These type of analog sensor offers the position of a pen
> >> on a touchpad, and is represented as a voltage, which can be
> >> converted to a position on X and Y axis on the pad.
> >> The channel will hand the relative position on the pad in both directions.
> >>
> >> The channel can then be consumed by a touchscreen driver or
> >> read as-is for a raw indication of the touchpen on a touchpad.
> >>
> >> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> >> ---
> >> Changes in v2:
> >>   - modified channel name to relative position as suggested.
> >>   - modified kernel version to 4.18 (presumable)
> >>
> >>   Documentation/ABI/testing/sysfs-bus-iio | 12 ++++++++++++
> >>   drivers/iio/industrialio-core.c         |  1 +
> >>   include/uapi/linux/iio/types.h          |  1 +
> >>   tools/iio/iio_event_monitor.c           |  2 ++
> >>   4 files changed, 16 insertions(+)
> >>
> >> diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> >> index 6a5f34b..42a9287 100644
> >> --- a/Documentation/ABI/testing/sysfs-bus-iio
> >> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> >> @@ -190,6 +190,18 @@ Description:
> >>   		but should match other such assignments on device).
> >>   		Units after application of scale and offset are m/s^2.
> >>   
> >> +What:		/sys/bus/iio/devices/iio:deviceX/in_positionrelative_x_raw
> >> +What:		/sys/bus/iio/devices/iio:deviceX/in_positionrelative_y_raw
> >> +KernelVersion:	4.18
> >> +Contact:	linux-iio@vger.kernel.org
> >> +Description:
> >> +		Relative position in direction x or y on a pad (may be
> >> +		arbitrarily assigned but should match other such assignments on
> >> +		device).
> >> +		Units after application of scale and offset are milli percents
> >> +		from the pad's size in both directions. Should be calibrated by
> >> +		the consumer.  
> > I know the milli percent comes form the humidity equivalent, but I wonder
> > if we are right to follow that.  10^-5 is a pretty random base unit (though
> > I got argued into it being a standard choice for humidity sensors IIRC...
> > 
> > What do people think?  We could go with 1 for full range or just percent perhaps?
> > 
> > I'm not that fussed about staying consistent with humidity - we are unlikely
> > to end up with sensors doing both anytime soon so there shouldn't be
> > any confusion...
> > 
> > Jonathan  
> Hello Jonathan,
> 
> For my specific use case, percents are not enough, as this would mean 
> the resolution will be pretty low. If we have a touchpanel of a higher 
> resolution, having the position only ranged 0 to 100 is pretty bad.
> Having millipercents means we can have a resolution up to 100,000 points 
> in range, which is fine for the hardware as of this moment.
> Of course, specific drivers reporting these channels can define a 
> specific range if they desire (report just in the first percent if you 
> wish (0-1000) or so, which would mean a lower resolution.
> Centi-percent would work fine as well I believe (0-10,000 range), but to 
> keep consistent with your suggestion regarding relative humidity, I 
> picked this larger scale.
> In my specific case, since we have a 12 bit ADC, range is 0-4096 for 
> this value.
> Calibrating these values to the actual size of the touchpanel is left 
> for the consumer to do (map 4096x4096 to the actual resolution)
> 
> If you have a better idea than milli-percents I can change it, no problem.
> 

It doesn't actually matter what the defined 'base units' are from a question
of what we can represent.  That is just handled by suppling an appropriate
SCALE for the channel.  All this is about is trying to provide something
consistent rather than having any effect on the actual range.  Will let
this sit a while longer...

Jonathan

> Eugen
> >> +
> >>   [...]  
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Jonathan.Cameron@huawei.com (Jonathan Cameron)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 03/11] iio: Add channel for Position Relative
Date: Wed, 18 Apr 2018 10:32:27 +0100	[thread overview]
Message-ID: <20180418103227.00003a2e@huawei.com> (raw)
In-Reply-To: <02533699-a2bc-7c0c-4d8a-c10bb0102667@microchip.com>

On Tue, 17 Apr 2018 10:30:46 +0300
Eugen Hristev <eugen.hristev@microchip.com> wrote:

> On 15.04.2018 22:29, Jonathan Cameron wrote:
> > On Tue, 10 Apr 2018 11:57:49 +0300
> > Eugen Hristev <eugen.hristev@microchip.com> wrote:
> >   
> >> Add new channel type for relative position on a pad.
> >>
> >> These type of analog sensor offers the position of a pen
> >> on a touchpad, and is represented as a voltage, which can be
> >> converted to a position on X and Y axis on the pad.
> >> The channel will hand the relative position on the pad in both directions.
> >>
> >> The channel can then be consumed by a touchscreen driver or
> >> read as-is for a raw indication of the touchpen on a touchpad.
> >>
> >> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> >> ---
> >> Changes in v2:
> >>   - modified channel name to relative position as suggested.
> >>   - modified kernel version to 4.18 (presumable)
> >>
> >>   Documentation/ABI/testing/sysfs-bus-iio | 12 ++++++++++++
> >>   drivers/iio/industrialio-core.c         |  1 +
> >>   include/uapi/linux/iio/types.h          |  1 +
> >>   tools/iio/iio_event_monitor.c           |  2 ++
> >>   4 files changed, 16 insertions(+)
> >>
> >> diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> >> index 6a5f34b..42a9287 100644
> >> --- a/Documentation/ABI/testing/sysfs-bus-iio
> >> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> >> @@ -190,6 +190,18 @@ Description:
> >>   		but should match other such assignments on device).
> >>   		Units after application of scale and offset are m/s^2.
> >>   
> >> +What:		/sys/bus/iio/devices/iio:deviceX/in_positionrelative_x_raw
> >> +What:		/sys/bus/iio/devices/iio:deviceX/in_positionrelative_y_raw
> >> +KernelVersion:	4.18
> >> +Contact:	linux-iio at vger.kernel.org
> >> +Description:
> >> +		Relative position in direction x or y on a pad (may be
> >> +		arbitrarily assigned but should match other such assignments on
> >> +		device).
> >> +		Units after application of scale and offset are milli percents
> >> +		from the pad's size in both directions. Should be calibrated by
> >> +		the consumer.  
> > I know the milli percent comes form the humidity equivalent, but I wonder
> > if we are right to follow that.  10^-5 is a pretty random base unit (though
> > I got argued into it being a standard choice for humidity sensors IIRC...
> > 
> > What do people think?  We could go with 1 for full range or just percent perhaps?
> > 
> > I'm not that fussed about staying consistent with humidity - we are unlikely
> > to end up with sensors doing both anytime soon so there shouldn't be
> > any confusion...
> > 
> > Jonathan  
> Hello Jonathan,
> 
> For my specific use case, percents are not enough, as this would mean 
> the resolution will be pretty low. If we have a touchpanel of a higher 
> resolution, having the position only ranged 0 to 100 is pretty bad.
> Having millipercents means we can have a resolution up to 100,000 points 
> in range, which is fine for the hardware as of this moment.
> Of course, specific drivers reporting these channels can define a 
> specific range if they desire (report just in the first percent if you 
> wish (0-1000) or so, which would mean a lower resolution.
> Centi-percent would work fine as well I believe (0-10,000 range), but to 
> keep consistent with your suggestion regarding relative humidity, I 
> picked this larger scale.
> In my specific case, since we have a 12 bit ADC, range is 0-4096 for 
> this value.
> Calibrating these values to the actual size of the touchpanel is left 
> for the consumer to do (map 4096x4096 to the actual resolution)
> 
> If you have a better idea than milli-percents I can change it, no problem.
> 

It doesn't actually matter what the defined 'base units' are from a question
of what we can represent.  That is just handled by suppling an appropriate
SCALE for the channel.  All this is about is trying to provide something
consistent rather than having any effect on the actual range.  Will let
this sit a while longer...

Jonathan

> Eugen
> >> +
> >>   [...]  
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2018-04-18  9:32 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-10  8:57 [PATCH v3 00/11] Add support for SAMA5D2 touchscreen Eugen Hristev
2018-04-10  8:57 ` Eugen Hristev
2018-04-10  8:57 ` Eugen Hristev
2018-04-10  8:57 ` [PATCH v3 01/11] iio: adc: at91-sama5d2_adc: fix channel configuration for differential channels Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-15 19:23   ` Jonathan Cameron
2018-04-15 19:23     ` Jonathan Cameron
2018-04-15 19:23     ` Jonathan Cameron
2018-04-10  8:57 ` [PATCH v3 02/11] MAINTAINERS: add generic resistive touchscreen adc Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-10  8:57 ` [PATCH v3 03/11] iio: Add channel for Position Relative Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-15 19:29   ` Jonathan Cameron
2018-04-15 19:29     ` Jonathan Cameron
2018-04-15 19:29     ` Jonathan Cameron
2018-04-17  7:30     ` Eugen Hristev
2018-04-17  7:30       ` Eugen Hristev
2018-04-17  7:30       ` Eugen Hristev
2018-04-18  9:32       ` Jonathan Cameron [this message]
2018-04-18  9:32         ` Jonathan Cameron
2018-04-18  9:32         ` Jonathan Cameron
2018-04-10  8:57 ` [PATCH v3 04/11] dt-bindings: input: touchscreen: add pressure threshold touchscreen property Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-13 18:33   ` Rob Herring
2018-04-13 18:33     ` Rob Herring
2018-04-10  8:57 ` [PATCH v3 05/11] dt-bindings: input: touchscreen: resistive-adc-touch: create bindings Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-13 18:34   ` Rob Herring
2018-04-13 18:34     ` Rob Herring
2018-04-10  8:57 ` [PATCH v3 06/11] iio: inkern: add module put/get on iio dev module when requesting channels Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-15 19:33   ` Jonathan Cameron
2018-04-15 19:33     ` Jonathan Cameron
2018-04-15 19:33     ` Jonathan Cameron
2018-04-16 23:58     ` Dmitry Torokhov
2018-04-16 23:58       ` Dmitry Torokhov
2018-04-17  7:39       ` Eugen Hristev
2018-04-17  7:39         ` Eugen Hristev
2018-04-17  7:39         ` Eugen Hristev
2018-04-17 19:19         ` Dmitry Torokhov
2018-04-17 19:19           ` Dmitry Torokhov
2018-04-18  9:35           ` Jonathan Cameron
2018-04-18  9:35             ` Jonathan Cameron
2018-04-18  9:35             ` Jonathan Cameron
2018-04-18 12:37             ` Lars-Peter Clausen
2018-04-18 12:37               ` Lars-Peter Clausen
2018-04-10  8:57 ` [PATCH v3 07/11] iio: adc: at91-sama5d2_adc: add support for position and pressure channels Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-15 19:45   ` Jonathan Cameron
2018-04-15 19:45     ` Jonathan Cameron
2018-04-15 19:45     ` Jonathan Cameron
2018-04-10  8:57 ` [PATCH v3 08/11] input: touchscreen: resistive-adc-touch: add generic resistive ADC touchscreen Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-23 23:22   ` Dmitry Torokhov
2018-04-23 23:22     ` Dmitry Torokhov
2018-04-23 23:24     ` Dmitry Torokhov
2018-04-23 23:24       ` Dmitry Torokhov
2018-04-10  8:57 ` [PATCH v3 09/11] dt-bindings: iio: adc: at91-sama5d2_adc: add channel specific consumer info Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-10  8:57 ` [PATCH v3 10/11] ARM: dts: at91: sama5d2: add channel cells for ADC device Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-10  8:57 ` [PATCH v3 11/11] ARM: dts: at91: sama5d2: Add resistive touch device Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev
2018-04-10  8:57   ` Eugen Hristev

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=20180418103227.00003a2e@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=eugen.hristev@microchip.com \
    --cc=jic23@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ludovic.desroches@microchip.com \
    --cc=nicolas.ferre@microchip.com \
    --cc=robh@kernel.org \
    /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.