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

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Cc: ander.conselvan.de.oliveira@intel.com,
	gustavo.padovan@collabora.co.uk, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/4] drm/i915: Introduce a vfunc for platform-specfic MMIO flip code
Date: Mon, 27 Oct 2014 16:47:53 +0200	[thread overview]
Message-ID: <20141027144753.GO4284@intel.com> (raw)
In-Reply-To: <544E58CC.10201@gmail.com>

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@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 :)

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