[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E346BC0694@ORSMSX101.amr.corp.intel.com>
Date: Tue, 13 Nov 2012 16:34:07 +0000
From: "Moore, Robert" <robert.moore@...el.com>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>,
"Rafael J. Wysocki" <rjw@...k.pl>
CC: "mathias.nyman@...ux.intel.com" <mathias.nyman@...ux.intel.com>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"lenb@...nel.org" <lenb@...nel.org>,
"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
"broonie@...nsource.wolfsonmicro.com"
<broonie@...nsource.wolfsonmicro.com>,
"grant.likely@...retlab.ca" <grant.likely@...retlab.ca>,
"linus.walleij@...aro.org" <linus.walleij@...aro.org>,
"khali@...ux-fr.org" <khali@...ux-fr.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
"Zheng, Lv" <lv.zheng@...el.com>
Subject: RE: [PATCH 3/3] ACPI: Evaluate _CRS while creating device node
objects
> I suppose we can just do acpi_get_current_resources() and play with
> the buffer returned by it. That won't be nice, but still better than
> what we have.
A couple of the reasons we created the ACPICA resource manager was to:
1) Simplify host access to the various resource fields, especially packed flags.
2) Avoid alignment issues, especially on machines that don't support misaligned transfers.
If there are issues with the current resource manager, we can discuss them. But I would hope that you really don't want to be fussing around with the raw data coming back from the AML. It is not pretty and we have gone to some lengths to make the entire conversion table-driven to minimize bugs and simplify maintenance.
Bob
> -----Original Message-----
> From: Mika Westerberg [mailto:mika.westerberg@...ux.intel.com]
> Sent: Monday, November 12, 2012 11:12 PM
> To: Rafael J. Wysocki
> Cc: mathias.nyman@...ux.intel.com; linux-acpi@...r.kernel.org; linux-
> kernel@...r.kernel.org; lenb@...nel.org; Wysocki, Rafael J;
> broonie@...nsource.wolfsonmicro.com; grant.likely@...retlab.ca;
> linus.walleij@...aro.org; khali@...ux-fr.org; Bjorn Helgaas; Moore, Robert
> Subject: Re: [PATCH 3/3] ACPI: Evaluate _CRS while creating device node
> objects
>
> On Mon, Nov 12, 2012 at 10:03:56PM +0100, Rafael J. Wysocki wrote:
> > > > +static acpi_status acpi_bus_add_resource(struct acpi_resource *res,
> > > > + void *context)
> > > > +{
> > > > + struct list_head *list = context;
> > > > + struct acpi_resource_list_entry *entry;
> > > > +
> > > > + entry = kzalloc(sizeof(*entry), GFP_KERNEL);
> > > > + if (!entry)
> > > > + return AE_NO_MEMORY;
> > > > +
> > > > + entry->resource = *res;
> > >
> > > This does not work well with all resource types - specifically those
> > > that contain pointers, like acpi_resource_gpio and
> acpi_resource_source.
> >
> > Good point.
> >
> > Well, this pretty much means we can't copy those things.
>
> Yeah. I only noticed this yesterday when I tested the GPIO translation in
> a custom driver (since it uses the acpi_resource_gpio).
>
> > > The memory for the resources gets freed once acpi_walk_resources() is
> done.
> >
> > I know that.
> >
> > Having to evaluate _CRS and creating a buffer, converting the output
> > into ACPI resources and so on every time we need to look into the
> > device's current resources is totally inefficient. We _need_ to cache
> the _CRS output.
>
> I agree and besides having adev->resources is much easier to use than
> calling acpi_walk_resources() everytime.
>
> > Now, because of the pointers in certain types of resources, we can't
> > make copies of the resource objects used by acpi_walk_resources()
> > which makes that function totally unuseful to us.
> >
> > I suppose we can just do acpi_get_current_resources() and play with
> > the buffer returned by it. That won't be nice, but still better than
> > what we have.
>
> I don't know any better option.
>
> Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists