2022-05-03 02:41 PM
We are doing a custom board bring-up and currently trying to display video on our display device. We use CubeMx to generate the device trees for our project, we have configured the DSI PLL dividers to match our display device requirement. Snapshot of the configuration is shown below.
In the device tree's rcc node, we do see the CLK_DSI_DSIPLL, however we are not seeing these divider information.
The clock configurations for rest of the peripherals are reflected in the device tree, also the clock dividers to generate DSI pixel clock are present in the rcc node and in the target's clock summary dsi_px clock shows the configured clock frequency.
The clock configurations for DSI lane clock is not seen in the device tree and also in the target it shows 200MHz instead of a 174MHz when measured.
Are we missing anything here? Where is the DSI PHY configurations in the device tree?
Solved! Go to Solution.
2022-06-22 03:19 PM
Hi Gregory,
Thanks for getting back. Through some experiments, we resolved the clock issue.
We observed that the issue where, the measured DSI lane clock was 200MHz instead of 174MHz was linked to the video mode we used.
Our display does not support non-continuous clock, so we had set the video mode to MIPI_DSI_MODE_VIDEO_BURST with a continuous clock. With this combination, though our panel displays images the measured DSI lane clock frequency on the Oscilloscope shows 200MHz. We are still not sure why this combination pushes the DSI lane clock higher than configured.
However, since we do not support burst mode and non-continuous clock, we changed the
dsi->mode_flags to MIPI_DSI_MODE_VIDEO which solved our issue. Now the DSI lane clock shows ~174MHz and the display works fine too.
Also we are going with the assumption that the DSI PLL dividers and DSI lane byte clock info were not present in the generated device tree, may be because it is reverse calculated based on the the pixel clock, resolution, porch values etc, in the panel driver.
Thanks,
Shalini
2022-05-04 08:16 AM
DSI byte clock create LVDS byte clock to transfer one byte and use both edges...
43,5 x 8 = 348MB/s == 174 MHz
DSI pixel clock need be less as lane data speed ...
2022-05-09 09:54 AM
The DSI pixel clock is @28.87MHz which is lesser than lane byte clock.
The issue we have here is that with the dividers matching the snapshot above we see a 200Mhz clock instead of a 174MHz clock on the DSI clock lane in the Oscilloscope.
Any idea why is that the case?
2022-05-09 12:55 PM
Seems you dont understand what you do.
Clock for display data is based on RGB888 = 28,87 x 24 = 692,88 MHz
2022-05-09 01:48 PM
We understand this math. The effective rate must correlate with number of data lanes used by MIPI.
In our case we use two data lanes, which means 692.88 / 4 = 173.22 which is the dsi data lane clock.
Right now when we measure that clock we see 200Mhz instead of ~174Mhz. That's what we are trying to figure out? why the frequency is incorrect?
2022-06-20 02:36 AM
hi @SKris ,
In order to have all the information could you send me the result of the command "modetest -M stm" and the DSI part of your DeviceTree.
Could you also tell me if you use Birthmode or not ?
Waiting for your return, I will do some research with CubeMX.
regards,
Grégory
2022-06-22 03:19 PM
Hi Gregory,
Thanks for getting back. Through some experiments, we resolved the clock issue.
We observed that the issue where, the measured DSI lane clock was 200MHz instead of 174MHz was linked to the video mode we used.
Our display does not support non-continuous clock, so we had set the video mode to MIPI_DSI_MODE_VIDEO_BURST with a continuous clock. With this combination, though our panel displays images the measured DSI lane clock frequency on the Oscilloscope shows 200MHz. We are still not sure why this combination pushes the DSI lane clock higher than configured.
However, since we do not support burst mode and non-continuous clock, we changed the
dsi->mode_flags to MIPI_DSI_MODE_VIDEO which solved our issue. Now the DSI lane clock shows ~174MHz and the display works fine too.
Also we are going with the assumption that the DSI PLL dividers and DSI lane byte clock info were not present in the generated device tree, may be because it is reverse calculated based on the the pixel clock, resolution, porch values etc, in the panel driver.
Thanks,
Shalini