UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor aawce
Visitor
1,288 Views
Registered: ‎09-13-2018

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

Jump to solution

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

 

 

 

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
1,219 Views
Registered: ‎08-01-2007

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

Jump to 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.

Chris
Video Design Hub | Embedded SW Support

---------------------------------------------------------------------------
Don’t forget to Reply, Kudo, and Accept as Solution.
---------------------------------------------------------------------------
11 Replies
Xilinx Employee
Xilinx Employee
1,264 Views
Registered: ‎08-01-2007

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

Jump to solution

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.

Chris
Video Design Hub | Embedded SW Support

---------------------------------------------------------------------------
Don’t forget to Reply, Kudo, and Accept as Solution.
---------------------------------------------------------------------------
Xilinx Employee
Xilinx Employee
1,249 Views
Registered: ‎03-30-2016

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

Jump to solution

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

 

0 Kudos
Visitor aawce
Visitor
1,229 Views
Registered: ‎09-13-2018

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

Jump to solution

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

0 Kudos
Xilinx Employee
Xilinx Employee
1,220 Views
Registered: ‎08-01-2007

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

Jump to 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.

Chris
Video Design Hub | Embedded SW Support

---------------------------------------------------------------------------
Don’t forget to Reply, Kudo, and Accept as Solution.
---------------------------------------------------------------------------
Visitor aawce
Visitor
1,212 Views
Registered: ‎09-13-2018

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

Jump to solution

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

0 Kudos
Xilinx Employee
Xilinx Employee
1,205 Views
Registered: ‎08-01-2007

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

Jump to solution

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.

Chris
Video Design Hub | Embedded SW Support

---------------------------------------------------------------------------
Don’t forget to Reply, Kudo, and Accept as Solution.
---------------------------------------------------------------------------
Moderator
Moderator
1,125 Views
Registered: ‎11-09-2015

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

Jump to solution

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,


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
Visitor aawce
Visitor
1,054 Views
Registered: ‎09-13-2018

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

Jump to solution

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):

dispctrl-timing-table.png

Xilinx Employee
Xilinx Employee
1,028 Views
Registered: ‎03-30-2016

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

Jump to solution

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.

0 Kudos
Visitor aawce
Visitor
887 Views
Registered: ‎09-13-2018

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

Jump to solution

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

0 Kudos
Moderator
Moderator
850 Views
Registered: ‎11-09-2015

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

Jump to solution

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,

 


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos