[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <175f7e89-5b4b-dd54-20a3-d6a5a04c6e9c@pengutronix.de>
Date: Fri, 16 Aug 2019 10:37:46 +0200
From: Marc Kleine-Budde <mkl@...gutronix.de>
To: "FIXED-TERM Buecheler Konstantin (ETAS-SEC/ECT-Mu)"
<fixed-term.Konstantin.Buecheler@...rypt.com>,
Patrick Menschel <menschel.p@...teo.de>,
"linux-can@...r.kernel.org" <linux-can@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc: Dan Murphy <dmurphy@...com>
Subject: Re: AW: can: tcan4x5x: spi bits_per_word issue on Raspberry PI
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 |
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists