From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Mark Brown <broonie@sirena.org.uk>
Cc: dvhart@dvhart.com, ksummit-discuss@lists.linuxfoundation.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Driver model/resources, ACPI, DT, etc (sigh)
Date: Mon, 19 May 2014 01:56:33 +0200 [thread overview]
Message-ID: <1785175.GYZBbEJPJC@vostro.rjw.lan> (raw)
In-Reply-To: <20140517132423.GX22111@sirena.org.uk>
On Saturday, May 17, 2014 02:24:23 PM Mark Brown wrote:
>
> --ucW7QTJbHsz5ya91
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Thu, May 15, 2014 at 02:05:43PM +0200, Rafael J. Wysocki wrote:
> > On Wednesday, May 14, 2014 02:04:01 PM Mark Brown wrote:
>
> > > Of course, and for all of these things other than GPIOs we already
> > > handle the lookups without any DT code at all in the drivers (and GPIOs
> > > are moving away from needing explicit code too). Things like that just
> > > aren't an issue and I'd say that if we are adding new fw_ interfaces for
> > > resource lookup like you describe we're doing things wrong, we already
> > > have the idiom of looking up by device and some key which works well.
>
> > The "key" think doesn't really work in ACPI if it is a string, however.
>
> > That's a real problem, because, for example, ACPI says "I have these GPIO
> > connections between your device and controller X" and it gives you pin
> > numbers. Now the driver (or someone else) needs to figure out which pin
> > is used for what.
>
> > If there's only one pin per device, all is fine, but if there are more of
> > them things get very ugly quite quickly.
>
> > So in "native" ACPI something like gpiod_get() cannot really be implemented
> > to use con_id and if you look at acpi_find_gpio() (the one in gpiolib.c),
> > you'll see that it actually only uses the index for this very reason.
>
> Surely all we need to do for these cases is provide a way for drivers to
> supply the name to number mappings for usage with ACPI (probably with
> per device and per board overrides possible due to all the failures
> usually associated with numbers)?
Yes, we can do that for things like gpiod_get() that already abstract the
firmware interface away from device drivers.
> That's much less invasive than making new APIs.
But for drivers that call of_get_something() directly I don't see any other
sensible way forward. Otherwise each of them will need to do something like
if (dev->of_node)
use of_get_X()
else if (ACPI_COMPANION(dev))
use acpi_get_X()
else
use black magic
possibly in several places.
Rafael
next prev parent reply other threads:[~2014-05-18 23:39 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-02 21:42 Olof Johansson
2014-05-03 0:05 ` Rafael J. Wysocki
2014-05-03 2:02 ` Mark Brown
2014-05-04 12:28 ` Rafael J. Wysocki
2014-05-05 8:45 ` Benjamin Herrenschmidt
2014-05-05 19:06 ` Mark Brown
2014-05-06 12:22 ` Rafael J. Wysocki
2014-05-12 21:59 ` Mark Brown
2014-05-12 22:03 ` Rafael J. Wysocki
2014-05-13 7:34 ` Arnd Bergmann
2014-05-13 10:47 ` Rafael J. Wysocki
2014-05-13 12:11 ` Mark Brown
2014-05-13 13:08 ` Arnd Bergmann
2014-05-13 19:31 ` Mark Brown
2014-05-13 19:53 ` Arnd Bergmann
2014-05-13 21:19 ` Rafael J. Wysocki
2014-05-14 13:04 ` Mark Brown
2014-05-15 12:05 ` Rafael J. Wysocki
2014-05-17 1:11 ` Darren Vincent Hart
2014-05-19 0:02 ` Rafael J. Wysocki
2014-05-17 13:24 ` Mark Brown
2014-05-18 23:56 ` Rafael J. Wysocki [this message]
2014-05-23 17:33 ` Mark Brown
2014-05-26 21:19 ` Linus Walleij
2014-05-26 21:55 ` Rafael J. Wysocki
2014-05-13 20:02 ` Olof Johansson
2014-05-17 3:57 ` Darren Vincent Hart
2014-05-17 13:09 ` Mark Brown
2014-05-17 6:52 ` Darren Vincent Hart
2014-05-23 17:21 ` Mark Brown
2014-05-03 15:14 ` Arnd Bergmann
2014-05-04 11:14 ` Catalin Marinas
2014-05-04 17:18 ` Olof Johansson
2014-05-04 17:27 ` Guenter Roeck
2014-05-04 22:02 ` Rafael J. Wysocki
2014-05-05 2:44 ` Pantelis Antoniou
2014-05-05 11:22 ` Rafael J. Wysocki
2014-05-05 2:52 ` Pantelis Antoniou
2014-05-05 4:21 ` Guenter Roeck
2014-05-05 23:05 ` Pantelis Antoniou
2014-05-04 21:33 ` Rafael J. Wysocki
2014-05-05 8:43 ` Benjamin Herrenschmidt
2014-05-05 11:32 ` Rafael J. Wysocki
2014-05-05 11:31 ` Benjamin Herrenschmidt
2014-05-06 12:18 ` Rafael J. Wysocki
2014-05-06 13:35 ` Arnd Bergmann
2014-05-08 0:16 ` Rafael J. Wysocki
2014-05-12 6:21 ` Benjamin Herrenschmidt
2014-05-13 21:14 ` Olof Johansson
2014-05-13 21:40 ` Rafael J. Wysocki
2014-05-13 21:28 ` Olof Johansson
2014-05-13 21:51 ` Rafael J. Wysocki
2014-05-17 3:22 ` Darren Vincent Hart
2014-05-14 12:06 ` Arnd Bergmann
2014-05-14 12:25 ` Mark Brown
2014-05-18 16:34 ` Linus Walleij
2014-05-14 12:31 ` Rafael J. Wysocki
2014-05-17 3:02 ` Darren Vincent Hart
2014-05-17 2:57 ` Darren Vincent Hart
2014-05-18 16:31 ` Linus Walleij
2014-05-05 15:09 ` Rob Herring
2014-05-05 16:02 ` Jason Cooper
2014-05-05 16:41 ` Thomas Petazzoni
2014-05-05 22:55 ` Benjamin Herrenschmidt
2014-05-17 2:32 ` Darren Vincent Hart
2014-05-05 8:39 ` Benjamin Herrenschmidt
2014-05-05 11:37 ` Rafael J. Wysocki
2014-05-07 11:05 ` David Woodhouse
2014-05-07 13:06 ` Rafael J. Wysocki
2014-05-08 3:27 ` Benjamin Herrenschmidt
2014-05-17 2:05 ` Darren Vincent Hart
2014-05-17 1:54 ` Darren Vincent Hart
2014-05-17 23:03 ` Benjamin Herrenschmidt
2014-05-18 20:28 ` Linus Walleij
2014-05-18 16:12 ` Darren Vincent Hart
2014-05-19 20:53 ` Rafael J. Wysocki
2014-05-04 10:56 ` Catalin Marinas
2014-05-04 12:19 ` Rafael J. Wysocki
2014-05-04 17:23 ` Olof Johansson
2014-05-04 21:58 ` Rafael J. Wysocki
2014-05-06 2:41 ` Linus Walleij
2014-05-06 11:41 ` Rafael J. Wysocki
2014-05-08 11:36 ` Linus Walleij
2014-05-08 12:08 ` Rafael J. Wysocki
2014-05-17 4:39 ` Darren Vincent Hart
2014-05-17 4:33 ` Darren Vincent Hart
2014-05-03 0:23 ` Darren Hart
2014-05-05 16:58 ` Linus Walleij
2014-05-06 5:02 ` Darren Hart
2014-05-17 0:32 ` Darren Vincent Hart
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=1785175.GYZBbEJPJC@vostro.rjw.lan \
--to=rjw@rjwysocki.net \
--cc=broonie@sirena.org.uk \
--cc=dvhart@dvhart.com \
--cc=gregkh@linuxfoundation.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=mika.westerberg@linux.intel.com \
--cc=rafael.j.wysocki@intel.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