2009-12-11 12:24:15 +03:00
/*
* Copyright ( C ) 2008 Maarten Maathuis .
* All Rights Reserved .
*
* Permission is hereby granted , free of charge , to any person obtaining
* a copy of this software and associated documentation files ( the
* " Software " ) , to deal in the Software without restriction , including
* without limitation the rights to use , copy , modify , merge , publish ,
* distribute , sublicense , and / or sell copies of the Software , and to
* permit persons to whom the Software is furnished to do so , subject to
* the following conditions :
*
* The above copyright notice and this permission notice ( including the
* next paragraph ) shall be included in all copies or substantial
* portions of the Software .
*
* THE SOFTWARE IS PROVIDED " AS IS " , WITHOUT WARRANTY OF ANY KIND ,
* EXPRESS OR IMPLIED , INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
* MERCHANTABILITY , FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT .
* IN NO EVENT SHALL THE COPYRIGHT OWNER ( S ) AND / OR ITS SUPPLIERS BE
* LIABLE FOR ANY CLAIM , DAMAGES OR OTHER LIABILITY , WHETHER IN AN ACTION
* OF CONTRACT , TORT OR OTHERWISE , ARISING FROM , OUT OF OR IN CONNECTION
* WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE .
*
*/
2016-11-09 20:17:44 +03:00
# include <acpi/video.h>
2019-05-19 17:00:44 +03:00
2016-11-04 10:20:36 +03:00
# include <drm/drm_atomic.h>
# include <drm/drm_atomic_helper.h>
2012-10-02 21:01:07 +04:00
# include <drm/drm_crtc_helper.h>
2017-12-05 21:25:00 +03:00
# include <drm/drm_fb_helper.h>
2019-05-19 17:00:44 +03:00
# include <drm/drm_fourcc.h>
2020-02-06 13:19:41 +03:00
# include <drm/drm_gem_framebuffer_helper.h>
2019-01-18 00:03:34 +03:00
# include <drm/drm_probe_helper.h>
2019-05-19 17:00:44 +03:00
# include <drm/drm_vblank.h>
2012-07-31 10:16:21 +04:00
2009-12-11 12:24:15 +03:00
# include "nouveau_fbcon.h"
2010-10-21 01:35:40 +04:00
# include "nouveau_crtc.h"
2012-07-31 10:16:21 +04:00
# include "nouveau_gem.h"
2011-10-17 06:23:41 +04:00
# include "nouveau_connector.h"
2011-02-09 04:57:45 +03:00
# include "nv50_display.h"
2009-12-11 12:24:15 +03:00
2019-02-12 15:28:13 +03:00
# include <nvif/class.h>
2015-11-08 03:44:19 +03:00
# include <nvif/cl0046.h>
2014-08-09 22:10:20 +04:00
# include <nvif/event.h>
drm/nouveau/kms/nvd9-: Add CRC support
This introduces support for CRC readback on gf119+, using the
documentation generously provided to us by Nvidia:
https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt
We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed
through a single set of "outp" sources: outp-active/auto for a CRC of
the scanout region, outp-complete for a CRC of both the scanout and
blanking/sync region combined, and outp-inactive for a CRC of only the
blanking/sync region. For each source, nouveau selects the appropriate
tap point based on the output path in use. We also expose an "rg"
source, which allows for capturing CRCs of the scanout raster before
it's encoded into a video signal in the output path. This tap point is
referred to as the raster generator.
Note that while there's some other neat features that can be used with
CRC capture on nvidia hardware, like capturing from two CRC sources
simultaneously, I couldn't see any usecase for them and did not
implement them.
Nvidia only allows for accessing CRCs through a shared DMA region that
we program through the core EVO/NvDisplay channel which is referred to
as the notifier context. The notifier context is limited to either 255
(for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and
unfortunately the hardware simply drops CRCs and reports an overflow
once all available entries in the notifier context are filled.
Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit
on how many CRCs can be captured, we work around this in nouveau by
allocating two separate notifier contexts for each head instead of one.
We schedule a vblank worker ahead of time so that once we start getting
close to filling up all of the available entries in the notifier
context, we can swap the currently used notifier context out with
another pre-prepared notifier context in a manner similar to page
flipping.
Unfortunately, the hardware only allows us to this by flushing two
separate updates on the core channel: one to release the current
notifier context handle, and one to program the next notifier context's
handle. When the hardware processes the first update, the CRC for the
current frame is lost. However, the second update can be flushed
immediately without waiting for the first to complete so that CRC
generation resumes on the next frame. According to Nvidia's hardware
engineers, there isn't any cleaner way of flipping notifier contexts
that would avoid this.
Since using vblank workers to swap out the notifier context will ensure
we can usually flush both updates to hardware within the timespan of a
single frame, we can also ensure that there will only be exactly one
frame lost between the first and second update being executed by the
hardware. This gives us the guarantee that we're always correctly
matching each CRC entry with it's respective frame even after a context
flip. And since IGT will retrieve the CRC entry for a frame by waiting
until it receives a CRC for any subsequent frames, this doesn't cause an
issue with any tests and is much simpler than trying to change the
current DRM API to accommodate.
In order to facilitate testing of correct handling of this limitation,
we also expose a debugfs interface to manually control the threshold for
when we start trying to flip the notifier context. We will use this in
igt to trigger a context flip for testing purposes without needing to
wait for the notifier to completely fill up. This threshold is reset
to the default value set by nouveau after each capture, and is exposed
in a separate folder within each CRTC's debugfs directory labelled
"nv_crc".
Changes since v1:
* Forgot to finish saving crc.h before saving, whoops. This just adds
some corrections to the empty function declarations that we use if
CONFIG_DEBUG_FS isn't enabled.
Changes since v2:
* Don't check return code from debugfs_create_dir() or
debugfs_create_file() - Greg K-H
Changes since v3:
(no functional changes)
* Fix SPDX license identifiers (checkpatch)
* s/uint32_t/u32/ (checkpatch)
* Fix indenting in switch cases (checkpatch)
Changes since v4:
* Remove unneeded param changes with nv50_head_flush_clr/set
* Rebase
Changes since v5:
* Remove set but unused variable (outp) in nv50_crc_atomic_check() -
Kbuild bot
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-10-lyude@redhat.com
2019-10-07 21:20:12 +03:00
# include <dispnv50/crc.h>
2013-10-03 01:02:29 +04:00
int
2020-01-23 16:59:30 +03:00
nouveau_display_vblank_enable ( struct drm_crtc * crtc )
2013-10-03 01:02:29 +04:00
{
2017-01-09 14:25:43 +03:00
struct nouveau_crtc * nv_crtc ;
nv_crtc = nouveau_crtc ( crtc ) ;
nvif_notify_get ( & nv_crtc - > vblank ) ;
return 0 ;
2013-10-03 01:02:29 +04:00
}
void
2020-01-23 16:59:30 +03:00
nouveau_display_vblank_disable ( struct drm_crtc * crtc )
2013-10-03 01:02:29 +04:00
{
2017-01-09 14:25:43 +03:00
struct nouveau_crtc * nv_crtc ;
nv_crtc = nouveau_crtc ( crtc ) ;
nvif_notify_put ( & nv_crtc - > vblank ) ;
2013-10-03 01:02:29 +04:00
}
2013-11-14 07:37:49 +04:00
static inline int
calc ( int blanks , int blanke , int total , int line )
{
if ( blanke > = blanks ) {
if ( line > = blanks )
line - = total ;
} else {
if ( line > = blanks )
line - = total ;
line - = blanke + 1 ;
}
return line ;
}
drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos
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
2017-05-09 17:03:28 +03:00
static bool
2013-11-14 07:37:49 +04:00
nouveau_display_scanoutpos_head ( struct drm_crtc * crtc , int * vpos , int * hpos ,
ktime_t * stime , ktime_t * etime )
{
2014-08-09 22:10:27 +04:00
struct {
struct nv04_disp_mthd_v0 base ;
struct nv04_disp_scanoutpos_v0 scan ;
} args = {
. base . method = NV04_DISP_SCANOUTPOS ,
. base . head = nouveau_crtc ( crtc ) - > index ,
} ;
2013-11-14 07:37:49 +04:00
struct nouveau_display * disp = nouveau_display ( crtc - > dev ) ;
2015-09-14 22:43:43 +03:00
struct drm_vblank_crtc * vblank = & crtc - > dev - > vblank [ drm_crtc_index ( crtc ) ] ;
drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos
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
2017-05-09 17:03:28 +03:00
int retry = 20 ;
bool ret = false ;
2013-11-14 07:37:49 +04:00
do {
2018-05-08 13:39:47 +03:00
ret = nvif_mthd ( & disp - > disp . object , 0 , & args , sizeof ( args ) ) ;
2013-11-14 07:37:49 +04:00
if ( ret ! = 0 )
drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos
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
2017-05-09 17:03:28 +03:00
return false ;
2013-11-14 07:37:49 +04:00
2014-08-09 22:10:27 +04:00
if ( args . scan . vline ) {
drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos
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
2017-05-09 17:03:28 +03:00
ret = true ;
2013-11-14 07:37:49 +04:00
break ;
}
2015-09-14 22:43:43 +03:00
if ( retry ) ndelay ( vblank - > linedur_ns ) ;
2013-11-14 07:37:49 +04:00
} while ( retry - - ) ;
2014-08-09 22:10:27 +04:00
* hpos = args . scan . hline ;
* vpos = calc ( args . scan . vblanks , args . scan . vblanke ,
args . scan . vtotal , args . scan . vline ) ;
if ( stime ) * stime = ns_to_ktime ( args . scan . time [ 0 ] ) ;
if ( etime ) * etime = ns_to_ktime ( args . scan . time [ 1 ] ) ;
2013-11-14 07:37:49 +04:00
return ret ;
}
drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos
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
2017-05-09 17:03:28 +03:00
bool
2020-01-23 16:59:29 +03:00
nouveau_display_scanoutpos ( struct drm_crtc * crtc ,
drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos
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
2017-05-09 17:03:28 +03:00
bool in_vblank_irq , int * vpos , int * hpos ,
2015-09-24 19:35:31 +03:00
ktime_t * stime , ktime_t * etime ,
2015-09-14 22:43:44 +03:00
const struct drm_display_mode * mode )
2013-11-14 07:37:49 +04:00
{
2020-01-23 16:59:29 +03:00
return nouveau_display_scanoutpos_head ( crtc , vpos , hpos ,
stime , etime ) ;
2013-11-14 07:37:49 +04:00
}
2009-12-11 12:24:15 +03:00
static const struct drm_framebuffer_funcs nouveau_framebuffer_funcs = {
2020-02-06 13:19:41 +03:00
. destroy = drm_gem_fb_destroy ,
. create_handle = drm_gem_fb_create_handle ,
2009-12-11 12:24:15 +03:00
} ;
2020-02-11 02:15:55 +03:00
static void
nouveau_decode_mod ( struct nouveau_drm * drm ,
uint64_t modifier ,
uint32_t * tile_mode ,
uint8_t * kind )
{
drm/nouveau: Accept 'legacy' format modifiers
Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers. Existing Mesa
drivers are still aware of only these older
format modifiers which do not differentiate
between different variations of the block linear
layout. When the format modifier support flag was
flipped in the nouveau kernel driver, the X.org
modesetting driver began attempting to use its
format modifier-enabled framebuffer path. Because
the set of format modifiers advertised by the
kernel prior to this change do not intersect with
the set of format modifiers advertised by Mesa,
allocating GBM buffers using format modifiers
fails and the modesetting driver falls back to
non-modifier allocation. However, it still later
queries the modifier of the GBM buffer when
creating its DRM-KMS framebuffer object, receives
the old-format modifier from Mesa, and attempts
to create a framebuffer with it. Since the kernel
is still not aware of these formats, this fails.
Userspace should not be attempting to query format
modifiers of GBM buffers allocated with a non-
format-modifier-aware allocation path, but to
avoid breaking existing userspace behavior, this
change accepts the old-style format modifiers when
creating framebuffers and applying them to planes
by translating them to the equivalent new-style
modifier. To accomplish this, some layout
parameters must be assumed to match properties of
the device targeted by the relevant ioctls. To
avoid perpetuating misuse of the old-style
modifiers, this change does not advertise support
for them. Doing so would imply compatibility
between devices with incompatible memory layouts.
Tested with Xorg 1.20 modesetting driver,
weston@c46c70dac84a4b3030cd05b380f9f410536690fc,
gnome & KDE wayland desktops from Ubuntu 18.04,
and sway 1.5
Reported-by: Kirill A. Shutemov <kirill@shutemov.name>
Fixes: fa4f4c213f5f ("drm/nouveau/kms: Support NVIDIA format modifiers")
Link: https://lkml.org/lkml/2020/6/30/1251
Signed-off-by: James Jones <jajones@nvidia.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2020-07-31 02:58:23 +03:00
struct nouveau_display * disp = nouveau_display ( drm - > dev ) ;
2020-02-11 02:15:55 +03:00
BUG_ON ( ! tile_mode | | ! kind ) ;
if ( modifier = = DRM_FORMAT_MOD_LINEAR ) {
/* tile_mode will not be used in this case */
* tile_mode = 0 ;
* kind = 0 ;
} else {
/*
* Extract the block height and kind from the corresponding
* modifier fields . See drm_fourcc . h for details .
*/
drm/nouveau: Accept 'legacy' format modifiers
Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers. Existing Mesa
drivers are still aware of only these older
format modifiers which do not differentiate
between different variations of the block linear
layout. When the format modifier support flag was
flipped in the nouveau kernel driver, the X.org
modesetting driver began attempting to use its
format modifier-enabled framebuffer path. Because
the set of format modifiers advertised by the
kernel prior to this change do not intersect with
the set of format modifiers advertised by Mesa,
allocating GBM buffers using format modifiers
fails and the modesetting driver falls back to
non-modifier allocation. However, it still later
queries the modifier of the GBM buffer when
creating its DRM-KMS framebuffer object, receives
the old-format modifier from Mesa, and attempts
to create a framebuffer with it. Since the kernel
is still not aware of these formats, this fails.
Userspace should not be attempting to query format
modifiers of GBM buffers allocated with a non-
format-modifier-aware allocation path, but to
avoid breaking existing userspace behavior, this
change accepts the old-style format modifiers when
creating framebuffers and applying them to planes
by translating them to the equivalent new-style
modifier. To accomplish this, some layout
parameters must be assumed to match properties of
the device targeted by the relevant ioctls. To
avoid perpetuating misuse of the old-style
modifiers, this change does not advertise support
for them. Doing so would imply compatibility
between devices with incompatible memory layouts.
Tested with Xorg 1.20 modesetting driver,
weston@c46c70dac84a4b3030cd05b380f9f410536690fc,
gnome & KDE wayland desktops from Ubuntu 18.04,
and sway 1.5
Reported-by: Kirill A. Shutemov <kirill@shutemov.name>
Fixes: fa4f4c213f5f ("drm/nouveau/kms: Support NVIDIA format modifiers")
Link: https://lkml.org/lkml/2020/6/30/1251
Signed-off-by: James Jones <jajones@nvidia.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2020-07-31 02:58:23 +03:00
if ( ( modifier & ( 0xffull < < 12 ) ) = = 0ull ) {
/* Legacy modifier. Translate to this dev's 'kind.' */
modifier | = disp - > format_modifiers [ 0 ] & ( 0xffull < < 12 ) ;
}
2020-02-11 02:15:55 +03:00
* tile_mode = ( uint32_t ) ( modifier & 0xF ) ;
* kind = ( uint8_t ) ( ( modifier > > 12 ) & 0xFF ) ;
if ( drm - > client . device . info . chipset > = 0xc0 )
* tile_mode < < = 4 ;
}
}
void
nouveau_framebuffer_get_layout ( struct drm_framebuffer * fb ,
uint32_t * tile_mode ,
uint8_t * kind )
{
if ( fb - > flags & DRM_MODE_FB_MODIFIERS ) {
struct nouveau_drm * drm = nouveau_drm ( fb - > dev ) ;
nouveau_decode_mod ( drm , fb - > modifier , tile_mode , kind ) ;
} else {
const struct nouveau_bo * nvbo = nouveau_gem_object ( fb - > obj [ 0 ] ) ;
* tile_mode = nvbo - > mode ;
* kind = nvbo - > kind ;
}
}
drm/nouveau: Accept 'legacy' format modifiers
Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers. Existing Mesa
drivers are still aware of only these older
format modifiers which do not differentiate
between different variations of the block linear
layout. When the format modifier support flag was
flipped in the nouveau kernel driver, the X.org
modesetting driver began attempting to use its
format modifier-enabled framebuffer path. Because
the set of format modifiers advertised by the
kernel prior to this change do not intersect with
the set of format modifiers advertised by Mesa,
allocating GBM buffers using format modifiers
fails and the modesetting driver falls back to
non-modifier allocation. However, it still later
queries the modifier of the GBM buffer when
creating its DRM-KMS framebuffer object, receives
the old-format modifier from Mesa, and attempts
to create a framebuffer with it. Since the kernel
is still not aware of these formats, this fails.
Userspace should not be attempting to query format
modifiers of GBM buffers allocated with a non-
format-modifier-aware allocation path, but to
avoid breaking existing userspace behavior, this
change accepts the old-style format modifiers when
creating framebuffers and applying them to planes
by translating them to the equivalent new-style
modifier. To accomplish this, some layout
parameters must be assumed to match properties of
the device targeted by the relevant ioctls. To
avoid perpetuating misuse of the old-style
modifiers, this change does not advertise support
for them. Doing so would imply compatibility
between devices with incompatible memory layouts.
Tested with Xorg 1.20 modesetting driver,
weston@c46c70dac84a4b3030cd05b380f9f410536690fc,
gnome & KDE wayland desktops from Ubuntu 18.04,
and sway 1.5
Reported-by: Kirill A. Shutemov <kirill@shutemov.name>
Fixes: fa4f4c213f5f ("drm/nouveau/kms: Support NVIDIA format modifiers")
Link: https://lkml.org/lkml/2020/6/30/1251
Signed-off-by: James Jones <jajones@nvidia.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2020-07-31 02:58:23 +03:00
static const u64 legacy_modifiers [ ] = {
DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK ( 0 ) ,
DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK ( 1 ) ,
DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK ( 2 ) ,
DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK ( 3 ) ,
DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK ( 4 ) ,
DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK ( 5 ) ,
DRM_FORMAT_MOD_INVALID
} ;
2020-02-11 02:15:55 +03:00
static int
nouveau_validate_decode_mod ( struct nouveau_drm * drm ,
uint64_t modifier ,
uint32_t * tile_mode ,
uint8_t * kind )
{
struct nouveau_display * disp = nouveau_display ( drm - > dev ) ;
int mod ;
if ( drm - > client . device . info . family < NV_DEVICE_INFO_V0_TESLA ) {
return - EINVAL ;
}
BUG_ON ( ! disp - > format_modifiers ) ;
for ( mod = 0 ;
( disp - > format_modifiers [ mod ] ! = DRM_FORMAT_MOD_INVALID ) & &
( disp - > format_modifiers [ mod ] ! = modifier ) ;
mod + + ) ;
drm/nouveau: Accept 'legacy' format modifiers
Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers. Existing Mesa
drivers are still aware of only these older
format modifiers which do not differentiate
between different variations of the block linear
layout. When the format modifier support flag was
flipped in the nouveau kernel driver, the X.org
modesetting driver began attempting to use its
format modifier-enabled framebuffer path. Because
the set of format modifiers advertised by the
kernel prior to this change do not intersect with
the set of format modifiers advertised by Mesa,
allocating GBM buffers using format modifiers
fails and the modesetting driver falls back to
non-modifier allocation. However, it still later
queries the modifier of the GBM buffer when
creating its DRM-KMS framebuffer object, receives
the old-format modifier from Mesa, and attempts
to create a framebuffer with it. Since the kernel
is still not aware of these formats, this fails.
Userspace should not be attempting to query format
modifiers of GBM buffers allocated with a non-
format-modifier-aware allocation path, but to
avoid breaking existing userspace behavior, this
change accepts the old-style format modifiers when
creating framebuffers and applying them to planes
by translating them to the equivalent new-style
modifier. To accomplish this, some layout
parameters must be assumed to match properties of
the device targeted by the relevant ioctls. To
avoid perpetuating misuse of the old-style
modifiers, this change does not advertise support
for them. Doing so would imply compatibility
between devices with incompatible memory layouts.
Tested with Xorg 1.20 modesetting driver,
weston@c46c70dac84a4b3030cd05b380f9f410536690fc,
gnome & KDE wayland desktops from Ubuntu 18.04,
and sway 1.5
Reported-by: Kirill A. Shutemov <kirill@shutemov.name>
Fixes: fa4f4c213f5f ("drm/nouveau/kms: Support NVIDIA format modifiers")
Link: https://lkml.org/lkml/2020/6/30/1251
Signed-off-by: James Jones <jajones@nvidia.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2020-07-31 02:58:23 +03:00
if ( disp - > format_modifiers [ mod ] = = DRM_FORMAT_MOD_INVALID ) {
for ( mod = 0 ;
( legacy_modifiers [ mod ] ! = DRM_FORMAT_MOD_INVALID ) & &
( legacy_modifiers [ mod ] ! = modifier ) ;
mod + + ) ;
if ( legacy_modifiers [ mod ] = = DRM_FORMAT_MOD_INVALID )
return - EINVAL ;
}
2020-02-11 02:15:55 +03:00
nouveau_decode_mod ( drm , modifier , tile_mode , kind ) ;
return 0 ;
}
2020-02-11 02:15:54 +03:00
static inline uint32_t
nouveau_get_width_in_blocks ( uint32_t stride )
{
/* GOBs per block in the x direction is always one, and GOBs are
* 64 bytes wide
*/
static const uint32_t log_block_width = 6 ;
return ( stride + ( 1 < < log_block_width ) - 1 ) > > log_block_width ;
}
static inline uint32_t
nouveau_get_height_in_blocks ( struct nouveau_drm * drm ,
uint32_t height ,
uint32_t log_block_height_in_gobs )
{
uint32_t log_gob_height ;
uint32_t log_block_height ;
BUG_ON ( drm - > client . device . info . family < NV_DEVICE_INFO_V0_TESLA ) ;
if ( drm - > client . device . info . family < NV_DEVICE_INFO_V0_FERMI )
log_gob_height = 2 ;
else
log_gob_height = 3 ;
log_block_height = log_block_height_in_gobs + log_gob_height ;
return ( height + ( 1 < < log_block_height ) - 1 ) > > log_block_height ;
}
static int
nouveau_check_bl_size ( struct nouveau_drm * drm , struct nouveau_bo * nvbo ,
uint32_t offset , uint32_t stride , uint32_t h ,
uint32_t tile_mode )
{
uint32_t gob_size , bw , bh ;
uint64_t bl_size ;
BUG_ON ( drm - > client . device . info . family < NV_DEVICE_INFO_V0_TESLA ) ;
if ( drm - > client . device . info . chipset > = 0xc0 ) {
if ( tile_mode & 0xF )
return - EINVAL ;
tile_mode > > = 4 ;
}
if ( tile_mode & 0xFFFFFFF0 )
return - EINVAL ;
if ( drm - > client . device . info . family < NV_DEVICE_INFO_V0_FERMI )
gob_size = 256 ;
else
gob_size = 512 ;
bw = nouveau_get_width_in_blocks ( stride ) ;
bh = nouveau_get_height_in_blocks ( drm , h , tile_mode ) ;
bl_size = bw * bh * ( 1 < < tile_mode ) * gob_size ;
2020-12-09 17:07:50 +03:00
DRM_DEBUG_KMS ( " offset=%u stride=%u h=%u tile_mode=0x%02x bw=%u bh=%u gob_size=%u bl_size=%llu size=%zu \n " ,
2020-02-11 02:15:54 +03:00
offset , stride , h , tile_mode , bw , bh , gob_size , bl_size ,
2020-12-09 17:07:50 +03:00
nvbo - > bo . base . size ) ;
2020-02-11 02:15:54 +03:00
2020-12-09 17:07:50 +03:00
if ( bl_size + offset > nvbo - > bo . base . size )
2020-02-11 02:15:54 +03:00
return - ERANGE ;
return 0 ;
}
2010-03-30 09:34:13 +04:00
int
2016-11-04 10:20:35 +03:00
nouveau_framebuffer_new ( struct drm_device * dev ,
const struct drm_mode_fb_cmd2 * mode_cmd ,
2020-02-06 13:19:41 +03:00
struct drm_gem_object * gem ,
2020-02-06 13:19:42 +03:00
struct drm_framebuffer * * pfb )
2009-12-11 12:24:15 +03:00
{
2017-08-06 05:25:02 +03:00
struct nouveau_drm * drm = nouveau_drm ( dev ) ;
2020-02-11 02:15:54 +03:00
struct nouveau_bo * nvbo = nouveau_gem_object ( gem ) ;
2020-02-06 13:19:42 +03:00
struct drm_framebuffer * fb ;
2020-02-11 02:15:54 +03:00
const struct drm_format_info * info ;
2021-02-25 10:51:42 +03:00
unsigned int height , i ;
2020-02-11 02:15:55 +03:00
uint32_t tile_mode ;
uint8_t kind ;
2009-12-11 12:24:15 +03:00
int ret ;
2017-08-06 05:25:02 +03:00
/* YUV overlays have special requirements pre-NV50 */
if ( drm - > client . device . info . family < NV_DEVICE_INFO_V0_TESLA & &
( mode_cmd - > pixel_format = = DRM_FORMAT_YUYV | |
mode_cmd - > pixel_format = = DRM_FORMAT_UYVY | |
mode_cmd - > pixel_format = = DRM_FORMAT_NV12 | |
mode_cmd - > pixel_format = = DRM_FORMAT_NV21 ) & &
( mode_cmd - > pitches [ 0 ] & 0x3f | | /* align 64 */
mode_cmd - > pitches [ 0 ] > = 0x10000 | | /* at most 64k pitch */
( mode_cmd - > pitches [ 1 ] & & /* pitches for planes must match */
mode_cmd - > pitches [ 0 ] ! = mode_cmd - > pitches [ 1 ] ) ) ) {
2021-02-16 18:57:22 +03:00
DRM_DEBUG_KMS ( " Unsuitable framebuffer: format: %p4cc; pitches: 0x%x \n 0x%x \n " ,
& mode_cmd - > pixel_format ,
mode_cmd - > pitches [ 0 ] , mode_cmd - > pitches [ 1 ] ) ;
2017-08-06 05:25:02 +03:00
return - EINVAL ;
}
2020-02-11 02:15:55 +03:00
if ( mode_cmd - > flags & DRM_MODE_FB_MODIFIERS ) {
if ( nouveau_validate_decode_mod ( drm , mode_cmd - > modifier [ 0 ] ,
& tile_mode , & kind ) ) {
DRM_DEBUG_KMS ( " Unsupported modifier: 0x%llx \n " ,
mode_cmd - > modifier [ 0 ] ) ;
return - EINVAL ;
}
} else {
tile_mode = nvbo - > mode ;
kind = nvbo - > kind ;
}
2020-02-11 02:15:54 +03:00
info = drm_get_format_info ( dev , mode_cmd ) ;
for ( i = 0 ; i < info - > num_planes ; i + + ) {
height = drm_format_info_plane_height ( info ,
mode_cmd - > height ,
i ) ;
2020-02-11 02:15:55 +03:00
if ( kind ) {
2020-02-11 02:15:54 +03:00
ret = nouveau_check_bl_size ( drm , nvbo ,
mode_cmd - > offsets [ i ] ,
mode_cmd - > pitches [ i ] ,
2020-02-11 02:15:55 +03:00
height , tile_mode ) ;
2020-02-11 02:15:54 +03:00
if ( ret )
return ret ;
} else {
uint32_t size = mode_cmd - > pitches [ i ] * height ;
2020-12-09 17:07:50 +03:00
if ( size + mode_cmd - > offsets [ i ] > nvbo - > bo . base . size )
2020-02-11 02:15:54 +03:00
return - ERANGE ;
}
}
2016-11-04 10:20:36 +03:00
if ( ! ( fb = * pfb = kzalloc ( sizeof ( * fb ) , GFP_KERNEL ) ) )
2016-11-04 10:20:35 +03:00
return - ENOMEM ;
2011-02-09 04:57:45 +03:00
2020-02-06 13:19:42 +03:00
drm_helper_mode_fill_fb_struct ( dev , fb , mode_cmd ) ;
fb - > obj [ 0 ] = gem ;
2014-08-09 22:10:19 +04:00
2020-02-06 13:19:42 +03:00
ret = drm_framebuffer_init ( dev , fb , & nouveau_framebuffer_funcs ) ;
2016-11-04 10:20:36 +03:00
if ( ret )
kfree ( fb ) ;
2014-08-09 22:10:19 +04:00
return ret ;
2009-12-11 12:24:15 +03:00
}
2016-11-04 10:20:36 +03:00
struct drm_framebuffer *
2009-12-11 12:24:15 +03:00
nouveau_user_framebuffer_create ( struct drm_device * dev ,
struct drm_file * file_priv ,
2015-11-11 20:11:29 +03:00
const struct drm_mode_fb_cmd2 * mode_cmd )
2009-12-11 12:24:15 +03:00
{
2020-02-06 13:19:42 +03:00
struct drm_framebuffer * fb ;
2009-12-11 12:24:15 +03:00
struct drm_gem_object * gem ;
2016-11-04 10:20:35 +03:00
int ret ;
2009-12-11 12:24:15 +03:00
2016-05-09 13:04:54 +03:00
gem = drm_gem_object_lookup ( file_priv , mode_cmd - > handles [ 0 ] ) ;
2009-12-11 12:24:15 +03:00
if ( ! gem )
2010-08-08 16:36:38 +04:00
return ERR_PTR ( - ENOENT ) ;
2009-12-11 12:24:15 +03:00
2020-02-06 13:19:41 +03:00
ret = nouveau_framebuffer_new ( dev , mode_cmd , gem , & fb ) ;
2016-11-04 10:20:35 +03:00
if ( ret = = 0 )
2020-02-06 13:19:42 +03:00
return fb ;
2013-07-08 08:50:54 +04:00
2020-05-15 12:51:05 +03:00
drm_gem_object_put ( gem ) ;
2013-07-08 08:50:54 +04:00
return ERR_PTR ( ret ) ;
2009-12-11 12:24:15 +03:00
}
2011-10-06 06:46:40 +04:00
static const struct drm_mode_config_funcs nouveau_mode_config_funcs = {
2009-12-11 12:24:15 +03:00
. fb_create = nouveau_user_framebuffer_create ,
drm/nouveau/drm/nouveau: Fix deadlock with fb_helper with async RPM requests
Currently, nouveau uses the generic drm_fb_helper_output_poll_changed()
function provided by DRM as it's output_poll_changed callback.
Unfortunately however, this function doesn't grab runtime PM references
early enough and even if it did-we can't block waiting for the device to
resume in output_poll_changed() since it's very likely that we'll need
to grab the fb_helper lock at some point during the runtime resume
process. This currently results in deadlocking like so:
[ 246.669625] INFO: task kworker/4:0:37 blocked for more than 120 seconds.
[ 246.673398] Not tainted 4.18.0-rc5Lyude-Test+ #2
[ 246.675271] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 246.676527] kworker/4:0 D 0 37 2 0x80000000
[ 246.677580] Workqueue: events output_poll_execute [drm_kms_helper]
[ 246.678704] Call Trace:
[ 246.679753] __schedule+0x322/0xaf0
[ 246.680916] schedule+0x33/0x90
[ 246.681924] schedule_preempt_disabled+0x15/0x20
[ 246.683023] __mutex_lock+0x569/0x9a0
[ 246.684035] ? kobject_uevent_env+0x117/0x7b0
[ 246.685132] ? drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper]
[ 246.686179] mutex_lock_nested+0x1b/0x20
[ 246.687278] ? mutex_lock_nested+0x1b/0x20
[ 246.688307] drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper]
[ 246.689420] drm_fb_helper_output_poll_changed+0x23/0x30 [drm_kms_helper]
[ 246.690462] drm_kms_helper_hotplug_event+0x2a/0x30 [drm_kms_helper]
[ 246.691570] output_poll_execute+0x198/0x1c0 [drm_kms_helper]
[ 246.692611] process_one_work+0x231/0x620
[ 246.693725] worker_thread+0x214/0x3a0
[ 246.694756] kthread+0x12b/0x150
[ 246.695856] ? wq_pool_ids_show+0x140/0x140
[ 246.696888] ? kthread_create_worker_on_cpu+0x70/0x70
[ 246.697998] ret_from_fork+0x3a/0x50
[ 246.699034] INFO: task kworker/0:1:60 blocked for more than 120 seconds.
[ 246.700153] Not tainted 4.18.0-rc5Lyude-Test+ #2
[ 246.701182] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 246.702278] kworker/0:1 D 0 60 2 0x80000000
[ 246.703293] Workqueue: pm pm_runtime_work
[ 246.704393] Call Trace:
[ 246.705403] __schedule+0x322/0xaf0
[ 246.706439] ? wait_for_completion+0x104/0x190
[ 246.707393] schedule+0x33/0x90
[ 246.708375] schedule_timeout+0x3a5/0x590
[ 246.709289] ? mark_held_locks+0x58/0x80
[ 246.710208] ? _raw_spin_unlock_irq+0x2c/0x40
[ 246.711222] ? wait_for_completion+0x104/0x190
[ 246.712134] ? trace_hardirqs_on_caller+0xf4/0x190
[ 246.713094] ? wait_for_completion+0x104/0x190
[ 246.713964] wait_for_completion+0x12c/0x190
[ 246.714895] ? wake_up_q+0x80/0x80
[ 246.715727] ? get_work_pool+0x90/0x90
[ 246.716649] flush_work+0x1c9/0x280
[ 246.717483] ? flush_workqueue_prep_pwqs+0x1b0/0x1b0
[ 246.718442] __cancel_work_timer+0x146/0x1d0
[ 246.719247] cancel_delayed_work_sync+0x13/0x20
[ 246.720043] drm_kms_helper_poll_disable+0x1f/0x30 [drm_kms_helper]
[ 246.721123] nouveau_pmops_runtime_suspend+0x3d/0xb0 [nouveau]
[ 246.721897] pci_pm_runtime_suspend+0x6b/0x190
[ 246.722825] ? pci_has_legacy_pm_support+0x70/0x70
[ 246.723737] __rpm_callback+0x7a/0x1d0
[ 246.724721] ? pci_has_legacy_pm_support+0x70/0x70
[ 246.725607] rpm_callback+0x24/0x80
[ 246.726553] ? pci_has_legacy_pm_support+0x70/0x70
[ 246.727376] rpm_suspend+0x142/0x6b0
[ 246.728185] pm_runtime_work+0x97/0xc0
[ 246.728938] process_one_work+0x231/0x620
[ 246.729796] worker_thread+0x44/0x3a0
[ 246.730614] kthread+0x12b/0x150
[ 246.731395] ? wq_pool_ids_show+0x140/0x140
[ 246.732202] ? kthread_create_worker_on_cpu+0x70/0x70
[ 246.732878] ret_from_fork+0x3a/0x50
[ 246.733768] INFO: task kworker/4:2:422 blocked for more than 120 seconds.
[ 246.734587] Not tainted 4.18.0-rc5Lyude-Test+ #2
[ 246.735393] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 246.736113] kworker/4:2 D 0 422 2 0x80000080
[ 246.736789] Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper]
[ 246.737665] Call Trace:
[ 246.738490] __schedule+0x322/0xaf0
[ 246.739250] schedule+0x33/0x90
[ 246.739908] rpm_resume+0x19c/0x850
[ 246.740750] ? finish_wait+0x90/0x90
[ 246.741541] __pm_runtime_resume+0x4e/0x90
[ 246.742370] nv50_disp_atomic_commit+0x31/0x210 [nouveau]
[ 246.743124] drm_atomic_commit+0x4a/0x50 [drm]
[ 246.743775] restore_fbdev_mode_atomic+0x1c8/0x240 [drm_kms_helper]
[ 246.744603] restore_fbdev_mode+0x31/0x140 [drm_kms_helper]
[ 246.745373] drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xb0 [drm_kms_helper]
[ 246.746220] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper]
[ 246.746884] drm_fb_helper_hotplug_event.part.28+0x96/0xb0 [drm_kms_helper]
[ 246.747675] drm_fb_helper_output_poll_changed+0x23/0x30 [drm_kms_helper]
[ 246.748544] drm_kms_helper_hotplug_event+0x2a/0x30 [drm_kms_helper]
[ 246.749439] nv50_mstm_hotplug+0x15/0x20 [nouveau]
[ 246.750111] drm_dp_send_link_address+0x177/0x1c0 [drm_kms_helper]
[ 246.750764] drm_dp_check_and_send_link_address+0xa8/0xd0 [drm_kms_helper]
[ 246.751602] drm_dp_mst_link_probe_work+0x51/0x90 [drm_kms_helper]
[ 246.752314] process_one_work+0x231/0x620
[ 246.752979] worker_thread+0x44/0x3a0
[ 246.753838] kthread+0x12b/0x150
[ 246.754619] ? wq_pool_ids_show+0x140/0x140
[ 246.755386] ? kthread_create_worker_on_cpu+0x70/0x70
[ 246.756162] ret_from_fork+0x3a/0x50
[ 246.756847]
Showing all locks held in the system:
[ 246.758261] 3 locks held by kworker/4:0/37:
[ 246.759016] #0: 00000000f8df4d2d ((wq_completion)"events"){+.+.}, at: process_one_work+0x1b3/0x620
[ 246.759856] #1: 00000000e6065461 ((work_completion)(&(&dev->mode_config.output_poll_work)->work)){+.+.}, at: process_one_work+0x1b3/0x620
[ 246.760670] #2: 00000000cb66735f (&helper->lock){+.+.}, at: drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper]
[ 246.761516] 2 locks held by kworker/0:1/60:
[ 246.762274] #0: 00000000fff6be0f ((wq_completion)"pm"){+.+.}, at: process_one_work+0x1b3/0x620
[ 246.762982] #1: 000000005ab44fb4 ((work_completion)(&dev->power.work)){+.+.}, at: process_one_work+0x1b3/0x620
[ 246.763890] 1 lock held by khungtaskd/64:
[ 246.764664] #0: 000000008cb8b5c3 (rcu_read_lock){....}, at: debug_show_all_locks+0x23/0x185
[ 246.765588] 5 locks held by kworker/4:2/422:
[ 246.766440] #0: 00000000232f0959 ((wq_completion)"events_long"){+.+.}, at: process_one_work+0x1b3/0x620
[ 246.767390] #1: 00000000bb59b134 ((work_completion)(&mgr->work)){+.+.}, at: process_one_work+0x1b3/0x620
[ 246.768154] #2: 00000000cb66735f (&helper->lock){+.+.}, at: drm_fb_helper_restore_fbdev_mode_unlocked+0x4c/0xb0 [drm_kms_helper]
[ 246.768966] #3: 000000004c8f0b6b (crtc_ww_class_acquire){+.+.}, at: restore_fbdev_mode_atomic+0x4b/0x240 [drm_kms_helper]
[ 246.769921] #4: 000000004c34a296 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_backoff+0x8a/0x1b0 [drm]
[ 246.770839] 1 lock held by dmesg/1038:
[ 246.771739] 2 locks held by zsh/1172:
[ 246.772650] #0: 00000000836d0438 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40
[ 246.773680] #1: 000000001f4f4d48 (&ldata->atomic_read_lock){+.+.}, at: n_tty_read+0xc1/0x870
[ 246.775522] =============================================
After trying dozens of different solutions, I found one very simple one
that should also have the benefit of preventing us from having to fight
locking for the rest of our lives. So, we work around these deadlocks by
deferring all fbcon hotplug events that happen after the runtime suspend
process starts until after the device is resumed again.
Changes since v7:
- Fixup commit message - Daniel Vetter
Changes since v6:
- Remove unused nouveau_fbcon_hotplugged_in_suspend() - Ilia
Changes since v5:
- Come up with the (hopefully final) solution for solving this dumb
problem, one that is a lot less likely to cause issues with locking in
the future. This should work around all deadlock conditions with fbcon
brought up thus far.
Changes since v4:
- Add nouveau_fbcon_hotplugged_in_suspend() to workaround deadlock
condition that Lukas described
- Just move all of this out of drm_fb_helper. It seems that other DRM
drivers have already figured out other workarounds for this. If other
drivers do end up needing this in the future, we can just move this
back into drm_fb_helper again.
Changes since v3:
- Actually check if fb_helper is NULL in both new helpers
- Actually check drm_fbdev_emulation in both new helpers
- Don't fire off a fb_helper hotplug unconditionally; only do it if
the following conditions are true (as otherwise, calling this in the
wrong spot will cause Bad Things to happen):
- fb_helper hotplug handling was actually inhibited previously
- fb_helper actually has a delayed hotplug pending
- fb_helper is actually bound
- fb_helper is actually initialized
- Add __must_check to drm_fb_helper_suspend_hotplug(). There's no
situation where a driver would actually want to use this without
checking the return value, so enforce that
- Rewrite and clarify the documentation for both helpers.
- Make sure to return true in the drm_fb_helper_suspend_hotplug() stub
that's provided in drm_fb_helper.h when CONFIG_DRM_FBDEV_EMULATION
isn't enabled
- Actually grab the toplevel fb_helper lock in
drm_fb_helper_resume_hotplug(), since it's possible other activity
(such as a hotplug) could be going on at the same time the driver
calls drm_fb_helper_resume_hotplug(). We need this to check whether or
not drm_fb_helper_hotplug_event() needs to be called anyway
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Cc: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-08-15 22:00:13 +03:00
. output_poll_changed = nouveau_fbcon_output_poll_changed ,
2009-12-11 12:24:15 +03:00
} ;
2011-10-06 07:29:05 +04:00
2012-02-06 13:58:17 +04:00
struct nouveau_drm_prop_enum_list {
2011-10-17 06:23:41 +04:00
u8 gen_mask ;
2011-10-06 07:29:05 +04:00
int type ;
char * name ;
} ;
2012-02-06 13:58:17 +04:00
static struct nouveau_drm_prop_enum_list underscan [ ] = {
2011-11-11 17:49:06 +04:00
{ 6 , UNDERSCAN_AUTO , " auto " } ,
{ 6 , UNDERSCAN_OFF , " off " } ,
{ 6 , UNDERSCAN_ON , " on " } ,
2011-10-17 06:23:41 +04:00
{ }
2011-10-06 07:29:05 +04:00
} ;
2012-02-06 13:58:17 +04:00
static struct nouveau_drm_prop_enum_list dither_mode [ ] = {
2011-10-17 06:23:41 +04:00
{ 7 , DITHERING_MODE_AUTO , " auto " } ,
{ 7 , DITHERING_MODE_OFF , " off " } ,
{ 1 , DITHERING_MODE_ON , " on " } ,
{ 6 , DITHERING_MODE_STATIC2X2 , " static 2x2 " } ,
{ 6 , DITHERING_MODE_DYNAMIC2X2 , " dynamic 2x2 " } ,
{ 4 , DITHERING_MODE_TEMPORAL , " temporal " } ,
{ }
} ;
2012-02-06 13:58:17 +04:00
static struct nouveau_drm_prop_enum_list dither_depth [ ] = {
2011-10-17 06:23:41 +04:00
{ 6 , DITHERING_DEPTH_AUTO , " auto " } ,
{ 6 , DITHERING_DEPTH_6BPC , " 6 bpc " } ,
{ 6 , DITHERING_DEPTH_8BPC , " 8 bpc " } ,
{ }
} ;
# define PROP_ENUM(p,gen,n,list) do { \
2012-02-06 13:58:17 +04:00
struct nouveau_drm_prop_enum_list * l = ( list ) ; \
2011-10-17 06:23:41 +04:00
int c = 0 ; \
while ( l - > gen_mask ) { \
if ( l - > gen_mask & ( 1 < < ( gen ) ) ) \
c + + ; \
l + + ; \
} \
if ( c ) { \
p = drm_property_create ( dev , DRM_MODE_PROP_ENUM , n , c ) ; \
l = ( list ) ; \
while ( p & & l - > gen_mask ) { \
if ( l - > gen_mask & ( 1 < < ( gen ) ) ) { \
2018-03-16 22:04:20 +03:00
drm_property_add_enum ( p , l - > type , l - > name ) ; \
2011-10-17 06:23:41 +04:00
} \
l + + ; \
} \
} \
} while ( 0 )
2020-08-26 21:24:48 +03:00
void
nouveau_display_hpd_resume ( struct drm_device * dev )
{
struct nouveau_drm * drm = nouveau_drm ( dev ) ;
mutex_lock ( & drm - > hpd_lock ) ;
drm - > hpd_pending = ~ 0 ;
mutex_unlock ( & drm - > hpd_lock ) ;
schedule_work ( & drm - > hpd_work ) ;
}
2016-11-09 20:17:44 +03:00
static void
2016-11-21 19:50:54 +03:00
nouveau_display_hpd_work ( struct work_struct * work )
2016-11-09 20:17:44 +03:00
{
2016-11-21 19:50:54 +03:00
struct nouveau_drm * drm = container_of ( work , typeof ( * drm ) , hpd_work ) ;
2020-08-26 21:24:48 +03:00
struct drm_device * dev = drm - > dev ;
struct drm_connector * connector ;
struct drm_connector_list_iter conn_iter ;
u32 pending ;
bool changed = false ;
pm_runtime_get_sync ( dev - > dev ) ;
2016-11-09 20:17:44 +03:00
2020-08-26 21:24:48 +03:00
mutex_lock ( & drm - > hpd_lock ) ;
pending = drm - > hpd_pending ;
drm - > hpd_pending = 0 ;
mutex_unlock ( & drm - > hpd_lock ) ;
2016-11-09 20:17:44 +03:00
2020-08-26 21:24:48 +03:00
/* Nothing to do, exit early without updating the last busy counter */
if ( ! pending )
goto noop ;
mutex_lock ( & dev - > mode_config . mutex ) ;
drm_connector_list_iter_begin ( dev , & conn_iter ) ;
nouveau_for_each_non_mst_connector_iter ( connector , & conn_iter ) {
enum drm_connector_status old_status = connector - > status ;
u64 old_epoch_counter = connector - > epoch_counter ;
if ( ! ( pending & drm_connector_mask ( connector ) ) )
continue ;
connector - > status = drm_helper_probe_detect ( connector , NULL ,
false ) ;
if ( old_epoch_counter = = connector - > epoch_counter )
continue ;
changed = true ;
drm_dbg_kms ( dev , " [CONNECTOR:%d:%s] status updated from %s to %s (epoch counter %llu->%llu) \n " ,
connector - > base . id , connector - > name ,
drm_get_connector_status_name ( old_status ) ,
drm_get_connector_status_name ( connector - > status ) ,
old_epoch_counter , connector - > epoch_counter ) ;
}
drm_connector_list_iter_end ( & conn_iter ) ;
mutex_unlock ( & dev - > mode_config . mutex ) ;
if ( changed )
drm_kms_helper_hotplug_event ( dev ) ;
2016-11-09 20:17:44 +03:00
pm_runtime_mark_last_busy ( drm - > dev - > dev ) ;
2020-08-26 21:24:48 +03:00
noop :
2016-11-09 20:17:44 +03:00
pm_runtime_put_sync ( drm - > dev - > dev ) ;
}
2016-11-21 19:50:54 +03:00
# ifdef CONFIG_ACPI
2016-11-09 20:17:44 +03:00
static int
nouveau_display_acpi_ntfy ( struct notifier_block * nb , unsigned long val ,
void * data )
{
struct nouveau_drm * drm = container_of ( nb , typeof ( * drm ) , acpi_nb ) ;
struct acpi_bus_event * info = data ;
drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events too early
On most systems with ACPI hotplugging support, it seems that we always
receive a hotplug event once we re-enable EC interrupts even if the GPU
hasn't even been resumed yet.
This can cause problems since even though we schedule hpd_work to handle
connector reprobing for us, hpd_work synchronizes on
pm_runtime_get_sync() to wait until the device is ready to perform
reprobing. Since runtime suspend/resume callbacks are disabled before
the PM core calls ->suspend(), any calls to pm_runtime_get_sync() during
this period will grab a runtime PM ref and return immediately with
-EACCES. Because we schedule hpd_work from our ACPI HPD handler, and
hpd_work synchronizes on pm_runtime_get_sync(), this causes us to launch
a connector reprobe immediately even if the GPU isn't actually resumed
just yet. This causes various warnings in dmesg and occasionally, also
prevents some displays connected to the dedicated GPU from coming back
up after suspend. Example:
usb 1-4: USB disconnect, device number 14
usb 1-4.1: USB disconnect, device number 15
WARNING: CPU: 0 PID: 838 at drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h:170 nouveau_dp_detect+0x17e/0x370 [nouveau]
CPU: 0 PID: 838 Comm: kworker/0:6 Not tainted 4.17.14-201.Lyude.bz1477182.V3.fc28.x86_64 #1
Hardware name: LENOVO 20EQS64N00/20EQS64N00, BIOS N1EET77W (1.50 ) 03/28/2018
Workqueue: events nouveau_display_hpd_work [nouveau]
RIP: 0010:nouveau_dp_detect+0x17e/0x370 [nouveau]
RSP: 0018:ffffa15143933cf0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8cb4f656c400 RCX: 0000000000000000
RDX: ffffa1514500e4e4 RSI: ffffa1514500e4e4 RDI: 0000000001009002
RBP: ffff8cb4f4a8a800 R08: ffffa15143933cfd R09: ffffa15143933cfc
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8cb4fb57a000
R13: ffff8cb4fb57a000 R14: ffff8cb4f4a8f800 R15: ffff8cb4f656c418
FS: 0000000000000000(0000) GS:ffff8cb51f400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f78ec938000 CR3: 000000073720a003 CR4: 00000000003606f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
? _cond_resched+0x15/0x30
nouveau_connector_detect+0x2ce/0x520 [nouveau]
? _cond_resched+0x15/0x30
? ww_mutex_lock+0x12/0x40
drm_helper_probe_detect_ctx+0x8b/0xe0 [drm_kms_helper]
drm_helper_hpd_irq_event+0xa8/0x120 [drm_kms_helper]
nouveau_display_hpd_work+0x2a/0x60 [nouveau]
process_one_work+0x187/0x340
worker_thread+0x2e/0x380
? pwq_unbound_release_workfn+0xd0/0xd0
kthread+0x112/0x130
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x35/0x40
Code: 4c 8d 44 24 0d b9 00 05 00 00 48 89 ef ba 09 00 00 00 be 01 00 00 00 e8 e1 09 f8 ff 85 c0 0f 85 b2 01 00 00 80 7c 24 0c 03 74 02 <0f> 0b 48 89 ef e8 b8 07 f8 ff f6 05 51 1b c8 ff 02 0f 84 72 ff
---[ end trace 55d811b38fc8e71a ]---
So, to fix this we attempt to grab a runtime PM reference in the ACPI
handler itself asynchronously. If the GPU is already awake (it will have
normal hotplugging at this point) or runtime PM callbacks are currently
disabled on the device, we drop our reference without updating the
autosuspend delay. We only schedule connector reprobes when we
successfully managed to queue up a resume request with our asynchronous
PM ref.
This also has the added benefit of preventing redundant connector
reprobes from ACPI while the GPU is runtime resumed!
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: stable@vger.kernel.org
Cc: Karol Herbst <kherbst@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1477182#c41
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-08-16 23:13:13 +03:00
int ret ;
2016-11-09 20:17:44 +03:00
if ( ! strcmp ( info - > device_class , ACPI_VIDEO_CLASS ) ) {
if ( info - > type = = ACPI_VIDEO_NOTIFY_PROBE ) {
drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events too early
On most systems with ACPI hotplugging support, it seems that we always
receive a hotplug event once we re-enable EC interrupts even if the GPU
hasn't even been resumed yet.
This can cause problems since even though we schedule hpd_work to handle
connector reprobing for us, hpd_work synchronizes on
pm_runtime_get_sync() to wait until the device is ready to perform
reprobing. Since runtime suspend/resume callbacks are disabled before
the PM core calls ->suspend(), any calls to pm_runtime_get_sync() during
this period will grab a runtime PM ref and return immediately with
-EACCES. Because we schedule hpd_work from our ACPI HPD handler, and
hpd_work synchronizes on pm_runtime_get_sync(), this causes us to launch
a connector reprobe immediately even if the GPU isn't actually resumed
just yet. This causes various warnings in dmesg and occasionally, also
prevents some displays connected to the dedicated GPU from coming back
up after suspend. Example:
usb 1-4: USB disconnect, device number 14
usb 1-4.1: USB disconnect, device number 15
WARNING: CPU: 0 PID: 838 at drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h:170 nouveau_dp_detect+0x17e/0x370 [nouveau]
CPU: 0 PID: 838 Comm: kworker/0:6 Not tainted 4.17.14-201.Lyude.bz1477182.V3.fc28.x86_64 #1
Hardware name: LENOVO 20EQS64N00/20EQS64N00, BIOS N1EET77W (1.50 ) 03/28/2018
Workqueue: events nouveau_display_hpd_work [nouveau]
RIP: 0010:nouveau_dp_detect+0x17e/0x370 [nouveau]
RSP: 0018:ffffa15143933cf0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8cb4f656c400 RCX: 0000000000000000
RDX: ffffa1514500e4e4 RSI: ffffa1514500e4e4 RDI: 0000000001009002
RBP: ffff8cb4f4a8a800 R08: ffffa15143933cfd R09: ffffa15143933cfc
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8cb4fb57a000
R13: ffff8cb4fb57a000 R14: ffff8cb4f4a8f800 R15: ffff8cb4f656c418
FS: 0000000000000000(0000) GS:ffff8cb51f400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f78ec938000 CR3: 000000073720a003 CR4: 00000000003606f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
? _cond_resched+0x15/0x30
nouveau_connector_detect+0x2ce/0x520 [nouveau]
? _cond_resched+0x15/0x30
? ww_mutex_lock+0x12/0x40
drm_helper_probe_detect_ctx+0x8b/0xe0 [drm_kms_helper]
drm_helper_hpd_irq_event+0xa8/0x120 [drm_kms_helper]
nouveau_display_hpd_work+0x2a/0x60 [nouveau]
process_one_work+0x187/0x340
worker_thread+0x2e/0x380
? pwq_unbound_release_workfn+0xd0/0xd0
kthread+0x112/0x130
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x35/0x40
Code: 4c 8d 44 24 0d b9 00 05 00 00 48 89 ef ba 09 00 00 00 be 01 00 00 00 e8 e1 09 f8 ff 85 c0 0f 85 b2 01 00 00 80 7c 24 0c 03 74 02 <0f> 0b 48 89 ef e8 b8 07 f8 ff f6 05 51 1b c8 ff 02 0f 84 72 ff
---[ end trace 55d811b38fc8e71a ]---
So, to fix this we attempt to grab a runtime PM reference in the ACPI
handler itself asynchronously. If the GPU is already awake (it will have
normal hotplugging at this point) or runtime PM callbacks are currently
disabled on the device, we drop our reference without updating the
autosuspend delay. We only schedule connector reprobes when we
successfully managed to queue up a resume request with our asynchronous
PM ref.
This also has the added benefit of preventing redundant connector
reprobes from ACPI while the GPU is runtime resumed!
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: stable@vger.kernel.org
Cc: Karol Herbst <kherbst@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1477182#c41
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-08-16 23:13:13 +03:00
ret = pm_runtime_get ( drm - > dev - > dev ) ;
if ( ret = = 1 | | ret = = - EACCES ) {
/* If the GPU is already awake, or in a state
* where we can ' t wake it up , it can handle
* it ' s own hotplug events .
*/
pm_runtime_put_autosuspend ( drm - > dev - > dev ) ;
} else if ( ret = = 0 ) {
2020-08-26 21:24:48 +03:00
/* We've started resuming the GPU already, so
* it will handle scheduling a full reprobe
* itself
drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events too early
On most systems with ACPI hotplugging support, it seems that we always
receive a hotplug event once we re-enable EC interrupts even if the GPU
hasn't even been resumed yet.
This can cause problems since even though we schedule hpd_work to handle
connector reprobing for us, hpd_work synchronizes on
pm_runtime_get_sync() to wait until the device is ready to perform
reprobing. Since runtime suspend/resume callbacks are disabled before
the PM core calls ->suspend(), any calls to pm_runtime_get_sync() during
this period will grab a runtime PM ref and return immediately with
-EACCES. Because we schedule hpd_work from our ACPI HPD handler, and
hpd_work synchronizes on pm_runtime_get_sync(), this causes us to launch
a connector reprobe immediately even if the GPU isn't actually resumed
just yet. This causes various warnings in dmesg and occasionally, also
prevents some displays connected to the dedicated GPU from coming back
up after suspend. Example:
usb 1-4: USB disconnect, device number 14
usb 1-4.1: USB disconnect, device number 15
WARNING: CPU: 0 PID: 838 at drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h:170 nouveau_dp_detect+0x17e/0x370 [nouveau]
CPU: 0 PID: 838 Comm: kworker/0:6 Not tainted 4.17.14-201.Lyude.bz1477182.V3.fc28.x86_64 #1
Hardware name: LENOVO 20EQS64N00/20EQS64N00, BIOS N1EET77W (1.50 ) 03/28/2018
Workqueue: events nouveau_display_hpd_work [nouveau]
RIP: 0010:nouveau_dp_detect+0x17e/0x370 [nouveau]
RSP: 0018:ffffa15143933cf0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8cb4f656c400 RCX: 0000000000000000
RDX: ffffa1514500e4e4 RSI: ffffa1514500e4e4 RDI: 0000000001009002
RBP: ffff8cb4f4a8a800 R08: ffffa15143933cfd R09: ffffa15143933cfc
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8cb4fb57a000
R13: ffff8cb4fb57a000 R14: ffff8cb4f4a8f800 R15: ffff8cb4f656c418
FS: 0000000000000000(0000) GS:ffff8cb51f400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f78ec938000 CR3: 000000073720a003 CR4: 00000000003606f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
? _cond_resched+0x15/0x30
nouveau_connector_detect+0x2ce/0x520 [nouveau]
? _cond_resched+0x15/0x30
? ww_mutex_lock+0x12/0x40
drm_helper_probe_detect_ctx+0x8b/0xe0 [drm_kms_helper]
drm_helper_hpd_irq_event+0xa8/0x120 [drm_kms_helper]
nouveau_display_hpd_work+0x2a/0x60 [nouveau]
process_one_work+0x187/0x340
worker_thread+0x2e/0x380
? pwq_unbound_release_workfn+0xd0/0xd0
kthread+0x112/0x130
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x35/0x40
Code: 4c 8d 44 24 0d b9 00 05 00 00 48 89 ef ba 09 00 00 00 be 01 00 00 00 e8 e1 09 f8 ff 85 c0 0f 85 b2 01 00 00 80 7c 24 0c 03 74 02 <0f> 0b 48 89 ef e8 b8 07 f8 ff f6 05 51 1b c8 ff 02 0f 84 72 ff
---[ end trace 55d811b38fc8e71a ]---
So, to fix this we attempt to grab a runtime PM reference in the ACPI
handler itself asynchronously. If the GPU is already awake (it will have
normal hotplugging at this point) or runtime PM callbacks are currently
disabled on the device, we drop our reference without updating the
autosuspend delay. We only schedule connector reprobes when we
successfully managed to queue up a resume request with our asynchronous
PM ref.
This also has the added benefit of preventing redundant connector
reprobes from ACPI while the GPU is runtime resumed!
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: stable@vger.kernel.org
Cc: Karol Herbst <kherbst@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1477182#c41
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-08-16 23:13:13 +03:00
*/
NV_DEBUG ( drm , " ACPI requested connector reprobe \n " ) ;
pm_runtime_put_noidle ( drm - > dev - > dev ) ;
} else {
NV_WARN ( drm , " Dropped ACPI reprobe event due to RPM error: %d \n " ,
ret ) ;
}
2016-11-09 20:17:44 +03:00
/* acpi-video should not generate keypresses for this */
return NOTIFY_BAD ;
}
}
return NOTIFY_DONE ;
}
# endif
2011-11-09 09:18:47 +04:00
int
2019-02-12 15:28:13 +03:00
nouveau_display_init ( struct drm_device * dev , bool resume , bool runtime )
2011-11-09 09:18:47 +04:00
{
2012-07-31 10:16:21 +04:00
struct nouveau_display * disp = nouveau_display ( dev ) ;
2011-11-24 06:59:44 +04:00
struct drm_connector * connector ;
2018-07-13 20:06:32 +03:00
struct drm_connector_list_iter conn_iter ;
2011-11-09 09:18:47 +04:00
int ret ;
2019-10-01 02:03:29 +03:00
/*
* Enable hotplug interrupts ( done as early as possible , since we need
* them for MST )
*/
drm_connector_list_iter_begin ( dev , & conn_iter ) ;
nouveau_for_each_non_mst_connector_iter ( connector , & conn_iter ) {
struct nouveau_connector * conn = nouveau_connector ( connector ) ;
nvif_notify_get ( & conn - > hpd ) ;
}
drm_connector_list_iter_end ( & conn_iter ) ;
2019-02-12 15:28:13 +03:00
ret = disp - > init ( dev , resume , runtime ) ;
2011-11-24 06:59:44 +04:00
if ( ret )
return ret ;
2018-08-15 22:00:11 +03:00
/* enable connector detection and polling for connectors without HPD
* support
*/
drm_kms_helper_poll_enable ( dev ) ;
2011-11-09 09:18:47 +04:00
return ret ;
}
void
2018-08-08 00:32:48 +03:00
nouveau_display_fini ( struct drm_device * dev , bool suspend , bool runtime )
2011-11-09 09:18:47 +04:00
{
2012-07-31 10:16:21 +04:00
struct nouveau_display * disp = nouveau_display ( dev ) ;
2015-08-20 07:54:18 +03:00
struct nouveau_drm * drm = nouveau_drm ( dev ) ;
2011-11-24 06:59:44 +04:00
struct drm_connector * connector ;
2018-07-13 20:06:32 +03:00
struct drm_connector_list_iter conn_iter ;
drm/nouveau: Dis/Enable vblank irqs during suspend/resume.
Vblank irqs don't get disabled during suspend or driver
unload, which causes irq delivery after "suspend" or
driver unload, at least until the gpu is powered off.
This could race with drm_vblank_cleanup() in the case
of nouveau and cause a use-after-free bug if the driver
is unloaded.
More annoyingly during everyday use, at least on nv50
display engine (likely also others), vblank irqs are
off after a resume from suspend, but the drm doesn't
know this, so all vblank related functionality is dead
after a resume. E.g., all windowed OpenGL clients will
hang at swapbuffers time, as well as many fullscreen
clients in many cases. This makes suspend/resume useless
if one wants to use any OpenGL apps after the resume.
In Linux 3.16, drm_vblank_on() was added, complementing
the older drm_vblank_off() to solve these problems
elegantly, so use those calls in nouveaus suspend/resume
code.
For kernels 3.8 - 3.15, we need to cherry-pick the
drm_vblank_on() patch to support this patch.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: <stable@vger.kernel.org> #v3.16
Cc: <stable@vger.kernel.org> #v3.8+: f275228: drm: Add drm_vblank_on()
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-07-29 04:36:44 +04:00
2017-03-21 19:41:49 +03:00
if ( ! suspend ) {
if ( drm_drv_uses_atomic_modeset ( dev ) )
drm_atomic_helper_shutdown ( dev ) ;
else
2018-12-17 22:43:00 +03:00
drm_helper_force_disable_all ( dev ) ;
2017-03-21 19:41:49 +03:00
}
2016-11-04 10:20:35 +03:00
2011-11-24 06:59:44 +04:00
/* disable hotplug interrupts */
2018-07-13 20:06:32 +03:00
drm_connector_list_iter_begin ( dev , & conn_iter ) ;
2018-07-13 20:06:33 +03:00
nouveau_for_each_non_mst_connector_iter ( connector , & conn_iter ) {
2011-11-24 06:59:44 +04:00
struct nouveau_connector * conn = nouveau_connector ( connector ) ;
2014-08-09 22:10:28 +04:00
nvif_notify_put ( & conn - > hpd ) ;
2011-11-24 06:59:44 +04:00
}
2018-07-13 20:06:32 +03:00
drm_connector_list_iter_end ( & conn_iter ) ;
2011-11-09 09:18:47 +04:00
2018-08-08 00:32:48 +03:00
if ( ! runtime )
cancel_work_sync ( & drm - > hpd_work ) ;
2011-11-09 09:18:47 +04:00
drm_kms_helper_poll_disable ( dev ) ;
drm/nouveau/kms/nv50-: Refactor and cleanup DP HPD handling
First some backstory here: Currently, we keep track of whether or not
we've enabled MST or not by trying to piggy-back off the MST helpers.
This means that in order to check whether MST is enabled or not, we
actually need to grab drm_dp_mst_topology_mgr.lock.
Back when I originally wrote this, I did this piggy-backing with the
intention that I'd eventually be teaching our MST helpers how to recover
when an MST device has stopped responding, which in turn would require
the MST helpers having a way of disabling MST independently of the
driver. Note that this was before I reworked locking in the MST helpers,
so at the time we were sticking random things under &mgr->lock - which
grabbing this lock was meant to protect against.
This never came to fruition because doing such a reset safely turned out
to be a lot more painful and impossible then it sounds, and also just
risks us working around issues with our MST handlers that should be
properly fixed instead. Even if it did though, simply calling
drm_dp_mst_topology_mgr_set_mst() from the MST helpers (with the
exception of when we're tearing down our MST managers, that's always OK)
wouldn't have been a bad idea, since drivers like nouveau and i915 need
to do their own book keeping immediately after disabling MST.
So-implementing that would likely require adding a hook for
helper-triggered MST disables anyway.
So, fast forward to now - we want to start adding support for all of the
miscellaneous bits of the DP protocol (for both SST and MST) we're
missing before moving on to supporting more complicated features like
supporting different BPP values on MST, DSC, etc. Since many of these
features only exist on SST and make use of DP HPD IRQs, we want to be
able to atomically check whether we're servicing an MST IRQ or SST IRQ
in nouveau_connector_hotplug(). Currently we literally don't do this at
all, and just handle any kind of possible DP IRQ we could get including
ESIs - even if MST isn't actually enabled.
This would be very complicated and difficult to fix if we need to hold
&mgr->lock while handling SST IRQs to ensure that the MST topology
state doesn't change under us. What we really want here is to do our own
tracking of whether MST is enabled or not, similar to drivers like i915,
and define our own locking order to decomplicate things and avoid
hitting locking issues in the future.
So, let's do this by refactoring our MST probing/enabling code to use
our own MST bookkeeping, along with adding a lock for protecting DP
state that needs to be checked outside of our connector probing
functions. While we're at it, we also remove a bunch of unneeded steps
we perform when probing/enabling MST:
* Enabling bits in MSTM_CTRL before calling drm_dp_mst_topology_mgr_set_mst().
I don't think these ever actually did anything, since the nvif methods
for enabling MST don't actually do anything DPCD related and merely
indicate to nvkm that we've turned on MST.
* Checking the MSTM_CTRL bit is intact when checking the state of an
enabled MST topology in nv50_mstm_detect(). I just added this to be safe
originally, but now that we try reading the DPCD when probing DP
connectors it shouldn't be needed as that will abort our hotplug probing
if the device was removed well before we start checking for MST..
* All of the duplicate DPCD version checks.
This leaves us with much nicer looking code, a much more sensible
locking scheme, and an easy way of checking whether MST is enabled or
not for handling DP HPD IRQs.
v2:
* Get rid of accidental newlines
v4:
* Fix uninitialized usage of mstm in nv50_mstm_detect() - thanks kernel
bot!
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-9-lyude@redhat.com
2020-08-26 21:24:44 +03:00
disp - > fini ( dev , runtime , suspend ) ;
2011-11-09 09:18:47 +04:00
}
2014-08-09 22:10:21 +04:00
static void
nouveau_display_create_properties ( struct drm_device * dev )
2011-10-06 06:46:40 +04:00
{
2014-08-09 22:10:21 +04:00
struct nouveau_display * disp = nouveau_display ( dev ) ;
int gen ;
2011-10-17 06:23:41 +04:00
2018-05-08 13:39:47 +03:00
if ( disp - > disp . object . oclass < NV50_DISP )
2011-10-17 06:23:41 +04:00
gen = 0 ;
else
2018-05-08 13:39:47 +03:00
if ( disp - > disp . object . oclass < GF110_DISP )
2011-10-17 06:23:41 +04:00
gen = 1 ;
else
gen = 2 ;
PROP_ENUM ( disp - > dithering_mode , gen , " dithering mode " , dither_mode ) ;
PROP_ENUM ( disp - > dithering_depth , gen , " dithering depth " , dither_depth ) ;
PROP_ENUM ( disp - > underscan_property , gen , " underscan " , underscan ) ;
2011-10-06 07:29:05 +04:00
disp - > underscan_hborder_property =
2012-02-06 13:58:18 +04:00
drm_property_create_range ( dev , 0 , " underscan hborder " , 0 , 128 ) ;
2011-10-06 07:29:05 +04:00
disp - > underscan_vborder_property =
2012-02-06 13:58:18 +04:00
drm_property_create_range ( dev , 0 , " underscan vborder " , 0 , 128 ) ;
2011-10-06 07:29:05 +04:00
2014-08-09 22:10:21 +04:00
if ( gen < 1 )
return ;
2012-01-22 02:13:26 +04:00
2014-08-09 22:10:21 +04:00
/* -90..+90 */
disp - > vibrant_hue_property =
drm_property_create_range ( dev , 0 , " vibrant hue " , 0 , 180 ) ;
/* -100..+100 */
disp - > color_vibrance_property =
drm_property_create_range ( dev , 0 , " color vibrance " , 0 , 200 ) ;
}
int
nouveau_display_create ( struct drm_device * dev )
{
struct nouveau_drm * drm = nouveau_drm ( dev ) ;
2016-05-18 06:57:42 +03:00
struct nvkm_device * device = nvxx_device ( & drm - > client . device ) ;
2014-08-09 22:10:21 +04:00
struct nouveau_display * disp ;
int ret ;
disp = drm - > display = kzalloc ( sizeof ( * disp ) , GFP_KERNEL ) ;
if ( ! disp )
return - ENOMEM ;
drm_mode_config_init ( dev ) ;
drm_mode_create_scaling_mode_property ( dev ) ;
drm_mode_create_dvi_i_properties ( dev ) ;
2012-01-22 02:13:26 +04:00
2012-05-17 15:27:23 +04:00
dev - > mode_config . funcs = & nouveau_mode_config_funcs ;
2015-08-20 07:54:23 +03:00
dev - > mode_config . fb_base = device - > func - > resource_addr ( device , 1 ) ;
2011-10-06 06:46:40 +04:00
dev - > mode_config . min_width = 0 ;
dev - > mode_config . min_height = 0 ;
2016-05-18 06:57:42 +03:00
if ( drm - > client . device . info . family < NV_DEVICE_INFO_V0_CELSIUS ) {
2011-10-06 06:46:40 +04:00
dev - > mode_config . max_width = 2048 ;
dev - > mode_config . max_height = 2048 ;
} else
2016-05-18 06:57:42 +03:00
if ( drm - > client . device . info . family < NV_DEVICE_INFO_V0_TESLA ) {
2011-10-06 06:46:40 +04:00
dev - > mode_config . max_width = 4096 ;
dev - > mode_config . max_height = 4096 ;
2015-09-18 05:31:20 +03:00
} else
2016-05-18 06:57:42 +03:00
if ( drm - > client . device . info . family < NV_DEVICE_INFO_V0_FERMI ) {
2011-10-06 06:46:40 +04:00
dev - > mode_config . max_width = 8192 ;
dev - > mode_config . max_height = 8192 ;
2015-09-18 05:31:20 +03:00
} else {
dev - > mode_config . max_width = 16384 ;
dev - > mode_config . max_height = 16384 ;
2011-10-06 06:46:40 +04:00
}
2012-02-20 18:39:11 +04:00
dev - > mode_config . preferred_depth = 24 ;
dev - > mode_config . prefer_shadow = 1 ;
2016-05-18 06:57:42 +03:00
if ( drm - > client . device . info . chipset < 0x11 )
2013-11-11 07:59:40 +04:00
dev - > mode_config . async_page_flip = false ;
else
dev - > mode_config . async_page_flip = true ;
2011-11-09 09:18:47 +04:00
drm_kms_helper_poll_init ( dev ) ;
drm_kms_helper_poll_disable ( dev ) ;
2014-08-09 22:10:31 +04:00
if ( nouveau_modeset ! = 2 & & drm - > vbios . dcb . entries ) {
2020-03-30 07:03:20 +03:00
ret = nvif_disp_ctor ( & drm - > client . device , " kmsDisp " , 0 ,
& disp - > disp ) ;
2014-01-22 06:58:12 +04:00
if ( ret = = 0 ) {
2014-08-09 22:10:21 +04:00
nouveau_display_create_properties ( dev ) ;
2018-05-08 13:39:47 +03:00
if ( disp - > disp . object . oclass < NV50_DISP )
2014-01-22 06:58:12 +04:00
ret = nv04_display_create ( dev ) ;
else
ret = nv50_display_create ( dev ) ;
}
2013-09-10 07:20:34 +04:00
} else {
ret = 0 ;
}
2012-10-31 06:11:15 +04:00
2013-09-10 07:20:34 +04:00
if ( ret )
goto disp_create_err ;
2012-10-31 06:11:15 +04:00
2016-11-04 10:20:35 +03:00
drm_mode_config_reset ( dev ) ;
2013-09-10 07:20:34 +04:00
if ( dev - > mode_config . num_crtc ) {
drm/nouveau/kms/nvd9-: Add CRC support
This introduces support for CRC readback on gf119+, using the
documentation generously provided to us by Nvidia:
https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt
We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed
through a single set of "outp" sources: outp-active/auto for a CRC of
the scanout region, outp-complete for a CRC of both the scanout and
blanking/sync region combined, and outp-inactive for a CRC of only the
blanking/sync region. For each source, nouveau selects the appropriate
tap point based on the output path in use. We also expose an "rg"
source, which allows for capturing CRCs of the scanout raster before
it's encoded into a video signal in the output path. This tap point is
referred to as the raster generator.
Note that while there's some other neat features that can be used with
CRC capture on nvidia hardware, like capturing from two CRC sources
simultaneously, I couldn't see any usecase for them and did not
implement them.
Nvidia only allows for accessing CRCs through a shared DMA region that
we program through the core EVO/NvDisplay channel which is referred to
as the notifier context. The notifier context is limited to either 255
(for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and
unfortunately the hardware simply drops CRCs and reports an overflow
once all available entries in the notifier context are filled.
Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit
on how many CRCs can be captured, we work around this in nouveau by
allocating two separate notifier contexts for each head instead of one.
We schedule a vblank worker ahead of time so that once we start getting
close to filling up all of the available entries in the notifier
context, we can swap the currently used notifier context out with
another pre-prepared notifier context in a manner similar to page
flipping.
Unfortunately, the hardware only allows us to this by flushing two
separate updates on the core channel: one to release the current
notifier context handle, and one to program the next notifier context's
handle. When the hardware processes the first update, the CRC for the
current frame is lost. However, the second update can be flushed
immediately without waiting for the first to complete so that CRC
generation resumes on the next frame. According to Nvidia's hardware
engineers, there isn't any cleaner way of flipping notifier contexts
that would avoid this.
Since using vblank workers to swap out the notifier context will ensure
we can usually flush both updates to hardware within the timespan of a
single frame, we can also ensure that there will only be exactly one
frame lost between the first and second update being executed by the
hardware. This gives us the guarantee that we're always correctly
matching each CRC entry with it's respective frame even after a context
flip. And since IGT will retrieve the CRC entry for a frame by waiting
until it receives a CRC for any subsequent frames, this doesn't cause an
issue with any tests and is much simpler than trying to change the
current DRM API to accommodate.
In order to facilitate testing of correct handling of this limitation,
we also expose a debugfs interface to manually control the threshold for
when we start trying to flip the notifier context. We will use this in
igt to trigger a context flip for testing purposes without needing to
wait for the notifier to completely fill up. This threshold is reset
to the default value set by nouveau after each capture, and is exposed
in a separate folder within each CRTC's debugfs directory labelled
"nv_crc".
Changes since v1:
* Forgot to finish saving crc.h before saving, whoops. This just adds
some corrections to the empty function declarations that we use if
CONFIG_DEBUG_FS isn't enabled.
Changes since v2:
* Don't check return code from debugfs_create_dir() or
debugfs_create_file() - Greg K-H
Changes since v3:
(no functional changes)
* Fix SPDX license identifiers (checkpatch)
* s/uint32_t/u32/ (checkpatch)
* Fix indenting in switch cases (checkpatch)
Changes since v4:
* Remove unneeded param changes with nv50_head_flush_clr/set
* Rebase
Changes since v5:
* Remove set but unused variable (outp) in nv50_crc_atomic_check() -
Kbuild bot
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-10-lyude@redhat.com
2019-10-07 21:20:12 +03:00
ret = drm_vblank_init ( dev , dev - > mode_config . num_crtc ) ;
2013-09-10 07:20:34 +04:00
if ( ret )
goto vblank_err ;
drm/nouveau/kms/nvd9-: Add CRC support
This introduces support for CRC readback on gf119+, using the
documentation generously provided to us by Nvidia:
https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt
We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed
through a single set of "outp" sources: outp-active/auto for a CRC of
the scanout region, outp-complete for a CRC of both the scanout and
blanking/sync region combined, and outp-inactive for a CRC of only the
blanking/sync region. For each source, nouveau selects the appropriate
tap point based on the output path in use. We also expose an "rg"
source, which allows for capturing CRCs of the scanout raster before
it's encoded into a video signal in the output path. This tap point is
referred to as the raster generator.
Note that while there's some other neat features that can be used with
CRC capture on nvidia hardware, like capturing from two CRC sources
simultaneously, I couldn't see any usecase for them and did not
implement them.
Nvidia only allows for accessing CRCs through a shared DMA region that
we program through the core EVO/NvDisplay channel which is referred to
as the notifier context. The notifier context is limited to either 255
(for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and
unfortunately the hardware simply drops CRCs and reports an overflow
once all available entries in the notifier context are filled.
Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit
on how many CRCs can be captured, we work around this in nouveau by
allocating two separate notifier contexts for each head instead of one.
We schedule a vblank worker ahead of time so that once we start getting
close to filling up all of the available entries in the notifier
context, we can swap the currently used notifier context out with
another pre-prepared notifier context in a manner similar to page
flipping.
Unfortunately, the hardware only allows us to this by flushing two
separate updates on the core channel: one to release the current
notifier context handle, and one to program the next notifier context's
handle. When the hardware processes the first update, the CRC for the
current frame is lost. However, the second update can be flushed
immediately without waiting for the first to complete so that CRC
generation resumes on the next frame. According to Nvidia's hardware
engineers, there isn't any cleaner way of flipping notifier contexts
that would avoid this.
Since using vblank workers to swap out the notifier context will ensure
we can usually flush both updates to hardware within the timespan of a
single frame, we can also ensure that there will only be exactly one
frame lost between the first and second update being executed by the
hardware. This gives us the guarantee that we're always correctly
matching each CRC entry with it's respective frame even after a context
flip. And since IGT will retrieve the CRC entry for a frame by waiting
until it receives a CRC for any subsequent frames, this doesn't cause an
issue with any tests and is much simpler than trying to change the
current DRM API to accommodate.
In order to facilitate testing of correct handling of this limitation,
we also expose a debugfs interface to manually control the threshold for
when we start trying to flip the notifier context. We will use this in
igt to trigger a context flip for testing purposes without needing to
wait for the notifier to completely fill up. This threshold is reset
to the default value set by nouveau after each capture, and is exposed
in a separate folder within each CRTC's debugfs directory labelled
"nv_crc".
Changes since v1:
* Forgot to finish saving crc.h before saving, whoops. This just adds
some corrections to the empty function declarations that we use if
CONFIG_DEBUG_FS isn't enabled.
Changes since v2:
* Don't check return code from debugfs_create_dir() or
debugfs_create_file() - Greg K-H
Changes since v3:
(no functional changes)
* Fix SPDX license identifiers (checkpatch)
* s/uint32_t/u32/ (checkpatch)
* Fix indenting in switch cases (checkpatch)
Changes since v4:
* Remove unneeded param changes with nv50_head_flush_clr/set
* Rebase
Changes since v5:
* Remove set but unused variable (outp) in nv50_crc_atomic_check() -
Kbuild bot
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-10-lyude@redhat.com
2019-10-07 21:20:12 +03:00
if ( disp - > disp . object . oclass > = NV50_DISP )
nv50_crc_init ( dev ) ;
2011-11-09 09:18:47 +04:00
}
2016-11-21 19:50:54 +03:00
INIT_WORK ( & drm - > hpd_work , nouveau_display_hpd_work ) ;
2020-08-26 21:24:48 +03:00
mutex_init ( & drm - > hpd_lock ) ;
2016-11-09 20:17:44 +03:00
# ifdef CONFIG_ACPI
drm - > acpi_nb . notifier_call = nouveau_display_acpi_ntfy ;
register_acpi_notifier ( & drm - > acpi_nb ) ;
# endif
2012-04-15 16:36:08 +04:00
return 0 ;
vblank_err :
2012-07-31 10:16:21 +04:00
disp - > dtor ( dev ) ;
2012-04-15 16:36:08 +04:00
disp_create_err :
drm_kms_helper_poll_fini ( dev ) ;
drm_mode_config_cleanup ( dev ) ;
2011-11-09 05:36:33 +04:00
return ret ;
2011-10-06 06:46:40 +04:00
}
void
nouveau_display_destroy ( struct drm_device * dev )
{
2012-07-31 10:16:21 +04:00
struct nouveau_display * disp = nouveau_display ( dev ) ;
2020-08-26 21:24:48 +03:00
struct nouveau_drm * drm = nouveau_drm ( dev ) ;
2011-10-06 06:46:40 +04:00
2016-11-09 20:17:44 +03:00
# ifdef CONFIG_ACPI
2020-08-26 21:24:48 +03:00
unregister_acpi_notifier ( & drm - > acpi_nb ) ;
2016-11-09 20:17:44 +03:00
# endif
2011-11-09 09:18:47 +04:00
2012-10-30 04:59:12 +04:00
drm_kms_helper_poll_fini ( dev ) ;
drm_mode_config_cleanup ( dev ) ;
2012-10-31 06:11:15 +04:00
if ( disp - > dtor )
disp - > dtor ( dev ) ;
2011-11-09 09:18:47 +04:00
2018-05-08 13:39:47 +03:00
nvif_disp_dtor ( & disp - > disp ) ;
2014-01-22 06:58:12 +04:00
2012-07-31 10:16:21 +04:00
nouveau_drm ( dev ) - > display = NULL ;
2020-08-26 21:24:48 +03:00
mutex_destroy ( & drm - > hpd_lock ) ;
2012-07-31 10:16:21 +04:00
kfree ( disp ) ;
}
int
2014-10-02 07:22:27 +04:00
nouveau_display_suspend ( struct drm_device * dev , bool runtime )
2012-07-31 10:16:21 +04:00
{
2016-11-04 10:20:36 +03:00
struct nouveau_display * disp = nouveau_display ( dev ) ;
2012-07-31 10:16:21 +04:00
2016-12-22 11:50:42 +03:00
if ( drm_drv_uses_atomic_modeset ( dev ) ) {
2016-11-04 10:20:36 +03:00
if ( ! runtime ) {
2017-02-21 16:51:40 +03:00
disp - > suspend = drm_atomic_helper_suspend ( dev ) ;
2016-11-04 10:20:36 +03:00
if ( IS_ERR ( disp - > suspend ) ) {
int ret = PTR_ERR ( disp - > suspend ) ;
disp - > suspend = NULL ;
return ret ;
}
}
}
2018-08-08 00:32:48 +03:00
nouveau_display_fini ( dev , true , runtime ) ;
2012-07-31 10:16:21 +04:00
return 0 ;
}
void
2014-10-02 07:22:27 +04:00
nouveau_display_resume ( struct drm_device * dev , bool runtime )
2012-07-31 10:16:21 +04:00
{
2016-11-04 10:20:36 +03:00
struct nouveau_display * disp = nouveau_display ( dev ) ;
2019-02-12 15:28:13 +03:00
nouveau_display_init ( dev , true , runtime ) ;
2012-07-31 10:16:21 +04:00
2016-12-22 11:50:42 +03:00
if ( drm_drv_uses_atomic_modeset ( dev ) ) {
2016-11-04 10:20:36 +03:00
if ( disp - > suspend ) {
drm_atomic_helper_resume ( dev , disp - > suspend ) ;
disp - > suspend = NULL ;
}
return ;
}
2011-10-06 06:46:40 +04:00
}
2011-09-30 02:55:50 +04:00
int
nouveau_display_dumb_create ( struct drm_file * file_priv , struct drm_device * dev ,
struct drm_mode_create_dumb * args )
{
2016-05-24 10:29:55 +03:00
struct nouveau_cli * cli = nouveau_cli ( file_priv ) ;
2011-09-30 02:55:50 +04:00
struct nouveau_bo * bo ;
2015-02-20 12:22:59 +03:00
uint32_t domain ;
2011-09-30 02:55:50 +04:00
int ret ;
args - > pitch = roundup ( args - > width * ( args - > bpp / 8 ) , 256 ) ;
args - > size = args - > pitch * args - > height ;
args - > size = roundup ( args - > size , PAGE_SIZE ) ;
2015-02-20 12:22:59 +03:00
/* Use VRAM if there is any ; otherwise fallback to system memory */
2016-05-18 06:57:42 +03:00
if ( nouveau_drm ( dev ) - > client . device . info . ram_size ! = 0 )
2015-02-20 12:22:59 +03:00
domain = NOUVEAU_GEM_DOMAIN_VRAM ;
else
domain = NOUVEAU_GEM_DOMAIN_GART ;
2016-05-24 10:29:55 +03:00
ret = nouveau_gem_new ( cli , args - > size , 0 , domain , 0 , 0 , & bo ) ;
2011-09-30 02:55:50 +04:00
if ( ret )
return ret ;
2019-08-05 17:01:08 +03:00
ret = drm_gem_handle_create ( file_priv , & bo - > bo . base , & args - > handle ) ;
2020-05-15 12:51:05 +03:00
drm_gem_object_put ( & bo - > bo . base ) ;
2011-09-30 02:55:50 +04:00
return ret ;
}