On Mon, Aug 26, 2013 at 11:32:44AM +0200, Linus Walleij wrote:
> On Sat, Aug 24, 2013 at 2:13 AM, Guenter Roeck wrote:
>
> > Did the group conclude that the idea of FDT augmenting ACPI is not feasible
> > ?
>
> I don't think anyone really knows. For example: how to specify a few
> config option
On Sat, Aug 24, 2013 at 2:13 AM, Guenter Roeck wrote:
> Did the group conclude that the idea of FDT augmenting ACPI is not feasible ?
I don't think anyone really knows. For example: how to specify a few
config options through a FDT augmented ACPI system is trivial. Passing
system-wide resources
On 08/23/2013 09:51 PM, Matthew Garrett wrote:
On Fri, Aug 23, 2013 at 09:45:10PM -0700, Guenter Roeck wrote:
"What happens when you have an ACPI device that contains an interrupt in
_CRS and contains a different interrupt in an embedded FDT block?"
Does the situation occur today, ie does it
On Fri, Aug 23, 2013 at 09:45:10PM -0700, Guenter Roeck wrote:
> "What happens when you have an ACPI device that contains an interrupt in
> _CRS and contains a different interrupt in an embedded FDT block?"
>
> Does the situation occur today, ie does it ever happen that one interrupt
> for a dev
On 08/23/2013 08:06 PM, Matthew Garrett wrote:
On Fri, Aug 23, 2013 at 07:55:31PM -0700, Guenter Roeck wrote:
Question is: Does this work _today_ with any existing driver, where
one interrupt is served through ACPI and another as 'standard' Linux
interrupt ? If yes, it must be working, and usin
On Fri, Aug 23, 2013 at 07:55:31PM -0700, Guenter Roeck wrote:
> Question is: Does this work _today_ with any existing driver, where
> one interrupt is served through ACPI and another as 'standard' Linux
> interrupt ? If yes, it must be working, and using fdt to describe
> the interrupt mapping fo
On 08/23/2013 07:38 PM, Matthew Garrett wrote:
On Fri, Aug 23, 2013 at 06:47:23PM -0700, Guenter Roeck wrote:
On Sat, Aug 24, 2013 at 02:10:36AM +0100, Matthew Garrett wrote:
On Fri, Aug 23, 2013 at 05:13:45PM -0700, Guenter Roeck wrote:
Did the group conclude that the idea of FDT augmenting
On Fri, Aug 23, 2013 at 06:47:23PM -0700, Guenter Roeck wrote:
> On Sat, Aug 24, 2013 at 02:10:36AM +0100, Matthew Garrett wrote:
> > On Fri, Aug 23, 2013 at 05:13:45PM -0700, Guenter Roeck wrote:
> >
> > > Did the group conclude that the idea of FDT augmenting ACPI is not
> > > feasible ?
> >
On Sat, Aug 24, 2013 at 02:10:36AM +0100, Matthew Garrett wrote:
> On Fri, Aug 23, 2013 at 05:13:45PM -0700, Guenter Roeck wrote:
>
> > Did the group conclude that the idea of FDT augmenting ACPI is not feasible
> > ?
>
> I think expressing FDT in ACPI is feasible, I'm just not sure it's
> des
On Fri, Aug 23, 2013 at 05:13:45PM -0700, Guenter Roeck wrote:
> Did the group conclude that the idea of FDT augmenting ACPI is not feasible ?
I think expressing FDT in ACPI is feasible, I'm just not sure it's
desirable. We'd still end up with duplicate information and no mechanism
for drivers
On Fri, Aug 23, 2013 at 04:45:48PM -0700, Darren Hart wrote:
> On Sat, 2013-08-24 at 00:38 +0100, Matthew Garrett wrote:
> > On Fri, Aug 23, 2013 at 04:25:43PM -0700, Darren Hart wrote:
> >
> > > It had been my hope at the start of this project to open the creation of
> > > SSDTs up to inventors a
On Sat, 2013-08-24 at 00:38 +0100, Matthew Garrett wrote:
> On Fri, Aug 23, 2013 at 04:25:43PM -0700, Darren Hart wrote:
>
> > It had been my hope at the start of this project to open the creation of
> > SSDTs up to inventors and hackers who want to create Lures for the
> > MinnowBoard in such a w
On Fri, Aug 23, 2013 at 04:25:43PM -0700, Darren Hart wrote:
> It had been my hope at the start of this project to open the creation of
> SSDTs up to inventors and hackers who want to create Lures for the
> MinnowBoard in such a way that they could write these SSDTs and load
> them from a file at
On Thu, 2013-08-22 at 01:03 +0100, Matthew Garrett wrote:
> On Thu, Aug 22, 2013 at 02:02:29AM +0200, Rafael J. Wysocki wrote:
>
> > And now the practice appears to be that vendors actually ship some ACPI
> > tables with their systems, but those ACPI tables do not contain information
> > needed to
On Thu, Aug 22, 2013 at 02:02:29AM +0200, Rafael J. Wysocki wrote:
> And now the practice appears to be that vendors actually ship some ACPI
> tables with their systems, but those ACPI tables do not contain information
> needed to enumerate all devices. On the other hand, it is known what the
> D
On Thursday, August 22, 2013 12:39:42 AM Matthew Garrett wrote:
> On Thu, Aug 22, 2013 at 01:11:14AM +0200, Rafael J. Wysocki wrote:
>
> > Moreover, even if we are able to instruct everyone interested how to create
> > the requisite ACPI tables, there is the little problem of shipping them
> > som
On Thu, Aug 22, 2013 at 01:11:14AM +0200, Rafael J. Wysocki wrote:
> Moreover, even if we are able to instruct everyone interested how to create
> the requisite ACPI tables, there is the little problem of shipping them
> somehow so that they actually can be used by the kernel that needs to be
> ad
On Wednesday, August 21, 2013 05:09:03 PM Matthew Garrett wrote:
> 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
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
On Tue, Aug 20, 2013 at 11:11 PM, Rafael J. Wysocki wrote:
> There's one more problematic case which is that some systems ship with ACPI
> tables that don't contain all of the information necessary to enumerate
> hardware appropriately and it's difficult, if not impossible, to convince
> the vend
On Tuesday, August 20, 2013 11:11:09 PM Rafael J. Wysocki wrote:
> On Tuesday, August 20, 2013 08:26:50 PM Matthew Garrett wrote:
> > This conversation seems to have pretty much entirely ended up happening
> > on ksummit-discuss, which doesn't seem that useful. So let's have
> > another go with a
On Tue, Aug 20, 2013 at 09:57:13PM +0100, Matthew Garrett wrote:
> On Tue, Aug 20, 2013 at 01:51:03PM -0700, Darren Hart wrote:
>
> > It seems to me that the only way to end up in a situation where the data
> > is reused by other OSes, is to go through a standards body. What about
> > attempting t
On Tue, 2013-08-20 at 21:57 +0100, Matthew Garrett wrote:
> On Tue, Aug 20, 2013 at 01:51:03PM -0700, Darren Hart wrote:
>
> > It seems to me that the only way to end up in a situation where the data
> > is reused by other OSes, is to go through a standards body. What about
> > attempting to stand
On Tuesday, August 20, 2013 09:57:13 PM Matthew Garrett wrote:
> On Tue, Aug 20, 2013 at 01:51:03PM -0700, Darren Hart wrote:
>
> > It seems to me that the only way to end up in a situation where the data
> > is reused by other OSes, is to go through a standards body. What about
> > attempting to
On Tuesday, August 20, 2013 08:26:50 PM Matthew Garrett wrote:
> This conversation seems to have pretty much entirely ended up happening
> on ksummit-discuss, which doesn't seem that useful. So let's have
> another go with a wider audience (and where I don't have to sign up for
> yet another mai
On Tue, Aug 20, 2013 at 01:51:03PM -0700, Darren Hart wrote:
> It seems to me that the only way to end up in a situation where the data
> is reused by other OSes, is to go through a standards body. What about
> attempting to standardize the _DSM method? I suppose the challenge then
> is how do we
On Tue, 2013-08-20 at 20:26 +0100, Matthew Garrett wrote:
> This conversation seems to have pretty much entirely ended up happening
> on ksummit-discuss, which doesn't seem that useful. So let's have
> another go with a wider audience (and where I don't have to sign up for
> yet another mailing
27 matches
Mail list logo
