On Thu, Sep 26, 2019 at 07:09:22PM +0300, Ville Syrjälä wrote:
> 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.lankho...@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...

It took a handful extra fixes to get that to boot. But now I at least
get a picture on the screen instead of oopses.

Fixes pushed to the same branch.

Looks like still something going wrong with the cursor ioctl though.

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to