Eric Lee / smarc-fsl-linux-kernel

20 Mar, 2006

1 commit

09 Sep, 2005

1 commit

  • 085ae41f6   [PATCH] Make sparc64 use setup-res.c ... Browse Code »

    There were three changes necessary in order to allow
    sparc64 to use setup-res.c:

    1) Sparc64 roots the PCI I/O and MEM address space using
    parent resources contained in the PCI controller structure.
    I'm actually surprised no other platforms do this, especially
    ones like Alpha and PPC{,64}. These resources get linked into the
    iomem/ioport tree when PCI controllers are probed.

    So the hierarchy looks like this:

    iomem --|
    PCI controller 1 MEM space --|
    device 1
    device 2
    etc.
    PCI controller 2 MEM space --|
    ...
    ioport --|
    PCI controller 1 IO space --|
    ...
    PCI controller 2 IO space --|
    ...

    You get the idea. The drivers/pci/setup-res.c code allocates
    using plain iomem_space and ioport_space as the root, so that
    wouldn't work with the above setup.

    So I added a pcibios_select_root() that is used to handle this.
    It uses the PCI controller struct's io_space and mem_space on
    sparc64, and io{port,mem}_resource on every other platform to
    keep current behavior.

    2) quirk_io_region() is buggy. It takes in raw BUS view addresses
    and tries to use them as a PCI resource.

    pci_claim_resource() expects the resource to be fully formed when
    it gets called. The sparc64 implementation would do the translation
    but that's absolutely wrong, because if the same resource gets
    released then re-claimed we'll adjust things twice.

    So I fixed up quirk_io_region() to do the proper pcibios_bus_to_resource()
    conversion before passing it on to pci_claim_resource().

    3) I was mistakedly __init'ing the function methods the PCI controller
    drivers provide on sparc64 to implement some parts of these
    routines. This was, of course, easy to fix.

    So we end up with the following, and that nasty SPARC64 makefile
    ifdef in drivers/pci/Makefile is finally zapped.

    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    David S. Miller
     

13 Jul, 2005

1 commit

12 Jul, 2005

1 commit

28 Jun, 2005

2 commits

  • bb4a61b6e   [PATCH] PCI: fix up errors after dma bursting patch and CONFIG_PCI=n ... Browse Code »

    With CONFIG_PCI=n:

    In file included from include/linux/pci.h:917,
    from lib/iomap.c:6:
    include/asm/pci.h:104: warning: `enum pci_dma_burst_strategy' declared inside parameter list
    include/asm/pci.h:104: warning: its scope is only this definition or declaration, which is probably not what you want.
    include/asm/pci.h: In function `pci_dma_burst_advice':
    include/asm/pci.h:106: dereferencing pointer to incomplete type
    include/asm/pci.h:106: `PCI_DMA_BURST_INFINITY' undeclared (first use in this function)
    include/asm/pci.h:106: (Each undeclared identifier is reported only once
    include/asm/pci.h:106: for each function it appears in.)
    make[1]: *** [lib/iomap.o] Error 1

    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Andrew Morton
     
  • e24c2d963   [PATCH] PCI: DMA bursting advice ... Browse Code »

    After seeing, at best, "guesses" as to the following kind
    of information in several drivers, I decided that we really
    need a way for platforms to specifically give advice in this
    area for what works best with their PCI controller implementation.

    Basically, this new interface gives DMA bursting advice on
    PCI. There are three forms of the advice:

    1) Burst as much as possible, it is not necessary to end bursts
    on some particular boundary for best performance.

    2) Burst on some byte count multiple. A DMA burst to some multiple of
    number of bytes may be done, but it is important to end the burst
    on an exact multiple for best performance.

    The best example of this I am aware of are the PPC64 PCI
    controllers, where if you end a burst mid-cacheline then
    chip has to refetch the data and the IOMMU translations
    which hurts performance a lot.

    3) Burst on a single byte count multiple. Bursts shall end
    exactly on the next multiple boundary for best performance.

    Sparc64 and Alpha's PCI controllers operate this way. They
    disconnect any device which tries to burst across a cacheline
    boundary.

    Actually, newer sparc64 PCI controllers do not have this behavior.
    That is why the "pdev" is passed into the interface, so I can
    add code later to check which PCI controller the system is using
    and give advice accordingly.

    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    David S. Miller
     

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