From: "David S. Miller" <davem@davemloft.net>
To: linux-kernel@vger.kernel.org
Cc: perex@suse.de
Subject: ALSA update broke Sparc
Date: Fri, 27 Aug 2004 18:36:46 -0700 [thread overview]
Message-ID: <20040827183646.1da2befc.davem@davemloft.net> (raw)
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.
next reply other threads:[~2004-08-28 1:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-28 1:36 David S. Miller [this message]
2004-08-28 7:45 ` ALSA update broke Sparc Russell King
2004-08-30 10:26 ` Takashi Iwai
2004-08-31 19:07 ` Takashi Iwai
2004-08-31 20:56 ` David S. Miller
2004-09-01 8:12 ` Takashi Iwai
2004-08-31 20:58 ` David S. Miller
2004-09-01 8:14 ` Takashi Iwai
2004-08-31 22:20 ` Andrew Morton
2004-09-01 8:16 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040827183646.1da2befc.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=perex@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.