Move the documentation into Documentation/gpu, link it up and pull in
the kernel doc.

No actual text changes except that I did polish the kerneldoc a bit,
especially for vga_client_register().

v2: Remove some rst from vga-switcheroo.rst that I don't understand,
but which seems to be the reason why the new vgaarbiter.rst sometimes
drops out of the sidebar index.

v3: Drop one level of headings and clarify the vgaarb one a bit.

v4: Fix some typos (Sean).

Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471034937-651-20-git-send-email-daniel.vetter@ffwll.ch

Fix up formatting glitches remaining after the automatic rst conversion.

Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/3a369602ae35fdbf5e4a12f7e172088c89fa27bb.1468225027.git.lukas@wunner.de

Daniel Vetter pointed out that vga_switcheroo_client_probe_defer() could
be needed by audio clients as well. To avoid mistakes when someone adds
conditions for these in the future, constrain the single existing
condition to VGA clients by checking for PCI_BASE_CLASS_DISPLAY. This
encompasses both PCI_CLASS_DISPLAY_VGA as well as PCI_CLASS_DISPLAY_3D,
which is used by some Nvidia Optimus GPUs.

Any future checks for audio clients should then be constrained to
PCI_BASE_CLASS_MULTIMEDIA.

v6: Spun out from commit introducing vga_switcheroo_client_probe_defer()
    to keep it a pure refactoring change. (Emil Velikov, Jani Nikula)

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/358d58490eb9dda5f270d844b0dce511a2a20828.1464685538.git.lukas@wunner.de

So far we've got one condition when DRM drivers need to defer probing
on a dual GPU system and it's coded separately into each of the relevant
drivers. As suggested by Daniel Vetter, deduplicate that code in the
drivers and move it to a new vga_switcheroo helper. This yields better
encapsulation of concepts and lets us add further checks in a central
place. (The existing check pertains to pre-retina MacBook Pros and an
additional check is expected to be needed for retinas.)

One might be tempted to check deferred probing conditions in
vga_switcheroo_register_client(), but this is usually called fairly late
during driver load. The GPU is fully brought up and ready for switching
at that point. On boot the ->probe hook is potentially called dozens of
times until it finally succeeds, and each time we'd repeat bringup and
teardown of the GPU, lengthening boot time considerably and cluttering
logfiles. A separate helper is therefore needed which can be called
right at the beginning of the ->probe hook.

Note that amdgpu currently does not call this helper as the AMD GPUs
built into MacBook Pros are only supported by radeon so far.

v2: This helper could eventually be used by audio clients as well,
    so rephrase kerneldoc to refer to "client" instead of "GPU"
    and move the single existing check in an if block specific
    to PCI_CLASS_DISPLAY_VGA devices. Move documentation on
    that check from kerneldoc to a comment. (Daniel Vetter)

v3: Mandate in kerneldoc that registration of client shall only
    happen after calling this helper. (Daniel Vetter)

