Eric Lee / smarc-fsl-linux-kernel

22 Apr, 2009

1 commit

  • 77e38a554   frv: insert PCI root bus resources for the MB93090 devel motherboard ... Browse Code »

    Insert PCI root bus resources for the FRV-based MB93090 development kit
    motherboard. This is required because the CPU's window onto the PCI bus
    address space is considerably smaller than the CPU's full address space
    and non-PCI devices lie outside of the PCI window that we might want to
    access.

    Without this patch, the PCI root bus uses the platform-level bus
    resources, and these are then confined to the PCI window, thus making
    platform_device_add() reject devices outside of this window.

    Signed-off-by: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

17 Oct, 2008

2 commits

  • c9af956cf   FRV: Provide dma_map_page() for NOMMU and fix comments ... Browse Code »

    Provide dma_map_page() for the NOMMU-mode FRV arch.

    Also do some fixing on the comments attached to the various DMA functions for
    both MMU and NOMMU mode FRV code.

    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds

    David Howells
     
  • 9bd8f9c63   frv: use generic pci_enable_resources() ... Browse Code »

    Use the generic pci_enable_resources() instead of the arch-specific code.

    Unlike this arch-specific code, the generic version:
    - checks PCI_NUM_RESOURCES (11), not 6, resources
    - skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
    - skips ROM resources unless IORESOURCE_ROM_ENABLE is set
    - checks for resource collisions with "!r->parent"

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

    Bjorn Helgaas
     

28 Jun, 2008

1 commit

  • 0aea53132   PCI: remove unused arch pcibios_update_resource() functions ... Browse Code »

    Russell King did the following back in 2003:

    [PCI] pci-9: Kill per-architecture pcibios_update_resource()

    Kill pcibios_update_resource(), replacing it with pci_update_resource().
    pci_update_resource() uses pcibios_resource_to_bus() to convert a
    resource to a device BAR - the transformation should be exactly the
    same as the transformation used for the PCI bridges.

    pci_update_resource "knows" about 64-bit BARs, but doesn't attempt to
    set the high 32-bits to anything non-zero - currently no architecture
    attempts to do something different. If anyone cares, please fix; I'm
    going to reflect current behaviour for the time being.

    Ivan pointed out the following architectures need to examine their
    pcibios_update_resource() implementation - they should make sure that
    this new implementation does the right thing. #warning's have been
    added where appropriate.

    ia64
    mips
    mips64

    This cset also includes a fix for the problem reported by AKPM where
    64-bit arch compilers complain about the resource mask being placed
    in a u32.

    This patch removes the unused pcibios_update_resource() functions the
    kernel gained since, from FRV, m68k, mips & sh architectures.

    Signed-off-by: Adrian Bunk
    Acked-by: David Howells
    Acked-by: Greg Ungerer
    Acked-by: Paul Mundt
    Acked-by: Ralf Baechle
    Signed-off-by: Jesse Barnes

    Adrian Bunk
     

07 Jun, 2008

1 commit

29 Apr, 2008

1 commit

  • b70d3a2c5   iomap: fix 64 bits resources on 32 bits ... Browse Code »

    Almost all implementations of pci_iomap() in the kernel, including the generic
    lib/iomap.c one, copies the content of a struct resource into unsigned long's
    which will break on 32 bits platforms with 64 bits resources.

    This fixes all definitions of pci_iomap() to use resource_size_t. I also
    "fixed" the 64bits arch for consistency.

    Signed-off-by: Benjamin Herrenschmidt
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Benjamin Herrenschmidt
     

21 Apr, 2008

