On Tue, Mar 07, 2023 at 07:43:42PM +0000, Christophe Leroy wrote: > Le 07/03/2023 à 20:19, Mark Brown a écrit : > > Oh, so the issue is that your controller is *not* swapping data? In > > that case if 16 bit transfers are more efficient and a buffer formatted > > for 8 bit transfers is already in the correct format then why not just > > tell the controller to use 16 bit words where possible? Nothing outside ... > No no, 8 bits mode is slower, or should I say it consumes more CPU for > the same clock rate, which means we have to use slower rate in order to > not saturate the RISC controller of the Communication Processor. Please read what I wrote above. > Well I not sure what you mean by swapping / not swapping data. Powerpc > 8xx is natively a big endian processor like all PPC32. But its > Communication Processor (CPM) is apparently fetching data as little > endian when told to perform transfer of 16 bits word on SPI. The default wire format for SPI is big endian (MSB first), as covered in spi.h: * In-memory data values are always in native CPU byte order, translated * from the wire byte order (big-endian except with SPI_LSB_FIRST). So * for example when bits_per_word is sixteen, buffers are 2N bytes long * (@len = 2N) and hold N sixteen bit words in CPU byte order. LSB_FIRST has only one in tree user other than spidev so I'd question how often it's correctly implemented. > So, my problem really is the GPIO MAX7301 driver which requests 16 bits > transfers, because then the SPI controller sends the 2 bytes in reversed > order. Do I understand correctly that from your point of view, that > driver shouldn't request a 16 bits tranfer ? It is done here, in the > max7301_probe() function, > https://elixir.bootlin.com/linux/v6.3-rc1/source/drivers/gpio/gpio-max7301.c#L50 It would certainly improve interoperability with controllers to request 8 bit, but so long as the driver is reading and writing data in the expected format it should work perfectly well. Looking at the lack of any endianness handling in the driver that doesn't seem to be the case though, it's just handling data in CPU endian format which isn't portable. > Because if I clamp the CPM SPI driver to 8 bits transfers, then I cannot > anymore perform 16 bits transfer for loading my FPGA, then it means I > must reduce data rate then loading the FPGA takes ages. Why?
Attachment:
signature.asc
Description: PGP signature
