SPI transmission with 9 bits per word is wrong with BSP 3.0b2 on iMX6ULL

Technical Support
, , , ,
1

We are using a customized BSP based on 3.02b for an iMX6ULL together with an Aster carrier board.
A display with an ILI9341 controller in 9-bit mode is connected to the SPI. The device tree and the kernel were modified to use a framebuffer for accessing the display (small TFT support in kernel together with staged drivers).

During tests we noticed that the 9 bits per word transmission on SPI isn’t working correct if multible words will be sent. Instead of 9 bits always 16 bits will be sent for multible word transmission.

For further analyses and to rule out problems with our customized BSP we flashed the Toradex Console image 3.0b2 and made some tests with spidev_test.

Toradex Console image 3.0b2

We see the same bahavior as we noticed with our custom BSP:

Single 9-bit word transmission is okay:

./spidev_test -D /dev/spidev0.0 -D -s 1000000 -b 9 -p \\x31\\x01

[upload|pFLVF2ypGN9Dkqi2rlyAnipzeWc=]

Multible 9-bit word transmission is wrong:

./spidev_test -D /dev/spidev0.0 -D -s 1000000 -b 8 -p 10203040 -> data sent = 10203040 (Tx buffer: 31 30 32 30 33 30 34 30)

Encode with 9 bits per word:
[upload|8TL9RppSQVybBSydwts57XK8/6U=]

Encoded with 16 bits per word:
[upload|UEQZvuscp/nsUaPO1YzR/V9j5kQ=]

=> 9 bits per word is set but 16 bits per word will be used and only the first 8 bits will be taken.

After that we downgraded the module to Toradex console image 2.8b6:

Toradex console image 2.8b6

Single 9-bit word transmission is okay.

Multible 9-bit word transmission is also okay:

./spidev_test -D /dev/spidev0.0 -D -s 1000000 -b 8 -p 10203040 -> data sent = 10203040 (Tx buffer: 31 30 32 30 33 30 34 30)

Encode with 9 bits per word:
[upload|39huHJqLkhjvgSFA787OWQBXM+c=]

Findings:

  1. Single word SPI transmission with 9 bit per word work with BSB 2.8b6 and BSP 3.0b2.
  2. Multible word transmission with 9 bits per word work with BSP 2.8b6 but not with 3.0b2.

Is there a SPI bug in 3.0b2? What can we do to solve the problem?

2

Dear @lic,

Thanks for contacting support with detailed inputs. I am looking into this and would like to get back to you soon.

3

Dear @lic,

When I do 32 bytes transfer, it is using DMA transfer and clock cycles are proper according to the bits-per-word.

./spidev_test -D /dev/spidev2.0 -s 1000000 -b 9 -S 32 -I 1 -v

If it is less 32 bytes then PIO transfer mode is using by the driver. Still, I am looking into it to get more details about the issue.

5

Dear @lic,

Thank you for your patience. This issue is introduced due to dynamic_burst implementation in the 4.14.117(12 - Nov -2017) kernel. Later on, there are many changes in spi_imx.c file so far now : https://github.com/torvalds/linux/commits/v5.4-rc7/drivers/spi/spi-imx.c

If you need a fix urgently, then could you apply this commit patch with our 4.14.117 kernel.

Meanwhile, I will check with my team when we would integrate this patch or migrate to that kernel version and let you know.

I would like to know how long could you wait to get from our official kernel releases.

Please feel free to contact us if you any support in future

Thank you.

7

Dear @raja.tx

It’s not very urgent for me. At the moment I’m using a 9-bit emulation with 8-bit access to the SPI (lower performance but it works).
Maybe I will try the patch if I find some time.

Thanks a lot for your great support.

8

Hi @lic

You are welcome.

Please let us know if the patch worked for you.

Best regards,
Jaski

9

Hi @jaski.tx

Because my kernel is 4.14-2.0.x I couldn’t apply the patch directly. But I have manually applied all changes from the commit patch to my current spi-imx.c and now everything is working fine.

Many thanks for your help and best regards,

Christoph

10

Hi @lic

Perfect that it works. Thanks for the feedback.

Best regards,
Jaski