[PATCH 2/3] drm/vc4: Force ->x_scaling[1] should never be set to VC4_SCALING_NONE

[Eric Anholt]

Boris Brezillon <boris.brezillon at bootlin.com> writes:

> On Thu, 08 Nov 2018 06:52:44 -0800
> Eric Anholt <eric at anholt.net> wrote:
>
>> Boris Brezillon <boris.brezillon at bootlin.com> writes:
>> 
>> > For the YUV conversion to work properly, ->x_scaling[0,1] should never
>> > be set to VC4_SCALING_NONE, but vc4_get_scaling_mode() might return
>> > VC4_SCALING_NONE if the horizontal scaling ratio exactly matches the
>> > horizontal subsampling factor. Add a test to turn VC4_SCALING_NONE
>> > into VC4_SCALING_PPF when that happens.
>> >
>> > Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.")
>> > Signed-off-by: Boris Brezillon <boris.brezillon at bootlin.com>  
>> 
>> I couldn't find a spec justification for this -- did you have a testcase
>> that fails?
>
> Yep. Just set the downscaling ratio to 0.5 with an NV12 format and
> you'll hit the issue (I used modetest to do that):
>
> # modetest -M vc4 -s 29:1920x1080-60  -P 96 at 95:1920x1080*0.5 at NV12

I found that the firmware has a similar behavior to your patch ("if Y is
!unity (x or scaling) and UV is unity, set UV to HPPF/VPPF scaling").
They also select the unity flag after the YUV scaling fixup.

Regardless, if this works, it's got my reviewed-by.

Hopefully we can do some IGT with writeback or chamelium testing all of
the X/Y scaling options with a focus on hitting these 1:1 ratios.  The
state space is big and the docs are just ambiguous enough.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20181108/7843d23c/attachment.sig>