[PATCH 1/2] drm/i915/display: After joiner compute pfit_dst
Garg, Nemesa
nemesa.garg at intel.com
Thu Dec 19 15:13:28 UTC 2024
> -----Original Message-----
> From: Cavitt, Jonathan <jonathan.cavitt at intel.com>
> Sent: Thursday, December 12, 2024 9:24 PM
> To: Garg, Nemesa <nemesa.garg at intel.com>; intel-gfx at lists.freedesktop.org;
> intel-xe at lists.freedesktop.org
> Cc: Garg, Nemesa <nemesa.garg at intel.com>; Cavitt, Jonathan
> <jonathan.cavitt at intel.com>
> Subject: RE: [PATCH 1/2] drm/i915/display: After joiner compute pfit_dst
>
> -----Original Message-----
> From: Intel-gfx <intel-gfx-bounces at lists.freedesktop.org> On Behalf Of
> Nemesa Garg
> Sent: Thursday, December 12, 2024 6:33 AM
> To: intel-gfx at lists.freedesktop.org; intel-xe at lists.freedesktop.org
> Cc: Garg, Nemesa <nemesa.garg at intel.com>
> Subject: [PATCH 1/2] drm/i915/display: After joiner compute pfit_dst
> >
> > In panel fitter/pipe scaler scenario the pch_pfit configuration
> > currently takes place before accounting for pipe_src width for joiner.
> > This causes issue when pch_pfit and joiner get enabled together.So
> > once pipe src is computed adjust the pfit_dst.
> > It can be done by computing per pipe output area first and then and
> > then find the intersection of above area with pfit_dst and then adjust
> > the coordinates.
>
> Maybe reword the commit message as such:
>
> """
> In the panel fitter/pipe scaler scenario, the pch_pfit configuration currently
> takes place before accounting for pipe_src width for joiner. This causes issues
> when pch_pfit and joiner get enabled together. So, once pipe_src is
> computed, adjust the pfit_dst.
> This can be done by first computing per pipe output area, then finding the
> intersection of above area with pfit_dst before finally adjusting the
> coordinates.
> """
>
> The above is just a suggested full revision. The following is all that's strictly
> necessary to fix:
> s/together.So/together. So/
> s/area first and then and then/area first and then/
>
> >
> > Signed-off-by: Nemesa Garg <nemesa.garg at intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 41
> > ++++++++++++++++++++
> > 1 file changed, 41 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 21319f753a34..7be2ea11b8b0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -2563,6 +2563,36 @@ static int intel_crtc_compute_pipe_src(struct
> intel_crtc_state *crtc_state)
> > return 0;
> > }
> >
> > +/*
> > + * The x-coordinate for Primary should be calculated in such a way
> > + * that it remains consistent whether the pipes are joined or not.
> > + * This means we need to consider the full width of the display even
> > + * when the pipes are joined. The x-coordinate for secondaries is 0
> > + * because it starts at the leftmost point of its own display area,
> > + * ensuring that the framebuffer is centered within Pipe B’s
> > +portion
>
> Pipe B’s portion of the overall display? This is probably just a corruption
> in the email due to my mail viewer of choice, but if it's not, this needs to be
> fixed before pushing.
>
> > + * of the overall display.
> > + */
> > +static int intel_crtc_compute_pfit(struct intel_atomic_state *state,
> > + struct intel_crtc_state *crtc_state) {
> > + struct drm_display_mode *mode = &crtc_state->hw.pipe_mode;
> > + struct drm_rect area;
> > +
> > + if (!crtc_state->pch_pfit.enabled)
> > + return 0;
> > +
> > + drm_rect_init(&area, 0, 0,
> > + mode->crtc_hdisplay,
> > + mode->crtc_vdisplay);
> > +
> > + if (!drm_rect_intersect(&crtc_state->pch_pfit.dst, &area))
> > + return -EINVAL;
> > +
> > + drm_rect_translate(&crtc_state->pch_pfit.dst, -area.x1, -area.y1);
> > +
> > + return 0;
> > +}
> > +
> > static int intel_crtc_compute_pipe_mode(struct intel_crtc_state
> > *crtc_state) {
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > @@ -2645,6 +2675,10 @@ static int intel_crtc_compute_config(struct
> intel_atomic_state *state,
> > if (ret)
> > return ret;
> >
> > + ret = intel_crtc_compute_pfit(state, crtc_state);
> > + if (ret)
> > + return ret;
> > +
> > intel_crtc_compute_pixel_rate(crtc_state);
> >
> > if (crtc_state->has_pch_encoder)
> > @@ -4865,6 +4899,13 @@ copy_joiner_crtc_state_modeset(struct
> intel_atomic_state *state,
> > drm_dp_tunnel_ref_get(primary_crtc_state-
> >dp_tunnel_ref.tunnel,
> > &secondary_crtc_state->dp_tunnel_ref);
> >
> > + if (secondary_crtc_state->pch_pfit.enabled) {
> > + struct drm_rect *dst = &secondary_crtc_state->pch_pfit.dst;
> > + int y = dst->y1;
> > +
> > + drm_rect_translate_to(dst, 0, y);
> > + }
> > +
>
> Aside from the above minor grammatical issues:
> Reviewed-by: Jonathan Cavitt <jonathan.cavitt at intel.com> -Jonathan Cavitt
>
Thanks for review. I'll edit the commit message.
Regards,
Nemesa
> > copy_joiner_crtc_state_nomodeset(state, secondary_crtc);
> >
> > secondary_crtc_state->uapi.mode_changed =
> > primary_crtc_state->uapi.mode_changed;
> > --
> > 2.25.1
> >
> >
More information about the Intel-xe
mailing list