can: tcan4x5x: spi bits_per_word issue on Raspberry PI

can: tcan4x5x: spi bits_per_word issue on Raspberry PI

[FIXED-TERM Buecheler Konstantin (ETAS-SEC/ECT-Mu)]

> Hi all,
> 
> I am trying to use a tcan4550 together with a Raspberry PI 3 B. I am using the
> tcan4x5x driver from net-next.
> I always get the following error during startup.
> 	tcan4x5x spi0.0: Probe failed, err=-22
> 	tcan4x5x: probe of spi0.0 failed with error -22
> 
> I realized that this happens because the Raspberry PI does only support 8/9 bit
> words. https://elinux.org/index.php?title=RPi_SPI#Supported_bits_per_word
> In the driver it is set to 32.
> 	spi->bits_per_word = 32;
> 
> Setting this to 8 does not help of course since the tcan chip expects a multiple of
> 32 per spi transaction.
> I don't know if this is a Raspberry Pi specific problem or if there are more devices
> with this hardware limitation.
> 
> Does anyone have a workaround for that?

It seems to be enough to just change the bits_per_word value to 8

> 
> If this a common issue it might be a good idea to patch the driver. I will check if I
> can find proper a way to do so.
> 
> Regards,
> Konstantin

Now I have another really confusing problem. Anything I write to SPI is written little endian. The tcan chip expects big endian. 
Anything I read from SPI is treated as little endian but is big endian. Does anyone know why this happens? 
Is there a flag or something I can set for the SPI device/wire to fix this?

Regards,
Konstantin

Re: can: tcan4x5x: spi bits_per_word issue on Raspberry PI

[Marc Kleine-Budde]

[-- Attachment #1.1: Type: text/plain, Size: 1871 bytes --]

On 8/14/19 5:01 PM, FIXED-TERM Buecheler Konstantin (ETAS-SEC/ECT-Mu) wrote:
>> Hi all,
>>
>> I am trying to use a tcan4550 together with a Raspberry PI 3 B. I am using the
>> tcan4x5x driver from net-next.
>> I always get the following error during startup.
>> 	tcan4x5x spi0.0: Probe failed, err=-22
>> 	tcan4x5x: probe of spi0.0 failed with error -22
>>
>> I realized that this happens because the Raspberry PI does only support 8/9 bit
>> words. https://elinux.org/index.php?title=RPi_SPI#Supported_bits_per_word
>> In the driver it is set to 32.
>> 	spi->bits_per_word = 32;
>>
>> Setting this to 8 does not help of course since the tcan chip expects a multiple of
>> 32 per spi transaction.
>> I don't know if this is a Raspberry Pi specific problem or if there are more devices
>> with this hardware limitation.
>>
>> Does anyone have a workaround for that?
> 
> It seems to be enough to just change the bits_per_word value to 8
> 
>>
>> If this a common issue it might be a good idea to patch the driver. I will check if I
>> can find proper a way to do so.
>>
>> Regards,
>> Konstantin
> 
> Now I have another really confusing problem. Anything I write to SPI is written little endian. The tcan chip expects big endian. 
> Anything I read from SPI is treated as little endian but is big endian. Does anyone know why this happens? 
> Is there a flag or something I can set for the SPI device/wire to fix this?

Have you changed the bits_per_word to 8? Then you read just a stream of
bytes. If you tread them as an u32 they are in host order.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

AW: can: tcan4x5x: spi bits_per_word issue on Raspberry PI

[FIXED-TERM Buecheler Konstantin (ETAS-SEC/ECT-Mu)]

> >> Now I have another really confusing problem. Anything I write to SPI is written little endian. The tcan chip expects big endian.
> >> Anything I read from SPI is treated as little endian but is big endian. Does anyone know why this happens?
> >> Is there a flag or something I can set for the SPI device/wire to fix this?
> >
> > Have you changed the bits_per_word to 8? Then you read just a stream
> > of bytes. If you tread them as an u32 they are in host order.
> >

@Marc
Yes, I changed bits_per_word to 8. Since the PI does not support any values apart from 
8 and 9 this seems to be the only way.

> > Marc
> >
> 
> 
> Hi,
> 
> from my experience with SPIDEV on RPI, the driver uses a char array for I/O.
> As the RPI code is build little endian, logically little endian comes out of SPI. You
> basically have to invert the bit and byte order by hand for a big endian slave.
> 

@Patrick, Marc
You both are right. This seems to be the problem. The SPI driver uses char arrays
and the tcan driver treats them as u32. 

I will try to change the byte order by hand to get it running for my project. But in the long 
run, this does not seem to be a proper solution... 

Regards, 
Konstantin 


> Clock Phase and Clock Polarity are also an issue on the RPI as at least SPIDEV
> kindly overlooks any options set previously.
> I had my share of this while writing a test app for a MAX31855 IC and ended up
> casting a little endian array to a big endian structure.
> 
> Regards,
> Patrick

Re: AW: can: tcan4x5x: spi bits_per_word issue on Raspberry PI

[Marc Kleine-Budde]

[-- Attachment #1.1: Type: text/plain, Size: 1583 bytes --]

On 8/16/19 10:26 AM, FIXED-TERM Buecheler Konstantin (ETAS-SEC/ECT-Mu)
wrote:
>>> Have you changed the bits_per_word to 8? Then you read just a stream
>>> of bytes. If you tread them as an u32 they are in host order.
> 
> @Marc
> Yes, I changed bits_per_word to 8. Since the PI does not support any values apart from 
> 8 and 9 this seems to be the only way.

ok

>> from my experience with SPIDEV on RPI, the driver uses a char array for I/O.
>> As the RPI code is build little endian, logically little endian comes out of SPI. You
>> basically have to invert the bit and byte order by hand for a big endian slave.
> 
> @Patrick, Marc
> You both are right. This seems to be the problem. The SPI driver uses char arrays
> and the tcan driver treats them as u32. 

No, the tcan configures the spi device or rather the host driver that
the word len should be 32 bit. If you change the value to 8 you break
the assumptions in the driver.

> I will try to change the byte order by hand to get it running for my project. But in the long 
> run, this does not seem to be a proper solution... 

Indeed, that's the wrong approach. I don't have any HW here to test, but
I'll prepare a patch. BTW: the driver is broken in several ways, when it
comes to the regmap configuration.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]