On Sat, Jan 12, 2019 at 10:13 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Wed, Jan 09, 2019 at 06:57:57PM +0530, Jagan Teki wrote:
On Tue, Jan 8, 2019 at 2:28 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Mon, Jan 07, 2019 at 08:48:21PM +0530, Jagan Teki wrote:
On Mon, Jan 7, 2019 at 7:42 PM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Fri, Dec 21, 2018 at 02:26:11AM +0530, Jagan Teki wrote:
On Tue, Dec 11, 2018 at 10:19 PM Maxime Ripard maxime.ripard@bootlin.com wrote: > > On Mon, Dec 10, 2018 at 09:47:19PM +0530, Jagan Teki wrote: > > Video start delay can be computed by subtracting total vertical > > timing with front porch timing and with adding 1 delay line for TCON. > > > > BSP code form BPI-M64-bsp is computing video start delay as > > (from linux-sunxi/ > > drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c) > > > > u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp; > > => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp) > > => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y) > > - panel->lcd_y - (panel->lcd_vbp) > > => timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y > > - panel->lcd_y - panel->lcd_vbp > > => timmings->ver_front_porch > > > > So, update the start delay computation accordingly. > > > > Signed-off-by: Jagan Teki jagan@amarulasolutions.com > > Even though it's a bit better now on my A33 board and I don't have the > white stripes on the bottom of the display, there's still some > flickering with your patches applied. > > Bisecting it seems to point at that patch, but reverting it doesn't > make the issue go away, so it's not really clear which one exactly is > at fault.
Is reverting this patch, work fine or not?
As I was saying, it doesn't.
This patch is trying to make use of front porch instead of existing back porch to compute the delay. Since we revert the VBP fix patch[1] to assume VBP as VFP value look like your setup would also require to revert this change. But as per BSP or drm_mode details all of my displays even work with and w/o reverting these two.
Again, I cannot help you without the datasheet for the panels you're trying to submit.
The panel bound with Sitronix ST7701 IC http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf
It's the controller, not the panel
As I said before, the datasheet of that panel doesn't have any information except electrical characteristics and used IC which is ST7701.
I have one more panel, which is from Bananapi, S070WV20-CT16 ICN621 please find the attachment for the same.
Here is some more details of the same.
https://github.com/yesnoandor/x300/blob/master/kernel/arch/arm/boot/dts/erob... https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/...
https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/driver... matches timings for https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/a...
https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#...
Where did you get the timings from then?
You mean drm_mode timings, the same panel with RGB available in panel-simple[1], and dsi driver in Mailing list[2] and actual DSI sequence commands from BSP[3]
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/d... [2] https://patchwork.kernel.org/patch/10680331/ [3] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/...