* [PATCH] drm/bridge: tc358767: fix max_tu_symbol value @ 2019-09-24 13:17 ` Tomi Valkeinen 2019-09-25 7:37 ` Jyri Sarha 2019-10-10 9:19 ` Andrzej Hajda 0 siblings, 2 replies; 6+ messages in thread From: Tomi Valkeinen @ 2019-09-24 13:17 UTC (permalink / raw) To: dri-devel, Andrey Smirnov, Andrzej Hajda, Jyri Sarha Cc: Tomi Valkeinen, Andrey Gusakov, Laurent Pinchart max_tu_symbol was programmed to TU_SIZE_RECOMMENDED - 1, which is not what the spec says. The spec says: roundup ((input active video bandwidth in bytes/output active video bandwidth in bytes) * tu_size) It is not quite clear what the above means, but calculating max_tu_symbol = (input Bps / output Bps) * tu_size seems to work and fixes the issues seen. This fixes artifacts in some videomodes (e.g. 1024x768@60 on 2-lanes & 1.62Gbps was pretty bad for me). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> --- drivers/gpu/drm/bridge/tc358767.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 13ade28a36a8..b6aa1bd47e1d 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -677,6 +677,8 @@ static int tc_set_video_mode(struct tc_data *tc, int upper_margin = mode->vtotal - mode->vsync_end; int lower_margin = mode->vsync_start - mode->vdisplay; int vsync_len = mode->vsync_end - mode->vsync_start; + u32 bits_per_pixel = 24; + u32 in_bw, out_bw; /* * Recommended maximum number of symbols transferred in a transfer unit: @@ -684,7 +686,10 @@ static int tc_set_video_mode(struct tc_data *tc, * (output active video bandwidth in bytes)) * Must be less than tu_size. */ - max_tu_symbol = TU_SIZE_RECOMMENDED - 1; + + in_bw = mode->clock * bits_per_pixel / 8; + out_bw = tc->link.base.num_lanes * tc->link.base.rate; + max_tu_symbol = DIV_ROUND_UP(in_bw * TU_SIZE_RECOMMENDED, out_bw); dev_dbg(tc->dev, "set mode %dx%d\n", mode->hdisplay, mode->vdisplay); -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] drm/bridge: tc358767: fix max_tu_symbol value 2019-09-24 13:17 ` [PATCH] drm/bridge: tc358767: fix max_tu_symbol value Tomi Valkeinen @ 2019-09-25 7:37 ` Jyri Sarha 2019-10-10 9:19 ` Andrzej Hajda 1 sibling, 0 replies; 6+ messages in thread From: Jyri Sarha @ 2019-09-25 7:37 UTC (permalink / raw) To: Tomi Valkeinen, dri-devel, Andrey Smirnov, Andrzej Hajda Cc: Andrey Gusakov, Laurent Pinchart On 24/09/2019 16:17, Tomi Valkeinen wrote: > max_tu_symbol was programmed to TU_SIZE_RECOMMENDED - 1, which is not > what the spec says. The spec says: > > roundup ((input active video bandwidth in bytes/output active video > bandwidth in bytes) * tu_size) > > It is not quite clear what the above means, but calculating > max_tu_symbol = (input Bps / output Bps) * tu_size seems to work and > fixes the issues seen. > > This fixes artifacts in some videomodes (e.g. 1024x768@60 on 2-lanes & > 1.62Gbps was pretty bad for me). > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> I could reproduce the problem and see that the patch fixes it, so: Tested-by: Jyri Sarha <jsarha@ti.com> > --- > drivers/gpu/drm/bridge/tc358767.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c > index 13ade28a36a8..b6aa1bd47e1d 100644 > --- a/drivers/gpu/drm/bridge/tc358767.c > +++ b/drivers/gpu/drm/bridge/tc358767.c > @@ -677,6 +677,8 @@ static int tc_set_video_mode(struct tc_data *tc, > int upper_margin = mode->vtotal - mode->vsync_end; > int lower_margin = mode->vsync_start - mode->vdisplay; > int vsync_len = mode->vsync_end - mode->vsync_start; > + u32 bits_per_pixel = 24; > + u32 in_bw, out_bw; > > /* > * Recommended maximum number of symbols transferred in a transfer unit: > @@ -684,7 +686,10 @@ static int tc_set_video_mode(struct tc_data *tc, > * (output active video bandwidth in bytes)) > * Must be less than tu_size. > */ > - max_tu_symbol = TU_SIZE_RECOMMENDED - 1; > + > + in_bw = mode->clock * bits_per_pixel / 8; > + out_bw = tc->link.base.num_lanes * tc->link.base.rate; > + max_tu_symbol = DIV_ROUND_UP(in_bw * TU_SIZE_RECOMMENDED, out_bw); > > dev_dbg(tc->dev, "set mode %dx%d\n", > mode->hdisplay, mode->vdisplay); > -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] drm/bridge: tc358767: fix max_tu_symbol value 2019-09-24 13:17 ` [PATCH] drm/bridge: tc358767: fix max_tu_symbol value Tomi Valkeinen 2019-09-25 7:37 ` Jyri Sarha @ 2019-10-10 9:19 ` Andrzej Hajda 2019-10-10 9:25 ` Tomi Valkeinen 1 sibling, 1 reply; 6+ messages in thread From: Andrzej Hajda @ 2019-10-10 9:19 UTC (permalink / raw) To: Tomi Valkeinen, dri-devel, Andrey Smirnov, Jyri Sarha Cc: Andrey Gusakov, Laurent Pinchart On 24.09.2019 15:17, Tomi Valkeinen wrote: > max_tu_symbol was programmed to TU_SIZE_RECOMMENDED - 1, which is not > what the spec says. The spec says: > > roundup ((input active video bandwidth in bytes/output active video > bandwidth in bytes) * tu_size) > > It is not quite clear what the above means, but calculating > max_tu_symbol = (input Bps / output Bps) * tu_size seems to work and > fixes the issues seen. > > This fixes artifacts in some videomodes (e.g. 1024x768@60 on 2-lanes & > 1.62Gbps was pretty bad for me). > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Queued to fixes. Regards Andrzej > --- > drivers/gpu/drm/bridge/tc358767.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c > index 13ade28a36a8..b6aa1bd47e1d 100644 > --- a/drivers/gpu/drm/bridge/tc358767.c > +++ b/drivers/gpu/drm/bridge/tc358767.c > @@ -677,6 +677,8 @@ static int tc_set_video_mode(struct tc_data *tc, > int upper_margin = mode->vtotal - mode->vsync_end; > int lower_margin = mode->vsync_start - mode->vdisplay; > int vsync_len = mode->vsync_end - mode->vsync_start; > + u32 bits_per_pixel = 24; > + u32 in_bw, out_bw; > > /* > * Recommended maximum number of symbols transferred in a transfer unit: > @@ -684,7 +686,10 @@ static int tc_set_video_mode(struct tc_data *tc, > * (output active video bandwidth in bytes)) > * Must be less than tu_size. > */ > - max_tu_symbol = TU_SIZE_RECOMMENDED - 1; > + > + in_bw = mode->clock * bits_per_pixel / 8; > + out_bw = tc->link.base.num_lanes * tc->link.base.rate; > + max_tu_symbol = DIV_ROUND_UP(in_bw * TU_SIZE_RECOMMENDED, out_bw); > > dev_dbg(tc->dev, "set mode %dx%d\n", > mode->hdisplay, mode->vdisplay); _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] drm/bridge: tc358767: fix max_tu_symbol value 2019-10-10 9:19 ` Andrzej Hajda @ 2019-10-10 9:25 ` Tomi Valkeinen 2019-11-06 11:23 ` Tomi Valkeinen 0 siblings, 1 reply; 6+ messages in thread From: Tomi Valkeinen @ 2019-10-10 9:25 UTC (permalink / raw) To: Andrzej Hajda, dri-devel, Andrey Smirnov, Jyri Sarha Cc: Andrey Gusakov, Laurent Pinchart Hi Andrzej, On 10/10/2019 12:19, Andrzej Hajda wrote: > On 24.09.2019 15:17, Tomi Valkeinen wrote: >> max_tu_symbol was programmed to TU_SIZE_RECOMMENDED - 1, which is not >> what the spec says. The spec says: >> >> roundup ((input active video bandwidth in bytes/output active video >> bandwidth in bytes) * tu_size) >> >> It is not quite clear what the above means, but calculating >> max_tu_symbol = (input Bps / output Bps) * tu_size seems to work and >> fixes the issues seen. >> >> This fixes artifacts in some videomodes (e.g. 1024x768@60 on 2-lanes & >> 1.62Gbps was pretty bad for me). >> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> > > > Queued to fixes. If you didn't push this yet, can you drop it for now? This works for all the video modes I have tested, but as I mention above, the calculation is really not quite clear to me. I've sent queries to Toshiba about how to calculate this, and I'm hoping to get a reply soon. If you did push it already, that's fine too, as it does improve things. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] drm/bridge: tc358767: fix max_tu_symbol value @ 2019-11-06 11:23 ` Tomi Valkeinen 0 siblings, 0 replies; 6+ messages in thread From: Tomi Valkeinen @ 2019-11-06 11:23 UTC (permalink / raw) To: Andrzej Hajda, dri-devel, Andrey Smirnov, Jyri Sarha Cc: Andrey Gusakov, Laurent Pinchart On 10/10/2019 12:25, Tomi Valkeinen wrote: > Hi Andrzej, > > On 10/10/2019 12:19, Andrzej Hajda wrote: >> On 24.09.2019 15:17, Tomi Valkeinen wrote: >>> max_tu_symbol was programmed to TU_SIZE_RECOMMENDED - 1, which is not >>> what the spec says. The spec says: >>> >>> roundup ((input active video bandwidth in bytes/output active video >>> bandwidth in bytes) * tu_size) >>> >>> It is not quite clear what the above means, but calculating >>> max_tu_symbol = (input Bps / output Bps) * tu_size seems to work and >>> fixes the issues seen. >>> >>> This fixes artifacts in some videomodes (e.g. 1024x768@60 on 2-lanes & >>> 1.62Gbps was pretty bad for me). >>> >>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> >> >> >> Queued to fixes. > > If you didn't push this yet, can you drop it for now? This works for all > the video modes I have tested, but as I mention above, the calculation > is really not quite clear to me. > > I've sent queries to Toshiba about how to calculate this, and I'm hoping > to get a reply soon. > > If you did push it already, that's fine too, as it does improve things. Just for the record, got a reply from Toshiba, and the patch is correct. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] drm/bridge: tc358767: fix max_tu_symbol value @ 2019-11-06 11:23 ` Tomi Valkeinen 0 siblings, 0 replies; 6+ messages in thread From: Tomi Valkeinen @ 2019-11-06 11:23 UTC (permalink / raw) To: Andrzej Hajda, dri-devel, Andrey Smirnov, Jyri Sarha Cc: Andrey Gusakov, Laurent Pinchart On 10/10/2019 12:25, Tomi Valkeinen wrote: > Hi Andrzej, > > On 10/10/2019 12:19, Andrzej Hajda wrote: >> On 24.09.2019 15:17, Tomi Valkeinen wrote: >>> max_tu_symbol was programmed to TU_SIZE_RECOMMENDED - 1, which is not >>> what the spec says. The spec says: >>> >>> roundup ((input active video bandwidth in bytes/output active video >>> bandwidth in bytes) * tu_size) >>> >>> It is not quite clear what the above means, but calculating >>> max_tu_symbol = (input Bps / output Bps) * tu_size seems to work and >>> fixes the issues seen. >>> >>> This fixes artifacts in some videomodes (e.g. 1024x768@60 on 2-lanes & >>> 1.62Gbps was pretty bad for me). >>> >>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> >> >> >> Queued to fixes. > > If you didn't push this yet, can you drop it for now? This works for all > the video modes I have tested, but as I mention above, the calculation > is really not quite clear to me. > > I've sent queries to Toshiba about how to calculate this, and I'm hoping > to get a reply soon. > > If you did push it already, that's fine too, as it does improve things. Just for the record, got a reply from Toshiba, and the patch is correct. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-11-06 11:23 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CGME20190924131723epcas2p27878e7a6c00a7a077260cf0c5cad5b1a@epcas2p2.samsung.com>
2019-09-24 13:17 ` [PATCH] drm/bridge: tc358767: fix max_tu_symbol value Tomi Valkeinen
2019-09-25 7:37 ` Jyri Sarha
2019-10-10 9:19 ` Andrzej Hajda
2019-10-10 9:25 ` Tomi Valkeinen
2019-11-06 11:23 ` Tomi Valkeinen
2019-11-06 11:23 ` Tomi Valkeinen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.