All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juergen Beisert <jbe@pengutronix.de>
To: linux-arm-kernel@lists.infradead.org
Cc: "Lars-Peter Clausen" <lars@metafoo.de>,
	Marek Vasut <marex@denx.de>,
	linux-iio@vger.kernel.org
Subject: Re: [PATCH] IIO: Add basic MXS LRADC driver
Date: Tue, 10 Jul 2012 12:41:23 +0200	[thread overview]
Message-ID: <201207101241.24151.jbe@pengutronix.de> (raw)
In-Reply-To: <4FFC056B.7020106@metafoo.de>

Lars-Peter Clausen wrote:
> On 07/10/2012 12:26 PM, Juergen Beisert wrote:
> > Marek Vasut wrote:
> >> Dear Juergen Beisert,
> >>
> >>> Hi Marek,
> >>>
> >>> Marek Vasut wrote:
> >>>>>>> When I try to compile
> >>>>>>> your code I get:
> >>>>>>>
> >>>>>>> drivers/staging/iio/adc/mxs-lradc.c:42:40: fatal error:
> >>>>>>> linux/iio/triggered_buffer.h: No such file or directory
> >>>>>>
> >>>>>> You need this patches:
> >>>>>>     iio:kfifo_buf Take advantage of the fixed record size used in
> >>>>>> IIO iio: kfifo - add poll support.
> >>>>>>
> >>>>>> And use latest -next.
> >>>>>
> >>>>> Thanks for the hints. Now it compiles and the driver seems to work.
> >>>>>
> >>>>> One thing I do not understand: It does not matter what channel I read
> >>>>> ('in_voltage*_raw'), only interrupt 16 ('mxs-lradc-channel0') counts
> >>>>> up. Intended?
> >>>>> Or did I a mistake by adding interrupt numbers "<13 14 15 16 17 18 19
> >>>>> 20 21 22 23 24 25>" to the corresponding device tree entry?
> >>>>
> >>>> They're wrong
> >>>>
> >>>> lradc@80050000 {
> >>>>
> >>>>         compatible = "fsl,imx28-lradc";
> >>>>         reg = <0x80050000 2000>;
> >>>>         interrupts = <10 14 15 16 17 18 19
> >>>>
> >>>>                         20 21 22 23 24 25>;
> >>>>
> >>>>         status = "disabled";
> >>>>
> >>>> };
> >>>
> >>> Ups, thanks. But still the same behaviour:
> >>>
> >>> $ cat /proc/interrupts
> >>> [...]
> >>>  10:          0         -  mxs-lradc-touchscreen
> >>>  14:          0         -  mxs-lradc-thresh0
> >>>  15:          0         -  mxs-lradc-thresh1
> >>>  16:          0         -  mxs-lradc-channel0
> >>>  17:          0         -  mxs-lradc-channel1
> >>>  18:          0         -  mxs-lradc-channel2
> >>>  19:          0         -  mxs-lradc-channel3
> >>>  20:          0         -  mxs-lradc-channel4
> >>>  21:          0         -  mxs-lradc-channel5
> >>>  22:          0         -  mxs-lradc-channel6
> >>>  23:          0         -  mxs-lradc-channel7
> >>>  24:          0         -  mxs-lradc-button0
> >>>  25:          0         -  mxs-lradc-button1
> >>> [...]
> >>>
> >>> $ cat in_voltage0_raw
> >>> 524
> >>> $ cat in_voltage1_raw
> >>> 96
> >>> $ cat in_voltage2_raw
> >>> 1261
> >>>
> >>> $ cat /proc/interrupts
> >>> [...]
> >>>  10:          0         -  mxs-lradc-touchscreen
> >>>  14:          0         -  mxs-lradc-thresh0
> >>>  15:          0         -  mxs-lradc-thresh1
> >>>  16:          3         -  mxs-lradc-channel0
> >>>  17:          0         -  mxs-lradc-channel1
> >>>  18:          0         -  mxs-lradc-channel2
> >>>  19:          0         -  mxs-lradc-channel3
> >>>  20:          0         -  mxs-lradc-channel4
> >>>  21:          0         -  mxs-lradc-channel5
> >>>  22:          0         -  mxs-lradc-channel6
> >>>  23:          0         -  mxs-lradc-channel7
> >>>  24:          0         -  mxs-lradc-button0
> >>>  25:          0         -  mxs-lradc-button1
> >>> [...]
> >>>
> >>> Intended in this way?
> >>
> >> But wait, you're getting interrupts on channel 0. Doesn't seem quite
> >> right. Did you happen to poke into the code and see where the issue
> >> might be?
> >
> > No yet. But if you think this is not the intended behaviour of your
> > driver I will do a deeper look.
>
> I don't know the hardware, but from what I've seen in the driver this
> behavior looks correct. When reading a physical channel the channel will be
> mapped to the first free virtual channel, afterward it is unmapped again.

