Eric Lee / smarc-fsl-linux-kernel

23 Oct, 2008

1 commit

11 Oct, 2008

1 commit

  • 2f53432c2   PNP: convert to using pnp_dbg() ... Browse Code »

    pnp_dbg() is equivalent to dev_dbg() except that we can turn it
    on at boot-time with the "pnp.debug" kernel parameter, so we don't
    have to build a new kernel image.

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Andi Kleen
    Signed-off-by: Len Brown

    Bjorn Helgaas
     

23 Sep, 2008

1 commit

17 Jul, 2008

8 commits

  • 1f32ca31e   PNP: convert resource options to single linked list ... Browse Code »

    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
    Signed-off-by: Andi Kleen
    Acked-by: Rene Herman
    Signed-off-by: Len Brown

    Bjorn Helgaas
     
  • bbe413b4f   ISAPNP: handle independent options following dependent ones ... Browse Code »

    The ISAPNP spec recommends that independent options precede
    dependent ones, but this is not actually required. The current
    ISAPNP code incorrectly puts such trailing independent options
    at the end of the last dependent option list.

    This patch fixes that bug by resetting the current option list
    to the independent list when we see an "End Dependent Functions"
    tag. PNPBIOS and PNPACPI handle this the same way.

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Andi Kleen
    Acked-by: Rene Herman
    Signed-off-by: Len Brown

    Bjorn Helgaas
     
  • e2a1a6f1c   PNP: remove extra 0x100 bit from option priority ... Browse Code »

    When building resource options, ISAPNP and PNPBIOS set the priority
    to something like "0x100 | PNP_RES_PRIORITY_ACCEPTABLE", but we
    immediately mask off the 0x100 again in pnp_build_option(), so that
    bit looks superfluous.

    Thanks to Rene Herman for pointing this out.

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Andi Kleen
    Acked-by: Rene Herman
    Signed-off-by: Len Brown

    Bjorn Helgaas
     
  • c227536b4   PNP: centralize resource option allocations ... Browse Code »

    This patch moves all the option allocations (pnp_mem, pnp_port, etc)
    into the pnp_register_{mem,port,irq,dma}_resource() functions. This
    will make it easier to rework the option data structures.

    The non-trivial part of this patch is the IRQ handling. The backends
    have to allocate a local pnp_irq_mask_t bitmap, populate it, and pass
    a pointer to pnp_register_irq_resource().

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Andi Kleen
    Acked-by: Rene Herman
    Signed-off-by: Len Brown

    Bjorn Helgaas
     
  • 7aefff518   PNP: introduce pnp_irq_mask_t typedef ... Browse Code »

    This adds a typedef for the IRQ bitmap, which should cause
    no functional change, but will make it easier to pass a
    pointer to a bitmap to pnp_register_irq_resource().

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Andi Kleen
    Acked-by: Rene Herman
    Signed-off-by: Len Brown

    Bjorn Helgaas
     
  • 08c9f262f   PNP: define PNP-specific IORESOURCE_IO_* flags alongside IRQ, DMA, MEM ... Browse Code »

    PNP previously defined PNP_PORT_FLAG_16BITADDR and PNP_PORT_FLAG_FIXED
    in a private header file, but put those flags in struct resource.flags
    fields. Better to make them IORESOURCE_IO_* flags like the existing
    IRQ, DMA, and MEM flags.

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Andi Kleen
    Acked-by: Rene Herman
    Signed-off-by: Len Brown

    Bjorn Helgaas
     
  • aee3ad815   PNP: replace pnp_resource_table with dynamically allocated resources ... Browse Code »

    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
    Signed-off-by: Len Brown
    Signed-off-by: Andi Kleen

    Bjorn Helgaas
     
  • 87e4acf3e   PNP: remove pnp_resource.index ... Browse Code »

    We used pnp_resource.index to keep track of which ISAPNP configuration
    register a resource should be written to. We needed this only to
    handle the case where a register is disabled but a subsequent register
    in the same set is enabled.

    Rather than explicitly maintaining the pnp_resource.index, this patch
    adds a resource every time we read an ISAPNP configuration register
    and marks the resource as IORESOURCE_DISABLED when appropriate. This
    makes the position in the pnp_resource_table always correspond to the
    config register index.

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Len Brown
    Signed-off-by: Andi Kleen

    Bjorn Helgaas
     

29 Apr, 2008

22 commits

23 Mar, 2008

1 commit

  • 245073f0b   ISAPNP: fix limits of logical device register set ... Browse Code »

    PNP_MAX_MEM and PNP_MAX_PORT are mainly used to size tables of PNP
    device resources. In 2.6.24, we increased their values to accomodate
    ACPI devices that have many resources:

    2.6.23 2.6.24
    ------ ------
    PNP_MAX_MEM 4 12
    PNP_MAX_PORT 8 40

    However, ISAPNP also used these constants as the size of parts of the
    logical device register set. This register set is fixed by hardware,
    so increasing the constants meant that we were reading and writing
    unintended parts of the register set.

    This patch changes ISAPNP to use the correct register set sizes (the
    same values we used prior to 2.6.24).

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Linus Torvalds

    Bjorn Helgaas
     

16 Oct, 2007

1 commit

24 Aug, 2007

3 commits

27 Jul, 2007

2 commits

  • 07d4e9af1   PNP: fix up after Lindent ... Browse Code »

    These are manual fixups after running Lindent. No functional change.

    Signed-off-by: Bjorn Helgaas
    Cc: Len Brown
    Cc: Adam Belay
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bjorn Helgaas
     
  • 9dd78466c   PNP: Lindent all source files ... Browse Code »

    Run Lindent on all PNP source files.

    Produced by:

    $ quilt new pnp-lindent
    $ find drivers/pnp -name \*.[ch] | xargs quilt add
    $ quilt add include/linux/{pnp.h,pnpbios.h}
    $ scripts/Lindent drivers/pnp/*.c drivers/pnp/*/*.c include/linux/pnp*.h
    $ quilt refresh --sort

    Signed-off-by: Bjorn Helgaas
    Cc: Len Brown
    Cc: Adam Belay
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bjorn Helgaas