All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Guenter Roeck <linux@roeck-us.net>,
	Darren Hart <dvhart@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: ACPI vs Device Tree - moving forward
Date: Wed, 21 Aug 2013 17:09:03 +0100	[thread overview]
Message-ID: <20130821160903.GA11908@srcf.ucam.org> (raw)
In-Reply-To: <CACRpkdaVz28gn-keUC4tTX+bdTKEV2ZrdHxshG=K3oM_NhvroA@mail.gmail.com>

On Wed, Aug 21, 2013 at 05:57:07PM +0200, Linus Walleij wrote:

> - The I2C address is specified in "reg" - maybe ACPI have
>   some other way to assign I2C addresses to I2C devices?
>   In any case, it *must* reference the parent I2C controller,
>   here that is done implicitly by placing this DT node inside
>   the I2C controllers DT node.

That's fine. You put the child device inside the I2C contorller's scope, 
which can be done from a separate ACPI table if you want. The address 
can be provided via _ADR().

> - Then it is using a GPIO line as interrupt, and specify that
>   this shall be configured as a falling edge IRQ.

ACPI 5 permits this.

> - It then tells the interrupt controller parent. So it needs
>   to have a reference to whatever interrupt chip device
>   will handle that IRQ.

By interrupt controller, do you mean the GPIO controller? ACPI GPIO 
definitions include the parent device.

> - Further it *is* an interrupt controller, so devices connected
>   to the GPIO lines may generate IRQs and then this
>   device should service them. Is it possible that the devices
>   connected to this expander in turn use ACPI to describe
>   themselves? Then we need a reference in the other
>   direction.

I think that's also doable.

> - Further it is a wakeup source, so each IRQ it provides
>   on its GPIO lines can be set as a wakeup. I wonder how
>   this plays with D-states and ACPI.

That's fine. GPIO lines can be described as causing ACPI events and then 
that simply referenced as a wakeup event.

> I did present the above as an extreme example, but if we
> start to combine DT and ACPI we have to have that kind of
> hardware in mind. GPIO expanders with IRQs and all are
> maybe rare on desktops and laptops but very common on
> embedded systems.

Yeah, describing complicated device topology isn't really the problem I 
think we'll end up facing - it's the wider range of device configuration 
data that worries me.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

  reply	other threads:[~2013-08-21 16:09 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-20 19:26 ACPI vs Device Tree - moving forward Matthew Garrett
2013-08-20 20:51 ` Darren Hart
2013-08-20 20:57   ` Matthew Garrett
2013-08-20 21:03     ` Darren Hart
2013-08-20 21:13     ` Rafael J. Wysocki
2013-08-20 21:36     ` Guenter Roeck
2013-08-20 21:11 ` Rafael J. Wysocki
2013-08-20 23:29   ` Rafael J. Wysocki
2013-08-21 15:57   ` Linus Walleij
2013-08-21 16:09     ` Matthew Garrett [this message]
2013-08-21 23:11       ` Rafael J. Wysocki
2013-08-21 23:39         ` Matthew Garrett
2013-08-22  0:02           ` Rafael J. Wysocki
2013-08-22  0:03             ` Matthew Garrett
2013-08-23 23:25               ` Darren Hart
2013-08-23 23:38                 ` Matthew Garrett
2013-08-23 23:45                   ` Darren Hart
2013-08-24  0:13                     ` Guenter Roeck
2013-08-24  1:10                       ` Matthew Garrett
2013-08-24  1:47                         ` Guenter Roeck
2013-08-24  2:38                           ` Matthew Garrett
2013-08-24  2:55                             ` Guenter Roeck
2013-08-24  3:06                               ` Matthew Garrett
2013-08-24  4:45                                 ` Guenter Roeck
2013-08-24  4:51                                   ` Matthew Garrett
2013-08-24  5:30                                     ` Guenter Roeck
2013-08-26  9:32                       ` Linus Walleij
2013-08-26 10:48                         ` Graeme Gregory

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=20130821160903.GA11908@srcf.ucam.org \
    --to=mjg59@srcf.ucam.org \
    --cc=dvhart@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=rjw@sisk.pl \
    /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.