All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: Hector Palacios <hector.palacios@digi.com>
Cc: "fabio.estevam@freescale.com" <fabio.estevam@freescale.com>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	"alexandre.belloni@free-electrons.com"
	<alexandre.belloni@free-electrons.com>,
	"lars@metafoo.de" <lars@metafoo.de>,
	"jic23@kernel.org" <jic23@kernel.org>
Subject: Re: [PATCH 1/4] iio: mxs-lradc: change the realbits to 12
Date: Wed, 10 Jul 2013 13:49:26 +0200	[thread overview]
Message-ID: <201307101349.26318.marex@denx.de> (raw)
In-Reply-To: <51DD3BA5.6000402@digi.com>

Hi Hector,

> Hello,
> 
> On 07/05/2013 03:10 PM, Marek Vasut wrote:
> > Dear Hector Palacios,
> > 
> >> Dear Marek,
> >> 
> >> On 07/05/2013 01:37 PM, Marek Vasut wrote:
> >>> Dear Hector Palacios,
> >>> 
> >>>> The LRADC virtual channels have an 18 bit field to store the sum of up
> >>>> to 2^5 accumulated samples. The read_raw function however only
> >>>> operates over a single sample (12 bit resolution).
> >>>> In order to use this field for scaling operations, we need it to be
> >>>> the exact resolution value of the LRADC.
> >>> 
> >>> How would this work once the accumulation is supported?
> >> 
> >> As I see it, when you read a channel the driver should give you the
> >> 12-bit value either of one single sample or of N samples.
> > 
> > The hardware will always give you 18 bit value, let's call it A of N
> > accumulated samples, each 12 bit long. N is in range of 1 to 32 .
> > 
> > The driver currently supports N = 1.
> > 
> > Do I understand it correctly that if we want to support N > 1, we have to
> > do the division of A / N in the driver and therefore we will again
> > report only a 12-bit value to the userland ?
> > 
> > If so,
> > 
> > Acked-by: Marek Vasut <marex@denx.de>
> 
> Coming back to this patch, I just noticed that it is not enough to just
> change the realbits from 18 to 12. When using this driver as touchscreen
> for Yocto's SATO graphic rootfs I noticed that the driver is using
> LRADC_CH_VALUE_MASK for reporting the coordinates.
> 
> 	input_set_abs_params(input, ABS_X, 0, LRADC_CH_VALUE_MASK, 0, 0);
> 	input_set_abs_params(input, ABS_Y, 0, LRADC_CH_VALUE_MASK, 0, 0);
> 	input_set_abs_params(input, ABS_PRESSURE, 0, LRADC_CH_VALUE_MASK, 0, 0);
> 
> which is defined as an 18bit mask:
> 
> 	#define	LRADC_CH_VALUE_MASK			0x3ffff
> 
> The result is that the touch calibration range in Xorg is expecting values
> between 0 and 262143 (0x3ffff), which causes trouble (at least I had
> problems to calibrate it).

What kind of trouble does it cause?

[...]

> Notice that I leave the existing LRADC_CH_VALUE_MASK 18bit mask in the rest
> of the driver, to support accumulated samples.
> Curiously, ts_lib works fine without this (maybe the calibration fixes
> this?), but nevertheless the information passed by the driver is
> incorrect, I guess. Is anybody out there working with the touch? Under
> which graphic system?

Both QtE and Sato work for me, that's why I'm curious about your issues.

Best regards,
Marek Vasut

  reply	other threads:[~2013-07-10 11:49 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-05  8:30 [PATCH 0/4] iio: mxs-lradc: add support to optional divider_by_two Hector Palacios
2013-07-05  8:30 ` [PATCH 1/4] iio: mxs-lradc: change the realbits to 12 Hector Palacios
2013-07-05 11:37   ` Marek Vasut
2013-07-05 12:40     ` Hector Palacios
2013-07-05 13:10       ` Marek Vasut
2013-07-05 14:35         ` Hector Palacios
2013-07-05 17:17           ` Lars-Peter Clausen
2013-07-06 10:08             ` Jonathan Cameron
2013-07-06 10:13               ` Marek Vasut
2013-07-10 10:47         ` Hector Palacios
2013-07-10 11:49           ` Marek Vasut [this message]
2013-07-10 14:45             ` Hector Palacios
2013-07-10 15:22               ` Marek Vasut
2013-07-05  8:30 ` [PATCH 2/4] iio: mxs-lradc: add scale attribute to channels Hector Palacios
2013-07-05 10:32   ` Lars-Peter Clausen
2013-07-05 15:49     ` Hector Palacios
2013-07-05 16:56       ` Marek Vasut
2013-07-05 11:41   ` Marek Vasut
2013-07-05 16:42     ` Hector Palacios
2013-07-05 16:59       ` Marek Vasut
2013-07-05 17:08         ` Lars-Peter Clausen
2013-07-05 17:39           ` Marek Vasut
2013-07-06  9:59         ` Jonathan Cameron
2013-07-05  8:30 ` [PATCH 3/4] iio: mxs-lradc: add scale_available file " Hector Palacios
2013-07-05 10:40   ` Lars-Peter Clausen
2013-07-08  8:27     ` Hector Palacios
2013-07-08  8:42       ` Lars-Peter Clausen
2013-07-05 11:46   ` Marek Vasut
2013-07-08  8:51     ` Hector Palacios
2013-07-08 13:05       ` Marek Vasut
2013-07-05  8:30 ` [PATCH 4/4] iio: mxs-lradc: add write_raw function to modify scale Hector Palacios
2013-07-05 10:41   ` Lars-Peter Clausen

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=201307101349.26318.marex@denx.de \
    --to=marex@denx.de \
    --cc=alexandre.belloni@free-electrons.com \
    --cc=fabio.estevam@freescale.com \
    --cc=hector.palacios@digi.com \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.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.