linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Lars-Peter Clausen <lars@metafoo.de>
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, 2 Feb 2013 08:14:48 -0800	[thread overview]
Message-ID: <20130202161448.GD10386@roeck-us.net> (raw)
In-Reply-To: <510D24BA.5000300@metafoo.de>

On Sat, Feb 02, 2013 at 03:37:46PM +0100, Lars-Peter Clausen wrote:
> 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.
> 
You are right. If I modify iio_get_channel to take the device pointer as
argument, it should work for both OF and non-OF with the approach you outlined
above.

Thanks,
Guenter

  reply	other threads:[~2013-02-02 16:14 UTC|newest]

Thread overview: 38+ 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 ` [PATCH 01/11] staging/iio: (iio_hwmon) Use devm_kzalloc Guenter Roeck
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-02-02  9:52   ` Jonathan Cameron
2013-01-31 21:43 ` [PATCH 03/11] staging/iio: (iio_hwmon) Basic devicetree support Guenter Roeck
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-02-02  9:55   ` Jonathan Cameron
2013-01-31 21:43 ` [PATCH 05/11] iio/adc: (max1363) " Guenter Roeck
2013-02-02 10:06   ` Jonathan Cameron
2013-01-31 21:43 ` [PATCH 06/11] iio/adc: (max1363) Remove duplicate code Guenter Roeck
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-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-02-02 10:14   ` Jonathan Cameron
2013-01-31 21:43 ` [RFC 09/11] iio: Simplify iio_map_array_unregister API Guenter Roeck
2013-02-02 10:16   ` Jonathan Cameron
2013-01-31 21:43 ` [RFC 10/11] iio: Add OF support 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 14:33     ` Guenter Roeck
2013-02-01 14:59       ` Lars-Peter Clausen
2013-02-01 19:42         ` Guenter Roeck
2013-02-02 14:37           ` Lars-Peter Clausen
2013-02-02 16:14             ` Guenter Roeck [this message]
2013-02-02 10:29   ` Jonathan Cameron
2013-02-02 16:10     ` Guenter Roeck
2013-02-03 11:39       ` Jonathan Cameron
2013-02-03 11:47         ` Lars-Peter Clausen
2013-02-03 11:52           ` Lars-Peter Clausen
2013-02-03 11:57             ` Jonathan Cameron
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-02-02 10:33   ` Jonathan Cameron
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=20130202161448.GD10386@roeck-us.net \
    --to=linux@roeck-us.net \
    --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=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --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 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).