From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: "Moore, Robert" <robert.moore@intel.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>,
"mathias.nyman@linux.intel.com" <mathias.nyman@linux.intel.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"lenb@kernel.org" <lenb@kernel.org>,
"Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
"broonie@opensource.wolfsonmicro.com"
<broonie@opensource.wolfsonmicro.com>,
"grant.likely@secretlab.ca" <grant.likely@secretlab.ca>,
"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
"khali@linux-fr.org" <khali@linux-fr.org>,
Bjorn Helgaas <bhelgaas@google.com>,
"Zheng, Lv" <lv.zheng@intel.com>
Subject: Re: [PATCH 3/3] ACPI: Evaluate _CRS while creating device node objects
Date: Wed, 14 Nov 2012 10:32:33 +0100 [thread overview]
Message-ID: <4910900.pJ82TKumIi@vostro.rjw.lan> (raw)
In-Reply-To: <5571446.V5xhWp9giY@vostro.rjw.lan>
On Wednesday, November 14, 2012 10:18:46 AM Rafael J. Wysocki wrote:
> On Wednesday, November 14, 2012 02:23:51 AM Moore, Robert wrote:
> > Rafael,
> >
> > I sounds like with a few changes, we can enhance this mechanism to
> > be more useful to you and others. Some comments below. I need to look
> > at the code in question a bit more, but I see no insurmountable issues.
>
> Great, thanks!
>
>
> > > -----Original Message-----
> > > From: Rafael J. Wysocki [mailto:rjw@sisk.pl]
> > > Sent: Tuesday, November 13, 2012 2:57 PM
> > > To: Moore, Robert
> > > Cc: Mika Westerberg; mathias.nyman@linux.intel.com; linux-
> > > acpi@vger.kernel.org; linux-kernel@vger.kernel.org; lenb@kernel.org;
> > > Wysocki, Rafael J; broonie@opensource.wolfsonmicro.com;
> > > grant.likely@secretlab.ca; linus.walleij@linaro.org; khali@linux-fr.org;
> > > Bjorn Helgaas; Zheng, Lv
> > > Subject: Re: [PATCH 3/3] ACPI: Evaluate _CRS while creating device node
> > > objects
> > >
> > > On Tuesday, November 13, 2012 10:06:03 PM Moore, Robert wrote:
> > > > I may not quite understand what you are asking for, but I will try.
> > > > It seems like we already have much of what you want/need, so maybe I'm
> > > > missing something.
> > >
> > > I think all of the necessary pieces are there.
> > >
> > > > > So what I would like to have, in general terms, is something like
> > > > > acpi_walk_resources() split into three parts:
> > > > >
> > > > > (1) One that processes the _CRS output and creates a list of
> > > > > struct acpi_resource objects for us to play with. I suppose
> > > > > it's OK if that's just a buffer filled with resource objects,
> > > > > but a linked list might be more convenient.
> > > > >
> > > >
> > > > This sounds like AcpiGetCurrentResources. It executes _CRS and formats
> > > > the data into acpi_resource objects.
> > >
> > > Yes, it does. However, it is not completely clear to me if/how the caller
> > > is supposed to prepare the buffer object pointed to by the second arg.
> > >
> > > If the buffer is initialized by AcpiGetCurrentResources, then that's what
> > > I need for (1).
> >
> >
> > It looks to me that at least AcpiGetCurrentResources does not actually ever
> > allocate a buffer for the resource template, it expects the caller to
> > eventually provide one of at least the size of the returned resource template.
> >
> > This is really quite a bit out-of-date as far as the memory allocation model.
> > It should also support the option to just allocate the buffer of the appropriate
> > size before returning it to the caller.
>
> Yes, that would be really useful.
>
> Ideally, I'd like to be able to pass a pointer to an uninitialized buffer
> structure to it (or to a wrapper around it) and get a buffer full of
> struct acpi_resource objects (if _CRS returns any) back from it. :-)
Of course, I can add such a wrapper in the Linux-specific code just fine.
> > > > > (2) One that allows us to access (read/write) resources in the
> > > > > list returned by (1). We don't need to open code walking
> > > > > the list and I probably wouldn't event want to do that. What
> > > > > we need is to be able to walk the same list for a number of
> > > > > times and possibly to modify values in the resource objects
> > > > > if there are conflicts.
> > > >
> > > > This sounds like AcpiWalkResources. I suppose a possible issue is that
> > > > currently, AcpiWalkResources actually invokes the _CRS, _PRS, or _AEI
> > > > method on behalf of the caller.
> > >
> > > Yes, that exactly is the problem.
> > >
> > > > It might make more sense to allow the caller to pass in the resource
> > > > buffer returned from a call to _CRS, etc.
> > >
> > > Yes! :-)
> >
> >
> > I'll take a closer look at this tomorrow.
>
> Cool, thanks!
>
>
> > > > > (3) One allowing us to free the list returned by (1) if not needed
> > > > > any more.
> > > > >
> > > >
> > > > AcpiGetCurrentResources: Currently, everything is returned in a single
> > > > buffer to minimize the number of allocations. A buffer you can free
> > > > when you are done with it.
> > >
> > > I suppose I should use ACPI_FREE(buffer.pointer) for that, but isn't it
> > > for the ACPICA's internal use only?
> > >
> > > Besides, I would prefer to be able to pass just "buffer" for freeing,
> > > without having to touch its internals. No big deal, but it would be
> > > nicer. :-)
> >
> >
> > The ACPI_BUFFER type is in fact a public type that is meant to return both the
> > buffer and the (actual) length. You will find many instances of
> > ACPI_FREE(buffer.pointer) within existing linux code, since it also used for
> > objects returned by control method execution/object evaluation.
>
> Well, I suppose I only wanted to say that acpi_free_buffer(buffer) would look
> a bit more straightforward than ACPI_FREE(buffer.pointer). :-)
And I can define acpi_free_buffer() in the Linux-specific code too.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
next prev parent reply other threads:[~2012-11-14 9:28 UTC|newest]
Thread overview: 119+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-03 7:46 [PATCH 0/3] ACPI 5 support for GPIO, SPI and I2C Mika Westerberg
2012-11-03 7:46 ` [PATCH 1/3] gpio / ACPI: add ACPI support Mika Westerberg
2012-11-05 11:53 ` Linus Walleij
2012-11-05 12:14 ` Mathias Nyman
2012-11-05 12:46 ` Rafael J. Wysocki
2012-11-05 13:11 ` Linus Walleij
2012-11-05 13:19 ` Rafael J. Wysocki
2012-11-05 13:28 ` Linus Walleij
2012-11-05 13:50 ` Rafael J. Wysocki
2012-11-05 14:40 ` Linus Walleij
2012-11-06 9:39 ` Mika Westerberg
2012-11-06 10:15 ` Linus Walleij
2012-11-07 8:54 ` Mika Westerberg
2012-11-08 15:55 ` Grant Likely
2012-11-08 19:38 ` Mika Westerberg
2012-11-09 14:11 ` Mathias Nyman
2012-11-09 14:18 ` Grant Likely
2012-11-09 15:05 ` Mathias Nyman
2012-11-09 15:46 ` Grant Likely
2012-11-11 9:50 ` Mika Westerberg
2012-11-03 7:46 ` [PATCH 2/3] spi / ACPI: add ACPI enumeration support Mika Westerberg
2012-11-03 19:42 ` Bjorn Helgaas
2012-11-03 20:13 ` Mika Westerberg
2012-11-03 20:59 ` Rafael J. Wysocki
2012-11-05 10:31 ` Rafael J. Wysocki
2012-11-05 10:56 ` Mika Westerberg
2012-11-05 10:56 ` Mark Brown
2012-11-05 12:02 ` Mika Westerberg
2012-11-05 12:23 ` Jean Delvare
2012-11-05 12:59 ` Rafael J. Wysocki
2012-11-05 13:15 ` Mika Westerberg
2012-11-05 13:20 ` Linus Walleij
2012-11-05 13:43 ` Mika Westerberg
2012-11-05 14:03 ` Jean Delvare
2012-11-05 14:19 ` Rafael J. Wysocki
2012-11-05 14:53 ` Mika Westerberg
2012-11-05 15:19 ` Jean Delvare
2012-11-05 17:12 ` Mika Westerberg
2012-11-05 17:43 ` Bjorn Helgaas
2012-11-05 18:08 ` Mika Westerberg
2012-11-05 17:49 ` Jean Delvare
2012-11-05 20:42 ` Linus Walleij
2012-11-06 8:11 ` Mark Brown
2012-11-05 16:54 ` Bjorn Helgaas
2012-11-06 13:43 ` Rafael J. Wysocki
2012-11-06 20:35 ` Bjorn Helgaas
2012-11-06 22:28 ` Rafael J. Wysocki
2012-11-06 22:36 ` Rafael J. Wysocki
2012-11-07 9:58 ` Mika Westerberg
2012-11-07 11:14 ` Rafael J. Wysocki
2012-11-07 13:05 ` Mika Westerberg
2012-11-08 0:46 ` Rafael J. Wysocki
2012-11-08 20:20 ` Mika Westerberg
2012-11-08 20:54 ` Rafael J. Wysocki
2012-11-08 18:05 ` Grant Likely
2012-11-08 21:06 ` Rafael J. Wysocki
2012-11-08 21:34 ` Grant Likely
2012-11-05 10:54 ` Mark Brown
2012-11-03 20:39 ` Rafael J. Wysocki
2012-11-05 16:54 ` Bjorn Helgaas
2012-11-06 13:16 ` Rafael J. Wysocki
2012-11-06 20:53 ` Bjorn Helgaas
2012-11-06 22:18 ` Rafael J. Wysocki
2012-11-07 9:56 ` Mika Westerberg
2012-11-08 19:32 ` Bjorn Helgaas
2012-11-08 20:04 ` Mika Westerberg
2012-11-09 15:11 ` Bjorn Helgaas
2012-11-09 15:45 ` Grant Likely
2012-11-09 16:35 ` Bjorn Helgaas
2012-11-09 16:43 ` Grant Likely
2012-11-09 16:48 ` Mark Brown
2012-11-09 16:53 ` Bjorn Helgaas
2012-11-10 11:10 ` Rafael J. Wysocki
2012-11-10 11:16 ` Grant Likely
2012-11-10 17:14 ` Bjorn Helgaas
2012-11-10 19:40 ` Rafael J. Wysocki
2012-11-05 10:54 ` Mark Brown
2012-11-05 11:03 ` Mika Westerberg
2012-11-05 11:13 ` Mark Brown
2012-11-08 18:48 ` Grant Likely
2012-11-09 3:50 ` Mika Westerberg
2012-11-03 7:46 ` [PATCH 3/3] i2c " Mika Westerberg
2012-11-03 21:52 ` Jean Delvare
2012-11-04 7:23 ` Mika Westerberg
2012-11-04 8:50 ` Jean Delvare
2012-11-04 10:50 ` Mika Westerberg
2012-11-08 18:58 ` Grant Likely
2012-11-09 3:51 ` Mika Westerberg
2012-11-04 18:29 ` [PATCH 0/3] ACPI 5 support for GPIO, SPI and I2C Linus Walleij
2012-11-05 9:23 ` Mika Westerberg
2012-11-12 11:51 ` [PATCH 0/3] Centralized parsing of ACPI device resources (was: Re: [PATCH 0/3] ACPI 5 support for GPIO, SPI and I2C) Rafael J. Wysocki
2012-11-12 12:00 ` [PATCH 1/3] ACPI: Move device resources interpretation code from PNP to ACPI core Rafael J. Wysocki
2012-11-12 13:27 ` Mika Westerberg
2012-11-12 20:25 ` [Update][PATCH " Rafael J. Wysocki
2012-11-12 12:01 ` [PATCH 2/3] ACPI / platform: Use common ACPI device resource parsing routines Rafael J. Wysocki
2012-11-12 12:02 ` [PATCH 3/3] ACPI: Evaluate _CRS while creating device node objects Rafael J. Wysocki
2012-11-12 14:46 ` Mika Westerberg
2012-11-12 21:03 ` Rafael J. Wysocki
2012-11-13 7:12 ` Mika Westerberg
2012-11-13 12:06 ` [Replacement][PATCH 3/3] Rafael J. Wysocki
2012-11-13 14:16 ` Mika Westerberg
2012-11-13 15:15 ` Rafael J. Wysocki
2012-11-13 15:18 ` Mika Westerberg
2012-11-13 15:28 ` Rafael J. Wysocki
2012-11-13 15:37 ` Mika Westerberg
2012-11-13 16:34 ` [PATCH 3/3] ACPI: Evaluate _CRS while creating device node objects Moore, Robert
2012-11-13 20:44 ` Rafael J. Wysocki
2012-11-13 22:06 ` Moore, Robert
2012-11-13 22:56 ` Rafael J. Wysocki
2012-11-14 2:23 ` Moore, Robert
2012-11-14 9:18 ` Rafael J. Wysocki
2012-11-14 9:32 ` Rafael J. Wysocki [this message]
2012-11-14 14:20 ` Moore, Robert
2012-11-13 20:51 ` [PATCH 0/3 rev 2] Centralized parsing of ACPI device resources Rafael J. Wysocki
2012-11-13 20:55 ` [PATCH 1/3 rev 2] ACPI: Move device resources interpretation code from PNP to ACPI core Rafael J. Wysocki
2012-11-13 20:55 ` [PATCH 2/3 rev 2] ACPI / platform: Use common ACPI device resource parsing routines Rafael J. Wysocki
2012-11-13 20:56 ` [PATCH 3/3 rev 2] ACPI: Centralized processing of ACPI device resources Rafael J. Wysocki
2012-11-14 9:52 ` [PATCH 0/3 rev 2] Centralized parsing " Mika Westerberg
2012-11-14 10:08 ` Rafael J. Wysocki
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=4910900.pJ82TKumIi@vostro.rjw.lan \
--to=rjw@sisk.pl \
--cc=bhelgaas@google.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=grant.likely@secretlab.ca \
--cc=khali@linux-fr.org \
--cc=lenb@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lv.zheng@intel.com \
--cc=mathias.nyman@linux.intel.com \
--cc=mika.westerberg@linux.intel.com \
--cc=rafael.j.wysocki@intel.com \
--cc=robert.moore@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;
as well as URLs for NNTP newsgroup(s).