SN65DSI86: read register waiting time

However, when F6 has a problem, reading F6 inside after the initialization is completed is the wrong value to read,It will take at least 40ms to read correctly

Hi,

For the status registers, sometimes errors flags can be set at power-on or during start of the DSI stream. For this reason, it is recommended to clear flags by writing 0xFF and then reading back status flags.

Can you please clarify your comment "reading F6 inside after the initialization is completed is the wrong value to read"? Address 0xF6 thru 0xF7 report errors associated with DSI to DP video timing. Typically, errors are set in these registers when video timing programmed into DSI86 doesn’t match timing received on the DSI interface. So register 0xF6 will not return a value until the video stream has been started at the DSI input.

Thanks

David

When F6=40 or F6=60, the corresponding value cannot be obtained immediately，need delay 40ms

Hi,

Did you read the value from status register 0xF6 after you set the VSTREAM_ENABLE bit in register 0x5A?

Thanks

David

Not to read the value immediately,Read F6 after initializing the code

Hi,

I am not clear on your question and asked our FAE Stone to get in touch with you for support on the DSI86.

Thanks

David

Hi David,

1.We want to know the min waiting time to read 0xF6 register after DSI86 initiation,we use below codes,and found the min waiting time is about 40ms to read 0xF6 register after DSI init.Could you please check the below code if there is any problem?

