2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
|
* pnpacpi -- PnP ACPI driver
|
|
|
|
|
*
|
|
|
|
|
* Copyright (c) 2004 Matthieu Castet <castet.matthieu@free.fr>
|
|
|
|
|
* Copyright (c) 2004 Li Shaohua <shaohua.li@intel.com>
|
2008-06-28 06:57:19 +08:00
|
|
|
* Copyright (C) 2008 Hewlett-Packard Development Company, L.P.
|
|
|
|
|
* Bjorn Helgaas <bjorn.helgaas@hp.com>
|
[ACPI] ACPICA 20050930
Completed a major overhaul of the Resource Manager code -
specifically, optimizations in the area of the AML/internal
resource conversion code. The code has been optimized to
simplify and eliminate duplicated code, CPU stack use has
been decreased by optimizing function parameters and local
variables, and naming conventions across the manager have
been standardized for clarity and ease of maintenance (this
includes function, parameter, variable, and struct/typedef
names.)
All Resource Manager dispatch and information tables have
been moved to a single location for clarity and ease of
maintenance. One new file was created, named "rsinfo.c".
The ACPI return macros (return_ACPI_STATUS, etc.) have
been modified to guarantee that the argument is
not evaluated twice, making them less prone to macro
side-effects. However, since there exists the possibility
of additional stack use if a particular compiler cannot
optimize them (such as in the debug generation case),
the original macros are optionally available. Note that
some invocations of the return_VALUE macro may now cause
size mismatch warnings; the return_UINT8 and return_UINT32
macros are provided to eliminate these. (From Randy Dunlap)
Implemented a new mechanism to enable debug tracing for
individual control methods. A new external interface,
acpi_debug_trace(), is provided to enable this mechanism. The
intent is to allow the host OS to easily enable and disable
tracing for problematic control methods. This interface
can be easily exposed to a user or debugger interface if
desired. See the file psxface.c for details.
acpi_ut_callocate() will now return a valid pointer if a
length of zero is specified - a length of one is used
and a warning is issued. This matches the behavior of
acpi_ut_allocate().
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 07:03:00 +08:00
|
|
|
*
|
2005-04-17 06:20:36 +08:00
|
|
|
* This program is free software; you can redistribute it and/or modify it
|
|
|
|
|
* under the terms of the GNU General Public License as published by the
|
|
|
|
|
* Free Software Foundation; either version 2, or (at your option) any
|
|
|
|
|
* later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful, but
|
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
|
* General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
|
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
|
|
|
|
*/
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
|
#include <linux/acpi.h>
|
|
|
|
|
#include <linux/pci.h>
|
2008-04-29 06:34:28 +08:00
|
|
|
#include <linux/pnp.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2008-04-29 06:34:28 +08:00
|
|
|
#include "../base.h"
|
2005-04-17 06:20:36 +08:00
|
|
|
#include "pnpacpi.h"
|
|
|
|
|
|
2008-06-10 07:52:04 +08:00
|
|
|
static void decode_irq_flags(struct pnp_dev *dev, int flags, int *triggering,
|
2008-06-10 07:52:05 +08:00
|
|
|
int *polarity, int *shareable)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-06-10 07:52:04 +08:00
|
|
|
switch (flags & (IORESOURCE_IRQ_LOWLEVEL | IORESOURCE_IRQ_HIGHLEVEL |
|
|
|
|
|
IORESOURCE_IRQ_LOWEDGE | IORESOURCE_IRQ_HIGHEDGE)) {
|
2005-04-17 06:20:36 +08:00
|
|
|
case IORESOURCE_IRQ_LOWLEVEL:
|
[ACPI] ACPICA 20050930
Completed a major overhaul of the Resource Manager code -
specifically, optimizations in the area of the AML/internal
resource conversion code. The code has been optimized to
simplify and eliminate duplicated code, CPU stack use has
been decreased by optimizing function parameters and local
variables, and naming conventions across the manager have
been standardized for clarity and ease of maintenance (this
includes function, parameter, variable, and struct/typedef
names.)
All Resource Manager dispatch and information tables have
been moved to a single location for clarity and ease of
maintenance. One new file was created, named "rsinfo.c".
The ACPI return macros (return_ACPI_STATUS, etc.) have
been modified to guarantee that the argument is
not evaluated twice, making them less prone to macro
side-effects. However, since there exists the possibility
of additional stack use if a particular compiler cannot
optimize them (such as in the debug generation case),
the original macros are optionally available. Note that
some invocations of the return_VALUE macro may now cause
size mismatch warnings; the return_UINT8 and return_UINT32
macros are provided to eliminate these. (From Randy Dunlap)
Implemented a new mechanism to enable debug tracing for
individual control methods. A new external interface,
acpi_debug_trace(), is provided to enable this mechanism. The
intent is to allow the host OS to easily enable and disable
tracing for problematic control methods. This interface
can be easily exposed to a user or debugger interface if
desired. See the file psxface.c for details.
acpi_ut_callocate() will now return a valid pointer if a
length of zero is specified - a length of one is used
and a warning is issued. This matches the behavior of
acpi_ut_allocate().
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 07:03:00 +08:00
|
|
|
*triggering = ACPI_LEVEL_SENSITIVE;
|
|
|
|
|
*polarity = ACPI_ACTIVE_LOW;
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
2006-03-29 06:04:00 +08:00
|
|
|
case IORESOURCE_IRQ_HIGHLEVEL:
|
[ACPI] ACPICA 20050930
Completed a major overhaul of the Resource Manager code -
specifically, optimizations in the area of the AML/internal
resource conversion code. The code has been optimized to
simplify and eliminate duplicated code, CPU stack use has
been decreased by optimizing function parameters and local
variables, and naming conventions across the manager have
been standardized for clarity and ease of maintenance (this
includes function, parameter, variable, and struct/typedef
names.)
All Resource Manager dispatch and information tables have
been moved to a single location for clarity and ease of
maintenance. One new file was created, named "rsinfo.c".
The ACPI return macros (return_ACPI_STATUS, etc.) have
been modified to guarantee that the argument is
not evaluated twice, making them less prone to macro
side-effects. However, since there exists the possibility
of additional stack use if a particular compiler cannot
optimize them (such as in the debug generation case),
the original macros are optionally available. Note that
some invocations of the return_VALUE macro may now cause
size mismatch warnings; the return_UINT8 and return_UINT32
macros are provided to eliminate these. (From Randy Dunlap)
Implemented a new mechanism to enable debug tracing for
individual control methods. A new external interface,
acpi_debug_trace(), is provided to enable this mechanism. The
intent is to allow the host OS to easily enable and disable
tracing for problematic control methods. This interface
can be easily exposed to a user or debugger interface if
desired. See the file psxface.c for details.
acpi_ut_callocate() will now return a valid pointer if a
length of zero is specified - a length of one is used
and a warning is issued. This matches the behavior of
acpi_ut_allocate().
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 07:03:00 +08:00
|
|
|
*triggering = ACPI_LEVEL_SENSITIVE;
|
|
|
|
|
*polarity = ACPI_ACTIVE_HIGH;
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
|
case IORESOURCE_IRQ_LOWEDGE:
|
[ACPI] ACPICA 20050930
Completed a major overhaul of the Resource Manager code -
specifically, optimizations in the area of the AML/internal
resource conversion code. The code has been optimized to
simplify and eliminate duplicated code, CPU stack use has
been decreased by optimizing function parameters and local
variables, and naming conventions across the manager have
been standardized for clarity and ease of maintenance (this
includes function, parameter, variable, and struct/typedef
names.)
All Resource Manager dispatch and information tables have
been moved to a single location for clarity and ease of
maintenance. One new file was created, named "rsinfo.c".
The ACPI return macros (return_ACPI_STATUS, etc.) have
been modified to guarantee that the argument is
not evaluated twice, making them less prone to macro
side-effects. However, since there exists the possibility
of additional stack use if a particular compiler cannot
optimize them (such as in the debug generation case),
the original macros are optionally available. Note that
some invocations of the return_VALUE macro may now cause
size mismatch warnings; the return_UINT8 and return_UINT32
macros are provided to eliminate these. (From Randy Dunlap)
Implemented a new mechanism to enable debug tracing for
individual control methods. A new external interface,
acpi_debug_trace(), is provided to enable this mechanism. The
intent is to allow the host OS to easily enable and disable
tracing for problematic control methods. This interface
can be easily exposed to a user or debugger interface if
desired. See the file psxface.c for details.
acpi_ut_callocate() will now return a valid pointer if a
length of zero is specified - a length of one is used
and a warning is issued. This matches the behavior of
acpi_ut_allocate().
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 07:03:00 +08:00
|
|
|
*triggering = ACPI_EDGE_SENSITIVE;
|
|
|
|
|
*polarity = ACPI_ACTIVE_LOW;
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
|
case IORESOURCE_IRQ_HIGHEDGE:
|
[ACPI] ACPICA 20050930
Completed a major overhaul of the Resource Manager code -
specifically, optimizations in the area of the AML/internal
resource conversion code. The code has been optimized to
simplify and eliminate duplicated code, CPU stack use has
been decreased by optimizing function parameters and local
variables, and naming conventions across the manager have
been standardized for clarity and ease of maintenance (this
includes function, parameter, variable, and struct/typedef
names.)
All Resource Manager dispatch and information tables have
been moved to a single location for clarity and ease of
maintenance. One new file was created, named "rsinfo.c".
The ACPI return macros (return_ACPI_STATUS, etc.) have
been modified to guarantee that the argument is
not evaluated twice, making them less prone to macro
side-effects. However, since there exists the possibility
of additional stack use if a particular compiler cannot
optimize them (such as in the debug generation case),
the original macros are optionally available. Note that
some invocations of the return_VALUE macro may now cause
size mismatch warnings; the return_UINT8 and return_UINT32
macros are provided to eliminate these. (From Randy Dunlap)
Implemented a new mechanism to enable debug tracing for
individual control methods. A new external interface,
acpi_debug_trace(), is provided to enable this mechanism. The
intent is to allow the host OS to easily enable and disable
tracing for problematic control methods. This interface
can be easily exposed to a user or debugger interface if
desired. See the file psxface.c for details.
acpi_ut_callocate() will now return a valid pointer if a
length of zero is specified - a length of one is used
and a warning is issued. This matches the behavior of
acpi_ut_allocate().
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 07:03:00 +08:00
|
|
|
*triggering = ACPI_EDGE_SENSITIVE;
|
|
|
|
|
*polarity = ACPI_ACTIVE_HIGH;
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
2008-06-10 07:52:04 +08:00
|
|
|
default:
|
|
|
|
|
dev_err(&dev->dev, "can't encode invalid IRQ mode %#x\n",
|
|
|
|
|
flags);
|
|
|
|
|
*triggering = ACPI_EDGE_SENSITIVE;
|
|
|
|
|
*polarity = ACPI_ACTIVE_HIGH;
|
|
|
|
|
break;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2008-06-10 07:52:05 +08:00
|
|
|
|
|
|
|
|
if (flags & IORESOURCE_IRQ_SHAREABLE)
|
|
|
|
|
*shareable = ACPI_SHARED;
|
|
|
|
|
else
|
|
|
|
|
*shareable = ACPI_EXCLUSIVE;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-08-20 06:53:21 +08:00
|
|
|
static int dma_flags(struct pnp_dev *dev, int type, int bus_master,
|
|
|
|
|
int transfer)
|
2007-03-09 12:29:29 +08:00
|
|
|
{
|
|
|
|
|
int flags = 0;
|
|
|
|
|
|
|
|
|
|
if (bus_master)
|
|
|
|
|
flags |= IORESOURCE_DMA_MASTER;
|
|
|
|
|
switch (type) {
|
|
|
|
|
case ACPI_COMPATIBILITY:
|
|
|
|
|
flags |= IORESOURCE_DMA_COMPATIBLE;
|
|
|
|
|
break;
|
|
|
|
|
case ACPI_TYPE_A:
|
|
|
|
|
flags |= IORESOURCE_DMA_TYPEA;
|
|
|
|
|
break;
|
|
|
|
|
case ACPI_TYPE_B:
|
|
|
|
|
flags |= IORESOURCE_DMA_TYPEB;
|
|
|
|
|
break;
|
|
|
|
|
case ACPI_TYPE_F:
|
|
|
|
|
flags |= IORESOURCE_DMA_TYPEF;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
/* Set a default value ? */
|
|
|
|
|
flags |= IORESOURCE_DMA_COMPATIBLE;
|
2008-08-20 06:53:21 +08:00
|
|
|
dev_err(&dev->dev, "invalid DMA type %d\n", type);
|
2007-03-09 12:29:29 +08:00
|
|
|
}
|
|
|
|
|
switch (transfer) {
|
|
|
|
|
case ACPI_TRANSFER_8:
|
|
|
|
|
flags |= IORESOURCE_DMA_8BIT;
|
|
|
|
|
break;
|
|
|
|
|
case ACPI_TRANSFER_8_16:
|
|
|
|
|
flags |= IORESOURCE_DMA_8AND16BIT;
|
|
|
|
|
break;
|
|
|
|
|
case ACPI_TRANSFER_16:
|
|
|
|
|
flags |= IORESOURCE_DMA_16BIT;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
/* Set a default value ? */
|
|
|
|
|
flags |= IORESOURCE_DMA_8AND16BIT;
|
2008-08-20 06:53:21 +08:00
|
|
|
dev_err(&dev->dev, "invalid DMA transfer type %d\n", transfer);
|
2007-03-09 12:29:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return flags;
|
|
|
|
|
}
|
|
|
|
|
|
2012-11-15 07:30:01 +08:00
|
|
|
/*
|
|
|
|
|
* Allocated Resources
|
|
|
|
|
*/
|
2007-07-27 01:41:21 +08:00
|
|
|
|
2012-11-15 07:30:01 +08:00
|
|
|
static void pnpacpi_add_irqresource(struct pnp_dev *dev, struct resource *r)
|
|
|
|
|
{
|
|
|
|
|
if (!(r->flags & IORESOURCE_DISABLED))
|
|
|
|
|
pcibios_penalize_isa_irq(r->start, 1);
|
2008-04-29 06:34:36 +08:00
|
|
|
|
2012-11-15 07:30:01 +08:00
|
|
|
pnp_add_resource(dev, r);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-06-28 06:57:19 +08:00
|
|
|
/*
|
|
|
|
|
* Device CSRs that do not appear in PCI config space should be described
|
|
|
|
|
* via ACPI. This would normally be done with Address Space Descriptors
|
|
|
|
|
* marked as "consumer-only," but old versions of Windows and Linux ignore
|
|
|
|
|
* the producer/consumer flag, so HP invented a vendor-defined resource to
|
|
|
|
|
* describe the location and size of CSR space.
|
|
|
|
|
*/
|
|
|
|
|
static struct acpi_vendor_uuid hp_ccsr_uuid = {
|
|
|
|
|
.subtype = 2,
|
|
|
|
|
.data = { 0xf9, 0xad, 0xe9, 0x69, 0x4f, 0x92, 0x5f, 0xab, 0xf6, 0x4a,
|
|
|
|
|
0x24, 0xd2, 0x01, 0x37, 0x0e, 0xad },
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static int vendor_resource_matches(struct pnp_dev *dev,
|
|
|
|
|
struct acpi_resource_vendor_typed *vendor,
|
|
|
|
|
struct acpi_vendor_uuid *match,
|
|
|
|
|
int expected_len)
|
|
|
|
|
{
|
|
|
|
|
int uuid_len = sizeof(vendor->uuid);
|
|
|
|
|
u8 uuid_subtype = vendor->uuid_subtype;
|
|
|
|
|
u8 *uuid = vendor->uuid;
|
|
|
|
|
int actual_len;
|
|
|
|
|
|
|
|
|
|
/* byte_length includes uuid_subtype and uuid */
|
|
|
|
|
actual_len = vendor->byte_length - uuid_len - 1;
|
|
|
|
|
|
|
|
|
|
if (uuid_subtype == match->subtype &&
|
|
|
|
|
uuid_len == sizeof(match->data) &&
|
|
|
|
|
memcmp(uuid, match->data, uuid_len) == 0) {
|
|
|
|
|
if (expected_len && expected_len != actual_len) {
|
|
|
|
|
dev_err(&dev->dev, "wrong vendor descriptor size; "
|
|
|
|
|
"expected %d, found %d bytes\n",
|
|
|
|
|
expected_len, actual_len);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void pnpacpi_parse_allocated_vendor(struct pnp_dev *dev,
|
|
|
|
|
struct acpi_resource_vendor_typed *vendor)
|
|
|
|
|
{
|
|
|
|
|
if (vendor_resource_matches(dev, vendor, &hp_ccsr_uuid, 16)) {
|
|
|
|
|
u64 start, length;
|
|
|
|
|
|
|
|
|
|
memcpy(&start, vendor->byte_data, sizeof(start));
|
|
|
|
|
memcpy(&length, vendor->byte_data + 8, sizeof(length));
|
|
|
|
|
|
|
|
|
|
pnp_add_mem_resource(dev, start, start + length - 1, 0);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static acpi_status pnpacpi_allocated_resource(struct acpi_resource *res,
|
2007-07-27 01:41:20 +08:00
|
|
|
void *data)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-04-29 06:34:06 +08:00
|
|
|
struct pnp_dev *dev = data;
|
2008-04-29 06:34:00 +08:00
|
|
|
struct acpi_resource_dma *dma;
|
2008-06-28 06:57:19 +08:00
|
|
|
struct acpi_resource_vendor_typed *vendor_typed;
|
2013-07-16 16:23:44 +08:00
|
|
|
struct resource r = {0};
|
2008-04-29 06:34:35 +08:00
|
|
|
int i, flags;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-03-11 22:40:27 +08:00
|
|
|
if (acpi_dev_resource_address_space(res, &r)
|
2012-11-15 07:30:01 +08:00
|
|
|
|| acpi_dev_resource_ext_address_space(res, &r)) {
|
|
|
|
|
pnp_add_resource(dev, &r);
|
|
|
|
|
return AE_OK;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
r.flags = 0;
|
|
|
|
|
if (acpi_dev_resource_interrupt(res, 0, &r)) {
|
|
|
|
|
pnpacpi_add_irqresource(dev, &r);
|
|
|
|
|
for (i = 1; acpi_dev_resource_interrupt(res, i, &r); i++)
|
|
|
|
|
pnpacpi_add_irqresource(dev, &r);
|
2008-06-28 06:56:58 +08:00
|
|
|
|
2012-11-15 07:30:01 +08:00
|
|
|
if (i > 1) {
|
2008-06-28 06:56:58 +08:00
|
|
|
/*
|
|
|
|
|
* The IRQ encoder puts a single interrupt in each
|
|
|
|
|
* descriptor, so if a _CRS descriptor has more than
|
|
|
|
|
* one interrupt, we won't be able to re-encode it.
|
|
|
|
|
*/
|
2012-11-15 07:30:01 +08:00
|
|
|
if (pnp_can_write(dev)) {
|
2008-06-28 06:56:58 +08:00
|
|
|
dev_warn(&dev->dev, "multiple interrupts in "
|
|
|
|
|
"_CRS descriptor; configuration can't "
|
|
|
|
|
"be changed\n");
|
|
|
|
|
dev->capabilities &= ~PNP_WRITE;
|
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2012-11-15 07:30:01 +08:00
|
|
|
return AE_OK;
|
|
|
|
|
} else if (r.flags & IORESOURCE_DISABLED) {
|
|
|
|
|
pnp_add_irq_resource(dev, 0, IORESOURCE_DISABLED);
|
|
|
|
|
return AE_OK;
|
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-11-15 07:30:01 +08:00
|
|
|
switch (res->type) {
|
2014-03-11 22:40:27 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_MEMORY24:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_MEMORY32:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
|
|
|
|
|
if (acpi_dev_resource_memory(res, &r))
|
|
|
|
|
pnp_add_resource(dev, &r);
|
|
|
|
|
break;
|
|
|
|
|
case ACPI_RESOURCE_TYPE_IO:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_FIXED_IO:
|
|
|
|
|
if (acpi_dev_resource_io(res, &r))
|
|
|
|
|
pnp_add_resource(dev, &r);
|
|
|
|
|
break;
|
[ACPI] ACPICA 20050930
Completed a major overhaul of the Resource Manager code -
specifically, optimizations in the area of the AML/internal
resource conversion code. The code has been optimized to
simplify and eliminate duplicated code, CPU stack use has
been decreased by optimizing function parameters and local
variables, and naming conventions across the manager have
been standardized for clarity and ease of maintenance (this
includes function, parameter, variable, and struct/typedef
names.)
All Resource Manager dispatch and information tables have
been moved to a single location for clarity and ease of
maintenance. One new file was created, named "rsinfo.c".
The ACPI return macros (return_ACPI_STATUS, etc.) have
been modified to guarantee that the argument is
not evaluated twice, making them less prone to macro
side-effects. However, since there exists the possibility
of additional stack use if a particular compiler cannot
optimize them (such as in the debug generation case),
the original macros are optionally available. Note that
some invocations of the return_VALUE macro may now cause
size mismatch warnings; the return_UINT8 and return_UINT32
macros are provided to eliminate these. (From Randy Dunlap)
Implemented a new mechanism to enable debug tracing for
individual control methods. A new external interface,
acpi_debug_trace(), is provided to enable this mechanism. The
intent is to allow the host OS to easily enable and disable
tracing for problematic control methods. This interface
can be easily exposed to a user or debugger interface if
desired. See the file psxface.c for details.
acpi_ut_callocate() will now return a valid pointer if a
length of zero is specified - a length of one is used
and a warning is issued. This matches the behavior of
acpi_ut_allocate().
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 07:03:00 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_DMA:
|
2008-04-29 06:34:00 +08:00
|
|
|
dma = &res->data.dma;
|
2008-06-28 06:56:58 +08:00
|
|
|
if (dma->channel_count > 0 && dma->channels[0] != (u8) -1)
|
2008-08-20 06:53:21 +08:00
|
|
|
flags = dma_flags(dev, dma->type, dma->bus_master,
|
2008-04-29 06:34:35 +08:00
|
|
|
dma->transfer);
|
2008-06-28 06:56:58 +08:00
|
|
|
else
|
|
|
|
|
flags = IORESOURCE_DISABLED;
|
|
|
|
|
pnp_add_dma_resource(dev, dma->channels[0], flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
2006-01-20 14:11:37 +08:00
|
|
|
|
|
|
|
|
case ACPI_RESOURCE_TYPE_START_DEPENDENT:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_END_DEPENDENT:
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case ACPI_RESOURCE_TYPE_VENDOR:
|
2008-06-28 06:57:19 +08:00
|
|
|
vendor_typed = &res->data.vendor_typed;
|
|
|
|
|
pnpacpi_parse_allocated_vendor(dev, vendor_typed);
|
2006-01-20 14:11:37 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case ACPI_RESOURCE_TYPE_END_TAG:
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case ACPI_RESOURCE_TYPE_GENERIC_REGISTER:
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
2006-01-20 14:11:37 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
default:
|
2008-04-29 06:34:12 +08:00
|
|
|
dev_warn(&dev->dev, "unknown resource type %d in _CRS\n",
|
|
|
|
|
res->type);
|
2005-04-17 06:20:36 +08:00
|
|
|
return AE_ERROR;
|
|
|
|
|
}
|
2006-03-29 06:04:00 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
return AE_OK;
|
|
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:39 +08:00
|
|
|
int pnpacpi_parse_allocated_resource(struct pnp_dev *dev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2009-11-18 08:05:14 +08:00
|
|
|
struct acpi_device *acpi_dev = dev->data;
|
|
|
|
|
acpi_handle handle = acpi_dev->handle;
|
2008-04-29 06:34:39 +08:00
|
|
|
acpi_status status;
|
2008-04-29 06:34:06 +08:00
|
|
|
|
2008-08-20 06:53:47 +08:00
|
|
|
pnp_dbg(&dev->dev, "parse allocated resources\n");
|
2008-04-29 06:34:07 +08:00
|
|
|
|
2008-04-29 06:34:09 +08:00
|
|
|
pnp_init_resources(dev);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-04-29 06:34:39 +08:00
|
|
|
status = acpi_walk_resources(handle, METHOD_NAME__CRS,
|
|
|
|
|
pnpacpi_allocated_resource, dev);
|
|
|
|
|
|
|
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
|
if (status != AE_NOT_FOUND)
|
|
|
|
|
dev_err(&dev->dev, "can't evaluate _CRS: %d", status);
|
|
|
|
|
return -EPERM;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:04 +08:00
|
|
|
static __init void pnpacpi_parse_dma_option(struct pnp_dev *dev,
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
unsigned int option_flags,
|
2008-02-06 17:40:03 +08:00
|
|
|
struct acpi_resource_dma *p)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
|
int i;
|
2011-10-28 02:56:47 +08:00
|
|
|
unsigned char map = 0, flags;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-07-27 01:41:20 +08:00
|
|
|
for (i = 0; i < p->channel_count; i++)
|
2008-06-28 06:57:11 +08:00
|
|
|
map |= 1 << p->channels[i];
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2011-10-28 02:56:47 +08:00
|
|
|
flags = dma_flags(dev, p->type, p->bus_master, p->transfer);
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
pnp_register_dma_resource(dev, option_flags, map, flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:04 +08:00
|
|
|
static __init void pnpacpi_parse_irq_option(struct pnp_dev *dev,
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
unsigned int option_flags,
|
2008-02-06 17:40:03 +08:00
|
|
|
struct acpi_resource_irq *p)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
|
int i;
|
2008-06-28 06:57:11 +08:00
|
|
|
pnp_irq_mask_t map;
|
2011-10-28 02:56:47 +08:00
|
|
|
unsigned char flags;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-06-28 06:57:11 +08:00
|
|
|
bitmap_zero(map.bits, PNP_IRQ_NR);
|
2007-07-27 01:41:20 +08:00
|
|
|
for (i = 0; i < p->interrupt_count; i++)
|
2005-04-17 06:20:36 +08:00
|
|
|
if (p->interrupts[i])
|
2008-06-28 06:57:11 +08:00
|
|
|
__set_bit(p->interrupts[i], map.bits);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-11-15 07:30:01 +08:00
|
|
|
flags = acpi_dev_irq_flags(p->triggering, p->polarity, p->sharable);
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
pnp_register_irq_resource(dev, option_flags, &map, flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:04 +08:00
|
|
|
static __init void pnpacpi_parse_ext_irq_option(struct pnp_dev *dev,
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
unsigned int option_flags,
|
2008-02-06 17:40:03 +08:00
|
|
|
struct acpi_resource_extended_irq *p)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
|
int i;
|
2008-06-28 06:57:11 +08:00
|
|
|
pnp_irq_mask_t map;
|
2011-10-28 02:56:47 +08:00
|
|
|
unsigned char flags;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-06-28 06:57:11 +08:00
|
|
|
bitmap_zero(map.bits, PNP_IRQ_NR);
|
2008-06-28 06:57:12 +08:00
|
|
|
for (i = 0; i < p->interrupt_count; i++) {
|
|
|
|
|
if (p->interrupts[i]) {
|
|
|
|
|
if (p->interrupts[i] < PNP_IRQ_NR)
|
|
|
|
|
__set_bit(p->interrupts[i], map.bits);
|
|
|
|
|
else
|
|
|
|
|
dev_err(&dev->dev, "ignoring IRQ %d option "
|
|
|
|
|
"(too large for %d entry bitmap)\n",
|
|
|
|
|
p->interrupts[i], PNP_IRQ_NR);
|
|
|
|
|
}
|
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-11-15 07:30:01 +08:00
|
|
|
flags = acpi_dev_irq_flags(p->triggering, p->polarity, p->sharable);
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
pnp_register_irq_resource(dev, option_flags, &map, flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:04 +08:00
|
|
|
static __init void pnpacpi_parse_port_option(struct pnp_dev *dev,
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
unsigned int option_flags,
|
2008-02-06 17:40:03 +08:00
|
|
|
struct acpi_resource_io *io)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-06-28 06:57:11 +08:00
|
|
|
unsigned char flags = 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-06-28 06:57:11 +08:00
|
|
|
if (io->io_decode == ACPI_DECODE_16)
|
2011-10-28 02:56:47 +08:00
|
|
|
flags = IORESOURCE_IO_16BIT_ADDR;
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
pnp_register_port_resource(dev, option_flags, io->minimum, io->maximum,
|
2008-06-28 06:57:11 +08:00
|
|
|
io->alignment, io->address_length, flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:04 +08:00
|
|
|
static __init void pnpacpi_parse_fixed_port_option(struct pnp_dev *dev,
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
unsigned int option_flags,
|
2008-02-06 17:40:03 +08:00
|
|
|
struct acpi_resource_fixed_io *io)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
pnp_register_port_resource(dev, option_flags, io->address, io->address,
|
2011-10-28 02:56:47 +08:00
|
|
|
0, io->address_length, IORESOURCE_IO_FIXED);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:04 +08:00
|
|
|
static __init void pnpacpi_parse_mem24_option(struct pnp_dev *dev,
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
unsigned int option_flags,
|
2008-02-06 17:40:03 +08:00
|
|
|
struct acpi_resource_memory24 *p)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-06-28 06:57:11 +08:00
|
|
|
unsigned char flags = 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-06-28 06:57:11 +08:00
|
|
|
if (p->write_protect == ACPI_READ_WRITE_MEMORY)
|
2011-10-28 02:56:47 +08:00
|
|
|
flags = IORESOURCE_MEM_WRITEABLE;
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
pnp_register_mem_resource(dev, option_flags, p->minimum, p->maximum,
|
2008-06-28 06:57:11 +08:00
|
|
|
p->alignment, p->address_length, flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:04 +08:00
|
|
|
static __init void pnpacpi_parse_mem32_option(struct pnp_dev *dev,
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
unsigned int option_flags,
|
2008-02-06 17:40:03 +08:00
|
|
|
struct acpi_resource_memory32 *p)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-06-28 06:57:11 +08:00
|
|
|
unsigned char flags = 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-06-28 06:57:11 +08:00
|
|
|
if (p->write_protect == ACPI_READ_WRITE_MEMORY)
|
2011-10-28 02:56:47 +08:00
|
|
|
flags = IORESOURCE_MEM_WRITEABLE;
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
pnp_register_mem_resource(dev, option_flags, p->minimum, p->maximum,
|
2008-06-28 06:57:11 +08:00
|
|
|
p->alignment, p->address_length, flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:04 +08:00
|
|
|
static __init void pnpacpi_parse_fixed_mem32_option(struct pnp_dev *dev,
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
unsigned int option_flags,
|
2008-02-06 17:40:03 +08:00
|
|
|
struct acpi_resource_fixed_memory32 *p)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-06-28 06:57:11 +08:00
|
|
|
unsigned char flags = 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-06-28 06:57:11 +08:00
|
|
|
if (p->write_protect == ACPI_READ_WRITE_MEMORY)
|
2011-10-28 02:56:47 +08:00
|
|
|
flags = IORESOURCE_MEM_WRITEABLE;
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
pnp_register_mem_resource(dev, option_flags, p->address, p->address,
|
2008-06-28 06:57:11 +08:00
|
|
|
0, p->address_length, flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:04 +08:00
|
|
|
static __init void pnpacpi_parse_address_option(struct pnp_dev *dev,
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
unsigned int option_flags,
|
2008-02-06 17:40:03 +08:00
|
|
|
struct acpi_resource *r)
|
2005-09-21 03:26:00 +08:00
|
|
|
{
|
|
|
|
|
struct acpi_resource_address64 addr, *p = &addr;
|
|
|
|
|
acpi_status status;
|
2008-06-28 06:57:11 +08:00
|
|
|
unsigned char flags = 0;
|
2005-09-21 03:26:00 +08:00
|
|
|
|
|
|
|
|
status = acpi_resource_to_address64(r, p);
|
2008-08-20 06:53:21 +08:00
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
|
dev_warn(&dev->dev, "can't convert resource type %d\n",
|
2007-07-27 01:41:20 +08:00
|
|
|
r->type);
|
2005-09-21 03:26:00 +08:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (p->resource_type == ACPI_MEMORY_RANGE) {
|
2008-06-28 06:57:11 +08:00
|
|
|
if (p->info.mem.write_protect == ACPI_READ_WRITE_MEMORY)
|
2011-10-28 02:56:47 +08:00
|
|
|
flags = IORESOURCE_MEM_WRITEABLE;
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
pnp_register_mem_resource(dev, option_flags, p->minimum,
|
|
|
|
|
p->minimum, 0, p->address_length,
|
|
|
|
|
flags);
|
2008-06-28 06:57:11 +08:00
|
|
|
} else if (p->resource_type == ACPI_IO_RANGE)
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
pnp_register_port_resource(dev, option_flags, p->minimum,
|
|
|
|
|
p->minimum, 0, p->address_length,
|
2011-10-28 02:56:47 +08:00
|
|
|
IORESOURCE_IO_FIXED);
|
2005-09-21 03:26:00 +08:00
|
|
|
}
|
|
|
|
|
|
2009-05-22 05:49:59 +08:00
|
|
|
static __init void pnpacpi_parse_ext_address_option(struct pnp_dev *dev,
|
|
|
|
|
unsigned int option_flags,
|
|
|
|
|
struct acpi_resource *r)
|
|
|
|
|
{
|
|
|
|
|
struct acpi_resource_extended_address64 *p = &r->data.ext_address64;
|
|
|
|
|
unsigned char flags = 0;
|
|
|
|
|
|
|
|
|
|
if (p->resource_type == ACPI_MEMORY_RANGE) {
|
|
|
|
|
if (p->info.mem.write_protect == ACPI_READ_WRITE_MEMORY)
|
2011-10-28 02:56:47 +08:00
|
|
|
flags = IORESOURCE_MEM_WRITEABLE;
|
2009-05-22 05:49:59 +08:00
|
|
|
pnp_register_mem_resource(dev, option_flags, p->minimum,
|
|
|
|
|
p->minimum, 0, p->address_length,
|
|
|
|
|
flags);
|
|
|
|
|
} else if (p->resource_type == ACPI_IO_RANGE)
|
|
|
|
|
pnp_register_port_resource(dev, option_flags, p->minimum,
|
|
|
|
|
p->minimum, 0, p->address_length,
|
2011-10-28 02:56:47 +08:00
|
|
|
IORESOURCE_IO_FIXED);
|
2009-05-22 05:49:59 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
struct acpipnp_parse_option_s {
|
|
|
|
|
struct pnp_dev *dev;
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
unsigned int option_flags;
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
|
2008-02-06 17:40:03 +08:00
|
|
|
static __init acpi_status pnpacpi_option_resource(struct acpi_resource *res,
|
|
|
|
|
void *data)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-06-28 06:57:15 +08:00
|
|
|
int priority;
|
2007-08-16 00:32:10 +08:00
|
|
|
struct acpipnp_parse_option_s *parse_data = data;
|
2005-04-17 06:20:36 +08:00
|
|
|
struct pnp_dev *dev = parse_data->dev;
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
unsigned int option_flags = parse_data->option_flags;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2005-09-22 12:25:18 +08:00
|
|
|
switch (res->type) {
|
2007-07-27 01:41:20 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_IRQ:
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
pnpacpi_parse_irq_option(dev, option_flags, &res->data.irq);
|
2007-07-27 01:41:20 +08:00
|
|
|
break;
|
2006-01-20 14:11:37 +08:00
|
|
|
|
2007-07-27 01:41:20 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_DMA:
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
pnpacpi_parse_dma_option(dev, option_flags, &res->data.dma);
|
2007-07-27 01:41:20 +08:00
|
|
|
break;
|
2006-01-20 14:11:37 +08:00
|
|
|
|
2007-07-27 01:41:20 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_START_DEPENDENT:
|
|
|
|
|
switch (res->data.start_dpf.compatibility_priority) {
|
|
|
|
|
case ACPI_GOOD_CONFIGURATION:
|
|
|
|
|
priority = PNP_RES_PRIORITY_PREFERRED;
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
2006-01-20 14:11:37 +08:00
|
|
|
|
2007-07-27 01:41:20 +08:00
|
|
|
case ACPI_ACCEPTABLE_CONFIGURATION:
|
|
|
|
|
priority = PNP_RES_PRIORITY_ACCEPTABLE;
|
2005-03-26 01:03:15 +08:00
|
|
|
break;
|
2006-01-20 14:11:37 +08:00
|
|
|
|
2007-07-27 01:41:20 +08:00
|
|
|
case ACPI_SUB_OPTIMAL_CONFIGURATION:
|
|
|
|
|
priority = PNP_RES_PRIORITY_FUNCTIONAL;
|
2006-01-20 14:11:37 +08:00
|
|
|
break;
|
2007-07-27 01:41:20 +08:00
|
|
|
default:
|
|
|
|
|
priority = PNP_RES_PRIORITY_INVALID;
|
2006-01-20 14:11:37 +08:00
|
|
|
break;
|
2007-07-27 01:41:20 +08:00
|
|
|
}
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
parse_data->option_flags = pnp_new_dependent_set(dev, priority);
|
2007-07-27 01:41:20 +08:00
|
|
|
break;
|
2006-01-20 14:11:37 +08:00
|
|
|
|
2007-07-27 01:41:20 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_END_DEPENDENT:
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
parse_data->option_flags = 0;
|
2007-07-27 01:41:20 +08:00
|
|
|
break;
|
2006-01-20 14:11:37 +08:00
|
|
|
|
2007-07-27 01:41:20 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_IO:
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
pnpacpi_parse_port_option(dev, option_flags, &res->data.io);
|
2007-07-27 01:41:20 +08:00
|
|
|
break;
|
2006-01-20 14:11:37 +08:00
|
|
|
|
2007-07-27 01:41:20 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_FIXED_IO:
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
pnpacpi_parse_fixed_port_option(dev, option_flags,
|
2008-04-29 06:34:04 +08:00
|
|
|
&res->data.fixed_io);
|
2007-07-27 01:41:20 +08:00
|
|
|
break;
|
2006-01-20 14:11:37 +08:00
|
|
|
|
2007-07-27 01:41:20 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_VENDOR:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_END_TAG:
|
|
|
|
|
break;
|
2006-01-20 14:11:37 +08:00
|
|
|
|
2007-07-27 01:41:20 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_MEMORY24:
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
pnpacpi_parse_mem24_option(dev, option_flags,
|
|
|
|
|
&res->data.memory24);
|
2007-07-27 01:41:20 +08:00
|
|
|
break;
|
2006-01-20 14:11:37 +08:00
|
|
|
|
2007-07-27 01:41:20 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_MEMORY32:
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
pnpacpi_parse_mem32_option(dev, option_flags,
|
|
|
|
|
&res->data.memory32);
|
2007-07-27 01:41:20 +08:00
|
|
|
break;
|
2006-01-20 14:11:37 +08:00
|
|
|
|
2007-07-27 01:41:20 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
pnpacpi_parse_fixed_mem32_option(dev, option_flags,
|
2007-07-27 01:41:20 +08:00
|
|
|
&res->data.fixed_memory32);
|
|
|
|
|
break;
|
2006-01-20 14:11:37 +08:00
|
|
|
|
2007-07-27 01:41:20 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_ADDRESS16:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_ADDRESS32:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_ADDRESS64:
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
pnpacpi_parse_address_option(dev, option_flags, res);
|
2007-07-27 01:41:20 +08:00
|
|
|
break;
|
2006-01-20 14:11:37 +08:00
|
|
|
|
2007-07-27 01:41:20 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64:
|
2009-05-22 05:49:59 +08:00
|
|
|
pnpacpi_parse_ext_address_option(dev, option_flags, res);
|
2007-07-27 01:41:20 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
pnpacpi_parse_ext_irq_option(dev, option_flags,
|
2008-04-29 06:34:04 +08:00
|
|
|
&res->data.extended_irq);
|
2007-07-27 01:41:20 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case ACPI_RESOURCE_TYPE_GENERIC_REGISTER:
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default:
|
2008-04-29 06:34:12 +08:00
|
|
|
dev_warn(&dev->dev, "unknown resource type %d in _PRS\n",
|
|
|
|
|
res->type);
|
2007-07-27 01:41:20 +08:00
|
|
|
return AE_ERROR;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2006-03-29 06:04:00 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
return AE_OK;
|
|
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:39 +08:00
|
|
|
int __init pnpacpi_parse_resource_option_data(struct pnp_dev *dev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2009-11-18 08:05:14 +08:00
|
|
|
struct acpi_device *acpi_dev = dev->data;
|
|
|
|
|
acpi_handle handle = acpi_dev->handle;
|
2005-04-17 06:20:36 +08:00
|
|
|
acpi_status status;
|
|
|
|
|
struct acpipnp_parse_option_s parse_data;
|
|
|
|
|
|
2008-08-20 06:53:47 +08:00
|
|
|
pnp_dbg(&dev->dev, "parse resource options\n");
|
2008-04-29 06:34:07 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
parse_data.dev = dev;
|
PNP: convert resource options to single linked list
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.
PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:
dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...
This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.
However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.
This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:
dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...
All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.
Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:
ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-06-28 06:57:17 +08:00
|
|
|
parse_data.option_flags = 0;
|
|
|
|
|
|
[ACPI] ACPICA 20050930
Completed a major overhaul of the Resource Manager code -
specifically, optimizations in the area of the AML/internal
resource conversion code. The code has been optimized to
simplify and eliminate duplicated code, CPU stack use has
been decreased by optimizing function parameters and local
variables, and naming conventions across the manager have
been standardized for clarity and ease of maintenance (this
includes function, parameter, variable, and struct/typedef
names.)
All Resource Manager dispatch and information tables have
been moved to a single location for clarity and ease of
maintenance. One new file was created, named "rsinfo.c".
The ACPI return macros (return_ACPI_STATUS, etc.) have
been modified to guarantee that the argument is
not evaluated twice, making them less prone to macro
side-effects. However, since there exists the possibility
of additional stack use if a particular compiler cannot
optimize them (such as in the debug generation case),
the original macros are optionally available. Note that
some invocations of the return_VALUE macro may now cause
size mismatch warnings; the return_UINT8 and return_UINT32
macros are provided to eliminate these. (From Randy Dunlap)
Implemented a new mechanism to enable debug tracing for
individual control methods. A new external interface,
acpi_debug_trace(), is provided to enable this mechanism. The
intent is to allow the host OS to easily enable and disable
tracing for problematic control methods. This interface
can be easily exposed to a user or debugger interface if
desired. See the file psxface.c for details.
acpi_ut_callocate() will now return a valid pointer if a
length of zero is specified - a length of one is used
and a warning is issued. This matches the behavior of
acpi_ut_allocate().
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 07:03:00 +08:00
|
|
|
status = acpi_walk_resources(handle, METHOD_NAME__PRS,
|
2007-07-27 01:41:20 +08:00
|
|
|
pnpacpi_option_resource, &parse_data);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-04-29 06:34:39 +08:00
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
|
if (status != AE_NOT_FOUND)
|
|
|
|
|
dev_err(&dev->dev, "can't evaluate _PRS: %d", status);
|
|
|
|
|
return -EPERM;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2006-03-29 06:04:00 +08:00
|
|
|
static int pnpacpi_supported_resource(struct acpi_resource *res)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2005-09-22 12:25:18 +08:00
|
|
|
switch (res->type) {
|
[ACPI] ACPICA 20050930
Completed a major overhaul of the Resource Manager code -
specifically, optimizations in the area of the AML/internal
resource conversion code. The code has been optimized to
simplify and eliminate duplicated code, CPU stack use has
been decreased by optimizing function parameters and local
variables, and naming conventions across the manager have
been standardized for clarity and ease of maintenance (this
includes function, parameter, variable, and struct/typedef
names.)
All Resource Manager dispatch and information tables have
been moved to a single location for clarity and ease of
maintenance. One new file was created, named "rsinfo.c".
The ACPI return macros (return_ACPI_STATUS, etc.) have
been modified to guarantee that the argument is
not evaluated twice, making them less prone to macro
side-effects. However, since there exists the possibility
of additional stack use if a particular compiler cannot
optimize them (such as in the debug generation case),
the original macros are optionally available. Note that
some invocations of the return_VALUE macro may now cause
size mismatch warnings; the return_UINT8 and return_UINT32
macros are provided to eliminate these. (From Randy Dunlap)
Implemented a new mechanism to enable debug tracing for
individual control methods. A new external interface,
acpi_debug_trace(), is provided to enable this mechanism. The
intent is to allow the host OS to easily enable and disable
tracing for problematic control methods. This interface
can be easily exposed to a user or debugger interface if
desired. See the file psxface.c for details.
acpi_ut_callocate() will now return a valid pointer if a
length of zero is specified - a length of one is used
and a warning is issued. This matches the behavior of
acpi_ut_allocate().
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 07:03:00 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_IRQ:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_DMA:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_IO:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_FIXED_IO:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_MEMORY24:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_MEMORY32:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_ADDRESS16:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_ADDRESS32:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_ADDRESS64:
|
2009-05-22 05:49:59 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64:
|
2006-01-20 14:11:37 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
|
2006-03-29 06:04:00 +08:00
|
|
|
return 1;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2006-03-29 06:04:00 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Set resource
|
|
|
|
|
*/
|
|
|
|
|
static acpi_status pnpacpi_count_resources(struct acpi_resource *res,
|
2007-07-27 01:41:20 +08:00
|
|
|
void *data)
|
2006-03-29 06:04:00 +08:00
|
|
|
{
|
2007-08-16 00:32:10 +08:00
|
|
|
int *res_cnt = data;
|
2006-03-29 06:04:00 +08:00
|
|
|
|
|
|
|
|
if (pnpacpi_supported_resource(res))
|
|
|
|
|
(*res_cnt)++;
|
2005-04-17 06:20:36 +08:00
|
|
|
return AE_OK;
|
|
|
|
|
}
|
|
|
|
|
|
2006-03-29 06:04:00 +08:00
|
|
|
static acpi_status pnpacpi_type_resources(struct acpi_resource *res, void *data)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2007-08-16 00:32:10 +08:00
|
|
|
struct acpi_resource **resource = data;
|
2006-03-29 06:04:00 +08:00
|
|
|
|
|
|
|
|
if (pnpacpi_supported_resource(res)) {
|
2005-09-22 12:25:18 +08:00
|
|
|
(*resource)->type = res->type;
|
2006-03-29 06:04:00 +08:00
|
|
|
(*resource)->length = sizeof(struct acpi_resource);
|
2008-06-10 07:52:06 +08:00
|
|
|
if (res->type == ACPI_RESOURCE_TYPE_IRQ)
|
|
|
|
|
(*resource)->data.irq.descriptor_length =
|
|
|
|
|
res->data.irq.descriptor_length;
|
2005-04-17 06:20:36 +08:00
|
|
|
(*resource)++;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return AE_OK;
|
|
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:03 +08:00
|
|
|
int pnpacpi_build_resource_template(struct pnp_dev *dev,
|
2007-07-27 01:41:20 +08:00
|
|
|
struct acpi_buffer *buffer)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2009-11-18 08:05:14 +08:00
|
|
|
struct acpi_device *acpi_dev = dev->data;
|
|
|
|
|
acpi_handle handle = acpi_dev->handle;
|
2005-04-17 06:20:36 +08:00
|
|
|
struct acpi_resource *resource;
|
|
|
|
|
int res_cnt = 0;
|
|
|
|
|
acpi_status status;
|
|
|
|
|
|
[ACPI] ACPICA 20050930
Completed a major overhaul of the Resource Manager code -
specifically, optimizations in the area of the AML/internal
resource conversion code. The code has been optimized to
simplify and eliminate duplicated code, CPU stack use has
been decreased by optimizing function parameters and local
variables, and naming conventions across the manager have
been standardized for clarity and ease of maintenance (this
includes function, parameter, variable, and struct/typedef
names.)
All Resource Manager dispatch and information tables have
been moved to a single location for clarity and ease of
maintenance. One new file was created, named "rsinfo.c".
The ACPI return macros (return_ACPI_STATUS, etc.) have
been modified to guarantee that the argument is
not evaluated twice, making them less prone to macro
side-effects. However, since there exists the possibility
of additional stack use if a particular compiler cannot
optimize them (such as in the debug generation case),
the original macros are optionally available. Note that
some invocations of the return_VALUE macro may now cause
size mismatch warnings; the return_UINT8 and return_UINT32
macros are provided to eliminate these. (From Randy Dunlap)
Implemented a new mechanism to enable debug tracing for
individual control methods. A new external interface,
acpi_debug_trace(), is provided to enable this mechanism. The
intent is to allow the host OS to easily enable and disable
tracing for problematic control methods. This interface
can be easily exposed to a user or debugger interface if
desired. See the file psxface.c for details.
acpi_ut_callocate() will now return a valid pointer if a
length of zero is specified - a length of one is used
and a warning is issued. This matches the behavior of
acpi_ut_allocate().
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 07:03:00 +08:00
|
|
|
status = acpi_walk_resources(handle, METHOD_NAME__CRS,
|
2007-07-27 01:41:20 +08:00
|
|
|
pnpacpi_count_resources, &res_cnt);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (ACPI_FAILURE(status)) {
|
2008-04-29 06:34:39 +08:00
|
|
|
dev_err(&dev->dev, "can't evaluate _CRS: %d\n", status);
|
2005-04-17 06:20:36 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
if (!res_cnt)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
buffer->length = sizeof(struct acpi_resource) * (res_cnt + 1) + 1;
|
2006-12-13 16:34:52 +08:00
|
|
|
buffer->pointer = kzalloc(buffer->length - 1, GFP_KERNEL);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (!buffer->pointer)
|
|
|
|
|
return -ENOMEM;
|
2008-04-29 06:34:07 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
resource = (struct acpi_resource *)buffer->pointer;
|
[ACPI] ACPICA 20050930
Completed a major overhaul of the Resource Manager code -
specifically, optimizations in the area of the AML/internal
resource conversion code. The code has been optimized to
simplify and eliminate duplicated code, CPU stack use has
been decreased by optimizing function parameters and local
variables, and naming conventions across the manager have
been standardized for clarity and ease of maintenance (this
includes function, parameter, variable, and struct/typedef
names.)
All Resource Manager dispatch and information tables have
been moved to a single location for clarity and ease of
maintenance. One new file was created, named "rsinfo.c".
The ACPI return macros (return_ACPI_STATUS, etc.) have
been modified to guarantee that the argument is
not evaluated twice, making them less prone to macro
side-effects. However, since there exists the possibility
of additional stack use if a particular compiler cannot
optimize them (such as in the debug generation case),
the original macros are optionally available. Note that
some invocations of the return_VALUE macro may now cause
size mismatch warnings; the return_UINT8 and return_UINT32
macros are provided to eliminate these. (From Randy Dunlap)
Implemented a new mechanism to enable debug tracing for
individual control methods. A new external interface,
acpi_debug_trace(), is provided to enable this mechanism. The
intent is to allow the host OS to easily enable and disable
tracing for problematic control methods. This interface
can be easily exposed to a user or debugger interface if
desired. See the file psxface.c for details.
acpi_ut_callocate() will now return a valid pointer if a
length of zero is specified - a length of one is used
and a warning is issued. This matches the behavior of
acpi_ut_allocate().
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 07:03:00 +08:00
|
|
|
status = acpi_walk_resources(handle, METHOD_NAME__CRS,
|
2007-07-27 01:41:20 +08:00
|
|
|
pnpacpi_type_resources, &resource);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
|
kfree(buffer->pointer);
|
2008-04-29 06:34:39 +08:00
|
|
|
dev_err(&dev->dev, "can't evaluate _CRS: %d\n", status);
|
2005-04-17 06:20:36 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
/* resource will pointer the end resource now */
|
[ACPI] ACPICA 20050930
Completed a major overhaul of the Resource Manager code -
specifically, optimizations in the area of the AML/internal
resource conversion code. The code has been optimized to
simplify and eliminate duplicated code, CPU stack use has
been decreased by optimizing function parameters and local
variables, and naming conventions across the manager have
been standardized for clarity and ease of maintenance (this
includes function, parameter, variable, and struct/typedef
names.)
All Resource Manager dispatch and information tables have
been moved to a single location for clarity and ease of
maintenance. One new file was created, named "rsinfo.c".
The ACPI return macros (return_ACPI_STATUS, etc.) have
been modified to guarantee that the argument is
not evaluated twice, making them less prone to macro
side-effects. However, since there exists the possibility
of additional stack use if a particular compiler cannot
optimize them (such as in the debug generation case),
the original macros are optionally available. Note that
some invocations of the return_VALUE macro may now cause
size mismatch warnings; the return_UINT8 and return_UINT32
macros are provided to eliminate these. (From Randy Dunlap)
Implemented a new mechanism to enable debug tracing for
individual control methods. A new external interface,
acpi_debug_trace(), is provided to enable this mechanism. The
intent is to allow the host OS to easily enable and disable
tracing for problematic control methods. This interface
can be easily exposed to a user or debugger interface if
desired. See the file psxface.c for details.
acpi_ut_callocate() will now return a valid pointer if a
length of zero is specified - a length of one is used
and a warning is issued. This matches the behavior of
acpi_ut_allocate().
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 07:03:00 +08:00
|
|
|
resource->type = ACPI_RESOURCE_TYPE_END_TAG;
|
2013-03-24 03:16:37 +08:00
|
|
|
resource->length = sizeof(struct acpi_resource);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:07 +08:00
|
|
|
static void pnpacpi_encode_irq(struct pnp_dev *dev,
|
|
|
|
|
struct acpi_resource *resource,
|
2007-07-27 01:41:20 +08:00
|
|
|
struct resource *p)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-04-29 06:34:00 +08:00
|
|
|
struct acpi_resource_irq *irq = &resource->data.irq;
|
2008-06-10 07:52:05 +08:00
|
|
|
int triggering, polarity, shareable;
|
2006-03-29 06:04:00 +08:00
|
|
|
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
if (!pnp_resource_enabled(p)) {
|
|
|
|
|
irq->interrupt_count = 0;
|
2008-08-20 06:53:47 +08:00
|
|
|
pnp_dbg(&dev->dev, " encode irq (%s)\n",
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
p ? "disabled" : "missing");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2008-06-10 07:52:05 +08:00
|
|
|
decode_irq_flags(dev, p->flags, &triggering, &polarity, &shareable);
|
2008-04-29 06:34:00 +08:00
|
|
|
irq->triggering = triggering;
|
|
|
|
|
irq->polarity = polarity;
|
2008-06-10 07:52:05 +08:00
|
|
|
irq->sharable = shareable;
|
2008-04-29 06:34:00 +08:00
|
|
|
irq->interrupt_count = 1;
|
|
|
|
|
irq->interrupts[0] = p->start;
|
2008-04-29 06:34:07 +08:00
|
|
|
|
2008-08-20 06:53:47 +08:00
|
|
|
pnp_dbg(&dev->dev, " encode irq %d %s %s %s (%d-byte descriptor)\n",
|
2008-06-10 07:52:06 +08:00
|
|
|
(int) p->start,
|
2008-04-29 06:34:07 +08:00
|
|
|
triggering == ACPI_LEVEL_SENSITIVE ? "level" : "edge",
|
|
|
|
|
polarity == ACPI_ACTIVE_LOW ? "low" : "high",
|
2008-06-10 07:52:06 +08:00
|
|
|
irq->sharable == ACPI_SHARED ? "shared" : "exclusive",
|
|
|
|
|
irq->descriptor_length);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:07 +08:00
|
|
|
static void pnpacpi_encode_ext_irq(struct pnp_dev *dev,
|
|
|
|
|
struct acpi_resource *resource,
|
2007-07-27 01:41:20 +08:00
|
|
|
struct resource *p)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-04-29 06:34:00 +08:00
|
|
|
struct acpi_resource_extended_irq *extended_irq = &resource->data.extended_irq;
|
2008-06-10 07:52:05 +08:00
|
|
|
int triggering, polarity, shareable;
|
2006-03-29 06:04:00 +08:00
|
|
|
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
if (!pnp_resource_enabled(p)) {
|
|
|
|
|
extended_irq->interrupt_count = 0;
|
2008-08-20 06:53:47 +08:00
|
|
|
pnp_dbg(&dev->dev, " encode extended irq (%s)\n",
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
p ? "disabled" : "missing");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2008-06-10 07:52:05 +08:00
|
|
|
decode_irq_flags(dev, p->flags, &triggering, &polarity, &shareable);
|
2008-04-29 06:34:00 +08:00
|
|
|
extended_irq->producer_consumer = ACPI_CONSUMER;
|
|
|
|
|
extended_irq->triggering = triggering;
|
|
|
|
|
extended_irq->polarity = polarity;
|
2008-06-10 07:52:05 +08:00
|
|
|
extended_irq->sharable = shareable;
|
2008-04-29 06:34:00 +08:00
|
|
|
extended_irq->interrupt_count = 1;
|
|
|
|
|
extended_irq->interrupts[0] = p->start;
|
2008-04-29 06:34:07 +08:00
|
|
|
|
2008-08-20 06:53:47 +08:00
|
|
|
pnp_dbg(&dev->dev, " encode irq %d %s %s %s\n", (int) p->start,
|
2008-04-29 06:34:07 +08:00
|
|
|
triggering == ACPI_LEVEL_SENSITIVE ? "level" : "edge",
|
|
|
|
|
polarity == ACPI_ACTIVE_LOW ? "low" : "high",
|
|
|
|
|
extended_irq->sharable == ACPI_SHARED ? "shared" : "exclusive");
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:07 +08:00
|
|
|
static void pnpacpi_encode_dma(struct pnp_dev *dev,
|
|
|
|
|
struct acpi_resource *resource,
|
2007-07-27 01:41:20 +08:00
|
|
|
struct resource *p)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-04-29 06:34:00 +08:00
|
|
|
struct acpi_resource_dma *dma = &resource->data.dma;
|
|
|
|
|
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
if (!pnp_resource_enabled(p)) {
|
|
|
|
|
dma->channel_count = 0;
|
2008-08-20 06:53:47 +08:00
|
|
|
pnp_dbg(&dev->dev, " encode dma (%s)\n",
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
p ? "disabled" : "missing");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* Note: pnp_assign_dma will copy pnp_dma->flags into p->flags */
|
2006-04-08 02:00:27 +08:00
|
|
|
switch (p->flags & IORESOURCE_DMA_SPEED_MASK) {
|
2007-07-27 01:41:20 +08:00
|
|
|
case IORESOURCE_DMA_TYPEA:
|
2008-04-29 06:34:00 +08:00
|
|
|
dma->type = ACPI_TYPE_A;
|
2007-07-27 01:41:20 +08:00
|
|
|
break;
|
|
|
|
|
case IORESOURCE_DMA_TYPEB:
|
2008-04-29 06:34:00 +08:00
|
|
|
dma->type = ACPI_TYPE_B;
|
2007-07-27 01:41:20 +08:00
|
|
|
break;
|
|
|
|
|
case IORESOURCE_DMA_TYPEF:
|
2008-04-29 06:34:00 +08:00
|
|
|
dma->type = ACPI_TYPE_F;
|
2007-07-27 01:41:20 +08:00
|
|
|
break;
|
|
|
|
|
default:
|
2008-04-29 06:34:00 +08:00
|
|
|
dma->type = ACPI_COMPATIBILITY;
|
2006-04-08 02:00:27 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (p->flags & IORESOURCE_DMA_TYPE_MASK) {
|
2007-07-27 01:41:20 +08:00
|
|
|
case IORESOURCE_DMA_8BIT:
|
2008-04-29 06:34:00 +08:00
|
|
|
dma->transfer = ACPI_TRANSFER_8;
|
2007-07-27 01:41:20 +08:00
|
|
|
break;
|
|
|
|
|
case IORESOURCE_DMA_8AND16BIT:
|
2008-04-29 06:34:00 +08:00
|
|
|
dma->transfer = ACPI_TRANSFER_8_16;
|
2007-07-27 01:41:20 +08:00
|
|
|
break;
|
|
|
|
|
default:
|
2008-04-29 06:34:00 +08:00
|
|
|
dma->transfer = ACPI_TRANSFER_16;
|
2006-04-08 02:00:27 +08:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:00 +08:00
|
|
|
dma->bus_master = !!(p->flags & IORESOURCE_DMA_MASTER);
|
|
|
|
|
dma->channel_count = 1;
|
|
|
|
|
dma->channels[0] = p->start;
|
2008-04-29 06:34:07 +08:00
|
|
|
|
2008-08-20 06:53:47 +08:00
|
|
|
pnp_dbg(&dev->dev, " encode dma %d "
|
2008-04-29 06:34:07 +08:00
|
|
|
"type %#x transfer %#x master %d\n",
|
|
|
|
|
(int) p->start, dma->type, dma->transfer, dma->bus_master);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:07 +08:00
|
|
|
static void pnpacpi_encode_io(struct pnp_dev *dev,
|
|
|
|
|
struct acpi_resource *resource,
|
2007-07-27 01:41:20 +08:00
|
|
|
struct resource *p)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-04-29 06:34:00 +08:00
|
|
|
struct acpi_resource_io *io = &resource->data.io;
|
|
|
|
|
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
if (pnp_resource_enabled(p)) {
|
|
|
|
|
/* Note: pnp_assign_port copies pnp_port->flags into p->flags */
|
2008-06-28 06:57:03 +08:00
|
|
|
io->io_decode = (p->flags & IORESOURCE_IO_16BIT_ADDR) ?
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
ACPI_DECODE_16 : ACPI_DECODE_10;
|
|
|
|
|
io->minimum = p->start;
|
|
|
|
|
io->maximum = p->end;
|
|
|
|
|
io->alignment = 0; /* Correct? */
|
2011-06-10 00:13:32 +08:00
|
|
|
io->address_length = resource_size(p);
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
} else {
|
|
|
|
|
io->minimum = 0;
|
|
|
|
|
io->address_length = 0;
|
|
|
|
|
}
|
2008-04-29 06:34:07 +08:00
|
|
|
|
2008-08-20 06:53:47 +08:00
|
|
|
pnp_dbg(&dev->dev, " encode io %#x-%#x decode %#x\n", io->minimum,
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
io->minimum + io->address_length - 1, io->io_decode);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:07 +08:00
|
|
|
static void pnpacpi_encode_fixed_io(struct pnp_dev *dev,
|
|
|
|
|
struct acpi_resource *resource,
|
2007-07-27 01:41:20 +08:00
|
|
|
struct resource *p)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-04-29 06:34:00 +08:00
|
|
|
struct acpi_resource_fixed_io *fixed_io = &resource->data.fixed_io;
|
|
|
|
|
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
if (pnp_resource_enabled(p)) {
|
|
|
|
|
fixed_io->address = p->start;
|
2011-06-10 00:13:32 +08:00
|
|
|
fixed_io->address_length = resource_size(p);
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
} else {
|
|
|
|
|
fixed_io->address = 0;
|
|
|
|
|
fixed_io->address_length = 0;
|
|
|
|
|
}
|
2008-04-29 06:34:07 +08:00
|
|
|
|
2008-08-20 06:53:47 +08:00
|
|
|
pnp_dbg(&dev->dev, " encode fixed_io %#x-%#x\n", fixed_io->address,
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
fixed_io->address + fixed_io->address_length - 1);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:07 +08:00
|
|
|
static void pnpacpi_encode_mem24(struct pnp_dev *dev,
|
|
|
|
|
struct acpi_resource *resource,
|
2007-07-27 01:41:20 +08:00
|
|
|
struct resource *p)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-04-29 06:34:00 +08:00
|
|
|
struct acpi_resource_memory24 *memory24 = &resource->data.memory24;
|
|
|
|
|
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
if (pnp_resource_enabled(p)) {
|
|
|
|
|
/* Note: pnp_assign_mem copies pnp_mem->flags into p->flags */
|
|
|
|
|
memory24->write_protect = p->flags & IORESOURCE_MEM_WRITEABLE ?
|
|
|
|
|
ACPI_READ_WRITE_MEMORY : ACPI_READ_ONLY_MEMORY;
|
|
|
|
|
memory24->minimum = p->start;
|
|
|
|
|
memory24->maximum = p->end;
|
|
|
|
|
memory24->alignment = 0;
|
2011-06-10 00:13:32 +08:00
|
|
|
memory24->address_length = resource_size(p);
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
} else {
|
|
|
|
|
memory24->minimum = 0;
|
|
|
|
|
memory24->address_length = 0;
|
|
|
|
|
}
|
|
|
|
|
|
2008-08-20 06:53:47 +08:00
|
|
|
pnp_dbg(&dev->dev, " encode mem24 %#x-%#x write_protect %#x\n",
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
memory24->minimum,
|
|
|
|
|
memory24->minimum + memory24->address_length - 1,
|
2008-04-29 06:34:07 +08:00
|
|
|
memory24->write_protect);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:07 +08:00
|
|
|
static void pnpacpi_encode_mem32(struct pnp_dev *dev,
|
|
|
|
|
struct acpi_resource *resource,
|
2007-07-27 01:41:20 +08:00
|
|
|
struct resource *p)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-04-29 06:34:00 +08:00
|
|
|
struct acpi_resource_memory32 *memory32 = &resource->data.memory32;
|
|
|
|
|
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
if (pnp_resource_enabled(p)) {
|
|
|
|
|
memory32->write_protect = p->flags & IORESOURCE_MEM_WRITEABLE ?
|
|
|
|
|
ACPI_READ_WRITE_MEMORY : ACPI_READ_ONLY_MEMORY;
|
|
|
|
|
memory32->minimum = p->start;
|
|
|
|
|
memory32->maximum = p->end;
|
|
|
|
|
memory32->alignment = 0;
|
2011-06-10 00:13:32 +08:00
|
|
|
memory32->address_length = resource_size(p);
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
} else {
|
|
|
|
|
memory32->minimum = 0;
|
|
|
|
|
memory32->alignment = 0;
|
|
|
|
|
}
|
2008-04-29 06:34:07 +08:00
|
|
|
|
2008-08-20 06:53:47 +08:00
|
|
|
pnp_dbg(&dev->dev, " encode mem32 %#x-%#x write_protect %#x\n",
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
memory32->minimum,
|
|
|
|
|
memory32->minimum + memory32->address_length - 1,
|
2008-04-29 06:34:07 +08:00
|
|
|
memory32->write_protect);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:07 +08:00
|
|
|
static void pnpacpi_encode_fixed_mem32(struct pnp_dev *dev,
|
|
|
|
|
struct acpi_resource *resource,
|
2007-07-27 01:41:20 +08:00
|
|
|
struct resource *p)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-04-29 06:34:00 +08:00
|
|
|
struct acpi_resource_fixed_memory32 *fixed_memory32 = &resource->data.fixed_memory32;
|
|
|
|
|
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
if (pnp_resource_enabled(p)) {
|
|
|
|
|
fixed_memory32->write_protect =
|
|
|
|
|
p->flags & IORESOURCE_MEM_WRITEABLE ?
|
|
|
|
|
ACPI_READ_WRITE_MEMORY : ACPI_READ_ONLY_MEMORY;
|
|
|
|
|
fixed_memory32->address = p->start;
|
2011-06-10 00:13:32 +08:00
|
|
|
fixed_memory32->address_length = resource_size(p);
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
} else {
|
|
|
|
|
fixed_memory32->address = 0;
|
|
|
|
|
fixed_memory32->address_length = 0;
|
|
|
|
|
}
|
2008-04-29 06:34:07 +08:00
|
|
|
|
2008-08-20 06:53:47 +08:00
|
|
|
pnp_dbg(&dev->dev, " encode fixed_mem32 %#x-%#x write_protect %#x\n",
|
PNP: replace pnp_resource_table with dynamically allocated resources
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.
This patch replaces the table with a linked list of resources where
the entries are allocated on demand.
This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resources
References:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110
This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.
Prior to this patch, the pnp_resource_table entries used the flags
like this:
IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.
IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().
This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.
Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:
- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a device
IORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:
- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative length
After this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:
IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.
IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.
We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.
Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.
IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-06-28 06:56:57 +08:00
|
|
|
fixed_memory32->address,
|
|
|
|
|
fixed_memory32->address + fixed_memory32->address_length - 1,
|
2008-04-29 06:34:07 +08:00
|
|
|
fixed_memory32->write_protect);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-04-29 06:34:06 +08:00
|
|
|
int pnpacpi_encode_resources(struct pnp_dev *dev, struct acpi_buffer *buffer)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
|
int i = 0;
|
|
|
|
|
/* pnpacpi_build_resource_template allocates extra mem */
|
2007-07-27 01:41:20 +08:00
|
|
|
int res_cnt = (buffer->length - 1) / sizeof(struct acpi_resource) - 1;
|
2007-08-16 00:32:10 +08:00
|
|
|
struct acpi_resource *resource = buffer->pointer;
|
2005-04-17 06:20:36 +08:00
|
|
|
int port = 0, irq = 0, dma = 0, mem = 0;
|
|
|
|
|
|
2008-08-20 06:53:47 +08:00
|
|
|
pnp_dbg(&dev->dev, "encode %d resources\n", res_cnt);
|
2005-04-17 06:20:36 +08:00
|
|
|
while (i < res_cnt) {
|
2007-07-27 01:41:20 +08:00
|
|
|
switch (resource->type) {
|
[ACPI] ACPICA 20050930
Completed a major overhaul of the Resource Manager code -
specifically, optimizations in the area of the AML/internal
resource conversion code. The code has been optimized to
simplify and eliminate duplicated code, CPU stack use has
been decreased by optimizing function parameters and local
variables, and naming conventions across the manager have
been standardized for clarity and ease of maintenance (this
includes function, parameter, variable, and struct/typedef
names.)
All Resource Manager dispatch and information tables have
been moved to a single location for clarity and ease of
maintenance. One new file was created, named "rsinfo.c".
The ACPI return macros (return_ACPI_STATUS, etc.) have
been modified to guarantee that the argument is
not evaluated twice, making them less prone to macro
side-effects. However, since there exists the possibility
of additional stack use if a particular compiler cannot
optimize them (such as in the debug generation case),
the original macros are optionally available. Note that
some invocations of the return_VALUE macro may now cause
size mismatch warnings; the return_UINT8 and return_UINT32
macros are provided to eliminate these. (From Randy Dunlap)
Implemented a new mechanism to enable debug tracing for
individual control methods. A new external interface,
acpi_debug_trace(), is provided to enable this mechanism. The
intent is to allow the host OS to easily enable and disable
tracing for problematic control methods. This interface
can be easily exposed to a user or debugger interface if
desired. See the file psxface.c for details.
acpi_ut_callocate() will now return a valid pointer if a
length of zero is specified - a length of one is used
and a warning is issued. This matches the behavior of
acpi_ut_allocate().
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 07:03:00 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_IRQ:
|
2008-04-29 06:34:07 +08:00
|
|
|
pnpacpi_encode_irq(dev, resource,
|
2008-04-29 06:34:24 +08:00
|
|
|
pnp_get_resource(dev, IORESOURCE_IRQ, irq));
|
2005-04-17 06:20:36 +08:00
|
|
|
irq++;
|
|
|
|
|
break;
|
|
|
|
|
|
[ACPI] ACPICA 20050930
Completed a major overhaul of the Resource Manager code -
specifically, optimizations in the area of the AML/internal
resource conversion code. The code has been optimized to
simplify and eliminate duplicated code, CPU stack use has
been decreased by optimizing function parameters and local
variables, and naming conventions across the manager have
been standardized for clarity and ease of maintenance (this
includes function, parameter, variable, and struct/typedef
names.)
All Resource Manager dispatch and information tables have
been moved to a single location for clarity and ease of
maintenance. One new file was created, named "rsinfo.c".
The ACPI return macros (return_ACPI_STATUS, etc.) have
been modified to guarantee that the argument is
not evaluated twice, making them less prone to macro
side-effects. However, since there exists the possibility
of additional stack use if a particular compiler cannot
optimize them (such as in the debug generation case),
the original macros are optionally available. Note that
some invocations of the return_VALUE macro may now cause
size mismatch warnings; the return_UINT8 and return_UINT32
macros are provided to eliminate these. (From Randy Dunlap)
Implemented a new mechanism to enable debug tracing for
individual control methods. A new external interface,
acpi_debug_trace(), is provided to enable this mechanism. The
intent is to allow the host OS to easily enable and disable
tracing for problematic control methods. This interface
can be easily exposed to a user or debugger interface if
desired. See the file psxface.c for details.
acpi_ut_callocate() will now return a valid pointer if a
length of zero is specified - a length of one is used
and a warning is issued. This matches the behavior of
acpi_ut_allocate().
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 07:03:00 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_DMA:
|
2008-04-29 06:34:07 +08:00
|
|
|
pnpacpi_encode_dma(dev, resource,
|
2008-04-29 06:34:24 +08:00
|
|
|
pnp_get_resource(dev, IORESOURCE_DMA, dma));
|
2006-03-29 06:04:00 +08:00
|
|
|
dma++;
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
[ACPI] ACPICA 20050930
Completed a major overhaul of the Resource Manager code -
specifically, optimizations in the area of the AML/internal
resource conversion code. The code has been optimized to
simplify and eliminate duplicated code, CPU stack use has
been decreased by optimizing function parameters and local
variables, and naming conventions across the manager have
been standardized for clarity and ease of maintenance (this
includes function, parameter, variable, and struct/typedef
names.)
All Resource Manager dispatch and information tables have
been moved to a single location for clarity and ease of
maintenance. One new file was created, named "rsinfo.c".
The ACPI return macros (return_ACPI_STATUS, etc.) have
been modified to guarantee that the argument is
not evaluated twice, making them less prone to macro
side-effects. However, since there exists the possibility
of additional stack use if a particular compiler cannot
optimize them (such as in the debug generation case),
the original macros are optionally available. Note that
some invocations of the return_VALUE macro may now cause
size mismatch warnings; the return_UINT8 and return_UINT32
macros are provided to eliminate these. (From Randy Dunlap)
Implemented a new mechanism to enable debug tracing for
individual control methods. A new external interface,
acpi_debug_trace(), is provided to enable this mechanism. The
intent is to allow the host OS to easily enable and disable
tracing for problematic control methods. This interface
can be easily exposed to a user or debugger interface if
desired. See the file psxface.c for details.
acpi_ut_callocate() will now return a valid pointer if a
length of zero is specified - a length of one is used
and a warning is issued. This matches the behavior of
acpi_ut_allocate().
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 07:03:00 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_IO:
|
2008-04-29 06:34:07 +08:00
|
|
|
pnpacpi_encode_io(dev, resource,
|
2008-04-29 06:34:24 +08:00
|
|
|
pnp_get_resource(dev, IORESOURCE_IO, port));
|
2006-03-29 06:04:00 +08:00
|
|
|
port++;
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
[ACPI] ACPICA 20050930
Completed a major overhaul of the Resource Manager code -
specifically, optimizations in the area of the AML/internal
resource conversion code. The code has been optimized to
simplify and eliminate duplicated code, CPU stack use has
been decreased by optimizing function parameters and local
variables, and naming conventions across the manager have
been standardized for clarity and ease of maintenance (this
includes function, parameter, variable, and struct/typedef
names.)
All Resource Manager dispatch and information tables have
been moved to a single location for clarity and ease of
maintenance. One new file was created, named "rsinfo.c".
The ACPI return macros (return_ACPI_STATUS, etc.) have
been modified to guarantee that the argument is
not evaluated twice, making them less prone to macro
side-effects. However, since there exists the possibility
of additional stack use if a particular compiler cannot
optimize them (such as in the debug generation case),
the original macros are optionally available. Note that
some invocations of the return_VALUE macro may now cause
size mismatch warnings; the return_UINT8 and return_UINT32
macros are provided to eliminate these. (From Randy Dunlap)
Implemented a new mechanism to enable debug tracing for
individual control methods. A new external interface,
acpi_debug_trace(), is provided to enable this mechanism. The
intent is to allow the host OS to easily enable and disable
tracing for problematic control methods. This interface
can be easily exposed to a user or debugger interface if
desired. See the file psxface.c for details.
acpi_ut_callocate() will now return a valid pointer if a
length of zero is specified - a length of one is used
and a warning is issued. This matches the behavior of
acpi_ut_allocate().
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 07:03:00 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_FIXED_IO:
|
2008-04-29 06:34:07 +08:00
|
|
|
pnpacpi_encode_fixed_io(dev, resource,
|
2008-04-29 06:34:24 +08:00
|
|
|
pnp_get_resource(dev, IORESOURCE_IO, port));
|
2006-03-29 06:04:00 +08:00
|
|
|
port++;
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
[ACPI] ACPICA 20050930
Completed a major overhaul of the Resource Manager code -
specifically, optimizations in the area of the AML/internal
resource conversion code. The code has been optimized to
simplify and eliminate duplicated code, CPU stack use has
been decreased by optimizing function parameters and local
variables, and naming conventions across the manager have
been standardized for clarity and ease of maintenance (this
includes function, parameter, variable, and struct/typedef
names.)
All Resource Manager dispatch and information tables have
been moved to a single location for clarity and ease of
maintenance. One new file was created, named "rsinfo.c".
The ACPI return macros (return_ACPI_STATUS, etc.) have
been modified to guarantee that the argument is
not evaluated twice, making them less prone to macro
side-effects. However, since there exists the possibility
of additional stack use if a particular compiler cannot
optimize them (such as in the debug generation case),
the original macros are optionally available. Note that
some invocations of the return_VALUE macro may now cause
size mismatch warnings; the return_UINT8 and return_UINT32
macros are provided to eliminate these. (From Randy Dunlap)
Implemented a new mechanism to enable debug tracing for
individual control methods. A new external interface,
acpi_debug_trace(), is provided to enable this mechanism. The
intent is to allow the host OS to easily enable and disable
tracing for problematic control methods. This interface
can be easily exposed to a user or debugger interface if
desired. See the file psxface.c for details.
acpi_ut_callocate() will now return a valid pointer if a
length of zero is specified - a length of one is used
and a warning is issued. This matches the behavior of
acpi_ut_allocate().
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 07:03:00 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_MEMORY24:
|
2008-04-29 06:34:07 +08:00
|
|
|
pnpacpi_encode_mem24(dev, resource,
|
2008-04-29 06:34:24 +08:00
|
|
|
pnp_get_resource(dev, IORESOURCE_MEM, mem));
|
2006-03-29 06:04:00 +08:00
|
|
|
mem++;
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
[ACPI] ACPICA 20050930
Completed a major overhaul of the Resource Manager code -
specifically, optimizations in the area of the AML/internal
resource conversion code. The code has been optimized to
simplify and eliminate duplicated code, CPU stack use has
been decreased by optimizing function parameters and local
variables, and naming conventions across the manager have
been standardized for clarity and ease of maintenance (this
includes function, parameter, variable, and struct/typedef
names.)
All Resource Manager dispatch and information tables have
been moved to a single location for clarity and ease of
maintenance. One new file was created, named "rsinfo.c".
The ACPI return macros (return_ACPI_STATUS, etc.) have
been modified to guarantee that the argument is
not evaluated twice, making them less prone to macro
side-effects. However, since there exists the possibility
of additional stack use if a particular compiler cannot
optimize them (such as in the debug generation case),
the original macros are optionally available. Note that
some invocations of the return_VALUE macro may now cause
size mismatch warnings; the return_UINT8 and return_UINT32
macros are provided to eliminate these. (From Randy Dunlap)
Implemented a new mechanism to enable debug tracing for
individual control methods. A new external interface,
acpi_debug_trace(), is provided to enable this mechanism. The
intent is to allow the host OS to easily enable and disable
tracing for problematic control methods. This interface
can be easily exposed to a user or debugger interface if
desired. See the file psxface.c for details.
acpi_ut_callocate() will now return a valid pointer if a
length of zero is specified - a length of one is used
and a warning is issued. This matches the behavior of
acpi_ut_allocate().
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 07:03:00 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_MEMORY32:
|
2008-04-29 06:34:07 +08:00
|
|
|
pnpacpi_encode_mem32(dev, resource,
|
2008-04-29 06:34:24 +08:00
|
|
|
pnp_get_resource(dev, IORESOURCE_MEM, mem));
|
2006-03-29 06:04:00 +08:00
|
|
|
mem++;
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
[ACPI] ACPICA 20050930
Completed a major overhaul of the Resource Manager code -
specifically, optimizations in the area of the AML/internal
resource conversion code. The code has been optimized to
simplify and eliminate duplicated code, CPU stack use has
been decreased by optimizing function parameters and local
variables, and naming conventions across the manager have
been standardized for clarity and ease of maintenance (this
includes function, parameter, variable, and struct/typedef
names.)
All Resource Manager dispatch and information tables have
been moved to a single location for clarity and ease of
maintenance. One new file was created, named "rsinfo.c".
The ACPI return macros (return_ACPI_STATUS, etc.) have
been modified to guarantee that the argument is
not evaluated twice, making them less prone to macro
side-effects. However, since there exists the possibility
of additional stack use if a particular compiler cannot
optimize them (such as in the debug generation case),
the original macros are optionally available. Note that
some invocations of the return_VALUE macro may now cause
size mismatch warnings; the return_UINT8 and return_UINT32
macros are provided to eliminate these. (From Randy Dunlap)
Implemented a new mechanism to enable debug tracing for
individual control methods. A new external interface,
acpi_debug_trace(), is provided to enable this mechanism. The
intent is to allow the host OS to easily enable and disable
tracing for problematic control methods. This interface
can be easily exposed to a user or debugger interface if
desired. See the file psxface.c for details.
acpi_ut_callocate() will now return a valid pointer if a
length of zero is specified - a length of one is used
and a warning is issued. This matches the behavior of
acpi_ut_allocate().
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 07:03:00 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
|
2008-04-29 06:34:07 +08:00
|
|
|
pnpacpi_encode_fixed_mem32(dev, resource,
|
2008-04-29 06:34:24 +08:00
|
|
|
pnp_get_resource(dev, IORESOURCE_MEM, mem));
|
2006-03-29 06:04:00 +08:00
|
|
|
mem++;
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
2006-01-20 14:11:37 +08:00
|
|
|
case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
|
2008-04-29 06:34:07 +08:00
|
|
|
pnpacpi_encode_ext_irq(dev, resource,
|
2008-04-29 06:34:24 +08:00
|
|
|
pnp_get_resource(dev, IORESOURCE_IRQ, irq));
|
2006-01-20 14:11:37 +08:00
|
|
|
irq++;
|
|
|
|
|
break;
|
|
|
|
|
case ACPI_RESOURCE_TYPE_START_DEPENDENT:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_END_DEPENDENT:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_VENDOR:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_END_TAG:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_ADDRESS16:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_ADDRESS32:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_ADDRESS64:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_GENERIC_REGISTER:
|
2007-07-27 01:41:20 +08:00
|
|
|
default: /* other type */
|
2008-04-29 06:34:12 +08:00
|
|
|
dev_warn(&dev->dev, "can't encode unknown resource "
|
|
|
|
|
"type %d\n", resource->type);
|
2005-04-17 06:20:36 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
2006-03-29 06:04:00 +08:00
|
|
|
resource++;
|
|
|
|
|
i++;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|