Re: Looking for a solution for CPM FSL SPI driver that swaps 16 bits words

[Christophe Leroy <christophe.leroy@xxxxxxxxxx>]

Le 07/03/2023 à 20:19, Mark Brown a écrit :
> On Tue, Mar 07, 2023 at 07:01:54PM +0000, Christophe Leroy wrote:
> 
>> What about a new flag at SPI device registration to tell the SPI
>> subsystem that this SPI device driver wants "raw/native 16 bits" data
>> being sent as-is, that my loader would set in order to tell the
>> controler "I have prepared the data, send it in your native 16 bits
>> order mode" ?
>> And for all devices not setting that flags, the controller would
>> fallback to 8 bits mode.
> 
> 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
> the controller cares about anything other than the memory and wire
> formats, if the controller correctly performs an 8 bit transfer when
> programmed for 16 bit words and it's faster then just do that.  That
> will work a lot better in general, drivers just sending a byte stream
> aren't going to (and shouldn't) ask for anything other than 8 bit words.
> 
> Word size configuration should only be used by a client driver when it
> wants things rewriting.

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.

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.

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

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.

Christophe