Hi Arnd,
On Thu, Nov 19, 2020 at 5:22 PM Arnd Bergmann arnd@kernel.org wrote:
On Thu, Nov 19, 2020 at 5:13 PM Geert Uytterhoeven geert@linux-m68k.org wrote:
On Thu, Nov 19, 2020 at 4:54 PM Arnd Bergmann arnd@kernel.org wrote:
On Thu, Nov 19, 2020 at 1:53 PM Geert Uytterhoeven geert+renesas@glider.be wrote:
I'm also not sure whether changing this breaks big-endian SuperH, which defines the accessors differently from Arm and most other architectures.
On SH, this driver is only used on SH7724 systems. Compiling an ecovec24_defconfig kernel with CONFIG_CPU_BIG_ENDIAN=y shows that the same code (native 32-bit access) is generated for big-endian as for little-endian, which means that it indeed must be broken for one of them. But this is not changed by my patch.
Not necessarily: I think superh is more like the old 'BE32' variant of Arm big-endian, in that on-chip registers are accessed in CPU-endian byte order, while access to external RAM is byte-swapped.
That's indeed quite likely: according to the SH7724 docs, the endianness of "the system" is configured by an external pin at power-on reset time, and cannot be changed dynamically. Hence testing this would require a big-endian boot loader, too.
Maybe better just mark the driver as 'depends on SH || !CPU_BIG_ENDIAN' as it is clearly broken on big-endian Arm.
"depends on !CPU_BIG_ENDIAN"?
I think I'd just leave it as it is. Unless someone wants to try out this
OK.
board in both big-endian and little-endian configurations and also listen to the audio output, it's impossible to know whether it is actually broken. sound/soc/sh/dma-sh7760.c does have a comment from 2007 saying "// FIXME: little-endian only for now".
SH7760 does not use the FSI driver. A few SH defconfig files have CONFIG_CPU_BIG_ENDIAN=y, but the later SH4A parts all seem to be used in little-endian mode.
Gr{oetje,eeting}s,
Geert