[PATCH] drm/omapdrm: dispc: Refuse x-decimation above 4 for all but 8-bit formats

[Tomi Valkeinen]

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 at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170208/b5aefbef/attachment.sig>