[alsa-devel] [PATCH 4/4] ASoC: fsl: make fsl_ssi driver compilable on ARM/IMX
timur at freescale.com
Sat Feb 25 00:05:16 CET 2012
Russell King - ARM Linux wrote:
> Ho hum. So, what that's saying to me is that even implementing in_32be()
> on ARM results in rubbish because it wouldn't be big endian there.
Well, the "be" in in_be32() means to assume that 32-bit integer is stored
in big-endian format, and to convert it to native format during the read.
An ARM implementation of in_be32() would include byte-swapping.
> So are we heading towards driver specific sets of IO accessors? :-( It
> sounds like that's what it needs because of these different endian-ness
I'm surprised that ioread32() on PowerPC always does a little-endian read,
but I'm guessing that was done for compatibility. I don't know what to do
> And lets not forget that we're talking just about this - there's also
> the issue of on-SoC devices on ARM now appearing behind PCI buses on
> x86, which would make those appear as LE. I bet if any of those
> appearing on PPC would appear in BE mode. So, 'native endian' doesn't
> work either.
I think PCI is a special-case on most PowerPC parts, in that the registers
are still little-endian. But I don't know how pervasive that is. In
fact, I think on some Freescale PowerPC SOCs, the PCI registers are
little-endian, and other others they're big-endian. You can see that in
> So, I'm getting the feeling that something as simple as IO accessors are
> just a huge mountain of crap waiting to bite.
Very few devices are shared between Freescale's PowerPC and ARM SOCs, so
the impact is only a few drivers. That's why it might be okay (for now)
to have "dual" I/O accessors in specific drivers.
Linux kernel developer at Freescale
More information about the Alsa-devel