mipi dsi display command queue not emptying - are blanking porch calculations correct?

[aawce]

Hi,

We are having trouble getting the Xilinx DSI core to work with a 2-lane MIPI display that uses the MIPI in-band configuration.  The display supports the DCS short write 1-parameter, and the DSI core supports this, so we are using the DSI core command queue to send the commands.  However, we submit the commands and they do not go out - the queue barely empties, if at all (i.e. after 10sec maybe one command goes out).  And the display won't come on until the config commands go correctly out over MIPI to the display.

So I think maybe our porch/timing settings are incorrect.  I attach a spreadsheet for how I calculated all these based on the display datasheet.  We need a MIPI DSI core expert to review this with us. 

Thanks,

Chris

[chrisar]

I took a look at the information that we have and it looks like you are missing some critical information from Display Datasheet.
It doesn’t contain the following information, which is needed to properly configure the core.

• Video resolution
• Horizontal Active
• Vertical Active
• Horizontal Period
• Vertical Period
• Horizontal Blanking
• Vertical Blanking
• Video clock in MHz

You might be able to get some of this from the Display EDID.

If you have access to the CVT Timing Generator from the VESA group to see if you can generate this information, but typically this is specific to the display and should be provided by the manufacture.

[karnanl]

Hello Chris @aawce

Hello @chrisar

I looked at you spreadsheet calculation. I believe you system usecase is not correct.

If your pixel frequency is 98.304MHz and you want to send RGB888 then you will need (at least)

   98.304 x 24bit = 2359.296 Mbps

Current MIPI DSI line-rate is 500Mbps x 2lanes. So I do not think you have enough bandwith to transfer the video data.

That is why your H-Blanking calculation time is negative. Is it possible to increase the MIPI DSI line rate ?

Please let me know if I have misunderstanding your usecase.

Thanks & regards

Leo

[aawce]

Hi,

Thanks.  In the spreadsheet it should be clear:

Resolution/pixel rate:  480x800  (60fps) =  480*600*60 = 23.04 Mpixel/sec

and 

RGB888 bit rates:  24*23.04 Mbps = 552.960 Mbps / 2lanes = 276.480 bps MIPI line-rate

So we are well within the MIPI line rate requirement, and these values are also confirmed by the display mfg.  (how they test).

However you raise a point about the pixel clock.  I assumed using a higher clock rate is OK (we use 98.304 Mhz vs the 23.04 Mpixel requirement).  Perhaps this is too high of an input pixel clock rate for this configuration?  What input clock rate should we use?  Should we lower the rate to half (i.e. 47Mhz), or do we really need to closer to 23.04MHz?  I don't see any advice in the product guide about this, although the examples suggest you should NOT use an exact clock, but a higher clock rate.  I suppose our rate was too much higher.  Guidance on this specific issue much appreciated.

Also I attach our new spreadsheet using a 47.4MHz pixel clock.  Appreciate any feedback if it is correct.  The display values of 480x800 are in there as input values in the first column.

Thanks,

Chris

[chrisar · Accepted solution]

As @karnanl pointed out, your pixel clock is quite high, which means that you need more bandwidth.  But this probably not correct, as you actual active resolution doesn't need a pixel clock that fast unless your refresh rate is rally high, (higher than the standard 60fps).

For this resolution I would expect the pixel clock to be closer to say 30Mhz.  The reason for this is that the pixel clock is just fast enough to clock the data necessary for the display parameters at the specified frame rate.  These include the active region, plus some blanking around the edges.  Typically the manufacture will provide data on what these values are, either in the display data sheet, or they are embedded in the Display EDID.  For standard displays that follow either VESA or CEA standards, then they typically use the values defined in these standards.

Here is some ideas on things to test if you can't get these values.  Once you have these, then calculating the values for the register should be pretty straight forward as documented in the MIPI DSI TX Subsystem Product Guide PG238.

Known Values:

• Horizontal Active = 480 Pixels
• Vertical Active = 800 Lines

Assumptions: (Reasonable values to try where the data is not provided, but is more likely to work if you can get real values):

