All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: imre.deak@intel.com
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	intel-gfx@lists.freedesktop.org,
	Jani Nikula <jani.nikula@intel.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	linux-pci@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v3 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization
Date: Mon, 01 May 2017 22:36:13 +0200	[thread overview]
Message-ID: <1719094.muzv4MLyNX@aspire.rjw.lan> (raw)
In-Reply-To: <20170430125713.GA29281@ideak-desk.fi.intel.com>

On Sunday, April 30, 2017 03:57:13 PM Imre Deak wrote:
> On Sat, Apr 29, 2017 at 12:21:57PM +0200, Rafael J. Wysocki wrote:
> > On Friday, April 28, 2017 11:33:02 PM Rafael J. Wysocki wrote:
> > > On Friday, April 28, 2017 05:16:02 PM Imre Deak wrote:
> > > > Some drivers - like i915 - may not support the system suspend direct
> > > > complete optimization due to differences in their runtime and system
> > > > suspend sequence. Add a flag that when set resumes the device before
> > > > calling the driver's system suspend handlers which effectively disables
> > > > the optimization.
> > > > 
> > > > Needed by the next patch fixing suspend/resume on i915.
> > > > 
> > > > Suggested by Rafael.
> > > > 
> > > > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > > > Cc: linux-pci@vger.kernel.org
> > > > Cc: stable@vger.kernel.org
> > > > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > > 
> > > Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > 
> > > The reason why the opt-out flag was not added on day one was because we were
> > > not sure whether or not it would be necessary at all.
> > > 
> > > Quite evidently, it is needed.
> > 
> > But that said, it actually can be implemented as a flag in dev_flags too, say
> > PCI_DEV_FLAGS_NEEDS_RESUME, in analogy with PCI_DEV_FLAGS_NO_D3 that's
> > already there.
> > 
> > The struct size would not need to grow then which I guess would be better?
> 
> Hm, both the bit field and the flag would need to increase if running
> out of bits, so what's the difference? (Atm, the struct size wouldn't
> change either way.)

In the bit field case this depends on what the compiler thinks is better to be
entirely precise, so they are not 100% equivalent.

Plus, since there already are things related to PM in dev_flags, why to depart
from that pattern?

Thanks,
Rafael

  reply	other threads:[~2017-05-01 20:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-28 14:16 [PATCH v3 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization Imre Deak
2017-04-28 14:16 ` [PATCH v3 2/2] drm/i915: Prevent the system " Imre Deak
2017-04-28 14:16   ` Imre Deak
2017-04-28 15:39 ` ✓ Fi.CI.BAT: success for series starting with [v3,1/2] PCI / PM: Add needs_resume flag to avoid " Patchwork
2017-04-28 21:33 ` [PATCH v3 1/2] " Rafael J. Wysocki
2017-04-29 10:21   ` Rafael J. Wysocki
2017-04-30 12:57     ` Imre Deak
2017-04-30 12:57       ` Imre Deak
2017-05-01 20:36       ` Rafael J. Wysocki [this message]
2017-05-02  9:05         ` Imre Deak
2017-05-02  9:05           ` Imre Deak
2017-05-02 20:57           ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1719094.muzv4MLyNX@aspire.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=bhelgaas@google.com \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.