Re: ALSA update broke Sparc

[Takashi Iwai <tiwai@suse.de>]

At Fri, 27 Aug 2004 18:36:46 -0700,
David S. Miller wrote:
> 
> 
> 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.

Argh, sorry about that.  My ignorance.


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

I'll fix this anyway - but, doesn't it make sense to change the
argument type to more reasonable one for 64bit architectures (as wli 
posted)?


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

Calling io_remap_page_range() in the PCM layer is provided only for
certain PCI drivers such as nm256, so disabling this isn't a problem
in general.  Indeed, this feature should be disabled for architectures
like sparc.

Or even better, as Russell King suggested before, we can hide
arch-specific things by creating a generic mmap method for struct
device.  I see that sparc already has pci_mmap_page_range() for a
similar purpose.


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

I'll try to set up.


--
Takashi Iwai <tiwai@suse.de>		ALSA Developer - www.alsa-project.org