On Mon, Oct 10, 2016 at 04:13:26PM +0300, Ville Syrjälä wrote:
> On Mon, Oct 10, 2016 at 02:07:16PM +0100, Chris Wilson wrote:
> > On Mon, Oct 10, 2016 at 03:41:04PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 07, 2016 at 08:31:50PM +0100, Chris Wilson wrote:
> > > > During rpm resume we restore
On Mon, Oct 10, 2016 at 02:07:16PM +0100, Chris Wilson wrote:
> On Mon, Oct 10, 2016 at 03:41:04PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 07, 2016 at 08:31:50PM +0100, Chris Wilson wrote:
> > > During rpm resume we restore the fences, but we do not have the
> > > protection of struct_mutex. Th
On Mon, Oct 10, 2016 at 03:41:04PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 07, 2016 at 08:31:50PM +0100, Chris Wilson wrote:
> > During rpm resume we restore the fences, but we do not have the
> > protection of struct_mutex. This rules out updating the activity
> > tracking on the fences, and req
On Fri, Oct 07, 2016 at 08:31:50PM +0100, Chris Wilson wrote:
> During rpm resume we restore the fences, but we do not have the
> protection of struct_mutex. This rules out updating the activity
> tracking on the fences, and requires us to rely on the rpm as the
> serialisation barrier instead.
>
During rpm resume we restore the fences, but we do not have the
protection of struct_mutex. This rules out updating the activity
tracking on the fences, and requires us to rely on the rpm as the
serialisation barrier instead.
[ 350.298052] [drm:intel_runtime_resume [i915]] Resuming device
[ 350.