ALSA update broke Sparc

From: David S. Miller (davem_at_davemloft.net)
Date: 08/28/04

  • Next message: Andrew Morton: "Re: page fault scalability patch final : i386 tested, x86_64 support added"
    Date:	Fri, 27 Aug 2004 18:36:46 -0700
    To: linux-kernel@vger.kernel.org
    
    

    Each platform uses a different number of arguments for
    io_remap_page_range(), so you can't just blindly call it
    from generic code.

    However, sound/core/pcm_native.c is doing exactly that.

    The reason each platform takes a different number of
    args is that the "unsigned long" base address argument
    is only 32-bits on 32-bit platforms yet on some of
    such platforms I/O and physical memory addresses
    are larger than 32-bits.

    Sparc and Sparc64 use a "space" argument to provide this
    upper 32-bits of information.

    Also, what this PCM mmap'ing code is trying to do
    is take I/O addresses and remap them into the process
    address space. pci_resource_start() values are not necessarily
    suitable for passing around as physical addresses. These
    things are well defined when used with ioremap() but
    that is it. I don't know if we've defined it such that
    passing these into io_remap_page_range() can be expected
    to work.

    In fact, because of the sparc 32-bit issue, I know it won't
    work. You'll need to have the full resource structure
    available, as that's where we hide the upper 32-bits of
    the physical address on sparc32.

    This is really non-portable, what the PCM code is doing.
    I would suggest, for the time being, to pass resources
    around and then have an arch-defined macro which takes
    the resource pointer and makes the appropriate io_remap_page_range()
    call.

    Can I make a small formal request of the ALSA folks? Can you
    at least setup a cross-compiler to make sure your ALSA merges
    don't explode on sparc64? As it stands, 1 out of every 2 ALSA
    merges breaks the build on that platform.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Andrew Morton: "Re: page fault scalability patch final : i386 tested, x86_64 support added"

    Relevant Pages

    • Re: Silly URL...
      ... Note that while an URL can refer to a local File.. ... - A File cannot refer to a resource on an http site, or ftp, or.. ... But how many times have you seen code similar to this? ... ...use of File's can easily be made 'platform specific', ...
      (comp.lang.java.programmer)
    • Re: The problems in comp.lang.c
      ... and redirect the poster to an appropriate resource. ... platform specific solutions for one of the most commonly available ... because of topicality concerns. ...
      (comp.lang.c)
    • Re: PCI bus enumeration differences between Geode and ARM
      ... hard codes values to some of the PCI devices. ... might break the whole platform so I decided to reseach the problem a little ... device emunration and resource dispatch is done by the ...
      (microsoft.public.windowsce.platbuilder)
    • Re: Separate resource dll for PPC and Smartphone
      ... resource dll for each language with a separate rc file for the platform ... in the given resource dll project. ... automatically depending on the current configuration (i.e. Smartphone ...
      (microsoft.public.windowsce.embedded.vc)
    • Re: [PATCH] Custom IORESOURCE Class
      ... >> useful for most platform data. ... I also need to pass a fractional divider clk id. ... resource table seemed appropriate because the base addresses and the ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)