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

[Boris Brezillon]

On Mon, 12 Nov 2018 10:20:35 +0000
Dave Stevenson <dave.stevenson at raspberrypi.org> wrote:

> Hi Boris & Eric.
> 
> On Thu, 8 Nov 2018 at 15:12, Eric Anholt <eric at anholt.net> wrote:
> >
> > 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.  
> 
> Great timing as I've hit exactly this when playing back a 1080P video
> on a 1080P screen. The colours were very muted in this situation,
> whilst playing any other resolution or any RGB format was fine. Took
> me a while to realise it wasn't the conversion matrices being set
> incorrectly :-/ Applying this patch sorts the problem.
> This was on the downstream 4.19 kernel, and the v2 of this set
> backported fairly easily. Can I request that for stable? Otherwise we
> can cherry-pick it for downstream.

Sure.