2 commits

  • 6355f3d1c   PCI: remove pcibios_fixup_ghosts() ... Browse Code »

    This function was obviously never being used since early 2.5 days as any
    device that it would try to remove would never really be removed from
    the system due to the PCI device list being held in the driver core, not
    the general list of PCI devices.

    As we have not had a single report of a problem here in 4 years, I think
    it's safe to remove now.

    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     
  • 1ba6ab11d   PCI: remove initial bios sort of PCI devices on x86 ... Browse Code »

    We currently keep 2 lists of PCI devices in the system, one in the
    driver core, and one all on its own. This second list is sorted at boot
    time, in "BIOS" order, to try to remain compatible with older kernels
    (2.2 and earlier days). There was also a "nosort" option to turn this
    sorting off, to remain compatible with even older kernel versions, but
    that just ends up being what we have been doing from 2.5 days...

    Unfortunately, the second list of devices is not really ever used to
    determine the probing order of PCI devices or drivers[1]. That is done
    using the driver core list instead. This change happened back in the
    early 2.5 days.

    Relying on BIOS ording for the binding of drivers to specific device
    names is problematic for many reasons, and userspace tools like udev
    exist to properly name devices in a persistant manner if that is needed,
    no reliance on the BIOS is needed.

    Matt Domsch and others at Dell noticed this back in 2006, and added a
    boot option to sort the PCI device lists (both of them) in a
    breadth-first manner to help remain compatible with the 2.4 order, if
    needed for any reason. This option is not going away, as some systems
    rely on them.

    This patch removes the sorting of the internal PCI device list in "BIOS"
    mode, as it's not needed at all anymore, and hasn't for many years.
    I've also removed the PCI flags for this from some other arches that for
    some reason defined them, but never used them.

    This should not change the ordering of any drivers or device probing.

    [1] The old-style pci_get_device and pci_find_device() still used this
    sorting order, but there are very few drivers that use these functions,
    as they are deprecated for use in this manner. If for some reason, a
    driver rely on the order and uses these functions, the breadth-first
    boot option will resolve any problem.

    Cc: Matt Domsch
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

28 Oct, 2007

1 commit

02 Aug, 2007

1 commit

29 Mar, 2007

1 commit

  • bba6f6fc6   [PATCH] MSI-X: fix resume crash ... Browse Code »

    So I think the right solution is to simply make pci_enable_device just
    flip enable bits and move the rest of the work someplace else.

    However a thorough cleanup is a little extreme for this point in the
    release cycle, so I think a quick hack that makes the code not stomp the
    irq when msi irq's are enabled should be the first fix. Then we can
    later make the code not change the irqs at all.

    Signed-off-by: Eric W. Biederman
    Signed-off-by: Ingo Molnar
    Signed-off-by: Linus Torvalds

    Eric W. Biederman
     

26 Sep, 2006

1 commit

11 Jul, 2006

1 commit

  • 9dec17eb5   [PATCH] FRV: Fix FRV arch compile errors ... Browse Code »

    Fix some FRV arch compile errors, including:

    (*) Marking nr_kernel_pages as __meminitdata so that references to it end up
    being properly calculated rather than being assumed to be in the small
    data section (and thus calculated wrt the GP register). Not doing this
    causes the linker to emit errors as the offset is too big to fit into the
    load instruction.

    (*) Move pm_power_off into an unconditionally compiled .c file as it's now
    unconditionally accessed.

    (*) Declare frv_change_cmode() in a header file rather than in a .c file, and
    declare it asmlinkage.

    Signed-off-by: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

01 Jul, 2006

1 commit

28 Jun, 2006

1 commit

23 Jun, 2006

1 commit

10 Jan, 2006

2 commits

09 Jan, 2006

2 commits

29 Nov, 2005

1 commit

  • 8080f2312   [PATCH] FRV: Make the FRV arch work again ... Browse Code »

    The attached patch implements a bunch of small changes to the FRV arch to
    make it work again.

    It deals with the following problems:

    (1) SEM_DEBUG should be SEMAPHORE_DEBUG.

    (2) The argument list to pcibios_penalize_isa_irq() has changed.

    (3) CONFIG_HIGHMEM can't be used directly in #if as it may not be defined.

    (4) page->private is no longer directly accessible.

    (5) linux/hardirq.h assumes asm/hardirq.h will include linux/irq.h

    (6) The IDE MMIO access functions are given pointers, not integers, and so
    get type casting errors.

    (7) __pa() is passed an explicit u64 type in drivers/char/mem.c, but that
    can't be cast directly to a pointer on a 32-bit platform.

    (8) SEMAPHORE_DEBUG should not be contingent on WAITQUEUE_DEBUG as that no
    longer exists.

    (9) PREEMPT_ACTIVE is too low a value.

    Signed-off-by: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

28 Oct, 2005

1 commit

12 Jul, 2005

1 commit

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds