Is there a way to use the B-LCDAD-HDMI adapter (bridge chip ADV7533) instead of the default panel DSI on the STM32MP157a-ev1 board?

[LOrci.1]

Hi,

I tried to update the DTS to make use of the adapter but unfortunately without success. These are the change I made:

hdmi-out {
    compatible = "hdmi-connector";
    type = "a";
 
    port {
        hdmi_con: endpoint {
                remote-endpoint = <&adv7533_out>;
            };
        };
};
 
&dsi { 
 
    phy-dsi-supply = <&reg18>;
 
    #address-cells = <1>;
    #size-cells = <0>;
    status = "okay";
 
    ports {
        #address-cells = <1>;
        #size-cells = <0>;
 
        port@0 {
            reg = <0>;
            dsi_in: endpoint {
                remote-endpoint = <&ltdc_ep0_out>;	
            };
        };
 
        port@1 {
            reg = <1>;
            dsi_out: endpoint {
                remote-endpoint = <&adv7533_in>;
            };
        };
    };
};
 
&i2c2 {
    pinctrl-names = "default", "sleep";
    pinctrl-0 = <&i2c2_pins_a>;
    pinctrl-1 = <&i2c2_pins_sleep_a>;
    i2c-scl-rising-time-ns = <185>;
    i2c-scl-falling-time-ns = <20>;
    status = "okay";
    /delete-property/dmas;
    /delete-property/dma-names;
 
    hdmi-transmitter@3d {
        compatible = "adi,adv7533";
        reg = <0x3d>;  // (3d = 7A>>1)
        
        a2vdd-supply =  <&v1v8>;
        v3p3-supply = <&v3v3>;
        v1p2-supply =  <&v1v8>;
 
        avdd-supply = <&v1v8>;
        dvdd-supply = <&v1v8>;
        pvdd-supply = <&v1v8>;
        dvdd-3v-supply = <&v3v3>;
 
        adi,dsi-lanes = <2>;
        adi,disable-timing-generator = <1>;
 
        status = "okay";
 
        ports {
            #address-cells = <1>;
            #size-cells = <0>;
 
            port@0 {
                reg = <0>;
                adv7533_in: endpoint {
                    remote-endpoint = <&dsi_out>;
                };
            };
 
            port@1 {
                reg = <1>;
                adv7533_out: endpoint {
                    remote-endpoint = <&hdmi_con>;
                };
            };
        };
   };

thanks in advance for your help.

Luca.

[Raggio]

Dear MKonz.1,

And so it was, it really helped us a lot!

The mod to the adv7511_drv.c file was key to finally get the kernel to detect ADV7533 and correctly read the display EDID. We also managed to add an IRQ line, even if we found that it doesn't change the behaviour of the driver, even without it, the kernel is able to detect an HDMI connector (plug-in and plug-out events) and EDID. Right now the are trying to find a less demanding screen as at boot we get:

[   18.513484] Time out check load galcore module expired
[   29.124419] Time out check galcore device expired
[   29.178322] Weston already configured on pixman
[   29.911176] [drm] Warning max phy mbps is used

To also give some details, this is what we get we probe status "cat /sys/kernel/debug/dri/0/state":

plane[30]: plane-0
        crtc=crtc-0
        fb=36
                allocated by = weston
                refcount=2
                format=XR24 little-endian (0x34325258)
                modifier=0x0
                size=1280x720
                layers:
                        size[0]=1280x720
                        pitch[0]=5120
                        offset[0]=0
                        obj[0]:
                                name=0
                                refcount=3
                                start=00010000
                                size=3686400
                                imported=no
        crtc-pos=1280x720+0+0
        src-pos=1280.000000x720.000000+0.000000+0.000000
        rotation=1
        normalized-zpos=0
        color-encoding=ITU-R BT.601 YCbCr
        color-range=YCbCr limited range
        user_updates=0fps
plane[33]: plane-1
        crtc=(null)
        fb=0
        crtc-pos=0x0+0+0
        src-pos=0.000000x0.000000+0.000000+0.000000
        rotation=1
        normalized-zpos=0
        color-encoding=ITU-R BT.601 YCbCr
        color-range=YCbCr limited range
        user_updates=0fps
crtc[32]: crtc-0
        enable=1
        active=1
        planes_changed=1
        mode_changed=0
        active_changed=0
        connectors_changed=0
        color_mgmt_changed=0
        plane_mask=1
        connector_mask=1
        encoder_mask=1
        mode: 0:"1280x720" 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5
connector[29]: HDMI-A-1
        crtc=crtc-0

meminfo also report that the frame buffer has been allocated "cat /proc/meminfo | grep -I cma":

CmaTotal:         131072 kB
CmaFree:          105688 kB

But no DMA/CMA has been allocated "cat /sys/kernel/debug/dma_buf/bufinfo":

Dma-buf Objects:
size            flags           mode            count           exp_name

Finally, with DMS/KMS logs enabled "echo 0x02 > /sys/module/drm/parameters/debug" we get:

// Only once, HDMI connector plug-in
[  946.608886] [drm:ltdc_crtc_mode_valid] clk rate target 148500000, available 148500000
[  946.608913] [drm:ltdc_crtc_mode_valid] clk rate target 147170000, available 118800000
[  946.608929] [drm:ltdc_crtc_mode_valid] clk rate target 148500000, available 148500000
[  946.608943] [drm:ltdc_crtc_mode_valid] clk rate target 108000000, available 99000000
[  946.608957] [drm:ltdc_crtc_mode_valid] clk rate target 108000000, available 99000000
[  946.608971] [drm:ltdc_crtc_mode_valid] clk rate target 136750000, available 118800000
[  946.608985] [drm:ltdc_crtc_mode_valid] clk rate target 88750000, available 84857143
[  946.608999] [drm:ltdc_crtc_mode_valid] clk rate target 119000000, available 118800000
[  946.609013] [drm:ltdc_crtc_mode_valid] clk rate target 74250000, available 74250000
[  946.609030] [drm:ltdc_crtc_mode_valid] clk rate target 40000000, available 39600000
[  946.609044] [drm:ltdc_crtc_mode_valid] clk rate target 31500000, available 31263158
[  946.609058] [drm:ltdc_crtc_mode_valid] clk rate target 31500000, available 31263158
[  946.609072] [drm:ltdc_crtc_mode_valid] clk rate target 30240000, available 29700000
[  946.609086] [drm:ltdc_crtc_mode_valid] clk rate target 25175000, available 24750000
[  946.609100] [drm:ltdc_crtc_mode_valid] clk rate target 28320000, available 28285715
[  946.609114] [drm:ltdc_crtc_mode_valid] clk rate target 135000000, available 118800000
[  946.609128] [drm:ltdc_crtc_mode_valid] clk rate target 78750000, available 74250000
[  946.609142] [drm:ltdc_crtc_mode_valid] clk rate target 65000000, available 59400000
[  946.609156] [drm:ltdc_crtc_mode_valid] clk rate target 49500000, available 49500000
[  946.609214] [drm:ltdc_crtc_mode_valid] clk rate target 25175000, available 24750000
[  946.609228] [drm:ltdc_crtc_mode_valid] clk rate target 27000000, available 27000000
[  946.609244] [drm:ltdc_crtc_mode_valid] clk rate target 27000000, available 27000000
[  946.609261] [drm:ltdc_crtc_mode_valid] clk rate target 148500000, available 148500000
[  946.609275] [drm:ltdc_crtc_mode_valid] clk rate target 27000000, available 27000000
[  946.609298] [drm:ltdc_crtc_mode_valid] clk rate target 27000000, available 27000000
[  946.609320] [drm:ltdc_crtc_mode_valid] clk rate target 74250000, available 74250000
[  946.609343] [drm:ltdc_crtc_mode_valid] clk rate target 148500000, available 148500000
[  946.609357] [drm:ltdc_crtc_mode_valid] clk rate target 74250000, available 74250000
[  946.609374] [drm:ltdc_crtc_mode_valid] clk rate target 74176000, available 66000000
[  946.609388] [drm:ltdc_crtc_mode_valid] clk rate target 25200000, available 24750000
[  946.609402] [drm:ltdc_crtc_mode_valid] clk rate target 27027000, available 27000000
[  946.609416] [drm:ltdc_crtc_mode_valid] clk rate target 27027000, available 27000000
[  946.609431] [drm:ltdc_crtc_mode_valid] clk rate target 148352000, available 118800000
[  946.638012] [drm:ltdc_plane_atomic_check] 
[  946.638033] [drm:ltdc_plane_atomic_check] 
[  946.647847] [drm:ltdc_plane_atomic_check] 
[  946.647878] [drm:ltdc_plane_atomic_check] plane:30 fb:37 (1280x720)@(0,0) -> (1280x720)@(0,0)
[  946.647889] [drm:ltdc_plane_atomic_check] 
[  946.648005] [drm:ltdc_plane_atomic_update] fb: phys 0xf7d00000
[  946.648022] [drm:ltdc_crtc_enable_vblank] 
[  947.001302] [drm:ltdc_plane_atomic_check] 
[  947.001335] [drm:ltdc_plane_atomic_check] plane:30 fb:37 (1280x720)@(0,0) -> (1280x720)@(0,0)
[  947.032752] [drm:ltdc_plane_atomic_check] 
[  947.032785] [drm:ltdc_plane_atomic_check] plane:30 fb:36 (1280x720)@(0,0) -> (1280x720)@(0,0)
[  947.032933] [drm:ltdc_plane_atomic_update] fb: phys 0xf7900000
[  952.109914] [drm:ltdc_crtc_disable_vblank] 
 
// Repeating sequence
[ 1006.637171] [drm:ltdc_crtc_enable_vblank] 
[ 1006.650527] [drm:ltdc_plane_atomic_check] 
[ 1006.650556] [drm:ltdc_plane_atomic_check] plane:30 fb:36 (1280x720)@(0,0) -> (1280x720)@(0,0)
[ 1006.656782] [drm:ltdc_plane_atomic_check] 
[ 1006.656813] [drm:ltdc_plane_atomic_check] plane:30 fb:37 (1280x720)@(0,0) -> (1280x720)@(0,0)
[ 1006.656946] [drm:ltdc_plane_atomic_update] fb: phys 0xf7d00000
[ 1011.709766] [drm:ltdc_crtc_disable_vblank] 
[ 1066.635943] [drm:ltdc_crtc_enable_vblank] 
[ 1066.651307] [drm:ltdc_plane_atomic_check] 
[ 1066.651338] [drm:ltdc_plane_atomic_check] plane:30 fb:37 (1280x720)@(0,0) -> (1280x720)@(0,0)
[ 1066.653817] [drm:ltdc_plane_atomic_check] 
[ 1066.653846] [drm:ltdc_plane_atomic_check] plane:30 fb:36 (1280x720)@(0,0) -> (1280x720)@(0,0)
[ 1066.653983] [drm:ltdc_plane_atomic_update] fb: phys 0xf7900000
[ 1071.709705] [drm:ltdc_crtc_disable_vblank] 

I don't get why it indicated so many valid modes, when "modetest -M STM" only gets 9 modes:

Encoders:
id      crtc    type    possible crtcs  possible clones
28      32      DSI     0x00000001      0x00000000
 
Connectors:
id      encoder status          name            size (mm)       modes   encoders
29      28      connected       HDMI-A-1        880x490         8       28
  modes:
        name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
  1280x720 60 1280 1390 1430 1650 720 725 730 750 74250 flags: phsync, pvsync; type: driver
  1280x720 60 1280 1390 1430 1650 720 725 730 750 74250 flags: phsync, pvsync; type: driver
  1280x720 50 1280 1720 1760 1980 720 725 730 750 74250 flags: phsync, pvsync; type: driver
  800x600 75 800 816 896 1056 600 601 604 625 49500 flags: phsync, pvsync; type: driver
  720x576 50 720 732 796 864 576 581 586 625 27000 flags: nhsync, nvsync; type: driver
  720x576 50 720 732 796 864 576 581 586 625 27000 flags: nhsync, nvsync; type: driver
  720x480 60 720 736 798 858 480 489 495 525 27000 flags: nhsync, nvsync; type: driver
  720x480 60 720 736 798 858 480 489 495 525 27000 flags: nhsync, nvsync; type: driver

Unfortunately we are still getting no output, the monitor remains without input signal, as every time we try send a test pattern to the screen, as an example with "modetest -M stm -s 29@32:1280x720-50", we get:

setting mode 1280x720-50Hz@XR24 on connectors 29
crtc 32 failed to set mode: Permission denied

Do you also think that the required pixel clock of our display is the key issue?

Many thanks again,

Regards

[MKonz.1]

I'm not sure. My display is 800x480 and is running correctly. Did you modify the dw-mipi-dsi.c routine I mentioned above to endure the horizontal active area is passed to the timing routine, not the horizontal total. I will try to a 1280 by 720 hdmi capable monitor and see what happens...

Regards,

[Raggio]

Dear @MKonz.1​ 

We've found an old RaspberryPi display with 1024x600 @ 30Hz and it worked ok with just the modification you've suggested.

Event if it showed a consistent image, a good portion of the image was out of the display: the video output stream was still 1280x720 (like if it ignored the current display resolution and put out an "hardcoded" one).

Maybe this is because last time we skipped the mod to the dw-mipi-dsi.c routine. Unfortunately we didn't really know what to modify specifically to specify an Horizontal Active Area, instead of the Horizontal Total... nor what is the Horizontal Active Area of our display.

I assume Horizontal Active Area is the actual display pixel resolution (1024 in the case of the old RaspberryPi display), while the Horizontal Total is the pixel resolution of the ldc embedded controller (that is usually larger as generic controllers may be matched with generic display... in the case of the old RaspberryPi display this may be 1280). Am I right?

Why the bigger 1280x720 isn't working is still unresolved from our side: if you can do the tests a monitor of yours it would be great!

Thank you again

[MKonz.1]

Sorry, I've been wrapped up on on other problems on my development project. I will try to test the larger display next week. I have a feeling the 1280x720 resolution is too high for the 2 channel DSI without reducing colour depth and/or refresh.

[Raggio]

Dear @MKonz.1​ 

Do not worry about the delay and many thanks for the update and help.

I hope that you have solved the issue you had with your project, we'll wait for your test results.

Meanwhile we managed to get a DK1 evaluation board (LTDC parallel interface routed to a Lattice Sil9022A), and in this case the HDMI port can handle our monitor at 1280x720 @ 60Hz. In fact it can even do more, adapting it's output size to the available monitor by reading the EDID at first plug-in event: so it can also drive the other 1024x600 @ 30Hz display. Unfortunately it won't adapt if a different monitor is plugged in after boot with another one of different resolution, but it is still something.

We think that this is an indicator of two main issues: the first one, that you already pointed out, is that EV1 "ignore" display size as it was born with the idea to be used with only one DSI display (dw-mipi-dsi.c routine mod to hardcode horizontal active area); the other is maybe the inability of the 2 lanes DSI to support that pixel clock, but we need to further investigate.

In the next day one of our colleague will take in hand this issue full-time, with a deep dive on DK1 modes of operations and what can be done to obtain the same results with EV1 and the HDMI adapter.

Thank you again,

Davide

[MBassi]

Dear @MKonz.1​ 

Sorry for some months of silence, I'm Marco a coworker of Davide in charge since last week of this part of the project.

I made the change you suggested in file KERNEL/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c updating the mode->htotal parameter to mode->hdisplay in dw_mipi_dsi_line_timer_config routine (hdisplay is the name for hactive timing parameter in drm_display_mode structure), but nothing changes on our display (I'm testing with a 1024x600).

I tried to do some changes using /etc/xdg/weston/weston.ini configuration file and I noticed that using B-LCDAD-HDMI adapter:

• Changes done in [output] section of our HDMI-A-1 are completely ignored, e.g I tried to flip the display using transform=flipped
• Changes done in [shell] section work, e.g I try to change panel position from bottom to top (panel-position=top)

while both changes done with the display connected to a DK1's native HDMI port work without any troubles.

As Davide wrote in his last post, DK1 handles our display without troubles using LTDC parallel interface routed to a Lattice Sil9022A through a DPI encoder, while our B-LCDAD-HDMI adapter use LTDC parallel interface routed to a ADV7533 through a DSI encoder.

I tried to figure out where the different behaviour could take place and I think it could be on how ADV7533 communicates with the DSI: it seems communication is mislead or broken for some reasons and the system could only use a partial or a default (or hardcoded??) configuration which not completely fit our display. I don't know if there are some linux drivers to add or some other changes to do in the DSI driver.

I hope you have some further suggestions or ideas for us

Best Regards

Marco.

[PatrickF]

Hi,

maybe this post could help: https://community.st.com/s/question/0D53W000018Ttf1SAC

Regards.

[MBassi]

Thank you @PatrickF​ for the immediate reply,

I tried your solution (both kernel patch and device tree) but unfortunately doesn't solve our issue which seems to be linked to a wrong computation of horizontal back porch or to a misled communication of EDID informations.

I add an image of my display hoping it could help to figure out the issue; if you have any other ideas or suggestions, they could be of help

Best regards

Marco.

[PatrickF]

Hi,

I'm not expert on this area, just linked other post which was on same topics. Maybe @PZak.1​ could have more clues.

Is it the display which is not aligned/sized or the weston screen size which is not correct ?

Maybe https://wiki.st.com/stm32mpu/wiki/Wayland_Weston_overview#Configuration could help

Regards.

[AntonioST]

The board MB1232 B-LCDAD-HDMI1 can be plugged on STM32MP157F-EV1 in place of the LCD panel.

There are few patches sent for upstream Linux, but not merged yet, that allows the setup MB1232 on STM32MP157F-EV1 to work fine with latest OpenSTLinux 3.1.0 (kernel v5.10.61).

These patches will soon be merged and become part of next OpenSTLinux deliveries.

The rest of this post is about the setup MB1232 on STM32MP157F-EV1, but it can be easily generalized for other systems containing STM32MP15x plus ADV7533.

This post covers the DSI to HDMI conversion only. Other features of ADV7533 (e.g. audio to HDMI) are not covered.

With STM32MP157F-EV1 board powered off:

• remove the camera module from STM32MP157F-EV1 (details below),
• remove the LCD panel from STM32MP157F-EV1,
• plug the MB1232 on the connector CN19 (DSI) of STM32MP157F-EV1, originally used by the LCD panel.

NOTE: the connection MB1232 on STM32MP157F-EV1 is fine from electrical point of view, but the two boards cannot be mechanically locked/screwed together; the HDMI cable can easily force, move and disconnect the board MB1232. Try to use an highly flexible HDMI cable and pay close attention on the mechanical stability of the system.

For the SW part, you need to patch and rebuild kernel and devicetree.

You can download each of the patches below by opening the corresponding links and then clicking on the link "(raw)" beside the Message-ID.

Use "git am ..." to apply each patch in the same order as listed below.

1) https://lore.kernel.org/lkml/20211218182804.208906-1-antonio.borneo@foss.st.com/

On STM32MP157F-EV1 the I2C address of the camera module conflicts with MB1232.

ADV7533 allows reprogramming the I2C address, but such reprogramming should be done before Linux accesses the conflicting address.

Unfortunately the probe of ADV7533 often happens after the probe of the camera, so the conflict can still create issues.

The reprogramming of ADV7533 could be done in U-Boot, before Linux starts, but this is not covered in this current setup.

As a quick workaround, for the time being, I suggest to keep the camera module unplugged.

Without camera module, this patch is still relevant to avoid I2C address conflicts in the devicetree; the devicetree below requires this patch.

2) https://lore.kernel.org/lkml/20211218215055.212421-1-antonio.borneo@foss.st.com/

3) https://lore.kernel.org/lkml/20211218215055.212421-2-antonio.borneo@foss.st.com/

4) https://lore.kernel.org/lkml/20211218215055.212421-3-antonio.borneo@foss.st.com/

These patches instruct DSI to reject all the video modes that cannot be supported with the current clock.

Without these patches the DSI never rejects a video mode, so the DRM framework can incorrectly choose a mode that cannot be displayed.

HDMI panels are quite picky with the timings, so these patches are relevant for a correct setup of a DSI-to-HDMI bridge.

ADV7533 does not accepts DSI burst mode, so STM32MP15x DSI must generate the exact pixel clock required by the HDMI panel.

The STM32MP15x DSI has some limitation on the pixel clock values that can be generated.

This script dumps all the DSI pixel clock values that are compatible with the STM32MP157F-EV1's on-board oscillator of 24 MHz:

#!/bin/bash
hse=24000000
vcomin=1000000000
vcomax=2000000000
n_lanes=2
 
# 24 bpp
byte_per_pixel=3
 
for i in {1..7}; do
  for n in {10..125}; do
    vco=$(($hse*2*$n/$i))
    if [ $vco -lt $vcomin -o $vco -gt $vcomax ]; then
      continue
    fi
    for o in 1 2 4 8; do
      hs_clk=$(($hse*$n/($i*$o)))
      echo $(($hs_clk*$n_lanes/(8*$byte_per_pixel)))
    done
  done
done | sort -nu

NOTE: If you need to support a specific pixel clock not listed by the script, you can consider replacing the 24 MHz main oscillator on the board (HSE clock).

You can find information about the oscillator's frequencies allowed by the bootrom of STM32MP1 in

https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_code_overview#USB_Boot

If you change oscillator, you should align the clock configuration in TF-A devicetree

https://wiki.st.com/stm32mpu/wiki/Clock_device_tree_configuration_-_Bootloader_specific

Modify the variable "hse" in the script above to dump the pixel frequencies for different oscillators.

With the patches above applied, add the change in attachment for the kernel's devicetree to disable the (removed) STM32MP157F-EV1 panel and enable the MB1232.