MIPI DSI Generic FIFO Issue on i.MX6dl

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MIPI DSI Generic FIFO Issue on i.MX6dl

1,357 Views
kaangencay
Contributor I

Hello,

I have custom board based on i.MX6dl and I use MIPI DSI interface to drive an LCD. 

I have a problem that mostly right after rebooting, two parallel lines appear on the screen. It seems to be random and cannot be reproduced easily. 

I suppose that it is about initialize sequence. Sometimes it can't write to the register because of timeout error I think. Because, in Linux driver (mipi_dsi.c), MIPI_DSI_REG_RW_TIMEOUT = 20 ms and in the log below we can see 19.9 ms.

Initialize sequence takes almost 2,5 seconds. When I measure that how much time does each register take, I got logs below. Also the part of initial code below.

I think there is an issue about MIPI DSI Generic FIFO size. I can't find anything about Generic FIFO size.

Do you have any idea about it or any suggest about it?

Best Regards,

Kaan

/*the part of init code*/

LCD_Gen_write_1A_3P(0xFF,0x98,0x81,0x03);
LCD_Gen_write_1A_1P(0x01,0x00);
LCD_Gen_write_1A_1P(0x02,0x00);
LCD_Gen_write_1A_1P(0x03,0x73);
LCD_Gen_write_1A_1P(0x04,0xD3);
LCD_Gen_write_1A_1P(0x05,0x00);
LCD_Gen_write_1A_1P(0x06,0x0A);
LCD_Gen_write_1A_1P(0x07,0x0F);
LCD_Gen_write_1A_1P(0x08,0x00);
LCD_Gen_write_1A_1P(0x09,0x01);
LCD_Gen_write_1A_1P(0x0A,0x01);
LCD_Gen_write_1A_1P(0x0B,0x01);
LCD_Gen_write_1A_1P(0x0C,0x01);
LCD_Gen_write_1A_1P(0x0D,0x01);
LCD_Gen_write_1A_1P(0x0E,0x01);

LCD_Gen_write_1A_1P(0x0F,0x01);

...

/**/

static int LCD_Gen_write_1A_3P(u8 a,u8 b,u8 c,u8 d)
{
u32 buf[1];
u32 mbbuf[4];
int err;

mbbuf[0]=a;
mbbuf[1]=b;
mbbuf[2]=c;
mbbuf[3]=d;


buf[0]=0;
buf[0] = mbbuf[0] | (mbbuf[1] << 8) | (mbbuf[2] << 16) | (mbbuf[3] << 24);
err = mipi_dsi_tianma->mipi_dsi_pkt_write(mipi_dsi_tianma, MIPI_DSI_GENERIC_LONG_WRITE, buf, 4);

return 0;
}

/**/

static int LCD_Gen_write_1A_1P(u8 a, u8 b)
{
u32 buf[1];
int err;
u32 mbbuf[4];

int ret;
mbbuf[0]=a;
mbbuf[1]=b;

buf[0]=0;
buf[0] = mbbuf[0] | (mbbuf[1] << 8);
err = mipi_dsi_tianma->mipi_dsi_pkt_write(mipi_dsi_tianma, MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM, buf, 0);

return 0;
}

/*Measurement logs*/

[ 0.243296] Register 0xff took 3 usec
[ 0.263281] Register 0x1 took 19980 usec
[ 0.263286] Register 0x2 took 1 usec
[ 0.283280] Register 0x3 took 19989 usec
[ 0.283284] Register 0x4 took 1 usec
[ 0.303279] Register 0x5 took 19990 usec
[ 0.303283] Register 0x6 took 1 usec
[ 0.323281] Register 0x7 took 19994 usec
[ 0.323285] Register 0x8 took 1 usec
[ 0.343280] Register 0x9 took 19991 usec
[ 0.343285] Register 0xa took 2 usec
[ 0.363279] Register 0xb took 19990 usec
[ 0.363284] Register 0xc took 2 usec
[ 0.383279] Register 0xd took 19991 usec
[ 0.383283] Register 0xe took 2 usec
[ 0.403279] Register 0xf took 19992 usec

...

Labels (1)
0 Kudos
3 Replies

1,182 Views
igorpadykov
NXP Employee
NXP Employee

Hi KAAN

such issue may be observed in case when reset does not remove all power to board.

For example i.MX6 Sabre SD was designed to remove power (voltage source) to all components
on the board (using PWRON PMIC siganl) in the event of a processor reset.

In general one can try to disable MIPI DSI before rebooting.

Schematics (1)
Design files, including hardware schematics, Gerbers, and OrCAD files.

SABRE Platform for Smart Devices | NXP 

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

0 Kudos

1,182 Views
kaangencay
Contributor I

msleep(1) line which is used in mipi_dsi_pkt_write() function in mipi_dsi.c takes about 19 ms and I don't know why. When I replaced with udelay(10), Initialize sequence takes almost 0.2 second. Logs are below.

But  two parallel lines appearing issue still persists randomly. It is not fixed. If I get some logs about it, I will share.

/*Measurement logs*/

[ 0.203643] Register 0xff took 2 usec
[ 0.203658] Register 0x1 took 12 usec
[ 0.203684] Register 0x2 took 1 usec
[ 0.203710] Register 0x3 took 1 usec
[ 0.203736] Register 0x4 took 1 usec
[ 0.203762] Register 0x5 took 1 usec
[ 0.203788] Register 0x6 took 1 usec
[ 0.203814] Register 0x7 took 1 usec
[ 0.203840] Register 0x8 took 1 usec
[ 0.203866] Register 0x9 took 1 usec
[ 0.203892] Register 0xa took 1 usec
[ 0.203919] Register 0xb took 2 usec
[ 0.203945] Register 0xc took 1 usec
[ 0.203971] Register 0xd took 2 usec
[ 0.203997] Register 0xe took 2 usec
[ 0.204022] Register 0xf took 1 usec

...

0 Kudos

1,182 Views
igorpadykov
NXP Employee
NXP Employee

Hi KAAN

for issues which can be observed only on custom boards

may be recommended support with NXP Professional Services | NXP 

Best regards
igor

0 Kudos