• Refresh Rate or Frames Per Second (FPS) = 60Hz
• Horizontal Blanking = 120 Pixels  (Might try reducing this assumption to say 60 if 120 doesn't work.).
• Vertical Blanking = 12 Lines

Calculations based first on known values and assumptions:

• Horizontal Period = Horizontal Active + Horizontal Blanking = 480 + 120 = 600
• Vertical Period = Vertical Active + Vertical Blanking = 800 + 12 = 812
• Video clock in MHz = Horizontal Period * Vertical Period * FPS = 600 * 812 * 60 = 29.232MHz

Based on this these quick numbers, 47MHz, means that your refresh rate is higher than 60MHz.  It's really dependent on the display if it can actually handle this fast of a rate.

---

One other idea that you can try is that the display might actually be 800x400 and you need to transpose the active settings accordingly.  But this is just based on the theory that most displays are wider than they are tall (Landscape) natively and that if you want a display that is taller than it is wide (Portrait) that are really just changing the orientation.

[aawce]

Hi Chris,

Thanks, I think that clarifies it.  So the pixel clock needs to be exact with pixel rate spec, and one adjusts the horizontal and vertical blanking porches to a range that is acceptable to the display.

Note I do have all the specs from the display mfg.  It really is 480x800 60fps.  About the only limitation is the HBP must be < 127.

Thanks,

Chris

[chrisar]

Chris,

Sure, glad to be of help.  You are correct the pixel clock should be as close as possible.  Any variation results in a faster refresh rate.  Like most parameters there is usually a limit on how much you can overclock.  Also as @karnanl pointed out, if you run a faster pixel clock you are generating more data and will need more bandwidth across the MIPI link.

[florentw]

Hi @aawce,

Were the replies from @chrisar and @karnanl enough for you on this?

If your question is answered or your issue is solved, please kindly mark the response which helped as solution (click on "Accept as solution" button below the reply)

If this is not solved/answered, please reply in the topic giving more information on your current status.

Thanks and Regards,

[aawce]

Hi Leo or other experts,

So we still don't have the display working yet, but it's much closer.  Some of the in-band MIPI config commands are working, but not all (will post in separate thread). And pixel data shows up partially correct, but since the config commands don't all work, the display is not setup right so it's expected it doesn't look right.

But for now I wanted to see if you could double-check our final config and see if you see anything wrong.  I attach our spreadsheet calculations, and also the display datasheet and a timing table from the display controller datasheet.   And below is a textual summary.

Note one thing we see is when we read back the total line time, it's off by 1 (i.e. we read 0x6CC instead of 0x6CD).  Other than that it seems all this is correct, but appreciate your expert feedback.

Thanks,

Chris

Inputs:    
MIPI Line Rate (Mbps)    350
MIPI Lanes    2
MIPI Format    RGB888
Bytes per pixel (for above)    3
MIPI Mode    Non-burst w/sync events
Horiz. Resolution    480
Vert. Resolution    800
Hblank (pixels)    120
Vblank (lines)    12
Frame rate (Hz)    60
Calc. Pixel Input Freq. (MHz)    29.232
Actual Pixel Input Freq. (MHz)    30.16  (Via actual  PLL output)

------------ Calculations:

Timing Register-2 (0x54)    HACT (WC)    1440  = 0x5A0    H res + H blank
Timing Register-2 (0x54)    VACT (lines)    800   = 0x320    
    Pixel Period (ns)    33.16        
    Total Pixels per Line    600        
    Total line time (ns)    19894    =0x6CD    Read value in WC

...

    Avail. Blanking time in WC    278        
    HBP/HFP ratio 1:N    5        
Timing Register-3 (0x58)    HFP (WC)    222    DE    
Timing Register-3 (0x58)    HBP (WC)    56    38    Must be <= 126 per display ctrl ds

 Vertical blanking ratios (VSA:VBP:VFP)    1, 1,1      
Timing Register-4 (0x5C)    VSA (Lines)    4    4    
Timing Register-4 (0x5C)    VBP (Lines)    4    4    
Timing Register-4 (0x5C)    VFP (Lines)    4    4

Display controller timing requirements (note: we use 800 line display mode):

[karnanl]

Hello Chris @aawce

I just checked your calculation spreadsheet, so you have lowered your pixel clock.
Now everything seems to be correctly calculated, thanks for sharing this.

Regarding "total line time", 0x6CC should be correct.
If you do not round_up the calculation result, you will get 0x6CC instead of 0x6CD.

Thanks & regards
Leo

--BTW, I just answered your question on DSC command in separate thread.
  I do not know which FAE is responsible for your project, but I think @chrisar can give us some help to involve Marketing.

[aawce]

Hi Leo,

Many thanks and good to know this is correct.

I went back to look at the signaling rates, and I now see that the data lanes seem to never be leaving LP mode - I only see about 10Mbs data, the data lane signal levels are about .8V pk-pk, and the clock lane is inactive.  I'm not sure when this behavior started as I haven't been checking signals for a while, but originally they seemed OK.  I'm now looking into how this could be.  Maybe it's these new settings, or the change to 350Mhz DPHY, or something else.  We do see the in-band commands working per the other thread, but it never seems to be going into high-speed mode.

Appreciate your suggestions where to look or what could cause this new problem.

Thks,

Chris

[florentw]

Hi @aawce,

What is the status on this topic? If your your issue is solved, could you kindly mark the response from @chrisar or @chrisar which helped as solution (when logged in, click on the "accept as solution" button below the reply)

If this is not solved/answered, please reply in the topic giving more information on your current status.

Best Regards,