All of lore.kernel.org
 help / color / mirror / Atom feed
From: "FIXED-TERM Buecheler Konstantin (ETAS-SEC/ECT-Mu)" <fixed-term.Konstantin.Buecheler@escrypt.com>
To: Patrick Menschel <menschel.p@posteo.de>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: Dan Murphy <dmurphy@ti.com>
Subject: AW: can: tcan4x5x: spi bits_per_word issue on Raspberry PI
Date: Fri, 16 Aug 2019 08:26:16 +0000	[thread overview]
Message-ID: <47108d803086402c83d1073f3e3a62bb@escrypt.com> (raw)
In-Reply-To: <e6577cc2-89fc-9428-b73e-47f41eff2949@posteo.de>

> >> 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


  parent reply	other threads:[~2019-08-16  8:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-14 15:01 can: tcan4x5x: spi bits_per_word issue on Raspberry PI FIXED-TERM Buecheler Konstantin (ETAS-SEC/ECT-Mu)
2019-08-15  8:34 ` Marc Kleine-Budde
     [not found]   ` <e6577cc2-89fc-9428-b73e-47f41eff2949@posteo.de>
2019-08-16  8:26     ` FIXED-TERM Buecheler Konstantin (ETAS-SEC/ECT-Mu) [this message]
2019-08-16  8:37       ` AW: " Marc Kleine-Budde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47108d803086402c83d1073f3e3a62bb@escrypt.com \
    --to=fixed-term.konstantin.buecheler@escrypt.com \
    --cc=dmurphy@ti.com \
    --cc=linux-can@vger.kernel.org \
    --cc=menschel.p@posteo.de \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.