Message ID | 20181210161729.29720-8-jagan@amarulasolutions.com |
---|---|
State | New |
Headers | show |
Series |
|
Related | show |
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
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(-)