[PATCH 3/5] drm/armada: Construct a temporary crtc state for plane checks

[Russell King - ARM Linux]

On Fri, Feb 23, 2018 at 05:55:47PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 02, 2018 at 05:10:54PM +0200, Ville Syrjälä wrote:
> > On Fri, Feb 02, 2018 at 04:10:39PM +0200, Ville Syrjälä wrote:
> > > On Tue, Jan 23, 2018 at 09:02:35PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Jan 23, 2018 at 06:42:00PM +0000, Russell King - ARM Linux wrote:
> > > > > On Tue, Jan 23, 2018 at 07:08:55PM +0200, Ville Syrjala wrote:
> > > > > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > > > 
> > > > > > As armada isn't an atomic driver trying to pass a non-populated
> > > > > > crtc->state to drm_atomic_helper_check_plane_state() will end in tears.
> > > > > > Construct a temporary crtc state a la drm_plane_helper_check_update()
> > > > > > and pass that instead. For now we just really need crtc_state->enable
> > > > > > to be there.
> > > > > 
> > > > > Would it be possible to solve this by having the atomic state setup
> > > > > for non-atomic drivers instead, so we're not unwinding some of the
> > > > > work that's already been done to try and convert drivers /to/
> > > > > atomic modeset?
> > > > 
> > > > Dunno. Feels like a wasted effort adding more code that'll just get
> > > > ripped out as soon as the atomic conversion happens. And I'd rather
> > > > not have to worry about potentially stale states hanging around, in
> > > > case you forgot to update something somewhere.
> > > > 
> > > > In any case, I don't think this is unwinding anything. Once you have
> > > > the atomic conversion done sufficiently you can just drop these
> > > > temporary states. We already have the temp state for the plane here
> > > > anyway, and pairing that with a crtc state seems rather logical.
> > > 
> > > So yea or nay on these armada patches?
> > 
> > Also cc:ing Lucas since apparently armada is somehow related to
> > etnaviv...
> > 
> > I have my doubts about the current code working at all (due to
> > the conflict resolution between my refactoring and rmk's work).
> 
> Ping. I'd like to get the final piece merged at some point. armada
> is holding that back.

I'll look at it when I can get my cubox tree in a buildable state for
v4.15 - which is a necessary step to moving forward to anything beyond
that point.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up