All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Michał Grzelak" <michal.grzelak@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	Nemesa Garg <nemesa.garg@intel.com>
Subject: Re: [PATCH 4/9] drm/i915/casf: Extract scaler_has_casf()
Date: Fri, 27 Mar 2026 12:41:17 +0200	[thread overview]
Message-ID: <acZezWKFo1QwLAci@intel.com> (raw)
In-Reply-To: <7de76a02-bf3e-49e0-52c0-14ef65c879c3@intel.com>

On Fri, Mar 27, 2026 at 11:06:18AM +0100, Michał Grzelak wrote:
> On Fri, 27 Mar 2026, Michał Grzelak wrote:
> > On Thu, 26 Mar 2026, Ville Syrjala wrote:
> >> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> 
> >> Extract a small helper to determine if the scaler supports
> >> the sharpness filter or not.
> >> 
> >> Cc: Nemesa Garg <nemesa.garg@intel.com>
> >> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> ---
> >> drivers/gpu/drm/i915/display/skl_scaler.c | 12 ++++++++----
> >> 1 file changed, 8 insertions(+), 4 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c 
> >> b/drivers/gpu/drm/i915/display/skl_scaler.c
> >> index e9fe5c0bf6ff..525afd736195 100644
> >> --- a/drivers/gpu/drm/i915/display/skl_scaler.c
> >> +++ b/drivers/gpu/drm/i915/display/skl_scaler.c
> >> @@ -323,19 +323,24 @@ int skl_update_scaler_plane(struct intel_crtc_state 
> >> *crtc_state,
> >> 				 need_scaler);
> >> }
> >> 
> >> +static bool scaler_has_casf(struct intel_display *display, int scaler_id)
> >> +{
> >> +	return HAS_CASF(display) && scaler_id == 1;
> >> +}
> >> +
> >> static int intel_allocate_scaler(struct intel_crtc_scaler_state 
> >> *scaler_state,
> >> 				 struct intel_crtc *crtc,
> >> 				 struct intel_plane_state *plane_state,
> >> 				 bool casf_scaler)
> >> {
> >> +	struct intel_display *display = to_intel_display(crtc);
> >> 	int i;
> >>
> >> 	for (i = 0; i < crtc->num_scalers; i++) {
> >> 		if (scaler_state->scalers[i].in_use)
> >> 			continue;
> >> 
> >> -		/* CASF needs second scaler */
> >> -		if (!plane_state && casf_scaler && i != 1)
> >> +		if (casf_scaler && !scaler_has_casf(display, i))
> >> 			continue;
> >>
> >> 		scaler_state->scalers[i].in_use = true;
> >> @@ -982,8 +987,7 @@ void skl_scaler_get_config(struct intel_crtc_state 
> >> *crtc_state)
> >>
> >> 		id = i;
> >> 
> >> -		/* Read CASF regs for second scaler */
> >> -		if (HAS_CASF(display) && id == 1)
> >> +		if (scaler_has_casf(display, i))
> >
> > With that being changed I am wondering if we need int id at all. The
> > only user of it is outside the loop. Since id is set to i on every
> > loop's pass, I guess we can replace it with last value of i. And if
> > crtc->num_scalers == -1, we wouldn't enter the loop anyway, so the id
> > is still set to -1. The only scenario I see where it can break is e.g.
> > when crtc->num_scalers == -2, but I have no clue if it is even possible.
> >
> > To be precise, I am wondering about such change (diff without your change
> > being applied):
> >
> > diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c 
> > b/drivers/gpu/drm/i915/display/skl_scaler.c
> > index 4c4deac7f9c8..78852267e60b 100644
> > --- a/drivers/gpu/drm/i915/display/skl_scaler.c
> > +++ b/drivers/gpu/drm/i915/display/skl_scaler.c
> > @@ -969,7 +969,6 @@ void skl_scaler_get_config(struct intel_crtc_state 
> > *crtc_state)
> >        struct intel_display *display = to_intel_display(crtc_state);
> >        struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> >        struct intel_crtc_scaler_state *scaler_state = 
> > &crtc_state->scaler_state;
> > -       int id = -1;
> >        int i;
> >
> >        /* find scaler attached to this pipe */
> > @@ -980,8 +979,6 @@ void skl_scaler_get_config(struct intel_crtc_state 
> > *crtc_state)
> >                if ((ctl & (PS_SCALER_EN | PS_BINDING_MASK)) != (PS_SCALER_EN 
> > | PS_BINDING_PIPE))
> >                        continue;
> >
> > -               id = i;
> > -
> >                /* Read CASF regs for second scaler */
> >                if (HAS_CASF(display) && id == 1)
> >                        intel_casf_sharpness_get_config(crtc_state);
> > @@ -1003,8 +1000,8 @@ void skl_scaler_get_config(struct intel_crtc_state 
> > *crtc_state)
> >                break;
> >        }
> >
> > -       scaler_state->scaler_id = id;
> > -       if (id >= 0)
> > +       scaler_state->scaler_id = crtc->num_scalers;
> > +       if (scaler_state->scaler_id >= 0)
> >                scaler_state->scaler_users |= (1 << SKL_CRTC_INDEX);
> >        else
> >                scaler_state->scaler_users &= ~(1 << SKL_CRTC_INDEX);
> >
> > But I don't know if the reasoning above makes any sense.
> 
> Now I see that I missed the continue-break magic, so please disregard
> the whole comment.

I think the correct thing is to s/i/scaler_id/ and just move the 
scaler_state->scaler_id and caler_state->scaler_users assignment into
the loop.

Or even better something like this:

skl_pipe_scaler_get_hw_state()
{
	for (scaler_id) {
		ctl = ...
		if (ctl...)
			return scaler_id;
	}

	return -1;
}

skl_scaler_get_config()
{
	scaler_id = skl_pipe_scaler_get_hw_state();
	if (scaler_id < 0)
		return;

	// do the scaler readout
}

Feel free to go at it.

> 
> BR,
> Michał
> 
> >
> > Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
> >
> > BR,
> > Michał
> >
> >> 			intel_casf_sharpness_get_config(crtc_state);
> >>
> >> 		if (!crtc_state->pch_pfit.casf.enable)
> >> -- 
> >> 2.52.0
> >> 
> >> 
> >


-- 
Ville Syrjälä
Intel

  reply	other threads:[~2026-03-27 10:41 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-26 22:31 [PATCH 0/9] drm/i915/casf: Integrate the sharpness filter properly into the scaler code Ville Syrjala
2026-03-26 22:31 ` [PATCH 1/9] drm/i915/casf: s/casf_enable/enable/ Ville Syrjala
2026-03-27  8:41   ` Michał Grzelak
2026-03-26 22:31 ` [PATCH 2/9] drm/i915/casf: Make a proper hw state copy of the sharpness_strength Ville Syrjala
2026-03-27  8:46   ` Michał Grzelak
2026-03-26 22:31 ` [PATCH 3/9] drm/i915/casf: Move the casf state to better place Ville Syrjala
2026-03-27  9:10   ` Michał Grzelak
2026-03-27 10:30     ` Ville Syrjälä
2026-03-28 15:34       ` Michał Grzelak
2026-04-01 10:02         ` Michał Grzelak
2026-03-26 22:31 ` [PATCH 4/9] drm/i915/casf: Extract scaler_has_casf() Ville Syrjala
2026-03-27  9:33   ` Michał Grzelak
2026-03-27 10:06     ` Michał Grzelak
2026-03-27 10:41       ` Ville Syrjälä [this message]
2026-03-28 14:52         ` Michał Grzelak
2026-03-26 22:31 ` [PATCH 5/9] drm/i915/casf: Handle CASF in skl_scaler_get_filter_select() Ville Syrjala
2026-03-27  9:35   ` Michał Grzelak
2026-03-26 22:31 ` [PATCH 6/9] drm/i915/casf: Constify crtc_state Ville Syrjala
2026-03-27  9:44   ` Michał Grzelak
2026-03-26 22:31 ` [PATCH 7/9] drn/i915/casf: Remove redundant argument from intel_casf_filter_lut_load() Ville Syrjala
2026-03-27  9:46   ` Michał Grzelak
2026-03-28 16:04     ` Michał Grzelak
2026-03-26 22:31 ` [PATCH 8/9] drm/i915/pfit: Call intel_pfit_compute_config() unconditionally on (e)DP/HDMI Ville Syrjala
2026-03-27  9:48   ` Michał Grzelak
2026-03-27 10:31     ` Ville Syrjälä
2026-03-26 22:31 ` [PATCH 9/9] drm/i915/casf: Integrate the sharpness filter properly into the scaler code Ville Syrjala
2026-03-31  8:11   ` Garg, Nemesa
2026-03-31  9:40     ` Ville Syrjälä
2026-03-31  9:48   ` Ville Syrjälä
2026-03-31 13:33     ` Garg, Nemesa
2026-03-26 23:26 ` ✓ i915.CI.BAT: success for " Patchwork
2026-03-26 23:27 ` ✓ CI.KUnit: " Patchwork
2026-03-27  0:02 ` ✓ Xe.CI.BAT: " Patchwork
2026-03-27 18:27 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-03-28  0:01 ` ✓ i915.CI.Full: success " Patchwork
2026-03-31 11:40 ` [PATCH 0/9] " Sharma, Swati2
2026-03-31 12:34   ` Ville Syrjälä
2026-04-01  6:02     ` Sharma, Swati2
2026-04-01 11:54       ` Ville Syrjälä
2026-04-02  6:04         ` Sharma, Swati2
2026-04-27 15:31       ` Sharma, Swati2
2026-03-31 16:44 ` Garg, Nemesa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acZezWKFo1QwLAci@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=michal.grzelak@intel.com \
    --cc=nemesa.garg@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.