All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: Peter Turczak <pt@netconsequence.de>
Cc: Jonathan Cameron <jic23@cam.ac.uk>,
	linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: i.MX28 die temperature
Date: Tue, 23 Oct 2012 10:52:39 +0200	[thread overview]
Message-ID: <201210231052.39983.marex@denx.de> (raw)
In-Reply-To: <6E339FB7-3B7F-4D90-A472-D375F36755F1@netconsequence.de>

Dear Peter Turczak,

> Hi Marek,
> hi Jonathan,
> 
> while trying to implement a battery charger driver for the mx28 platform I
> came across your posts. Sorry to stir up an old thread but it was running
> the same way.
> 
> On Jun 27, 2012, at 2:00 PM, Marek Vasut wrote:
> Dear Jonathan Cameron,
> 
> >> On 6/26/2012 8:02 PM, Marek Vasut wrote:
> >>> Dear Juergen Beisert,
> >>> 
> >>>> I tried a little bit with your driver. The disadvantage I see is, its
> >>>> claims all the free AD channels. But a few of them can also act as a
> >>>> touchscreen controller. Shouldn't be the driver handle the channel
> >>>> usage dynamically?
> >>> 
> >>> I wonder, I'd rather see this driver behave as a composite driver, what
> >>> do you think?
> >> 
> >> Alternative (though it's still in development) would be to use IIO
> >> as the ADC layer and sit the other parts on top.
> 
> I am currently trying to go this route, the idea is to use the consumer api
> to get the required battery management data to the battery driver. As a
> foundation I used the driver provided by Freescale which uses the lradc
> directly which I found rather bad in the system context.

We have some basic LRADC driver in upstream already, you should use that.

See drivers/staging/iio/adc/mxs-lradc.c

> Maybe one could map all the driver muxing and use specific parameters in
> explicitly named iio channels? But this could lead to permanent
> reconfiguring of the LRADC and maybe quite difficult handling of the
> measurements that arrive asynchronously.
> 
> Also I don't seem to quite get the usage of iio_map_array_register() which
> seems to enable the consumer api access to the device. I found only one
> use of it in an example in max1363.c which confused me even more. How do I
> correctly provide the iio_map struct? What is the consumer_dev_name used
> for and which "namespace" should used there, is it the name used in a
> platform_driver struct or the instances name (given there can only be one
> internal mxs battery charger at a time)?
> 
> Best regards,
>   Peter

Best regards,
Marek Vasut

WARNING: multiple messages have this Message-ID (diff)
From: marex@denx.de (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: i.MX28 die temperature
Date: Tue, 23 Oct 2012 10:52:39 +0200	[thread overview]
Message-ID: <201210231052.39983.marex@denx.de> (raw)
In-Reply-To: <6E339FB7-3B7F-4D90-A472-D375F36755F1@netconsequence.de>

Dear Peter Turczak,

> Hi Marek,
> hi Jonathan,
> 
> while trying to implement a battery charger driver for the mx28 platform I
> came across your posts. Sorry to stir up an old thread but it was running
> the same way.
> 
> On Jun 27, 2012, at 2:00 PM, Marek Vasut wrote:
> Dear Jonathan Cameron,
> 
> >> On 6/26/2012 8:02 PM, Marek Vasut wrote:
> >>> Dear Juergen Beisert,
> >>> 
> >>>> I tried a little bit with your driver. The disadvantage I see is, its
> >>>> claims all the free AD channels. But a few of them can also act as a
> >>>> touchscreen controller. Shouldn't be the driver handle the channel
> >>>> usage dynamically?
> >>> 
> >>> I wonder, I'd rather see this driver behave as a composite driver, what
> >>> do you think?
> >> 
> >> Alternative (though it's still in development) would be to use IIO
> >> as the ADC layer and sit the other parts on top.
> 
> I am currently trying to go this route, the idea is to use the consumer api
> to get the required battery management data to the battery driver. As a
> foundation I used the driver provided by Freescale which uses the lradc
> directly which I found rather bad in the system context.

We have some basic LRADC driver in upstream already, you should use that.

See drivers/staging/iio/adc/mxs-lradc.c

> Maybe one could map all the driver muxing and use specific parameters in
> explicitly named iio channels? But this could lead to permanent
> reconfiguring of the LRADC and maybe quite difficult handling of the
> measurements that arrive asynchronously.
> 
> Also I don't seem to quite get the usage of iio_map_array_register() which
> seems to enable the consumer api access to the device. I found only one
> use of it in an example in max1363.c which confused me even more. How do I
> correctly provide the iio_map struct? What is the consumer_dev_name used
> for and which "namespace" should used there, is it the name used in a
> platform_driver struct or the instances name (given there can only be one
> internal mxs battery charger at a time)?
> 
> Best regards,
>   Peter

Best regards,
Marek Vasut

  reply	other threads:[~2012-10-23  8:52 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-28 15:13 i.MX28 die temperature Randle, Bill
2012-03-29  2:37 ` Shawn Guo
2012-03-29 15:52   ` Randle, Bill
2012-04-04 23:51     ` Marek Vasut
2012-04-05  0:07       ` Randle, Bill
2012-04-05  0:36         ` Fabio Estevam
2012-06-22 11:49           ` Juergen Beisert
2012-06-22 17:19             ` Marek Vasut
2012-06-26  8:12               ` Juergen Beisert
2012-06-26 19:02                 ` Marek Vasut
2012-06-26 19:02                   ` Marek Vasut
2012-06-27  7:21                   ` Jonathan Cameron
2012-06-27  7:21                     ` Jonathan Cameron
2012-06-27 12:00                     ` Marek Vasut
2012-06-27 12:00                       ` Marek Vasut
2012-06-27 12:06                       ` Jonathan Cameron
2012-06-27 12:06                         ` Jonathan Cameron
2012-06-27 12:25                         ` Marek Vasut
2012-06-27 12:25                           ` Marek Vasut
2012-06-27 12:33                         ` Juergen Beisert
2012-06-27 12:33                           ` Juergen Beisert
2012-06-27 22:58                           ` Marek Vasut
2012-06-27 22:58                             ` Marek Vasut
2012-06-28  8:00                             ` Jonathan Cameron
2012-06-28  8:00                               ` Jonathan Cameron
2012-06-28  3:05                           ` Marek Vasut
2012-06-28  3:05                             ` Marek Vasut
2012-06-28 15:42                             ` Marek Vasut
2012-06-28 15:42                               ` Marek Vasut
2012-10-23  8:48                       ` Peter Turczak
2012-10-23  8:48                         ` Peter Turczak
2012-10-23  8:52                         ` Marek Vasut [this message]
2012-10-23  8:52                           ` Marek Vasut
2012-10-23 10:22                           ` Peter Turczak
2012-10-23 10:22                             ` Peter Turczak
2012-10-23 10:32                             ` Marek Vasut
2012-10-23 10: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=201210231052.39983.marex@denx.de \
    --to=marex@denx.de \
    --cc=jic23@cam.ac.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=pt@netconsequence.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.