Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

These are particularly annoying on Optimus systems where these paths can
be called regularly.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

drm_gem_dumb_destroy() is the drm_driver.dumb_destroy default,
so no need to set it.

Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1500837417-40580-33-git-send-email-noralf@tronnes.org

The magic switching between proper pci driver and shadow-attach isn't
useful anymore since there's no ums+kms drivers left. Let's split this
up properly, calling pci_register_driver for kms drivers and renaming
the shadow-attach init to drm_legacy_pci_init/exit.
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-6-daniel.vetter@ffwll.ch

The only special-case is pci devices, and we can easily handle this in
the core. Do so and drop a pile of boilerplate from drivers.
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-5-daniel.vetter@ffwll.ch

There is a prototype for this function in the header, but the function
itself lacks a 'void' in the argument list, causing a harmless warning
when building with 'make W=1':

drivers/gpu/drm/nouveau/nouveau_drm.c: In function 'nouveau_pmops_runtime':
drivers/gpu/drm/nouveau/nouveau_drm.c:730:1: error: old-style function definition [-Werror=old-style-definition]

Fixes: 321f5c5f ("drm/nouveau: replace multiple open-coded runpm support checks with function")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This prevents a deadlock that somehow results from the suspend() ->
forbid() -> resume() callchain.

[  125.266960] [drm] Initialized nouveau 1.3.1 20120801 for 0000:02:00.0 on minor 1
[  370.120872] INFO: task kworker/4:1:77 blocked for more than 120 seconds.
[  370.120920]       Tainted: G           O    4.12.0-rc3 #20
[  370.120947] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  370.120982] kworker/4:1     D13808    77      2 0x00000000
[  370.120998] Workqueue: pm pm_runtime_work
[  370.121004] Call Trace:
[  370.121018]  __schedule+0x2bf/0xb40
[  370.121025]  ? mark_held_locks+0x5f/0x90
[  370.121038]  schedule+0x3d/0x90
[  370.121044]  rpm_resume+0x107/0x870
[  370.121052]  ? finish_wait+0x90/0x90
[  370.121065]  ? pci_pm_runtime_resume+0xa0/0xa0
[  370.121070]  pm_runtime_forbid+0x4c/0x60
[  370.121129]  nouveau_pmops_runtime_suspend+0xaf/0xc0 [nouveau]
[  370.121139]  pci_pm_runtime_suspend+0x5f/0x170
[  370.121147]  ? pci_pm_runtime_resume+0xa0/0xa0
[  370.121152]  __rpm_callback+0xb9/0x1e0
[  370.121159]  ? pci_pm_runtime_resume+0xa0/0xa0
[  370.121166]  rpm_callback+0x24/0x80
[  370.121171]  ? pci_pm_runtime_resume+0xa0/0xa0
[  370.121176]  rpm_suspend+0x138/0x6e0
[  370.121192]  pm_runtime_work+0x7b/0xc0
[  370.121199]  process_one_work+0x253/0x6a0
[  370.121216]  worker_thread+0x4d/0x3b0
[  370.121229]  kthread+0x133/0x150
[  370.121234]  ? process_one_work+0x6a0/0x6a0
[  370.121238]  ? kthread_create_on_node+0x70/0x70
[  370.121246]  ret_from_fork+0x2a/0x40
[  370.121283]
               Showing all locks held in the system:
[  370.121291] 2 locks held by kworker/4:1/77:
[  370.121298]  #0:  ("pm"){.+.+.+}, at: [<ffffffffac0d3530>] process_one_work+0x1d0/0x6a0
[  370.121315]  #1:  ((&dev->power.work)){+.+.+.}, at: [<ffffffffac0d3530>] process_one_work+0x1d0/0x6a0
[  370.121330] 1 lock held by khungtaskd/81:
[  370.121333]  #0:  (tasklist_lock){.+.+..}, at: [<ffffffffac10fc8d>] debug_show_all_locks+0x3d/0x1a0
[  370.121355] 1 lock held by dmesg/1639:
[  370.121358]  #0:  (&user->lock){+.+.+.}, at: [<ffffffffac124b6d>] devkmsg_read+0x4d/0x360

