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

["Sharma, Swati2" <swati2.sharma@intel.com>]

Hi Ville,

On 01-04-2026 05:24 pm, Ville Syrjälä wrote:
> 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)?
Right, when we are trying with different resolutions; though from driver 
different taps are

being selected but from IGT we don't know if its correct or not.

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

You mean, shall i add this test on kms_chamelium_sharpness_filter.c ? 
Currently we have only

basic test enabled there.

>>> 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.
Ack.
>