Eve Redero

It might be a platform-specific issue, because ili9xxx_set_mem_area does jump into the SPI HAL, even for 0x2a and 0x2b commands: ``` #0 transceive (asynchronous=false, cb=0x0, userdata=0x0, rx_bufs=0x0, tx_bufs=, config=0x802d9c8 ,...

For reference, this is what the screen looks like with this 0x2a and 0x2b missing commands issue. Since it does not receive the coordinates correctly, the grey pixels from the...

It does fail consistently, always the same 0x2a and 0x2b disappearing behaviour. I tried to compare initialization commands in both cases, and only some commands are missing, never data: [ok_vs_ko.ods](https://github.com/zephyrproject-rtos/zephyr/files/14315798/ok_vs_ko.ods)

- The delay does not change the behaviour:  - I think nothing gets written to the hardware, it seems like it never gets to the SPIx->DR register modification (also,...

The display works if I disable interrupt mode for SPI driver: `CONFIG_SPI_STM32_INTERRUPT=n`

No, #69200 doesn't affect my issue

I tried with duplex removed, still with the fix, with no success. Logging gives: ` spi_ll_stm32: spi_stm32_configure: Installed config 0x802ceec: freq 10500000Hz (div = 4), mode 0/0/0, slave 0`

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

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

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