2005-04-16 22:20:36 +00: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-27 22:57:19 +00: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-09-30 23:03:00 +00:00
|
|
|
*
|
2005-04-16 22:20:36 +00: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-28 22:34:28 +00:00
|
|
|
#include <linux/pnp.h>
|
|
|
|
|
#include "../base.h"
|
2005-04-16 22:20:36 +00:00
|
|
|
#include "pnpacpi.h"
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_IA64
|
|
|
|
|
#define valid_IRQ(i) (1)
|
|
|
|
|
#else
|
|
|
|
|
#define valid_IRQ(i) (((i) != 0) && ((i) != 2))
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Allocated Resources
|
|
|
|
|
*/
|
2008-04-28 22:34:02 +00:00
|
|
|
static int irq_flags(int triggering, int polarity, int shareable)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-04-28 22:34:02 +00:00
|
|
|
int flags;
|
|
|
|
|
|
[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-09-30 23:03:00 +00:00
|
|
|
if (triggering == ACPI_LEVEL_SENSITIVE) {
|
2006-03-28 22:04:00 +00:00
|
|
|
if (polarity == ACPI_ACTIVE_LOW)
|
2008-04-28 22:34:02 +00:00
|
|
|
flags = IORESOURCE_IRQ_LOWLEVEL;
|
2005-04-16 22:20:36 +00:00
|
|
|
else
|
2008-04-28 22:34:02 +00:00
|
|
|
flags = IORESOURCE_IRQ_HIGHLEVEL;
|
2007-07-26 17:41:20 +00:00
|
|
|
} else {
|
2006-03-28 22:04:00 +00:00
|
|
|
if (polarity == ACPI_ACTIVE_LOW)
|
2008-04-28 22:34:02 +00:00
|
|
|
flags = IORESOURCE_IRQ_LOWEDGE;
|
2005-04-16 22:20:36 +00:00
|
|
|
else
|
2008-04-28 22:34:02 +00:00
|
|
|
flags = IORESOURCE_IRQ_HIGHEDGE;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2008-04-28 22:34:02 +00:00
|
|
|
|
2008-06-09 23:52:05 +00:00
|
|
|
if (shareable == ACPI_SHARED)
|
2008-04-28 22:34:02 +00:00
|
|
|
flags |= IORESOURCE_IRQ_SHAREABLE;
|
|
|
|
|
|
|
|
|
|
return flags;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-06-09 23:52:04 +00:00
|
|
|
static void decode_irq_flags(struct pnp_dev *dev, int flags, int *triggering,
|
2008-06-09 23:52:05 +00:00
|
|
|
int *polarity, int *shareable)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-06-09 23:52:04 +00:00
|
|
|
switch (flags & (IORESOURCE_IRQ_LOWLEVEL | IORESOURCE_IRQ_HIGHLEVEL |
|
|
|
|
|
IORESOURCE_IRQ_LOWEDGE | IORESOURCE_IRQ_HIGHEDGE)) {
|
2005-04-16 22:20:36 +00: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-09-30 23:03:00 +00:00
|
|
|
*triggering = ACPI_LEVEL_SENSITIVE;
|
|
|
|
|
*polarity = ACPI_ACTIVE_LOW;
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
2006-03-28 22:04:00 +00: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-09-30 23:03:00 +00:00
|
|
|
*triggering = ACPI_LEVEL_SENSITIVE;
|
|
|
|
|
*polarity = ACPI_ACTIVE_HIGH;
|
2005-04-16 22:20:36 +00: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-09-30 23:03:00 +00:00
|
|
|
*triggering = ACPI_EDGE_SENSITIVE;
|
|
|
|
|
*polarity = ACPI_ACTIVE_LOW;
|
2005-04-16 22:20:36 +00: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-09-30 23:03:00 +00:00
|
|
|
*triggering = ACPI_EDGE_SENSITIVE;
|
|
|
|
|
*polarity = ACPI_ACTIVE_HIGH;
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
2008-06-09 23:52:04 +00: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-16 22:20:36 +00:00
|
|
|
}
|
2008-06-09 23:52:05 +00:00
|
|
|
|
|
|
|
|
if (flags & IORESOURCE_IRQ_SHAREABLE)
|
|
|
|
|
*shareable = ACPI_SHARED;
|
|
|
|
|
else
|
|
|
|
|
*shareable = ACPI_EXCLUSIVE;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:06 +00:00
|
|
|
static void pnpacpi_parse_allocated_irqresource(struct pnp_dev *dev,
|
2007-07-26 17:41:21 +00:00
|
|
|
u32 gsi, int triggering,
|
|
|
|
|
int polarity, int shareable)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-04-28 22:34:34 +00:00
|
|
|
int irq, flags;
|
2007-11-17 06:05:28 +00:00
|
|
|
int p, t;
|
2005-09-03 04:37:56 +00:00
|
|
|
|
2008-06-27 22:56:58 +00:00
|
|
|
if (!valid_IRQ(gsi)) {
|
|
|
|
|
pnp_add_irq_resource(dev, gsi, IORESOURCE_DISABLED);
|
2005-09-03 04:37:56 +00:00
|
|
|
return;
|
2008-06-27 22:56:58 +00:00
|
|
|
}
|
2005-09-03 04:37:56 +00:00
|
|
|
|
2007-11-17 06:05:28 +00:00
|
|
|
/*
|
|
|
|
|
* in IO-APIC mode, use overrided attribute. Two reasons:
|
|
|
|
|
* 1. BIOS bug in DSDT
|
|
|
|
|
* 2. BIOS uses IO-APIC mode Interrupt Source Override
|
|
|
|
|
*/
|
|
|
|
|
if (!acpi_get_override_irq(gsi, &t, &p)) {
|
|
|
|
|
t = t ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
|
|
|
|
|
p = p ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
|
|
|
|
|
|
|
|
|
|
if (triggering != t || polarity != p) {
|
2008-04-28 22:34:12 +00:00
|
|
|
dev_warn(&dev->dev, "IRQ %d override to %s, %s\n",
|
2007-11-17 06:05:28 +00:00
|
|
|
gsi, t ? "edge":"level", p ? "low":"high");
|
|
|
|
|
triggering = t;
|
|
|
|
|
polarity = p;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:34 +00:00
|
|
|
flags = irq_flags(triggering, polarity, shareable);
|
2009-04-28 01:01:20 +00:00
|
|
|
irq = acpi_register_gsi(&dev->dev, gsi, triggering, polarity);
|
2008-04-28 22:34:34 +00:00
|
|
|
if (irq >= 0)
|
|
|
|
|
pcibios_penalize_isa_irq(irq, 1);
|
|
|
|
|
else
|
|
|
|
|
flags |= IORESOURCE_DISABLED;
|
2005-09-03 04:37:56 +00:00
|
|
|
|
2008-04-28 22:34:34 +00:00
|
|
|
pnp_add_irq_resource(dev, irq, flags);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-08-19 22:53:21 +00:00
|
|
|
static int dma_flags(struct pnp_dev *dev, int type, int bus_master,
|
|
|
|
|
int transfer)
|
2007-03-09 04:29:29 +00: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-19 22:53:21 +00:00
|
|
|
dev_err(&dev->dev, "invalid DMA type %d\n", type);
|
2007-03-09 04:29:29 +00: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-19 22:53:21 +00:00
|
|
|
dev_err(&dev->dev, "invalid DMA transfer type %d\n", transfer);
|
2007-03-09 04:29:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return flags;
|
|
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:36 +00:00
|
|
|
static void pnpacpi_parse_allocated_ioresource(struct pnp_dev *dev, u64 start,
|
2010-03-05 17:47:52 +00:00
|
|
|
u64 len, int io_decode,
|
|
|
|
|
int window)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-04-28 22:34:36 +00:00
|
|
|
int flags = 0;
|
|
|
|
|
u64 end = start + len - 1;
|
2007-07-26 17:41:21 +00:00
|
|
|
|
2008-04-28 22:34:36 +00:00
|
|
|
if (io_decode == ACPI_DECODE_16)
|
2008-06-27 22:57:03 +00:00
|
|
|
flags |= IORESOURCE_IO_16BIT_ADDR;
|
2008-04-28 22:34:36 +00:00
|
|
|
if (len == 0 || end >= 0x10003)
|
|
|
|
|
flags |= IORESOURCE_DISABLED;
|
2010-03-05 17:47:52 +00:00
|
|
|
if (window)
|
|
|
|
|
flags |= IORESOURCE_WINDOW;
|
2008-04-28 22:34:36 +00:00
|
|
|
|
|
|
|
|
pnp_add_io_resource(dev, start, end, flags);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-06-27 22:57:19 +00: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);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:06 +00:00
|
|
|
static void pnpacpi_parse_allocated_memresource(struct pnp_dev *dev,
|
2008-04-28 22:34:37 +00:00
|
|
|
u64 start, u64 len,
|
2010-03-05 17:47:52 +00:00
|
|
|
int write_protect, int window)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-04-28 22:34:37 +00:00
|
|
|
int flags = 0;
|
|
|
|
|
u64 end = start + len - 1;
|
|
|
|
|
|
|
|
|
|
if (len == 0)
|
|
|
|
|
flags |= IORESOURCE_DISABLED;
|
|
|
|
|
if (write_protect == ACPI_READ_WRITE_MEMORY)
|
|
|
|
|
flags |= IORESOURCE_MEM_WRITEABLE;
|
2010-03-05 17:47:52 +00:00
|
|
|
if (window)
|
|
|
|
|
flags |= IORESOURCE_WINDOW;
|
2008-04-28 22:34:37 +00:00
|
|
|
|
|
|
|
|
pnp_add_mem_resource(dev, start, end, flags);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2010-03-05 17:47:57 +00:00
|
|
|
static void pnpacpi_parse_allocated_busresource(struct pnp_dev *dev,
|
|
|
|
|
u64 start, u64 len)
|
|
|
|
|
{
|
|
|
|
|
u64 end = start + len - 1;
|
|
|
|
|
|
|
|
|
|
pnp_add_bus_resource(dev, start, end);
|
|
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:06 +00:00
|
|
|
static void pnpacpi_parse_allocated_address_space(struct pnp_dev *dev,
|
2007-07-26 17:41:21 +00:00
|
|
|
struct acpi_resource *res)
|
2006-03-28 22:03:00 +00:00
|
|
|
{
|
|
|
|
|
struct acpi_resource_address64 addr, *p = &addr;
|
|
|
|
|
acpi_status status;
|
2010-03-05 17:47:52 +00:00
|
|
|
int window;
|
2006-03-28 22:03:00 +00:00
|
|
|
|
|
|
|
|
status = acpi_resource_to_address64(res, p);
|
|
|
|
|
if (!ACPI_SUCCESS(status)) {
|
2008-04-28 22:34:12 +00:00
|
|
|
dev_warn(&dev->dev, "failed to convert resource type %d\n",
|
2007-07-26 17:41:20 +00:00
|
|
|
res->type);
|
2006-03-28 22:03:00 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2010-03-05 17:47:52 +00:00
|
|
|
window = (p->producer_consumer == ACPI_PRODUCER) ? 1 : 0;
|
2006-08-05 19:15:12 +00:00
|
|
|
|
2006-03-28 22:03:00 +00:00
|
|
|
if (p->resource_type == ACPI_MEMORY_RANGE)
|
2008-04-28 22:34:06 +00:00
|
|
|
pnpacpi_parse_allocated_memresource(dev,
|
2007-07-26 17:41:21 +00:00
|
|
|
p->minimum, p->address_length,
|
2010-03-05 17:47:52 +00:00
|
|
|
p->info.mem.write_protect, window);
|
2006-03-28 22:03:00 +00:00
|
|
|
else if (p->resource_type == ACPI_IO_RANGE)
|
2008-04-28 22:34:06 +00:00
|
|
|
pnpacpi_parse_allocated_ioresource(dev,
|
2007-07-26 17:41:21 +00:00
|
|
|
p->minimum, p->address_length,
|
|
|
|
|
p->granularity == 0xfff ? ACPI_DECODE_10 :
|
2010-03-05 17:47:52 +00:00
|
|
|
ACPI_DECODE_16, window);
|
2010-03-05 17:47:57 +00:00
|
|
|
else if (p->resource_type == ACPI_BUS_NUMBER_RANGE)
|
|
|
|
|
pnpacpi_parse_allocated_busresource(dev, p->minimum,
|
|
|
|
|
p->address_length);
|
2006-03-28 22:03:00 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-05-21 21:49:59 +00:00
|
|
|
static void pnpacpi_parse_allocated_ext_address_space(struct pnp_dev *dev,
|
|
|
|
|
struct acpi_resource *res)
|
|
|
|
|
{
|
|
|
|
|
struct acpi_resource_extended_address64 *p = &res->data.ext_address64;
|
2010-03-05 17:47:52 +00:00
|
|
|
int window;
|
2009-05-21 21:49:59 +00:00
|
|
|
|
2010-03-05 17:47:52 +00:00
|
|
|
window = (p->producer_consumer == ACPI_PRODUCER) ? 1 : 0;
|
2009-05-21 21:49:59 +00:00
|
|
|
|
|
|
|
|
if (p->resource_type == ACPI_MEMORY_RANGE)
|
|
|
|
|
pnpacpi_parse_allocated_memresource(dev,
|
|
|
|
|
p->minimum, p->address_length,
|
2010-03-05 17:47:52 +00:00
|
|
|
p->info.mem.write_protect, window);
|
2009-05-21 21:49:59 +00:00
|
|
|
else if (p->resource_type == ACPI_IO_RANGE)
|
|
|
|
|
pnpacpi_parse_allocated_ioresource(dev,
|
|
|
|
|
p->minimum, p->address_length,
|
|
|
|
|
p->granularity == 0xfff ? ACPI_DECODE_10 :
|
2010-03-05 17:47:52 +00:00
|
|
|
ACPI_DECODE_16, window);
|
2010-03-05 17:47:57 +00:00
|
|
|
else if (p->resource_type == ACPI_BUS_NUMBER_RANGE)
|
|
|
|
|
pnpacpi_parse_allocated_busresource(dev, p->minimum,
|
|
|
|
|
p->address_length);
|
2009-05-21 21:49:59 +00:00
|
|
|
}
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
static acpi_status pnpacpi_allocated_resource(struct acpi_resource *res,
|
2007-07-26 17:41:20 +00:00
|
|
|
void *data)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-04-28 22:34:06 +00:00
|
|
|
struct pnp_dev *dev = data;
|
2008-04-28 22:34:00 +00:00
|
|
|
struct acpi_resource_irq *irq;
|
|
|
|
|
struct acpi_resource_dma *dma;
|
|
|
|
|
struct acpi_resource_io *io;
|
|
|
|
|
struct acpi_resource_fixed_io *fixed_io;
|
2008-06-27 22:57:19 +00:00
|
|
|
struct acpi_resource_vendor_typed *vendor_typed;
|
2008-04-28 22:34:00 +00:00
|
|
|
struct acpi_resource_memory24 *memory24;
|
|
|
|
|
struct acpi_resource_memory32 *memory32;
|
|
|
|
|
struct acpi_resource_fixed_memory32 *fixed_memory32;
|
|
|
|
|
struct acpi_resource_extended_irq *extended_irq;
|
2008-04-28 22:34:35 +00:00
|
|
|
int i, flags;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2005-09-22 04:25:18 +00: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-09-30 23:03:00 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_IRQ:
|
2005-09-03 04:37:56 +00:00
|
|
|
/*
|
|
|
|
|
* Per spec, only one interrupt per descriptor is allowed in
|
|
|
|
|
* _CRS, but some firmware violates this, so parse them all.
|
|
|
|
|
*/
|
2008-04-28 22:34:00 +00:00
|
|
|
irq = &res->data.irq;
|
2008-06-27 22:56:58 +00:00
|
|
|
if (irq->interrupt_count == 0)
|
|
|
|
|
pnp_add_irq_resource(dev, 0, IORESOURCE_DISABLED);
|
|
|
|
|
else {
|
|
|
|
|
for (i = 0; i < irq->interrupt_count; i++) {
|
|
|
|
|
pnpacpi_parse_allocated_irqresource(dev,
|
|
|
|
|
irq->interrupts[i],
|
|
|
|
|
irq->triggering,
|
|
|
|
|
irq->polarity,
|
|
|
|
|
irq->sharable);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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.
|
|
|
|
|
*/
|
|
|
|
|
if (pnp_can_write(dev) && irq->interrupt_count > 1) {
|
|
|
|
|
dev_warn(&dev->dev, "multiple interrupts in "
|
|
|
|
|
"_CRS descriptor; configuration can't "
|
|
|
|
|
"be changed\n");
|
|
|
|
|
dev->capabilities &= ~PNP_WRITE;
|
|
|
|
|
}
|
2005-04-16 22:20:36 +00: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-09-30 23:03:00 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_DMA:
|
2008-04-28 22:34:00 +00:00
|
|
|
dma = &res->data.dma;
|
2008-06-27 22:56:58 +00:00
|
|
|
if (dma->channel_count > 0 && dma->channels[0] != (u8) -1)
|
2008-08-19 22:53:21 +00:00
|
|
|
flags = dma_flags(dev, dma->type, dma->bus_master,
|
2008-04-28 22:34:35 +00:00
|
|
|
dma->transfer);
|
2008-06-27 22:56:58 +00:00
|
|
|
else
|
|
|
|
|
flags = IORESOURCE_DISABLED;
|
|
|
|
|
pnp_add_dma_resource(dev, dma->channels[0], flags);
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
2006-01-20 06:11:37 +00:00
|
|
|
|
[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-09-30 23:03:00 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_IO:
|
2008-04-28 22:34:00 +00:00
|
|
|
io = &res->data.io;
|
2008-04-28 22:34:06 +00:00
|
|
|
pnpacpi_parse_allocated_ioresource(dev,
|
2008-04-28 22:34:00 +00:00
|
|
|
io->minimum,
|
|
|
|
|
io->address_length,
|
2010-03-05 17:47:52 +00:00
|
|
|
io->io_decode, 0);
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
2006-01-20 06:11:37 +00:00
|
|
|
|
|
|
|
|
case ACPI_RESOURCE_TYPE_START_DEPENDENT:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_END_DEPENDENT:
|
|
|
|
|
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-09-30 23:03:00 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_FIXED_IO:
|
2008-04-28 22:34:00 +00:00
|
|
|
fixed_io = &res->data.fixed_io;
|
2008-04-28 22:34:06 +00:00
|
|
|
pnpacpi_parse_allocated_ioresource(dev,
|
2008-04-28 22:34:00 +00:00
|
|
|
fixed_io->address,
|
|
|
|
|
fixed_io->address_length,
|
2010-03-05 17:47:52 +00:00
|
|
|
ACPI_DECODE_10, 0);
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
2006-01-20 06:11:37 +00:00
|
|
|
|
|
|
|
|
case ACPI_RESOURCE_TYPE_VENDOR:
|
2008-06-27 22:57:19 +00:00
|
|
|
vendor_typed = &res->data.vendor_typed;
|
|
|
|
|
pnpacpi_parse_allocated_vendor(dev, vendor_typed);
|
2006-01-20 06:11:37 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case ACPI_RESOURCE_TYPE_END_TAG:
|
|
|
|
|
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-09-30 23:03:00 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_MEMORY24:
|
2008-04-28 22:34:00 +00:00
|
|
|
memory24 = &res->data.memory24;
|
2008-04-28 22:34:06 +00:00
|
|
|
pnpacpi_parse_allocated_memresource(dev,
|
2008-04-28 22:34:00 +00:00
|
|
|
memory24->minimum,
|
|
|
|
|
memory24->address_length,
|
2010-03-05 17:47:52 +00:00
|
|
|
memory24->write_protect, 0);
|
2005-04-16 22:20:36 +00: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-09-30 23:03:00 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_MEMORY32:
|
2008-04-28 22:34:00 +00:00
|
|
|
memory32 = &res->data.memory32;
|
2008-04-28 22:34:06 +00:00
|
|
|
pnpacpi_parse_allocated_memresource(dev,
|
2008-04-28 22:34:00 +00:00
|
|
|
memory32->minimum,
|
|
|
|
|
memory32->address_length,
|
2010-03-05 17:47:52 +00:00
|
|
|
memory32->write_protect, 0);
|
2005-04-16 22:20:36 +00: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-09-30 23:03:00 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
|
2008-04-28 22:34:00 +00:00
|
|
|
fixed_memory32 = &res->data.fixed_memory32;
|
2008-04-28 22:34:06 +00:00
|
|
|
pnpacpi_parse_allocated_memresource(dev,
|
2008-04-28 22:34:00 +00:00
|
|
|
fixed_memory32->address,
|
|
|
|
|
fixed_memory32->address_length,
|
2010-03-05 17:47:52 +00:00
|
|
|
fixed_memory32->write_protect, 0);
|
2005-04-16 22:20:36 +00: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-09-30 23:03:00 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_ADDRESS16:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_ADDRESS32:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_ADDRESS64:
|
2008-04-28 22:34:06 +00:00
|
|
|
pnpacpi_parse_allocated_address_space(dev, res);
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
2006-01-20 06:11:37 +00:00
|
|
|
|
|
|
|
|
case ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64:
|
2009-05-21 21:49:59 +00:00
|
|
|
pnpacpi_parse_allocated_ext_address_space(dev, res);
|
2006-01-20 06:11:37 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
|
2008-04-28 22:34:00 +00:00
|
|
|
extended_irq = &res->data.extended_irq;
|
2006-08-05 19:15:12 +00:00
|
|
|
|
2008-06-27 22:56:58 +00:00
|
|
|
if (extended_irq->interrupt_count == 0)
|
|
|
|
|
pnp_add_irq_resource(dev, 0, IORESOURCE_DISABLED);
|
|
|
|
|
else {
|
|
|
|
|
for (i = 0; i < extended_irq->interrupt_count; i++) {
|
|
|
|
|
pnpacpi_parse_allocated_irqresource(dev,
|
|
|
|
|
extended_irq->interrupts[i],
|
|
|
|
|
extended_irq->triggering,
|
|
|
|
|
extended_irq->polarity,
|
|
|
|
|
extended_irq->sharable);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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.
|
|
|
|
|
*/
|
|
|
|
|
if (pnp_can_write(dev) &&
|
|
|
|
|
extended_irq->interrupt_count > 1) {
|
|
|
|
|
dev_warn(&dev->dev, "multiple interrupts in "
|
|
|
|
|
"_CRS descriptor; configuration can't "
|
|
|
|
|
"be changed\n");
|
|
|
|
|
dev->capabilities &= ~PNP_WRITE;
|
|
|
|
|
}
|
2006-01-20 06:11:37 +00:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case ACPI_RESOURCE_TYPE_GENERIC_REGISTER:
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
2006-01-20 06:11:37 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
default:
|
2008-04-28 22:34:12 +00:00
|
|
|
dev_warn(&dev->dev, "unknown resource type %d in _CRS\n",
|
|
|
|
|
res->type);
|
2005-04-16 22:20:36 +00:00
|
|
|
return AE_ERROR;
|
|
|
|
|
}
|
2006-03-28 22:04:00 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
return AE_OK;
|
|
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:39 +00:00
|
|
|
int pnpacpi_parse_allocated_resource(struct pnp_dev *dev)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2009-11-18 00:05:14 +00:00
|
|
|
struct acpi_device *acpi_dev = dev->data;
|
|
|
|
|
acpi_handle handle = acpi_dev->handle;
|
2008-04-28 22:34:39 +00:00
|
|
|
acpi_status status;
|
2008-04-28 22:34:06 +00:00
|
|
|
|
2008-08-19 22:53:47 +00:00
|
|
|
pnp_dbg(&dev->dev, "parse allocated resources\n");
|
2008-04-28 22:34:07 +00:00
|
|
|
|
2008-04-28 22:34:09 +00:00
|
|
|
pnp_init_resources(dev);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-04-28 22:34:39 +00: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-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:04 +00: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-27 22:57:17 +00:00
|
|
|
unsigned int option_flags,
|
2008-02-06 09:40:03 +00:00
|
|
|
struct acpi_resource_dma *p)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
|
int i;
|
2008-06-27 22:57:11 +00:00
|
|
|
unsigned char map = 0, flags;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
[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-09-30 23:03:00 +00:00
|
|
|
if (p->channel_count == 0)
|
2005-04-16 22:20:36 +00:00
|
|
|
return;
|
|
|
|
|
|
2007-07-26 17:41:20 +00:00
|
|
|
for (i = 0; i < p->channel_count; i++)
|
2008-06-27 22:57:11 +00:00
|
|
|
map |= 1 << p->channels[i];
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-08-19 22:53:21 +00: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-27 22:57:17 +00:00
|
|
|
pnp_register_dma_resource(dev, option_flags, map, flags);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:04 +00: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-27 22:57:17 +00:00
|
|
|
unsigned int option_flags,
|
2008-02-06 09:40:03 +00:00
|
|
|
struct acpi_resource_irq *p)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
|
int i;
|
2008-06-27 22:57:11 +00:00
|
|
|
pnp_irq_mask_t map;
|
|
|
|
|
unsigned char flags;
|
2006-03-28 22:04:00 +00:00
|
|
|
|
[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-09-30 23:03:00 +00:00
|
|
|
if (p->interrupt_count == 0)
|
2005-04-16 22:20:36 +00:00
|
|
|
return;
|
|
|
|
|
|
2008-06-27 22:57:11 +00:00
|
|
|
bitmap_zero(map.bits, PNP_IRQ_NR);
|
2007-07-26 17:41:20 +00:00
|
|
|
for (i = 0; i < p->interrupt_count; i++)
|
2005-04-16 22:20:36 +00:00
|
|
|
if (p->interrupts[i])
|
2008-06-27 22:57:11 +00:00
|
|
|
__set_bit(p->interrupts[i], map.bits);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-06-27 22:57:11 +00:00
|
|
|
flags = 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-27 22:57:17 +00:00
|
|
|
pnp_register_irq_resource(dev, option_flags, &map, flags);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:04 +00: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-27 22:57:17 +00:00
|
|
|
unsigned int option_flags,
|
2008-02-06 09:40:03 +00:00
|
|
|
struct acpi_resource_extended_irq *p)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
|
int i;
|
2008-06-27 22:57:11 +00:00
|
|
|
pnp_irq_mask_t map;
|
|
|
|
|
unsigned char flags;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
[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-09-30 23:03:00 +00:00
|
|
|
if (p->interrupt_count == 0)
|
2005-04-16 22:20:36 +00:00
|
|
|
return;
|
|
|
|
|
|
2008-06-27 22:57:11 +00:00
|
|
|
bitmap_zero(map.bits, PNP_IRQ_NR);
|
2008-06-27 22:57:12 +00: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-16 22:20:36 +00:00
|
|
|
|
2008-06-27 22:57:11 +00:00
|
|
|
flags = 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-27 22:57:17 +00:00
|
|
|
pnp_register_irq_resource(dev, option_flags, &map, flags);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:04 +00: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-27 22:57:17 +00:00
|
|
|
unsigned int option_flags,
|
2008-02-06 09:40:03 +00:00
|
|
|
struct acpi_resource_io *io)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-06-27 22:57:11 +00:00
|
|
|
unsigned char flags = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
[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-09-30 23:03:00 +00:00
|
|
|
if (io->address_length == 0)
|
2005-04-16 22:20:36 +00:00
|
|
|
return;
|
2008-06-27 22:57:11 +00:00
|
|
|
|
|
|
|
|
if (io->io_decode == ACPI_DECODE_16)
|
|
|
|
|
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-27 22:57:17 +00:00
|
|
|
pnp_register_port_resource(dev, option_flags, io->minimum, io->maximum,
|
2008-06-27 22:57:11 +00:00
|
|
|
io->alignment, io->address_length, flags);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:04 +00: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-27 22:57:17 +00:00
|
|
|
unsigned int option_flags,
|
2008-02-06 09:40:03 +00:00
|
|
|
struct acpi_resource_fixed_io *io)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
[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-09-30 23:03:00 +00:00
|
|
|
if (io->address_length == 0)
|
2005-04-16 22:20:36 +00:00
|
|
|
return;
|
2008-06-27 22:57:11 +00: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-27 22:57:17 +00:00
|
|
|
pnp_register_port_resource(dev, option_flags, io->address, io->address,
|
|
|
|
|
0, io->address_length, IORESOURCE_IO_FIXED);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:04 +00: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-27 22:57:17 +00:00
|
|
|
unsigned int option_flags,
|
2008-02-06 09:40:03 +00:00
|
|
|
struct acpi_resource_memory24 *p)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-06-27 22:57:11 +00:00
|
|
|
unsigned char flags = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
[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-09-30 23:03:00 +00:00
|
|
|
if (p->address_length == 0)
|
2005-04-16 22:20:36 +00:00
|
|
|
return;
|
|
|
|
|
|
2008-06-27 22:57:11 +00:00
|
|
|
if (p->write_protect == ACPI_READ_WRITE_MEMORY)
|
|
|
|
|
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-27 22:57:17 +00:00
|
|
|
pnp_register_mem_resource(dev, option_flags, p->minimum, p->maximum,
|
2008-06-27 22:57:11 +00:00
|
|
|
p->alignment, p->address_length, flags);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:04 +00: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-27 22:57:17 +00:00
|
|
|
unsigned int option_flags,
|
2008-02-06 09:40:03 +00:00
|
|
|
struct acpi_resource_memory32 *p)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-06-27 22:57:11 +00:00
|
|
|
unsigned char flags = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
[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-09-30 23:03:00 +00:00
|
|
|
if (p->address_length == 0)
|
2005-04-16 22:20:36 +00:00
|
|
|
return;
|
|
|
|
|
|
2008-06-27 22:57:11 +00:00
|
|
|
if (p->write_protect == ACPI_READ_WRITE_MEMORY)
|
|
|
|
|
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-27 22:57:17 +00:00
|
|
|
pnp_register_mem_resource(dev, option_flags, p->minimum, p->maximum,
|
2008-06-27 22:57:11 +00:00
|
|
|
p->alignment, p->address_length, flags);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:04 +00: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-27 22:57:17 +00:00
|
|
|
unsigned int option_flags,
|
2008-02-06 09:40:03 +00:00
|
|
|
struct acpi_resource_fixed_memory32 *p)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-06-27 22:57:11 +00:00
|
|
|
unsigned char flags = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
[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-09-30 23:03:00 +00:00
|
|
|
if (p->address_length == 0)
|
2005-04-16 22:20:36 +00:00
|
|
|
return;
|
|
|
|
|
|
2008-06-27 22:57:11 +00:00
|
|
|
if (p->write_protect == ACPI_READ_WRITE_MEMORY)
|
|
|
|
|
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-27 22:57:17 +00:00
|
|
|
pnp_register_mem_resource(dev, option_flags, p->address, p->address,
|
2008-06-27 22:57:11 +00:00
|
|
|
0, p->address_length, flags);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:04 +00: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-27 22:57:17 +00:00
|
|
|
unsigned int option_flags,
|
2008-02-06 09:40:03 +00:00
|
|
|
struct acpi_resource *r)
|
2005-09-20 19:26:00 +00:00
|
|
|
{
|
|
|
|
|
struct acpi_resource_address64 addr, *p = &addr;
|
|
|
|
|
acpi_status status;
|
2008-06-27 22:57:11 +00:00
|
|
|
unsigned char flags = 0;
|
2005-09-20 19:26:00 +00:00
|
|
|
|
|
|
|
|
status = acpi_resource_to_address64(r, p);
|
2008-08-19 22:53:21 +00:00
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
|
dev_warn(&dev->dev, "can't convert resource type %d\n",
|
2007-07-26 17:41:20 +00:00
|
|
|
r->type);
|
2005-09-20 19:26:00 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (p->address_length == 0)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if (p->resource_type == ACPI_MEMORY_RANGE) {
|
2008-06-27 22:57:11 +00:00
|
|
|
if (p->info.mem.write_protect == ACPI_READ_WRITE_MEMORY)
|
|
|
|
|
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-27 22:57:17 +00:00
|
|
|
pnp_register_mem_resource(dev, option_flags, p->minimum,
|
|
|
|
|
p->minimum, 0, p->address_length,
|
|
|
|
|
flags);
|
2008-06-27 22:57:11 +00: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-27 22:57:17 +00:00
|
|
|
pnp_register_port_resource(dev, option_flags, p->minimum,
|
|
|
|
|
p->minimum, 0, p->address_length,
|
2008-06-27 22:57:11 +00:00
|
|
|
IORESOURCE_IO_FIXED);
|
2005-09-20 19:26:00 +00:00
|
|
|
}
|
|
|
|
|
|
2009-05-21 21:49:59 +00: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->address_length == 0)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if (p->resource_type == ACPI_MEMORY_RANGE) {
|
|
|
|
|
if (p->info.mem.write_protect == ACPI_READ_WRITE_MEMORY)
|
|
|
|
|
flags = IORESOURCE_MEM_WRITEABLE;
|
|
|
|
|
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,
|
|
|
|
|
IORESOURCE_IO_FIXED);
|
|
|
|
|
}
|
|
|
|
|
|
2005-04-16 22:20:36 +00: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-27 22:57:17 +00:00
|
|
|
unsigned int option_flags;
|
2005-04-16 22:20:36 +00:00
|
|
|
};
|
|
|
|
|
|
2008-02-06 09:40:03 +00:00
|
|
|
static __init acpi_status pnpacpi_option_resource(struct acpi_resource *res,
|
|
|
|
|
void *data)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-06-27 22:57:15 +00:00
|
|
|
int priority;
|
2007-08-15 16:32:10 +00:00
|
|
|
struct acpipnp_parse_option_s *parse_data = data;
|
2005-04-16 22:20:36 +00: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-27 22:57:17 +00:00
|
|
|
unsigned int option_flags = parse_data->option_flags;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2005-09-22 04:25:18 +00:00
|
|
|
switch (res->type) {
|
2007-07-26 17:41:20 +00: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-27 22:57:17 +00:00
|
|
|
pnpacpi_parse_irq_option(dev, option_flags, &res->data.irq);
|
2007-07-26 17:41:20 +00:00
|
|
|
break;
|
2006-01-20 06:11:37 +00:00
|
|
|
|
2007-07-26 17:41:20 +00: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-27 22:57:17 +00:00
|
|
|
pnpacpi_parse_dma_option(dev, option_flags, &res->data.dma);
|
2007-07-26 17:41:20 +00:00
|
|
|
break;
|
2006-01-20 06:11:37 +00:00
|
|
|
|
2007-07-26 17:41:20 +00: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-16 22:20:36 +00:00
|
|
|
break;
|
2006-01-20 06:11:37 +00:00
|
|
|
|
2007-07-26 17:41:20 +00:00
|
|
|
case ACPI_ACCEPTABLE_CONFIGURATION:
|
|
|
|
|
priority = PNP_RES_PRIORITY_ACCEPTABLE;
|
2005-03-25 17:03:15 +00:00
|
|
|
break;
|
2006-01-20 06:11:37 +00:00
|
|
|
|
2007-07-26 17:41:20 +00:00
|
|
|
case ACPI_SUB_OPTIMAL_CONFIGURATION:
|
|
|
|
|
priority = PNP_RES_PRIORITY_FUNCTIONAL;
|
2006-01-20 06:11:37 +00:00
|
|
|
break;
|
2007-07-26 17:41:20 +00:00
|
|
|
default:
|
|
|
|
|
priority = PNP_RES_PRIORITY_INVALID;
|
2006-01-20 06:11:37 +00:00
|
|
|
break;
|
2007-07-26 17:41:20 +00: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-27 22:57:17 +00:00
|
|
|
parse_data->option_flags = pnp_new_dependent_set(dev, priority);
|
2007-07-26 17:41:20 +00:00
|
|
|
break;
|
2006-01-20 06:11:37 +00:00
|
|
|
|
2007-07-26 17:41:20 +00: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-27 22:57:17 +00:00
|
|
|
parse_data->option_flags = 0;
|
2007-07-26 17:41:20 +00:00
|
|
|
break;
|
2006-01-20 06:11:37 +00:00
|
|
|
|
2007-07-26 17:41:20 +00: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-27 22:57:17 +00:00
|
|
|
pnpacpi_parse_port_option(dev, option_flags, &res->data.io);
|
2007-07-26 17:41:20 +00:00
|
|
|
break;
|
2006-01-20 06:11:37 +00:00
|
|
|
|
2007-07-26 17:41:20 +00: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-27 22:57:17 +00:00
|
|
|
pnpacpi_parse_fixed_port_option(dev, option_flags,
|
2008-04-28 22:34:04 +00:00
|
|
|
&res->data.fixed_io);
|
2007-07-26 17:41:20 +00:00
|
|
|
break;
|
2006-01-20 06:11:37 +00:00
|
|
|
|
2007-07-26 17:41:20 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_VENDOR:
|
|
|
|
|
case ACPI_RESOURCE_TYPE_END_TAG:
|
|
|
|
|
break;
|
2006-01-20 06:11:37 +00:00
|
|
|
|
2007-07-26 17:41:20 +00: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-27 22:57:17 +00:00
|
|
|
pnpacpi_parse_mem24_option(dev, option_flags,
|
|
|
|
|
&res->data.memory24);
|
2007-07-26 17:41:20 +00:00
|
|
|
break;
|
2006-01-20 06:11:37 +00:00
|
|
|
|
2007-07-26 17:41:20 +00: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-27 22:57:17 +00:00
|
|
|
pnpacpi_parse_mem32_option(dev, option_flags,
|
|
|
|
|
&res->data.memory32);
|
2007-07-26 17:41:20 +00:00
|
|
|
break;
|
2006-01-20 06:11:37 +00:00
|
|
|
|
2007-07-26 17:41:20 +00: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-27 22:57:17 +00:00
|
|
|
pnpacpi_parse_fixed_mem32_option(dev, option_flags,
|
2007-07-26 17:41:20 +00:00
|
|
|
&res->data.fixed_memory32);
|
|
|
|
|
break;
|
2006-01-20 06:11:37 +00:00
|
|
|
|
2007-07-26 17:41:20 +00: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-27 22:57:17 +00:00
|
|
|
pnpacpi_parse_address_option(dev, option_flags, res);
|
2007-07-26 17:41:20 +00:00
|
|
|
break;
|
2006-01-20 06:11:37 +00:00
|
|
|
|
2007-07-26 17:41:20 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64:
|
2009-05-21 21:49:59 +00:00
|
|
|
pnpacpi_parse_ext_address_option(dev, option_flags, res);
|
2007-07-26 17:41:20 +00: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-27 22:57:17 +00:00
|
|
|
pnpacpi_parse_ext_irq_option(dev, option_flags,
|
2008-04-28 22:34:04 +00:00
|
|
|
&res->data.extended_irq);
|
2007-07-26 17:41:20 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case ACPI_RESOURCE_TYPE_GENERIC_REGISTER:
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default:
|
2008-04-28 22:34:12 +00:00
|
|
|
dev_warn(&dev->dev, "unknown resource type %d in _PRS\n",
|
|
|
|
|
res->type);
|
2007-07-26 17:41:20 +00:00
|
|
|
return AE_ERROR;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2006-03-28 22:04:00 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
return AE_OK;
|
|
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:39 +00:00
|
|
|
int __init pnpacpi_parse_resource_option_data(struct pnp_dev *dev)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2009-11-18 00:05:14 +00:00
|
|
|
struct acpi_device *acpi_dev = dev->data;
|
|
|
|
|
acpi_handle handle = acpi_dev->handle;
|
2005-04-16 22:20:36 +00:00
|
|
|
acpi_status status;
|
|
|
|
|
struct acpipnp_parse_option_s parse_data;
|
|
|
|
|
|
2008-08-19 22:53:47 +00:00
|
|
|
pnp_dbg(&dev->dev, "parse resource options\n");
|
2008-04-28 22:34:07 +00:00
|
|
|
|
2005-04-16 22:20:36 +00: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-27 22:57:17 +00: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-09-30 23:03:00 +00:00
|
|
|
status = acpi_walk_resources(handle, METHOD_NAME__PRS,
|
2007-07-26 17:41:20 +00:00
|
|
|
pnpacpi_option_resource, &parse_data);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-04-28 22:34:39 +00: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-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2006-03-28 22:04:00 +00:00
|
|
|
static int pnpacpi_supported_resource(struct acpi_resource *res)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2005-09-22 04:25:18 +00: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-09-30 23:03:00 +00: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-21 21:49:59 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64:
|
2006-01-20 06:11:37 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
|
2006-03-28 22:04:00 +00:00
|
|
|
return 1;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2006-03-28 22:04:00 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Set resource
|
|
|
|
|
*/
|
|
|
|
|
static acpi_status pnpacpi_count_resources(struct acpi_resource *res,
|
2007-07-26 17:41:20 +00:00
|
|
|
void *data)
|
2006-03-28 22:04:00 +00:00
|
|
|
{
|
2007-08-15 16:32:10 +00:00
|
|
|
int *res_cnt = data;
|
2006-03-28 22:04:00 +00:00
|
|
|
|
|
|
|
|
if (pnpacpi_supported_resource(res))
|
|
|
|
|
(*res_cnt)++;
|
2005-04-16 22:20:36 +00:00
|
|
|
return AE_OK;
|
|
|
|
|
}
|
|
|
|
|
|
2006-03-28 22:04:00 +00:00
|
|
|
static acpi_status pnpacpi_type_resources(struct acpi_resource *res, void *data)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2007-08-15 16:32:10 +00:00
|
|
|
struct acpi_resource **resource = data;
|
2006-03-28 22:04:00 +00:00
|
|
|
|
|
|
|
|
if (pnpacpi_supported_resource(res)) {
|
2005-09-22 04:25:18 +00:00
|
|
|
(*resource)->type = res->type;
|
2006-03-28 22:04:00 +00:00
|
|
|
(*resource)->length = sizeof(struct acpi_resource);
|
2008-06-09 23:52:06 +00:00
|
|
|
if (res->type == ACPI_RESOURCE_TYPE_IRQ)
|
|
|
|
|
(*resource)->data.irq.descriptor_length =
|
|
|
|
|
res->data.irq.descriptor_length;
|
2005-04-16 22:20:36 +00:00
|
|
|
(*resource)++;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return AE_OK;
|
|
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:03 +00:00
|
|
|
int pnpacpi_build_resource_template(struct pnp_dev *dev,
|
2007-07-26 17:41:20 +00:00
|
|
|
struct acpi_buffer *buffer)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2009-11-18 00:05:14 +00:00
|
|
|
struct acpi_device *acpi_dev = dev->data;
|
|
|
|
|
acpi_handle handle = acpi_dev->handle;
|
2005-04-16 22:20:36 +00: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-09-30 23:03:00 +00:00
|
|
|
status = acpi_walk_resources(handle, METHOD_NAME__CRS,
|
2007-07-26 17:41:20 +00:00
|
|
|
pnpacpi_count_resources, &res_cnt);
|
2005-04-16 22:20:36 +00:00
|
|
|
if (ACPI_FAILURE(status)) {
|
2008-04-28 22:34:39 +00:00
|
|
|
dev_err(&dev->dev, "can't evaluate _CRS: %d\n", status);
|
2005-04-16 22:20:36 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
if (!res_cnt)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
buffer->length = sizeof(struct acpi_resource) * (res_cnt + 1) + 1;
|
2006-12-13 08:34:52 +00:00
|
|
|
buffer->pointer = kzalloc(buffer->length - 1, GFP_KERNEL);
|
2005-04-16 22:20:36 +00:00
|
|
|
if (!buffer->pointer)
|
|
|
|
|
return -ENOMEM;
|
2008-04-28 22:34:07 +00:00
|
|
|
|
2005-04-16 22:20:36 +00: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-09-30 23:03:00 +00:00
|
|
|
status = acpi_walk_resources(handle, METHOD_NAME__CRS,
|
2007-07-26 17:41:20 +00:00
|
|
|
pnpacpi_type_resources, &resource);
|
2005-04-16 22:20:36 +00:00
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
|
kfree(buffer->pointer);
|
2008-04-28 22:34:39 +00:00
|
|
|
dev_err(&dev->dev, "can't evaluate _CRS: %d\n", status);
|
2005-04-16 22:20:36 +00: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-09-30 23:03:00 +00:00
|
|
|
resource->type = ACPI_RESOURCE_TYPE_END_TAG;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:07 +00:00
|
|
|
static void pnpacpi_encode_irq(struct pnp_dev *dev,
|
|
|
|
|
struct acpi_resource *resource,
|
2007-07-26 17:41:20 +00:00
|
|
|
struct resource *p)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-04-28 22:34:00 +00:00
|
|
|
struct acpi_resource_irq *irq = &resource->data.irq;
|
2008-06-09 23:52:05 +00:00
|
|
|
int triggering, polarity, shareable;
|
2006-03-28 22:04:00 +00: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-27 22:56:57 +00:00
|
|
|
if (!pnp_resource_enabled(p)) {
|
|
|
|
|
irq->interrupt_count = 0;
|
2008-08-19 22:53:47 +00: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-27 22:56:57 +00:00
|
|
|
p ? "disabled" : "missing");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2008-06-09 23:52:05 +00:00
|
|
|
decode_irq_flags(dev, p->flags, &triggering, &polarity, &shareable);
|
2008-04-28 22:34:00 +00:00
|
|
|
irq->triggering = triggering;
|
|
|
|
|
irq->polarity = polarity;
|
2008-06-09 23:52:05 +00:00
|
|
|
irq->sharable = shareable;
|
2008-04-28 22:34:00 +00:00
|
|
|
irq->interrupt_count = 1;
|
|
|
|
|
irq->interrupts[0] = p->start;
|
2008-04-28 22:34:07 +00:00
|
|
|
|
2008-08-19 22:53:47 +00:00
|
|
|
pnp_dbg(&dev->dev, " encode irq %d %s %s %s (%d-byte descriptor)\n",
|
2008-06-09 23:52:06 +00:00
|
|
|
(int) p->start,
|
2008-04-28 22:34:07 +00:00
|
|
|
triggering == ACPI_LEVEL_SENSITIVE ? "level" : "edge",
|
|
|
|
|
polarity == ACPI_ACTIVE_LOW ? "low" : "high",
|
2008-06-09 23:52:06 +00:00
|
|
|
irq->sharable == ACPI_SHARED ? "shared" : "exclusive",
|
|
|
|
|
irq->descriptor_length);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:07 +00:00
|
|
|
static void pnpacpi_encode_ext_irq(struct pnp_dev *dev,
|
|
|
|
|
struct acpi_resource *resource,
|
2007-07-26 17:41:20 +00:00
|
|
|
struct resource *p)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-04-28 22:34:00 +00:00
|
|
|
struct acpi_resource_extended_irq *extended_irq = &resource->data.extended_irq;
|
2008-06-09 23:52:05 +00:00
|
|
|
int triggering, polarity, shareable;
|
2006-03-28 22:04:00 +00: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-27 22:56:57 +00:00
|
|
|
if (!pnp_resource_enabled(p)) {
|
|
|
|
|
extended_irq->interrupt_count = 0;
|
2008-08-19 22:53:47 +00: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-27 22:56:57 +00:00
|
|
|
p ? "disabled" : "missing");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2008-06-09 23:52:05 +00:00
|
|
|
decode_irq_flags(dev, p->flags, &triggering, &polarity, &shareable);
|
2008-04-28 22:34:00 +00:00
|
|
|
extended_irq->producer_consumer = ACPI_CONSUMER;
|
|
|
|
|
extended_irq->triggering = triggering;
|
|
|
|
|
extended_irq->polarity = polarity;
|
2008-06-09 23:52:05 +00:00
|
|
|
extended_irq->sharable = shareable;
|
2008-04-28 22:34:00 +00:00
|
|
|
extended_irq->interrupt_count = 1;
|
|
|
|
|
extended_irq->interrupts[0] = p->start;
|
2008-04-28 22:34:07 +00:00
|
|
|
|
2008-08-19 22:53:47 +00:00
|
|
|
pnp_dbg(&dev->dev, " encode irq %d %s %s %s\n", (int) p->start,
|
2008-04-28 22:34:07 +00:00
|
|
|
triggering == ACPI_LEVEL_SENSITIVE ? "level" : "edge",
|
|
|
|
|
polarity == ACPI_ACTIVE_LOW ? "low" : "high",
|
|
|
|
|
extended_irq->sharable == ACPI_SHARED ? "shared" : "exclusive");
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:07 +00:00
|
|
|
static void pnpacpi_encode_dma(struct pnp_dev *dev,
|
|
|
|
|
struct acpi_resource *resource,
|
2007-07-26 17:41:20 +00:00
|
|
|
struct resource *p)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-04-28 22:34:00 +00: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-27 22:56:57 +00:00
|
|
|
if (!pnp_resource_enabled(p)) {
|
|
|
|
|
dma->channel_count = 0;
|
2008-08-19 22:53:47 +00: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-27 22:56:57 +00:00
|
|
|
p ? "disabled" : "missing");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* Note: pnp_assign_dma will copy pnp_dma->flags into p->flags */
|
2006-04-07 18:00:27 +00:00
|
|
|
switch (p->flags & IORESOURCE_DMA_SPEED_MASK) {
|
2007-07-26 17:41:20 +00:00
|
|
|
case IORESOURCE_DMA_TYPEA:
|
2008-04-28 22:34:00 +00:00
|
|
|
dma->type = ACPI_TYPE_A;
|
2007-07-26 17:41:20 +00:00
|
|
|
break;
|
|
|
|
|
case IORESOURCE_DMA_TYPEB:
|
2008-04-28 22:34:00 +00:00
|
|
|
dma->type = ACPI_TYPE_B;
|
2007-07-26 17:41:20 +00:00
|
|
|
break;
|
|
|
|
|
case IORESOURCE_DMA_TYPEF:
|
2008-04-28 22:34:00 +00:00
|
|
|
dma->type = ACPI_TYPE_F;
|
2007-07-26 17:41:20 +00:00
|
|
|
break;
|
|
|
|
|
default:
|
2008-04-28 22:34:00 +00:00
|
|
|
dma->type = ACPI_COMPATIBILITY;
|
2006-04-07 18:00:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (p->flags & IORESOURCE_DMA_TYPE_MASK) {
|
2007-07-26 17:41:20 +00:00
|
|
|
case IORESOURCE_DMA_8BIT:
|
2008-04-28 22:34:00 +00:00
|
|
|
dma->transfer = ACPI_TRANSFER_8;
|
2007-07-26 17:41:20 +00:00
|
|
|
break;
|
|
|
|
|
case IORESOURCE_DMA_8AND16BIT:
|
2008-04-28 22:34:00 +00:00
|
|
|
dma->transfer = ACPI_TRANSFER_8_16;
|
2007-07-26 17:41:20 +00:00
|
|
|
break;
|
|
|
|
|
default:
|
2008-04-28 22:34:00 +00:00
|
|
|
dma->transfer = ACPI_TRANSFER_16;
|
2006-04-07 18:00:27 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:00 +00:00
|
|
|
dma->bus_master = !!(p->flags & IORESOURCE_DMA_MASTER);
|
|
|
|
|
dma->channel_count = 1;
|
|
|
|
|
dma->channels[0] = p->start;
|
2008-04-28 22:34:07 +00:00
|
|
|
|
2008-08-19 22:53:47 +00:00
|
|
|
pnp_dbg(&dev->dev, " encode dma %d "
|
2008-04-28 22:34:07 +00:00
|
|
|
"type %#x transfer %#x master %d\n",
|
|
|
|
|
(int) p->start, dma->type, dma->transfer, dma->bus_master);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:07 +00:00
|
|
|
static void pnpacpi_encode_io(struct pnp_dev *dev,
|
|
|
|
|
struct acpi_resource *resource,
|
2007-07-26 17:41:20 +00:00
|
|
|
struct resource *p)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-04-28 22:34:00 +00: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-27 22:56:57 +00:00
|
|
|
if (pnp_resource_enabled(p)) {
|
|
|
|
|
/* Note: pnp_assign_port copies pnp_port->flags into p->flags */
|
2008-06-27 22:57:03 +00: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-27 22:56:57 +00:00
|
|
|
ACPI_DECODE_16 : ACPI_DECODE_10;
|
|
|
|
|
io->minimum = p->start;
|
|
|
|
|
io->maximum = p->end;
|
|
|
|
|
io->alignment = 0; /* Correct? */
|
|
|
|
|
io->address_length = p->end - p->start + 1;
|
|
|
|
|
} else {
|
|
|
|
|
io->minimum = 0;
|
|
|
|
|
io->address_length = 0;
|
|
|
|
|
}
|
2008-04-28 22:34:07 +00:00
|
|
|
|
2008-08-19 22:53:47 +00: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-27 22:56:57 +00:00
|
|
|
io->minimum + io->address_length - 1, io->io_decode);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:07 +00:00
|
|
|
static void pnpacpi_encode_fixed_io(struct pnp_dev *dev,
|
|
|
|
|
struct acpi_resource *resource,
|
2007-07-26 17:41:20 +00:00
|
|
|
struct resource *p)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-04-28 22:34:00 +00: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-27 22:56:57 +00:00
|
|
|
if (pnp_resource_enabled(p)) {
|
|
|
|
|
fixed_io->address = p->start;
|
|
|
|
|
fixed_io->address_length = p->end - p->start + 1;
|
|
|
|
|
} else {
|
|
|
|
|
fixed_io->address = 0;
|
|
|
|
|
fixed_io->address_length = 0;
|
|
|
|
|
}
|
2008-04-28 22:34:07 +00:00
|
|
|
|
2008-08-19 22:53:47 +00: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-27 22:56:57 +00:00
|
|
|
fixed_io->address + fixed_io->address_length - 1);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:07 +00:00
|
|
|
static void pnpacpi_encode_mem24(struct pnp_dev *dev,
|
|
|
|
|
struct acpi_resource *resource,
|
2007-07-26 17:41:20 +00:00
|
|
|
struct resource *p)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-04-28 22:34:00 +00: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-27 22:56:57 +00: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;
|
|
|
|
|
memory24->address_length = p->end - p->start + 1;
|
|
|
|
|
} else {
|
|
|
|
|
memory24->minimum = 0;
|
|
|
|
|
memory24->address_length = 0;
|
|
|
|
|
}
|
|
|
|
|
|
2008-08-19 22:53:47 +00: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-27 22:56:57 +00:00
|
|
|
memory24->minimum,
|
|
|
|
|
memory24->minimum + memory24->address_length - 1,
|
2008-04-28 22:34:07 +00:00
|
|
|
memory24->write_protect);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:07 +00:00
|
|
|
static void pnpacpi_encode_mem32(struct pnp_dev *dev,
|
|
|
|
|
struct acpi_resource *resource,
|
2007-07-26 17:41:20 +00:00
|
|
|
struct resource *p)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-04-28 22:34:00 +00: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-27 22:56:57 +00: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;
|
|
|
|
|
memory32->address_length = p->end - p->start + 1;
|
|
|
|
|
} else {
|
|
|
|
|
memory32->minimum = 0;
|
|
|
|
|
memory32->alignment = 0;
|
|
|
|
|
}
|
2008-04-28 22:34:07 +00:00
|
|
|
|
2008-08-19 22:53:47 +00: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-27 22:56:57 +00:00
|
|
|
memory32->minimum,
|
|
|
|
|
memory32->minimum + memory32->address_length - 1,
|
2008-04-28 22:34:07 +00:00
|
|
|
memory32->write_protect);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:07 +00:00
|
|
|
static void pnpacpi_encode_fixed_mem32(struct pnp_dev *dev,
|
|
|
|
|
struct acpi_resource *resource,
|
2007-07-26 17:41:20 +00:00
|
|
|
struct resource *p)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-04-28 22:34:00 +00: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-27 22:56:57 +00: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;
|
|
|
|
|
fixed_memory32->address_length = p->end - p->start + 1;
|
|
|
|
|
} else {
|
|
|
|
|
fixed_memory32->address = 0;
|
|
|
|
|
fixed_memory32->address_length = 0;
|
|
|
|
|
}
|
2008-04-28 22:34:07 +00:00
|
|
|
|
2008-08-19 22:53:47 +00: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-27 22:56:57 +00:00
|
|
|
fixed_memory32->address,
|
|
|
|
|
fixed_memory32->address + fixed_memory32->address_length - 1,
|
2008-04-28 22:34:07 +00:00
|
|
|
fixed_memory32->write_protect);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
2008-04-28 22:34:06 +00:00
|
|
|
int pnpacpi_encode_resources(struct pnp_dev *dev, struct acpi_buffer *buffer)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
|
int i = 0;
|
|
|
|
|
/* pnpacpi_build_resource_template allocates extra mem */
|
2007-07-26 17:41:20 +00:00
|
|
|
int res_cnt = (buffer->length - 1) / sizeof(struct acpi_resource) - 1;
|
2007-08-15 16:32:10 +00:00
|
|
|
struct acpi_resource *resource = buffer->pointer;
|
2005-04-16 22:20:36 +00:00
|
|
|
int port = 0, irq = 0, dma = 0, mem = 0;
|
|
|
|
|
|
2008-08-19 22:53:47 +00:00
|
|
|
pnp_dbg(&dev->dev, "encode %d resources\n", res_cnt);
|
2005-04-16 22:20:36 +00:00
|
|
|
while (i < res_cnt) {
|
2007-07-26 17:41:20 +00: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-09-30 23:03:00 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_IRQ:
|
2008-04-28 22:34:07 +00:00
|
|
|
pnpacpi_encode_irq(dev, resource,
|
2008-04-28 22:34:24 +00:00
|
|
|
pnp_get_resource(dev, IORESOURCE_IRQ, irq));
|
2005-04-16 22:20:36 +00: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-09-30 23:03:00 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_DMA:
|
2008-04-28 22:34:07 +00:00
|
|
|
pnpacpi_encode_dma(dev, resource,
|
2008-04-28 22:34:24 +00:00
|
|
|
pnp_get_resource(dev, IORESOURCE_DMA, dma));
|
2006-03-28 22:04:00 +00:00
|
|
|
dma++;
|
2005-04-16 22:20:36 +00: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-09-30 23:03:00 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_IO:
|
2008-04-28 22:34:07 +00:00
|
|
|
pnpacpi_encode_io(dev, resource,
|
2008-04-28 22:34:24 +00:00
|
|
|
pnp_get_resource(dev, IORESOURCE_IO, port));
|
2006-03-28 22:04:00 +00:00
|
|
|
port++;
|
2005-04-16 22:20:36 +00: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-09-30 23:03:00 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_FIXED_IO:
|
2008-04-28 22:34:07 +00:00
|
|
|
pnpacpi_encode_fixed_io(dev, resource,
|
2008-04-28 22:34:24 +00:00
|
|
|
pnp_get_resource(dev, IORESOURCE_IO, port));
|
2006-03-28 22:04:00 +00:00
|
|
|
port++;
|
2005-04-16 22:20:36 +00: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-09-30 23:03:00 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_MEMORY24:
|
2008-04-28 22:34:07 +00:00
|
|
|
pnpacpi_encode_mem24(dev, resource,
|
2008-04-28 22:34:24 +00:00
|
|
|
pnp_get_resource(dev, IORESOURCE_MEM, mem));
|
2006-03-28 22:04:00 +00:00
|
|
|
mem++;
|
2005-04-16 22:20:36 +00: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-09-30 23:03:00 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_MEMORY32:
|
2008-04-28 22:34:07 +00:00
|
|
|
pnpacpi_encode_mem32(dev, resource,
|
2008-04-28 22:34:24 +00:00
|
|
|
pnp_get_resource(dev, IORESOURCE_MEM, mem));
|
2006-03-28 22:04:00 +00:00
|
|
|
mem++;
|
2005-04-16 22:20:36 +00: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-09-30 23:03:00 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
|
2008-04-28 22:34:07 +00:00
|
|
|
pnpacpi_encode_fixed_mem32(dev, resource,
|
2008-04-28 22:34:24 +00:00
|
|
|
pnp_get_resource(dev, IORESOURCE_MEM, mem));
|
2006-03-28 22:04:00 +00:00
|
|
|
mem++;
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
2006-01-20 06:11:37 +00:00
|
|
|
case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
|
2008-04-28 22:34:07 +00:00
|
|
|
pnpacpi_encode_ext_irq(dev, resource,
|
2008-04-28 22:34:24 +00:00
|
|
|
pnp_get_resource(dev, IORESOURCE_IRQ, irq));
|
2006-01-20 06:11:37 +00: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-26 17:41:20 +00:00
|
|
|
default: /* other type */
|
2008-04-28 22:34:12 +00:00
|
|
|
dev_warn(&dev->dev, "can't encode unknown resource "
|
|
|
|
|
"type %d\n", resource->type);
|
2005-04-16 22:20:36 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
2006-03-28 22:04:00 +00:00
|
|
|
resource++;
|
|
|
|
|
i++;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