Makes sense.

> So if you are only reading a single channel it will always be mapped to
> first virtual channel. If you'd be using buffered mode and read multiple
> channels at once you'll probably get multiple interrupts on different
> virtual channels.

So, the driver's behaviour is intended. Sorry for the noise.

Regards,
Juergen

-- 
Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | http://www.pengutronix.de/  |

WARNING: multiple messages have this Message-ID (diff)
From: jbe@pengutronix.de (Juergen Beisert)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] IIO: Add basic MXS LRADC driver
Date: Tue, 10 Jul 2012 12:41:23 +0200	[thread overview]
Message-ID: <201207101241.24151.jbe@pengutronix.de> (raw)
In-Reply-To: <4FFC056B.7020106@metafoo.de>

Lars-Peter Clausen wrote:
> On 07/10/2012 12:26 PM, Juergen Beisert wrote:
> > Marek Vasut wrote:
> >> Dear Juergen Beisert,
> >>
> >>> Hi Marek,
> >>>
> >>> Marek Vasut wrote:
> >>>>>>> When I try to compile
> >>>>>>> your code I get:
> >>>>>>>
> >>>>>>> drivers/staging/iio/adc/mxs-lradc.c:42:40: fatal error:
> >>>>>>> linux/iio/triggered_buffer.h: No such file or directory
> >>>>>>
> >>>>>> You need this patches:
> >>>>>>     iio:kfifo_buf Take advantage of the fixed record size used in
> >>>>>> IIO iio: kfifo - add poll support.
> >>>>>>
> >>>>>> And use latest -next.
> >>>>>
> >>>>> Thanks for the hints. Now it compiles and the driver seems to work.
> >>>>>
> >>>>> One thing I do not understand: It does not matter what channel I read
> >>>>> ('in_voltage*_raw'), only interrupt 16 ('mxs-lradc-channel0') counts
> >>>>> up. Intended?
> >>>>> Or did I a mistake by adding interrupt numbers "<13 14 15 16 17 18 19
> >>>>> 20 21 22 23 24 25>" to the corresponding device tree entry?
> >>>>
> >>>> They're wrong
> >>>>
> >>>> lradc at 80050000 {
> >>>>
> >>>>         compatible = "fsl,imx28-lradc";
> >>>>         reg = <0x80050000 2000>;
> >>>>         interrupts = <10 14 15 16 17 18 19
> >>>>
> >>>>                         20 21 22 23 24 25>;
> >>>>
> >>>>         status = "disabled";
> >>>>
> >>>> };
> >>>
> >>> Ups, thanks. But still the same behaviour:
> >>>
> >>> $ cat /proc/interrupts
> >>> [...]
> >>>  10:          0         -  mxs-lradc-touchscreen
> >>>  14:          0         -  mxs-lradc-thresh0
> >>>  15:          0         -  mxs-lradc-thresh1
> >>>  16:          0         -  mxs-lradc-channel0
> >>>  17:          0         -  mxs-lradc-channel1
> >>>  18:          0         -  mxs-lradc-channel2
> >>>  19:          0         -  mxs-lradc-channel3
> >>>  20:          0         -  mxs-lradc-channel4
> >>>  21:          0         -  mxs-lradc-channel5
> >>>  22:          0         -  mxs-lradc-channel6
> >>>  23:          0         -  mxs-lradc-channel7
> >>>  24:          0         -  mxs-lradc-button0
> >>>  25:          0         -  mxs-lradc-button1
> >>> [...]
> >>>
> >>> $ cat in_voltage0_raw
> >>> 524
> >>> $ cat in_voltage1_raw
> >>> 96
> >>> $ cat in_voltage2_raw
> >>> 1261
> >>>
> >>> $ cat /proc/interrupts
> >>> [...]
> >>>  10:          0         -  mxs-lradc-touchscreen
> >>>  14:          0         -  mxs-lradc-thresh0
> >>>  15:          0         -  mxs-lradc-thresh1
> >>>  16:          3         -  mxs-lradc-channel0
> >>>  17:          0         -  mxs-lradc-channel1
> >>>  18:          0         -  mxs-lradc-channel2
> >>>  19:          0         -  mxs-lradc-channel3
> >>>  20:          0         -  mxs-lradc-channel4
> >>>  21:          0         -  mxs-lradc-channel5
> >>>  22:          0         -  mxs-lradc-channel6
> >>>  23:          0         -  mxs-lradc-channel7
> >>>  24:          0         -  mxs-lradc-button0
> >>>  25:          0         -  mxs-lradc-button1
> >>> [...]
> >>>
> >>> Intended in this way?
> >>
> >> But wait, you're getting interrupts on channel 0. Doesn't seem quite
> >> right. Did you happen to poke into the code and see where the issue
> >> might be?
> >
> > No yet. But if you think this is not the intended behaviour of your
> > driver I will do a deeper look.
>
> I don't know the hardware, but from what I've seen in the driver this
> behavior looks correct. When reading a physical channel the channel will be
> mapped to the first free virtual channel, afterward it is unmapped again.

