IMX8MM - DSI - PH720128T003 - ILI9881c-based DISPLAY

[Noel_V]

Hi all, 

i've been spending some weeks on connecting a MIPI-panel/display to the IMX8MM-evk ! 

I'm using kernel version linux-imx_4.14.98_2.0.0_ga ( and before linux-imx_4.14.78_1.0.0_ga) , both kernels do are resulting into the same 'trouble' , can't get the display working. (HDMI version is working out of the box) 

I've started writing a driver for the powertip-ph720128T0003-MIPI-DSI display  (based on rm67191 that is included into the kernel sources).

In order to initialize the display a "set of commands must be sent to the display" (over MIPI-DSI) ... and during the initial command transfer at certain point ( in panel_enable)  the MIPI-DSI controller 'STOPS' communicating ( no more IRQ's are being seen by the kernel)  { the display init commands exists out of a 285 command set over MIPI , at this time the init hangs after approx 53 commands being send out over mipi}

In order to track down the reason i've been logging every access to de MIPI-DSI device controller ( located into the file sec-dsim.c) . { read and writes to the registers are written / logged in syslog ( a full syslog is included just for reference)}

the issue i'm facing is that at certain point in the init-phase the 'sec_mipi_dsim_irq_handler' is getting no longer the 'SFRPHFIFOEMPTY' interrupts.

Just before the loss of  'SFRPHFIFOEMPTY' interrupts, I see a status 'st=0x8010040E' in the interrupt routine at that time I no longer get the 'INTSRC_SFRPHFIFOEMPTY' interrupt ( FY in normal cases it is 'st=0x8010010F') 

The IMX8MM reference manual is not very clear on why this can happen ... ( in fact the 'description' on why this could happen.. is not there ).

[ 1.983040] READ : reg:0x00000004 val=0x8010010F
[ 1.983043] sec_mipi_dsim_irq_handler-1 sr=0x10000000 - st=0x8010010F - msk=0x0B00FFFF
[ 1.983047] WRITE : reg:0x00000034 val=0x10000000
[ 1.983055] ####ph720128T003_panel_enable-Send MANUF-CMDS [53]
[ 1.983057] ili9881c_send_cmd_data - 0x35,0x00
[ 1.983060] READ : reg:0x0000001C val=0x00000080
[ 1.983063] WRITE : reg:0x0000001C val=0x00000080
[ 1.983065] WRITE : reg:0x0000003C val=0x00003515
[ 1.983075] READ : reg:0x00000038 val=0x0B00FFFF
[ 1.983077] READ : reg:0x00000034 val=0x10000000
[ 1.983081] READ : reg:0x00000004 val=0x8010040E
[ 1.983085] sec_mipi_dsim_irq_handler-1 sr=0x10000000 - st=0x8010040E - msk=0x0B00FFFF
[ 1.983088] WRITE : reg:0x00000034 val=0x10000000
[ 1.983096] ####ph720128T003_panel_enable-Send MANUF-CMDS [54]
[ 1.983101] ili9881c_send_cmd_data - 0x36,0x00
[ 1.983104] READ : reg:0x0000001C val=0x00000080
[ 1.983106] WRITE : reg:0x0000001C val=0x00000080
[ 1.983109] WRITE : reg:0x0000003C val=0x00003615
[ 2.236741] READ : reg:0x00000034 val=0x00000000
[ 2.236744] READ : reg:0x00000004 val=0x8010040E
[ 2.236748] sec_mipi_dsim_host_transfer-2 ERROR HANDLER sr=0x00000000 - st=0x8010040E
[ 2.236755] imx_sec_dsim_drv 32e10000.mipi_dsi: wait pkthdr tx done time out
[ 2.236758] ####ph720128T003_panel_enable init fail in 54, ret: fffffff0
[ 2.236762] imx_sec_dsim_drv 32e10000.mipi_dsi: panel enable failed: -16

once the "MIPI-DSI' controller get into this 'state' .. it is no longer possible to send something out to the 'display' over MIPI-DSI.

I see lots of issues/troubles/questions on the MIPI-DSI in this forum, and everybody is pointing you the same example as reference... but i've been looking 1001 times to this rm67191 as reference,.. so pointing me into this direction won't bring me anything.

Anyone that is able to give me some feedback .. and or possible work around.

Even better would be pointing me to a known-working version of the kernel on MIPI-DSI..  { i see a different behavior between linux-imx_4.14.98_2.0.0_ga and linux-imx_4.14.78_1.0.0_ga.. when i use the same drivers}

Furthermore when using the rm67191 driver ( just to log the init phase , i see that it 'stalls' on a similar place during the the panel_enable functions)

Best regards,

Noel

[Noel_V]

Hi all,

Reporting back.. to community. 

Issue solved,  was no software issue,  was a PCB-design-error  (voltage level of reset pin was 1.8V iso 3V3) ! !

Regards 

Noel

[Noel_V]

Hello, 

Does anybody have experience with the following ? 

If I disconnect the MIPI-panel ( PT270128T003  or the RM67191) and I do boot kernel,  at that time, I GET EXACTLY THE SAME ERROR  ( aka SFRPHFIFOEMPTYinterrupts stay away after some time ) during the init-phase of the display-panel ( when sending custom commands to the display). { 53 command can be send out ,  on command 45th Fifo-interrupts are missing } 

Is there any one that can explain why this is happening ?

During the this custom init ( sending custom lcd-commands down) only data is being send to the panel .. ( nothing is being read) ... why would "sending" ( shifting data out) fail ( so that IRQ's stays away ).

Best regards.

Noel

[igorpadykov]

Hi Noel

for ILI9881 lcd one can look at technexion boards :

imx8mm change display mipi dsi · TechNexion/u-boot-edm Wiki · GitHub 

linux-imx-tn/imx8mm-pico-pi-ili9881c.dts at tn-imx_4.14.98_2.0.0_ga-wip-mipi2lvds · TechNexion-custo... 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[Noel_V]

Hi Igor, 

I've been checking purposed , but  it seems I stalls on the 'same level'  ( ili9881_prepare, this sends down a similar init-sequence as I need on the ph7201208T003 display) 

As far as I can see ( with this quick test) this now hangs at the 4th ( iso of the 54th) init-command ( with a similar behavior... no more IRQ's for 'SFRPHFIFOEMPTY')

The difference between this proposed driver (/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c)  and the 'RM67191' ( where I started from) that in this 'code  you are pointing me to that the LCD-panel-init  (manufacturer depending) is done on the 'ON_PREPARE' iso the  'ON_ENABLE', but both ... 'drivers' seem to stall on the MANUFACTURERS depending init ...

( both cases are, missing interrupts on SFRPHFIFOEMPTY on the MIPI-DSi-driver 'sec_mipi_dsim_irq_handler' )

Please note that I use IMX8MM-evk board to test !  ( and not IMX8QM)

Writing / having code is one thing, I wonder if there is anyone who can confirm to have it working !

Regards Noel

[igorpadykov]

Hi Noel

suggested  technexion board ILI9881 lcd  example is for i.MX8MM, not for i.MX8QM.

For init-sequence for ph7201208T003 display one can apply for help to vendor of that panel for additional details. 

Best regards
igor

[Noel_V]

Hi Igor,

The init sequence itself is not an issue this is clearly stated into the ph7201208T003 datasheet.

The problem I'm facing is that for some reason the DSI - IRQ's on fifo-empty ( for header packets, into the sec_mipi_dsim_irq_handler)  SFRPHFIFOEMPTY are failing ( it works for some time couple of ms.lets say, during panel-init.... but suddenly the IRQ's stay away ... while i've been logging ( printing in syslog) every access to the registers ( and this log does NOT show any access to the registers that can explain the IRQ's to be disabled)

If you check the syslog i've included you can see this ...  the question is what can be the reason for this?

I'm even far away from having a 'clear' picture on the display, at this time, I'm in the stage of trying to get the 'init-sequence' sent out to the display without errors.

Just for info: If I test the same sequence for another display ( for example RM97191) .. i see exactly the same behavior..( before the init -sequence is done the IRQ's are no longer there.)

The ILC9881c code ( created by maxime ( free-electrons)) the one you pointed to on TechNexion-customization · GitHub ) is also having the same behavior, this probably means that it is something else (in the kernel) and not the driver itself.. the question is what it can be that causes this behavior.

Noel.