From: "Govindapillai, Vinod" <vinod.govindapillai@intel.com>
To: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"Sousa, Gustavo" <gustavo.sousa@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"jani.nikula@linux.intel.com" <jani.nikula@linux.intel.com>
Cc: "Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com>,
"Coelho, Luciano" <luciano.coelho@intel.com>,
"Atwood, Matthew S" <matthew.s.atwood@intel.com>,
"Chauhan, Shekhar" <shekhar.chauhan@intel.com>,
"Heikkila, Juha-pekka" <juha-pekka.heikkila@intel.com>,
"Roper, Matthew D" <matthew.d.roper@intel.com>,
"Bhadane, Dnyaneshwar" <dnyaneshwar.bhadane@intel.com>,
"sai.teja.pottumuttu@intel.com" <sai.teja.pottumuttu@intel.com>,
"Hogander, Jouni" <jouni.hogander@intel.com>,
"De Marchi, Lucas" <lucas.demarchi@intel.com>,
"Vodapalli, Ravi Kumar" <ravi.kumar.vodapalli@intel.com>
Subject: Re: [PATCH 24/32] drm/i915/xe3p_lpd: Introduce pixel normalizer config support
Date: Mon, 20 Oct 2025 09:35:36 +0000 [thread overview]
Message-ID: <c191b93abc493c57c3340d7c75c53a205aaafcc4.camel@intel.com> (raw)
In-Reply-To: <89c53f433c7cd805e803d941d67b6188db730c01@intel.com>
On Wed, 2025-10-15 at 18:11 +0300, Jani Nikula wrote:
> On Wed, 15 Oct 2025, Gustavo Sousa <gustavo.sousa@intel.com> wrote:
> > From: Vinod Govindapillai <vinod.govindapillai@intel.com>
> >
> > To enable FBC for FP16 formats, we need to enable the pixel
> > normalizer
> > block. Introduce the register definitions and the initial steps for
> > configuring the pixel normalizer block. In this patch the pixel
> > normalizer block is kept as disabled. The follow-up patches will
> > handle
> > configuring the pixel normalizer block for hdr planes for FP16
> > formats.
> >
> > Bspec: 69863
> > Cc: Shekhar Chauhan <shekhar.chauhan@intel.com>
> > Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
> > Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_display_types.h | 3 +++
> > drivers/gpu/drm/i915/display/skl_universal_plane.c | 15
> > +++++++++++++++
> > drivers/gpu/drm/i915/display/skl_universal_plane_regs.h | 11
> > +++++++++++
> > 3 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 87b7cec35320..13652e2996a4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -679,6 +679,9 @@ struct intel_plane_state {
> > /* surface address register */
> > u32 surf;
> >
> > + /* plane pixel normalizer config for Xe3p_LPD+ FBC FP16 */
> > + u32 pixel_normalizer;
>
> I'm pretty strongly of the opinion that software state should not be
> just a 1:1 map of the hardware state. Software state is logical,
> hardware state is physical.
>
> The software state should have logical things like "normalize form
> factor" and "normalize enable", and the hardware then has those in
> some
> register(s) somewhere.
>
> Please let's not start storing software state as register contents.
> The
> registers and their contents *will* change across platforms.
Thanks for the comments. Got your point.
Well.. in this case we are forced to enable the pixel notmalizer with
factor as 1 because of the FBC hw block requirement. So far we don't
have any separate logic to decide on the normalization factor. We hard
code the normalization factor as 1 for display version >= 35 and FP16
format the plane is FBC capable.
So now I am wondering, if we need to maintain a state variable for that
- just directly program register with normalization factor as 1.0 +
enable for FP16 formats?
if (disp >= 35) {
if (fp16 format && FBC capable plane)
intel_de_write_dsb(factor_1_0 | enable)
else
intel_de_write_ds(0)
}
Do you have any suggestion on this?
BR
Vinod
>
> > +
> > /*
> > * scaler_id
> > * = -1 : not using a scaler
> > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > index 9f1111324dab..16a9c141281b 100644
> > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > @@ -893,6 +893,12 @@ static void skl_write_plane_wm(struct
> > intel_dsb *dsb,
> >
> > xe3_plane_min_ddb_reg_val(min_ddb, interim_ddb));
> > }
> >
> > +static void
> > +xe3p_lpd_plane_check_pixel_normalizer(struct intel_plane_state
> > *plane_state)
>
> The function name has nothing to do with what the function does. What
> does "check" mean?
>
> > +{
> > + plane_state->pixel_normalizer = 0;
> > +}
> > +
> > static void
> > skl_plane_disable_arm(struct intel_dsb *dsb,
> > struct intel_plane *plane,
> > @@ -1671,6 +1677,11 @@ icl_plane_update_arm(struct intel_dsb *dsb,
> >
> > icl_plane_update_sel_fetch_arm(dsb, plane, crtc_state,
> > plane_state);
> >
> > + /* Only the HDR planes can have pixel normalizer */
> > + if (DISPLAY_VER(display) >= 35 &&
> > icl_is_hdr_plane(display, plane_id))
> > + intel_de_write_dsb(display, dsb,
> > + PLANE_PIXEL_NORMALIZE(plane-
> > >pipe, plane->id),
> > + plane_state->pixel_normalizer);
>
> This is the place where you'd look at the software state, and
> construct
> what will be written to hardware based on that.
>
> > /*
> > * The control register self-arms if the plane was
> > previously
> > * disabled. Try to make the plane enable atomic by
> > writing
> > @@ -2385,6 +2396,10 @@ static int skl_plane_check(struct
> > intel_crtc_state *crtc_state,
> > plane_state->damage = DRM_RECT_INIT(0, 0, 0, 0);
> > }
> >
> > + /* Pixel normalizer for Xe3p_LPD+ */
> > + if (DISPLAY_VER(display) >= 35 &&
> > icl_is_hdr_plane(display, plane->id))
> > + xe3p_lpd_plane_check_pixel_normalizer(plane_state)
> > ;
> > +
> > plane_state->ctl = skl_plane_ctl(plane_state);
> >
> > if (DISPLAY_VER(display) >= 10)
> > diff --git
> > a/drivers/gpu/drm/i915/display/skl_universal_plane_regs.h
> > b/drivers/gpu/drm/i915/display/skl_universal_plane_regs.h
> > index 84cf565bd653..11c713f9b237 100644
> > --- a/drivers/gpu/drm/i915/display/skl_universal_plane_regs.h
> > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane_regs.h
> > @@ -456,4 +456,15 @@
> > _S
> > EL_FETCH_PLANE_OFFSET_5_A, _SEL_FETCH_PLANE_OFFSET_5_B, \
> > _S
> > EL_FETCH_PLANE_OFFSET_6_A, _SEL_FETCH_PLANE_OFFSET_6_B)
> >
> > +#define _PLANE_PIXEL_NORMALIZE_1_A 0x701a8
> > +#define _PLANE_PIXEL_NORMALIZE_2_A 0x702a8
> > +#define _PLANE_PIXEL_NORMALIZE_1_B 0x711a8
> > +#define _PLANE_PIXEL_NORMALIZE_2_B 0x712a8
> > +#define PLANE_PIXEL_NORMALIZE(pipe,
> > plane) _MMIO_SKL_PLANE((pipe), (plane), \
> > + _P
> > LANE_PIXEL_NORMALIZE_1_A, _PLANE_PIXEL_NORMALIZE_1_B, \
> > + _P
> > LANE_PIXEL_NORMALIZE_2_A, _PLANE_PIXEL_NORMALIZE_2_B)
> > +#define
> > PLANE_PIXEL_NORMALIZE_ENABLE REG_BIT(31)
> > +#define
> > PLANE_PIXEL_NORMALIZE_NORM_FACTOR_MASK REG_GENMASK(15, 0)
> > +#define
> > PLANE_PIXEL_NORMALIZE_NORM_FACTOR(val) REG_FIELD_PREP(PLANE_PIXEL_NORMALIZE_NORM_FACTOR_MASK,(val))
> > +
> > #endif /* __SKL_UNIVERSAL_PLANE_REGS_H__ */
>
next prev parent reply other threads:[~2025-10-20 9:35 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-15 3:15 [PATCH 00/32] drm/i915/display: Add initial support for Xe3p_LPD Gustavo Sousa
2025-10-15 3:15 ` [PATCH 01/32] drm/xe/nvl: Define NVL-S platform Gustavo Sousa
2025-10-15 8:07 ` Shekhar Chauhan
2025-10-15 8:09 ` Shekhar Chauhan
2025-10-15 17:43 ` Lucas De Marchi
2025-10-15 3:15 ` [PATCH 02/32] drm/i915/xe3p_lpd: Add Xe3p_LPD display IP features Gustavo Sousa
2025-10-15 8:11 ` Shekhar Chauhan
2025-10-15 3:15 ` [PATCH 03/32] drm/i915/xe3p_lpd: Drop north display reset option programming Gustavo Sousa
2025-10-15 15:56 ` Matt Atwood
2025-10-15 3:15 ` [PATCH 04/32] drm/i915/display: Use braces for if-ladder in intel_bw_init_hw() Gustavo Sousa
2025-10-15 17:40 ` Matt Roper
2025-10-15 3:15 ` [PATCH 05/32] drm/i915/dram: Add field ecc_impacting_de Gustavo Sousa
2025-10-15 14:46 ` Jani Nikula
2025-10-15 15:54 ` Matt Atwood
2025-10-15 16:13 ` Gustavo Sousa
2025-10-15 16:20 ` Matt Atwood
2025-10-15 3:15 ` [PATCH 06/32] drm/i915/xe3p_lpd: Update bandwidth parameters Gustavo Sousa
2025-10-15 17:48 ` Matt Roper
2025-10-15 18:12 ` Gustavo Sousa
2025-10-15 19:12 ` Matt Roper
2025-10-15 19:51 ` Gustavo Sousa
2025-10-15 3:15 ` [PATCH 07/32] drm/i915/xe3p_lpd: Expand bifield masks dbuf blocks fields Gustavo Sousa
2025-10-15 17:55 ` Matt Roper
2025-10-15 3:15 ` [PATCH 08/32] drm/i915/xe3p_lpd: Support UINT16 formats Gustavo Sousa
2025-10-15 20:23 ` Matt Atwood
2025-10-15 20:55 ` Matt Atwood
2025-10-15 3:15 ` [PATCH 09/32] drm/i915/xe3p_lpd: Extend FBC support to " Gustavo Sousa
2025-10-15 3:15 ` [PATCH 10/32] drm/i915/xe3p_lpd: Horizontal flip support for linear surfaces Gustavo Sousa
2025-10-15 17:58 ` Matt Roper
2025-10-15 3:15 ` [PATCH 11/32] drm/i915/xe3p_lpd: Wait for AUX channel power status Gustavo Sousa
2025-10-15 3:15 ` [PATCH 12/32] drm/i915/xe3p_lpd: Underrun debuggability and error codes/hints Gustavo Sousa
2025-10-15 14:56 ` Jani Nikula
2025-10-15 15:01 ` Ville Syrjälä
2025-10-15 3:15 ` [PATCH 13/32] drm/i915/xe3p_lpd: Remove gamma,csc bottom color checks Gustavo Sousa
2025-10-17 6:02 ` Borah, Chaitanya Kumar
2025-10-15 3:15 ` [PATCH 14/32] drm/i915/xe3p_lpd: Adapt to updates on MBUS_CTL/DBUF_CTL registers Gustavo Sousa
2025-10-15 14:58 ` Jani Nikula
2025-10-16 20:33 ` Gustavo Sousa
2025-10-15 3:15 ` [PATCH 15/32] drm/i915/xe3p_lpd: Always apply level-0 watermark adjustment Gustavo Sousa
2025-10-16 20:53 ` Matt Atwood
2025-10-16 21:03 ` Ville Syrjälä
2025-10-17 18:38 ` Gustavo Sousa
2025-10-15 3:15 ` [PATCH 16/32] drm/i915/xe3p_lpd: Add CDCLK table Gustavo Sousa
2025-10-15 17:39 ` Matt Roper
2025-10-15 17:43 ` Matt Atwood
2025-10-15 3:15 ` [PATCH 17/32] drm/i915/xe3p_lpd: Load DMC firmware Gustavo Sousa
2025-10-15 16:22 ` Matt Atwood
2025-10-15 3:15 ` [PATCH 18/32] drm/i915/xe3p_lpd: Drop support for interlace mode Gustavo Sousa
2025-10-15 4:21 ` Kandpal, Suraj
2025-10-15 3:15 ` [PATCH 19/32] drm/i915/xe3p_lpd: PSR SU minimum lines is 4 Gustavo Sousa
2025-10-15 15:00 ` Jani Nikula
2025-10-15 16:18 ` Gustavo Sousa
2025-10-15 3:15 ` [PATCH 20/32] drm/i915/xe3p_lpd: Enable system caching for FBC Gustavo Sousa
2025-10-15 3:15 ` [PATCH 21/32] drm/i915/xe3p_lpd: Extend Wa_16025573575 Gustavo Sousa
2025-10-15 8:13 ` Shekhar Chauhan
2025-10-15 3:15 ` [PATCH 22/32] drm/i915/xe3p_lpd: Don't allow odd ypan or ysize with semiplanar format Gustavo Sousa
2025-10-16 20:50 ` Matt Atwood
2025-10-15 3:15 ` [PATCH 23/32] drm/i915/xe3p_lpd: Reload DMC MMIO for pipes C and D Gustavo Sousa
2025-10-15 17:47 ` Matt Atwood
2025-10-15 3:15 ` [PATCH 24/32] drm/i915/xe3p_lpd: Introduce pixel normalizer config support Gustavo Sousa
2025-10-15 15:11 ` Jani Nikula
2025-10-20 9:35 ` Govindapillai, Vinod [this message]
2025-10-15 3:15 ` [PATCH 25/32] drm/i915/xe3p_lpd: Add FBC support for FP16 formats Gustavo Sousa
2025-10-15 15:13 ` Jani Nikula
2025-10-15 3:15 ` [PATCH 26/32] drm/i915/xe3p_lpd: Enable pixel normalizer for fp16 formats for FBC Gustavo Sousa
2025-10-15 15:15 ` Jani Nikula
2025-10-15 3:15 ` [PATCH 27/32] drm/i915/vbt: Add fields dedicated_external and dyn_port_over_tc Gustavo Sousa
2025-10-15 15:24 ` Jani Nikula
2025-10-17 19:52 ` Gustavo Sousa
2025-10-20 7:45 ` Jani Nikula
2025-10-20 12:43 ` Gustavo Sousa
2025-10-15 15:29 ` Jani Nikula
2025-10-17 20:20 ` Gustavo Sousa
2025-10-21 8:32 ` Jani Nikula
2025-10-15 3:15 ` [PATCH 28/32] drm/i915/power: Use intel_encoder_is_tc() Gustavo Sousa
2025-10-15 4:20 ` Kandpal, Suraj
2025-10-15 3:15 ` [PATCH 29/32] drm/i915/display: Handle dedicated external ports in intel_encoder_is_tc() Gustavo Sousa
2025-10-15 15:33 ` Jani Nikula
2025-10-15 16:25 ` Gustavo Sousa
2025-10-21 8:36 ` Jani Nikula
2025-10-15 3:15 ` [PATCH 30/32] drm/i915/wm: don't use method1 in Xe3p_LPD onwards Gustavo Sousa
2025-10-15 8:02 ` Shekhar Chauhan
2025-10-21 20:19 ` Gustavo Sousa
2025-10-15 3:15 ` [PATCH 31/32] drm/i915/xe3p_lpd: Extend Type-C flow for static DDI allocation Gustavo Sousa
2025-10-15 3:15 ` [PATCH 32/32] drm/i915/nvls: Add NVL-S display support Gustavo Sousa
2025-10-15 4:30 ` ✓ i915.CI.BAT: success for drm/i915/display: Add initial support for Xe3p_LPD Patchwork
2025-10-15 11:00 ` ✓ i915.CI.Full: " Patchwork
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=c191b93abc493c57c3340d7c75c53a205aaafcc4.camel@intel.com \
--to=vinod.govindapillai@intel.com \
--cc=ankit.k.nautiyal@intel.com \
--cc=dnyaneshwar.bhadane@intel.com \
--cc=gustavo.sousa@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=jouni.hogander@intel.com \
--cc=juha-pekka.heikkila@intel.com \
--cc=lucas.demarchi@intel.com \
--cc=luciano.coelho@intel.com \
--cc=matthew.d.roper@intel.com \
--cc=matthew.s.atwood@intel.com \
--cc=ravi.kumar.vodapalli@intel.com \
--cc=sai.teja.pottumuttu@intel.com \
--cc=shekhar.chauhan@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox