From: "Kristina Martšenko" <kristina.martsenko@gmail.com>
To: Marek Vasut <marex@denx.de>
Cc: Jonathan Cameron <jic23@kernel.org>,
Hartmut Knaack <knaack.h@gmx.de>,
Lars-Peter Clausen <lars@metafoo.de>,
Peter Meerwald <pmeerw@pmeerw.net>,
Juergen Beisert <jbe@pengutronix.de>,
Alexandre Belloni <alexandre.belloni@free-electrons.com>,
Fabio Estevam <fabio.estevam@freescale.com>,
Stefan Wahren <stefan.wahren@i2se.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-iio@vger.kernel.org, devel@driverdev.osuosl.org
Subject: Re: [PATCH 1/4] iio: mxs-lradc: separate touchscreen and buffer virtual channels
Date: Mon, 19 Jan 2015 21:02:03 +0200 [thread overview]
Message-ID: <54BD54AB.7020802@gmail.com> (raw)
In-Reply-To: <201501180119.04510.marex@denx.de>
On 18/01/15 02:19, Marek Vasut wrote:
> On Saturday, January 17, 2015 at 01:22:08 AM, Kristina Martšenko wrote:
>
> Hi!
Hi!
> Good stuff, thank you! Just minor nitpicks below.
>
> [...]
>
>> diff --git a/drivers/staging/iio/adc/mxs-lradc.c
>> b/drivers/staging/iio/adc/mxs-lradc.c index e0e91836eec1..fc65cd311be9
>> 100644
>> --- a/drivers/staging/iio/adc/mxs-lradc.c
>> +++ b/drivers/staging/iio/adc/mxs-lradc.c
>> @@ -214,11 +214,14 @@ struct mxs_lradc {
>> unsigned long is_divided;
>>
>> /*
>> - * Touchscreen LRADC channels receives a private slot in the CTRL4
>> - * register, the slot #7. Therefore only 7 slots instead of 8 in the
>> - * CTRL4 register can be mapped to LRADC channels when using the
>> - * touchscreen.
>> - *
>> + * When the touchscreen is enabled, we give it two private virtual
>> + * channels: #6 and #7. This means that only 6 virtual channels (instead
>> + * of 8) will be available for buffered capture.
>> + */
>> +#define TS_VCH1 7
>> +#define TS_VCH2 6
>
> Please use a bit more explicit name for the macro, it's really not clear what
> the macro represents from it's name. Something like TOUCHSCREEN_VCHANNEL1 might
> work better for example. What do you think ?
Sure, I tried to keep it short and similar to the TS_CH_YP (etc) macros,
but clearer is better, so I'll change it to TOUCHSCREEN_VCHANNEL1 in v2.
>> +
>> + /*
>> * Furthermore, certain LRADC channels are shared between touchscreen
>> * and/or touch-buttons and generic LRADC block. Therefore when using
>> * either of these, these channels are not available for the regular
> [...]
>
> I also have a general question/idea here, it's explicitly not something I'd like
> to force upon you to implement. I see we have some kind of a hardware, which can
> sample up-to N inputs in parallel . Each input is muxed between M possible
> sources . Is such a thing common in the ADC/DAC world ? Would it be worth to
> implement generic helper to handle this kind of a N:M mapping ? What do you all
> think please ?
Hmm, I don't know how other drivers do this, or if there's anything in
common. The IIO people will probably have a better idea, so I'll wait
for them to respond.
Kristina
next prev parent reply other threads:[~2015-01-19 19:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-17 0:22 [PATCH 0/4] iio: mxs-lradc: fix interactions between the touchscreen and the ADC Kristina Martšenko
2015-01-17 0:22 ` [PATCH 1/4] iio: mxs-lradc: separate touchscreen and buffer virtual channels Kristina Martšenko
2015-01-18 0:19 ` Marek Vasut
2015-01-19 19:02 ` Kristina Martšenko [this message]
2015-01-20 1:29 ` Marek Vasut
2015-01-17 0:22 ` [PATCH 2/4] iio: mxs-lradc: make ADC reads not disable touchscreen interrupts Kristina Martšenko
2015-01-18 0:21 ` Marek Vasut
2015-01-19 19:03 ` Kristina Martšenko
2015-01-17 0:22 ` [PATCH 3/4] iio: mxs-lradc: make ADC reads not unschedule touchscreen conversions Kristina Martšenko
2015-01-18 0:22 ` Marek Vasut
2015-01-19 7:20 ` Juergen Borleis
2015-01-19 7:57 ` Marek Vasut
2015-01-19 20:03 ` Kristina Martšenko
2015-01-17 0:22 ` [PATCH 4/4] iio: mxs-lradc: only update the buffer when its conversions have finished Kristina Martšenko
2015-01-18 0:23 ` Marek Vasut
2015-01-18 11:21 ` [PATCH 0/4] iio: mxs-lradc: fix interactions between the touchscreen and the ADC Stefan Wahren
2015-01-19 20:30 ` Kristina Martšenko
2015-01-20 1:32 ` Marek Vasut
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=54BD54AB.7020802@gmail.com \
--to=kristina.martsenko@gmail.com \
--cc=alexandre.belloni@free-electrons.com \
--cc=devel@driverdev.osuosl.org \
--cc=fabio.estevam@freescale.com \
--cc=gregkh@linuxfoundation.org \
--cc=jbe@pengutronix.de \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=marex@denx.de \
--cc=pmeerw@pmeerw.net \
--cc=stefan.wahren@i2se.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 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).