Problems with DSI configuration

Alot of the time, those values are given in the manufacturer's documentation. In general for DSI, the porch times have a wide range values which will work. I will typically split however many clock cycles are left from a horizonal or vertical sweep between the two.

Regards,

Matt

Thank you for the answer. Of course LCD manufacturer gives us the parameters' values expressed in the number of pixels, but DSI_VM_TIMING1 and DSI_VM_TIMING3 registers require the same thing described by number of byte clock cycles (TXBYTECLKHS clock). The dispc driver needs the number of pixels and dsi driver needs the number of clock cycles- yet they are hardcoded for blaze tablet lcd and changing them disrupts communication. To be clear- what we are asking for is the formula/dependancies that would enable calculation the number of TXBYTECLKHS cycles basing on the number of pixels in line, horizontal front porch, back porch and puls width.

Best regards, 

Marcin

Can you provide some more specfic information? What is the size of the panel, what refresh rate. How many data lanes are you using? What pixel clk does the manufacturer require?

TXBYTECLKHS is CLKIN4DDR/16.

Matt

Our parameters for DSI (panel-d2l.c). 

WIDTH		1280
HEIGHT		800
PCLK		65183
HFP		282
HSW		6
HBP		32
VFP		15
VSW		8
VBP		15

Because of hardcoding (except for width and height) we used blaze tablet settings. We managed however to enable SoC-D2L-LCD link and view the images from frame buffer on LCD. Nevertheless we faced another problem while using the bridge – its description is presented below.

Our setup :
LCD :    AUO B101EW05 V1 (1280x800@60Hz, RGB666, 3 data + 1 clock LVDS lanes, pixel clock required 64 - 85MHz)
D2L :    TC358765XBG (EXTCLK for the bridge is taken from FREF_CLK4 @38,4MHz - multiplied by bridge internal PLL to apropriate range)
SoC :    OMAP4430 (DSI output: 4 data + 1 clock)

The problem is that in single-link LVDS mode the image on LCD screen indicates huge instability (most of the lines flicker randomly, therefore anything else is barely visible). It is clear and stable only in dual-link LVDS mode (LVDLINK bit set to '1' in LVCFG register). This situation would be acceptable, if there wasn't one fault- the bridge sends 2 pixels during one clock cycle on both links simultaneously, hence the even pixels are missed and the odd ones are doubled on LCD- the effect is that we have only a half of the horizontal resolution.

Unfortunately we couldn't resolve this issue basing on OMAP4 and TC358765XBG documentation. Did you have similar problems with blaze tablet LCD configuration? Do you have any additional documentation for DISPC/DSI/D2L configuration? Does it make any difference for OMAP4 if there is single- or dual-link LVDS mode used in bridge?

Regards,

Marcin 

Marcin,

i've been trying to research and document this info as well. please post any findings you get here!

Dave

Matthew,

for reference we can look at this panel config and pandaboard :

https://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone/blobs/lg-panel-work/drivers/video/omap2/displays/panel-lg4591.c#line44

https://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone/blobs/lg-panel-work/arch/arm/mach-omap2/board-omap4panda.c#line660

Dave