18 Jul, 2008

1 commit

  • With this commit all sparc64 header files are moved to asm-sparc.
    The remaining files (71 files) were too different to be trivially
    merged so divide them up in a _32.h and a _64.h file which
    are both included from the file with no bit size.

    The following script were used:
    cd include
    FILES=`wc -l asm-sparc64/*h | grep -v '^ 1' | cut -b 20-`

    for FILE in ${FILES}; do
    echo $FILE:
    BASE=`echo $FILE | cut -d '.' -f 1`
    FN32=${BASE}_32.h
    FN64=${BASE}_64.h
    GUARD=___ASM_SPARC_`echo $BASE | tr '-' '_' | tr [:lower:] [:upper:]`_H
    git mv asm-sparc/$FILE asm-sparc/$FN32
    git mv asm-sparc64/$FILE asm-sparc/$FN64
    echo git mv done
    printf "#ifndef %s\n" $GUARD > asm-sparc/$FILE
    printf "#define %s\n" $GUARD >> asm-sparc/$FILE
    printf "#if defined(__sparc__) && defined(__arch64__)\n" >> asm-sparc/$FILE
    printf "#include \n" $FN64 >> asm-sparc/$FILE
    printf "#else\n" >> asm-sparc/$FILE
    printf "#include \n" $FN32 >> asm-sparc/$FILE
    printf "#endif\n" >> asm-sparc/$FILE
    printf "#endif\n" >> asm-sparc/$FILE
    git add asm-sparc/$FILE
    echo new file done
    printf "#include \n" $FILE > asm-sparc64/$FILE
    git add asm-sparc64/$FILE
    echo sparc64 file done
    done

    The guard contains three '_' to avoid conflict with existing guards.
    In additing the two Kbuild files are emptied to avoid breaking
    headers_* targets.
    We will reintroduce the exported header files when the necessary
    kbuild changes are merged.

    Signed-off-by: Sam Ravnborg
    Signed-off-by: David S. Miller

    Sam Ravnborg
     

27 Dec, 2007

1 commit


30 Jul, 2007

1 commit

  • Fully unify all of the DMA ops so that subordinate bus types to
    the DMA operation providers (such as ebus, isa, of_device) can
    work transparently.

    Basically, we just make sure that for every system device we
    create, the dev->archdata 'iommu' and 'stc' fields are filled
    in.

    Then we have two platform variants of the DMA ops, one for SUN4U which
    actually programs the real hardware, and one for SUN4V which makes
    hypervisor calls.

    This also fixes the crashes in parport_pc on sparc64, reported by
    Meelis Roos.

    Signed-off-by: David S. Miller

    David S. Miller
     

12 Jul, 2007

2 commits

  • Based on replies to a respective query, remove the pci_dac_dma_...() APIs
    (except for pci_dac_dma_supported() on Alpha, where this function is used
    in non-DAC PCI DMA code).

    Signed-off-by: Jan Beulich
    Cc: Andi Kleen
    Cc: Jesse Barnes
    Cc: Christoph Hellwig
    Acked-by: David Miller
    Cc: Jeff Garzik
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Jan Beulich
     
  • I'm not sure if this is going to fly, weak symbols work on the compilers I'm
    using, but whether they work for all of the affected architectures I can't say.
    I've cc'ed as many arch maintainers/lists as I could find.

    But assuming they do, we can use a weak empty definition of
    pcibios_add_platform_entries() to avoid having an empty definition on every
    arch.

    Signed-off-by: Michael Ellerman
    Signed-off-by: Greg Kroah-Hartman

    Michael Ellerman
     

26 Apr, 2007

1 commit


03 Mar, 2007

1 commit


02 Dec, 2006

1 commit

  • The setting of the CACHE_LINE_SIZE register in sparc64's pci
    initialisation code isn't quite adequate as the device may have
    incompatible requirements. The generic code tests for this, so switch
    sparc64 over to using it.

    Since sparc64 has different L1 cache line size and PCI cache line size,
    it would need to override the generic code like i386 and ia64 do. We
    know what the cache line size is at compile time though, so introduce a
    new optional constant PCI_CACHE_LINE_BYTES.

    Signed-off-by: Matthew Wilcox
    Signed-off-by: David Miller
    Acked-by: Jeff Garzik
    Signed-off-by: Greg Kroah-Hartman

    Matthew Wilcox
     

23 May, 2006

1 commit

  • Using asm-generic/dma-mapping.h does not work because pushing
    the call down to pci_alloc_coherent() causes the gfp_t argument
    of dma_alloc_coherent() to be ignored.

    Fix this by implementing things directly, and adding a gfp_t
    argument we can use in the internal call down to the PCI DMA
    implementation of pci_alloc_coherent().

    This fixes massive memory corruption when using the sound driver
    layer, which passes things like __GFP_COMP down into these
    routines and (correctly) expects that to work.

    Signed-off-by: David S. Miller

    David S. Miller
     

20 Mar, 2006

1 commit


09 Sep, 2005

1 commit

  • 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

  • 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
     
  • 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

  • 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