On Friday, December 12th, 2025 at 18:47, Borah, Chaitanya Kumar
<[email protected]> wrote:
> > > +void intel_color_plane_commit_arm(struct intel_dsb *dsb,
> > > + const struct intel_plane_state *plane_state)
> > > +{
> > > + struct intel_display *display = to_intel_display(plane_state);
> > > + struct intel_crtc *crtc = to_intel_crtc(plane_state->uapi.crtc);
> > > +
> > > + if (crtc && intel_color_crtc_has_3dlut(display, crtc->pipe))
> > > + glk_lut_3d_commit(dsb, crtc, !!plane_state->hw.lut_3d);
> > > ^^^^^^^^^^^^
> >
> > And this looks like a pretty major fail. Why is the 3D LUT stored in
> > the plane state when it's a pipe level thing?
>
> With DISPLAY_VER(display) >= 35, 3DLUT can be attached to a plane.
>
> (Bits[23:22] in 3DLUT_CTL). This is the only way we are exposing the HW
> to the userspace right now (through the new plane color pipeline uapi).
> Therefore, it lies in the plane state.
>
> However, there are (soonish)plans to adopt the color pipeline for crtcs
> too. Once that happens, it needs to be handled a bit more carefully. A
> potential approach is to allow userspace to program the block with a
> first come first served semantics and fail the commit if it tries to set
> 3DLUT both on plane and crtc in the same commit.
The plane 3D LUT must only be used before blending. Any pipe-level
post-blending 3D LUT hardware block is not suitable to implement plane
colorops.