693 static int sn65dsi86_resume_init(struct sn65dsi86_data *pdata)
694 {
695 int ret = 0;
696 int max_retries = 3;
697 int retries = 0;
698 pr_err("tmj sn65dsi86_resume_init\n");
699 if(!pdata->is_in_suspend)
700 return 0;
701
702 if(pdata == NULL) {
703 pr_err("sn65dsi86 pdata null !!! \n");
704 } else {
705 //sn65dsi86_reset(pdata);
706 sn65dsi86_init_reg(sn65dsi86_client, pdata);
707 msleep(100);
708 ret = sn65dsi86_read(sn65dsi86_client, EDP_I2C_ADDR, 0xF6);
709 pr_err("tmj sn65dsi86_resume_init ret=0x%x\n", ret);

2.Below is the resume code of dsi86,we first check F6 status,if F6 status has error,we'll disable vstream,then power off dsi86,then power on and reset dsi86,then init the dsi86.

693 static int sn65dsi86_resume_init(struct sn65dsi86_data *pdata)
694 {
695 int ret = 0;
696 int max_retries = 3;
697 int retries = 0;
698 pr_err("tmj sn65dsi86_resume_init\n");
699 if(!pdata->is_in_suspend)
700 return 0;
701
702 if(pdata == NULL) {
703 pr_err("sn65dsi86 pdata null !!! \n");
704 } else {
705 //sn65dsi86_reset(pdata);
706 sn65dsi86_init_reg(sn65dsi86_client, pdata);
707 msleep(100);
708 ret = sn65dsi86_read(sn65dsi86_client, EDP_I2C_ADDR, 0xF6);
709 pr_err("tmj sn65dsi86_resume_init ret=0x%x\n", ret);
710
711 while (ret != 0 && retries < max_retries) {
712 pr_err("tmj sn65dsi86_resume_init rty %d \n", retries + 1);
713
714 //gpio_direction_output(pdata->bl_gpio, 0);
715 //msleep(100);
716 //gpio_direction_output(pdata->pwr_gpio_dc12v, 0);
717 sn65dsi86_vstream_enable_off(pdata);
718 msleep(20);
719 sn65dsi86_write(sn65dsi86_client, EDP_I2C_ADDR, 0x96, 0x00);//01 normal 06 HBR2 mode
720 sn65dsi86_write(sn65dsi86_client, EDP_I2C_ADDR, 0x93, 0x00);//DP lanes, 2 lanes--->0x24; 4 lanes--->0x34
721 sn65dsi86_write(sn65dsi86_client, EDP_I2C_ADDR, 0x0D, 0x00);
722 gpio_direction_output(pdata->pwr_rst_gpio, 0);
723 gpio_direction_output(pdata->rst_gpio, 0);
724 msleep(50);
725 gpio_direction_output(pdata->pwr_gpio_12v, 0);
726 gpio_direction_output(pdata->pwr_gpio_18v, 0);
727 gpio_direction_output(pdata->pwr_gpio_33v, 0);
728
729 msleep(500);
730 sn65dsi86_power(pdata);
731 sn65dsi86_init_reg(sn65dsi86_client, pdata);
732 msleep(100);
733
734 ret = sn65dsi86_read(sn65dsi86_client, EDP_I2C_ADDR, 0xF6);
735 pr_err("tmj sn65dsi86_resume_init rty ret=0x%x\n", ret);
736
737 retries++;
}

551 void sn65dsi86_init_reg(struct i2c_client *client, struct sn65dsi86_data *pdata)
552 {
553 sn65dsi86_write(client,EDP_I2C_ADDR,0x09,0x00);
554 sn65dsi86_write(client,EDP_I2C_ADDR,0x0A,0x04);//dsiclk 09 06 //refclk 02
555 sn65dsi86_write(client,EDP_I2C_ADDR,0x0D,0x00);
556 sn65dsi86_write(client,EDP_I2C_ADDR,0x10,0x26);
557 sn65dsi86_write(client,EDP_I2C_ADDR,0x11,0x00);
558 sn65dsi86_write(client,EDP_I2C_ADDR,0x12,0x54);//refclk 59 5c
559 sn65dsi86_write(client,EDP_I2C_ADDR,0x13,0x54);//refclk 59 5c
560 sn65dsi86_write(client,EDP_I2C_ADDR,0x20,0x80);//1920
561 sn65dsi86_write(client,EDP_I2C_ADDR,0x21,0x07);//1920
562 sn65dsi86_write(client,EDP_I2C_ADDR,0x22,0x00);
563 sn65dsi86_write(client,EDP_I2C_ADDR,0x23,0x00);
564 sn65dsi86_write(client,EDP_I2C_ADDR,0x24,0x38);//1080
565 sn65dsi86_write(client,EDP_I2C_ADDR,0x25,0x04);//1080
566 sn65dsi86_write(client,EDP_I2C_ADDR,0x2C,0x14);//hsync-len(hpw)=20
567 sn65dsi86_write(client,EDP_I2C_ADDR,0x2D,0x00);//00
568 sn65dsi86_write(client,EDP_I2C_ADDR,0x30,0x08);//vsync-len(vpw)=8
569 sn65dsi86_write(client,EDP_I2C_ADDR,0x31,0x00);//00
570 sn65dsi86_write(client,EDP_I2C_ADDR,0x34,0xA0);//hback-porch(hbp)=160
571 sn65dsi86_write(client,EDP_I2C_ADDR,0x36,0x1B);//vback-porch(vbp)=27
572 sn65dsi86_write(client,EDP_I2C_ADDR,0x38,0x64);//hfront-porch(hfp)=100
573 sn65dsi86_write(client,EDP_I2C_ADDR,0x3A,0x14);//vfront-porch(vfp)=20
574 sn65dsi86_write(client,EDP_I2C_ADDR,0x3C,0x00);//pattern model test open:0x10, close:0x00
575 sn65dsi86_write(client,EDP_I2C_ADDR,0x3D,0x00);
576 sn65dsi86_write(client,EDP_I2C_ADDR,0x3E,0x00);
577 sn65dsi86_write(client,EDP_I2C_ADDR,0x5B,0x00);//00:RGB888, 01:RGB666
578 sn65dsi86_write(client,EDP_I2C_ADDR,0x93,0x24);//DP lanes, 2 lanes--->0x24; 4 lanes--->0x34
579 sn65dsi86_write(client,EDP_I2C_ADDR,0x94,0x80);//DP data rate, 1.62Gbps--->0x20; 2.7Gbps--->0x80
580 sn65dsi86_write(client,EDP_I2C_ADDR,0x5C,0x01);//HPD 0->enable 1->disable
581 sn65dsi86_write(client,EDP_I2C_ADDR,0x5A,0x05);
582 sn65dsi86_write(client,EDP_I2C_ADDR,0x0d,0x01);
583 mdelay(30);
584 sn65dsi86_write(client,EDP_I2C_ADDR,0x64,0x01);
585 sn65dsi86_write(client,EDP_I2C_ADDR,0x74,0x00);
586 sn65dsi86_write(client,EDP_I2C_ADDR,0x75,0x01);
587 sn65dsi86_write(client,EDP_I2C_ADDR,0x76,0x0A);
588 sn65dsi86_write(client,EDP_I2C_ADDR,0x77,0x01);
589 sn65dsi86_write(client,EDP_I2C_ADDR,0x78,0x81);
590 mdelay(20);
591 sn65dsi86_write(client,EDP_I2C_ADDR,0x96,0x01);//01 normal 06 HBR2 mode
592 mdelay(20);
593 sn65dsi86_write(client,EDP_I2C_ADDR,0x5A,0x0D);
594 mdelay(20);
595 sn65dsi86_write(client,EDP_I2C_ADDR,0x5F,0x08);
}

3.Could you tell us how to reproduce this 0xF6 error(the value of 0xF6 is 0x40 when occur error),and use above code to check if it can rescue this error?

Thanks a lot.

Hi, David,

this case is a bit complicated and let me share you more background here. Customer found sometimes the screen has flicker after Power up or wake up, check the F6 register and found DSI timing error,  now we don’t know what caused this error, the workaround solution is reset DSI86 when detect F6 register has error,  and need minimize this detection time, so customer wants to know how fast F6 register can report a timing error. 

Stone

Let's see if we can solver this flicker issue.

1. When the flicker issue happens and if they switch to the DSI86 internal color bar test, does the issue go away?

2. If it does, can they please map HSYNC and VSYNC to the DSI86 GPIO pin using register 0x5F bit [5:4]?

Can they then use a scope to measure the HSYNC and VSYNC frequency?

Thanks

David

Hi David，

got it, unfortunately we can’t measure hsync and vsync as both are grounded. 

Hi Stone,

David is currently on business travel, so his responses may be delayed. If you can try suggestion 1 from David's previous response and share the result, that would be helpful to see.

Best,

Shane

Hi Shane,David,

1. When the flicker issue happens and if they switch to the DSI86 internal color bar test, does the issue go away?

---------I've synchronized internally,we had tried color bar test and found the issue gone away.

Hi Stone,David,

2. If it does, can they please map HSYNC and VSYNC to the DSI86 GPIO pin using register 0x5F bit [5:4]?

-----------How to map it? and this issue reproduce ratio:2/100,this issue isn't reproduced  easily,so can we use other way to reproduce it?thanks

Hi,

If this issue goes away when switching to the color bar, then the root cause could be a timing mismatch between the DSI input and eDP output, One way to verify it is to map HSNYC and VSYNC to GPIO3 by writing 0x10 to bit [5:4] of the register 0x5F. When the error is reproduced and you measured the HSYNC and VSYNC frequency using a scope, you will want to see if the frequency meets the eDP timing requirement.

Thanks

David

Hi David,

From our hardware design,the GPIO3 is connected the ground,so we can't measure the GPIO3.Is there any other way to measure HSYNC and VSYNC?

Thanks

Hi,

Do you have GPIO2 available? You can set the 0x5F register to 0x08 to get VSYNC only on GPIO2. It would help more to check HSYNC as well if there is a rework you could do. 

When the issue is occurring, could you read registers 0xF1 - 0xF8, so we can check the error status registers.

Best regards,
Ikram

Hi IKram,

GPIO2 is pull up to 1.8V from the hardware design,and I'm checking with hardware team whether GPIO2 can be available.

We have read the register 0xF0-0xF8,and find the value of register 0xF6 is 0x40 when the issue is occuring.

Thanks

Hi Haibin,

Could you please ask them to clear the error first by setting 0xFF to the error checking registers.

If they still get erroneous display and read 0xF6 = 0x40, then it could be related to clock being unstable. Are they using a reference external clock?

- Ikram

Hi Ikram,

1.I have checked with our hardware team that the GPIO2 can be available.

2.Do you mean that we set 0xFF to the 0xF6 register to clear the error when the 0xF6 = 0x40?

3.We use external clock.

Thanks

Hi Haibin,

2. Yes, they should write 0xFF to clear the register after initialization, and then they can check the 0xF6 register again during run-time.

Hi Ikram,

I read the datasheet,and find the ACCESS of 0xF6 register is "RCU",what's the "RCU"? Could you please check if we can write the value to 0xF6 register?

Thanks

Hi Haibin,

The "Table 8-18. Bit Field Access Tag Descriptions" mentions the register tags. RCU, would mean:



So, writing 1 to each bit, meaning writing 0xF6 = 0xFF would clear all the errors, till it is updated by hardware.

Best regards,
Ikram

Hi Ikram，

I see.

As you said below:

2. Yes, they should write 0xFF to clear the register after initialization, and then they can check the 0xF6 register again during run-time.

I have a question: Do we write 0xFF to 0xF6 to clear the register after initialization(maybe 0xF6 is normal) or after we find 0xF6 = 0x40?

Thanks 

Hi Haibin,

You could clear after initialization, and check the register. If the error occurs during runtime, you could also clear it again to verify whether it occurs repeatedly.

- Ikram

Hi Ikram，

OK。

But,we can't reproduce this issue easily,Could you have any other way to produce this issue??

Thanks

Hi Haibin,

How often is this issue reproduced?

Best Regards,

Gil Abarca

Hi Gil Abarca，

There is about two devices when we test 100 devices at factory.and the issue will go away if we reboot the device.

Thanks.

Hi Haibin,

Has an ABA test been done?

Best Regards,

Gil Abarca

Hi Gil Abarca，

This issue will go away because we reboot the device,so we can't do swap test.

Do you have any other way to reproduce this issue?

Thanks.

Hi Haibin,

For testing purposes with the boards that show this issue, please add steps to

1. Clear the error checking registers after initialization (write 0xFF)

2. Poll the error checking registers (0xF1 - 0xF8)

3. Check whether the flickering occurs, and find corresponding errors which show on these registers by polling


Questions:

1. How are they finding this flickering and how often does it occur? Are they capturing the flickering with video?

2. When the flickering occurs, which error is found? Is it always the same?

3. Flickering or black screen issues could be due to various reasons, so we would need to find the error in order to potentially reproduce. Is this being tested with video input or internal test pattern? Does the flickering occur with test pattern as well? 


- Ikram

Hi Ikram,

1.We found this issue when we did the system suspend and resume test at factory,and the ration is about 2/100。we captured the video,please check the attachment.

2.When the flickering occures,0xF6 register is error and the value is 0x40.the error is same,but this issue will disppear after we reboot the device.

3.We found this issue when we do suspend and resume of system at factory.

Hi Haibin,

1. Just to confirm, is it always the same error signature? When this occurs, is it always that 0xF6 = 0x40, AND no other errors? And when system is okay, these registers do report other errors?

It would help if they could show that errors are cleared at the start, and register dumps of working and issue cases.

2. With the issue boards (you mentioned 2 out of 100), what is the frequency of this issue?

3. Is it always when the Suspend mode is used? If it's confirmed to occur after suspend is asserted, then de-asserted, then we would have to check the Suspend timing requirements and sequence.

- Ikram

Hi Ikram,

1.Yes,it is always that 0xF6 = 0x40,and no other errors,And when system is ok,this register 0xf6 =0.

2.when we have tested 100 devices,maybe can find 2 deivces have this problem,when this proble occurs,it can recovery after press powerkey to suspend and resume. if we meet this issue,we can't reproduce it .

3."Suspend" means the system enters into sleep.it is diffcult to reproduce this issue.

Thanks

Thank you Haibin, please give me 2-3 days to discuss with the team and get back to you on this.

Best regards,
Ikram

Hi Haibin,

By Suspend and entering into sleep, are they referring to suspend mode of the DP sync? In that case, please ask the customer to follow the sequence described in the "8.3.3.2 Suspend Mode" section and the "SUSPEND Timing Requirements" specifications. Could you please ask the customer to check this and to share what their procedure is for the "sleep" state?

The Loss of sync error showing on 0xF6 can be related to timing issues, such as the DSI86 not being programmed correctly for the DSI source timings. Please also check the Power-Up and Power-Down sequence from the datasheet. 

Best regards,
Ikram