[Intel-gfx] [PATCH 2/4] drm/i915: Introduce a vfunc for platform-specfic MMIO flip code

[Daniel Vetter]

On Mon, Oct 27, 2014 at 02:53:49PM +0000, Damien Lespiau wrote:
> On Mon, Oct 27, 2014 at 04:47:53PM +0200, Ville Syrjälä wrote:
> > On Mon, Oct 27, 2014 at 04:38:04PM +0200, Ander Conselvan de Oliveira wrote:
> > > On 10/27/2014 04:25 PM, Daniel Vetter wrote:
> > > > On Mon, Oct 27, 2014 at 11:08:20AM +0000, Damien Lespiau wrote:
> > > >> On Mon, Oct 27, 2014 at 10:16:06AM +0100, Daniel Vetter wrote:
> > > >>> On Sat, Oct 25, 2014 at 12:11:12AM +0100, Damien Lespiau wrote:
> > > >>>> SKL will specialize it.
> > > >>>>
> > > >>>> Signed-off-by: Damien Lespiau <damien.lespiau at intel.com>
> > > >>>
> > > >>> So with atomic I'd expect that we'd have one giant mmio_flip driver
> > > >>> function and that just calls into the relevant platform/plane update
> > > >>> hooks. Gustavo&Ville are working on that monster.
> > > >>>
> > > >>> Now this here seems to add another incarnation. Can't I have just one
> > > >>> please?
> > > >>
> > > >> I'd be happy to have that, but are we talking before 3.19? SKL doesn't
> > > >> flip at all without MMIO flips, so we'll need to have of of those by
> > > >> 3.19.
> > > >
> > > > It shouldn't be a lot of fuzz really since it will more or less amount to
> > > > calling the same low-level plane update functions for all of them. Or I'm
> > > > confused about all this. Also I think Ander is starting to rework
> > > > mmio_flip this week.
> > > 
> > > I did send a patch [1] related to mmio flip last week, but I wasn't 
> > > aware of the grand plan for that "giant mmio_flip driver function". I'm 
> > > learning the details as I go, so I should probably look into that, but 
> > > at least for now I wasn't planning to much more than that patch.
> > > 
> > > Paulo gave me some comments (off-list, due to the mailman issues) that I 
> > > plan to fix and then send a v2.
> > > 
> > >   [1] 
> > > http://lists.freedesktop.org/archives/intel-gfx/2014-October/053792.html
> > 
> > Yeah so this a step in the direction Daniel mentioned. The other part is
> > making the primary plane update func more sane, and split it to
> > check/commit phases, which is what Gustavo is working on.
> > 
> > Once all that's done we can add the vblank evade to the primary plane
> > update commit hook. And then there shouldn't be much difference in the mmio
> > flip vs. plane update anymore so we should be able to just call the primary
> > plane funcs for mmio flip, with the commit done from the wq.
> > 
> > And the end result is then quite close to what we want for nuclear flip.
> > Then we "just" expand it to cover multiple planes in one go and we're
> > almost there :)
> 
> Sounds like a wonderful future, but in the meantime, it'd be nice to
> have flips working on SKL. Maybe with a comment on top of the vfunc
> explaning it should be removed once we have MMIO updates for flips built
> on top the plane vfuncs?

Can't we copypaste the mmioflip for skl for now with a big comment stating
that this should all disappear? The current mmio flip is for gen4+ too
after all ...

I don't some temporary hacks too much, but going overboard with the design
with vfuncs and stuff seems like too much.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch