On ke, 2015-11-18 at 16:01 +0100, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 04:58:46PM +0200, Imre Deak wrote:
> > On ke, 2015-11-18 at 16:44 +0200, Imre Deak wrote:
> > > On ke, 2015-11-18 at 15:37 +0100, Daniel Vetter wrote:
> > > > On Mon, Nov 09, 2015 at 09:13:45PM +0200, Imre Deak wrote:
On Wed, Nov 18, 2015 at 05:11:03PM +0200, Imre Deak wrote:
> On ke, 2015-11-18 at 16:01 +0100, Daniel Vetter wrote:
> > On Wed, Nov 18, 2015 at 04:58:46PM +0200, Imre Deak wrote:
> > > On ke, 2015-11-18 at 16:44 +0200, Imre Deak wrote:
> > > > On ke, 2015-11-18 at 15:37 +0100, Daniel Vetter wrote:
On ke, 2015-11-18 at 16:47 +0100, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 05:11:03PM +0200, Imre Deak wrote:
> > On ke, 2015-11-18 at 16:01 +0100, Daniel Vetter wrote:
> > > On Wed, Nov 18, 2015 at 04:58:46PM +0200, Imre Deak wrote:
> >
> > Otherwise assert_rpm_wakelock_held() also
On Mon, Nov 09, 2015 at 09:13:45PM +0200, Imre Deak wrote:
> Atm, we assert that the device is not suspended after the point when the
> HW is truly put to a suspended state. This is fine, but we can catch
> more problems if we check the RPM refcount. After that one drops to zero
> we shouldn't
On Wed, Nov 18, 2015 at 04:58:46PM +0200, Imre Deak wrote:
> On ke, 2015-11-18 at 16:44 +0200, Imre Deak wrote:
> > On ke, 2015-11-18 at 15:37 +0100, Daniel Vetter wrote:
> > > On Mon, Nov 09, 2015 at 09:13:45PM +0200, Imre Deak wrote:
> > > > Atm, we assert that the device is not suspended after
On ke, 2015-11-18 at 16:44 +0200, Imre Deak wrote:
> On ke, 2015-11-18 at 15:37 +0100, Daniel Vetter wrote:
> > On Mon, Nov 09, 2015 at 09:13:45PM +0200, Imre Deak wrote:
> > > Atm, we assert that the device is not suspended after the point
> > > when the
> > > HW is truly put to a suspended
On ke, 2015-11-18 at 15:37 +0100, Daniel Vetter wrote:
> On Mon, Nov 09, 2015 at 09:13:45PM +0200, Imre Deak wrote:
> > Atm, we assert that the device is not suspended after the point
> > when the
> > HW is truly put to a suspended state. This is fine, but we can
> > catch
> > more problems if we
On ma, 2015-11-09 at 21:44 +, Chris Wilson wrote:
> On Mon, Nov 09, 2015 at 09:13:45PM +0200, Imre Deak wrote:
> > Atm, we assert that the device is not suspended after the point
> > when the
> > HW is truly put to a suspended state. This is fine, but we can
> > catch
> > more problems if we
Atm, we assert that the device is not suspended after the point when the
HW is truly put to a suspended state. This is fine, but we can catch
more problems if we check the RPM refcount. After that one drops to zero
we shouldn't access the HW any more, although the actual suspend may be
delayed.
On Mon, Nov 09, 2015 at 09:13:45PM +0200, Imre Deak wrote:
> Atm, we assert that the device is not suspended after the point when the
> HW is truly put to a suspended state. This is fine, but we can catch
> more problems if we check the RPM refcount. After that one drops to zero
> we shouldn't
10 matches
Mail list logo