Makes sense.

> So if you are only reading a single channel it will always be mapped to
> first virtual channel. If you'd be using buffered mode and read multiple
> channels at once you'll probably get multiple interrupts on different
> virtual channels.

So, the driver's behaviour is intended. Sorry for the noise.

Regards,
Juergen

-- 
Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | http://www.pengutronix.de/  |

  reply	other threads:[~2012-07-10 10:41 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-04  2:15 [PATCH] IIO: Add basic MXS LRADC driver Marek Vasut
2012-07-04  2:15 ` Marek Vasut
2012-07-04  4:30 ` Wolfgang Denk
2012-07-04  4:30   ` Wolfgang Denk
2012-07-04  8:35 ` Lars-Peter Clausen
2012-07-04  8:35   ` Lars-Peter Clausen
2012-07-04 23:48   ` Marek Vasut
2012-07-04 23:48     ` Marek Vasut
2012-07-05  8:33     ` Lars-Peter Clausen
2012-07-05  8:33       ` Lars-Peter Clausen
2012-07-05 19:53       ` Marek Vasut
2012-07-05 19:53         ` Marek Vasut
2012-07-19 14:23       ` Marek Vasut
2012-07-19 14:23         ` Marek Vasut
2012-07-19 14:33         ` Lars-Peter Clausen
2012-07-19 14:33           ` Lars-Peter Clausen
2012-07-19 15:15           ` Marek Vasut
2012-07-19 15:15             ` Marek Vasut
2012-07-19 19:26           ` Marek Vasut
2012-07-19 19:26             ` Marek Vasut
2012-07-20  2:18             ` Marek Vasut
2012-07-20  2:18               ` Marek Vasut
2012-07-20  8:39               ` Robert Schwebel
2012-07-20  8:39                 ` Robert Schwebel
2012-07-20 11:32                 ` Marek Vasut
2012-07-20 11:32                   ` Marek Vasut
2012-07-20 14:09               ` Lars-Peter Clausen
2012-07-20 14:09                 ` Lars-Peter Clausen
2012-07-22 19:48                 ` Jonathan Cameron
2012-07-20 14:11             ` Lars-Peter Clausen
2012-07-20 14:11               ` Lars-Peter Clausen
2012-07-20 15:12               ` Marek Vasut
2012-07-20 15:12                 ` Marek Vasut
2012-07-09  9:19 ` Juergen Beisert
2012-07-09  9:19   ` Juergen Beisert
2012-07-09  9:52   ` Lars-Peter Clausen
2012-07-09  9:52     ` Lars-Peter Clausen
2012-07-09 10:03   ` Marek Vasut
2012-07-09 10:03     ` Marek Vasut
2012-07-10  9:20     ` Juergen Beisert
2012-07-10  9:20       ` Juergen Beisert
2012-07-10  9:26       ` Marek Vasut
2012-07-10  9:26         ` Marek Vasut
2012-07-10  9:49         ` Juergen Beisert
2012-07-10  9:49           ` Juergen Beisert
2012-07-10 10:08           ` Marek Vasut
2012-07-10 10:08             ` Marek Vasut
2012-07-10 10:26             ` Juergen Beisert
2012-07-10 10:26               ` Juergen Beisert
2012-07-10 10:35               ` Lars-Peter Clausen
2012-07-10 10:35                 ` Lars-Peter Clausen
2012-07-10 10:41                 ` Juergen Beisert [this message]
2012-07-10 10:41                   ` Juergen Beisert
2012-07-10 10:45                   ` Marek Vasut
2012-07-10 10:45                     ` 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=201207101241.24151.jbe@pengutronix.de \
    --to=jbe@pengutronix.de \
    --cc=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=marex@denx.de \
    /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.