[Intel-gfx] [PATCH 2/4] drm/i915: Introduce a vfunc for platform-specfic MMIO flip code
Damien Lespiau
damien.lespiau at intel.com
Mon Oct 27 15:53:49 CET 2014
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?
--
Damien
More information about the Intel-gfx
mailing list