[alsa-devel] [PATCH 4/4] ASoC: fsl: make fsl_ssi driver compilable on ARM/IMX

[Timur Tabi]

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

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

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

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

-- 
Timur Tabi
Linux kernel developer at Freescale