[RFC] acpi _CRS analyzation for PCMCIA resource management

[Dominik Brodowski]

On Sun, Mar 28, 2004 at 06:06:12PM +0100, Russell King wrote:
> On Sun, Mar 28, 2004 at 06:50:07PM +0200, Dominik Brodowski wrote:
> > On Sun, Mar 28, 2004 at 03:11:18PM +0100, Russell King wrote:
> > > I therefore think it should be manipulating the kernels central resource
> > > manager rather than trying to produce some new separate database.
> > 
> > Also, manipulating the kernel's central resource manager is impossible for
> > the ACPI case: even though there's an ACPI name for each, let's say, PCI
> > object or serial port, in most cases there's no direct "pointer" from the
> > ACPI object to the linux kernel device object. And all device drivers would
> > need to become aware of ACPI then, and this is something we should try very
> > hard to avoid:
> > 
> > let's assume a resource are is marked as "consumed" by an ACPI _CRS object,
> > but it is not yet marked as "used" by the kernel's resource manager.
> 
> You wouldn't particularly want to mark any object given by CRS as
> "comsumed" or, in Linux kernel speak, "busy".  Drivers are the only
> things which should insert resources into the resource tree which
> are marked as being busy.
> 
> Everything else (iow, bus management) should add resources which are
> not marked busy.

Unfortunately, on the x86 there's very much the BIOS does without telling
the OS or the user... and then some resources are _used_ and thus "busy",
but without any driver knowing about it...

> allocate_resource() on the other hand will only allocate a region
> directly from the parent resource.  If there is sibling resource,
> busy or not, that region will be ignored.
> 
> So, all you need do is after the PCI bus probe, scan CRS and add
> non-busy resources to the resource tree for each area marked in
> ACPI.

For "consumed" CRS resources, agreed. There should be a scan of "produced"
CRS resources, and the "holes" in between "produced" CRS resources should be
filled with "reserved/not available" (non-busy, though) resources.

> When drivers want to use these resources, they will use the standard
> request_region/request_mem_region.  These will descend the tree until
> they hit a busy resource (and fail) or the non-busy resource to which
> the requested resource should be parented.

Ah. A light starts flashing in my head...

> So, by registering the CRS resources, you're not preventing drivers
> which know "hey, I'm *definitely* supposed to be here" from having
> to do anything extra, but you do prevent new resources being allocated
> where CRS indicates there is already some other usage.

Excellent.

> > This might change if the platform_data pointer in the driver model
> > is finally filled with life, as Patrick Mochel once intended to do...
> 
> Erk.  Please don't think like that - that is a completely incorrect
> thought about platform_data.  platform_data is there for *platform
> specific* data to be placed, not driver specific data, unless the
> driver is platform specific.  Cross-architecture drivers should not
> make any assumption what so ever about any data held in that pointer.

Quoting linux/include/device.h:
        void            *platform_data; /* Platform specific data (e.g. ACPI,
                                           BIOS data relevant to device) */

so I think platform_data may contain an acpi_handle in future, which would
let us access the device's _CRS and then indeed allocate_resource() from a
parent (in ACPI view parent!) resource "producer".

Will send out a new patch out for comments in the next few days.

	Dominik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-pcmcia/attachments/20040328/5cc90eac/attachment.bin