mipi_dbi: ssd1327: some screens don't work with the mipi_dbi bus

[lucbeaufils]

Describe the bug

Hardware:

• stm32l562e_dk
• WaveShare SSD1327 screen

I wrote a driver for SSD1327 screen controller (#74483).
The first version uses the basic spi bus and the second one uses the new MIPI DBI bus from Zephyr. I used only one screen at time to test the driver and everything was working.

However, for another project, I shop a new screen from the same place and noticed that it wasn't working with the MIPI DBI version. A third one had the same problem.

I managed to get all three functional with the MIPI DBI free version. After comparing the logical signal with a logic analyser, their is no difference between the working and the non-working screen with MIPI DBI.

For the moment, I have no idea where the problem comes from.

To Reproduce

I use the cfb code example with an ssd1327 screen in spi 4 wire.
When using the version with mipi dbi bus (branch: main, hash: ca48767), I use the following overlay for my board (stm325l62e_dk):

/ {
    chosen {
        zephyr,display = &ssd1327;
    };
    mipi_dbi {
        compatible = "zephyr,mipi-dbi-spi";
        spi-dev = <&spi3>;
        reset-gpios = <&gpioa 1 GPIO_ACTIVE_HIGH>;
        dc-gpios = <&gpioa 0 GPIO_ACTIVE_HIGH>;
        #address-cells = <1>;
        #size-cells = <0>;
        ssd1327: ssd1327fb@0 {
            compatible = "solomon,ssd1327fb";
            mipi-max-frequency = <4000000>;
            reg = <0x0>;
            width = <128>;
            height = <128>;
            multiplex-ratio = <127>;
            prechargep = <0x22>;
            remap-value = <0x5c>;
            oscillator-freq = <0x00>;
            display-offset = <0x00>;
            start-line = <0>;
        };
    };
};

And with the version without (hash: 61e5932ce1), I use this one:

/ {
    chosen {
        zephyr,display = &ssd1327;
    };
};

&spi3 {
    ssd1327: ssd1327@0 {
            compatible = "solomon,ssd1327fb";
            data_cmd-gpios = <&gpioa 0 GPIO_ACTIVE_HIGH>;
            spi-max-frequency = <4000000>;
            reg = <0x0>;
            width = <128>;
            height = <128>;
            multiplex-ratio = <127>;
            prechargep = <0x22>;
            remap-value = <0x5c>;
            display-offset = <0x00>;
            start-line = <0>;
            reset-gpios = <&gpioa 1 GPIO_ACTIVE_LOW>;
    };
};

Expected behavior

All SSD1327 screens must work with the MIPI DBI bus in the same way as with the simple SPI bus.

Impact

Either the screen works as expected, or it doesn't work at all. It depends on each screen

[github-actions[bot]]

Hi @lucbeaufils! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[erwango]

Removing STM32 tag as the issue doesn't seem to be related with the SoC here.

[mmahadevan108]

@erwango, do you have any suggestions for the developer. Looks like he is trying to enable the display using an STM32 board.

[erwango]

@erwango, do you have any suggestions for the developer. Looks like he is trying to enable the display using an STM32 board.

Unfortunately no. @danieldegrasse Maybe ?

[danieldegrasse]

Hi @lucbeaufils, I'm not certain what would be causing your display to have issues, but one difference I see between the two driver revisions is the delay on the reset pin pulses.

From what I can tell (based on your overlays):
In the upstream driver, RESET will be pulled high for 10 ms, then pulled low, then an additional 10ms delay is inserted before initialization starts.

In the working driver, there is an initial delay of 1ms, then RESET will be pulled low for 100us, and released. An additional 300 millisecond delay occurs before initialization starts.

This is probably where I'd look first to see if that is causing the issue for your display

[lucbeaufils]

hi @danieldegrasse,
Thanks for your reply.

Indeed, the only pin I didn't compare was the RESET. Following the datasheet, RESET is active low, so I don't understand why I added it as active high in the overlay...
Then the ssd1327 driver using the mipi_dbi is working on all of my screen without modification on the upstream driver. It's strange that the reset, set as active high, worked with one screen.
The reset timing seems to be ok with the upstream driver, it should not be updated.

Here the final working overlay :

/ {
    chosen {
        zephyr,display = &ssd1327;
    };
    mipi_dbi {
        compatible = "zephyr,mipi-dbi-spi";
        spi-dev = <&spi3>;
        reset-gpios = <&gpioa 1 GPIO_ACTIVE_LOW>;
        dc-gpios = <&gpioa 0 GPIO_ACTIVE_HIGH>;
        #address-cells = <1>;
        #size-cells = <0>;
        ssd1327: ssd1327fb@0 {
            compatible = "solomon,ssd1327fb";
            mipi-max-frequency = <4000000>;
            reg = <0x0>;
            width = <128>;
            height = <128>;
            multiplex-ratio = <127>;
            prechargep = <0x22>;
            remap-value = <0x5c>;
            oscillator-freq = <0x00>;
            display-offset = <0x00>;
            start-line = <0>;
        };
    };
};