| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
[ Upstream commit 659fb5f154c3434c90a34586f3b7aa1c39cf6062 ]
On calling pm_runtime_get_sync() the reference count of the device
is incremented. In case of failure, decrement the
ref count before returning the error.
Signed-off-by: Aditya Pakki <pakki001@umn.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 07f4f97d7b4bf325d9f558c5b58230387e4e57e0 ]
Back in 2013, runtime PM for GPUs with integrated HDA controller was
introduced with commits 0d69704ae348 ("gpu/vga_switcheroo: add driver
control power feature. (v3)") and 246efa4a072f ("snd/hda: add runtime
suspend/resume on optimus support (v4)").
Briefly, the idea was that the HDA controller is forced on and off in
unison with the GPU.
The original code is mostly still in place even though it was never a
100% perfect solution: E.g. on access to the HDA controller, the GPU
is powered up via vga_switcheroo_runtime_resume_hdmi_audio() but there
are no provisions to keep it resumed until access to the HDA controller
has ceased: The GPU autosuspends after 5 seconds, rendering the HDA
controller inaccessible.
Additionally, a kludge is required when hda_intel.c probes: It has to
check whether the GPU is powered down (check_hdmi_disabled()) and defer
probing if so.
However in the meantime (in v4.10) the driver core has gained a feature
called device links which promises to solve such issues in a clean way:
It allows us to declare a dependency from the HDA controller (consumer)
to the GPU (supplier). The PM core then automagically ensures that the
GPU is runtime resumed as long as the HDA controller's ->probe hook is
executed and whenever the HDA controller is accessed.
By default, the HDA controller has a dependency on its parent, a PCIe
Root Port. Adding a device link creates another dependency on its
sibling:
PCIe Root Port
^ ^
| |
| |
HDA ===> GPU
The device link is not only used for runtime PM, it also guarantees that
on system sleep, the HDA controller suspends before the GPU and resumes
after the GPU, and on system shutdown the HDA controller's ->shutdown
hook is executed before the one of the GPU. It is a complete solution.
Using this functionality is as simple as calling device_link_add(),
which results in a dmesg entry like this:
pci 0000:01:00.1: Linked as a consumer to 0000:01:00.0
The code for the GPU-governed audio power management can thus be removed
(except where it's still needed for legacy manual power control).
The device link is added in a PCI quirk rather than in hda_intel.c.
It is therefore legal for the GPU to runtime suspend to D3cold even if
the HDA controller is not bound to a driver or if CONFIG_SND_HDA_INTEL
is not enabled, for accesses to the HDA controller will cause the GPU to
wake up regardless if they're occurring outside of hda_intel.c (think
config space readout via sysfs).
Contrary to the previous implementation, the HDA controller's power
state is now self-governed, rather than GPU-governed, whereas the GPU's
power state is no longer fully self-governed. (The HDA controller needs
to runtime suspend before the GPU can.)
It is thus crucial that runtime PM is always activated on the HDA
controller even if CONFIG_SND_HDA_POWER_SAVE_DEFAULT is set to 0 (which
is the default), lest the GPU stays awake. This is achieved by setting
the auto_runtime_pm flag on every codec and the AZX_DCAPS_PM_RUNTIME
flag on the HDA controller.
A side effect is that power consumption might be reduced if the GPU is
in use but the HDA controller is not, because the HDA controller is now
allowed to go to D3hot. Before, it was forced to stay in D0 as long as
the GPU was in use. (There is no reduction in power consumption on my
Nvidia GK107, but there might be on other chips.)
The code paths for legacy manual power control are adjusted such that
runtime PM is disabled during power off, thereby preventing the PM core
from resuming the HDA controller.
Note that the device link is not only added on vga_switcheroo capable
systems, but for *any* GPU with integrated HDA controller. The idea is
that the HDA controller streams audio via connectors located on the GPU,
so the GPU needs to be on for the HDA controller to do anything useful.
This commit implicitly fixes an unbalanced runtime PM ref upon unbind of
hda_intel.c: On ->probe, a runtime PM ref was previously released under
the condition "azx_has_pm_runtime(chip) || hda->use_vga_switcheroo", but
on ->remove a runtime PM ref was only acquired under the first of those
conditions. Thus, binding and unbinding the driver twice on a
vga_switcheroo capable system caused the runtime PM refcount to drop
below zero. The issue is resolved because the AZX_DCAPS_PM_RUNTIME flag
is now always set if use_vga_switcheroo is true.
For more information on device links please refer to:
https://www.kernel.org/doc/html/latest/driver-api/device_link.html
Documentation/driver-api/device_link.rst
Cc: Dave Airlie <airlied@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Kai Heng Feng <kai.heng.feng@canonical.com> # AMD PowerXpress
Tested-by: Mike Lothian <mike@fireburn.co.uk> # AMD PowerXpress
Tested-by: Denis Lisov <dennis.lissov@gmail.com> # Nvidia Optimus
Tested-by: Peter Wu <peter@lekensteyn.nl> # Nvidia Optimus
Tested-by: Lukas Wunner <lukas@wunner.de> # MacBook Pro
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: https://patchwork.freedesktop.org/patch/msgid/51bd38360ff502a8c42b1ebf4405ee1d3f27118d.1520068884.git.lukas@wunner.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit b30a43ac7132cdda833ac4b13dd1ebd35ace14b7 upstream.
There was a nouveau DDX that relied on legacy context ioctls to work,
but we fixed it years ago, give distros that have a modern DDX the
option to break the uAPI and close the mess of holes that legacy
context support is.
Full context of the story:
commit 0e975980d435d58df2d430d688b8c18778b42218
Author: Peter Antoine <peter.antoine@intel.com>
Date: Tue Jun 23 08:18:49 2015 +0100
drm: Turn off Legacy Context Functions
The context functions are not used by the i915 driver and should not
be used by modeset drivers. These driver functions contain several bugs
and security holes. This change makes these functions optional can be
turned on by a setting, they are turned off by default for modeset
driver with the exception of the nouvea driver that may require them with
an old version of libdrm.
The previous attempt was
commit 7c510133d93dd6f15ca040733ba7b2891ed61fd1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Aug 8 15:41:21 2013 +0200
drm: mark context support as a legacy subsystem
but this had to be reverted
commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
Author: Dave Airlie <airlied@redhat.com>
Date: Fri Sep 20 08:32:59 2013 +1000
Revert "drm: mark context support as a legacy subsystem"
v2: remove returns from void function, and formatting (Daniel Vetter)
v3:
- s/Nova/nouveau/ in the commit message, and add references to the
previous attempts
- drop the part touching the drm hw lock, that should be a separate
patch.
Signed-off-by: Peter Antoine <peter.antoine@intel.com> (v2)
Cc: Peter Antoine <peter.antoine@intel.com> (v2)
Reviewed-by: Peter Antoine <peter.antoine@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: move DRM_VM dependency into legacy config.
v3: fix missing dep (kbuild robot)
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
(v3)"
This reverts commit 140ae656e3b7476719a2b15b96527c73c5acf90b which is
commit b30a43ac7132cdda833ac4b13dd1ebd35ace14b7 upstream.
Sven reports:
Commit 1e07d63749 ("drm/nouveau: add kconfig option to turn off nouveau
legacy contexts. (v3)") has caused a build failure for me when I
actually tried that option (CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n):
,----
| Kernel: arch/x86/boot/bzImage is ready (#1)
| Building modules, stage 2.
| MODPOST 290 modules
| ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
| scripts/Makefile.modpost:91: recipe for target '__modpost' failed
`----
Upstream does not have that problem, as commit bed2dd8421 ("drm/ttm:
Quick-test mmap offset in ttm_bo_mmap()") has removed the use of
drm_legacy_mmap from nouveau_ttm.c. Unfortunately that commit does not
apply in 5.1.9.
The ensuing discussion proposed a number of one-off patches, but no
solid agreement was made, so just revert the commit for now to get
people's systems building again.
Reported-by: Sven Joachim <svenjoac@gmx.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Thomas Backlund <tmb@mageia.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b30a43ac7132cdda833ac4b13dd1ebd35ace14b7 upstream.
There was a nouveau DDX that relied on legacy context ioctls to work,
but we fixed it years ago, give distros that have a modern DDX the
option to break the uAPI and close the mess of holes that legacy
context support is.
Full context of the story:
commit 0e975980d435d58df2d430d688b8c18778b42218
Author: Peter Antoine <peter.antoine@intel.com>
Date: Tue Jun 23 08:18:49 2015 +0100
drm: Turn off Legacy Context Functions
The context functions are not used by the i915 driver and should not
be used by modeset drivers. These driver functions contain several bugs
and security holes. This change makes these functions optional can be
turned on by a setting, they are turned off by default for modeset
driver with the exception of the nouvea driver that may require them with
an old version of libdrm.
The previous attempt was
commit 7c510133d93dd6f15ca040733ba7b2891ed61fd1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Aug 8 15:41:21 2013 +0200
drm: mark context support as a legacy subsystem
but this had to be reverted
commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
Author: Dave Airlie <airlied@redhat.com>
Date: Fri Sep 20 08:32:59 2013 +1000
Revert "drm: mark context support as a legacy subsystem"
v2: remove returns from void function, and formatting (Daniel Vetter)
v3:
- s/Nova/nouveau/ in the commit message, and add references to the
previous attempts
- drop the part touching the drm hw lock, that should be a separate
patch.
Signed-off-by: Peter Antoine <peter.antoine@intel.com> (v2)
Cc: Peter Antoine <peter.antoine@intel.com> (v2)
Reviewed-by: Peter Antoine <peter.antoine@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: move DRM_VM dependency into legacy config.
v3: fix missing dep (kbuild robot)
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 2f7ca781fd382cf8dde73ed36dfdd93fd05b3332 upstream.
Currently, there's nothing in nouveau that actually cancels this work
struct. So, cancel it on suspend/unload. Otherwise, if we're unlucky
enough hpd_work might try to keep running up until the system is
suspended.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 922a8c82fafdec99688bbaea6c5889f562a42cdc ]
Noticed this as I was skimming through, if we fail to allocate memory
for cli we'll end up returning without dropping the runtime PM ref we
got. Additionally, we'll even return the wrong return code! (ret most
likely will == 0 here, we want -ENOMEM).
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit eb493fbc150f4a28151ae1ee84f24395989f3600 upstream.
Currently nouveau doesn't actually expose the state debugfs file that's
usually provided for any modesetting driver that supports atomic, even
if nouveau is loaded with atomic=1. This is due to the fact that the
standard debugfs files that DRM creates for atomic drivers is called
when drm_get_pci_dev() is called from nouveau_drm.c. This happens well
before we've initialized the display core, which is currently
responsible for setting the DRIVER_ATOMIC cap.
So, move the atomic option into nouveau_drm.c and just add the
DRIVER_ATOMIC cap whenever it's enabled on the kernel commandline. This
shouldn't cause any actual issues, as the atomic ioctl will still fail
as expected even if the display core doesn't disable it until later in
the init sequence. This also provides the added benefit of being able to
use the state debugfs file to check the current display state even if
clients aren't allowed to modify it through anything other than the
legacy ioctls.
Additionally, disable the DRIVER_ATOMIC cap in nv04's display core, as
this was already disabled there previously.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
These are particularly annoying on Optimus systems where these paths can
be called regularly.
Signed-off-by: Ben 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: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1500837417-40580-33-git-send-email-noralf@tronnes.org
|
|
Required for Daniel's drm_vblank_cleanup cleanup
|
|
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: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel 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: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel 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: 321f5c5f2c49 ("drm/nouveau: replace multiple open-coded runpm support checks with function")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Linux 4.12-rc5 for nouveau fixes
|
|
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: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Linux 4.12-rc3
Daniel has requested this for some drm-intel-next work.
|
|
Include <drm/*.h> instead of relative path from include/drm, then
remove the -Iinclude/drm compiler flag.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1493009447-31524-12-git-send-email-yamada.masahiro@socionext.com
|
|
Commit cae9ff036eea 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: cae9ff036eea ("drm/nouveau: Don't enabling polling twice on runtime resume")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Lyude <lyude@redhat.com>
Signed-off-by: Ben 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: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel 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: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170508082633.4214-1-daniel.vetter@ffwll.ch
|
|
drm-misc-next
Merge Laurent's drm_platform removal code. Only conflict is with the
drm_pci.h extraction, which allows me to fix up the misplayed
drm_platform_init fumble that 0day and Stephen Rothwell reported.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
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: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-11-noralf@tronnes.org
|
|
Backmerge the main pull request to sync up with all the newly landed
drivers. Otherwise we'll have chaos even before 4.12 started in
earnest.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Linux 4.10-rc8
Backmerge Linus rc8 to fix some conflicts, but also
to avoid pulling it in via a fixes pull from someone.
|
|
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: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Jyri 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: Ben 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: Ben Skeggs <bskeggs@redhat.com>
|
|
These were a little insane.
Signed-off-by: Ben 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: Ben 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: Shawn 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: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Alexey Brodkin <abrodkin@synopsys.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Daniel 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: Lyude <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: Dave 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: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Acked-by: Christian König <christian.koenig@amd.com>.
Signed-off-by: Daniel 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: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: Ben 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ben 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: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben 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: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben 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: Tom Gundersen <teg@jklm.no>
Signed-off-by: Sean 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: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470847958-28465-2-git-send-email-daniel.vetter@ffwll.ch
|
|
git://anongit.freedesktop.org/drm-intel into drm-next
I recovered dri-devel backlog from my vacation, more misc stuff:
- of_put_node fixes from Peter Chen (not all yet)
- more patches from Gustavo to use kms-native drm_crtc_vblank_* funcs
- docs sphinxification from Lukas Wunner
- bunch of fixes all over from Dan Carpenter
- more follow up work from Chris register/unregister rework in various
places
- vgem dma-buf export (for writing testcases)
- small things all over from tons of different people
* tag 'topic/drm-misc-2016-07-14' of git://anongit.freedesktop.org/drm-intel: (52 commits)
drm: Don't overwrite user ioctl arg unless requested
dma-buf/sync_file: improve Kconfig description for Sync Files
MAINTAINERS: add entry for the Sync File Framework
drm: Resurrect atomic rmfb code
drm/vgem: Use PAGE_KERNEL in place of x86-specific PAGE_KERNEL_IO
qxl: silence uninitialized variable warning
qxl: check for kmap failures
vga_switcheroo: Sphinxify docs
drm: Restore double clflush on the last partial cacheline
gpu: drm: rockchip_drm_drv: add missing of_node_put after calling of_parse_phandle
gpu: drm: sti_vtg: add missing of_node_put after calling of_parse_phandle
gpu: drm: sti_hqvdp: add missing of_node_put after calling of_parse_phandle
gpu: drm: sti_vdo: add missing of_node_put after calling of_parse_phandle
gpu: drm: sti_compositor: add missing of_node_put after calling of_parse_phandle
drm/tilcdc: use drm_crtc_handle_vblank()
drm/rcar-du: use drm_crtc_handle_vblank()
drm/nouveau: use drm_crtc_handle_vblank()
drm/atmel: use drm_crtc_handle_vblank()
drm/armada: use drm_crtc_handle_vblank()
drm: make drm_vblank_count_and_time() static
...
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben 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: Karol Herbst <karolherbst@gmail.com>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel 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: 5addcf0a5f0f ("nouveau: add runtime PM support (v0.9)")
Cc: Dave Airlie <airlied@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Reported-by: Karol Herbst <karolherbst@gmail.com>
Tested-by: Karol Herbst <karolherbst@gmail.com>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel 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: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
git://anongit.freedesktop.org/drm-intel into drm-next
lockless gem bo freeing patches (and the oddball related patch) for all
the drivers who's maintainers are asleep at the helm - includes you ;-)
I based this on top of drm-fixes to include Chris' fix for the cma issue.
* tag 'topic/lockless-gem-bo-freeing-2016-06-01' of git://anongit.freedesktop.org/drm-intel: (21 commits)
drm/arcpgu: Use lockless gem BO free callback
drm/sun4i: Use lockless gem BO free callback
drm/omapdrm: Nuke dummy fb->dirty callback
drm/msm: Nuke dummy fb->dirty callback
drm/rockchip: Use cma gem vm ops
drm/sti: Use lockless gem BO free callback
drm: sti: remove useless call to dev->struct_mutex
drm/virtio: Use lockless gem BO free callback
drm/tilcdc: Use lockless gem BO free callback
drm/shmob: Use lockless gem BO free callback
drm/rockchip: Use lockless gem BO free callback
drm/rcar-du: Use lockless gem BO free callback
drm/qxl: Use lockless gem BO free callback
drm/nouveau: Use lockless gem BO free callback
drm/mga200g: Use lockless gem BO free callback
drm/fls-dcu: Use lockless gem BO free callback
drm/cirrus: Use lockless gem BO free callback
drm/bochs: Use lockless gem BO free callback
drm/atmel: Use lockless gem BO free callback
drm/ast: Use lockless gem BO free callback
...
|
|
No dev->struct_mutex anywhere to be seen.
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464630800-30786-9-git-send-email-daniel.vetter@ffwll.ch
|