v4: Rebase on 412c8f7d ("drm/radeon: Return -EPROBE_DEFER when
    amdkfd not loaded")

v5: Some Optimus GPUs use PCI_CLASS_DISPLAY_3D, make sure those are
    matched as well. (Emil Velikov)

v6: The if-condition referring to PCI_BASE_CLASS_DISPLAY may be
    considered a functional change. Move to a separate commit to
    keep this a pure refactoring change. (Emil Velikov, Jani Nikula)

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/575885fd440c2b13c3f19ddf44360cfbbff35f50.1464685538.git.lukas@wunner.de

Originally by Seth Forshee <seth.forshee@canonical.com>, 2012-10-04:
    During graphics driver initialization it's useful to be able to mux
    only the DDC to the inactive client in order to read the EDID. Add
    a switch_ddc callback to allow capable handlers to provide this
    functionality, and add vga_switcheroo_switch_ddc() to allow DRM
    to mux only the DDC.

Modified by Dave Airlie <airlied@gmail.com>, 2012-12-22:
    I can't figure out why I didn't like this, but I rewrote this [...]
    to lock/unlock the ddc lines [...]. I think I'd prefer something
    like that otherwise the interface got really ugly.

Modified by Lukas Wunner <lukas@wunner.de>, 2015-04 - 2015-10:
    Change semantics of ->switch_ddc handler callback to return previous
    DDC owner. Original version tried to determine previous DDC owner
    with find_active_client() but this fails if the inactive client
    registers before the active client.

    Don't lock vgasr_mutex in _lock_ddc() / _unlock_ddc(), it can cause
    deadlocks because (a) during switch (with vgasr_mutex already held),
    GPU is woken and probes its outputs, tries to re-acquire vgasr_mutex
    to lock DDC lines; (b) Likewise during switch, GPU is suspended and
    calls cancel_delayed_work_sync() to stop output polling, if poll
    task is running at this moment we may wait forever for it to finish.

    Instead, lock mux_hw_lock when unregistering the handler because
    the only reason why we'd want to lock vgasr_mutex in _lock_ddc() /
    _unlock_ddc() is to block the handler from disappearing while DDC
    lines are switched.

    Also acquire mux_hw_lock in stage2 to avoid race condition where
    reading the EDID and switching happens simultaneously. Likewise on
    MIGD / MDIS commands and on runtime suspend.

    v2.1: Overhaul locking, squash commits (Daniel Vetter)

    v2.2: Readability improvements (Thierry Reding)

    v2.3: Overhaul locking once more

    v2.4: Retain semantics of ->switchto handler callback to switch all
          pins, including DDC (Daniel Vetter)

    v5:   Rename ddc_lock to mux_hw_lock: Since we acquire this both
          when calling ->switch_ddc and ->switchto, it protects not just
          access to the DDC lines but to the mux in general. This is in
          line with the DRM convention to use low-level locks to avoid
          concurrent hw access (e.g. i2c, dp_aux) which are often called
          hw_lock (Daniel Vetter)

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115Tested-by: NLukas Wunner <lukas@wunner.de>
    [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Dave Airlie <airlied@gmail.com>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/e81ae9722b84c5ed591805fee3ea6dbf5dc6c4b3.1452525860.git.lukas@wunner.de

Allow handlers to declare their capabilities and allow clients to
obtain that information. So far we have these use cases:

* If the handler is able to switch DDC separately, clients need to
  probe EDID with drm_get_edid_switcheroo(). We should allow them
  to detect a capable handler to ensure this function only gets
  called when needed.

* Likewise if the handler is unable to switch AUX separately, the active
  client needs to communicate link training parameters to the inactive
  client, which may then skip the AUX handshake and set up its output
  with these pre-calibrated values (DisplayPort specification v1.1a,
  section 2.5.3.3). Clients need a way to recognize such a situation.

The flags for the radeon_atpx_handler and amdgpu_atpx_handler are
initially set to 0, this can later on be amended with
  handler_flags |= VGA_SWITCHEROO_CAN_SWITCH_DDC;
when a ->switch_ddc callback is added.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115Tested-by: NLukas Wunner <lukas@wunner.de>
    [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Reviewed-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/2b0d93ed6e511ca09e95e45e0b35627f330fabce.1452525860.git.lukas@wunner.de

Adds a function that sets the pointer to dev_pm_domain in struct device
and that warns if the device has already finished probing. The reason
why we want to enforce that is because in the general case that can
cause problems and also that we can simplify code quite a bit if we can
always assume that.

This patch also changes all current code that directly sets the
dev.pm_domain pointer.
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Fix indentation of vga_switcheroo sections in gpu.tmpl.

Change section type of API documentation from "chapter" to "sect1"
so that the individual functions no longer clutter up the ToC.
Group together under a new "API" chapter.

Fix wording "heretoforth" -> "henceforth".
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There are few defects in vga_get() related to signal hadning:

  - we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE
    case;

  - if we found pending signal we must remove ourself from wait queue
    and change task state back to running;

  - -ERESTARTSYS is more appropriate, I guess.
Signed-off-by: NKirill A. Shutemov <kirill@shutemov.name>
Cc: stable@vger.kernel.org
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

neither ->release() nor ->poll() can be called unless ->open()
has succeeded on the same struct file, so checking for "has
open() failed" is pointless.  What's more, ->poll() doesn't
return -E... - it always returns a bitmap of POLL... values,
so the dead code in that one had been actively bogus.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

hda_intel.c:azx_probe() defers initialization of an audio controller
on the discrete GPU if the GPU is powered off. The power state of the
GPU is determined by calling vga_switcheroo_get_client_state().

vga_switcheroo_get_client_state() returns VGA_SWITCHEROO_INIT if
vga_switcheroo is not enabled, i.e. if no second GPU or no handler
has registered.

This can go wrong in the following scenario:
- Driver for the integrated GPU is not loaded.
- Driver for the discrete GPU registers with vga_switcheroo, uses driver
  power control to power down the GPU, handler cuts power to the GPU.
- Driver for the audio controller gets loaded after the GPU was powered
  down, calls vga_switcheroo_get_client_state() which returns
  VGA_SWITCHEROO_INIT instead of VGA_SWITCHEROO_OFF.
- Consequence: azx_probe() tries to initialize the audio controller even
  though the GPU is powered down.

The power state VGA_SWITCHEROO_INIT was introduced by c8e9cf7b
("vga_switcheroo: Add a helper function to get the client state").
It is not apparent what its benefit might be. The idea seems to
be to initialize the audio controller even if the power state is
VGA_SWITCHEROO_OFF (were vga_switcheroo enabled), but as shown
above this can fail.

Drop VGA_SWITCHEROO_INIT to solve this.
Acked-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

vga_switcheroo_client_ops has always been declared const since its
introduction with 26ec685f ("vga_switcheroo: Introduce struct
vga_switcheroo_client_ops").

Do so for vga_switcheroo_handler as well.

 drivers/gpu/drm/amd/amdgpu/amdgpu.ko:
   6 .rodata       00009888
- 19 .data         00001f00
+ 19 .data         00001ee0
 drivers/gpu/drm/nouveau/nouveau.ko:
   6 .rodata       000460b8
  17 .data         00018fe0
 drivers/gpu/drm/radeon/radeon.ko:
-  7 .rodata       00030944
+  7 .rodata       00030964
- 21 .data         0000d6a0
+ 21 .data         0000d678
 drivers/platform/x86/apple-gmux.ko:
-  7 .rodata       00000140
+  7 .rodata       00000160
- 11 .data         000000e0
+ 11 .data         000000b8

Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Darren Hart <dvhart@linux.intel.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Reviewed-by: Christian König <christian.koenig@amd.com>.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NLukas Wunner <lukas@wunner.de>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NLukas Wunner <lukas@wunner.de>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NLukas Wunner <lukas@wunner.de>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The following functions iterate over the client list, invoke client
callbacks or invoke handler callbacks without locking anything at all:

- Introduced by c8e9cf7b ("vga_switcheroo: Add a helper function to
  get the client state"):
  vga_switcheroo_get_client_state()

- Introduced by 0d69704a ("gpu/vga_switcheroo: add driver control
  power feature. (v3)"):
  vga_switcheroo_set_dynamic_switch()
  vga_switcheroo_runtime_suspend()
  vga_switcheroo_runtime_resume()
  vga_switcheroo_runtime_resume_hdmi_audio()

Refactor vga_switcheroo_runtime_resume_hdmi_audio() a bit to be able to
release vgasr_mutex immediately after iterating over the client list.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The active attribute in struct vga_switcheroo_client denotes whether
the outputs are currently switched to this client. The attribute is
only meaningful for vga clients. It is never used for audio clients.

The function vga_switcheroo_register_audio_client() misuses this
attribute to store whether the audio device is fully initialized.
Most likely there was a misunderstanding about the meaning of
"active" when this was added.

Comment from Takashi's review:

"Not really.  The full initialization of audio was meant that the audio
is active indeed.  Admittedly, though, the active flag for each audio
client doesn't play any role because the audio always follows the gfx
state changes, and the value passed there doesn't reflect the actual
state due to the later change.  So, I agree with the removal of the
flag itself -- or let the audio active flag following the
corresponding gfx flag.  The latter will make the proc output more
consistent while the former is certainly more reduction of code."

Set the active attribute to false for audio clients. Remove the
active parameter from vga_switcheroo_register_audio_client() and
its sole caller, hda_intel.c:register_vga_switcheroo().

vga_switcheroo_register_audio_client() was introduced by 3e9e63db
("vga_switcheroo: Add the support for audio clients"). Its use in
hda_intel.c was introduced by a82d51ed ("ALSA: hda - Support
VGA-switcheroo").

v1.1: The changes above imply that in find_active_client() the call
to client_is_vga() is now superfluous. Drop it.

Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
[danvet: Add Takashi's clarification to the commit message.]
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This adds an "Overview" DOC section plus two DOC sections for the modes
of use ("Manual switching and manual power control" and "Driver power
control").

Also included is kernel-doc for all public functions, structs and enums.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

debugfs_remove() gracefully ignores NULL parameters, so the explicit
checks can be removed.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Wrap overly long lines to make checkpatch happy. While at it, also add
blank lines after declarations to eliminate additional problems flagged
by checkpatch.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use pr_fmt() to define the "vga_switcheroo: " prefix that is prepended
to all output messages emitted by pr_*() functions. This allows making
existing strings much shorter and eliminates a bunch of warnings from
checkpatch about lines being overly long.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The header comment uses a weird combination of formatting styles. Make
it consistent.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This silences a bunch of checkpatch warnings and makes the code shorter.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Wrap overly long lines (offending lines were mostly comments, so trivial
to fix up) and a number of other coding style issues pointed out by the
checkpatch tool.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Define the pr_fmt() macro to causes all messages emitted by pr_*()
functions to be prefixed with "vgaarb: ".
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some setups do not register a default VGA device, in which case the VGA
arbiter will still complain about the (non-existent) PCI device being a
non-VGA device.

Fix this by making the error message conditional on a default VGA device
having been set up. Note that the easy route of erroring out early isn't
going to work because otherwise priv->target won't be properly updated.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

schedule(), io_schedule() and schedule_timeout() always return
with TASK_RUNNING state set, so one more setting is unnecessary.

(All places in patch are visible good, only exception is
 kiblnd_scheduler() from:

      drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c

 Its schedule() is one line above standard 3 lines of unified diff)

No places where set_current_state() is used for mb().
Signed-off-by: NKirill Tkhai <ktkhai@parallels.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1410529254.3569.23.camel@tkhai
Cc: Alasdair Kergon <agk@redhat.com>
Cc: Anil Belur <askb23@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dave Kleikamp <shaggy@kernel.org>
Cc: David Airlie <airlied@linux.ie>
Cc: David Howells <dhowells@redhat.com>
Cc: Dmitry Eremin <dmitry.eremin@intel.com>
Cc: Frank Blaschka <blaschka@linux.vnet.ibm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Isaac Huang <he.huang@intel.com>
Cc: James E.J. Bottomley <JBottomley@parallels.com>
Cc: James E.J. Bottomley <jejb@parisc-linux.org>
Cc: J. Bruce Fields <bfields@fieldses.org>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Laura Abbott <lauraa@codeaurora.org>
Cc: Liang Zhen <liang.zhen@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Masaru Nomura <massa.nomura@gmail.com>
Cc: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Cc: Mikael Starvik <starvik@axis.com>
Cc: Mike Snitzer <snitzer@redhat.com>
Cc: Neil Brown <neilb@suse.de>
Cc: Oleg Drokin <green@linuxhacker.ru>
Cc: Peng Tao <bergwolf@gmail.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Robert Love <robert.w.love@intel.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: Ursula Braun <ursula.braun@de.ibm.com>
Cc: Zi Shen Lim <zlim.lnx@gmail.com>
Cc: devel@driverdev.osuosl.org
Cc: dm-devel@redhat.com
Cc: dri-devel@lists.freedesktop.org
Cc: fcoe-devel@open-fcoe.org
Cc: jfs-discussion@lists.sourceforge.net
Cc: linux390@de.ibm.com
Cc: linux-afs@lists.infradead.org
Cc: linux-cris-kernel@axis.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-nfs@vger.kernel.org
Cc: linux-parisc@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Cc: linux-s390@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Cc: qla2xxx-upstream@qlogic.com
Cc: user-mode-linux-devel@lists.sourceforge.net
Cc: user-mode-linux-user@lists.sourceforge.net
Signed-off-by: NIngo Molnar <mingo@kernel.org>

Drivers should call this on unload to unregister pmops.

Bug:
https://bugzilla.kernel.org/show_bug.cgi?id=84431Reviewed-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>

Commit 20cde694 ("x86, ia64: Move EFI_FB vga_default_device()
initialization to pci_vga_fixup()") moved boot video device detection from
efifb to x86 and ia64 pci/fixup.c.

Remove the left-over #ifndef check that will always match since the
corresponding arch-specific define is gone with above patch.
Signed-off-by: NBruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Matthew Garrett <matthew.garrett@nebula.com>

Commit 20cde694 ("x86, ia64: Move EFI_FB vga_default_device()
initialization to pci_vga_fixup()") moved boot video device detection from
efifb to x86 and ia64 pci/fixup.c.

For dual-GPU Apple computers above change represents a regression as code
in efifb did forcefully override vga_default_device while the merge did not
(vgaarb happens prior to PCI fixup).

To improve on initial device selection by vgaarb (it cannot know if PCI
device not behind bridges see/decode legacy VGA I/O or not), move the
screen_info based check from pci_video_fixup() to vgaarb's init function and
use it to refine/override decision taken while adding the individual PCI
VGA devices.  This way PCI fixup has no reason to adjust vga_default_device
anymore but can depend on its value for flagging shadowed VBIOS.

This has the nice benefit of removing duplicated code but does introduce a
#if defined() block in vgaarb.  Not all architectures have screen_info and
would cause compile to fail without it.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=84461Reported-and-Tested-By: NAndreas Noever <andreas.noever@gmail.com>
Signed-off-by: NBruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Matthew Garrett <matthew.garrett@nebula.com>
CC: stable@vger.kernel.org # v3.5+

The VGA arbiter does not allow devices to "own" resources that it
doesn't "decode".  However, it does allow devices to "lock" resources
that it doesn't decode.  This gets us into trouble because locking
the resource goes through the same bridge routing updates regardless
of whether we decode the resource.  This means that when a non-decoded
resource is released, the bridge is left with VGA routing enabled and
locking a different device won't clear it.

This happens in the following scenario:

VGA device 01:00.0 (VGA1) is owned by the radeon driver, which
registers a set_vga_decode function which releases legacy VGA decodes.

VGA device 02:00.0 (VGA2) is any VGA device.

VGA1 user locks VGA resources triggering first_use callback of
set_vga_decoded, clearing "decode" and "owns" of legacy resources
on VGA1.

VGA1 user unlocks VGA resources.

VGA2 user locks VGA resources, which skips VGA1 as conflicting as it
does not "own" legacy resources, although VGA routing is still enabled
for the VGA1 bridge.  VGA routing is enabled on VGA2 bridge.

VGA2 may or may not receive VGA transactions depending on the bus
priority of VGA1 vs VGA2 bridge.

To resolve this, we need to allow devices to "own" resources that they
do not "decode".  This way we can track bus ownership of VGA.  When a
device decodes VGA, it only means that we must update the command bits
in cases where the conflicting device is on the same bus.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Avoids blank screens on muxed systems when runpm is active.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=75917Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

When VGA decodes change we need to do a bit more evaluation of exactly what
has changed.  We don't necessarily give up all the old owns resources and
we need to account for resources with locks.  The new algorithm is: If
something is added, update decodes.  If legacy resources were added and
none were there before, we have a new participant.  If something is
removed, update decodes.  If we previously owned it, we no longer own it.
If it was previously locked, invalidate all locks and release it.  If
legacy resources were removed and none are left, remove the participant
from VGA arbitration.

Previously we updated decodes, released ownership of everything that was
previously decoded, ignored all locks, and went off looking for another
device to transfer VGA to.  In a test case where Intel IGD removes only
legacy VGA memory decoding, this left the arbiter switching to discrete
graphics without actually disabling legacy VGA IO from the IGD.  As a
bonus, we bumped up the count of VGA arbitration participants for no
good reason.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Kill now unused variables, reported by the 0-day kernel
builtbot.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If a device does not own a resource then we don't need to disable it.
This resolves the case where an Intel IGD device can be configured to
disable decode of VGA memory but we still need the arbiter to handle
VGA I/O port routing.  When the IGD device is in conflict, only
PCI_COMMAND_IO should be disabled since VGA memory does not require
arbitration on this device.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For optimus and powerxpress muxless we really want the GPU
driver deciding when to power up/down the GPU, not userspace.

This adds the ability for a driver to dynamically power up/down
the GPU and remove the switcheroo from controlling it, the
switcheroo reports the dynamic state to userspace also.

It also adds 2 power domains, one for machine where the power
switch is controlled outside the GPU D3 state, so the powerdown
ordering is done correctly, and the second for the hdmi audio
device to make sure it can resume for PCI config space accesses.

v1.1: fix build with switcheroo off

v2: add power domain support for radeon and v1 nvidia dsms
v2.1: fix typo in off case

v3: add audio power domain for hdmi audio + misc audio fixes

v4: use PCI_SLOT macro, drop power reference on hdmi audio resume
failure also.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Okay so Alan's patch handled the case where there was no registered fbcon,
however the other path entered in set_con2fb_map pit.

In there we called fbcon_takeover, but we also took the console lock in a couple
of places. So push the console lock out to the callers of set_con2fb_map,

this means fbmem and switcheroo needed to take the lock around the fb notifier
entry points that lead to this.

This should fix the efifb regression seen by Maarten.
Tested-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Tested-by: NLu Hua <huax.lu@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Signed-off-by: NIgor Murzov <e-mail@date.by>
Signed-off-by: NDave Airlie <airlied@redhat.com>