On 08/02/17 13:25, Laurent Pinchart wrote:
Hi Jyri,
Thank you for the patch.
On Tuesday 07 Feb 2017 16:41:20 Jyri Sarha wrote:
Let's disable all scaling that requires horizontal decimation with higher factor than 4, until we have better estimates of what we can and can not do. However, 1 byte per pixel color format appear to work Ok with all decimation factors.
When decimating horizontally by more that 4 the dss is not able to fetch the data in burst mode. When this happens it is hard to tell if there enough bandwidth. Despite what theory says this appears to be true also for 16-bit color formats.
Signed-off-by: Jyri Sarha jsarha@ti.com
drivers/gpu/drm/omapdrm/dss/dispc.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c b/drivers/gpu/drm/omapdrm/dss/dispc.c index 5554b72..61daef6 100644 --- a/drivers/gpu/drm/omapdrm/dss/dispc.c +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c @@ -2506,6 +2506,25 @@ static int dispc_ovl_calc_scaling_44xx(unsigned long pclk, unsigned long lclk, return -EINVAL; }
- if (*decim_x > 4 && color_mode_to_bpp(color_mode) > 8) {
/*
Let's disable all scaling that requires horizontal
decimation with higher factor than 4, until we have
better estimates of what we can and can not
do. However, 1 byte per pixel color format appear to
work Ok with all decimation factors.
When decimating horizontally by more that 4 the dss
is not able to fetch the data in burst mode. When
this happens it is hard to tell if there enough
bandwidth. Despite what theory says this appears to
be true also for 16-bit color formats.
*/
DSSERR("Not enough bandwidth (x-decimation factor %d > 4)",
*decim_x);
return -EINVAL;
This needs to be validated during the atomic check phase to avoid failures at commit time that are much harder to handle properly.
I agree, but that requires rewriting half of the dispc driver... This and the few earlier ones from Jyri are quick fixes to major issues we've found.
Tomi