[Intel-gfx] [PATCH 16/23] drm/i915: Program planes in bigjoiner mode.

[Ville Syrjälä]

On Thu, Sep 26, 2019 at 06:13:53PM +0200, Maarten Lankhorst wrote:
> Op 26-09-2019 om 18:09 schreef Ville Syrjälä:
> > On Thu, Sep 26, 2019 at 05:50:05PM +0200, Maarten Lankhorst wrote:
> >> Op 26-09-2019 om 15:06 schreef Ville Syrjälä:
> >>> On Fri, Sep 20, 2019 at 01:42:28PM +0200, Maarten Lankhorst wrote:
> >>>> Now that we can program planes from the update_slave callback, and
> >>>> we have done all fb pinning correctly, it's time to program those
> >>>> planes as well.
> >>>>
> >>>> We use the update_slave callback as it allows us to use the
> >>>> separate states correctly.
> >>>>
> >>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> >>>> ---
> >>>>  .../gpu/drm/i915/display/intel_atomic_plane.c | 53 +++++++++++++++++++
> >>>>  .../gpu/drm/i915/display/intel_atomic_plane.h |  2 +
> >>>>  drivers/gpu/drm/i915/display/intel_display.c  |  4 +-
> >>>>  3 files changed, 57 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> >>>> index cc088676f0a2..5db091e4ad6a 100644
> >>>> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> >>>> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> >>>> @@ -366,6 +366,59 @@ void skl_update_planes_on_crtc(struct intel_atomic_state *state,
> >>>>  	}
> >>>>  }
> >>>>  
> >>>> +void icl_update_bigjoiner_planes_on_crtc(struct intel_atomic_state *state,
> >>>> +					 struct intel_crtc *crtc)
> >>> This plane stuff is where things go very much off the rails IMO.
> >>> Planes should not have to know anything about bigjoiner. They should
> >>> just have their appropriate hw state and blindly bash it into the
> >>> hardware.
> >> We already need this for planar slave/master, what's the issue exactly?
> > That already is too fragile. I don't want this spreading all over
> > the driver and coupling everything to the bigjoiner logic.
> >
> > Here's a crude idea how I think we might avoid this:
> > git://github.com/vsyrjala/linux.git uapi_hw_state_split
> >
> > But I didn't dare boot it yet...
> 
> So you basically want the same uapi/hw split for planes as we did with crtc's above?

Yes. And ideally doing the uapi->hw copy in one specific spot as early
as possible, so that the rest of the driver can remain blissfully
ignonarant about all of this.

-- 
Ville Syrjälä
Intel