On Mon, Jul 03, 2017 at 12:30:48PM +0300, Ville Syrjälä wrote:
> I've pretty much decided that I'll be happy if I can solve this for
> future kernels. If someone else wants to try and cook up some kind
> of simple regression fix I don't have any real objections.
Imo fixing the regression isn't the
On Mon, Jul 03, 2017 at 09:55:48AM +0200, Daniel Vetter wrote:
> On Fri, Jun 30, 2017 at 09:46:36PM +0300, Ville Syrjälä wrote:
> > On Fri, Jun 30, 2017 at 08:23:58PM +0200, Daniel Vetter wrote:
> > > On Fri, Jun 30, 2017 at 5:44 PM, Ville Syrjälä
> > > wrote:
> > > >> And if the GEM folks insist
On Fri, Jun 30, 2017 at 09:46:36PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 30, 2017 at 08:23:58PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 30, 2017 at 5:44 PM, Ville Syrjälä
> > wrote:
> > >> And if the GEM folks insist the old behavior can't be restored, then we
> > >> just need a tailor-mad
On Fri, Jun 30, 2017 at 08:23:58PM +0200, Daniel Vetter wrote:
> On Fri, Jun 30, 2017 at 5:44 PM, Ville Syrjälä
> wrote:
> >> And if the GEM folks insist the old behavior can't be restored, then we
> >> just need a tailor-made get-out-of-jail card for gen4 gpu reset somewhere
> >> in i915_sw_fence
On Fri, Jun 30, 2017 at 5:44 PM, Ville Syrjälä
wrote:
>> And if the GEM folks insist the old behavior can't be restored, then we
>> just need a tailor-made get-out-of-jail card for gen4 gpu reset somewhere
>> in i915_sw_fence. Force-completing all render requests atomic updates
>> depend upon is i
On Fri, Jun 30, 2017 at 03:30:33PM +0200, Daniel Vetter wrote:
> On Fri, Jun 30, 2017 at 03:25:58PM +0200, Daniel Vetter wrote:
> > On Thu, Jun 29, 2017 at 04:49:48PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Introduce an rw_semaphore to protect the di
On Fri, Jun 30, 2017 at 03:25:58PM +0200, Daniel Vetter wrote:
> On Thu, Jun 29, 2017 at 04:49:48PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Introduce an rw_semaphore to protect the display commits. All normal
> > commits use down_read() and hence can proceed in
On Thu, Jun 29, 2017 at 04:49:48PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Introduce an rw_semaphore to protect the display commits. All normal
> commits use down_read() and hence can proceed in parallel, but GPU reset
> will use down_write() making sure no other com
Quoting ville.syrj...@linux.intel.com (2017-06-29 14:49:48)
> @@ -2640,15 +2600,13 @@ static void i915_reset_device(struct drm_i915_private
> *dev_priv)
> char *error_event[] = { I915_ERROR_UEVENT "=1", NULL };
> char *reset_event[] = { I915_RESET_UEVENT "=1", NULL };
> cha
From: Ville Syrjälä
Introduce an rw_semaphore to protect the display commits. All normal
commits use down_read() and hence can proceed in parallel, but GPU reset
will use down_write() making sure no other commits are in progress when
we have to pull the plug on the display engine on pre-g4x platf
10 matches
Mail list logo