[RFC] acpi _CRS analyzation for PCMCIA resource management
Russell King
rmk+pcmcia at arm.linux.org.uk
Sun Mar 28 19:06:12 BST 2004
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.
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.
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.
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.
> Not marking the resource as "used" is a no-go too: then PCMCIA would freely
> access this space...
Not true - see my comments concerning allocate_resource() above.
> 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.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
More information about the linux-pcmcia
mailing list