From: Lars-Peter Clausen <lars@metafoo.de>
To: Guenter Roeck <linux@roeck-us.net>
Cc: linux-iio@vger.kernel.org, Jonathan Cameron <jic23@kernel.org>,
devicetree-discuss@lists.ozlabs.org,
Naveen Krishna Chatradhi <ch.naveen@samsung.com>,
Doug Anderson <dianders@chromium.org>,
Tomasz Figa <tomasz.figa@gmail.com>,
Grant Likely <grant.likely@secretlab.ca>,
Rob Herring <rob.herring@calxeda.com>
Subject: Re: [RFC 10/11] iio: Add OF support
Date: Sat, 02 Feb 2013 15:37:46 +0100 [thread overview]
Message-ID: <510D24BA.5000300@metafoo.de> (raw)
In-Reply-To: <20130201194213.GA17968@roeck-us.net>
On 02/01/2013 08:42 PM, Guenter Roeck wrote:
> On Fri, Feb 01, 2013 at 03:59:17PM +0100, Lars-Peter Clausen wrote:
>> On 02/01/2013 03:33 PM, Guenter Roeck wrote:
>>> On Fri, Feb 01, 2013 at 12:58:02PM +0100, Lars-Peter Clausen wrote:
>>>> 013 10:43 PM, Guenter Roeck wrote:
>>>>> Provide bindings, new API access functions, and parse OF data
>>>>> during initialization.
>>>>>
>>>>
>>>> Hi Guenter,
>>>>
>>>> Thanks for taking care of this.
>>>>
>>>> I'd prefer to have only one iio_get_channel which handles both the dt and the
>>>> non-dt case. Otherwise we'll soon have constructs like
>>>>
>>>> if (dev->of_node)
>>>> chan = of_iio_get_channel(dev->of_node, 1);
>>>> else
>>>> chan = iio_get_channel(dev_name(dev), "vcc");
>>>>
>
> Clock code has of_clk_get_by_name(node *, name), clk_get(dev, name), and
> of_clk_get(node *, index). Right now of_iio_get_channel matches of_clk_get,
> and iio_get_channel matches clk_get.
>
> Question is really how we want to API to look like. I am open to suggestions.
I'm not necessarily against having a separate of_iio_get_channe function, but
I'm not sure if we really need it, maybe use it internally as a helper and if
we really need it in some driver make it public and export it. clk_get first
calls of_clk_get_by_name, and only if didn't find a clk it falls back to the
map based lookup. I think iio_get_channel should behave the similar. of_clk_get
is kind of just a helper function for of_clk_get_by_name, not sure if we need
it as a separate function in IIO. If we find out we need it we can probably
still add it later.
- Lars
>
>>>> appearing all over the place in drivers code. I'd keep the actual
>>>> implementation pretty close to what the clk framework does. E.g. take a
look at
>>>> of_clk_get_by_name() and clk_get() in clkdev.c. And don't take a detour
via the
>>>> iio_map lookup for the devicetree case, just loop over all IIO devices and
>>>> match by of_node. This should allow us to simplify the code quite a bit.
>>>>
>>> Yes, I just could not figure out how to loop over the list of iio devices. That
>>> is why I hijacked iio_map which does provide a list.
>>>
>>> Any hints ?
>>
>> Yes, use bus_find_device on iio_bus_type. A nice example how to use this to
>> lookup device by of node is of_find_i2c_device_by_node. For IIO you also need
>> to make sure that dev->type is iio_dev_type, since both devices and triggers
>> are registered on the same bus.
>>
> Great, that works nicely, and, yes, the code is now much simpler.
>
>>>>> +static struct iio_map *iio_map_of_init(struct iio_dev *idev)
>>>>> +{
>>>>
>>>> To be honest I find this whole function a bit confusing. If we are using
>>>> devicetree, we shouldn't need to register iio_map. Maybe just skip over
>>>> io-channel-output-names for now, until we figure out if we really need
this and
>>>> what for.
>>>>
> Correct, I don't need this anymore after implementing the above.
>
WARNING: multiple messages have this Message-ID (diff)
From: Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
To: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Naveen Krishna Chatradhi
<ch.naveen-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Tomasz Figa <tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Grant Likely
<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>,
Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Subject: Re: [RFC 10/11] iio: Add OF support
Date: Sat, 02 Feb 2013 15:37:46 +0100 [thread overview]
Message-ID: <510D24BA.5000300@metafoo.de> (raw)
In-Reply-To: <20130201194213.GA17968-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
On 02/01/2013 08:42 PM, Guenter Roeck wrote:
> On Fri, Feb 01, 2013 at 03:59:17PM +0100, Lars-Peter Clausen wrote:
>> On 02/01/2013 03:33 PM, Guenter Roeck wrote:
>>> On Fri, Feb 01, 2013 at 12:58:02PM +0100, Lars-Peter Clausen wrote:
>>>> 013 10:43 PM, Guenter Roeck wrote:
>>>>> Provide bindings, new API access functions, and parse OF data
>>>>> during initialization.
>>>>>
>>>>
>>>> Hi Guenter,
>>>>
>>>> Thanks for taking care of this.
>>>>
>>>> I'd prefer to have only one iio_get_channel which handles both the dt and the
>>>> non-dt case. Otherwise we'll soon have constructs like
>>>>
>>>> if (dev->of_node)
>>>> chan = of_iio_get_channel(dev->of_node, 1);
>>>> else
>>>> chan = iio_get_channel(dev_name(dev), "vcc");
>>>>
>
> Clock code has of_clk_get_by_name(node *, name), clk_get(dev, name), and
> of_clk_get(node *, index). Right now of_iio_get_channel matches of_clk_get,
> and iio_get_channel matches clk_get.
>
> Question is really how we want to API to look like. I am open to suggestions.
I'm not necessarily against having a separate of_iio_get_channe function, but
I'm not sure if we really need it, maybe use it internally as a helper and if
we really need it in some driver make it public and export it. clk_get first
calls of_clk_get_by_name, and only if didn't find a clk it falls back to the
map based lookup. I think iio_get_channel should behave the similar. of_clk_get
is kind of just a helper function for of_clk_get_by_name, not sure if we need
it as a separate function in IIO. If we find out we need it we can probably
still add it later.
- Lars
>
>>>> appearing all over the place in drivers code. I'd keep the actual
>>>> implementation pretty close to what the clk framework does. E.g. take a
look at
>>>> of_clk_get_by_name() and clk_get() in clkdev.c. And don't take a detour
via the
>>>> iio_map lookup for the devicetree case, just loop over all IIO devices and
>>>> match by of_node. This should allow us to simplify the code quite a bit.
>>>>
>>> Yes, I just could not figure out how to loop over the list of iio devices. That
>>> is why I hijacked iio_map which does provide a list.
>>>
>>> Any hints ?
>>
>> Yes, use bus_find_device on iio_bus_type. A nice example how to use this to
>> lookup device by of node is of_find_i2c_device_by_node. For IIO you also need
>> to make sure that dev->type is iio_dev_type, since both devices and triggers
>> are registered on the same bus.
>>
> Great, that works nicely, and, yes, the code is now much simpler.
>
>>>>> +static struct iio_map *iio_map_of_init(struct iio_dev *idev)
>>>>> +{
>>>>
>>>> To be honest I find this whole function a bit confusing. If we are using
>>>> devicetree, we shouldn't need to register iio_map. Maybe just skip over
>>>> io-channel-output-names for now, until we figure out if we really need
this and
>>>> what for.
>>>>
> Correct, I don't need this anymore after implementing the above.
>
next prev parent reply other threads:[~2013-02-02 14:37 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-31 21:42 [RFC 00/11] staging/iio: Devicetree support Guenter Roeck
2013-01-31 21:42 ` Guenter Roeck
2013-01-31 21:42 ` [PATCH 01/11] staging/iio: (iio_hwmon) Use devm_kzalloc Guenter Roeck
2013-01-31 21:42 ` Guenter Roeck
2013-02-02 9:50 ` Jonathan Cameron
2013-02-02 9:50 ` Jonathan Cameron
2013-01-31 21:42 ` [PATCH 02/11] staging/iio: (iio_hwmon) Add support for sysfs name attribute Guenter Roeck
2013-01-31 21:42 ` Guenter Roeck
2013-02-02 9:52 ` Jonathan Cameron
2013-02-02 9:52 ` Jonathan Cameron
2013-01-31 21:43 ` [PATCH 03/11] staging/iio: (iio_hwmon) Basic devicetree support Guenter Roeck
2013-01-31 21:43 ` Guenter Roeck
2013-02-02 9:54 ` Jonathan Cameron
2013-02-02 9:54 ` Jonathan Cameron
2013-01-31 21:43 ` [PATCH 04/11] iio/adc: (lp8788) Provide OF node information to iio device Guenter Roeck
2013-01-31 21:43 ` Guenter Roeck
2013-02-02 9:55 ` Jonathan Cameron
2013-02-02 9:55 ` Jonathan Cameron
2013-01-31 21:43 ` [PATCH 05/11] iio/adc: (max1363) " Guenter Roeck
2013-01-31 21:43 ` Guenter Roeck
2013-02-02 10:06 ` Jonathan Cameron
2013-02-02 10:06 ` Jonathan Cameron
2013-01-31 21:43 ` [PATCH 06/11] iio/adc: (max1363) Remove duplicate code Guenter Roeck
2013-01-31 21:43 ` Guenter Roeck
2013-02-02 10:07 ` Jonathan Cameron
2013-02-02 10:07 ` Jonathan Cameron
2013-01-31 21:43 ` [PATCH 07/11] iio/adc: (max1363) Fix data conversion problems Guenter Roeck
2013-01-31 21:43 ` Guenter Roeck
2013-02-02 10:08 ` Jonathan Cameron
2013-02-02 10:08 ` Jonathan Cameron
2013-01-31 21:43 ` [RFC 08/11] iio: Update iio_channel_get_all and iio_channel_get_all_cb API Guenter Roeck
2013-01-31 21:43 ` Guenter Roeck
2013-02-02 10:14 ` Jonathan Cameron
2013-02-02 10:14 ` Jonathan Cameron
2013-01-31 21:43 ` [RFC 09/11] iio: Simplify iio_map_array_unregister API Guenter Roeck
2013-01-31 21:43 ` Guenter Roeck
2013-02-02 10:16 ` Jonathan Cameron
2013-02-02 10:16 ` Jonathan Cameron
2013-01-31 21:43 ` [RFC 10/11] iio: Add OF support Guenter Roeck
2013-01-31 21:43 ` Guenter Roeck
2013-01-31 22:20 ` Peter Meerwald
2013-01-31 22:46 ` Guenter Roeck
2013-02-01 11:58 ` Lars-Peter Clausen
2013-02-01 11:58 ` Lars-Peter Clausen
2013-02-01 14:33 ` Guenter Roeck
2013-02-01 14:33 ` Guenter Roeck
2013-02-01 14:59 ` Lars-Peter Clausen
2013-02-01 14:59 ` Lars-Peter Clausen
2013-02-01 19:42 ` Guenter Roeck
2013-02-01 19:42 ` Guenter Roeck
2013-02-02 14:37 ` Lars-Peter Clausen [this message]
2013-02-02 14:37 ` Lars-Peter Clausen
2013-02-02 16:14 ` Guenter Roeck
2013-02-02 16:14 ` Guenter Roeck
2013-02-02 10:29 ` Jonathan Cameron
2013-02-02 10:29 ` Jonathan Cameron
2013-02-02 16:10 ` Guenter Roeck
2013-02-02 16:10 ` Guenter Roeck
2013-02-03 11:39 ` Jonathan Cameron
2013-02-03 11:39 ` Jonathan Cameron
2013-02-03 11:47 ` Lars-Peter Clausen
2013-02-03 11:47 ` Lars-Peter Clausen
2013-02-03 11:52 ` Lars-Peter Clausen
2013-02-03 11:52 ` Lars-Peter Clausen
2013-02-03 11:57 ` Jonathan Cameron
2013-02-03 11:57 ` Jonathan Cameron
2013-02-03 16:28 ` Guenter Roeck
2013-02-03 16:28 ` Guenter Roeck
2013-01-31 21:43 ` [RFC 11/11] iio/adc: (max1363) Add basic OF bindings and external vref support Guenter Roeck
2013-01-31 21:43 ` Guenter Roeck
2013-02-02 10:33 ` Jonathan Cameron
2013-02-02 10:33 ` Jonathan Cameron
2013-02-02 16:13 ` Guenter Roeck
2013-02-02 16:13 ` Guenter Roeck
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=510D24BA.5000300@metafoo.de \
--to=lars@metafoo.de \
--cc=ch.naveen@samsung.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=dianders@chromium.org \
--cc=grant.likely@secretlab.ca \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=rob.herring@calxeda.com \
--cc=tomasz.figa@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 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.