| Message ID | 1368006922-24957-4-git-send-email-ville.syrjala@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, May 08, 2013 at 12:55:18PM +0300, ville.syrjala@linux.intel.com wrote: > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > plane->enabled is never set, so this code didn't do anything. > > If we end up doing a full modeset, sprites already get disabled. However > if we end up doing a simple set_base, we still need to turn off the sprites > manually. > > And do the same for cursors, since we only want to see the primary plane > for fbdev. > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > --- > drivers/gpu/drm/i915/intel_display.c | 14 ++++++++++++++ > drivers/gpu/drm/i915/intel_drv.h | 1 + > drivers/gpu/drm/i915/intel_fb.c | 8 ++------ > 3 files changed, 17 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > index cfe2803..cef0bff 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -9928,3 +9928,17 @@ intel_display_print_error_state(struct seq_file *m, > } > } > #endif > + > +void intel_disable_cursors_and_sprites(struct drm_device *dev) > +{ > + struct drm_crtc *crtc; > + struct drm_plane *plane; > + > + list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) { > + intel_crtc_dpms_overlay(to_intel_crtc(crtc), false); > + intel_crtc_update_cursor(crtc, false); > + } > + > + list_for_each_entry(plane, &dev->mode_config.plane_list, head) > + intel_plane_disable(plane); > +} > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h > index cd1297e..a4e866a 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -789,5 +789,6 @@ extern bool intel_set_cpu_fifo_underrun_reporting(struct drm_device *dev, > extern bool intel_set_pch_fifo_underrun_reporting(struct drm_device *dev, > enum transcoder pch_transcoder, > bool enable); > +extern void intel_disable_cursors_and_sprites(struct drm_device *dev); > > #endif /* __INTEL_DRV_H__ */ > diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c > index a04481f..57a082c 100644 > --- a/drivers/gpu/drm/i915/intel_fb.c > +++ b/drivers/gpu/drm/i915/intel_fb.c > @@ -281,8 +281,6 @@ void intel_fb_restore_mode(struct drm_device *dev) > { > int ret; > drm_i915_private_t *dev_priv = dev->dev_private; > - struct drm_mode_config *config = &dev->mode_config; > - struct drm_plane *plane; > > if (INTEL_INFO(dev)->num_pipes == 0) > return; > @@ -293,10 +291,8 @@ void intel_fb_restore_mode(struct drm_device *dev) > if (ret) > DRM_DEBUG("failed to restore crtc mode\n"); > > - /* Be sure to shut off any planes that may be active */ > - list_for_each_entry(plane, &config->plane_list, head) > - if (plane->enabled) > - plane->funcs->disable_plane(plane); > + /* in case we ended up doing just set_base above */ > + intel_disable_cursors_and_sprites(dev); Since I did not merge patch 2 I've killed this comment here. -Daniel > > drm_modeset_unlock_all(dev); > } > -- > 1.8.1.5 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, May 08, 2013 at 12:55:18PM +0300, ville.syrjala@linux.intel.com wrote: > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > plane->enabled is never set, so this code didn't do anything. > > If we end up doing a full modeset, sprites already get disabled. However > if we end up doing a simple set_base, we still need to turn off the sprites > manually. > > And do the same for cursors, since we only want to see the primary plane > for fbdev. > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > --- > drivers/gpu/drm/i915/intel_display.c | 14 ++++++++++++++ > drivers/gpu/drm/i915/intel_drv.h | 1 + > drivers/gpu/drm/i915/intel_fb.c | 8 ++------ > 3 files changed, 17 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > index cfe2803..cef0bff 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -9928,3 +9928,17 @@ intel_display_print_error_state(struct seq_file *m, > } > } > #endif > + > +void intel_disable_cursors_and_sprites(struct drm_device *dev) > +{ > + struct drm_crtc *crtc; > + struct drm_plane *plane; > + > + list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) { > + intel_crtc_dpms_overlay(to_intel_crtc(crtc), false); > + intel_crtc_update_cursor(crtc, false); > + } > + > + list_for_each_entry(plane, &dev->mode_config.plane_list, head) > + intel_plane_disable(plane); Somehow my tree doesn't have an intel_plane_disable and while hunting that one down I've started to think a bit more ... Why exactly do we need special driver callbacks for all this? Strictly speaking fbcon is just another kms client, if it needs to dig around in driver details that just means our interfaces are not good enough. I know that there's some historical baggage left around, but for disabling cursors and planes I don't see any need at all: Can't we just loop over all crtcs and disable every cursor and then loop over all sprites and also shut them all down when restoring the fbdev mode? All without any new driver callbacks? It might flicker like mad since we can't do it atomically, but then again this would give us a neat in-kernel user for the atomic modeset stuff right away ... Cheers, Daniel > +} > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h > index cd1297e..a4e866a 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -789,5 +789,6 @@ extern bool intel_set_cpu_fifo_underrun_reporting(struct drm_device *dev, > extern bool intel_set_pch_fifo_underrun_reporting(struct drm_device *dev, > enum transcoder pch_transcoder, > bool enable); > +extern void intel_disable_cursors_and_sprites(struct drm_device *dev); > > #endif /* __INTEL_DRV_H__ */ > diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c > index a04481f..57a082c 100644 > --- a/drivers/gpu/drm/i915/intel_fb.c > +++ b/drivers/gpu/drm/i915/intel_fb.c > @@ -281,8 +281,6 @@ void intel_fb_restore_mode(struct drm_device *dev) > { > int ret; > drm_i915_private_t *dev_priv = dev->dev_private; > - struct drm_mode_config *config = &dev->mode_config; > - struct drm_plane *plane; > > if (INTEL_INFO(dev)->num_pipes == 0) > return; > @@ -293,10 +291,8 @@ void intel_fb_restore_mode(struct drm_device *dev) > if (ret) > DRM_DEBUG("failed to restore crtc mode\n"); > > - /* Be sure to shut off any planes that may be active */ > - list_for_each_entry(plane, &config->plane_list, head) > - if (plane->enabled) > - plane->funcs->disable_plane(plane); > + /* in case we ended up doing just set_base above */ > + intel_disable_cursors_and_sprites(dev); > > drm_modeset_unlock_all(dev); > } > -- > 1.8.1.5 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, May 24, 2013 at 11:35:07AM +0200, Daniel Vetter wrote: > On Wed, May 08, 2013 at 12:55:18PM +0300, ville.syrjala@linux.intel.com wrote: > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > plane->enabled is never set, so this code didn't do anything. > > > > If we end up doing a full modeset, sprites already get disabled. However > > if we end up doing a simple set_base, we still need to turn off the sprites > > manually. > > > > And do the same for cursors, since we only want to see the primary plane > > for fbdev. > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > > --- > > drivers/gpu/drm/i915/intel_display.c | 14 ++++++++++++++ > > drivers/gpu/drm/i915/intel_drv.h | 1 + > > drivers/gpu/drm/i915/intel_fb.c | 8 ++------ > > 3 files changed, 17 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > > index cfe2803..cef0bff 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -9928,3 +9928,17 @@ intel_display_print_error_state(struct seq_file *m, > > } > > } > > #endif > > + > > +void intel_disable_cursors_and_sprites(struct drm_device *dev) > > +{ > > + struct drm_crtc *crtc; > > + struct drm_plane *plane; > > + > > + list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) { > > + intel_crtc_dpms_overlay(to_intel_crtc(crtc), false); > > + intel_crtc_update_cursor(crtc, false); > > + } > > + > > + list_for_each_entry(plane, &dev->mode_config.plane_list, head) > > + intel_plane_disable(plane); > > Somehow my tree doesn't have an intel_plane_disable and while hunting that > one down I've started to think a bit more ... Yeah, that sucker was in the modeset sequence patch set. I should've pulled it out into a separate patch. > Why exactly do we need special driver callbacks for all this? Strictly > speaking fbcon is just another kms client, if it needs to dig around in > driver details that just means our interfaces are not good enough. I know > that there's some historical baggage left around, but for disabling > cursors and planes I don't see any need at all: > > Can't we just loop over all crtcs and disable every cursor and then loop > over all sprites and also shut them all down when restoring the fbdev > mode? All without any new driver callbacks? Some driver might want to use hardware cursor for fb_cursor, also some drivers want to use planes for fbdev scanout, which as you know is something I want for i915 as well in the future. Also there's the whole state mismanagement. We don't track enough of the state in the core to restore stuff properly, so if we disable stuff, we can't re-enable it when switching back to the client using sprites/planes. We could move the plane coordinate tracking to the core easily enough (I even had a patch for that in some old atomic branch). I haven't looked at out current cursor stuff closely enough to figure out if we can do the same there, but currently the cursor state is tracked purely inside the driver. So for the short term I think it's easier to go with the new hook, and let each driver manage their planes/cursors. > > It might flicker like mad since we can't do it atomically, but then again > this would give us a neat in-kernel user for the atomic modeset stuff > right away ... When we get to the atomic stuff, I'd like to keep a full state per client, and then it'd be very easy to just blast the new state in when swithing between clients. > > Cheers, Daniel > > > +} > > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h > > index cd1297e..a4e866a 100644 > > --- a/drivers/gpu/drm/i915/intel_drv.h > > +++ b/drivers/gpu/drm/i915/intel_drv.h > > @@ -789,5 +789,6 @@ extern bool intel_set_cpu_fifo_underrun_reporting(struct drm_device *dev, > > extern bool intel_set_pch_fifo_underrun_reporting(struct drm_device *dev, > > enum transcoder pch_transcoder, > > bool enable); > > +extern void intel_disable_cursors_and_sprites(struct drm_device *dev); > > > > #endif /* __INTEL_DRV_H__ */ > > diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c > > index a04481f..57a082c 100644 > > --- a/drivers/gpu/drm/i915/intel_fb.c > > +++ b/drivers/gpu/drm/i915/intel_fb.c > > @@ -281,8 +281,6 @@ void intel_fb_restore_mode(struct drm_device *dev) > > { > > int ret; > > drm_i915_private_t *dev_priv = dev->dev_private; > > - struct drm_mode_config *config = &dev->mode_config; > > - struct drm_plane *plane; > > > > if (INTEL_INFO(dev)->num_pipes == 0) > > return; > > @@ -293,10 +291,8 @@ void intel_fb_restore_mode(struct drm_device *dev) > > if (ret) > > DRM_DEBUG("failed to restore crtc mode\n"); > > > > - /* Be sure to shut off any planes that may be active */ > > - list_for_each_entry(plane, &config->plane_list, head) > > - if (plane->enabled) > > - plane->funcs->disable_plane(plane); > > + /* in case we ended up doing just set_base above */ > > + intel_disable_cursors_and_sprites(dev); > > > > drm_modeset_unlock_all(dev); > > } > > -- > > 1.8.1.5 > > > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Fri, May 24, 2013 at 11:59 AM, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > >> Why exactly do we need special driver callbacks for all this? Strictly >> speaking fbcon is just another kms client, if it needs to dig around in >> driver details that just means our interfaces are not good enough. I know >> that there's some historical baggage left around, but for disabling >> cursors and planes I don't see any need at all: >> >> Can't we just loop over all crtcs and disable every cursor and then loop >> over all sprites and also shut them all down when restoring the fbdev >> mode? All without any new driver callbacks? > > Some driver might want to use hardware cursor for fb_cursor, also some > drivers want to use planes for fbdev scanout, which as you know is > something I want for i915 as well in the future. I guess the aim is to use the plane scaler and blast the fbcon output over whatever resolution we're currently displaying for e.g. an oops? Even then I don't see how this is any different from Wayland blasting a fullscreen app all over the screen. And if our drm core -> driver interface isn't good enough for fbcon to do that, Wayland won't ever get it right. So all I'm saying is that proper fbcon safe/restore looks like a neat in-kernel test-bed to check interfaces. And we should go with that approach instead of rolling driver hacks. And splattering is_fbcon_crtc checks all over _is_ imo a great hack. > Also there's the whole state mismanagement. We don't track enough of > the state in the core to restore stuff properly, so if we disable > stuff, we can't re-enable it when switching back to the client using > sprites/planes. We could move the plane coordinate tracking to the > core easily enough (I even had a patch for that in some old atomic > branch). I haven't looked at out current cursor stuff closely enough > to figure out if we can do the same there, but currently the cursor > state is tracked purely inside the driver. Atm kms client state management is purely driven by vt switching, and we don't have any guarantees at all that state survives a vt switch. Hence both X and Wayland already fully restore kms state. So in the current model we don't need any state safe/restore in the kernel. Also I'm not sure whether doing that state safe/restore in the kernel is the right approach to handle switching between multiple compositors. I expect that we want a system compositor (for nice transitions) and then probably also we need a new ownership model to ensure that compositors don't have access to each anothers stuff. > So for the short term I think it's easier to go with the new hook, > and let each driver manage their planes/cursors. Since we can't avoid the flickering right now (at least in the set_base fastpath, which should be common) the only thing we need is to loop over all cursors and sprites in fbdev_restore_mode and kill them. X/Wayland will restore already. That's one small patch afaics and so imo the right solution short-term. And long-term we'd have a simple testcase for the atomic modeset interfaces, which might help a bit with the dri-devel bikeshedding. >> It might flicker like mad since we can't do it atomically, but then again >> this would give us a neat in-kernel user for the atomic modeset stuff >> right away ... > > When we get to the atomic stuff, I'd like to keep a full state per > client, and then it'd be very easy to just blast the new state in when > swithing between clients. See above, I don't think we need that. Or at least there's a lot of open questions around it imo. Generally though I really think we should move away from driver interfaces for fbcon. Currently we have - fb allocation - I think that could be done with the dumb ioctl interface instead, or at least it should be possible to do so. Tbh haven't looked into it. - initial mode selection. Can imo only be fixed for real with the check-only mode of the atomic modeset. Till then we have a bit an abstraction leak. - gamma settings. Pure duplication with the kms interfaces, is on my list of things to kill. The _only_ places fbdev support should need driver hooks are imo are if a driver wants extended fbdev emulation (e.g. render accel), and for those cases it can simply overwrite the fbdev vtable with its own functions (which might or might not call down into the fbdev helper). But for basic modeset operations there's imo really no need for special fbdev helper interfaces, our core drm -> driver interface should be good enough. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Fri, May 24, 2013 at 05:14:40PM +0200, Daniel Vetter wrote: > On Fri, May 24, 2013 at 11:59 AM, Ville Syrjälä > <ville.syrjala@linux.intel.com> wrote: > > > >> Why exactly do we need special driver callbacks for all this? Strictly > >> speaking fbcon is just another kms client, if it needs to dig around in > >> driver details that just means our interfaces are not good enough. I know > >> that there's some historical baggage left around, but for disabling > >> cursors and planes I don't see any need at all: > >> > >> Can't we just loop over all crtcs and disable every cursor and then loop > >> over all sprites and also shut them all down when restoring the fbdev > >> mode? All without any new driver callbacks? > > > > Some driver might want to use hardware cursor for fb_cursor, also some > > drivers want to use planes for fbdev scanout, which as you know is > > something I want for i915 as well in the future. > > I guess the aim is to use the plane scaler and blast the fbcon output > over whatever resolution we're currently displaying for e.g. an oops? I was mainly thinking about the current drivers that already depend on planes for scanout. We don't want to go blindly disable all planes in the core since the driver is the one that knows which plane it needs for the crtc scanout duties. > Even then I don't see how this is any different from Wayland blasting > a fullscreen app all over the screen. And if our drm core -> driver > interface isn't good enough for fbcon to do that, Wayland won't ever > get it right. > > So all I'm saying is that proper fbcon safe/restore looks like a neat > in-kernel test-bed to check interfaces. And we should go with that > approach instead of rolling driver hacks. And splattering > is_fbcon_crtc checks all over _is_ imo a great hack. Sure, it's a hack. > > > Also there's the whole state mismanagement. We don't track enough of > > the state in the core to restore stuff properly, so if we disable > > stuff, we can't re-enable it when switching back to the client using > > sprites/planes. We could move the plane coordinate tracking to the > > core easily enough (I even had a patch for that in some old atomic > > branch). I haven't looked at out current cursor stuff closely enough > > to figure out if we can do the same there, but currently the cursor > > state is tracked purely inside the driver. > > Atm kms client state management is purely driven by vt switching, and > we don't have any guarantees at all that state survives a vt switch. > Hence both X and Wayland already fully restore kms state. So in the > current model we don't need any state safe/restore in the kernel. > > Also I'm not sure whether doing that state safe/restore in the kernel > is the right approach to handle switching between multiple > compositors. I expect that we want a system compositor (for nice > transitions) and then probably also we need a new ownership model to > ensure that compositors don't have access to each anothers stuff. Good point. > > > So for the short term I think it's easier to go with the new hook, > > and let each driver manage their planes/cursors. > > Since we can't avoid the flickering right now (at least in the > set_base fastpath, which should be common) the only thing we need is > to loop over all cursors and sprites in fbdev_restore_mode and kill > them. X/Wayland will restore already. That's one small patch afaics > and so imo the right solution short-term. So what about set_par/pan_display? Do you want the fbdev restore thingy to permanently disable the planes/cursors, as in update our s/w state to indicate that they're disabled and hence won't get restored unless someone explicitly re-enables them? Because that's not what the current code does. > > And long-term we'd have a simple testcase for the atomic modeset > interfaces, which might help a bit with the dri-devel bikeshedding. > > >> It might flicker like mad since we can't do it atomically, but then again > >> this would give us a neat in-kernel user for the atomic modeset stuff > >> right away ... > > > > When we get to the atomic stuff, I'd like to keep a full state per > > client, and then it'd be very easy to just blast the new state in when > > swithing between clients. > > See above, I don't think we need that. Or at least there's a lot of > open questions around it imo. > > Generally though I really think we should move away from driver > interfaces for fbcon. Currently we have > - fb allocation - I think that could be done with the dumb ioctl > interface instead, or at least it should be possible to do so. Tbh > haven't looked into it. > - initial mode selection. Can imo only be fixed for real with the > check-only mode of the atomic modeset. Till then we have a bit an > abstraction leak. > - gamma settings. Pure duplication with the kms interfaces, is on my > list of things to kill. > > The _only_ places fbdev support should need driver hooks are imo are > if a driver wants extended fbdev emulation (e.g. render accel), and > for those cases it can simply overwrite the fbdev vtable with its own > functions (which might or might not call down into the fbdev helper). > > But for basic modeset operations there's imo really no need for > special fbdev helper interfaces, our core drm -> driver interface > should be good enough. > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Fri, May 24, 2013 at 7:06 PM, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > On Fri, May 24, 2013 at 05:14:40PM +0200, Daniel Vetter wrote: >> On Fri, May 24, 2013 at 11:59 AM, Ville Syrjälä >> <ville.syrjala@linux.intel.com> wrote: >> > >> >> Why exactly do we need special driver callbacks for all this? Strictly >> >> speaking fbcon is just another kms client, if it needs to dig around in >> >> driver details that just means our interfaces are not good enough. I know >> >> that there's some historical baggage left around, but for disabling >> >> cursors and planes I don't see any need at all: >> >> >> >> Can't we just loop over all crtcs and disable every cursor and then loop >> >> over all sprites and also shut them all down when restoring the fbdev >> >> mode? All without any new driver callbacks? >> > >> > Some driver might want to use hardware cursor for fb_cursor, also some >> > drivers want to use planes for fbdev scanout, which as you know is >> > something I want for i915 as well in the future. >> >> I guess the aim is to use the plane scaler and blast the fbcon output >> over whatever resolution we're currently displaying for e.g. an oops? > > I was mainly thinking about the current drivers that already depend on > planes for scanout. We don't want to go blindly disable all planes in > the core since the driver is the one that knows which plane it needs for > the crtc scanout duties. I guess those currently have a plane reserved for each crtc (or otherwise need to be careful not to glober crtc state if the implicit crtc plane is used as a real kms plane). I guess we want to eventually make that implicit plane explicit, but I guess that can only be done with a feature flag. At least I don't see any way to do this without breaking the established kms abi. Maybe Rob could chime in? [snip] >> > So for the short term I think it's easier to go with the new hook, >> > and let each driver manage their planes/cursors. >> >> Since we can't avoid the flickering right now (at least in the >> set_base fastpath, which should be common) the only thing we need is >> to loop over all cursors and sprites in fbdev_restore_mode and kill >> them. X/Wayland will restore already. That's one small patch afaics >> and so imo the right solution short-term. > > So what about set_par/pan_display? Do you want the fbdev restore thingy > to permanently disable the planes/cursors, as in update our s/w state to > indicate that they're disabled and hence won't get restored unless > someone explicitly re-enables them? Because that's not what the current > code does. Yeah, I think it should just clobber the kms state. Clients will restore everything when vt-switching anyway and if we oops it doesn't matter that much since the system is going down the toilet anyway. That leaves kgdb, but since kgdb is currently broken when the active client uses a sprite (which might cover up kgdb) I don't think it's worse if it's broken in a different fashion afterwards (by killing the sprite state once the client will be restored. And we should be able to fix this by storing the sprite state somewhere ... Maybe we need to add a better getfoo ioctl once we have atomic modeset to better support a system compositor. That way it could reconstruct the kms state and flip clients in userspace. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index cfe2803..cef0bff 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -9928,3 +9928,17 @@ intel_display_print_error_state(struct seq_file *m, } } #endif + +void intel_disable_cursors_and_sprites(struct drm_device *dev) +{ + struct drm_crtc *crtc; + struct drm_plane *plane; + + list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) { + intel_crtc_dpms_overlay(to_intel_crtc(crtc), false); + intel_crtc_update_cursor(crtc, false); + } + + list_for_each_entry(plane, &dev->mode_config.plane_list, head) + intel_plane_disable(plane); +} diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index cd1297e..a4e866a 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -789,5 +789,6 @@ extern bool intel_set_cpu_fifo_underrun_reporting(struct drm_device *dev, extern bool intel_set_pch_fifo_underrun_reporting(struct drm_device *dev, enum transcoder pch_transcoder, bool enable); +extern void intel_disable_cursors_and_sprites(struct drm_device *dev); #endif /* __INTEL_DRV_H__ */ diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c index a04481f..57a082c 100644 --- a/drivers/gpu/drm/i915/intel_fb.c +++ b/drivers/gpu/drm/i915/intel_fb.c @@ -281,8 +281,6 @@ void intel_fb_restore_mode(struct drm_device *dev) { int ret; drm_i915_private_t *dev_priv = dev->dev_private; - struct drm_mode_config *config = &dev->mode_config; - struct drm_plane *plane; if (INTEL_INFO(dev)->num_pipes == 0) return; @@ -293,10 +291,8 @@ void intel_fb_restore_mode(struct drm_device *dev) if (ret) DRM_DEBUG("failed to restore crtc mode\n"); - /* Be sure to shut off any planes that may be active */ - list_for_each_entry(plane, &config->plane_list, head) - if (plane->enabled) - plane->funcs->disable_plane(plane); + /* in case we ended up doing just set_base above */ + intel_disable_cursors_and_sprites(dev); drm_modeset_unlock_all(dev); }