Hi All,
a custom display manufacture requires receiving init commands before activating the clock.
If I try sending the commands during the panel_prepare function, I get the following kernel errors
imx_sec_dsim_drv 32e10000.mipi_dsi: wait pkthdr tx done time out
panel-simple-dsi 32e10000.mipi_dsi.0: Failed to send DCS (-16), (1)01
imx_sec_dsim_drv 32e10000.mipi_dsi: panel prepare failed: -16
Is there any way to overcome the problem?
Thanks
Regards
Pier
We are working on similar project with i.MX8M Mini and have similar results as oferausterlitz.
"If the commands are sent from the enable function (as for most of the MIPI displays drivers), the commands are sent correctly, but the display shows nothing.
If the commands are sent from the prepare function (not seen in other MIPI displays drivers), we get the errors reported in the 1st message of this thread."
Do you have any progress in solution of this issue?
Regarding your question:
> kernel errors
> imx_sec_dsim_drv 32e10000.mipi_dsi: wait pkthdr tx done time out
> panel-simple-dsi 32e10000.mipi_dsi.0: Failed to send DCS (-16), (1)01
> imx_sec_dsim_drv 32e10000.mipi_dsi: panel prepare failed: -16
I added a new display (the ORIC ORC03003N-40) using the Sitronix ST7701 driver chip to the iMX8MM EVK.
I patched the Raydium rm67191 driver by only changing the init sequence to the manufacturer command set of the new display, adjusted the pixel clock, and corrected the number of lanes in the corresponding dts and I immediately got colored stripes shown on the display.
One important observation is that the raydium driver uses
mipi_dsi_generic_write() to send mipi commands, which is working, while mipi_dsi_dcs_write_buffer() failed with "wait payload tx done time out" or ""wait pkthdr tx done time out" errors (in kernel log) after about four successful writes.
Find patches for i.MX8MM Android 10 sources below.
Apply with
cd imx-android-10/android_build/vendor/nxp-opensource/kernel_imx
git apply 0001-add-st7701-driver-shows-stripes-not-finished.patch
cd imx-android-10/android_build/device/fsl
git apply 0001-change-mipi-display-to-st7701.patch
Hi nxp31,
I'm also writing a driver for a MIPI panel and I have a doubt about the "mipi_dsi_generic_write()" function. When I send a MIPI command using this function, does it add the PacketHeader and the checksum to the message? Should I send just the payload of the message?
Supouse I have to send
PacketHeader[39 04 00 XX]
Payload[ B9 FF 83 94 ]
CheckSum [XX XX]
Would it be something like this....?
struct mipi_dsi_device *dsi;
uint8_t mymessage[] = {0xB9, 0xFF, 0x83, 0x94};
mipi_dsi_generic_write(dsi , (void*) mymessage, 4 ); // is this how it works?
....
Best Regards!
@electronic15
Hello,
Please create separate request
https://www.nxp.com/support/support:SUPPORTHOME?tid=sbmenu
Regards,
Yuri.
Hi Yuri,
thanks for pointing this out.
Can you please clarify if both of the bits (1 & 3) must be set?
The current sec-dsim driver, in LP mode currently enables only bit 7 (ESCMODE_CMDLPDT): is this required too?
Thanks
Best Regards
Pier
Hello,
To set LP11 mode before initialize the panel, it is possible to set register DSI_ESCMODE:
Bit 1: TxUlpsClk: Specifies ULPS request for clock lane.
Bit 3: TxUlpsDat: Specifies ULPS request for data lane.
Regards,
Yuri.
Hi Rogerio,
I attached the datasheet here:
https://support.nxp.com/s/case/5002p00002FrFGv
The feeling is that the display controller is not able to accept LPM commands once the MIPI interface switched to HS.
The EVK from the manufacturer shows that all the commands are sent before the MIPI CLK switch to HS.
From a linux kernel perspective, this means that the commands should be sent from the "prepare" function of drm_panel_funcs struct, called before the "enable" function of drm_panel_funcs struct.
If the commands are sent from the enable function (as for most of the MIPI displays drivers), the commands are sent correctly, but the display shows nothing.
If the commands are sent from the prepare function (not seen in other MIPI displays drivers), we get the errors reported in the 1st message of this thread.
Please let me know if you need further details.
Thanks
BR
Pier
hi @oferausterlitz
can you please tell me according to commands if i movie init sequence prepare function to enable function display is not able to on.what are the possibilities to on the display? i have bought this display from orient display and i am stuck on this.. in your case it worked?
We are working on similar project with i.MX8M Mini and have similar results as oferausterlitz.
"If the commands are sent from the enable function (as for most of the MIPI displays drivers), the commands are sent correctly, but the display shows nothing.
If the commands are sent from the prepare function (not seen in other MIPI displays drivers), we get the errors reported in the 1st message of this thread."
Do you have any progress in solution of this issue?
Hi Ofer,
I'll check if it's possible to enter in LPM after switch to HS Mode.
I can't download the datasheet. Could you please send me by e-mail? rogerio.silva@nxp.com
Thanks,
Rogerio
Hi Pierluigi, Andreas,
I'm not understanding what exactly waveform is expected by display. Could you please send the display datasheet?
Best regard,
Rogerio
Hello,
I just made some new measurements with the working Board (which uses a SSD2828 bridge; and no iMX).
I assume that the following transmission is a standard LowPower transmission, which every MIPI device should support - and therefore also the iMX8M mini, right?
Clock should be restored by Exor-function of D0P / D0N - right? --> the measurement shows something like 7.4MHz clock frequency for this transmission.
Hi Yuri,
we are currently based on kernel 4.14.98 v2.0.0.
I've also inspected and back-ported the additional sec-dsim patches from kernel 4.14.98 v2.3.0, but the behavior is exactly the same.
Any suggestion?
Thanks
Best Regards
Pier
Working on the same project, I can show this picture with another evalboard driving the discussed display. But as Pier wrote above, we need it with MIPI from imx8m mini.
Here you can see the initial code, without having signals on CLK_P (I have also measured CLK_N, but not visible here)
Please excuse the bad signal quality, but I only have one active probe.