[  370.121377] =============================================
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Include <drm/*.h> instead of relative path from include/drm, then
remove the -Iinclude/drm compiler flag.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1493009447-31524-12-git-send-email-yamada.masahiro@socionext.com

Commit cae9ff03 effectively disabled the drm poll_helper by checking
the wrong flag to see if the driver should enable the poll or not:
mode_config.poll_enabled is only set to true by poll_init and it is not
indicating if the poll is enabled or not.
nouveau_display_create() will initialize the poll and going to disable it
right away. After poll_init() the mode_config.poll_enabled will be true,
but the poll itself is disabled.

To avoid the race caused by calling the poll_enable() from different paths,
this patch will enable the poll from one place, in the
nouveau_display_hpd_work().

In case the pm_runtime is disabled we will enable the poll in
nouveau_drm_load() once.

Fixes: cae9ff03 ("drm/nouveau: Don't enabling polling twice on runtime resume")
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: NLyude <lyude@redhat.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

If we restrict this helper to only kms drivers (which is the case) we
can look up the correct mode easily ourselves. But it's a bit tricky:

- All legacy drivers look at crtc->hwmode. But that is updated already
  at the beginning of the modeset helper, which means when we disable
  a pipe. Hence the final timestamps might be a bit off. But since
  this is an existing bug I'm not going to change it, but just try to
  be bug-for-bug compatible with the current code. This only applies
  to radeon&amdgpu.

- i915 tries to get it perfect by updating crtc->hwmode when the pipe
  is off (i.e. vblank->enabled = false).

- All other atomic drivers look at crtc->state->adjusted_mode. Those
  that look at state->requested_mode simply don't adjust their mode,
  so it's the same. That has two problems: Accessing crtc->state from
  interrupt handling code is unsafe, and it's updated before we shut
  down the pipe. For nonblocking modesets it's even worse.

For atomic drivers try to implement what i915 does. To do that we add
a new hwmode field to the vblank structure, and update it from
drm_calc_timestamping_constants(). For atomic drivers that's called
from the right spot by the helper library already, so all fine. But
for safety let's enforce that.

For legacy driver this function is only called at the end (oh the
fun), which is broken, so again let's not bother and just stay
bug-for-bug compatible.

The  benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos
directly to implement ->get_vblank_timestamp in every driver, deleting
a lot of code.

v2: Completely new approach, trying to mimick the i915 solution.

v3: Fixup kerneldoc.

v4: Drop the WARN_ON to check that the vblank is off, atomic helpers
currently unconditionally call this. Recomputing the same stuff should
be harmless.

v5: Fix typos and move misplaced hunks to the right patches (Neil).

v6: Undo hunk movement (kbuild).

Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Cc: Eric Anholt <eric@anholt.net>
Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-4-daniel.vetter@ffwll.ch

Again no apparent explanation for the split except hysterical raisins.
Merging them also makes it a bit more obviuos what's going on wrt the
runtime pm refdancing.

Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: nouveau@lists.freedesktop.org
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Reviewed-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170508082633.4214-1-daniel.vetter@ffwll.ch

drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so the drm_driver.debugfs_cleanup callback is not
needed. Additionally it uses debugfs_remove_recursive() to clean
up the debugfs files, so no need for adding fake drm_info_node
entries.

Cc: bskeggs@redhat.com
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-11-noralf@tronnes.org

The field contains a pointer to the parent platform device of the DRM
device. As struct drm_device also contains a dev pointer to the struct
device embedded in the platform_device structure, the platformdev field
is redundant. Remove it and use the dev pointer directly.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NJyri Sarha <jsarha@ti.com>
Acked-by: Vincent Abriou <vincent.abriou@st.com> # For sti
Acked-by: Russell King <rmk+kernel@armlinux.org.uk> # For armada
Acked-by: Rob Clark <robdclark@gmail.com> # For msm
Acked-by: Xinwei Kong<kong.kongxinwei@hisilicon.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This will allow the DRM to share memory objects between clients later
down the track.

For the moment, the only immediate benefit is less logic required to
handle suspend/resume.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

These were a little insane.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We want a supervisor client of NVKM (such as the DRM) to be able to
allow sharing of resources (such as memory objects) between clients.

To allow this, the supervisor creates all its clients as children of
itself, and will use an upcoming ioctl to permit sharing.

Currently it's not possible for indirect clients to use subclients.
Supporting this will require an additional field in the main ioctl.
This isn't important currently, but will need to be fixed for virt.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Core code already makes drm_driver.get_vblank_counter hook optional by
letting drm_vblank_no_hw_counter be the default implementation for the
function hook.  So the drm_vblank_no_hw_counter assignment in the driver
code becomes redundant and can be removed now.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Mali DP Maintainers <malidp@foss.arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Stefan Agner <stefan@agner.ch>
Cc: Xinliang Liu <z.liuxinliang@hisilicon.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: CK Hu <ck.hu@mediatek.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Jyri Sarha <jsarha@ti.com>
Cc: Eric Anholt <eric@anholt.net>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NAlexey Brodkin <abrodkin@synopsys.com>
Acked-by: NLiviu Dudau <liviu.dudau@arm.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1486458995-31018-3-git-send-email-shawnguo@kernel.org

As it turns out, on cards that actually have CRTCs on them we're already
calling drm_kms_helper_poll_enable(drm_dev) from
nouveau_display_resume() before we call it in
nouveau_pmops_runtime_resume(). This leads us to accidentally trying to
enable polling twice, which results in a potential deadlock between the
RPM locks and drm_dev->mode_config.mutex if we end up trying to enable
polling the second time while output_poll_execute is running and holding
the mode_config lock. As such, make sure we only enable polling in
nouveau_pmops_runtime_resume() if we need to.

This fixes hangs observed on the ThinkPad W541
Signed-off-by: NLyude <lyude@redhat.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Kilian Singer <kilian.singer@quantumtechnology.info>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: David Airlie <airlied@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The integer returned by the unload hook is ignored by the drm core, so
let's make it void.

This patch was created using the following Coccinelle semantic script
(except for the declaration and comment in drm_drv.h):

Compile-tested only.

// <smpl>
@ get_name @
struct drm_driver drv;
identifier fn;
@@
drv.unload = fn;

@ replace_type @
identifier get_name.fn;
@@
- int
+ void
fn (...)
{
...
}

@ remove_return_param @
identifier get_name.fn;
@@
void fn (...)
{
<...
if (...)
return
- ...
;
...>
 }

@ drop_final_return @
identifier get_name.fn;
@@
void fn (...)
{
...

- return 0;
}
// </smpl>
Suggested-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NGabriel Krisman Bertazi <krisman@collabora.co.uk>
Acked-by: Christian König <christian.koenig@amd.com>.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170106175731.29196-1-krisman@collabora.co.uk

Currently, every backlight interface created by Nouveau uses the same name,
nv_backlight. This leads to a sysfs warning as it tries to create an already
existing folder. This patch adds a incremented number to the name, but keeps
the initial name as nv_backlight, to avoid possibly breaking userspace; the
second interface will be named nv_backlight1, and so on.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86539

v2:
* Switch to using ida for generating unique IDs, as suggested by Ilia Mirkin;
* Allocate backlight name on the stack, as suggested by Ilia Mirkin;
* Move `nouveau_get_backlight_name()` to avoid forward declaration, as
  suggested by Ilia Mirkin;
* Fix reference to bug report formatting, as reported by Nick Tenney.

v3:
* Define a macro for the size of the backlight name, to avoid defining
  it multiple times;
* Use snprintf in place of sprintf.

v4:
* Do not create similarly named interfaces when reaching the maximum
  amount of unique names, but fail instead, as pointed out by Lukas Wunner
Signed-off-by: NPierre Moreau <pierre.morrow@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We need to call drm_helper_hpd_irq_event() on resume to properly detect
monitor connection / disconnection on some laptops, use hpd_work for
this to avoid deadlocks.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

nouveau_display_fini() is responsible for quiescing the hardware, so
this is where such actions belong.

More than that, nouveau_display_fini() switches off the receiving of
sink irqs, which MST will require while shutting down an active head.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We received a donation of a Titan which has this useless feature
allowing users to control the brightness of the LED behind the
logo of NVIDIA. In the true spirit of open source, let's expose
that to the users of very expensive cards!

This patch hooks up this LED/PWM to the LED subsystem which allows
blinking it in sync with cpu/disk/network/whatever activity (heartbeat
is quite nice!). Users may also implement some breathing effect or
morse code support in the userspace if they feel like it.

v2:
 - surround the use of the LED framework with ifdef CONFIG_LEDS_CLASS

v3:
 - avoid using ifdefs everywhere, follow the recommendations of
   /doc/Documentation/CodingStyle. Suggested by Emil Velikov.

v4 (Ben):
 - squashed series of fixes from ml
Signed-off-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There are many reasons other than ENOMEM that drm_dev_init() can
fail. Return ERR_PTR rather than NULL to be able to distinguish
these in the caller.
Signed-off-by: NTom Gundersen <teg@jklm.no>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20160921145919.13754-2-teg@jklm.no

Lots of drivers don't properly compile without this when CONFIG_FB=n.
It's kinda a hack, but since CONFIG_FB doesn't stub any fucntions when
it's disabled I think it makes sense to add it to drm_fb_helper.h.

Long term we probably need to rethink all the logic to unload firmware
framebuffer drivers, at least if we want to be able to move away from
CONFIG_FB and fbcon.

v2: Unfortunately just stubbing out remove_conflicting_framebuffers in
drm_fb_helper.h upset gcc about static vs. non-static declarations, so
a new wrapper it needs to be. Means more churn :(

Cc: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: tomi.valkeinen@ti.com
Cc: dh.herrmann@gmail.com
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470847958-28465-2-git-send-email-daniel.vetter@ffwll.ch

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The PCI core calls pm_runtime_forbid() on device probe in pci_pm_init(),
making this the default state when nouveau is loaded. nouveau_drm_load()
therefore calls pm_runtime_allow(), but there's no pm_runtime_forbid()
in nouveau_drm_unload() to balance it. Add it so that we leave the
device in the same state that we found it.

This isn't a bug, it's just good housekeeping. When nouveau is first
loaded with runpm=1, then unloaded and loaded again with runpm=0,
pm_runtime_forbid() will be called from nouveau_pmops_runtime_idle() or
nouveau_pmops_runtime_suspend(), so the behaviour is correct. The nvidia
blob doesn't use runtime pm, but if it ever does, this commit avoids
that it has to clean up behind nouveau.

Cc: Ben Skeggs <bskeggs@redhat.com>
Tested-by: NKarol Herbst <karolherbst@gmail.com>
Tested-by: NPeter Wu <peter@lekensteyn.nl>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/92cf96445088217a4d7d7081b90140f2d6f047da.1465392124.git.lukas@wunner.de

nouveau_drm_load() calls pm_runtime_put() if nouveau_runtime_pm != 0,
but nouveau_drm_unload() calls pm_runtime_get_sync() unconditionally.
We therefore leak a runtime pm ref whenever nouveau is loaded with
runpm=0 and then unloaded. The GPU will subsequently never runtime
suspend even if nouveau is loaded again with runpm=1.

Fix by taking the runtime pm ref under the same condition that it was
released on driver load.

Fixes: 5addcf0a ("nouveau: add runtime PM support (v0.9)")
Cc: Dave Airlie <airlied@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Reported-by: NKarol Herbst <karolherbst@gmail.com>
Tested-by: NKarol Herbst <karolherbst@gmail.com>
Tested-by: NPeter Wu <peter@lekensteyn.nl>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1544b82007037601fbc510b1a50edc56c529e75f.1465392124.git.lukas@wunner.de

We already have a fallback in place to fill out the unique from
dev->unique, which is set to something reasonable in drm_dev_alloc.

Which means we only need to have a special set_busid for pci devices,
to be able to care the backwards compat code for drm 1.1 around, which
libdrm still needs.

While developing and testing this patch things blew up in really
interesting ways, and the code is rather confusing in naming things
between the kernel code, ioctl #defines and libdrm. For the next brave
dragon slayer, document all this madness properly in the userspace
interface section of gpu.tmpl.

v2: Make drm_dev_set_unique static and update kerneldoc.

v3: Entire rewrite, plus document what's going on for posterity in the
gpu docbook uapi section.

v4: Drop accidental amdgpu hunk (Emil).

v5: Drop accidental omapdrm vblank counter change (Emil).

v6: Rebase on top of the sphinx conversion.

Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> (virt_gpu)
Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

No dev->struct_mutex anywhere to be seen.

Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464630800-30786-9-git-send-email-daniel.vetter@ffwll.ch

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

Fixes out-of-tree build issue where uapi/drm/nouveau_drm.h gets picked
up instead.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This allows us to ditch a ton of ugly #ifdefs from a bunch of drm modeset
drivers.

v2: Make the dummy function actually return a sane value, spotted by
Ville.

v3: Because the patch is still in limbo there's no more drivers to
convert, noticed by Emil.

v4: Rebase once more, because hooray. I'll just go ahead an apply this
one later on to drm-misc.

Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This class supports a WFI method (0x0078) that's not present on the
KeplerChannelGpfifoA class.

The binary driver exposes both classes on these GPUs for some reason,
though there doesn't appear to be any difference in the setup that's
done for each (ie. even if you allocate GpfifoA, the WFI method will
still work).

We shall just expose GpfifoB, as I don't see a good reason to report
the presence of both.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>