From: Lars-Peter Clausen <lars@metafoo.de>
To: Naveen Krishna Ch <naveenkrishna.ch@gmail.com>
Cc: Doug Anderson <dianders@chromium.org>,
Naveen Krishna Chatradhi <ch.naveen@samsung.com>,
linux-iio@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-samsung-soc@vger.kernel.org"
<linux-samsung-soc@vger.kernel.org>,
gregkh@linuxfoundation.org, Jonathan Cameron <jic23@kernel.org>
Subject: Re: [PATCH] iio: adc: add exynos5 adc driver under iio framwork
Date: Thu, 24 Jan 2013 19:11:03 +0100 [thread overview]
Message-ID: <51017937.40106@metafoo.de> (raw)
In-Reply-To: <CAHfPSqC90LwqEZ2kQdWY94CQHeqvCTYmw-WkAqBBNQui7wkKZQ@mail.gmail.com>
On 01/24/2013 03:20 PM, Naveen Krishna Ch wrote:
> On 24 January 2013 15:24, Lars-Peter Clausen <lars@metafoo.de> wrote:
>>
>> On 01/24/2013 01:42 AM, Doug Anderson wrote:
>>> Lars,
>>>
>>> On Wed, Jan 23, 2013 at 4:52 AM, Lars-Peter Clausen <lars@metafoo.de> wrote:
>>>>> Few doubts regarding the mappings and child device handling.
>>>>> Kindly, suggest me better methods.
>>>>
>>>> The patch looks mostly good now. As for the mappings, the problem is that we
>>>> currently do not have any device tree bindings for IIO. So a proper solution
>>>> would be to add dt bindings for IIO.
>>>
>>> Can you explain more how you think this would work? It seems like
>>> just having child nodes as platform drivers would be OK (to me) and
>>> having them instantiated with of_platform_populate() seems reasonable.
>>>
>>> ...but the one thing that is missing is a way for children to get
>>> access to the channel properly.
>>>
>>> The children have access to the ADC "struct device" (it is their
>>> parent device) and have a channel number (their "reg" field), but
>>> there is no API call to map this to a "struct iio_channel". Is that
>>> all that's needed in this case? ...or are you envisioning something
>>> more?
>>
>> Well, the idea is that the consumer doesn't need to know the channel number.
>> That's what the mapping takes care of. It basically creates a consumer alias
>> for the channel. When requesting the channel the consumer always uses the
>> same name.
>>
>> iio_channel_get(dev_name(&pdev->dev), "voltage");
>>
>> And the mapping contains an entry which maps the tuple of device name and
>> channel name to a real IIO channel which as been registered by a IIO device.
>> Note if there is only one channel you can also just use NULL for the channel
>> name. This is similar to how clocks are managed with the clk framework.
>>
>> Now for the dt bindings I think we should stick to something similar to what
>> the clk framework does.
>>
>> E.g.
>>
>> adc: adc@12D10000 {
>>
>> #io-channel-cells = <1>;
>> io-channel-output-names = "adc1", "adc2", ...;
>>
>> ncp15wb473@0 {
>> compatible = "ntc,ncp15wb473";
>> ...
>> io-channels = <&adc 0>; // First ADC channel
>> io-channel-names = "voltage";
>> };
>>
>> ncp15wb473@0 {
>> compatible = "ntc,ncp15wb473";
>> ...
>> io-channels = <&adc 1>; // Second ADC channel
>> io-channel-names = "voltage";
>> }
>> };
>>
> Hello Lars,
>
> I've a doubt here
>
> How do i find the child dev_name for iio_map_array_register();
>
> cause the child devices are probed during of_platform_populate();
>
> and during the probe the child calls
> iio_channel_get(dev_name(&pdev->dev), "voltage");
>
> The child device nodes are ncp15wb473.0 and ncp15wb473.1 in this case.
> But, this may change.
Hi,
I think we should handle the devicetree channel mapping in the IIO core and
not in the individual drivers. If we handle it in the core we do not need to
create a iio_map and won't need to know the name of the consumer.
You'd basically need to check whether the device requesting the IIO channel
has a of_node. If it has, check if it has an io-channels attribute. If it
also has an io-channels attribute lookup the IIO device by the phandle and
create a iio_channel for the nth channel of that device.
If either the device has no of_node or no io-channels attribute fallback to
using the iio_map based lookup method.
This would require one API change though, iio_channel_get would need to take
a device instead of the device name so it has access to both the device name
and the device node. Jonathan: any particular reason why you choose to let
iio_channel_get the device name instead of the device itself?
- Lars
>
> Kindly, help.
>
> Assume we have a device tree like this
>
> adc@12D10000 {
> #io-channel-cells = <1>;
> io-channel-output-names = "adc0", "adc1", "adc2",
> "adc3", "adc4", "adc5",
> "adc6", "adc7", "adc8", "adc9";
>
> ncp15wb473@0 {
> compatible = "ntc,ncp15wb473";
> reg = <0x0>;
> io-channel-names = "voltage";
> pullup-uV = <1800000>;
> pullup-ohm = <47000>;
> pulldown-ohm = <0>;
> };
> ncp15wb473@1 {
> compatible = "ntc,ncp15wb473";
> reg = <0x1>;
> io-channel-names = "voltage";
> pullup-uV = <1800000>;
> pullup-ohm = <47000>;
> pulldown-ohm = <0>;
> };
>
> };
>
>
>> io-channel-output-names and io-channel-names can be optional. In the case
>> where there is only one channel it's not really necessary to use
>> io-channel-names.
>>
next prev parent reply other threads:[~2013-01-24 18:11 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-21 13:37 [PATCH] iio: adc: add exynos5 adc driver under iio framwork Naveen Krishna Chatradhi
2013-01-22 9:44 ` Lars-Peter Clausen
2013-01-22 14:03 ` Naveen Krishna Ch
2013-01-22 14:27 ` Naveen Krishna Chatradhi
2013-01-23 4:58 ` Naveen Krishna Chatradhi
2013-01-23 12:52 ` Lars-Peter Clausen
2013-01-24 0:42 ` Doug Anderson
2013-01-24 9:54 ` Lars-Peter Clausen
2013-01-24 14:20 ` Naveen Krishna Ch
2013-01-24 18:11 ` Lars-Peter Clausen [this message]
2013-01-24 16:12 ` Doug Anderson
2013-01-24 18:19 ` Lars-Peter Clausen
2013-01-24 19:15 ` Tomasz Figa
2013-01-24 19:30 ` Lars-Peter Clausen
2013-02-12 21:07 ` Guenter Roeck
2013-02-13 2:48 ` Naveen Krishna Ch
2013-02-13 11:05 ` Naveen Krishna Ch
2013-02-13 13:16 ` Naveen Krishna Ch
2013-02-13 13:30 ` Lars-Peter Clausen
2013-02-13 13:53 ` Naveen Krishna Ch
2013-02-13 14:05 ` Lars-Peter Clausen
2013-02-13 15:51 ` Guenter Roeck
2013-01-24 4:58 ` [PATCH] " Naveen Krishna Chatradhi
2013-01-26 10:57 ` Jonathan Cameron
2013-01-24 5:05 ` Naveen Krishna Chatradhi
2013-02-12 1:22 ` Olof Johansson
2013-02-14 12:11 ` [PATCH v6] iio: adc: add exynos " Naveen Krishna Chatradhi
2013-02-14 20:55 ` Lars-Peter Clausen
2013-02-15 6:56 ` [PATCH v7] " Naveen Krishna Chatradhi
2013-02-15 13:13 ` Lars-Peter Clausen
2013-02-15 13:17 ` Naveen Krishna Ch
2013-02-15 13:26 ` Lars-Peter Clausen
2013-02-15 13:35 ` Naveen Krishna Ch
2013-03-03 12:16 ` 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=51017937.40106@metafoo.de \
--to=lars@metafoo.de \
--cc=ch.naveen@samsung.com \
--cc=dianders@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=naveenkrishna.ch@gmail.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).