linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sanchayan Maity <maitysanchayan@gmail.com>
To: linux-iio@vger.kernel.org
Subject: Query regarding a IIO consumer touchscreen driver
Date: Fri, 09 Jan 2015 11:28:18 +0530	[thread overview]
Message-ID: <54AF6DFA.7040204@gmail.com> (raw)

Hello,

I have been working on a IIO consumer touchscreen driver. On one of our Vybrid modules we use the ADC channels for
the touchscreen. I ported an earlier driver in the 3.0 kernel done by my colleague to the recent 3.18/19 kernel to
use the IIO based consumer interface.

The touchscreen driver is here
http://git.toradex.com/cgit/linux-toradex.git/tree/drivers/input/touchscreen/colibri-vf50-ts.c?h=toradex_vf_3.18-next&id=7142dd741e948e1536632f9db1f3dd3a015450a5

The ADC driver with which it interacts is here
http://git.toradex.com/cgit/linux-toradex.git/tree/drivers/iio/adc/vf610_adc.c?h=toradex_vf_3.18-next&id=7142dd741e948e1536632f9db1f3dd3a015450a5

Currently, this works in a limited capaicty I would say. One of the problems I have with this driver is that when
this driver is used I can't get valid readings for any of the other ADC channels by using something like "cat". I
believe this is because of the fact that the workqueue runs a while loop every 10ms and reads the channels. This
clearly does not play well with reading of other channels and results in random reads on trying to read other channels,
for example the temperature channel. The exact reason I have not figured out here. I was thinking may be a device
lock would be required, but, that doesn't help.

The workqueue function
http://git.toradex.com/cgit/linux-toradex.git/tree/drivers/input/touchscreen/colibri-vf50-ts.c?h=toradex_vf_3.18-next&id=7142dd741e948e1536632f9db1f3dd3a015450a5#n102

The primary read raw function
http://git.toradex.com/cgit/linux-toradex.git/tree/drivers/iio/adc/vf610_adc.c?h=toradex_vf_3.18-next&id=7142dd741e948e1536632f9db1f3dd3a015450a5#n449

I was thinking this would need a better design than what has been done? Can someone give some suggestions as what
would be the right design/architecture here. I was thinking if setting up a IIO ring buffer, pushing the readings
to it and then reading from the touchscreen driver would work. One of the aims is also to make it clean enough for
eventual submission to the mainline. 

Thanks & Regards,
Sanchayan Maity.

             reply	other threads:[~2015-01-09  5:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-09  5:58 Sanchayan Maity [this message]
2015-01-10 11:03 ` Query regarding a IIO consumer touchscreen driver Jonathan Cameron
2015-01-12 12:54   ` Sanchayan Maity
2015-02-08 12:13     ` Jonathan Cameron

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=54AF6DFA.7040204@gmail.com \
    --to=maitysanchayan@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).