| Message ID | 20181210161729.29720-8-jagan@amarulasolutions.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
| Series | drm/sun4i: Allwinner A64 MIPI-DSI support | expand |
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. So, just like I asked in your v4, twice, http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/615339.html > Since the documentation is quite sparse, and a MIPI-DSI analyzer is > way too expensive, I'd really like to have at least what each of > these commits are actually fixing, and what symptoms each of these > were causing, and not just "the BSP does it". Maxime
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. > > So, just like I asked in your v4, twice, > > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/615339.html I don't know how can I comment here. Not quite clearly understand your setup, because I have verified 3 different panels from different vendors one with 2-lane, another with 4-lane and one with video format and another one is burstmode format. I even verified with the clock rate and register details. Please suggest me, what can look further on this.
Hi Maxime, On Tue, Dec 11, 2018 at 10:30 PM Jagan Teki <jagan@amarulasolutions.com> 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. > > > > So, just like I asked in your v4, twice, > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/615339.html > > I don't know how can I comment here. Not quite clearly understand your > setup, because I have verified 3 different panels from different > vendors one with 2-lane, another with 4-lane and one with video format > and another one is burstmode format. I even verified with the clock > rate and register details. > > Please suggest me, what can look further on this. From the BSP point-of-view I couldn't find have any difference in start_delay computation between A64, and A33[1]. In fact the driver initialization code is same, here is A64 dsi driver[2]. 1) The only difference that I observe is dsi_gen_wr in BSP [3], the A33 is right shifting message tx length to 0, 8 for first and next packet where as A64 did the same by adding +1 before. Please try to check that If your panel is using long write. and 2) Also every dsi transaction in A33 occupy some delay code in dsi_gen_wr[4], please check the same. and 3) Also If possible please check your panel timings or initialization sequence, because I don't have any panel with A33. 4) other than these I have didn't notice any differences atleast from my knowledge, Please suggest me where can I look further. [1] https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp/de/lowlevel_sun8iw5/de_dsi.c#L813 [2] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c [3] https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp/de/lowlevel_sun8iw5/de_dsi.c#L402 [4] https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp/de/lowlevel_sun8iw5/de_dsi.c#L378
On Tue, Dec 11, 2018 at 10:30:08PM +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. > > > > So, just like I asked in your v4, twice, > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/615339.html > > I don't know how can I comment here. Not quite clearly understand your > setup, because I have verified 3 different panels from different > vendors one with 2-lane, another with 4-lane and one with video format > and another one is burstmode format. I even verified with the clock > rate and register details. > > Please suggest me, what can look further on this. You had a reason to do these patches in the first place, yet you never mention it anywhere in your commit logs. it would address the first part of my comment. And I can help you nail down whatever is going on here, but I would need the panel datasheet for that. It is my second point. Maxime
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? 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. I'm thinking your display should work in the same behavior since the dsi controller making this route. [1] https://patchwork.kernel.org/patch/10680309/
On Fri, Dec 21, 2018 at 2:26 AM Jagan Teki <jagan@amarulasolutions.com> 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? > > 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. > > I'm thinking your display should work in the same behavior since the > dsi controller making this route. Any further comments on this?
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. Maxime
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
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 Maxime
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/erobbing/x300/x300.dtsi#L81 > https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/main.c#L15 > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/drivers/video/msm/mdss/mdss_i2c_interface.c#L152 > matches timings for > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/arm/boot/dts/qcom/dsi-mipi-2-rgb_1280p_video.dtsi#L20 > > https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#L169 Where did you get the timings from then? Maxime
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/erobbing/x300/x300.dtsi#L81 > > https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/main.c#L15 > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/drivers/video/msm/mdss/mdss_i2c_interface.c#L152 > > matches timings for > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/arm/boot/dts/qcom/dsi-mipi-2-rgb_1280p_video.dtsi#L20 > > > > https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#L169 > > 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/drivers/gpu/drm/panel/panel-simple.c?id=7ad8b41cd8f5c2842646d01cdd576663caee04a7 [2] https://patchwork.kernel.org/patch/10680331/ [3] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/lcd/S070WV20_MIPI_RGB.c
On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote: > > > > > > 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/erobbing/x300/x300.dtsi#L81 > > > https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/main.c#L15 > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/drivers/video/msm/mdss/mdss_i2c_interface.c#L152 > > > matches timings for > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/arm/boot/dts/qcom/dsi-mipi-2-rgb_1280p_video.dtsi#L20 > > > > > > https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#L169 > > > > 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/drivers/gpu/drm/panel/panel-simple.c?id=7ad8b41cd8f5c2842646d01cdd576663caee04a7 > [2] https://patchwork.kernel.org/patch/10680331/ > [3] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/lcd/S070WV20_MIPI_RGB.c So you had no reliable source for the timings then? How do you know if all your patches that are timing related are right then? Maxime
On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote: > > > > > > > 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/erobbing/x300/x300.dtsi#L81 > > > > https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/main.c#L15 > > > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/drivers/video/msm/mdss/mdss_i2c_interface.c#L152 > > > > matches timings for > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/arm/boot/dts/qcom/dsi-mipi-2-rgb_1280p_video.dtsi#L20 > > > > > > > > https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#L169 > > > > > > 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/drivers/gpu/drm/panel/panel-simple.c?id=7ad8b41cd8f5c2842646d01cdd576663caee04a7 > > [2] https://patchwork.kernel.org/patch/10680331/ > > [3] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/lcd/S070WV20_MIPI_RGB.c > > So you had no reliable source for the timings then? How do you know if > all your patches that are timing related are right then? I don't understand your point, or may be I confused with many links that I attached in previous mail. 1. Patch for same panel timings are already in Mainline that was tested on one of the board. [1] 2. Driver from AW, released bsp from BPI-M64-bsp [3] Do you think the above two points are not valid sources? Jagan.
On Thu, Jan 17, 2019 at 10:02 AM Jagan Teki <jagan@amarulasolutions.com> wrote: > > On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard > <maxime.ripard@bootlin.com> wrote: > > > > On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote: > > > > > > > > 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/erobbing/x300/x300.dtsi#L81 > > > > > https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/main.c#L15 > > > > > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/drivers/video/msm/mdss/mdss_i2c_interface.c#L152 > > > > > matches timings for > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/arm/boot/dts/qcom/dsi-mipi-2-rgb_1280p_video.dtsi#L20 > > > > > > > > > > https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#L169 > > > > > > > > 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/drivers/gpu/drm/panel/panel-simple.c?id=7ad8b41cd8f5c2842646d01cdd576663caee04a7 > > > [2] https://patchwork.kernel.org/patch/10680331/ > > > [3] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/lcd/S070WV20_MIPI_RGB.c > > > > So you had no reliable source for the timings then? How do you know if > > all your patches that are timing related are right then? > > I don't understand your point, or may be I confused with many links > that I attached in previous mail. > > 1. Patch for same panel timings are already in Mainline that was > tested on one of the board. [1] > 2. Driver from AW, released bsp from BPI-M64-bsp [3] > > Do you think the above two points are not valid sources? fyi, the panel datasheet attached in above mail has timing information.
On Fri, Jan 18, 2019 at 09:14:19PM +0530, Jagan Teki wrote: > On Thu, Jan 17, 2019 at 10:02 AM Jagan Teki <jagan@amarulasolutions.com> wrote: > > > > On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard > > <maxime.ripard@bootlin.com> wrote: > > > > > > On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote: > > > > > > > > > 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/erobbing/x300/x300.dtsi#L81 > > > > > > https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/main.c#L15 > > > > > > > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/drivers/video/msm/mdss/mdss_i2c_interface.c#L152 > > > > > > matches timings for > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/arm/boot/dts/qcom/dsi-mipi-2-rgb_1280p_video.dtsi#L20 > > > > > > > > > > > > https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#L169 > > > > > > > > > > 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/drivers/gpu/drm/panel/panel-simple.c?id=7ad8b41cd8f5c2842646d01cdd576663caee04a7 > > > > [2] https://patchwork.kernel.org/patch/10680331/ > > > > [3] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/lcd/S070WV20_MIPI_RGB.c > > > > > > So you had no reliable source for the timings then? How do you know if > > > all your patches that are timing related are right then? > > > > I don't understand your point, or may be I confused with many links > > that I attached in previous mail. > > > > 1. Patch for same panel timings are already in Mainline that was > > tested on one of the board. [1] > > 2. Driver from AW, released bsp from BPI-M64-bsp [3] > > > > Do you think the above two points are not valid sources? > > fyi, the panel datasheet attached in above mail has timing information. Do you have a page number? maxime
On Thu, Jan 17, 2019 at 10:02:12AM +0530, Jagan Teki wrote: > On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard > <maxime.ripard@bootlin.com> wrote: > > > > On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote: > > > > > > > > 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/erobbing/x300/x300.dtsi#L81 > > > > > https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/main.c#L15 > > > > > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/drivers/video/msm/mdss/mdss_i2c_interface.c#L152 > > > > > matches timings for > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/arm/boot/dts/qcom/dsi-mipi-2-rgb_1280p_video.dtsi#L20 > > > > > > > > > > https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#L169 > > > > > > > > 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/drivers/gpu/drm/panel/panel-simple.c?id=7ad8b41cd8f5c2842646d01cdd576663caee04a7 > > > [2] https://patchwork.kernel.org/patch/10680331/ > > > [3] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/lcd/S070WV20_MIPI_RGB.c > > > > So you had no reliable source for the timings then? How do you know if > > all your patches that are timing related are right then? > > I don't understand your point, or may be I confused with many links > that I attached in previous mail. > > 1. Patch for same panel timings are already in Mainline that was > tested on one of the board. [1] > 2. Driver from AW, released bsp from BPI-M64-bsp [3] > > Do you think the above two points are not valid sources? I'm saying that the only valid source is the datasheet or a DSI analyzer. Maxmie
On Tue, Jan 22, 2019 at 4:41 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > On Fri, Jan 18, 2019 at 09:14:19PM +0530, Jagan Teki wrote: > > On Thu, Jan 17, 2019 at 10:02 AM Jagan Teki <jagan@amarulasolutions.com> wrote: > > > > > > On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard > > > <maxime.ripard@bootlin.com> wrote: > > > > > > > > On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote: > > > > > > > > > > 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/erobbing/x300/x300.dtsi#L81 > > > > > > > https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/main.c#L15 > > > > > > > > > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/drivers/video/msm/mdss/mdss_i2c_interface.c#L152 > > > > > > > matches timings for > > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/arm/boot/dts/qcom/dsi-mipi-2-rgb_1280p_video.dtsi#L20 > > > > > > > > > > > > > > https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#L169 > > > > > > > > > > > > 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/drivers/gpu/drm/panel/panel-simple.c?id=7ad8b41cd8f5c2842646d01cdd576663caee04a7 > > > > > [2] https://patchwork.kernel.org/patch/10680331/ > > > > > [3] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/lcd/S070WV20_MIPI_RGB.c > > > > > > > > So you had no reliable source for the timings then? How do you know if > > > > all your patches that are timing related are right then? > > > > > > I don't understand your point, or may be I confused with many links > > > that I attached in previous mail. > > > > > > 1. Patch for same panel timings are already in Mainline that was > > > tested on one of the board. [1] > > > 2. Driver from AW, released bsp from BPI-M64-bsp [3] > > > > > > Do you think the above two points are not valid sources? > > > > fyi, the panel datasheet attached in above mail has timing information. > > Do you have a page number? Page 4 5.2 Interface Timings
On Tue, Jan 22, 2019 at 05:21:08PM +0530, Jagan Teki wrote: > On Tue, Jan 22, 2019 at 4:41 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > > > On Fri, Jan 18, 2019 at 09:14:19PM +0530, Jagan Teki wrote: > > > On Thu, Jan 17, 2019 at 10:02 AM Jagan Teki <jagan@amarulasolutions.com> wrote: > > > > > > > > On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard > > > > <maxime.ripard@bootlin.com> wrote: > > > > > > > > > > On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote: > > > > > > > > > > > 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/erobbing/x300/x300.dtsi#L81 > > > > > > > > https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/main.c#L15 > > > > > > > > > > > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/drivers/video/msm/mdss/mdss_i2c_interface.c#L152 > > > > > > > > matches timings for > > > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/arm/boot/dts/qcom/dsi-mipi-2-rgb_1280p_video.dtsi#L20 > > > > > > > > > > > > > > > > https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#L169 > > > > > > > > > > > > > > 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/drivers/gpu/drm/panel/panel-simple.c?id=7ad8b41cd8f5c2842646d01cdd576663caee04a7 > > > > > > [2] https://patchwork.kernel.org/patch/10680331/ > > > > > > [3] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/lcd/S070WV20_MIPI_RGB.c > > > > > > > > > > So you had no reliable source for the timings then? How do you know if > > > > > all your patches that are timing related are right then? > > > > > > > > I don't understand your point, or may be I confused with many links > > > > that I attached in previous mail. > > > > > > > > 1. Patch for same panel timings are already in Mainline that was > > > > tested on one of the board. [1] > > > > 2. Driver from AW, released bsp from BPI-M64-bsp [3] > > > > > > > > Do you think the above two points are not valid sources? > > > > > > fyi, the panel datasheet attached in above mail has timing information. > > > > Do you have a page number? > > Page 4 > 5.2 Interface Timings Which datasheet are we talking about here? The only one I've seen is the Sitronix IC's and the page 4 is the summary. Maxime
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index c9b0222ebcd4..cb41fea4f3ee 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -358,7 +358,17 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi, static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi, struct drm_display_mode *mode) { - return mode->vtotal - (mode->vsync_end - mode->vdisplay) + 1; + u32 vfp = mode->vsync_start - mode->vdisplay; + u32 start_delay; + + start_delay = mode->vtotal - vfp + 1; + if (start_delay > mode->vtotal) + start_delay -= mode->vtotal; + + if (!start_delay) + start_delay = 1; + + return start_delay; } static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
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> --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)