Re: [PATCH 0/9] drm/i915/casf: Integrate the sharpness filter properly into the scaler code

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Wed, Apr 01, 2026 at 11:32:30AM +0530, Sharma, Swati2 wrote:
> Hi Ville,
> 
> On 31-03-2026 06:04 pm, Ville Syrjälä wrote:
> > On Tue, Mar 31, 2026 at 05:10:42PM +0530, Sharma, Swati2 wrote:
> >> Hi Ville,
> >>
> >> On 27-03-2026 04:01 am, Ville Syrjala wrote:
> >>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>
> >>> The sharpness filter isn't anything special. It's just another
> >>> mode of the pipe scaler, so treat is as such.
> >>>
> >>> This gets rid of tons of special casing all over the place,
> >>> and will allow me to finally land the pending pipe prefill
> >>> series: https://patchwork.freedesktop.org/series/156137/
> >>>
> >>> Note that this will fail some kms_sharpness_filter tests,
> >>> because those tests are basically incorrect. But I couldn't
> >>> decide yet how much of that entire test should be nuked. It
> >>> seems to be doing a *lot* of things, most of which have
> >>> nothing to do with the sharpness filter...
> >> With your series I could see only 1 negative test failing -
> >> invalid-filter-with-scaling-mode-center
> >>
> >> https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163952v1/shards-all.html?testfilter=sharpness
> >>
> >> Is it sharpness and scaling-mode-center can work together? Since
> >> scaler-mode-center doesn't require
> >>
> >> scaler.
> >>
> >> You rightly said, all tests are not related to sharpness but covering
> >> valid scenarios for scaler + sharpness.
> >>
> >> Apart from invalid-filter-with-scaling-mode-center, which other tests do
> >> you think are incorrect? We tried covering all valid scenarios as per HAS.
> > I would probably nuke all these:
> >
> > Nothing to do with the sharpness filter since
> > it's on the pipe scaler, not plane scaler:
> > - filter-modifiers
> > - filter-rotations
> > - filter-formats
> Ack.
> >
> > Doesn't seem to test anything at all:
> > - filter-tap
> 
> Intention of this test is to validate different taps. As per spec,
> 
> different TAPS will be selected based on different resolution selected.
> 
> 
> TAP 3: mode->hdisplay <= 1920 && mode->vdisplay <= 1080
> TAP 5: (mode->hdisplay > 1920 && mode->hdisplay < 3840) && 
> (mode->vdisplay > 1080 && mode->vdisplay < 2160)
> TAP 7: mode->hdisplay >= 3840 && mode->vdisplay >= 2160

AFAIK all it does is try three different modes on the CRTC,
and then nothing. How does that verify anything (other
than the driver didn't explode)?

I suppose it could be verified with the chamelium/writeback
based test. But right now this test doesn't seem to do anything.

> 
> >
> > Maybe a decent idea, but really wasteful to have these kinds
> > of things for every little feature, as opposed to just
> > some generic "did we restore everything after dpms/suspend
> > correctly" test:
> > - filter-suspend
> > - filter-dpms
> 
> True, but we did caught an issue during local testing with this test 
> where we were not able
> 
> to retain sharpness after S/R.

That was likely due to the poor integration with the actual
pfit code. So the sharpness filter needed all kinds of special
cases everywhere in the driver. I'm fixing that now.

These kind of tests burn a lot of CI time. We really don't
want them separately for every little individual feature.

-- 
Ville Syrjälä
Intel