| Message ID | 1414192274-15933-2-git-send-email-damien.lespiau@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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? Thanks, Daniel > --- > drivers/gpu/drm/i915/i915_drv.h | 1 + > drivers/gpu/drm/i915/intel_display.c | 17 +++++++++++++---- > 2 files changed, 14 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 627b7e7..d979549 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -492,6 +492,7 @@ struct drm_i915_display_funcs { > struct drm_i915_gem_object *obj, > struct intel_engine_cs *ring, > uint32_t flags); > + void (*do_mmio_flip)(struct intel_crtc *crtc); > void (*update_primary_plane)(struct drm_crtc *crtc, > struct drm_framebuffer *fb, > int x, int y); > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > index 5133ef9..07440ad 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -9552,7 +9552,7 @@ static bool use_mmio_flip(struct intel_engine_cs *ring, > return ring != obj->ring; > } > > -static void intel_do_mmio_flip(struct intel_crtc *intel_crtc) > +static void ilk_do_mmio_flip(struct intel_crtc *intel_crtc) > { > struct drm_device *dev = intel_crtc->base.dev; > struct drm_i915_private *dev_priv = dev->dev_private; > @@ -9561,9 +9561,6 @@ static void intel_do_mmio_flip(struct intel_crtc *intel_crtc) > struct drm_i915_gem_object *obj = intel_fb->obj; > u32 dspcntr; > u32 reg; > - > - intel_mark_page_flip_active(intel_crtc); > - > reg = DSPCNTR(intel_crtc->plane); > dspcntr = I915_READ(reg); > > @@ -9579,6 +9576,15 @@ static void intel_do_mmio_flip(struct intel_crtc *intel_crtc) > POSTING_READ(DSPSURF(intel_crtc->plane)); > } > > +static void intel_do_mmio_flip(struct intel_crtc *intel_crtc) > +{ > + struct drm_device *dev = intel_crtc->base.dev; > + struct drm_i915_private *dev_priv = dev->dev_private; > + > + intel_mark_page_flip_active(intel_crtc); > + dev_priv->display.do_mmio_flip(intel_crtc); > +} > + > static int intel_postpone_flip(struct drm_i915_gem_object *obj) > { > struct intel_engine_cs *ring; > @@ -12694,6 +12700,9 @@ static void intel_init_display(struct drm_device *dev) > break; > } > > + if (INTEL_INFO(dev)->gen >= 5) > + dev_priv->display.do_mmio_flip = ilk_do_mmio_flip; > + > intel_panel_init_backlight_funcs(dev); > > mutex_init(&dev_priv->pps_mutex); > -- > 1.8.3.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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.
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. Ville, Ander? -Daniel
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 Cheers, Ander
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 :)
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@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?
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@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
On Tue, Oct 28, 2014 at 08:25:38AM +0100, Daniel Vetter wrote: > 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 ... We totally can!
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 627b7e7..d979549 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -492,6 +492,7 @@ struct drm_i915_display_funcs { struct drm_i915_gem_object *obj, struct intel_engine_cs *ring, uint32_t flags); + void (*do_mmio_flip)(struct intel_crtc *crtc); void (*update_primary_plane)(struct drm_crtc *crtc, struct drm_framebuffer *fb, int x, int y); diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 5133ef9..07440ad 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -9552,7 +9552,7 @@ static bool use_mmio_flip(struct intel_engine_cs *ring, return ring != obj->ring; } -static void intel_do_mmio_flip(struct intel_crtc *intel_crtc) +static void ilk_do_mmio_flip(struct intel_crtc *intel_crtc) { struct drm_device *dev = intel_crtc->base.dev; struct drm_i915_private *dev_priv = dev->dev_private; @@ -9561,9 +9561,6 @@ static void intel_do_mmio_flip(struct intel_crtc *intel_crtc) struct drm_i915_gem_object *obj = intel_fb->obj; u32 dspcntr; u32 reg; - - intel_mark_page_flip_active(intel_crtc); - reg = DSPCNTR(intel_crtc->plane); dspcntr = I915_READ(reg); @@ -9579,6 +9576,15 @@ static void intel_do_mmio_flip(struct intel_crtc *intel_crtc) POSTING_READ(DSPSURF(intel_crtc->plane)); } +static void intel_do_mmio_flip(struct intel_crtc *intel_crtc) +{ + struct drm_device *dev = intel_crtc->base.dev; + struct drm_i915_private *dev_priv = dev->dev_private; + + intel_mark_page_flip_active(intel_crtc); + dev_priv->display.do_mmio_flip(intel_crtc); +} + static int intel_postpone_flip(struct drm_i915_gem_object *obj) { struct intel_engine_cs *ring; @@ -12694,6 +12700,9 @@ static void intel_init_display(struct drm_device *dev) break; } + if (INTEL_INFO(dev)->gen >= 5) + dev_priv->display.do_mmio_flip = ilk_do_mmio_flip; + intel_panel_init_backlight_funcs(dev); mutex_init(&dev_priv->pps_mutex);
SKL will specialize it. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_display.c | 17 +++++++++++++---- 2 files changed, 14 insertions(+), 4 deletions(-)