zephyr: drivers: missing spi commands in mipi dbi driver

Describe the bug LCD screen does not display images correctly since last ili9xxx drivers update. There are some commands missing when probing the SPI bus. Here is what is sent on the bus since the update:

ko_dbg1

With previous ili9xxx drivers: ok_dbg1

Logs and console output Debugger shows that the calls to send 0x2a and 0x2b are executed:

Breakpoint 1, mipi_dbi_spi_write_helper (dev=<optimized out>, dbi_config=0x800a9e4 <ili9xxx_config_0+8>, cmd_present=cmd_present@entry=true, cmd=<optimized out>, data_buf=0x200019ac <z_main_stack+876> "", len=len@entry=4) at /home/eve/zephyrproject/zephyr/drivers/mipi_dbi/mipi_dbi_spi.c:103                                                                                                                                                                                         
103                             ret = spi_write(config->spi_dev, &dbi_config->config,                                                                                                                                                         
(gdb) print buf_set->buffers->len                                                                                                                                                                                                             
$7 = 1                                                                                                                                                                                                                                        
(gdb) x/1bx buf_set->buffers->buf                                                                                                                                                                                                             
0x2000195f <z_main_stack+799>:  0x2b

Environment (please complete the following information):

OS: GNU/Linux (LMDE 5)
Toolchain: Zephyr SDK
Zephyr branch #6fc6b30f (before MIPI DBI driver update) and #5f31c15b (after driver update)
Display sample application
Out-of-tree board: https://github.com/everedero/board_st_mb1283
SPI slowed down to 1MHz for probing

About this issue

Original URL
State: closed
Created 5 months ago
Comments: 19 (11 by maintainers)

Commits related to this issue

drivers: mipi_dbi: mipi_dbi_spi: do not take spinlock Taking a spinlock will result in interrupts being blocked in the MIPI DBI driver, which is not desired behavior while issuing SPI transfers, sinc... — committed to nxp-zephyr/zephyr by danieldegrasse 4 months ago
drivers: mipi_dbi: mipi_dbi_spi: do not take spinlock Taking a spinlock will result in interrupts being blocked in the MIPI DBI driver, which is not desired behavior while issuing SPI transfers, sinc... — committed to everedero/zephyr by danieldegrasse 4 months ago
drivers: mipi_dbi: mipi_dbi_spi: do not take spinlock Taking a spinlock will result in interrupts being blocked in the MIPI DBI driver, which is not desired behavior while issuing SPI transfers, sinc... — committed to everedero/zephyr by danieldegrasse 4 months ago
drivers: mipi_dbi: mipi_dbi_spi: do not take spinlock Taking a spinlock will result in interrupts being blocked in the MIPI DBI driver, which is not desired behavior while issuing SPI transfers, sinc... — committed to zephyrproject-rtos/zephyr by danieldegrasse 4 months ago
drivers: mipi_dbi: mipi_dbi_spi: do not take spinlock Taking a spinlock will result in interrupts being blocked in the MIPI DBI driver, which is not desired behavior while issuing SPI transfers, sinc... — committed to zephyrproject-rtos/zephyr by danieldegrasse 4 months ago
drivers: mipi_dbi: mipi_dbi_spi: do not take spinlock Taking a spinlock will result in interrupts being blocked in the MIPI DBI driver, which is not desired behavior while issuing SPI transfers, sinc... — committed to zephyrproject-rtos/zephyr by danieldegrasse 4 months ago
drivers: mipi_dbi: mipi_dbi_spi: do not take spinlock Taking a spinlock will result in interrupts being blocked in the MIPI DBI driver, which is not desired behavior while issuing SPI transfers, sinc... — committed to ashiroji/zephyr by danieldegrasse 4 months ago
drivers: mipi_dbi: mipi_dbi_spi: do not take spinlock Taking a spinlock will result in interrupts being blocked in the MIPI DBI driver, which is not desired behavior while issuing SPI transfers, sinc... — committed to everedero/zephyr by danieldegrasse 4 months ago

Most upvoted comments

Maybe I could somehow try to record the exact calls the display driver is sending to the SPI driver, and compare the old and the new driver calls and timings? There has to be a tiny difference from the upper levels to trigger a different behaviour in lower levels, it cannot just be a curse from my desk, right? 🤔

everedero on Feb 22, 2024

Turns out everything works if I comment out the spinlock calls in mipi_dbi_spi_write_helper (drivers/mipi_dbi/mipi_dbi_spi.c:61 and 127).

k_spinlock_key_t spinlock_key = k_spin_lock(&data->lock);

The two missing interrupts popping between MIPI driver call and STM32 SPI LL driver call are back, for some reasons.

Wow. This is bad- looking at the implementation I did there, that should absolutely be a mutex. Blocking interrupts here doesn’t make sense. Unless you’d like to, I’ll send a PR (as well as a backport) to fix this

danieldegrasse on Mar 5, 2024

Turns out everything works if I comment out the spinlock calls in mipi_dbi_spi_write_helper (drivers/mipi_dbi/mipi_dbi_spi.c:61 and 127).

k_spinlock_key_t spinlock_key = k_spin_lock(&data->lock);

The two missing interrupts popping between MIPI driver call and STM32 SPI LL driver call are back, for some reasons.

log_not_working_more_info.txt log_working_without_sema.txt

trace_working_without_sema.txt

everedero on Mar 5, 2024

I tried tracing, it is not helping me much, but here it is. The traces record a display_write call. The 2 semaphores traced are ctx.lock and ctx.sync:

spi_stm32_dev_data_0.ctx.lock.wait_q.waitq <spi_stm32_dev_data_0+16>
spi_stm32_dev_data_0.ctx.sync.wait_q.waitq <spi_stm32_dev_data_0+36>

trace_not_working.txt trace_working.txt

I also tried to print logs directly from the IRQ itself, it looks like it does not disrupt anything after all (the “.” is a printk when entering IRQ): log_not_working.txt log_working.txt

I will add more detailed logging, until it either give me interesting information or make everything collapse 😃

everedero on Mar 4, 2024