[radeon-alex:amd-staging-drm-next 1718/1730] htmldocs: drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:827: warning: Function parameter or member 'direct' not described in 'amdgpu_vm_bo_param'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: cfdabd064b2d58f98ff376f1134d3cea5515a64e
commit: 76c44610d813f21e7f843973813c1282b2388041 [1718/1730] drm/amdgpu:
allocate PDs/PTs with no_gpu_wait in a page fault
reproduce: make htmldocs
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
Warning: The Sphinx 'sphinx_rtd_theme' HTML theme was not found. Make sure
you have the theme installed to produce pretty HTML output. Falling back to the
default theme.
Documentation/sphinx/kfigure.py:174: RemovedInSphinx20Warning: app.verbose()
is now deprecated. Use sphinx.util.logging instead.
app.verbose("kfigure: check installed tools ...")
Documentation/sphinx/kfigure.py:182: RemovedInSphinx20Warning: app.warning()
is now deprecated. Use sphinx.util.logging instead.
app.warn("dot(1) not found, for better output quality install "
WARNING: dot(1) not found, for better output quality install graphviz from
http://www.graphviz.org
Documentation/sphinx/kfigure.py:188: RemovedInSphinx20Warning: app.warning()
is now deprecated. Use sphinx.util.logging instead.
"convert(1) not found, for SVG to PDF conversion install "
WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick
(https://www.imagemagick.org)
Documentation/sphinx/kerneldoc.py:93: RemovedInSphinx20Warning:
app.verbose() is now deprecated. Use sphinx.util.logging instead.
env.app.verbose('calling kernel-doc \'%s\'' % (" ".join(cmd)))
Documentation/sphinx/kerneldoc.py:125: RemovedInSphinx20Warning:
AutodocReporter is now deprecated. Use
sphinx.util.docutils.switch_source_input() instead.
self.state.memo.reporter = AutodocReporter(result,
self.state.memo.reporter)
include/linux/generic-radix-tree.h:1: warning: no structured comments found
lib/sort.c:59: warning: Excess function parameter 'size' description in
'swap_words_32'
lib/sort.c:83: warning: Excess function parameter 'size' description in
'swap_words_64'
lib/sort.c:110: warning: Excess function parameter 'size' description in
'swap_bytes'
block/genhd.c:540: warning: Function parameter or member 'devt' not
described in 'blk_invalidate_devt'
kernel/rcu/tree_plugin.h:1: warning: no structured comments found
include/net/cfg80211.h:1074: warning: Function parameter or member 'txpwr'
not described in 'station_parameters'
include/net/mac80211.h:4037: warning: Function parameter or member
'sta_set_txpwr' not described in 'ieee80211_ops'
include/net/mac80211.h:2004: warning: Function parameter or member 'txpwr'
not described in 'ieee80211_sta'
kernel/rcu/tree_plugin.h:1: warning: no structured comments found
include/linux/firmware/intel/stratix10-svc-client.h:1: warning: no
structured comments found
Error: Cannot open file drivers/counter/generic-counter.c
Error: Cannot open file drivers/counter/generic-counter.c
Documentation/sphinx/kerneldoc.py:103: RemovedInSphinx20Warning:
app.warning() is now deprecated. Use sphinx.util.logging instead.
env.app.warn('kernel-doc \'%s\' failed with return code %d' % ("
".join(cmd), p.returncode))
include/linux/gpio/driver.h:374: warning: Function parameter or member
'init_valid_mask' not described in 'gpio_chip'
include/linux/i2c.h:343: warning: Function parameter or member 'init_irq'
not described in 'i2c_client'
include/linux/iio/hw-consumer.h:1: warning: no structured comments found
drivers/base/node.c:78: warning: Function parameter or member 'hmem_attrs'
not described in 'node_access_nodes'
drivers/base/node.c:690: warning: Function parameter or member 'mem_nid' not
described in 'register_memory_node_under_compute_node'
drivers/base/node.c:690: warning: Function parameter or member 'cpu_nid' not
described in 'register_memory_node_under_compute_node'
drivers/base/node.c:690: warning: Excess function parameter 'mem_node'
description in 'register_memory_node_under_compute_node'
drivers/base/node.c:690: warning: Excess function parameter 'cpu_node'
description in 'register_memory_node_under_compute_node'
include/linux/input/sparse-keymap.h:46: warning: Function parameter or
member 'sw' not described in 'key_entry'
include/linux/regulator/machine.h:199: warning: Function parameter or member
'max_uV_step' not described in 'regulation_constraints'
include/linux/regulator/driver.h:228: warning: Function parameter or member
'resume' not described in 'regulator_ops'
drivers/slimbus/stream.c:1: warning: no structured comments found
include/linux/spi/spi.h:188: warning: Function parameter or member
'driver_override' not described in 'spi_device'
drivers/target/target_core_device.c:1: warning: no structured comments found
drivers/usb/typec/bus.c:1: warning: no structured comments found
drivers/usb/typec/class.c:1: warning: no structured comments found
include/linux/w1.h:281: warning:
[radeon-alex:amd-staging-drm-next 1717/1730] htmldocs: drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:861: warning: Function parameter or member 'direct' not described in 'amdgpu_vm_alloc_pts'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: cfdabd064b2d58f98ff376f1134d3cea5515a64e
commit: 4294fe6a8b0e99314a679122ec947574e53d4af6 [1717/1730] drm/amdgpu: allow
direct submission of clears
reproduce: make htmldocs
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
Warning: The Sphinx 'sphinx_rtd_theme' HTML theme was not found. Make sure
you have the theme installed to produce pretty HTML output. Falling back to the
default theme.
Documentation/sphinx/kfigure.py:174: RemovedInSphinx20Warning: app.verbose()
is now deprecated. Use sphinx.util.logging instead.
app.verbose("kfigure: check installed tools ...")
Documentation/sphinx/kfigure.py:182: RemovedInSphinx20Warning: app.warning()
is now deprecated. Use sphinx.util.logging instead.
app.warn("dot(1) not found, for better output quality install "
WARNING: dot(1) not found, for better output quality install graphviz from
http://www.graphviz.org
Documentation/sphinx/kfigure.py:188: RemovedInSphinx20Warning: app.warning()
is now deprecated. Use sphinx.util.logging instead.
"convert(1) not found, for SVG to PDF conversion install "
WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick
(https://www.imagemagick.org)
Documentation/sphinx/kerneldoc.py:93: RemovedInSphinx20Warning:
app.verbose() is now deprecated. Use sphinx.util.logging instead.
env.app.verbose('calling kernel-doc \'%s\'' % (" ".join(cmd)))
Documentation/sphinx/kerneldoc.py:125: RemovedInSphinx20Warning:
AutodocReporter is now deprecated. Use
sphinx.util.docutils.switch_source_input() instead.
self.state.memo.reporter = AutodocReporter(result,
self.state.memo.reporter)
include/linux/generic-radix-tree.h:1: warning: no structured comments found
lib/sort.c:59: warning: Excess function parameter 'size' description in
'swap_words_32'
lib/sort.c:83: warning: Excess function parameter 'size' description in
'swap_words_64'
lib/sort.c:110: warning: Excess function parameter 'size' description in
'swap_bytes'
block/genhd.c:540: warning: Function parameter or member 'devt' not
described in 'blk_invalidate_devt'
kernel/rcu/tree_plugin.h:1: warning: no structured comments found
include/net/cfg80211.h:1074: warning: Function parameter or member 'txpwr'
not described in 'station_parameters'
include/net/mac80211.h:4037: warning: Function parameter or member
'sta_set_txpwr' not described in 'ieee80211_ops'
include/net/mac80211.h:2004: warning: Function parameter or member 'txpwr'
not described in 'ieee80211_sta'
kernel/rcu/tree_plugin.h:1: warning: no structured comments found
include/linux/firmware/intel/stratix10-svc-client.h:1: warning: no
structured comments found
Error: Cannot open file drivers/counter/generic-counter.c
Error: Cannot open file drivers/counter/generic-counter.c
Documentation/sphinx/kerneldoc.py:103: RemovedInSphinx20Warning:
app.warning() is now deprecated. Use sphinx.util.logging instead.
env.app.warn('kernel-doc \'%s\' failed with return code %d' % ("
".join(cmd), p.returncode))
include/linux/gpio/driver.h:374: warning: Function parameter or member
'init_valid_mask' not described in 'gpio_chip'
include/linux/i2c.h:343: warning: Function parameter or member 'init_irq'
not described in 'i2c_client'
include/linux/iio/hw-consumer.h:1: warning: no structured comments found
drivers/base/node.c:78: warning: Function parameter or member 'hmem_attrs'
not described in 'node_access_nodes'
drivers/base/node.c:690: warning: Function parameter or member 'mem_nid' not
described in 'register_memory_node_under_compute_node'
drivers/base/node.c:690: warning: Function parameter or member 'cpu_nid' not
described in 'register_memory_node_under_compute_node'
drivers/base/node.c:690: warning: Excess function parameter 'mem_node'
description in 'register_memory_node_under_compute_node'
drivers/base/node.c:690: warning: Excess function parameter 'cpu_node'
description in 'register_memory_node_under_compute_node'
include/linux/input/sparse-keymap.h:46: warning: Function parameter or
member 'sw' not described in 'key_entry'
include/linux/regulator/machine.h:199: warning: Function parameter or member
'max_uV_step' not described in 'regulation_constraints'
include/linux/regulator/driver.h:228: warning: Function parameter or member
'resume' not described in 'regulator_ops'
drivers/slimbus/stream.c:1: warning: no structured comments found
include/linux/spi/spi.h:188: warning: Function parameter or member
'driver_override' not described in 'spi_device'
drivers/target/target_core_device.c:1: warning: no structured comments found
drivers/usb/typec/bus.c:1: warning: no structured comments found
drivers/usb/typec/class.c:1: warning: no structured comments found
include/linux/w1.h:281: warning: Function parameter or
RE: [PATCH v5] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
From: Wei Hu Sent: Thursday, September 12, 2019 11:03 PM > > Without deferred IO support, hyperv_fb driver informs the host to refresh > the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there > is screen update or not. This patch supports deferred IO for screens in > graphics mode and also enables the frame buffer on-demand refresh. The > highest refresh rate is still set at 20Hz. > > Currently Hyper-V only takes a physical address from guest as the starting > address of frame buffer. This implies the guest must allocate contiguous > physical memory for frame buffer. In addition, Hyper-V Gen 2 VMs only > accept address from MMIO region as frame buffer address. Due to these > limitations on Hyper-V host, we keep a shadow copy of frame buffer > in the guest. This means one more copy of the dirty rectangle inside > guest when doing the on-demand refresh. This can be optimized in the > future with help from host. For now the host performance gain from deferred > IO outweighs the shadow copy impact in the guest. > > Signed-off-by: Wei Hu > --- > v2: Incorporated review comments from Michael Kelley > - Increased dirty rectangle by one row in deferred IO case when sending > to Hyper-V. > - Corrected the dirty rectangle size in the text mode. > - Added more comments. > - Other minor code cleanups. > > v3: Incorporated more review comments > - Removed a few unnecessary variable tests > > v4: Incorporated test and review feedback from Dexuan Cui > - Not disable interrupt while acquiring docopy_lock in > hvfb_update_work(). This avoids significant bootup delay in > large vCPU count VMs. > > v5: Completely remove the unnecessary docopy_lock after discussing > with Dexuan Cui. > Reviewed-by: Michael Kelley
[PATCH CI 1/2] drm/connector: Share with non-atomic drivers the function to get the single encoder
This 3 non-atomic drivers all have the same function getting the
only encoder available in the connector, also atomic drivers have
this fallback. So moving it a common place and sharing between atomic
and non-atomic drivers.
While at it I also removed the mention of
drm_atomic_helper_best_encoder() that was renamed in
commit 297e30b5d9b6 ("drm/atomic-helper: Unexport
drm_atomic_helper_best_encoder").
v3: moving drm_connector_get_single_encoder to drm_kms_helper module
Reviewed-by: Laurent Pinchart
Reviewed-by: Ville Syrjälä
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: dri-devel@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/ast/ast_mode.c | 12
drivers/gpu/drm/drm_atomic_helper.c| 15 ++-
drivers/gpu/drm/drm_crtc_helper.c | 17 -
drivers/gpu/drm/drm_crtc_helper_internal.h | 3 +++
drivers/gpu/drm/mgag200/mgag200_mode.c | 11 ---
drivers/gpu/drm/udl/udl_connector.c| 8
include/drm/drm_modeset_helper_vtables.h | 7 +++
7 files changed, 24 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index d349c721501c..eef95e1af06b 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -687,17 +687,6 @@ static void ast_encoder_destroy(struct drm_encoder
*encoder)
kfree(encoder);
}
-
-static struct drm_encoder *ast_best_single_encoder(struct drm_connector
*connector)
-{
- int enc_id = connector->encoder_ids[0];
- /* pick the encoder ids */
- if (enc_id)
- return drm_encoder_find(connector->dev, NULL, enc_id);
- return NULL;
-}
-
-
static const struct drm_encoder_funcs ast_enc_funcs = {
.destroy = ast_encoder_destroy,
};
@@ -847,7 +836,6 @@ static void ast_connector_destroy(struct drm_connector
*connector)
static const struct drm_connector_helper_funcs ast_connector_helper_funcs = {
.mode_valid = ast_mode_valid,
.get_modes = ast_get_modes,
- .best_encoder = ast_best_single_encoder,
};
static const struct drm_connector_funcs ast_connector_funcs = {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 4706439fb490..9d7e4da6c292 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -97,17 +97,6 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state
*state,
}
}
-/*
- * For connectors that support multiple encoders, either the
- * .atomic_best_encoder() or .best_encoder() operation must be implemented.
- */
-static struct drm_encoder *
-pick_single_encoder_for_connector(struct drm_connector *connector)
-{
- WARN_ON(connector->encoder_ids[1]);
- return drm_encoder_find(connector->dev, NULL,
connector->encoder_ids[0]);
-}
-
static int handle_conflicting_encoders(struct drm_atomic_state *state,
bool disable_conflicting_encoders)
{
@@ -135,7 +124,7 @@ static int handle_conflicting_encoders(struct
drm_atomic_state *state,
else if (funcs->best_encoder)
new_encoder = funcs->best_encoder(connector);
else
- new_encoder =
pick_single_encoder_for_connector(connector);
+ new_encoder =
drm_connector_get_single_encoder(connector);
if (new_encoder) {
if (encoder_mask & drm_encoder_mask(new_encoder)) {
@@ -359,7 +348,7 @@ update_connector_routing(struct drm_atomic_state *state,
else if (funcs->best_encoder)
new_encoder = funcs->best_encoder(connector);
else
- new_encoder = pick_single_encoder_for_connector(connector);
+ new_encoder = drm_connector_get_single_encoder(connector);
if (!new_encoder) {
DRM_DEBUG_ATOMIC("No suitable encoder found for
[CONNECTOR:%d:%s]\n",
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index a51824a7e7c1..4a7447a53cea 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -460,6 +460,17 @@ drm_crtc_helper_disable(struct drm_crtc *crtc)
__drm_helper_disable_unused_functions(dev);
}
+/*
+ * For connectors that support multiple encoders, either the
+ * .atomic_best_encoder() or .best_encoder() operation must be implemented.
+ */
+struct drm_encoder *
+drm_connector_get_single_encoder(struct drm_connector *connector)
+{
+ WARN_ON(connector->encoder_ids[1]);
+ return drm_encoder_find(connector->dev, NULL,
connector->encoder_ids[0]);
+}
+
/**
* drm_crtc_helper_set_config - set a new config from userspace
* @set: mode set configuration
@@ -625,7 +636,11 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
new_encoder =
[PATCH CI 2/2] drm/connector: Allow max possible encoders to attach to a connector
Currently we restrict the number of encoders that can be linked to
a connector to 3, increase it to match the maximum number of encoders
that can be initialized(32).
To more effiently do that lets switch from an array of encoder ids to
bitmask.
v2: Fixing missed return on amdgpu_dm_connector_to_encoder()
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Cc: Alex Deucher
Cc: dri-devel@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Reviewed-by: Ville Syrjälä
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
.../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 23 +-
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 5 ++-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 -
drivers/gpu/drm/drm_client_modeset.c | 3 +-
drivers/gpu/drm/drm_connector.c | 31 +--
drivers/gpu/drm/drm_crtc_helper.c | 9 --
drivers/gpu/drm/drm_probe_helper.c| 3 +-
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 7 ++---
drivers/gpu/drm/radeon/radeon_connectors.c| 27 ++--
include/drm/drm_connector.h | 18 +--
12 files changed, 55 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index ece55c8fa673..d8729285f731 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -217,11 +217,10 @@ amdgpu_connector_update_scratch_regs(struct drm_connector
*connector,
struct drm_encoder *encoder;
const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
bool connected;
- int i;
best_encoder = connector_funcs->best_encoder(connector);
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if ((encoder == best_encoder) && (status ==
connector_status_connected))
connected = true;
else
@@ -236,9 +235,8 @@ amdgpu_connector_find_encoder(struct drm_connector
*connector,
int encoder_type)
{
struct drm_encoder *encoder;
- int i;
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if (encoder->encoder_type == encoder_type)
return encoder;
}
@@ -347,10 +345,9 @@ static struct drm_encoder *
amdgpu_connector_best_single_encoder(struct drm_connector *connector)
{
struct drm_encoder *encoder;
- int i;
/* pick the first one */
- drm_connector_for_each_possible_encoder(connector, encoder, i)
+ drm_connector_for_each_possible_encoder(connector, encoder)
return encoder;
return NULL;
@@ -1065,9 +1062,8 @@ amdgpu_connector_dvi_detect(struct drm_connector
*connector, bool force)
/* find analog encoder */
if (amdgpu_connector->dac_load_detect) {
struct drm_encoder *encoder;
- int i;
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if (encoder->encoder_type != DRM_MODE_ENCODER_DAC &&
encoder->encoder_type != DRM_MODE_ENCODER_TVDAC)
continue;
@@ -1117,9 +1113,8 @@ amdgpu_connector_dvi_encoder(struct drm_connector
*connector)
{
struct amdgpu_connector *amdgpu_connector =
to_amdgpu_connector(connector);
struct drm_encoder *encoder;
- int i;
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if (amdgpu_connector->use_digital == true) {
if (encoder->encoder_type == DRM_MODE_ENCODER_TMDS)
return encoder;
@@ -1134,7 +1129,7 @@ amdgpu_connector_dvi_encoder(struct drm_connector
*connector)
/* then check use digitial */
/* pick the first one */
- drm_connector_for_each_possible_encoder(connector, encoder, i)
+ drm_connector_for_each_possible_encoder(connector, encoder)
return encoder;
return NULL;
@@ -1271,9 +1266,8 @@ u16
amdgpu_connector_encoder_get_dp_bridge_encoder_id(struct drm_connector *conn
{
struct drm_encoder *encoder;
struct amdgpu_encoder *amdgpu_encoder;
- int i;
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
Re: [PATCH libdrm] meson: Fix sys/mkdev.h detection on Solaris
On 9/10/19 5:55 AM, Eric Engestrom wrote:
On Monday, 2019-09-09 16:51:16 -0700, Alan Coopersmith wrote:
On Solaris, sys/sysmacros.h has long-deprecated copies of major() & minor()
but not makedev(). sys/mkdev.h has all three and is the preferred choice.
So we check for sys/mkdev.h first, as autoconf's AC_HEADER_MAJOR does.
Reviewed-by: Eric Engestrom
Alternatively, how about this?
---8<---
diff --git a/meson.build b/meson.build
index bc5cfc588d0c621a9725..263f691ab2b9107f5be1 100644
--- a/meson.build
+++ b/meson.build
@@ -183,9 +183,14 @@ foreach header : ['sys/sysctl.h', 'sys/select.h',
'alloca.h']
config.set('HAVE_' + header.underscorify().to_upper(),
cc.compiles('#include <@0@>'.format(header), name : '@0@
works'.format(header)))
endforeach
-if cc.has_header_symbol('sys/sysmacros.h', 'major')
+if (cc.has_header_symbol('sys/sysmacros.h', 'major') and
+ cc.has_header_symbol('sys/sysmacros.h', 'minor') and
+ cc.has_header_symbol('sys/sysmacros.h', 'makedev'))
config.set10('MAJOR_IN_SYSMACROS', true)
-elif cc.has_header_symbol('sys/mkdev.h', 'major')
+endif
+if (cc.has_header_symbol('sys/mkdev.h', 'major') and
+ cc.has_header_symbol('sys/mkdev.h', 'minor') and
+ cc.has_header_symbol('sys/mkdev.h', 'makedev'))
config.set10('MAJOR_IN_MKDEV', true)
endif
config.set10('HAVE_OPEN_MEMSTREAM', cc.has_function('open_memstream'))
--->8---
Makes both checks independent and represent the reality of what's wanted
more accurately (despite the historical name of the macro).
That works:
Header has symbol "major" : YES (cached)
Header has symbol "minor" : YES
Header has symbol "makedev" : NO
Header has symbol "major" : YES
Header has symbol "minor" : YES
Header has symbol "makedev" : YES
Would you like me to resubmit with that, or do you want to submit it?
If you want to go ahead, then:
Reviewed-by: Alan Coopersmith
Tested-by: Alan Coopersmith
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111077] link_shader and deserialize_glsl_program suddenly consume huge amount of RAM
https://bugs.freedesktop.org/show_bug.cgi?id=111077 --- Comment #39 from Matt Turner --- (In reply to rol...@rptd.ch from comment #38) > Could it be that your patch is not for version "mesa-19.0.8" as I'm using? > (newer ones are keyworded) Perhaps try 19.2.0_rc3. That's much closer to master. Whatever the case, if the patch doesn't apply to 19.0.8 and portage tried (and as a result failed) to apply it, it would give an error and stop. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/nouveau: dispnv50: Remove nv50_mstc_best_encoder()
When drm_connector_helper_funcs->atomic_best_encoder is defined,
->best_encoder is ignored by the atomic modesetting helpers. That being
said, this hook is completely broken anyway - it always returns the
first msto for a given mstc, despite the fact it might already be in
use.
So, just get rid of it. We'll need this in a moment anyway, when we make
mstos per-head as opposed to per-connector.
Changes since v1:
* Fix typo in documentation - imirkin
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index b46be8a091e9..a3f350fdfa8c 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -920,14 +920,6 @@ nv50_mstc_atomic_best_encoder(struct drm_connector
*connector,
return >mstm->msto[head->base.index]->encoder;
}
-static struct drm_encoder *
-nv50_mstc_best_encoder(struct drm_connector *connector)
-{
- struct nv50_mstc *mstc = nv50_mstc(connector);
-
- return >mstm->msto[0]->encoder;
-}
-
static enum drm_mode_status
nv50_mstc_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
@@ -990,7 +982,6 @@ static const struct drm_connector_helper_funcs
nv50_mstc_help = {
.get_modes = nv50_mstc_get_modes,
.mode_valid = nv50_mstc_mode_valid,
- .best_encoder = nv50_mstc_best_encoder,
.atomic_best_encoder = nv50_mstc_atomic_best_encoder,
.atomic_check = nv50_mstc_atomic_check,
};
--
2.21.0
[PATCH 3/3] drm/encoder: Don't raise voice in drm_encoder_mask() documentation
There's no need to raise our voice when saying encoder, we're all civilized adults here! Signed-off-by: Lyude Paul --- include/drm/drm_encoder.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h index d65173d413b7..f06164f44efe 100644 --- a/include/drm/drm_encoder.h +++ b/include/drm/drm_encoder.h @@ -198,7 +198,7 @@ static inline unsigned int drm_encoder_index(const struct drm_encoder *encoder) } /** - * drm_encoder_mask - find the mask of a registered ENCODER + * drm_encoder_mask - find the mask of a registered encoder * @encoder: encoder to find mask for * * Given a registered encoder, return the mask bit of that encoder for an -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/encoder: Fix possible_crtcs documentation
Similar to possible_clones, we don't actually use possible_crtcs until
the driver is registered with userspace. So, fix the documentation to
indicate this.
Signed-off-by: Lyude Paul
---
include/drm/drm_encoder.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
index 81273b50b3f6..d65173d413b7 100644
--- a/include/drm/drm_encoder.h
+++ b/include/drm/drm_encoder.h
@@ -140,7 +140,7 @@ struct drm_encoder {
* @possible_crtcs: Bitmask of potential CRTC bindings, using
* drm_crtc_index() as the index into the bitfield. The driver must set
* the bits for all _crtc objects this encoder can be connected to
-* before calling drm_encoder_init().
+* before calling drm_dev_register().
*
* In reality almost every driver gets this wrong.
*
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm/encoder: Various doc fixes
Some random issues with documentation that I noticed while working on nouveau the other day. There are no functional changes in this series. Lyude Paul (3): drm/encoder: Fix possible_clones documentation drm/encoder: Fix possible_crtcs documentation drm/encoder: Don't raise voice in drm_encoder_mask() documentation include/drm/drm_encoder.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/encoder: Fix possible_clones documentation
We say that all of the bits in possible_clones must be set before
calling drm_encoder_init(). This isn't true though, since:
* The driver may not even have all of the encoder objects that could be
used as clones initialized at that point
* possible_crtcs isn't used at all outside of userspace, so it's not
actually needed to initialize it until drm_dev_register()
So, fix it.
Signed-off-by: Lyude Paul
---
include/drm/drm_encoder.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
index 70cfca03d812..81273b50b3f6 100644
--- a/include/drm/drm_encoder.h
+++ b/include/drm/drm_encoder.h
@@ -154,7 +154,7 @@ struct drm_encoder {
* using drm_encoder_index() as the index into the bitfield. The driver
* must set the bits for all _encoder objects which can clone a
* _crtc together with this encoder before calling
-* drm_encoder_init(). Drivers should set the bit representing the
+* drm_dev_register(). Drivers should set the bit representing the
* encoder itself, too. Cloning bits should be set such that when two
* encoders can be used in a cloned configuration, they both should have
* each another bits set.
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111273] crash calling AMDGPU_INFO_READ_MMR_REG with count set to -1
https://bugs.freedesktop.org/show_bug.cgi?id=111273 Alex Deucher changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/nouveau: dispnv50: Remove nv50_mstc_best_encoder()
On Fri, 2019-09-13 at 18:20 -0400, Ilia Mirkin wrote:
> On Fri, Sep 13, 2019 at 6:05 PM Lyude Paul wrote:
> > When drm_connector_helper_funcs->atomic_best_encoder is defined,
> > ->best_encoder is ignored both by the atomic modesetting helpers. That
>
> By both the atomic modesetting helpers and ... (usually "both" implies 2
> things)
good catch, will fix and respin in a moment
>
> > being said, this hook is completely broken anyway - it always returns
> > the first msto for a given mstc, despite the fact it might already be in
> > use.
> >
> > So, just get rid of it. We'll need this in a moment anyway, when we make
> > mstos per-head as opposed to per-connector.
> >
> > Signed-off-by: Lyude Paul
> > ---
> > drivers/gpu/drm/nouveau/dispnv50/disp.c | 9 -
> > 1 file changed, 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > index b46be8a091e9..a3f350fdfa8c 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > @@ -920,14 +920,6 @@ nv50_mstc_atomic_best_encoder(struct drm_connector
> > *connector,
> > return >mstm->msto[head->base.index]->encoder;
> > }
> >
> > -static struct drm_encoder *
> > -nv50_mstc_best_encoder(struct drm_connector *connector)
> > -{
> > - struct nv50_mstc *mstc = nv50_mstc(connector);
> > -
> > - return >mstm->msto[0]->encoder;
> > -}
> > -
> > static enum drm_mode_status
> > nv50_mstc_mode_valid(struct drm_connector *connector,
> > struct drm_display_mode *mode)
> > @@ -990,7 +982,6 @@ static const struct drm_connector_helper_funcs
> > nv50_mstc_help = {
> > .get_modes = nv50_mstc_get_modes,
> > .mode_valid = nv50_mstc_mode_valid,
> > - .best_encoder = nv50_mstc_best_encoder,
> > .atomic_best_encoder = nv50_mstc_atomic_best_encoder,
> > .atomic_check = nv50_mstc_atomic_check,
> > };
> > --
> > 2.21.0
> >
--
Cheers,
Lyude Paul
Re: [PATCH 2/4] drm/nouveau: dispnv50: Remove nv50_mstc_best_encoder()
On Fri, Sep 13, 2019 at 6:05 PM Lyude Paul wrote:
>
> When drm_connector_helper_funcs->atomic_best_encoder is defined,
> ->best_encoder is ignored both by the atomic modesetting helpers. That
By both the atomic modesetting helpers and ... (usually "both" implies 2 things)
> being said, this hook is completely broken anyway - it always returns
> the first msto for a given mstc, despite the fact it might already be in
> use.
>
> So, just get rid of it. We'll need this in a moment anyway, when we make
> mstos per-head as opposed to per-connector.
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index b46be8a091e9..a3f350fdfa8c 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -920,14 +920,6 @@ nv50_mstc_atomic_best_encoder(struct drm_connector
> *connector,
> return >mstm->msto[head->base.index]->encoder;
> }
>
> -static struct drm_encoder *
> -nv50_mstc_best_encoder(struct drm_connector *connector)
> -{
> - struct nv50_mstc *mstc = nv50_mstc(connector);
> -
> - return >mstm->msto[0]->encoder;
> -}
> -
> static enum drm_mode_status
> nv50_mstc_mode_valid(struct drm_connector *connector,
> struct drm_display_mode *mode)
> @@ -990,7 +982,6 @@ static const struct drm_connector_helper_funcs
> nv50_mstc_help = {
> .get_modes = nv50_mstc_get_modes,
> .mode_valid = nv50_mstc_mode_valid,
> - .best_encoder = nv50_mstc_best_encoder,
> .atomic_best_encoder = nv50_mstc_atomic_best_encoder,
> .atomic_check = nv50_mstc_atomic_check,
> };
> --
> 2.21.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/nouveau: dispnv50: Report possible_crtcs incorrectly on mstos, for now
This commit is seperate from the previous one to make it easier to revert in the future. Basically, while working on making MSTOs per-head as opposed to per-head-per-connector I discovered these lovely issues: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277 https://gitlab.gnome.org/GNOME/mutter/issues/759 Note as well that Intel already has a temporary workaround for this in their kernel driver. So, unfortunately we need to follow suit to avoid causing a regression in userspace. Once these issues get fixed, this commit should be reverted. Signed-off-by: Lyude Paul Cc: Ville Syrjälä --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c index d23ac13763b5..f5ad20af0dd5 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c @@ -2366,6 +2366,18 @@ nv50_display_create(struct drm_device *dev) head->msto = NULL; goto out; } + + /* +* FIXME: This is a hack to workaround the following +* issues: +* +* https://gitlab.gnome.org/GNOME/mutter/issues/759 +* https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277 +* +* Once these issues are closed, this should be +* removed +*/ + head->msto->encoder.possible_crtcs = crtcs; } } -- 2.21.0
[PATCH 3/4] drm/nouveau: dispnv50: Use less encoders by making mstos per-head
Currently, for every single MST capable DRM connector we create a set of
fake encoders, one for each possible head. Unfortunately this ends up
being a huge waste of encoders. While this currently isn't causing us
any problems, it's extremely close to doing so.
The ThinkPad P71 is a good example of this. Originally when trying to
figure out why nouveau was failing to load on this laptop, I discovered
it was because nouveau was creating too many encoders. This ended up
being because we were mistakenly creating MST encoders for the eDP port,
however we are still extremely close to hitting the encoder limit on
this machine as it exposes 1 eDP port and 5 DP ports, resulting in 31
encoders.
So while this fix didn't end up being necessary to fix the P71, we still
need to implement this so that we avoid hitting the encoder limit for
valid display configurations in the event that some machine with more
connectors then this becomes available. Plus, we don't want to let good
code go to waste :)
So, use less encoders by only creating one MSTO per head. Then, attach
each new MSTC to each MSTO which corresponds to a head that it's parent
DP port is capable of using. This brings the number of encoders we
register on the ThinkPad P71 from 31, down to just 15. Yay!
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 92 +++--
drivers/gpu/drm/nouveau/dispnv50/disp.h | 2 +
drivers/gpu/drm/nouveau/dispnv50/head.c | 17 +++--
drivers/gpu/drm/nouveau/dispnv50/head.h | 3 +-
4 files changed, 68 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index a3f350fdfa8c..d23ac13763b5 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -650,7 +650,6 @@ struct nv50_mstm {
struct nouveau_encoder *outp;
struct drm_dp_mst_topology_mgr mgr;
- struct nv50_msto *msto[4];
bool modified;
bool disabled;
@@ -716,7 +715,6 @@ nv50_msto_cleanup(struct nv50_msto *msto)
drm_dp_mst_deallocate_vcpi(>mgr, mstc->port);
msto->mstc = NULL;
- msto->head = NULL;
msto->disabled = false;
}
@@ -846,7 +844,6 @@ nv50_msto_enable(struct drm_encoder *encoder)
mstm->outp->update(mstm->outp, head->base.index, armh, proto, depth);
- msto->head = head;
msto->mstc = mstc;
mstm->modified = true;
}
@@ -887,37 +884,40 @@ nv50_msto = {
.destroy = nv50_msto_destroy,
};
-static int
-nv50_msto_new(struct drm_device *dev, u32 heads, const char *name, int id,
- struct nv50_msto **pmsto)
+static struct nv50_msto *
+nv50_msto_new(struct drm_device *dev, struct nv50_head *head, int id)
{
struct nv50_msto *msto;
int ret;
- if (!(msto = *pmsto = kzalloc(sizeof(*msto), GFP_KERNEL)))
- return -ENOMEM;
+ msto = kzalloc(sizeof(*msto), GFP_KERNEL);
+ if (!msto)
+ return ERR_PTR(-ENOMEM);
ret = drm_encoder_init(dev, >encoder, _msto,
- DRM_MODE_ENCODER_DPMST, "%s-mst-%d", name, id);
+ DRM_MODE_ENCODER_DPMST, "mst-%d", id);
if (ret) {
- kfree(*pmsto);
- *pmsto = NULL;
- return ret;
+ kfree(msto);
+ return ERR_PTR(ret);
}
drm_encoder_helper_add(>encoder, _msto_help);
- msto->encoder.possible_crtcs = heads;
- return 0;
+ msto->encoder.possible_crtcs = drm_crtc_mask(>base.base);
+ msto->head = head;
+ return msto;
}
static struct drm_encoder *
nv50_mstc_atomic_best_encoder(struct drm_connector *connector,
struct drm_connector_state *connector_state)
{
- struct nv50_head *head = nv50_head(connector_state->crtc);
struct nv50_mstc *mstc = nv50_mstc(connector);
+ struct drm_crtc *crtc = connector_state->crtc;
- return >mstm->msto[head->base.index]->encoder;
+ if (!(mstc->mstm->outp->dcb->heads & drm_crtc_mask(crtc)))
+ return NULL;
+
+ return _head(crtc)->msto->encoder;
}
static enum drm_mode_status
@@ -1036,8 +1036,9 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct
drm_dp_mst_port *port,
const char *path, struct nv50_mstc **pmstc)
{
struct drm_device *dev = mstm->outp->base.base.dev;
+ struct drm_crtc *crtc;
struct nv50_mstc *mstc;
- int ret, i;
+ int ret;
if (!(mstc = *pmstc = kzalloc(sizeof(*mstc), GFP_KERNEL)))
return -ENOMEM;
@@ -1057,8 +1058,13 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct
drm_dp_mst_port *port,
mstc->connector.funcs->reset(>connector);
nouveau_conn_attach_properties(>connector);
- for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto[i]; i++)
- drm_connector_attach_encoder(>connector,
>msto[i]->encoder);
+
[PATCH 2/4] drm/nouveau: dispnv50: Remove nv50_mstc_best_encoder()
When drm_connector_helper_funcs->atomic_best_encoder is defined,
->best_encoder is ignored both by the atomic modesetting helpers. That
being said, this hook is completely broken anyway - it always returns
the first msto for a given mstc, despite the fact it might already be in
use.
So, just get rid of it. We'll need this in a moment anyway, when we make
mstos per-head as opposed to per-connector.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index b46be8a091e9..a3f350fdfa8c 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -920,14 +920,6 @@ nv50_mstc_atomic_best_encoder(struct drm_connector
*connector,
return >mstm->msto[head->base.index]->encoder;
}
-static struct drm_encoder *
-nv50_mstc_best_encoder(struct drm_connector *connector)
-{
- struct nv50_mstc *mstc = nv50_mstc(connector);
-
- return >mstm->msto[0]->encoder;
-}
-
static enum drm_mode_status
nv50_mstc_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
@@ -990,7 +982,6 @@ static const struct drm_connector_helper_funcs
nv50_mstc_help = {
.get_modes = nv50_mstc_get_modes,
.mode_valid = nv50_mstc_mode_valid,
- .best_encoder = nv50_mstc_best_encoder,
.atomic_best_encoder = nv50_mstc_atomic_best_encoder,
.atomic_check = nv50_mstc_atomic_check,
};
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/nouveau: dispnv50: Don't create MSTMs for eDP connectors
On the ThinkPad P71, we have one eDP connector exposed along with 5 DP
connectors, resulting in a total of 11 TMDS encoders. Since the GPU on
this system is also capable of MST, we create an additional 4 fake MST
encoders for each DP port. Unfortunately, we also do this for the eDP
port as well, resulting in:
1 eDP port: +1 TMDS encoder
+4 DPMST encoders
5 DP ports: +2 TMDS encoders
+4 DPMST encoders
*5 ports
== 35 encoders
Which breaks things, since DRM has a hard coded limit of 32 encoders.
So, fix this by not creating MSTMs for any eDP connectors. This brings
us down to 31 encoders, although we can do better.
This fixes driver probing for nouveau on the ThinkPad P71.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 307584107d77..b46be8a091e9 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1603,7 +1603,8 @@ nv50_sor_create(struct drm_connector *connector, struct
dcb_output *dcbe)
nv_encoder->aux = aux;
}
- if ((data = nvbios_dp_table(bios, , , , )) &&
+ if (nv_connector->type != DCB_CONNECTOR_eDP &&
+ (data = nvbios_dp_table(bios, , , , )) &&
ver >= 0x40 && (nvbios_rd08(bios, data + 0x08) & 0x04)) {
ret = nv50_mstm_new(nv_encoder, _connector->aux, 16,
nv_connector->base.base.id,
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] drm: kirin: Fix dsi probe/attach logic
On Fri, Sep 13, 2019 at 1:47 AM Andrzej Hajda wrote: > On 12.09.2019 16:18, Matt Redfearn wrote: > > On 12/09/2019 14:21, Andrzej Hajda wrote: > >> On 12.09.2019 04:38, John Stultz wrote: > >>> Should I resubmit the kirin fix for the adv7511 regression here? > >>> Or do we revert the adv7511 patch? I believe db410c still needs a fix. > >>> > >>> I'd just like to keep the HiKey board from breaking, so let me know so > >>> I can get the fix submitted if needed. > >> > >> Since there is no response from Matt, we can perform revert, since there > >> are no other ideas. I will apply it tomorrow, if there are no objections. > > Hi, > > > > Sorry - yeah I think reverting is probably best at this point to avoid > > breaking in-tree platforms. > > It's a shame though that there is a built-in incompatibility within the > > tree between drivers. > > > Quite common in development - some issues becomes visible after some time. > > > The way that the generic Synopsys DSI host driver > > probes is currently incompatible with the ADV7533 (hence the patch), > > other DSI host drivers are now compatible with the ADV7533 but break > > when we change it to probe in a similar way to panel drivers. > > > 1. The behavior should be consistent between all hosts/device drivers. > Yea, I worry about this as well, as I know there is also the lt9611 bridge chip driver pending for the db845c which works against the current msm dsi code. So changing the msm driver for the adv7533 may break other drivers (in the case of lt9611, out of tree - so wouldn't be a regression, but there may be others) written against the current expectations. > 2. DSI controlled devices can expose drm objects (drm_bridge/drm_panel) > only when they can probe, ie DSI bus they sit on must be created 1st. > > 1 and 2 enforces policy that all host drivers should 1st create control > bus (DSI in this case) then look for higher level objects > (drm_bridge/drm_panel). > > As a consequence all bridges and panels should 1st gather the resources > they depends on, and then they can expose higher level objects. > > > > > >> And for the future: I guess it is not possible to make adv work with old > >> and new approach, but simple workaround for adv could be added later: > >> > >> if (source is msm or kirin) > >> > >> do_the_old_way > >> > >> else > >> > >> do_correctly. > > Maybe this would work, but how do we know that the list "msm or kirin" > > is exhaustive to cope with all platforms? > > > By checking dts/config files. > A temporary clearly-marked-deprecated config option might also a reasonable approach while we transition drivers over? > > It seems to me the built in > > incompatibility between DSI hosts needs to be resolved really rather > > than trying to work around it in the ADV7533 driver (and any other DSI > > bus device that falls into this trap). > > > If you know how, please describe. Atm the only real solution I see is > explicit workaround to allow new adv7511, then fixing controllers, > together with workaround-removal. > > OK, it could be possible to change msm, kirin and adv in one patch, > however I am not sure if this is the best solution. Matt: I'm happy to help you test and validate things. Let me know how I can help! thanks -john
Re: drm/amdgpu: remove the redundant null check
On Fri, Sep 6, 2019 at 3:01 AM zhong jiang wrote: > > On 2019/9/5 16:38, Markus Elfring wrote: > >>> Were any source code analysis tools involved for finding > >>> these update candidates? > >> With the help of Coccinelle. You can find out some example in > >> scripts/coccinelle/. > > Thanks for such background information. > > Was the script “ifnullfree.cocci” applied here? > Yep > > Will it be helpful to add attribution for such tools > > to any more descriptions in your patches? > Sometimes, I will add the description in my patches. Not always. Applied with some minor tweaks to the commit message. Thanks! Alex > > Thanks, > zhong jiang > > Regards, > > Markus > > > > . > > > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm/amd: be quiet when no SAD block is found
On Wed, Sep 4, 2019 at 9:18 AM Harry Wentland wrote:
>
> On 2019-09-04 5:12 a.m., Jean Delvare wrote:
> > It is fine for displays without audio functionality to not provide
> > any SAD block in their EDID. Do not log an error in that case,
> > just return quietly.
> >
> > This fixes half of bug fdo#107825:
> > https://bugs.freedesktop.org/show_bug.cgi?id=107825
> >
> > Signed-off-by: Jean Delvare
> > Cc: Alex Deucher
> > Cc: "Christian König"
> > Cc: "David (ChunMing) Zhou"
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: Harry Wentland
> > Cc: Leo Li
>
> Reviewed-by: Harry Wentland
Patches 1 and 2 applied.
Thanks!
Alex
>
> Harry
>
> > ---
> > No change since v1.
> >
> > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|4 ++--
> > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|4 ++--
> > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |4 ++--
> > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |4 ++--
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c |7 +++
> > 5 files changed, 11 insertions(+), 12 deletions(-)
> >
> > --- linux-5.2.orig/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 2019-07-08
> > 00:41:56.0 +0200
> > +++ linux-5.2/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 2019-08-30
> > 14:28:46.081682223 +0200
> > @@ -1345,10 +1345,10 @@ static void dce_v10_0_audio_write_sad_re
> > }
> >
> > sad_count = drm_edid_to_sad(amdgpu_connector_edid(connector), );
> > - if (sad_count <= 0) {
> > + if (sad_count < 0)
> > DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> > + if (sad_count <= 0)
> > return;
> > - }
> > BUG_ON(!sads);
> >
> > for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
> > --- linux-5.2.orig/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 2019-07-08
> > 00:41:56.0 +0200
> > +++ linux-5.2/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 2019-08-30
> > 14:29:27.276205310 +0200
> > @@ -1371,10 +1371,10 @@ static void dce_v11_0_audio_write_sad_re
> > }
> >
> > sad_count = drm_edid_to_sad(amdgpu_connector_edid(connector), );
> > - if (sad_count <= 0) {
> > + if (sad_count < 0)
> > DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> > + if (sad_count <= 0)
> > return;
> > - }
> > BUG_ON(!sads);
> >
> > for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
> > --- linux-5.2.orig/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 2019-07-08
> > 00:41:56.0 +0200
> > +++ linux-5.2/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 2019-08-30
> > 17:58:53.613953458 +0200
> > @@ -1248,10 +1248,10 @@ static void dce_v6_0_audio_write_sad_reg
> > }
> >
> > sad_count = drm_edid_to_sad(amdgpu_connector_edid(connector), );
> > - if (sad_count <= 0) {
> > + if (sad_count < 0)
> > DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> > + if (sad_count <= 0)
> > return;
> > - }
> >
> > for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
> > u32 tmp = 0;
> > --- linux-5.2.orig/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 2019-07-08
> > 00:41:56.0 +0200
> > +++ linux-5.2/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 2019-08-30
> > 14:29:01.948883708 +0200
> > @@ -1298,10 +1298,10 @@ static void dce_v8_0_audio_write_sad_reg
> > }
> >
> > sad_count = drm_edid_to_sad(amdgpu_connector_edid(connector), );
> > - if (sad_count <= 0) {
> > + if (sad_count < 0)
> > DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> > + if (sad_count <= 0)
> > return;
> > - }
> > BUG_ON(!sads);
> >
> > for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
> > ---
> > linux-5.2.orig/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > 2019-07-08 00:41:56.0 +0200
> > +++ linux-5.2/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > 2019-08-30 14:31:03.086421910 +0200
> > @@ -98,11 +98,10 @@ enum dc_edid_status dm_helpers_parse_edi
> > (struct edid *) edid->raw_edid);
> >
> > sad_count = drm_edid_to_sad((struct edid *) edid->raw_edid, );
> > - if (sad_count <= 0) {
> > - DRM_INFO("SADs count is: %d, don't need to read it\n",
> > - sad_count);
> > + if (sad_count < 0)
> > + DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> > + if (sad_count <= 0)
> > return result;
> > - }
> >
> > edid_caps->audio_mode_count = sad_count < DC_MAX_AUDIO_DESC_COUNT ?
> > sad_count : DC_MAX_AUDIO_DESC_COUNT;
> > for (i = 0; i < edid_caps->audio_mode_count; ++i) {
> >
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Re: [PATCH v2 24/27] drm/amdgpu/dm: Resume short HPD IRQs before resuming MST topology
On Tue, Sep 3, 2019 at 4:49 PM Lyude Paul wrote:
>
> Since we're going to be reprobing the entire topology state on resume
> now using sideband transactions, we need to ensure that we actually have
> short HPD irqs enabled before calling drm_dp_mst_topology_mgr_resume().
> So, do that.
>
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Daniel Vetter
> Signed-off-by: Lyude Paul
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 73630e2940d4..4d3c8bff77da 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1185,15 +1185,15 @@ static int dm_resume(void *handle)
> /* program HPD filter */
> dc_resume(dm->dc);
>
> - /* On resume we need to rewrite the MSTM control bits to enamble
> MST*/
> - s3_handle_mst(ddev, false);
> -
> /*
> * early enable HPD Rx IRQ, should be done before set mode as short
> * pulse interrupts are used for MST
> */
> amdgpu_dm_irq_resume_early(adev);
>
> + /* On resume we need to rewrite the MSTM control bits to enamble
> MST*/
> + s3_handle_mst(ddev, false);
> +
> /* Do detection*/
> drm_connector_list_iter_begin(ddev, );
> drm_for_each_connector_iter(connector, ) {
> --
> 2.21.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 23/27] drm/amdgpu: Iterate through DRM connectors correctly
On Tue, Sep 3, 2019 at 4:49 PM Lyude Paul wrote:
>
> Currently, every single piece of code in amdgpu that loops through
> connectors does it incorrectly and doesn't use the proper list iteration
> helpers, drm_connector_list_iter_begin() and
> drm_connector_list_iter_end(). Yeesh.
>
> So, do that.
In fairness, I think the origin of this code predated the iterators.
Reviewed-by: Alex Deucher
>
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Daniel Vetter
> Signed-off-by: Lyude Paul
> ---
> .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 13 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 20 +++---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 5 ++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c | 40 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 5 ++-
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 34
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 34
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 40 ++-
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 34
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 33 ---
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 10 -
> 11 files changed, 195 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index ece55c8fa673..bd31bb595c04 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -1022,8 +1022,12 @@ amdgpu_connector_dvi_detect(struct drm_connector
> *connector, bool force)
> */
> if (amdgpu_connector->shared_ddc && (ret ==
> connector_status_connected)) {
> struct drm_connector *list_connector;
> + struct drm_connector_list_iter iter;
> struct amdgpu_connector
> *list_amdgpu_connector;
> - list_for_each_entry(list_connector,
> >mode_config.connector_list, head) {
> +
> + drm_connector_list_iter_begin(dev, );
> + drm_for_each_connector_iter(list_connector,
> + ) {
> if (connector == list_connector)
> continue;
> list_amdgpu_connector =
> to_amdgpu_connector(list_connector);
> @@ -1040,6 +1044,7 @@ amdgpu_connector_dvi_detect(struct drm_connector
> *connector, bool force)
> }
> }
> }
> + drm_connector_list_iter_end();
> }
> }
> }
> @@ -1501,6 +1506,7 @@ amdgpu_connector_add(struct amdgpu_device *adev,
> {
> struct drm_device *dev = adev->ddev;
> struct drm_connector *connector;
> + struct drm_connector_list_iter iter;
> struct amdgpu_connector *amdgpu_connector;
> struct amdgpu_connector_atom_dig *amdgpu_dig_connector;
> struct drm_encoder *encoder;
> @@ -1515,10 +1521,12 @@ amdgpu_connector_add(struct amdgpu_device *adev,
> return;
>
> /* see if we already added it */
> - list_for_each_entry(connector, >mode_config.connector_list,
> head) {
> + drm_connector_list_iter_begin(dev, );
> + drm_for_each_connector_iter(connector, ) {
> amdgpu_connector = to_amdgpu_connector(connector);
> if (amdgpu_connector->connector_id == connector_id) {
> amdgpu_connector->devices |= supported_device;
> + drm_connector_list_iter_end();
> return;
> }
> if (amdgpu_connector->ddc_bus && i2c_bus->valid) {
> @@ -1533,6 +1541,7 @@ amdgpu_connector_add(struct amdgpu_device *adev,
> }
> }
> }
> + drm_connector_list_iter_end();
>
> /* check if it's a dp bridge */
> list_for_each_entry(encoder, >mode_config.encoder_list, head) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 2f884699eaef..acd39ce9b08e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3004,6 +3004,7 @@ int amdgpu_device_suspend(struct drm_device *dev, bool
> suspend, bool fbcon)
> struct amdgpu_device *adev;
> struct drm_crtc *crtc;
> struct drm_connector *connector;
> + struct drm_connector_list_iter iter;
> int r;
>
> if (dev == NULL || dev->dev_private == NULL) {
> @@ -3026,9 +3027,11 @@ int
[Bug 111273] crash calling AMDGPU_INFO_READ_MMR_REG with count set to -1
https://bugs.freedesktop.org/show_bug.cgi?id=111273 --- Comment #3 from Alex Deucher --- Applied. thanks! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/v3d: clean caches at the end of render jobs on request from user space
Iago Toral writes:
> On Thu, 2019-09-12 at 10:25 -0700, Eric Anholt wrote:
>> Iago Toral Quiroga writes:
>>
>> > Extends the user space ioctl for CL submissions so it can include a
>> > request
>> > to flush the cache once the CL execution has completed. Fixes
>> > memory
>> > write violation messages reported by the kernel in workloads
>> > involving
>> > shader memory writes (SSBOs, shader images, scratch, etc) which
>> > sometimes
>> > also lead to GPU resets during Piglit and CTS workloads.
>>
>> Some context for any other reviewers: This patch is the interface
>> change
>> necessary to expose GLES 3.1 on V3D. It turns out the HW packets for
>> flushing the caches were broken in multiple ways.
>>
>> > Signed-off-by: Iago Toral Quiroga
>> > ---
>> > drivers/gpu/drm/v3d/v3d_gem.c | 51 +
>> > --
>> > include/uapi/drm/v3d_drm.h| 7 ++---
>> > 2 files changed, 47 insertions(+), 11 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/v3d/v3d_gem.c
>> > b/drivers/gpu/drm/v3d/v3d_gem.c
>> > index 5d80507b539b..530fe9d9d5bd 100644
>> > --- a/drivers/gpu/drm/v3d/v3d_gem.c
>> > +++ b/drivers/gpu/drm/v3d/v3d_gem.c
>> > @@ -530,13 +530,16 @@ v3d_submit_cl_ioctl(struct drm_device *dev,
>> > void *data,
>> >struct drm_v3d_submit_cl *args = data;
>> >struct v3d_bin_job *bin = NULL;
>> >struct v3d_render_job *render;
>> > + struct v3d_job *clean_job = NULL;
>> > + struct v3d_job *last_job;
>> >struct ww_acquire_ctx acquire_ctx;
>> >int ret = 0;
>> >
>> >trace_v3d_submit_cl_ioctl(>drm, args->rcl_start, args-
>> > >rcl_end);
>> >
>> > - if (args->pad != 0) {
>> > - DRM_INFO("pad must be zero: %d\n", args->pad);
>> > + if (args->flags != 0 &&
>> > + args->flags != DRM_V3D_SUBMIT_CL_FLUSH_CACHE_FLAG) {
>> > + DRM_INFO("invalid flags: %d\n", args->flags);
>> >return -EINVAL;
>> >}
>> >
>> > @@ -575,12 +578,28 @@ v3d_submit_cl_ioctl(struct drm_device *dev,
>> > void *data,
>> >bin->render = render;
>> >}
>> >
>> > - ret = v3d_lookup_bos(dev, file_priv, >base,
>> > + if (args->flags & DRM_V3D_SUBMIT_CL_FLUSH_CACHE_FLAG) {
>> > + clean_job = kcalloc(1, sizeof(*clean_job), GFP_KERNEL);
>> > + if (!clean_job) {
>> > + ret = -ENOMEM;
>> > + goto fail;
>> > + }
>> > +
>> > + ret = v3d_job_init(v3d, file_priv, clean_job,
>> > v3d_job_free, 0);
>> > + if (ret)
>> > + goto fail;
>>
>> Only issue I see: If v3d_job_init() fails, we need to not
>> v3d_job_put()
>> it. I'm fine with either kfree() it and NULL the ptr before jumping
>> to
>> fail, or open code the bin/render puts.
>
> It seems we also call v3d_job_put() for the bin job when v3d_job_init()
> fails, which also returns immediately in that case instead of jumping
> to fail to v3d_job_put the render job, so I guess we need the same
> treatment there. Shall I fix that in this patch too or would you rather
> see a different patch sent separately for that?
I think you might be looking at the put of the (already-inited) render
job when initing bin job fails?
Looks like we do leak bin in that case, though. Happy to see that as a
fixup patch.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: Bail earlier when radeon.cik_/si_support=0 is passed
On Wed, Sep 11, 2019 at 11:29 AM Deucher, Alexander wrote: > > > -Original Message- > > From: Hans de Goede > > Sent: Tuesday, September 10, 2019 5:36 AM > > To: Michel Dänzer ; Deucher, Alexander > > ; Koenig, Christian > > ; Zhou, David(ChunMing) > > > > Cc: David Airlie ; dri-devel@lists.freedesktop.org; amd- > > g...@lists.freedesktop.org; Daniel Vetter > > Subject: Re: [PATCH] drm/radeon: Bail earlier when > > radeon.cik_/si_support=0 is passed > > > > Hi, > > > > On 9/10/19 9:50 AM, Michel Dänzer wrote: > > > On 2019-09-07 10:32 p.m., Hans de Goede wrote: > > >> Bail from the pci_driver probe function instead of from the > > >> drm_driver load function. > > >> > > >> This avoid /dev/dri/card0 temporarily getting registered and then > > >> unregistered again, sending unwanted add / remove udev events to > > >> userspace. > > >> > > >> Specifically this avoids triggering the (userspace) bug fixed by this > > >> plymouth merge-request: > > >> https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59 > > >> > > >> Note that despite that being an userspace bug, not sending > > >> unnecessary udev events is a good idea in general. > > >> > > >> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490 > > >> Signed-off-by: Hans de Goede > > > > > > Reviewed-by: Michel Dänzer > > > > Thank you for the review. I've drm push rights, but I guess that radeon/amd > > GPU patches are collected by someone @AMD, so I do not need to / should > > not push this myself, right? > > I'll pick this up later this week when I get home from travel. Applied. Thanks! Alex > > Thanks! > > Alex > > > > > > amdgpu should be changed correspondingly as well. > > > > Good point. I'm currently travelling (@plumbers) I can do this when I'm back > > home, but feel free to beat me to it (if you do please Cc me to avoid double > > work). > > > > Regards, > > > > Hans > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: rename variable eanble -> enable
On Fri, Sep 13, 2019 at 4:02 AM Colin King wrote:
>
> From: Colin Ian King
>
> There is a spelling mistake in the variable name eanble,
> rename it to enable.
>
> Signed-off-by: Colin Ian King
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
> b/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
> index 1488ffddf4e3..5944524faab9 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
> @@ -606,11 +606,11 @@ static void dce_mi_allocate_dmif(
> }
>
> if (dce_mi->wa.single_head_rdreq_dmif_limit) {
> - uint32_t eanble = (total_stream_num > 1) ? 0 :
> + uint32_t enable = (total_stream_num > 1) ? 0 :
> dce_mi->wa.single_head_rdreq_dmif_limit;
>
> REG_UPDATE(MC_HUB_RDREQ_DMIF_LIMIT,
> - ENABLE, eanble);
> + ENABLE, enable);
> }
> }
>
> @@ -636,11 +636,11 @@ static void dce_mi_free_dmif(
> 10, 3500);
>
> if (dce_mi->wa.single_head_rdreq_dmif_limit) {
> - uint32_t eanble = (total_stream_num > 1) ? 0 :
> + uint32_t enable = (total_stream_num > 1) ? 0 :
> dce_mi->wa.single_head_rdreq_dmif_limit;
>
> REG_UPDATE(MC_HUB_RDREQ_DMIF_LIMIT,
> - ENABLE, eanble);
> + ENABLE, enable);
> }
> }
>
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: display: Add xylon logicvc bindings documentation
On Fri, Sep 13, 2019 at 4:58 PM Paul Kocialkowski wrote: > > Hi Rob and thanks for the review! > > On Fri 13 Sep 19, 15:35, Rob Herring wrote: > > On Tue, Sep 10, 2019 at 05:34:08PM +0200, Paul Kocialkowski wrote: > > > The Xylon LogiCVC is a display controller implemented as programmable > > > logic in Xilinx FPGAs. > > > > > > Signed-off-by: Paul Kocialkowski > > > --- > > > .../bindings/display/xylon,logicvc.txt| 188 ++ > > > 1 file changed, 188 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/display/xylon,logicvc.txt > > > > Consider converting this to DT schema format. See > > Documentation/devicetree/writing-schema.rst (.md in 5.3). > > Oh right, that would certainly be much more future-proof! > > > > diff --git a/Documentation/devicetree/bindings/display/xylon,logicvc.txt > > > b/Documentation/devicetree/bindings/display/xylon,logicvc.txt > > > new file mode 100644 > > > index ..eb4b1553888a > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/display/xylon,logicvc.txt > > > @@ -0,0 +1,188 @@ > > > +Xylon LogiCVC display controller > > > + > > > +The Xylon LogiCVC is a display controller that supports multiple layers. > > > +It is usually implemented as programmable logic and was optimized for use > > > +with Xilinx Zynq-7000 SoCs and Xilinx FPGAs. > > > + > > > +Because the controller is intended for use in a FPGA, most of the > > > configuration > > > +of the controller takes place at logic configuration bitstream synthesis > > > time. > > > +As a result, many of the device-tree bindings are meant to reflect the > > > +synthesis configuration. These do not allow configuring the controller > > > +differently than synthesis configuration. > > > + > > > +Layers are declared in the "layers" sub-node and have dedicated > > > configuration. > > > +In version 3 of the controller, each layer has fixed memory offset and > > > address > > > +starting from the video memory base address for its framebuffer. With > > > version 4, > > > +framebuffers are configured with a direct memory address instead. > > > + > > > +Matching synthesis parameters are provided when applicable. > > > + > > > +Required properties: > > > +- compatible: Should be one of: > > > + "xylon,logicvc-3.02.a-display" > > > + "xylon,logicvc-4.01.a-display" > > > +- reg: Physical base address and size for the controller registers. > > > +- clocks: List of phandle and clock-specifier pairs, one for each entry > > > + in 'clock-names' > > > +- clock-names: List of clock names that should at least contain: > > > + - "vclk": The VCLK video clock input. > > > +- interrupts: The interrupt to use for VBLANK signaling. > > > +- xylon,display-interface: Display interface in use, should be one of: > > > + - "lvds-4bits": 4-bit LVDS interface (C_DISPLAY_INTERFACE == 4). > > > +- xylon,display-colorspace: Display output colorspace in use, should be > > > one of: > > > + - "rgb": RGB colorspace (C_DISPLAY_COLOR_SPACE == 0). > > > +- xylon,display-depth: Display output depth in use (C_PIXEL_DATA_WIDTH). > > > +- xylon,row-stride: Fixed number of pixels in a framebuffer row > > > (C_ROW_STRIDE). > > > +- xylon,layers-count: The number of available layers (C_NUM_OF_LAYERS). > > > > Presumably some of this is determined by the display attached. Isn't it > > safe to assume the IP was configured correctly for the intended display > > and you can just get this from the panel? > > Layers are what corresponds to DRM planes, which are not actually indicated > by the panel but are a charasteristic of the display controller. In our case, > this is directly selected at bitstream synthesis time for the controller. > > So I'm afraid there is no way we can auto-detect this from the driver. Sorry, I referring to the set of properties above. In particular, xylon,display-interface and xylon,display-colorspace, though I don't know if the latter is talking in memory format or on the wire format. Actually for xylon,layers-count, You should just count the child nodes of 'layers'. > > > +Optional properties: > > > +- memory-region: phandle to a node describing memory, as specified in: > > > + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > > +- clock-names: List of clock names that can optionally contain: > > > + - "vclk2": The VCLK2 doubled-rate video clock input. > > > + - "lvdsclk": The LVDS clock. > > > + - "lvdsclkn": The LVDS clock inverted. > > > > How are these really optional? > > Well, the controller currently only supports LVDS, but more interfaces may be > added later, so the lvdsclk clock will be optional when another interface > is used instead. Maybe I'm mistaken about how to categorize them though. > > My understanding is that the need for vclk2 and lvdsclkn depend on the target > FPGA family. I've developped the driver without the need for them, but the > datasheet states that they may be needed (but doesn't provide significant >
Re: [PATCH v7 3/7] drm: Add DisplayPort colorspace property
On Thu, Sep 12, 2019 at 02:33:34PM +0300, Gwan-gyeong Mun wrote:
> Because between HDMI and DP have different colorspaces, it renames
> drm_mode_create_colorspace_property() function to
> drm_mode_create_hdmi_colorspace_property() function for HDMI connector.
> And it adds drm_mode_create_dp_colorspace_property() function for creating
> of DP colorspace property.
> In order to apply changed and added drm api, i915 driver has channged.
>
> v3: Addressed review comments from Ville
> - Add new colorimetry options for DP 1.4a spec.
> - Separate set of colorimetry enum values for DP.
> v4: Add additional comments to struct drm_prop_enum_list.
> Polishing an enum string of struct drm_prop_enum_list
> v5: Change definitions of DRM_MODE_COLORIMETRYs to follow HDMI prefix and
> DP abbreviations.
> Add missed variables on dp_colorspaces.
> Fix typo. [Uma]
> v6: Addressed review comments from Ilia and Ville
>- Split drm_mode_create_colorspace_property() to DP and HDMI connector.
> v7: Fix typo [Jani Saarinen]
> Fix white space.
>
> Signed-off-by: Gwan-gyeong Mun
> Reviewed-by: Uma Shankar
> ---
> drivers/gpu/drm/drm_connector.c | 110 +++---
> .../gpu/drm/i915/display/intel_connector.c| 21 +++-
> include/drm/drm_connector.h | 11 +-
> 3 files changed, 121 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 4c766624b20d..656f72c1b3d7 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -882,6 +882,47 @@ static const struct drm_prop_enum_list
> hdmi_colorspaces[] = {
> { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
> };
>
> +/*
> + * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel
> Encoding/Colorimetry
> + * Format Table 2-120
> + */
> +static const struct drm_prop_enum_list dp_colorspaces[] = {
> + /* For Default case, driver will set the colorspace */
> + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> + /* Colorimetry based on sRGB (IEC 61966-2-1) */
> + { DRM_MODE_COLORIMETRY_CEA_RGB, "CEA_RGB" },
We already have other mechanism for the CEA vs. IT RGB.
I don't think we want to add another one. So I'd drop this.
> + { DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED, "RGB_Wide_Gamut_Fixed_Point" },
> + /* Colorimetry based on scRGB (IEC 61966-2-2) */
> + { DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT, "RGB_Wide_Gamut_Floating_Point"
> },
> + /* Colorimetry based on IEC 61966-2-5 */
> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
> + /* Colorimetry based on SMPTE RP 431-2 */
> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
> + { DRM_MODE_COLORIMETRY_RGB_CUSTOM_COLOR_PROFILE,
> "RGB_Custom_Color_Profile" },
I'd also drop this since we have no way to supply the profile anyway.
> + /* Colorimetry based on ITU-R BT.2020 */
> + { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> + { DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC" },
> + { DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> + { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
> + /* High Definition Colorimetry based on IEC 61966-2-4 */
> + { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> + { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
> + /* Colorimetry based on IEC 61966-2-5 [33] */
> + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
> + /* Colorimetry based on ITU-R BT.2020 */
> + { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
> + /* Colorimetry based on ITU-R BT.2020 */
> + { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
> + /*
> + * Colorimetry based on Digital Imaging and Communications in Medicine
> + * (DICOM) Part 14: Grayscale Standard Display Function
> + */
> + { DRM_MODE_COLORIMETRY_Y_ONLY_DICOM_P14_GRAYSCALE,
> "Y_ONLY_DICOM_Part_14_Grayscale" },
> + { DRM_MODE_COLORIMETRY_RAW_CUSTOM_COLOR_PROFILE,
> "Raw_Custom_Color_Profile" },
And these last two seem rather esoteric as well. I don't think any
driver supports RAW/Y stuff so I'd drop them too.
> +};
> +
> /**
> * DOC: standard connector properties
> *
> @@ -1674,7 +1715,6 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
> * DOC: standard connector properties
> *
> * Colorspace:
> - * drm_mode_create_colorspace_property - create colorspace property
> * This property helps select a suitable colorspace based on the sink
> * capability. Modern sink devices support wider gamut like BT2020.
> * This helps switch to BT2020 mode if the BT2020 encoded video stream
> @@ -1694,32 +1734,68 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
> * - This property is just to inform sink what colorspace
> *source is trying to drive.
> *
> + * Because
Re: [PATCH 2/2] drm/panfrost: Simplify devfreq utilisation tracking
Patch 1 is:
Acked-by: Alyssa Rosenzweig
Patch 2 is:
Reviewed-by: Alyssa Rosenzweig
Good stuff as always!
On Thu, Sep 12, 2019 at 12:28:04PM +0100, Steven Price wrote:
> Instead of tracking per-slot utilisation track a single value for the
> entire GPU. Ultimately it doesn't matter if the GPU is busy with only
> vertex or a combination of vertex and fragment processing - if it's busy
> then it's busy and devfreq should be scaling appropriately.
>
> This also makes way for being able to submit multiple jobs per slot
> which requires more values than the original boolean per slot.
>
> Signed-off-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 64 -
> drivers/gpu/drm/panfrost/panfrost_devfreq.h | 3 +-
> drivers/gpu/drm/panfrost/panfrost_device.h | 12 ++--
> drivers/gpu/drm/panfrost/panfrost_job.c | 14 ++---
> 4 files changed, 38 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> index 7ded282a5ca8..4c4e8a30a1ac 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> @@ -13,7 +13,7 @@
> #include "panfrost_gpu.h"
> #include "panfrost_regs.h"
>
> -static void panfrost_devfreq_update_utilization(struct panfrost_device
> *pfdev, int slot);
> +static void panfrost_devfreq_update_utilization(struct panfrost_device
> *pfdev);
>
> static int panfrost_devfreq_target(struct device *dev, unsigned long *freq,
> u32 flags)
> @@ -32,37 +32,23 @@ static int panfrost_devfreq_target(struct device *dev,
> unsigned long *freq,
>
> static void panfrost_devfreq_reset(struct panfrost_device *pfdev)
> {
> - ktime_t now = ktime_get();
> - int i;
> -
> - for (i = 0; i < NUM_JOB_SLOTS; i++) {
> - pfdev->devfreq.slot[i].busy_time = 0;
> - pfdev->devfreq.slot[i].idle_time = 0;
> - pfdev->devfreq.slot[i].time_last_update = now;
> - }
> + pfdev->devfreq.busy_time = 0;
> + pfdev->devfreq.idle_time = 0;
> + pfdev->devfreq.time_last_update = ktime_get();
> }
>
> static int panfrost_devfreq_get_dev_status(struct device *dev,
> struct devfreq_dev_status *status)
> {
> struct panfrost_device *pfdev = dev_get_drvdata(dev);
> - int i;
>
> - for (i = 0; i < NUM_JOB_SLOTS; i++) {
> - panfrost_devfreq_update_utilization(pfdev, i);
> - }
> + panfrost_devfreq_update_utilization(pfdev);
>
> status->current_frequency = clk_get_rate(pfdev->clock);
> - status->total_time =
> ktime_to_ns(ktime_add(pfdev->devfreq.slot[0].busy_time,
> -
> pfdev->devfreq.slot[0].idle_time));
> -
> - status->busy_time = 0;
> - for (i = 0; i < NUM_JOB_SLOTS; i++) {
> - status->busy_time +=
> ktime_to_ns(pfdev->devfreq.slot[i].busy_time);
> - }
> + status->total_time = ktime_to_ns(ktime_add(pfdev->devfreq.busy_time,
> +pfdev->devfreq.idle_time));
>
> - /* We're scheduling only to one core atm, so don't divide for now */
> - /* status->busy_time /= NUM_JOB_SLOTS; */
> + status->busy_time = ktime_to_ns(pfdev->devfreq.busy_time);
>
> panfrost_devfreq_reset(pfdev);
>
> @@ -134,14 +120,10 @@ void panfrost_devfreq_fini(struct panfrost_device
> *pfdev)
>
> void panfrost_devfreq_resume(struct panfrost_device *pfdev)
> {
> - int i;
> -
> if (!pfdev->devfreq.devfreq)
> return;
>
> panfrost_devfreq_reset(pfdev);
> - for (i = 0; i < NUM_JOB_SLOTS; i++)
> - pfdev->devfreq.slot[i].busy = false;
>
> devfreq_resume_device(pfdev->devfreq.devfreq);
> }
> @@ -154,9 +136,8 @@ void panfrost_devfreq_suspend(struct panfrost_device
> *pfdev)
> devfreq_suspend_device(pfdev->devfreq.devfreq);
> }
>
> -static void panfrost_devfreq_update_utilization(struct panfrost_device
> *pfdev, int slot)
> +static void panfrost_devfreq_update_utilization(struct panfrost_device
> *pfdev)
> {
> - struct panfrost_devfreq_slot *devfreq_slot = >devfreq.slot[slot];
> ktime_t now;
> ktime_t last;
>
> @@ -164,22 +145,27 @@ static void panfrost_devfreq_update_utilization(struct
> panfrost_device *pfdev, i
> return;
>
> now = ktime_get();
> - last = pfdev->devfreq.slot[slot].time_last_update;
> + last = pfdev->devfreq.time_last_update;
>
> - /* If we last recorded a transition to busy, we have been idle since */
> - if (devfreq_slot->busy)
> - pfdev->devfreq.slot[slot].busy_time += ktime_sub(now, last);
> + if (atomic_read(>devfreq.busy_count) > 0)
> + pfdev->devfreq.busy_time += ktime_sub(now, last);
> else
> - pfdev->devfreq.slot[slot].idle_time += ktime_sub(now, last);
> +
Re: [PATCH] drm/panfrost: Prevent race when handling page fault
I'm conflicted on this series.
On the one hand, userspace should obviously not be able to crash the
kernel. So the crash should be fixed in one way or another.
On the other hand, userspace really has to supply all the BOs it uses
for correctness. I realize the DDK doesn't do this but... it probably
should, umm...
Would it be possible to check for the NULL pointer in the kernel and
skip printing information that would require a dereference? (Without
having to play games with reference counts). Presumably that might fix
crashes in other corner cases.
On Thu, Sep 05, 2019 at 01:11:41PM +0100, Steven Price wrote:
> When handling a GPU page fault addr_to_drm_mm_node() is used to
> translate the GPU address to a buffer object. However it is possible for
> the buffer object to be freed after the function has returned resulting
> in a use-after-free of the BO.
>
> Change addr_to_drm_mm_node to return the panfrost_gem_object with an
> extra reference on it, preventing the BO from being freed until after
> the page fault has been handled.
>
> Signed-off-by: Steven Price
> ---
>
> I've managed to trigger this, generating the following stack trace.
>
> Unable to handle kernel NULL pointer dereference at virtual address 0090
> pgd = 33a6a181
> [0090] *pgd=
> Internal error: Oops: 5 [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 81 Comm: irq/60-mmu Not tainted 5.3.0-rc1+ #4
> Hardware name: Rockchip (Device Tree)
> PC is at panfrost_mmu_map_fault_addr+0x140/0x3a0
> LR is at _raw_spin_unlock+0x20/0x3c
> pc : []lr : []psr: 20030013
> sp : ec643e88 ip : ea70ce24 fp : ec5fe840
> r10: 0001 r9 : r8 : 000178c9
> r7 : r6 : 178c9f00 r5 : ec5fe940 r4 : ea70ce08
> r3 : r2 : r1 : ec640e00 r0 : ec5fe940
> Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> Control: 10c5387d Table: 29f8406a DAC: 0051
> Process irq/60-mmu (pid: 81, stack limit = 0x4b907106)
> Stack: (0xec643e88 to 0xec644000)
> 3e80: ec640e00 c07cede0 c0c0b200 ec640e00
> 3ea0: 000178c9 c0c0b200 c07cede0 eef91040 ec5fe840 0001
> 3ec0: 00010001 010003c3 00c3 0001 178c9f00 c0508c98 eef91050
> 3ee0: ec643f34 c07c9188 0001 c0167854 ec643ef8 c0c08448 c07c933c
> 3f00: ec643f04 fffefffe 3d182b17 ee193468 ee193400 ec5db3c0 ec5db3c0
> 3f20: c0183840 ec5db3e4 c0cb2874 c0183b08 0001 c018385c e000 ee193400
> 3f40: ec5db3c0 c0183b8c c0c08448 6013 c01839b8 3d182b17
> 3f60: e000 ec5d0500 ec5db380 ec642000 ec5db3c0 c0183a64 ed025cd8
> 3f80: ec5d0538 c0146cfc ec642000 ec5db380 c0146bc0
> 3fa0: c01010b4
> 3fc0:
> 3fe0: 0013
> [] (panfrost_mmu_map_fault_addr) from []
> (panfrost_mmu_irq_handler_thread+0xf4/0x248)
> [] (panfrost_mmu_irq_handler_thread) from []
> (irq_thread_fn+0x1c/0x58)
> [] (irq_thread_fn) from [] (irq_thread+0x128/0x240)
> [] (irq_thread) from [] (kthread+0x13c/0x154)
> [] (kthread) from [] (ret_from_fork+0x14/0x20)
> Exception stack(0xec643fb0 to 0xec643ff8)
> 3fa0:
> 3fc0:
> 3fe0: 0013
> Code: 1aec eae8 e5143004 e59d2014 (e5933090)
> ---[ end trace 04eadc3009b8f507 ]---
> ---
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 38 -
> 1 file changed, 24 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> index 842bdd7cf6be..115925e7460a 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> @@ -392,9 +392,11 @@ void panfrost_mmu_pgtable_free(struct panfrost_file_priv
> *priv)
> free_io_pgtable_ops(mmu->pgtbl_ops);
> }
>
> -static struct drm_mm_node *addr_to_drm_mm_node(struct panfrost_device
> *pfdev, int as, u64 addr)
> +static struct panfrost_gem_object *
> +addr_to_drm_mm_node(struct panfrost_device *pfdev, int as, u64 addr)
> {
> - struct drm_mm_node *node = NULL;
> + struct panfrost_gem_object *bo = NULL;
> + struct drm_mm_node *node;
> u64 offset = addr >> PAGE_SHIFT;
> struct panfrost_mmu *mmu;
>
> @@ -406,14 +408,17 @@ static struct drm_mm_node *addr_to_drm_mm_node(struct
> panfrost_device *pfdev, in
>
> priv = container_of(mmu, struct panfrost_file_priv, mmu);
> drm_mm_for_each_node(node, >mm) {
> - if (offset >= node->start && offset < (node->start +
> node->size))
> + if (offset >= node->start &&
> + offset <
Re: Kernel panic during drm/nouveau init 5.3.0-rc7-next-20190903
On Mon, Sep 9, 2019 at 12:25 PM Alexander Kapshuk wrote: > > On Mon, Sep 9, 2019 at 1:21 PM Stephen Rothwell wrote: > > > > Hi, > > > > On Mon, 9 Sep 2019 20:11:59 +1000 Stephen Rothwell > > wrote: > > > > > > If you are bisecting linux-next, I will suggest bisecting between the > > > stable branch on linux-next (which is just Linus' tree when I started > > > that day) and the top of the first linux-next that fails. (Assuming > > > that the stable branch is good). > > > > Actually (since you won't be bisecting the latest linux-next), you > > probably want to use > > > > git merge-base stable next-20190903 > > (or whatever linux-next you are bisecting) > > > > as your first good commit (assuming it id good :-)). > > > > -- > > Cheers, > > Stephen Rothwell > > Hi Stephen, > > Thanks very much for the tips. > I'll go ahead and give those a try. Yeah this should help, but in general, due to our non-linear history, git bisect can jump around quite a bit. Especially if you only look at dates. Also due to our non-linear history, it sometimes needs to test you a merge-base, to figure out which part of the history it needs to chase for the bad commit. So all normal, but the hint above should help. Also, you don't need to restart git bisect, you can just tell it about any good/bad commit you tested with $ git bisect good|bad $sha1 The more git knows, the quicker it should find the bad commit. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: image size is wrong in EDID, how to use EDID quirks
On Fri, 2019-09-13 at 04:21 +, zhangn1...@outlook.com wrote: > Dear developers > > I have a Samsung 40’ HDMI TV, which has wrong EDID. > > The actaul size of this TV is 40’ (88cm*49cm), but in EDID the size > is 49’ (106*63cm) > > Thus makes image size is larger than screen, both in console and > desktop. That's not how EDID works in Linux. It's only used to compute the DPI of the screen, not to scale the image. If the image on the TV looks like it extends off the edge of the TV you need to find the "overscan" setting in your TV and turn it off. - ajax ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/7] drm/ttm: TTM fault handler helpers
On 9/13/19 3:40 PM, Hillf Danton wrote:
On Fri, 13 Sep 2019 11:32:09 +0200
err = ttm_mem_io_lock(man, true);
- if (unlikely(err != 0)) {
- ret = VM_FAULT_NOPAGE;
- goto out_unlock;
- }
+ if (unlikely(err != 0))
+ return VM_FAULT_NOPAGE;
err = ttm_mem_io_reserve_vm(bo);
- if (unlikely(err != 0)) {
- ret = VM_FAULT_SIGBUS;
- goto out_io_unlock;
- }
+ if (unlikely(err != 0))
+ return VM_FAULT_SIGBUS;
Hehe, no hurry.
Ah. I get the point :) Yes, I'll update. Haven't been looking at these
patches for a while.
Thanks,
Thomas
Re: [RFC PATCH 3/7] drm/ttm: TTM fault handler helpers
On 9/13/19 5:18 PM, Matthew Wilcox wrote:
On Fri, Sep 13, 2019 at 11:32:09AM +0200, Thomas Hellström (VMware) wrote:
+vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
+ pgprot_t prot,
+ pgoff_t num_prefault)
+{
+ struct vm_area_struct *vma = vmf->vma;
+ struct vm_area_struct cvma = *vma;
+ struct ttm_buffer_object *bo = (struct ttm_buffer_object *)
+ vma->vm_private_data;
It's a void *. There's no need to cast it.
struct ttm_buffer_object *bo = vma->vm_private_data;
conveys exactly the same information to both the reader and the compiler,
except it's all on one line instead of split over two.
Indeed.
However since this is mostly a restructuring commit and there are a
couple of these present in the code I'd like to keep cleanups separate.
Thanks,
Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/panfrost: Prevent race when handling page fault
When handling a GPU page fault addr_to_drm_mm_node() is used to
translate the GPU address to a buffer object. However it is possible for
the buffer object to be freed after the function has returned resulting
in a use-after-free of the BO.
Change addr_to_drm_mm_node to return the panfrost_gem_object with an
extra reference on it, preventing the BO from being freed until after
the page fault has been handled.
Signed-off-by: Steven Price
---
Changes since v1:
* Hold the mm_lock around drm_mm_for_each_node()
I've also posted a new IGT test for this:
https://patchwork.freedesktop.org/patch/330513/
drivers/gpu/drm/panfrost/panfrost_mmu.c | 55 -
1 file changed, 36 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 842bdd7cf6be..b6b281896ed6 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -392,28 +392,40 @@ void panfrost_mmu_pgtable_free(struct panfrost_file_priv
*priv)
free_io_pgtable_ops(mmu->pgtbl_ops);
}
-static struct drm_mm_node *addr_to_drm_mm_node(struct panfrost_device *pfdev,
int as, u64 addr)
+static struct panfrost_gem_object *
+addr_to_drm_mm_node(struct panfrost_device *pfdev, int as, u64 addr)
{
- struct drm_mm_node *node = NULL;
+ struct panfrost_gem_object *bo = NULL;
+ struct panfrost_file_priv *priv;
+ struct drm_mm_node *node;
u64 offset = addr >> PAGE_SHIFT;
struct panfrost_mmu *mmu;
spin_lock(>as_lock);
list_for_each_entry(mmu, >as_lru_list, list) {
- struct panfrost_file_priv *priv;
- if (as != mmu->as)
- continue;
+ if (as == mmu->as)
+ break;
+ }
+ if (as != mmu->as)
+ goto out;
+
+ priv = container_of(mmu, struct panfrost_file_priv, mmu);
- priv = container_of(mmu, struct panfrost_file_priv, mmu);
- drm_mm_for_each_node(node, >mm) {
- if (offset >= node->start && offset < (node->start +
node->size))
- goto out;
+ spin_lock(>mm_lock);
+
+ drm_mm_for_each_node(node, >mm) {
+ if (offset >= node->start &&
+ offset < (node->start + node->size)) {
+ bo = drm_mm_node_to_panfrost_bo(node);
+ drm_gem_object_get(>base.base);
+ break;
}
}
+ spin_unlock(>mm_lock);
out:
spin_unlock(>as_lock);
- return node;
+ return bo;
}
#define NUM_FAULT_PAGES (SZ_2M / PAGE_SIZE)
@@ -421,29 +433,28 @@ static struct drm_mm_node *addr_to_drm_mm_node(struct
panfrost_device *pfdev, in
int panfrost_mmu_map_fault_addr(struct panfrost_device *pfdev, int as, u64
addr)
{
int ret, i;
- struct drm_mm_node *node;
struct panfrost_gem_object *bo;
struct address_space *mapping;
pgoff_t page_offset;
struct sg_table *sgt;
struct page **pages;
- node = addr_to_drm_mm_node(pfdev, as, addr);
- if (!node)
+ bo = addr_to_drm_mm_node(pfdev, as, addr);
+ if (!bo)
return -ENOENT;
- bo = drm_mm_node_to_panfrost_bo(node);
if (!bo->is_heap) {
dev_WARN(pfdev->dev, "matching BO is not heap type (GPU VA =
%llx)",
-node->start << PAGE_SHIFT);
- return -EINVAL;
+bo->node.start << PAGE_SHIFT);
+ ret = -EINVAL;
+ goto err_bo;
}
WARN_ON(bo->mmu->as != as);
/* Assume 2MB alignment and size multiple */
addr &= ~((u64)SZ_2M - 1);
page_offset = addr >> PAGE_SHIFT;
- page_offset -= node->start;
+ page_offset -= bo->node.start;
mutex_lock(>base.pages_lock);
@@ -452,7 +463,8 @@ int panfrost_mmu_map_fault_addr(struct panfrost_device
*pfdev, int as, u64 addr)
sizeof(struct sg_table), GFP_KERNEL |
__GFP_ZERO);
if (!bo->sgts) {
mutex_unlock(>base.pages_lock);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err_bo;
}
pages = kvmalloc_array(bo->base.base.size >> PAGE_SHIFT,
@@ -461,7 +473,8 @@ int panfrost_mmu_map_fault_addr(struct panfrost_device
*pfdev, int as, u64 addr)
kfree(bo->sgts);
bo->sgts = NULL;
mutex_unlock(>base.pages_lock);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err_bo;
}
bo->base.pages = pages;
bo->base.pages_use_count = 1;
@@ -499,12 +512,16 @@ int panfrost_mmu_map_fault_addr(struct panfrost_device
Re: [PATCH 1/2] dt-bindings: display: Add xylon logicvc bindings documentation
Hi Rob and thanks for the review! On Fri 13 Sep 19, 15:35, Rob Herring wrote: > On Tue, Sep 10, 2019 at 05:34:08PM +0200, Paul Kocialkowski wrote: > > The Xylon LogiCVC is a display controller implemented as programmable > > logic in Xilinx FPGAs. > > > > Signed-off-by: Paul Kocialkowski > > --- > > .../bindings/display/xylon,logicvc.txt| 188 ++ > > 1 file changed, 188 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/xylon,logicvc.txt > > Consider converting this to DT schema format. See > Documentation/devicetree/writing-schema.rst (.md in 5.3). Oh right, that would certainly be much more future-proof! > > diff --git a/Documentation/devicetree/bindings/display/xylon,logicvc.txt > > b/Documentation/devicetree/bindings/display/xylon,logicvc.txt > > new file mode 100644 > > index ..eb4b1553888a > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/xylon,logicvc.txt > > @@ -0,0 +1,188 @@ > > +Xylon LogiCVC display controller > > + > > +The Xylon LogiCVC is a display controller that supports multiple layers. > > +It is usually implemented as programmable logic and was optimized for use > > +with Xilinx Zynq-7000 SoCs and Xilinx FPGAs. > > + > > +Because the controller is intended for use in a FPGA, most of the > > configuration > > +of the controller takes place at logic configuration bitstream synthesis > > time. > > +As a result, many of the device-tree bindings are meant to reflect the > > +synthesis configuration. These do not allow configuring the controller > > +differently than synthesis configuration. > > + > > +Layers are declared in the "layers" sub-node and have dedicated > > configuration. > > +In version 3 of the controller, each layer has fixed memory offset and > > address > > +starting from the video memory base address for its framebuffer. With > > version 4, > > +framebuffers are configured with a direct memory address instead. > > + > > +Matching synthesis parameters are provided when applicable. > > + > > +Required properties: > > +- compatible: Should be one of: > > + "xylon,logicvc-3.02.a-display" > > + "xylon,logicvc-4.01.a-display" > > +- reg: Physical base address and size for the controller registers. > > +- clocks: List of phandle and clock-specifier pairs, one for each entry > > + in 'clock-names' > > +- clock-names: List of clock names that should at least contain: > > + - "vclk": The VCLK video clock input. > > +- interrupts: The interrupt to use for VBLANK signaling. > > +- xylon,display-interface: Display interface in use, should be one of: > > + - "lvds-4bits": 4-bit LVDS interface (C_DISPLAY_INTERFACE == 4). > > +- xylon,display-colorspace: Display output colorspace in use, should be > > one of: > > + - "rgb": RGB colorspace (C_DISPLAY_COLOR_SPACE == 0). > > +- xylon,display-depth: Display output depth in use (C_PIXEL_DATA_WIDTH). > > +- xylon,row-stride: Fixed number of pixels in a framebuffer row > > (C_ROW_STRIDE). > > +- xylon,layers-count: The number of available layers (C_NUM_OF_LAYERS). > > Presumably some of this is determined by the display attached. Isn't it > safe to assume the IP was configured correctly for the intended display > and you can just get this from the panel? Layers are what corresponds to DRM planes, which are not actually indicated by the panel but are a charasteristic of the display controller. In our case, this is directly selected at bitstream synthesis time for the controller. So I'm afraid there is no way we can auto-detect this from the driver. > > > +Optional properties: > > +- memory-region: phandle to a node describing memory, as specified in: > > + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > +- clock-names: List of clock names that can optionally contain: > > + - "vclk2": The VCLK2 doubled-rate video clock input. > > + - "lvdsclk": The LVDS clock. > > + - "lvdsclkn": The LVDS clock inverted. > > How are these really optional? Well, the controller currently only supports LVDS, but more interfaces may be added later, so the lvdsclk clock will be optional when another interface is used instead. Maybe I'm mistaken about how to categorize them though. My understanding is that the need for vclk2 and lvdsclkn depend on the target FPGA family. I've developped the driver without the need for them, but the datasheet states that they may be needed (but doesn't provide significant details about their role though). > > +- xylon,syscon: Syscon phandle representing the logicvc instance. > > +- xylon,dithering: Dithering module is enabled (C_XCOLOR). > > +- xylon,background-layer: The last layer is used to display a black > > background > > + (C_USE_BACKGROUND). It must still be registered. > > +- xylon,layers-configurable: Configuration of layers' size, position and > > offset > > + is enabled (C_USE_SIZE_POSITION). > > I would think this will effectively have to be enabled to make this > usable
[Bug 111669] Navi GPU hang in Minecraft
https://bugs.freedesktop.org/show_bug.cgi?id=111669 --- Comment #4 from Pierre-Eric Pelloux-Prayer --- Thanks for the test and new trace. I can reproduce the hang and it seems to go away with AMD_DEBUG=nodma. Another workaround is to use the following kernel parameter amdgpu.vm_update_mode=3 (well, except that sometimes this introduces another problem, see https://bugs.freedesktop.org/show_bug.cgi?id=111682) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 11:09:22AM -0400, Ilia Mirkin wrote: On Fri, Sep 13, 2019 at 11:01 AM Sasha Levin wrote: On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote: >On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote: >> On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: >> > Hi Greg, >> > >> > This feels like it's missing a From: line. >> > >> > commit b513a18cf1d705bd04efd91c417e79e4938be093 >> > Author: Lyude Paul >> > Date: Mon Jan 28 16:03:50 2019 -0500 >> > >> >drm/nouveau: Don't WARN_ON VCPI allocation failures >> > >> > Is this an artifact of your notification-of-patches process and I >> > never noticed before, or was the patch ingested incorrectly? >> >> It was always like this for patches that came through me. Greg's script >> generates an explicit "From:" line in the patch, but I never saw the >> value in that since git does the right thing by looking at the "From:" >> line in the mail header. >> >> The right thing is being done in stable-rc and for the releases. For >> your example here, this is how it looks like in the stable-rc tree: >> >> commit bdcc885be68289a37d0d063cd94390da81fd8178 >> Author: Lyude Paul >> AuthorDate: Mon Jan 28 16:03:50 2019 -0500 >> Commit: Greg Kroah-Hartman >> CommitDate: Fri Sep 13 14:05:29 2019 +0100 >> >>drm/nouveau: Don't WARN_ON VCPI allocation failures > >Yeah, we should fix your scripts to put the explicit From: line in here >as we are dealing with patches in this format and it causes confusion at >times (like now.) It's not the first time and that's why I added those >lines to the patches. Heh, didn't think anyone cared about this scenario for the stable-rc patches. I'll go add it. But... why do you actually care? Just a hygiene thing. Everyone else sends patches the normal way, with accurate attribution. Why should stable be different? It shouldn't. It's just a mismatch between our two somewhat seperate workflow. Technically it's Greg who needs to be adding that line since the patches I have in stable-queue correctly state the author, and it only goes wrong when they're being formatted into mails sent for the -rc cycles. But yes, thanks for pointing it out, I'll go add it in the scripts. -- Thanks, Sasha ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 04:10:51PM +0100, Greg Kroah-Hartman wrote: On Fri, Sep 13, 2019 at 11:01:11AM -0400, Sasha Levin wrote: On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote: > On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote: > > On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > > > Hi Greg, > > > > > > This feels like it's missing a From: line. > > > > > > commit b513a18cf1d705bd04efd91c417e79e4938be093 > > > Author: Lyude Paul > > > Date: Mon Jan 28 16:03:50 2019 -0500 > > > > > >drm/nouveau: Don't WARN_ON VCPI allocation failures > > > > > > Is this an artifact of your notification-of-patches process and I > > > never noticed before, or was the patch ingested incorrectly? > > > > It was always like this for patches that came through me. Greg's script > > generates an explicit "From:" line in the patch, but I never saw the > > value in that since git does the right thing by looking at the "From:" > > line in the mail header. > > > > The right thing is being done in stable-rc and for the releases. For > > your example here, this is how it looks like in the stable-rc tree: > > > > commit bdcc885be68289a37d0d063cd94390da81fd8178 > > Author: Lyude Paul > > AuthorDate: Mon Jan 28 16:03:50 2019 -0500 > > Commit: Greg Kroah-Hartman > > CommitDate: Fri Sep 13 14:05:29 2019 +0100 > > > >drm/nouveau: Don't WARN_ON VCPI allocation failures > > Yeah, we should fix your scripts to put the explicit From: line in here > as we are dealing with patches in this format and it causes confusion at > times (like now.) It's not the first time and that's why I added those > lines to the patches. Heh, didn't think anyone cared about this scenario for the stable-rc patches. I'll go add it. But... why do you actually care? On the emails we send out, it has inproper author information which can cause confusion that the sender of the email (i.e. me) is somehow saying that they are the author of the patch. Right right, I agree this is wrong and I'll fix it. I'm just concerned about what exactly you are doing with the -rc patches to actually care about this :) -- Thanks, Sasha ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/7] drm/ttm: TTM fault handler helpers
On Fri, Sep 13, 2019 at 11:32:09AM +0200, Thomas Hellström (VMware) wrote:
> +vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
> + pgprot_t prot,
> + pgoff_t num_prefault)
> +{
> + struct vm_area_struct *vma = vmf->vma;
> + struct vm_area_struct cvma = *vma;
> + struct ttm_buffer_object *bo = (struct ttm_buffer_object *)
> + vma->vm_private_data;
It's a void *. There's no need to cast it.
struct ttm_buffer_object *bo = vma->vm_private_data;
conveys exactly the same information to both the reader and the compiler,
except it's all on one line instead of split over two.
Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 11:01:11AM -0400, Sasha Levin wrote: > On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote: > > On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote: > > > On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > > > > Hi Greg, > > > > > > > > This feels like it's missing a From: line. > > > > > > > > commit b513a18cf1d705bd04efd91c417e79e4938be093 > > > > Author: Lyude Paul > > > > Date: Mon Jan 28 16:03:50 2019 -0500 > > > > > > > >drm/nouveau: Don't WARN_ON VCPI allocation failures > > > > > > > > Is this an artifact of your notification-of-patches process and I > > > > never noticed before, or was the patch ingested incorrectly? > > > > > > It was always like this for patches that came through me. Greg's script > > > generates an explicit "From:" line in the patch, but I never saw the > > > value in that since git does the right thing by looking at the "From:" > > > line in the mail header. > > > > > > The right thing is being done in stable-rc and for the releases. For > > > your example here, this is how it looks like in the stable-rc tree: > > > > > > commit bdcc885be68289a37d0d063cd94390da81fd8178 > > > Author: Lyude Paul > > > AuthorDate: Mon Jan 28 16:03:50 2019 -0500 > > > Commit: Greg Kroah-Hartman > > > CommitDate: Fri Sep 13 14:05:29 2019 +0100 > > > > > >drm/nouveau: Don't WARN_ON VCPI allocation failures > > > > Yeah, we should fix your scripts to put the explicit From: line in here > > as we are dealing with patches in this format and it causes confusion at > > times (like now.) It's not the first time and that's why I added those > > lines to the patches. > > Heh, didn't think anyone cared about this scenario for the stable-rc > patches. > > I'll go add it. > > But... why do you actually care? On the emails we send out, it has inproper author information which can cause confusion that the sender of the email (i.e. me) is somehow saying that they are the author of the patch. thanks, greg k-h
Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 11:01 AM Sasha Levin wrote: > > On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote: > >On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote: > >> On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > >> > Hi Greg, > >> > > >> > This feels like it's missing a From: line. > >> > > >> > commit b513a18cf1d705bd04efd91c417e79e4938be093 > >> > Author: Lyude Paul > >> > Date: Mon Jan 28 16:03:50 2019 -0500 > >> > > >> >drm/nouveau: Don't WARN_ON VCPI allocation failures > >> > > >> > Is this an artifact of your notification-of-patches process and I > >> > never noticed before, or was the patch ingested incorrectly? > >> > >> It was always like this for patches that came through me. Greg's script > >> generates an explicit "From:" line in the patch, but I never saw the > >> value in that since git does the right thing by looking at the "From:" > >> line in the mail header. > >> > >> The right thing is being done in stable-rc and for the releases. For > >> your example here, this is how it looks like in the stable-rc tree: > >> > >> commit bdcc885be68289a37d0d063cd94390da81fd8178 > >> Author: Lyude Paul > >> AuthorDate: Mon Jan 28 16:03:50 2019 -0500 > >> Commit: Greg Kroah-Hartman > >> CommitDate: Fri Sep 13 14:05:29 2019 +0100 > >> > >>drm/nouveau: Don't WARN_ON VCPI allocation failures > > > >Yeah, we should fix your scripts to put the explicit From: line in here > >as we are dealing with patches in this format and it causes confusion at > >times (like now.) It's not the first time and that's why I added those > >lines to the patches. > > Heh, didn't think anyone cared about this scenario for the stable-rc > patches. > > I'll go add it. > > But... why do you actually care? Just a hygiene thing. Everyone else sends patches the normal way, with accurate attribution. Why should stable be different? (I was surprised to see Greg contributing to nouveau when I first saw the patch. But then realized it was the stable ingestion notification.) -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote: On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote: On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > Hi Greg, > > This feels like it's missing a From: line. > > commit b513a18cf1d705bd04efd91c417e79e4938be093 > Author: Lyude Paul > Date: Mon Jan 28 16:03:50 2019 -0500 > >drm/nouveau: Don't WARN_ON VCPI allocation failures > > Is this an artifact of your notification-of-patches process and I > never noticed before, or was the patch ingested incorrectly? It was always like this for patches that came through me. Greg's script generates an explicit "From:" line in the patch, but I never saw the value in that since git does the right thing by looking at the "From:" line in the mail header. The right thing is being done in stable-rc and for the releases. For your example here, this is how it looks like in the stable-rc tree: commit bdcc885be68289a37d0d063cd94390da81fd8178 Author: Lyude Paul AuthorDate: Mon Jan 28 16:03:50 2019 -0500 Commit: Greg Kroah-Hartman CommitDate: Fri Sep 13 14:05:29 2019 +0100 drm/nouveau: Don't WARN_ON VCPI allocation failures Yeah, we should fix your scripts to put the explicit From: line in here as we are dealing with patches in this format and it causes confusion at times (like now.) It's not the first time and that's why I added those lines to the patches. Heh, didn't think anyone cared about this scenario for the stable-rc patches. I'll go add it. But... why do you actually care? -- Thanks, Sasha ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote: > On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > > Hi Greg, > > > > This feels like it's missing a From: line. > > > > commit b513a18cf1d705bd04efd91c417e79e4938be093 > > Author: Lyude Paul > > Date: Mon Jan 28 16:03:50 2019 -0500 > > > >drm/nouveau: Don't WARN_ON VCPI allocation failures > > > > Is this an artifact of your notification-of-patches process and I > > never noticed before, or was the patch ingested incorrectly? > > It was always like this for patches that came through me. Greg's script > generates an explicit "From:" line in the patch, but I never saw the > value in that since git does the right thing by looking at the "From:" > line in the mail header. > > The right thing is being done in stable-rc and for the releases. For > your example here, this is how it looks like in the stable-rc tree: > > commit bdcc885be68289a37d0d063cd94390da81fd8178 > Author: Lyude Paul > AuthorDate: Mon Jan 28 16:03:50 2019 -0500 > Commit: Greg Kroah-Hartman > CommitDate: Fri Sep 13 14:05:29 2019 +0100 > >drm/nouveau: Don't WARN_ON VCPI allocation failures Yeah, we should fix your scripts to put the explicit From: line in here as we are dealing with patches in this format and it causes confusion at times (like now.) It's not the first time and that's why I added those lines to the patches. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
blocking ops in drm_sched_cleanup_jobs()
Hi,
I hit the below splat randomly with panfrost. From what I can tell this
is a more general issue which would affect other drivers.
8<-
[58604.913130] [ cut here ]
[58604.918590] WARNING: CPU: 1 PID: 1758 at kernel/sched/core.c:6556
__might_sleep+0x74/0x98
[58604.927965] do not call blocking ops when !TASK_RUNNING; state=1 set at
[<0c590494>] prepare_to_wait_event+0x104/0x164
[58604.940047] Modules linked in: panfrost gpu_sched
[58604.945370] CPU: 1 PID: 1758 Comm: pan_js Not tainted 5.3.0-rc1+ #13
[58604.952500] Hardware name: Rockchip (Device Tree)
[58604.957815] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[58604.966521] [] (show_stack) from []
(dump_stack+0x9c/0xd4)
[58604.974639] [] (dump_stack) from [] (__warn+0xe8/0x104)
[58604.982462] [] (__warn) from []
(warn_slowpath_fmt+0x44/0x6c)
[58604.990867] [] (warn_slowpath_fmt) from []
(__might_sleep+0x74/0x98)
[58604.73] [] (__might_sleep) from []
(__mutex_lock+0x38/0x948)
[58605.008690] [] (__mutex_lock) from []
(mutex_lock_nested+0x18/0x20)
[58605.017841] [] (mutex_lock_nested) from []
(panfrost_gem_free_object+0x60/0x10c [panfrost])
[58605.029430] [] (panfrost_gem_free_object [panfrost]) from
[] (panfrost_job_put+0x138/0x150 [panfrost])
[58605.042076] [] (panfrost_job_put [panfrost]) from []
(drm_sched_cleanup_jobs+0xc8/0xe0 [gpu_sched])
[58605.054417] [] (drm_sched_cleanup_jobs [gpu_sched]) from
[] (drm_sched_main+0xcc/0x26c [gpu_sched])
[58605.066620] [] (drm_sched_main [gpu_sched]) from []
(kthread+0x13c/0x154)
[58605.076226] [] (kthread) from []
(ret_from_fork+0x14/0x20)
[58605.084346] Exception stack(0xe959bfb0 to 0xe959bff8)
[58605.090046] bfa0:
[58605.099250] bfc0:
[58605.108480] bfe0: 0013
[58605.116210] irq event stamp: 179
[58605.119955] hardirqs last enabled at (187): []
console_unlock+0x564/0x5c4
[58605.128935] hardirqs last disabled at (202): []
console_unlock+0x88/0x5c4
[58605.137788] softirqs last enabled at (216): []
__do_softirq+0x18c/0x548
[58605.146543] softirqs last disabled at (227): [] irq_exit+0xc4/0x10c
[58605.154618] ---[ end trace f65bdbd9ea9adfc0 ]---
8<-
The problem is that drm_sched_main() calls drm_sched_cleanup_jobs() as
part of the condition of wait_event_interruptible:
> wait_event_interruptible(sched->wake_up_worker,
>(drm_sched_cleanup_jobs(sched),
>(!drm_sched_blocked(sched) &&
> (entity =
> drm_sched_select_entity(sched))) ||
>kthread_should_stop()));
When drm_sched_cleanup_jobs() is called *after* a wait (i.e. after
prepare_to_wait_event() has been called), then any might_sleep() will
moan loudly about it. This doesn't seem to happen often (I've only
triggered it once) because usually drm_sched_cleanup_jobs() either
doesn't sleep or does the sleeping during the first call that
wait_event_interruptible() makes (which is before the task state is set).
I don't really understand why drm_sched_cleanup_jobs() needs to be
called here, a simple change like below 'fixes' it. But I presume
there's some reason for the call being part of the
wait_event_interruptible condition. Can anyone shed light on this?
The code was introduced in commit 5918045c4ed4 ("drm/scheduler: rework job
destruction")
Steve
8<-
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 9a0ee74d82dc..528f295e3a31 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -699,11 +699,12 @@ static int drm_sched_main(void *param)
struct drm_sched_job *sched_job;
struct dma_fence *fence;
+ drm_sched_cleanup_jobs(sched);
+
wait_event_interruptible(sched->wake_up_worker,
-(drm_sched_cleanup_jobs(sched),
(!drm_sched_blocked(sched) &&
(entity =
drm_sched_select_entity(sched))) ||
-kthread_should_stop()));
+kthread_should_stop());
if (!entity)
continue;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 10:46 AM Sasha Levin wrote: > > On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > >Hi Greg, > > > >This feels like it's missing a From: line. > > > >commit b513a18cf1d705bd04efd91c417e79e4938be093 > >Author: Lyude Paul > >Date: Mon Jan 28 16:03:50 2019 -0500 > > > >drm/nouveau: Don't WARN_ON VCPI allocation failures > > > >Is this an artifact of your notification-of-patches process and I > >never noticed before, or was the patch ingested incorrectly? > > It was always like this for patches that came through me. Greg's script > generates an explicit "From:" line in the patch, but I never saw the > value in that since git does the right thing by looking at the "From:" > line in the mail header. That's right -- the email's From header gets used in the case of no explicit From in the email body. But Greg is sending the emails From: Greg, so if I were to ingest that email, I would end up with a patch From: Greg, not From: Lyude as it ought to be. Cheers, -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: Hi Greg, This feels like it's missing a From: line. commit b513a18cf1d705bd04efd91c417e79e4938be093 Author: Lyude Paul Date: Mon Jan 28 16:03:50 2019 -0500 drm/nouveau: Don't WARN_ON VCPI allocation failures Is this an artifact of your notification-of-patches process and I never noticed before, or was the patch ingested incorrectly? It was always like this for patches that came through me. Greg's script generates an explicit "From:" line in the patch, but I never saw the value in that since git does the right thing by looking at the "From:" line in the mail header. The right thing is being done in stable-rc and for the releases. For your example here, this is how it looks like in the stable-rc tree: commit bdcc885be68289a37d0d063cd94390da81fd8178 Author: Lyude Paul AuthorDate: Mon Jan 28 16:03:50 2019 -0500 Commit: Greg Kroah-Hartman CommitDate: Fri Sep 13 14:05:29 2019 +0100 drm/nouveau: Don't WARN_ON VCPI allocation failures -- Thanks, Sasha ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/7] drm/ttm: TTM fault handler helpers
On 9/13/19 3:40 PM, Hillf Danton wrote:
On Fri, 13 Sep 2019 11:32:09 +0200
err = ttm_mem_io_lock(man, true);
- if (unlikely(err != 0)) {
- ret = VM_FAULT_NOPAGE;
- goto out_unlock;
- }
+ if (unlikely(err != 0))
+ return VM_FAULT_NOPAGE;
err = ttm_mem_io_reserve_vm(bo);
- if (unlikely(err != 0)) {
- ret = VM_FAULT_SIGBUS;
- goto out_io_unlock;
- }
+ if (unlikely(err != 0))
+ return VM_FAULT_SIGBUS;
Hehe, no hurry.
Could you be a bit more specific?
Thanks,
Thomas
@@ -295,8 +307,28 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
ret = VM_FAULT_NOPAGE;
out_io_unlock:
ttm_mem_io_unlock(man);
-out_unlock:
+ return ret;
+}
+EXPORT_SYMBOL(ttm_bo_vm_fault_reserved);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] drm/etnaviv: use drm_debug_enabled() to check for debug categories
On Fr, 2019-09-13 at 14:51 +0300, Jani Nikula wrote:
> Allow better abstraction of the drm_debug global variable in the
> future. No functional changes.
>
> Cc: Lucas Stach
> Cc: Russell King
> Cc: Christian Gmeiner
> Cc: etna...@lists.freedesktop.org
> Signed-off-by: Jani Nikula
Acked-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> index 7e4e2959bf4f..32d9fac587f9 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> @@ -326,7 +326,7 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
> exec_state,
>
> lockdep_assert_held(>lock);
>
> - if (drm_debug & DRM_UT_DRIVER)
> + if (drm_debug_enabled(DRM_UT_DRIVER))
> etnaviv_buffer_dump(gpu, buffer, 0, 0x50);
>
> link_target = etnaviv_cmdbuf_get_va(cmdbuf,
> @@ -459,13 +459,13 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
> exec_state,
>etnaviv_cmdbuf_get_va(buffer,
> >mmu_context->cmdbuf_mapping)
>+ buffer->user_size - 4);
>
> - if (drm_debug & DRM_UT_DRIVER)
> + if (drm_debug_enabled(DRM_UT_DRIVER))
> pr_info("stream link to 0x%08x @ 0x%08x %p\n",
> return_target,
> etnaviv_cmdbuf_get_va(cmdbuf,
> >mmu_context->cmdbuf_mapping),
> cmdbuf->vaddr);
>
> - if (drm_debug & DRM_UT_DRIVER) {
> + if (drm_debug_enabled(DRM_UT_DRIVER)) {
> print_hex_dump(KERN_INFO, "cmd ", DUMP_PREFIX_OFFSET, 16, 4,
> cmdbuf->vaddr, cmdbuf->size, 0);
>
> @@ -484,6 +484,6 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
> exec_state,
> VIV_FE_LINK_HEADER_PREFETCH(link_dwords),
> link_target);
>
> - if (drm_debug & DRM_UT_DRIVER)
> + if (drm_debug_enabled(DRM_UT_DRIVER))
> etnaviv_buffer_dump(gpu, buffer, 0, 0x50);
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] dt-bindings: backlight: lm3630a: add enable_gpios
Andreas
On 9/12/19 4:32 PM, Andreas Kemnade wrote:
add enable-gpios to describe HWEN pin
Signed-off-by: Andreas Kemnade
Acked-by: Daniel Thompson
Reviewed-by: Dan Murphy
---
changes in v2: added example
changes in v3: added Acked-by
changes in v4: moved enable-gpios to the right position
in the example
.../bindings/leds/backlight/lm3630a-backlight.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git
a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
index dc129d9a329e..c8470628fe02 100644
--- a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
@@ -29,6 +29,10 @@ properties:
'#size-cells':
const: 0
+ enable-gpios:
+description: GPIO to use to enable/disable the backlight (HWEN pin).
+maxItems: 1
+
required:
- compatible
- reg
@@ -96,6 +100,7 @@ examples:
led-controller@38 {
compatible = "ti,lm3630a";
reg = <0x38>;
+enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
Re: [PATCH 2/8] drm/shmem: switch shmem helper to _gem_object_funcs.mmap
On 13/09/2019 13:29, Gerd Hoffmann wrote:
> Switch gem shmem helper to the new mmap() workflow,
> from _driver.fops.mmap to _gem_object_funcs.mmap.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/drm/drm_gem_shmem_helper.h | 6 ++
> drivers/gpu/drm/drm_gem_shmem_helper.c | 26 -
> drivers/gpu/drm/panfrost/panfrost_gem.c | 2 +-
> drivers/gpu/drm/v3d/v3d_bo.c| 2 +-
> drivers/gpu/drm/virtio/virtgpu_object.c | 2 +-
> 5 files changed, 13 insertions(+), 25 deletions(-)
>
> diff --git a/include/drm/drm_gem_shmem_helper.h
> b/include/drm/drm_gem_shmem_helper.h
> index 01f514521687..d89f2116c8ab 100644
> --- a/include/drm/drm_gem_shmem_helper.h
> +++ b/include/drm/drm_gem_shmem_helper.h
> @@ -111,7 +111,7 @@ struct drm_gem_shmem_object {
> .poll = drm_poll,\
> .read = drm_read,\
> .llseek = noop_llseek,\
> - .mmap = drm_gem_shmem_mmap, \
> + .mmap = drm_gem_mmap, \
> }
>
> struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev,
> size_t size);
> @@ -143,9 +143,7 @@ drm_gem_shmem_create_with_handle(struct drm_file
> *file_priv,
> int drm_gem_shmem_dumb_create(struct drm_file *file, struct drm_device *dev,
> struct drm_mode_create_dumb *args);
>
> -int drm_gem_shmem_mmap(struct file *filp, struct vm_area_struct *vma);
> -
> -extern const struct vm_operations_struct drm_gem_shmem_vm_ops;
> +int drm_gem_shmem_mmap(struct drm_gem_object *obj, struct vm_area_struct
> *vma);
>
> void drm_gem_shmem_print_info(struct drm_printer *p, unsigned int indent,
> const struct drm_gem_object *obj);
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index f5918707672f..a104140154bb 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -32,7 +32,7 @@ static const struct drm_gem_object_funcs
> drm_gem_shmem_funcs = {
> .get_sg_table = drm_gem_shmem_get_sg_table,
> .vmap = drm_gem_shmem_vmap,
> .vunmap = drm_gem_shmem_vunmap,
> - .vm_ops = _gem_shmem_vm_ops,
> + .mmap = drm_gem_shmem_mmap,
> };
>
> /**
> @@ -505,39 +505,30 @@ static void drm_gem_shmem_vm_close(struct
> vm_area_struct *vma)
> drm_gem_vm_close(vma);
> }
>
> -const struct vm_operations_struct drm_gem_shmem_vm_ops = {
> +static const struct vm_operations_struct drm_gem_shmem_vm_ops = {
> .fault = drm_gem_shmem_fault,
> .open = drm_gem_shmem_vm_open,
> .close = drm_gem_shmem_vm_close,
> };
> -EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_ops);
>
> /**
> * drm_gem_shmem_mmap - Memory-map a shmem GEM object
> - * @filp: File object
> + * @obj: gem object
> * @vma: VMA for the area to be mapped
> *
> * This function implements an augmented version of the GEM DRM file mmap
> * operation for shmem objects. Drivers which employ the shmem helpers should
> - * use this function as their _operations.mmap handler in the DRM
> device file's
> - * file_operations structure.
> - *
> - * Instead of directly referencing this function, drivers should use the
> - * DEFINE_DRM_GEM_SHMEM_FOPS() macro.
> + * use this function as their _gem_object_funcs.mmap handler.
> *
> * Returns:
> * 0 on success or a negative error code on failure.
> */
> -int drm_gem_shmem_mmap(struct file *filp, struct vm_area_struct *vma)
> +int drm_gem_shmem_mmap(struct drm_gem_object *obj, struct vm_area_struct
> *vma)
> {
> struct drm_gem_shmem_object *shmem;
> int ret;
>
> - ret = drm_gem_mmap(filp, vma);
> - if (ret)
> - return ret;
> -
> - shmem = to_drm_gem_shmem_obj(vma->vm_private_data);
> + shmem = to_drm_gem_shmem_obj(obj);
>
> ret = drm_gem_shmem_get_pages(shmem);
> if (ret) {
> @@ -545,9 +536,8 @@ int drm_gem_shmem_mmap(struct file *filp, struct
> vm_area_struct *vma)
> return ret;
> }
>
> - /* VM_PFNMAP was set by drm_gem_mmap() */
> - vma->vm_flags &= ~VM_PFNMAP;
> - vma->vm_flags |= VM_MIXEDMAP;
> + vma->vm_flags |= (VM_MIXEDMAP|VM_DONTEXPAND);
I'm finding this a bit hard to follow - but I think here we've lost
VM_IO and VM_DONTDUMP which used to be set by drm_gem_mmap().
Also it looks like nothing is fiddling vma->vm_page_prot anymore.
Steve
> + vma->vm_ops = _gem_shmem_vm_ops;
>
> /* Remove the fake offset */
> vma->vm_pgoff -= drm_vma_node_start(>base.vma_node);
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
> b/drivers/gpu/drm/panfrost/panfrost_gem.c
> index acb07fe06580..deca0c30bbd4 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
> @@ -112,7 +112,7 @@ static const struct drm_gem_object_funcs
> panfrost_gem_funcs = {
> .get_sg_table = drm_gem_shmem_get_sg_table,
> .vmap =
Running SPICE on ppc64le
Hi, Is there any reason why Spice is not available on ppc64le? I've read there are still some issues with big endian, but what's wrong with little endian? I would really love to be able to use QXL and especially USB redirection on my Raptor Blackbird (Power 9). Bests, Niccolo' ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111669] Navi GPU hang in Minecraft
https://bugs.freedesktop.org/show_bug.cgi?id=111669 --- Comment #3 from Doug Ty --- Thanks for the response. Still hanging, unfortunately. While the patch allows me to replay the first apitrace just fine now, I'm still hanging in the same spot ingame. Same messages in journalctl I've captured a new apitrace that recreates the hang with the patch for me. https://drive.google.com/open?id=1WMeuCoZnOOqD0Tbjix6nNpFyVkzzbd94 As suggested in the other thread, AMD_DEBUG=nodma seems to successfully prevent the hang. Unsure if you can see it in the apitrace, but there are usually some artifacts shortly before the hang: stretchy verts, sheep textures turning blue -- these are also not present with nodma It's worth noting that I am getting some general desktop instability and sdma hangs like in the other thread you linked as well. While compiling the kernel patch I got a hang trying to watch a video in Firefox (has happened a couple times before), and previously I've also gotten hangs while loading Half Life 2 maps and closing GIMP. Not sure if any of these could be related. They happen so irregularly that I've been unable to reproduce or capture apitraces for them. Occasionally images on web pages will load corrupted and not display as well, though I can't tell if this is a GPU problem or a browser/network problem. The card works great on my Windows dual boot, so I'm pretty sure it's not a hardware problem. (though I have to use 19.7.5 as anything newer causes Firefox to blue screen me) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/panfrost: Extend the bo_wait() ioctl
On 13/09/2019 12:17, Boris Brezillon wrote:
> So we can choose to wait for all BO users, or just for writers.
>
> Signed-off-by: Boris Brezillon
Looks good to me:
Reviewed-by: Steven Price
Although I don't know if the term "writers" should be in the API or if
"exclusive" is the preferred term?
Steve
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 8 ++--
> include/uapi/drm/panfrost_drm.h | 4
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index 08082fd557c3..6a94aea2147f 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -322,16 +322,20 @@ panfrost_ioctl_wait_bo(struct drm_device *dev, void
> *data,
> struct drm_panfrost_wait_bo *args = data;
> struct drm_gem_object *gem_obj;
> unsigned long timeout = drm_timeout_abs_to_jiffies(args->timeout_ns);
> + bool wait_all = !(args->flags & PANFROST_WAIT_BO_WRITERS);
>
> if (args->pad)
> return -EINVAL;
>
> + if (args->flags & ~PANFROST_WAIT_BO_WRITERS)
> + return -EINVAL;
> +
> gem_obj = drm_gem_object_lookup(file_priv, args->handle);
> if (!gem_obj)
> return -ENOENT;
>
> - ret = dma_resv_wait_timeout_rcu(gem_obj->resv, true,
> - true, timeout);
> + ret = dma_resv_wait_timeout_rcu(gem_obj->resv, wait_all,
> + true, timeout);
> if (!ret)
> ret = timeout ? -ETIMEDOUT : -EBUSY;
>
> diff --git a/include/uapi/drm/panfrost_drm.h b/include/uapi/drm/panfrost_drm.h
> index 029c6ae1b1f0..ac4facbcee47 100644
> --- a/include/uapi/drm/panfrost_drm.h
> +++ b/include/uapi/drm/panfrost_drm.h
> @@ -111,6 +111,9 @@ struct drm_panfrost_submit {
> __u32 pad;
> };
>
> +#define PANFROST_WAIT_ALL_BO_USERS (0 << 0)
> +#define PANFROST_WAIT_BO_WRITERS (1 << 0)
> +
> /**
> * struct drm_panfrost_wait_bo - ioctl argument for waiting for
> * completion of the last DRM_PANFROST_SUBMIT on a BO.
> @@ -123,6 +126,7 @@ struct drm_panfrost_wait_bo {
> __u32 handle;
> __u32 pad;
> __s64 timeout_ns; /* absolute */
> + __u64 flags;
> };
>
> #define PANFROST_BO_NOEXEC 1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/panfrost: Allow passing extra information about BOs used by a job
On 13/09/2019 12:17, Boris Brezillon wrote:
> The READ/WRITE flags are particularly useful if we want to avoid
> serialization of jobs that read from the same BO but never write to it.
> The NO_IMPLICIT_FENCE might be useful when the user knows the BO is
> shared but jobs are using different portions of the buffer.
>
> Signed-off-by: Boris Brezillon
Good feature - we could do with an (easy) way of the user driver
detecting this - so it might be worth bumping the driver version for this?
Some more comments below.
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 72 +--
> drivers/gpu/drm/panfrost/panfrost_job.c | 164 +++-
> drivers/gpu/drm/panfrost/panfrost_job.h | 11 +-
> include/uapi/drm/panfrost_drm.h | 41 ++
> 4 files changed, 247 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index d74442d71048..08082fd557c3 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -119,20 +119,76 @@ panfrost_lookup_bos(struct drm_device *dev,
> struct drm_panfrost_submit *args,
> struct panfrost_job *job)
> {
> - job->bo_count = args->bo_handle_count;
> + struct drm_panfrost_submit_bo *bo_descs = NULL;
> + u32 *handles = NULL;
> + u32 i, bo_count;
> + int ret = 0;
>
> - if (!job->bo_count)
> + bo_count = args->bo_desc_count ?
> +args->bo_desc_count : args->bo_handle_count;
> + if (!bo_count)
> return 0;
>
> - job->implicit_fences = kvmalloc_array(job->bo_count,
> - sizeof(struct dma_fence *),
> + job->bos = kvmalloc_array(bo_count, sizeof(*job->bos),
> GFP_KERNEL | __GFP_ZERO);
> - if (!job->implicit_fences)
> + if (!job->bos)
> return -ENOMEM;
>
> - return drm_gem_objects_lookup(file_priv,
> - (void __user
> *)(uintptr_t)args->bo_handles,
> - job->bo_count, >bos);
> + job->bo_count = bo_count;
> + bo_descs = kvmalloc_array(bo_count, sizeof(*bo_descs),
> + GFP_KERNEL | __GFP_ZERO);
> + if (!bo_descs) {
> + ret = -ENOMEM;
> + goto out;
This can be just "return -ENOMEM" - both handles and bo_descs will be NULL.
> + }
> +
> + if (!args->bo_desc_count) {
> + handles = kvmalloc_array(bo_count, sizeof(*handles),
> + GFP_KERNEL);
> + if (!handles) {
> + ret =-ENOMEM;
> + goto out;
> + }
> +
> + if (copy_from_user(handles,
> +(void __user *)(uintptr_t)args->bo_handles,
> +job->bo_count * sizeof(*handles))) {
> + ret = -EFAULT;
> + goto out;
> + }
> +
> + for (i = 0; i < job->bo_count; i++) {
> + bo_descs[i].handle = handles[i];
> + bo_descs[i].flags = PANFROST_SUBMIT_BO_WRITE |
> + PANFROST_SUBMIT_BO_READ;
You can use PANFROST_SUBMIT_BO_RW here.
> + }
> + } else if (copy_from_user(bo_descs,
> + (void __user *)(uintptr_t)args->bo_descs,
> + job->bo_count * sizeof(*bo_descs))) {
> + ret = -EFAULT;
> + goto out;
> + }
> +
> + for (i = 0; i < job->bo_count; i++) {
> + if ((bo_descs[i].flags & ~PANFROST_SUBMIT_BO_VALID_FLAGS) ||
> +!(bo_descs[i].flags & PANFROST_SUBMIT_BO_RW)) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + job->bos[i].flags = bo_descs[i].flags;
> + job->bos[i].obj = drm_gem_object_lookup(file_priv,
> + bo_descs[i].handle);
> + if (!job->bos[i].obj) {
> + ret = -ENOENT;
> + goto out;
> + }
> + }
> +
> +out:
> + kvfree(handles);
> + kvfree(bo_descs);
> + return ret;
> }
>
> /**
> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
> b/drivers/gpu/drm/panfrost/panfrost_job.c
> index 05c85f45a0de..e4b74fde9339 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> @@ -193,24 +193,116 @@ static void panfrost_job_hw_submit(struct panfrost_job
> *job, int js)
> pm_runtime_put_autosuspend(pfdev->dev);
> }
>
> -static void panfrost_acquire_object_fences(struct drm_gem_object **bos,
> -int bo_count,
> -struct dma_fence **implicit_fences)
> +static int
Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
Hi Greg,
This feels like it's missing a From: line.
commit b513a18cf1d705bd04efd91c417e79e4938be093
Author: Lyude Paul
Date: Mon Jan 28 16:03:50 2019 -0500
drm/nouveau: Don't WARN_ON VCPI allocation failures
Is this an artifact of your notification-of-patches process and I
never noticed before, or was the patch ingested incorrectly?
Cheers,
-ilia
On Fri, Sep 13, 2019 at 9:16 AM Greg Kroah-Hartman
wrote:
>
> [ Upstream commit b513a18cf1d705bd04efd91c417e79e4938be093 ]
>
> This is much louder then we want. VCPI allocation failures are quite
> normal, since they will happen if any part of the modesetting process is
> interrupted by removing the DP MST topology in question. So just print a
> debugging message on VCPI failures instead.
>
> Signed-off-by: Lyude Paul
> Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2
> multi-stream")
> Cc: Ben Skeggs
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: # v4.10+
> Signed-off-by: Ben Skeggs
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index f889d41a281fa..5e01bfb69d7a3 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -759,7 +759,8 @@ nv50_msto_enable(struct drm_encoder *encoder)
>
> slots = drm_dp_find_vcpi_slots(>mgr, mstc->pbn);
> r = drm_dp_mst_allocate_vcpi(>mgr, mstc->port, mstc->pbn,
> slots);
> - WARN_ON(!r);
> + if (!r)
> + DRM_DEBUG_KMS("Failed to allocate VCPI\n");
>
> if (!mstm->links++)
> nv50_outp_acquire(mstm->outp);
> --
> 2.20.1
>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/8] drm/vram: drop DRM_VRAM_MM_FILE_OPERATIONS
Am 13.09.19 um 14:29 schrieb Gerd Hoffmann:
> Not needed any more because we don't have vram specific fops
> any more. DEFINE_DRM_GEM_FOPS() can be used instead.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/drm/drm_gem_vram_helper.h | 18
> include/drm/drm_vram_mm_helper.h | 82 +++
> drivers/gpu/drm/ast/ast_drv.c | 5 +-
> drivers/gpu/drm/bochs/bochs_drv.c | 5 +-
> .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +-
> drivers/gpu/drm/mgag200/mgag200_drv.c | 5 +-
> drivers/gpu/drm/vboxvideo/vbox_drv.c | 5 +-
> 7 files changed, 87 insertions(+), 38 deletions(-)
> create mode 100644 include/drm/drm_vram_mm_helper.h
>
> diff --git a/include/drm/drm_gem_vram_helper.h
> b/include/drm/drm_gem_vram_helper.h
> index 9d5526650291..3503ff784803 100644
> --- a/include/drm/drm_gem_vram_helper.h
> +++ b/include/drm/drm_gem_vram_helper.h
> @@ -180,22 +180,4 @@ struct drm_vram_mm *drm_vram_helper_alloc_mm(
> struct drm_device *dev, uint64_t vram_base, size_t vram_size);
> void drm_vram_helper_release_mm(struct drm_device *dev);
>
> -/**
> - * define DRM_VRAM_MM_FILE_OPERATIONS - default callback functions for \
> - file_operations
> - *
> - * Drivers that use VRAM MM can use this macro to initialize
> - * file_operations with default functions.
> - */
> -#define DRM_VRAM_MM_FILE_OPERATIONS \
> - .llseek = no_llseek, \
> - .read = drm_read, \
> - .poll = drm_poll, \
> - .unlocked_ioctl = drm_ioctl, \
> - .compat_ioctl = drm_compat_ioctl, \
> - .mmap = drm_gem_mmap, \
> - .open = drm_open, \
> - .release= drm_release \
> -
> -
> #endif
> diff --git a/include/drm/drm_vram_mm_helper.h
> b/include/drm/drm_vram_mm_helper.h
> new file mode 100644
Please rebase onto the latest drm-tip. This entire file has been removed
in a recent patch.
With this change applied:
Reviewed-by: Thomas Zimmermann
> index ..a47b49adba62
> --- /dev/null
> +++ b/include/drm/drm_vram_mm_helper.h
> @@ -0,0 +1,82 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +
> +#ifndef DRM_VRAM_MM_HELPER_H
> +#define DRM_VRAM_MM_HELPER_H
> +
> +#include
> +#include
> +#include
> +
> +struct drm_device;
> +
> +/**
> + * struct drm_vram_mm_funcs - Callback functions for drm_vram_mm
> + * @evict_flags: Provides an implementation for struct \
> + _bo_driver.evict_flags
> + * @move_notify: Provides an implementation for
> + * struct _bo_driver.move_notify
> + *
> + * These callback function integrate VRAM MM with TTM buffer objects. New
> + * functions can be added if necessary.
> + */
> +struct drm_vram_mm_funcs {
> + void (*evict_flags)(struct ttm_buffer_object *bo,
> + struct ttm_placement *placement);
> + void (*move_notify)(struct ttm_buffer_object *bo, bool evict,
> + struct ttm_mem_reg *new_mem);
> +};
> +
> +/**
> + * struct drm_vram_mm - An instance of VRAM MM
> + * @vram_base: Base address of the managed video memory
> + * @vram_size: Size of the managed video memory in bytes
> + * @bdev:The TTM BO device.
> + * @funcs: TTM BO functions
> + *
> + * The fields drm_vram_mm.vram_base and
> + * drm_vram_mm.vrm_size are managed by VRAM MM, but are
> + * available for public read access. Use the field
> + * drm_vram_mm.bdev to access the TTM BO device.
> + */
> +struct drm_vram_mm {
> + uint64_t vram_base;
> + size_t vram_size;
> +
> + struct ttm_bo_device bdev;
> +
> + const struct drm_vram_mm_funcs *funcs;
> +};
> +
> +/**
> + * drm_vram_mm_of_bdev() - \
> + Returns the container of type ttm_bo_device for field bdev.
> + * @bdev:the TTM BO device
> + *
> + * Returns:
> + * The containing instance of drm_vram_mm
> + */
> +static inline struct drm_vram_mm *drm_vram_mm_of_bdev(
> + struct ttm_bo_device *bdev)
> +{
> + return container_of(bdev, struct drm_vram_mm, bdev);
> +}
> +
> +int drm_vram_mm_debugfs_init(struct drm_minor *minor);
> +int drm_vram_mm_init(struct drm_vram_mm *vmm, struct drm_device *dev,
> + uint64_t vram_base, size_t vram_size,
> + const struct drm_vram_mm_funcs *funcs);
> +void drm_vram_mm_cleanup(struct drm_vram_mm *vmm);
> +
> +int drm_vram_mm_mmap(struct file *filp, struct vm_area_struct *vma,
> + struct drm_vram_mm *vmm);
> +
> +/*
> + * Helpers for integration with struct drm_device
> + */
> +
> +struct drm_vram_mm *drm_vram_helper_alloc_mm(
> + struct drm_device *dev, uint64_t vram_base, size_t vram_size,
> + const struct drm_vram_mm_funcs *funcs);
> +void drm_vram_helper_release_mm(struct drm_device *dev);
> +
> +#endif
> diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
> index e0e8770462bc..1f17794b0890 100644
> --- a/drivers/gpu/drm/ast/ast_drv.c
> +++
[PATCH 4.19 125/190] PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary
[ Upstream commit e0547c81bfcfad01cbbfa93a5e66bb98ab932f80 ] On ThinkPad P50 SKUs with an Nvidia Quadro M1000M instead of the M2000M variant, the BIOS does not always reset the secondary Nvidia GPU during reboot if the laptop is configured in Hybrid Graphics mode. The reason is unknown, but the following steps and possibly a good bit of patience will reproduce the issue: 1. Boot up the laptop normally in Hybrid Graphics mode 2. Make sure nouveau is loaded and that the GPU is awake 3. Allow the Nvidia GPU to runtime suspend itself after being idle 4. Reboot the machine, the more sudden the better (e.g. sysrq-b may help) 5. If nouveau loads up properly, reboot the machine again and go back to step 2 until you reproduce the issue This results in some very strange behavior: the GPU will be left in exactly the same state it was in when the previously booted kernel started the reboot. This has all sorts of bad side effects: for starters, this completely breaks nouveau starting with a mysterious EVO channel failure that happens well before we've actually used the EVO channel for anything: nouveau :01:00.0: disp: chid 0 mthd data 0400 1000 0002 This causes a timeout trying to bring up the GR ctx: nouveau :01:00.0: timeout WARNING: CPU: 0 PID: 12 at drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c:1547 gf100_grctx_generate+0x7b2/0x850 [nouveau] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET82W (1.55 ) 12/18/2018 Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] ... nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau :01:00.0: fifo: fault 01 [WRITE] at 8000 engine 00 [GR] client 15 [HUB/SCC_NB] reason c4 [] on channel -1 [00 unknown] The GPU never manages to recover. Booting without loading nouveau causes issues as well, since the GPU starts sending spurious interrupts that cause other device's IRQs to get disabled by the kernel: irq 16: nobody cared (try booting with the "irqpoll" option) ... handlers: [<7faa9e99>] i801_isr [i2c_i801] Disabling IRQ #16 ... serio: RMI4 PS/2 pass-through port at rmi4-00.fn03 i801_smbus :00:1f.4: Timeout waiting for interrupt! i801_smbus :00:1f.4: Transaction timeout rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-110). i801_smbus :00:1f.4: Timeout waiting for interrupt! i801_smbus :00:1f.4: Transaction timeout rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled interrupts! This causes the touchpad and sometimes other things to get disabled. Since this happens without nouveau, we can't fix this problem from nouveau itself. Add a PCI quirk for the specific P50 variant of this GPU. Make sure the GPU is advertising NoReset- so we don't reset the GPU when the machine is in Dedicated graphics mode (where the GPU being initialized by the BIOS is normal and expected). Map the GPU MMIO space and read the magic 0x2240c register, which will have bit 1 set if the device was POSTed during a previous boot. Once we've confirmed all of this, reset the GPU and re-disable it - bringing it back to a healthy state. Link: https://bugzilla.kernel.org/show_bug.cgi?id=203003 Link: https://lore.kernel.org/lkml/20190212220230.1568-1-ly...@redhat.com Signed-off-by: Lyude Paul Signed-off-by: Bjorn Helgaas Cc: nouv...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: Karol Herbst Cc: Ben Skeggs Cc: sta...@vger.kernel.org Signed-off-by: Sasha Levin --- drivers/pci/quirks.c | 58 1 file changed, 58 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 6cda8b7ecc821..311f8a33e62ff 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -5116,3 +5116,61 @@ SWITCHTEC_QUIRK(0x8573); /* PFXI 48XG3 */ SWITCHTEC_QUIRK(0x8574); /* PFXI 64XG3 */ SWITCHTEC_QUIRK(0x8575); /* PFXI 80XG3 */ SWITCHTEC_QUIRK(0x8576); /* PFXI 96XG3 */ + +/* + * On Lenovo Thinkpad P50 SKUs with a Nvidia Quadro M1000M, the BIOS does + * not always reset the secondary Nvidia GPU between reboots if the system + * is configured to use Hybrid Graphics mode. This results in the GPU + * being left in whatever state it was in during the *previous* boot, which + * causes spurious interrupts from the GPU, which in turn causes us to + * disable the wrong IRQ and end up breaking the touchpad. Unsurprisingly, + * this also completely breaks nouveau. + * + * Luckily, it seems a simple reset of the Nvidia GPU brings it back to a + * clean state and fixes all these issues. + * + * When the machine is configured in Dedicated display mode, the issue + * doesn't occur. Fortunately the GPU advertises NoReset+ when in this + * mode, so we can detect that and avoid resetting it. + */ +static void
[PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
[ Upstream commit b513a18cf1d705bd04efd91c417e79e4938be093 ]
This is much louder then we want. VCPI allocation failures are quite
normal, since they will happen if any part of the modesetting process is
interrupted by removing the DP MST topology in question. So just print a
debugging message on VCPI failures instead.
Signed-off-by: Lyude Paul
Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2
multi-stream")
Cc: Ben Skeggs
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: # v4.10+
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index f889d41a281fa..5e01bfb69d7a3 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -759,7 +759,8 @@ nv50_msto_enable(struct drm_encoder *encoder)
slots = drm_dp_find_vcpi_slots(>mgr, mstc->pbn);
r = drm_dp_mst_allocate_vcpi(>mgr, mstc->port, mstc->pbn, slots);
- WARN_ON(!r);
+ if (!r)
+ DRM_DEBUG_KMS("Failed to allocate VCPI\n");
if (!mstm->links++)
nv50_outp_acquire(mstm->outp);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/8] drm/vram: drop verify_access
Hi
Am 13.09.19 um 14:29 schrieb Gerd Hoffmann:
> Not needed any more.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 22 --
> 1 file changed, 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index e100b97ea6e3..42ee80414273 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -469,13 +469,6 @@ static void drm_gem_vram_bo_driver_evict_flags(struct
> drm_gem_vram_object *gbo,
> *pl = gbo->placement;
> }
>
> -static int drm_gem_vram_bo_driver_verify_access(struct drm_gem_vram_object
> *gbo,
> - struct file *filp)
> -{
> - return drm_vma_node_verify_access(>bo.base.vma_node,
> - filp->private_data);
> -}
> -
> static void drm_gem_vram_bo_driver_move_notify(struct drm_gem_vram_object
> *gbo,
> bool evict,
> struct ttm_mem_reg *new_mem)
> @@ -767,20 +760,6 @@ static void bo_driver_evict_flags(struct
> ttm_buffer_object *bo,
> drm_gem_vram_bo_driver_evict_flags(gbo, placement);
> }
>
> -static int bo_driver_verify_access(struct ttm_buffer_object *bo,
> -struct file *filp)
> -{
> - struct drm_gem_vram_object *gbo;
> -
> - /* TTM may pass BOs that are not GEM VRAM BOs. */
> - if (!drm_is_gem_vram(bo))
> - return -EINVAL;
> -
> - gbo = drm_gem_vram_of_bo(bo);
> -
> - return drm_gem_vram_bo_driver_verify_access(gbo, filp);
> -}
> -
> static void bo_driver_move_notify(struct ttm_buffer_object *bo,
> bool evict,
> struct ttm_mem_reg *new_mem)
> @@ -837,7 +816,6 @@ static struct ttm_bo_driver bo_driver = {
> .init_mem_type = bo_driver_init_mem_type,
> .eviction_valuable = ttm_bo_eviction_valuable,
> .evict_flags = bo_driver_evict_flags,
> - .verify_access = bo_driver_verify_access,
> .move_notify = bo_driver_move_notify,
> .io_mem_reserve = bo_driver_io_mem_reserve,
> .io_mem_free = bo_driver_io_mem_free,
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] drm/vram: switch vram helper to _gem_object_funcs.mmap()
Hi
Am 13.09.19 um 14:29 schrieb Gerd Hoffmann:
> Wire up the new drm_gem_ttm_mmap() helper function,
> use generic drm_gem_mmap for and
> delete dead drm_vram_mm_file_operations_mmap().
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Thomas Zimmermann
> ---
> include/drm/drm_gem_vram_helper.h | 9 +--
> drivers/gpu/drm/drm_gem_vram_helper.c | 34 +--
> 2 files changed, 2 insertions(+), 41 deletions(-)
>
> diff --git a/include/drm/drm_gem_vram_helper.h
> b/include/drm/drm_gem_vram_helper.h
> index 9aaef4f8c327..9d5526650291 100644
> --- a/include/drm/drm_gem_vram_helper.h
> +++ b/include/drm/drm_gem_vram_helper.h
> @@ -180,13 +180,6 @@ struct drm_vram_mm *drm_vram_helper_alloc_mm(
> struct drm_device *dev, uint64_t vram_base, size_t vram_size);
> void drm_vram_helper_release_mm(struct drm_device *dev);
>
> -/*
> - * Helpers for file_operations
> - */
> -
> -int drm_vram_mm_file_operations_mmap(
> - struct file *filp, struct vm_area_struct *vma);
> -
> /**
> * define DRM_VRAM_MM_FILE_OPERATIONS - default callback functions for \
>file_operations
> @@ -200,7 +193,7 @@ int drm_vram_mm_file_operations_mmap(
> .poll = drm_poll, \
> .unlocked_ioctl = drm_ioctl, \
> .compat_ioctl = drm_compat_ioctl, \
> - .mmap = drm_vram_mm_file_operations_mmap, \
> + .mmap = drm_gem_mmap, \
> .open = drm_open, \
> .release= drm_release \
>
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index 7bee80c6b6e8..e100b97ea6e3 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -681,6 +681,7 @@ static const struct drm_gem_object_funcs
> drm_gem_vram_object_funcs = {
> .unpin = drm_gem_vram_object_unpin,
> .vmap = drm_gem_vram_object_vmap,
> .vunmap = drm_gem_vram_object_vunmap,
> + .mmap = drm_gem_ttm_mmap,
> .print_info = drm_gem_ttm_print_info,
> };
>
> @@ -915,12 +916,6 @@ static void drm_vram_mm_cleanup(struct drm_vram_mm *vmm)
> ttm_bo_device_release(>bdev);
> }
>
> -static int drm_vram_mm_mmap(struct file *filp, struct vm_area_struct *vma,
> - struct drm_vram_mm *vmm)
> -{
> - return ttm_bo_mmap(filp, vma, >bdev);
> -}
> -
> /*
> * Helpers for integration with struct drm_device
> */
> @@ -976,30 +971,3 @@ void drm_vram_helper_release_mm(struct drm_device *dev)
> dev->vram_mm = NULL;
> }
> EXPORT_SYMBOL(drm_vram_helper_release_mm);
> -
> -/*
> - * Helpers for file_operations
> - */
> -
> -/**
> - * drm_vram_mm_file_operations_mmap() - \
> - Implements file_operations.mmap()
> - * @filp:the mapping's file structure
> - * @vma: the mapping's memory area
> - *
> - * Returns:
> - * 0 on success, or
> - * a negative error code otherwise.
> - */
> -int drm_vram_mm_file_operations_mmap(
> - struct file *filp, struct vm_area_struct *vma)
> -{
> - struct drm_file *file_priv = filp->private_data;
> - struct drm_device *dev = file_priv->minor->dev;
> -
> - if (WARN_ONCE(!dev->vram_mm, "VRAM MM not initialized"))
> - return -EINVAL;
> -
> - return drm_vram_mm_mmap(filp, vma, dev->vram_mm);
> -}
> -EXPORT_SYMBOL(drm_vram_mm_file_operations_mmap);
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/9] drm/print: add drm_debug_enabled()
On Friday, 2019-09-13 14:51:39 +0300, Jani Nikula wrote:
> Add helper to check if a drm debug category is enabled. Convert drm core
> to use it. No functional changes.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
> drivers/gpu/drm/drm_dp_mst_topology.c | 6 +++---
> drivers/gpu/drm/drm_edid.c| 2 +-
> drivers/gpu/drm/drm_edid_load.c | 2 +-
> drivers/gpu/drm/drm_mipi_dbi.c| 4 ++--
> drivers/gpu/drm/drm_print.c | 4 ++--
> drivers/gpu/drm/drm_vblank.c | 6 +++---
> include/drm/drm_print.h | 5 +
> 8 files changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 5a5b42db6f2a..6576cd997cbd 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -1406,7 +1406,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
> ret = drm_atomic_nonblocking_commit(state);
> } else {
> - if (unlikely(drm_debug & DRM_UT_STATE))
> + if (unlikely(drm_debug_enabled(DRM_UT_STATE)))
> drm_atomic_print_state(state);
>
> ret = drm_atomic_commit(state);
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 97216099a718..f47c5b6b51f7 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1180,7 +1180,7 @@ static int drm_dp_mst_wait_tx_reply(struct
> drm_dp_mst_branch *mstb,
> }
> }
> out:
> - if (unlikely(ret == -EIO && drm_debug & DRM_UT_DP)) {
> + if (unlikely(ret == -EIO && drm_debug_enabled(DRM_UT_DP))) {
> struct drm_printer p = drm_debug_printer(DBG_PREFIX);
>
> drm_dp_mst_dump_sideband_msg_tx(, txmsg);
> @@ -2321,7 +2321,7 @@ static int process_single_tx_qlock(struct
> drm_dp_mst_topology_mgr *mgr,
> idx += tosend + 1;
>
> ret = drm_dp_send_sideband_msg(mgr, up, chunk, idx);
> - if (unlikely(ret && drm_debug & DRM_UT_DP)) {
> + if (unlikely(ret && drm_debug_enabled(DRM_UT_DP))) {
> struct drm_printer p = drm_debug_printer(DBG_PREFIX);
>
> drm_printf(, "sideband msg failed to send\n");
> @@ -2388,7 +2388,7 @@ static void drm_dp_queue_down_tx(struct
> drm_dp_mst_topology_mgr *mgr,
> mutex_lock(>qlock);
> list_add_tail(>next, >tx_msg_downq);
>
> - if (unlikely(drm_debug & DRM_UT_DP)) {
> + if (unlikely(drm_debug_enabled(DRM_UT_DP))) {
> struct drm_printer p = drm_debug_printer(DBG_PREFIX);
>
> drm_dp_mst_dump_sideband_msg_tx(, txmsg);
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 12c783f4d956..58dad4d24cd4 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1551,7 +1551,7 @@ static void connector_bad_edid(struct drm_connector
> *connector,
> {
> int i;
>
> - if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
> + if (connector->bad_edid_counter++ && !drm_debug_enabled(DRM_UT_KMS))
> return;
>
> dev_warn(connector->dev->dev,
> diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
> index d38b3b255926..37d8ba3ddb46 100644
> --- a/drivers/gpu/drm/drm_edid_load.c
> +++ b/drivers/gpu/drm/drm_edid_load.c
> @@ -175,7 +175,7 @@ static void *edid_load(struct drm_connector *connector,
> const char *name,
> u8 *edid;
> int fwsize, builtin;
> int i, valid_extensions = 0;
> - bool print_bad_edid = !connector->bad_edid_counter || (drm_debug &
> DRM_UT_KMS);
> + bool print_bad_edid = !connector->bad_edid_counter ||
> drm_debug_enabled(DRM_UT_KMS);
>
> builtin = match_string(generic_edid_name, GENERIC_EDIDS, name);
> if (builtin >= 0) {
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index f8154316a3b0..ccfb5b33c5e3 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -783,7 +783,7 @@ static int mipi_dbi_spi1e_transfer(struct mipi_dbi *dbi,
> int dc,
> int i, ret;
> u8 *dst;
>
> - if (drm_debug & DRM_UT_DRIVER)
> + if (drm_debug_enabled(DRM_UT_DRIVER))
> pr_debug("[drm:%s] dc=%d, max_chunk=%zu, transfers:\n",
>__func__, dc, max_chunk);
>
> @@ -907,7 +907,7 @@ static int mipi_dbi_spi1_transfer(struct mipi_dbi *dbi,
> int dc,
> max_chunk = dbi->tx_buf9_len;
> dst16 = dbi->tx_buf9;
>
> - if (drm_debug & DRM_UT_DRIVER)
> + if (drm_debug_enabled(DRM_UT_DRIVER))
> pr_debug("[drm:%s] dc=%d, max_chunk=%zu, transfers:\n",
>__func__, dc, max_chunk);
>
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index
Re: [PATCH 4/8] drm/ttm: factor out ttm_bo_mmap_vma_setup
Hi
Am 13.09.19 um 14:29 schrieb Gerd Hoffmann:
> Factor out ttm vma setup to a new function. Reduces
> code duplication a bit and allows to implement
> _gem_object_funcs.mmap in gem ttm helpers.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/drm/ttm/ttm_bo_api.h| 8 ++
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 47 ++---
> 2 files changed, 33 insertions(+), 22 deletions(-)
>
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index 43c4929a2171..88c652f49602 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -734,6 +734,14 @@ int ttm_fbdev_mmap(struct vm_area_struct *vma, struct
> ttm_buffer_object *bo);
> int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma,
> struct ttm_bo_device *bdev);
>
> +/**
> + * ttm_bo_mmap_vma_setup - initialize vma for ttm bo mmap
> + *
> + * @bo: The buffer object.
> + * @vma: vma as input from the mmap method.
> + */
> +void ttm_bo_mmap_vma_setup(struct ttm_buffer_object *bo, struct
> vm_area_struct *vma);
> +
> void *ttm_kmap_atomic_prot(struct page *page, pgprot_t prot);
>
> void ttm_kunmap_atomic_prot(void *addr, pgprot_t prot);
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 4aa007edffb0..7c0e85c10e0e 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -426,6 +426,29 @@ static struct ttm_buffer_object *ttm_bo_vm_lookup(struct
> ttm_bo_device *bdev,
> return bo;
> }
>
> +void ttm_bo_mmap_vma_setup(struct ttm_buffer_object *bo, struct
> vm_area_struct *vma)
> +{
> + vma->vm_ops = _bo_vm_ops;
> +
> + /*
> + * Note: We're transferring the bo reference to
> + * vma->vm_private_data here.
> + */
> +
> + vma->vm_private_data = bo;
> +
> + /*
> + * We'd like to use VM_PFNMAP on shared mappings, where
> + * (vma->vm_flags & VM_SHARED) != 0, for performance reasons,
> + * but for some reason VM_PFNMAP + x86 PAT + write-combine is very
> + * bad for performance. Until that has been sorted out, use
> + * VM_MIXEDMAP on all mappings. See freedesktop.org bug #75719
> + */
> + vma->vm_flags |= VM_MIXEDMAP;
> + vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
> +}
> +EXPORT_SYMBOL(ttm_bo_mmap_vma_setup);
To me, this function looks like an internal helper that should rather
remain internal. As mentioned in my reply to patch 5, maybe re-using
ttm_fbdev_mmap() could help.
Best regards
Thomas
> +
> int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma,
> struct ttm_bo_device *bdev)
> {
> @@ -449,24 +472,7 @@ int ttm_bo_mmap(struct file *filp, struct vm_area_struct
> *vma,
> if (unlikely(ret != 0))
> goto out_unref;
>
> - vma->vm_ops = _bo_vm_ops;
> -
> - /*
> - * Note: We're transferring the bo reference to
> - * vma->vm_private_data here.
> - */
> -
> - vma->vm_private_data = bo;
> -
> - /*
> - * We'd like to use VM_PFNMAP on shared mappings, where
> - * (vma->vm_flags & VM_SHARED) != 0, for performance reasons,
> - * but for some reason VM_PFNMAP + x86 PAT + write-combine is very
> - * bad for performance. Until that has been sorted out, use
> - * VM_MIXEDMAP on all mappings. See freedesktop.org bug #75719
> - */
> - vma->vm_flags |= VM_MIXEDMAP;
> - vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
> + ttm_bo_mmap_vma_setup(bo, vma);
> return 0;
> out_unref:
> ttm_bo_put(bo);
> @@ -481,10 +487,7 @@ int ttm_fbdev_mmap(struct vm_area_struct *vma, struct
> ttm_buffer_object *bo)
>
> ttm_bo_get(bo);
>
> - vma->vm_ops = _bo_vm_ops;
> - vma->vm_private_data = bo;
> - vma->vm_flags |= VM_MIXEDMAP;
> - vma->vm_flags |= VM_IO | VM_DONTEXPAND;
> + ttm_bo_mmap_vma_setup(bo, vma);
> return 0;
> }
> EXPORT_SYMBOL(ttm_fbdev_mmap);
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 5/8] drm/ttm: add drm_gem_ttm_mmap()
Hi
Am 13.09.19 um 14:29 schrieb Gerd Hoffmann:
> Add helper function to mmap ttm bo's using _gem_object_funcs.mmap().
>
> Note that with this code path access verification is done by
> drm_gem_mmap() (which calls drm_vma_node_is_allowed(()).
> The _bo_driver.verify_access() callback is is not used.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/drm/drm_gem_ttm_helper.h | 2 ++
> drivers/gpu/drm/drm_gem_ttm_helper.c | 19 +++
> 2 files changed, 21 insertions(+)
>
> diff --git a/include/drm/drm_gem_ttm_helper.h
> b/include/drm/drm_gem_ttm_helper.h
> index 6268f89c5a48..118cef76f84f 100644
> --- a/include/drm/drm_gem_ttm_helper.h
> +++ b/include/drm/drm_gem_ttm_helper.h
> @@ -15,5 +15,7 @@
>
> void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int indent,
> const struct drm_gem_object *gem);
> +int drm_gem_ttm_mmap(struct drm_gem_object *gem,
> + struct vm_area_struct *vma);
>
> #endif
> diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
> b/drivers/gpu/drm/drm_gem_ttm_helper.c
> index 9a4bafcf20df..34ce6cf78b35 100644
> --- a/drivers/gpu/drm/drm_gem_ttm_helper.c
> +++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
> @@ -52,5 +52,24 @@ void drm_gem_ttm_print_info(struct drm_printer *p,
> unsigned int indent,
> }
> EXPORT_SYMBOL(drm_gem_ttm_print_info);
>
> +/**
> + * drm_gem_ttm_mmap() - mmap _buffer_object
> + * @gem: GEM object.
> + * @vma: vm area.
> + *
> + * This function can be used as _gem_object_funcs.mmap
> + * callback.
> + */
> +int drm_gem_ttm_mmap(struct drm_gem_object *gem,
> + struct vm_area_struct *vma)
> +{
> + struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
> +
> + ttm_bo_get(bo);
> + ttm_bo_mmap_vma_setup(bo, vma);
> + return 0;
> +}
This function looks like ttm_fbdev_mmap(). Can you use that instead?
Best regards
Thomas
> +EXPORT_SYMBOL(drm_gem_ttm_mmap);
> +
> MODULE_DESCRIPTION("DRM gem ttm helpers");
> MODULE_LICENSE("GPL");
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 4/8] drm/ttm: factor out ttm_bo_mmap_vma_setup
Hi
Am 13.09.19 um 14:29 schrieb Gerd Hoffmann:
> Factor out ttm vma setup to a new function. Reduces
> code duplication a bit and allows to implement
> _gem_object_funcs.mmap in gem ttm helpers.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/drm/ttm/ttm_bo_api.h| 8 ++
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 47 ++---
> 2 files changed, 33 insertions(+), 22 deletions(-)
>
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index 43c4929a2171..88c652f49602 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -734,6 +734,14 @@ int ttm_fbdev_mmap(struct vm_area_struct *vma, struct
> ttm_buffer_object *bo);
> int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma,
> struct ttm_bo_device *bdev);
>
> +/**
> + * ttm_bo_mmap_vma_setup - initialize vma for ttm bo mmap
> + *
> + * @bo: The buffer object.
> + * @vma: vma as input from the mmap method.
> + */
> +void ttm_bo_mmap_vma_setup(struct ttm_buffer_object *bo, struct
> vm_area_struct *vma);
> +
> void *ttm_kmap_atomic_prot(struct page *page, pgprot_t prot);
>
> void ttm_kunmap_atomic_prot(void *addr, pgprot_t prot);
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 4aa007edffb0..7c0e85c10e0e 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -426,6 +426,29 @@ static struct ttm_buffer_object *ttm_bo_vm_lookup(struct
> ttm_bo_device *bdev,
> return bo;
> }
>
> +void ttm_bo_mmap_vma_setup(struct ttm_buffer_object *bo, struct
> vm_area_struct *vma)
> +{
> + vma->vm_ops = _bo_vm_ops;
> +
> + /*
> + * Note: We're transferring the bo reference to
> + * vma->vm_private_data here.
> + */
> +
> + vma->vm_private_data = bo;
> +
> + /*
> + * We'd like to use VM_PFNMAP on shared mappings, where
> + * (vma->vm_flags & VM_SHARED) != 0, for performance reasons,
> + * but for some reason VM_PFNMAP + x86 PAT + write-combine is very
> + * bad for performance. Until that has been sorted out, use
> + * VM_MIXEDMAP on all mappings. See freedesktop.org bug #75719
> + */
> + vma->vm_flags |= VM_MIXEDMAP;
> + vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
> +}
> +EXPORT_SYMBOL(ttm_bo_mmap_vma_setup);
> +
> int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma,
> struct ttm_bo_device *bdev)
> {
> @@ -449,24 +472,7 @@ int ttm_bo_mmap(struct file *filp, struct vm_area_struct
> *vma,
> if (unlikely(ret != 0))
> goto out_unref;
>
> - vma->vm_ops = _bo_vm_ops;
> -
> - /*
> - * Note: We're transferring the bo reference to
> - * vma->vm_private_data here.
> - */
> -
> - vma->vm_private_data = bo;
> -
> - /*
> - * We'd like to use VM_PFNMAP on shared mappings, where
> - * (vma->vm_flags & VM_SHARED) != 0, for performance reasons,
> - * but for some reason VM_PFNMAP + x86 PAT + write-combine is very
> - * bad for performance. Until that has been sorted out, use
> - * VM_MIXEDMAP on all mappings. See freedesktop.org bug #75719
> - */
> - vma->vm_flags |= VM_MIXEDMAP;
> - vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
> + ttm_bo_mmap_vma_setup(bo, vma);
> return 0;
> out_unref:
> ttm_bo_put(bo);
> @@ -481,10 +487,7 @@ int ttm_fbdev_mmap(struct vm_area_struct *vma, struct
> ttm_buffer_object *bo)
>
> ttm_bo_get(bo);
>
> - vma->vm_ops = _bo_vm_ops;
> - vma->vm_private_data = bo;
> - vma->vm_flags |= VM_MIXEDMAP;
> - vma->vm_flags |= VM_IO | VM_DONTEXPAND;
> + ttm_bo_mmap_vma_setup(bo, vma);
Just double-checking: ttm_bo_mmap_vma_setup() will set VM_DONTDUMP in
vm_flags. Is that OK?
Best regards
Thomas
> return 0;
> }
> EXPORT_SYMBOL(ttm_fbdev_mmap);
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] drm: rework mmap() workflow
On Fri, Sep 13, 2019 at 02:29:00PM +0200, Gerd Hoffmann wrote: > Add mmap callback to drm_object Oops, hit sent to early. This should have been this: Add mmap callback to struct drm_gem_object_funcs, which is supposed to handle the vma setup. It will be used by both normal fops->mmap (via drm_gem_mmap_obj()) and prime mmap (via drm_gem_prime_mmap()). For starters the shmem and vram helpers are switched over to the new workflow, to show things in action for review. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] drm/vram: drop DRM_VRAM_MM_FILE_OPERATIONS
Not needed any more because we don't have vram specific fops
any more. DEFINE_DRM_GEM_FOPS() can be used instead.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_vram_helper.h | 18
include/drm/drm_vram_mm_helper.h | 82 +++
drivers/gpu/drm/ast/ast_drv.c | 5 +-
drivers/gpu/drm/bochs/bochs_drv.c | 5 +-
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +-
drivers/gpu/drm/mgag200/mgag200_drv.c | 5 +-
drivers/gpu/drm/vboxvideo/vbox_drv.c | 5 +-
7 files changed, 87 insertions(+), 38 deletions(-)
create mode 100644 include/drm/drm_vram_mm_helper.h
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index 9d5526650291..3503ff784803 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -180,22 +180,4 @@ struct drm_vram_mm *drm_vram_helper_alloc_mm(
struct drm_device *dev, uint64_t vram_base, size_t vram_size);
void drm_vram_helper_release_mm(struct drm_device *dev);
-/**
- * define DRM_VRAM_MM_FILE_OPERATIONS - default callback functions for \
-file_operations
- *
- * Drivers that use VRAM MM can use this macro to initialize
- * file_operations with default functions.
- */
-#define DRM_VRAM_MM_FILE_OPERATIONS \
- .llseek = no_llseek, \
- .read = drm_read, \
- .poll = drm_poll, \
- .unlocked_ioctl = drm_ioctl, \
- .compat_ioctl = drm_compat_ioctl, \
- .mmap = drm_gem_mmap, \
- .open = drm_open, \
- .release= drm_release \
-
-
#endif
diff --git a/include/drm/drm_vram_mm_helper.h b/include/drm/drm_vram_mm_helper.h
new file mode 100644
index ..a47b49adba62
--- /dev/null
+++ b/include/drm/drm_vram_mm_helper.h
@@ -0,0 +1,82 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#ifndef DRM_VRAM_MM_HELPER_H
+#define DRM_VRAM_MM_HELPER_H
+
+#include
+#include
+#include
+
+struct drm_device;
+
+/**
+ * struct drm_vram_mm_funcs - Callback functions for drm_vram_mm
+ * @evict_flags: Provides an implementation for struct \
+ _bo_driver.evict_flags
+ * @move_notify: Provides an implementation for
+ * struct _bo_driver.move_notify
+ *
+ * These callback function integrate VRAM MM with TTM buffer objects. New
+ * functions can be added if necessary.
+ */
+struct drm_vram_mm_funcs {
+ void (*evict_flags)(struct ttm_buffer_object *bo,
+ struct ttm_placement *placement);
+ void (*move_notify)(struct ttm_buffer_object *bo, bool evict,
+ struct ttm_mem_reg *new_mem);
+};
+
+/**
+ * struct drm_vram_mm - An instance of VRAM MM
+ * @vram_base: Base address of the managed video memory
+ * @vram_size: Size of the managed video memory in bytes
+ * @bdev: The TTM BO device.
+ * @funcs: TTM BO functions
+ *
+ * The fields drm_vram_mm.vram_base and
+ * drm_vram_mm.vrm_size are managed by VRAM MM, but are
+ * available for public read access. Use the field
+ * drm_vram_mm.bdev to access the TTM BO device.
+ */
+struct drm_vram_mm {
+ uint64_t vram_base;
+ size_t vram_size;
+
+ struct ttm_bo_device bdev;
+
+ const struct drm_vram_mm_funcs *funcs;
+};
+
+/**
+ * drm_vram_mm_of_bdev() - \
+ Returns the container of type ttm_bo_device for field bdev.
+ * @bdev: the TTM BO device
+ *
+ * Returns:
+ * The containing instance of drm_vram_mm
+ */
+static inline struct drm_vram_mm *drm_vram_mm_of_bdev(
+ struct ttm_bo_device *bdev)
+{
+ return container_of(bdev, struct drm_vram_mm, bdev);
+}
+
+int drm_vram_mm_debugfs_init(struct drm_minor *minor);
+int drm_vram_mm_init(struct drm_vram_mm *vmm, struct drm_device *dev,
+uint64_t vram_base, size_t vram_size,
+const struct drm_vram_mm_funcs *funcs);
+void drm_vram_mm_cleanup(struct drm_vram_mm *vmm);
+
+int drm_vram_mm_mmap(struct file *filp, struct vm_area_struct *vma,
+struct drm_vram_mm *vmm);
+
+/*
+ * Helpers for integration with struct drm_device
+ */
+
+struct drm_vram_mm *drm_vram_helper_alloc_mm(
+ struct drm_device *dev, uint64_t vram_base, size_t vram_size,
+ const struct drm_vram_mm_funcs *funcs);
+void drm_vram_helper_release_mm(struct drm_device *dev);
+
+#endif
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index e0e8770462bc..1f17794b0890 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -200,10 +200,7 @@ static struct pci_driver ast_pci_driver = {
.driver.pm = _pm_ops,
};
-static const struct file_operations ast_fops = {
- .owner = THIS_MODULE,
- DRM_VRAM_MM_FILE_OPERATIONS
-};
+DEFINE_DRM_GEM_FOPS(ast_fops);
static struct drm_driver driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM,
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
[PATCH 6/8] drm/vram: switch vram helper to _gem_object_funcs.mmap()
Wire up the new drm_gem_ttm_mmap() helper function,
use generic drm_gem_mmap for and
delete dead drm_vram_mm_file_operations_mmap().
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_vram_helper.h | 9 +--
drivers/gpu/drm/drm_gem_vram_helper.c | 34 +--
2 files changed, 2 insertions(+), 41 deletions(-)
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index 9aaef4f8c327..9d5526650291 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -180,13 +180,6 @@ struct drm_vram_mm *drm_vram_helper_alloc_mm(
struct drm_device *dev, uint64_t vram_base, size_t vram_size);
void drm_vram_helper_release_mm(struct drm_device *dev);
-/*
- * Helpers for file_operations
- */
-
-int drm_vram_mm_file_operations_mmap(
- struct file *filp, struct vm_area_struct *vma);
-
/**
* define DRM_VRAM_MM_FILE_OPERATIONS - default callback functions for \
file_operations
@@ -200,7 +193,7 @@ int drm_vram_mm_file_operations_mmap(
.poll = drm_poll, \
.unlocked_ioctl = drm_ioctl, \
.compat_ioctl = drm_compat_ioctl, \
- .mmap = drm_vram_mm_file_operations_mmap, \
+ .mmap = drm_gem_mmap, \
.open = drm_open, \
.release= drm_release \
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 7bee80c6b6e8..e100b97ea6e3 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -681,6 +681,7 @@ static const struct drm_gem_object_funcs
drm_gem_vram_object_funcs = {
.unpin = drm_gem_vram_object_unpin,
.vmap = drm_gem_vram_object_vmap,
.vunmap = drm_gem_vram_object_vunmap,
+ .mmap = drm_gem_ttm_mmap,
.print_info = drm_gem_ttm_print_info,
};
@@ -915,12 +916,6 @@ static void drm_vram_mm_cleanup(struct drm_vram_mm *vmm)
ttm_bo_device_release(>bdev);
}
-static int drm_vram_mm_mmap(struct file *filp, struct vm_area_struct *vma,
- struct drm_vram_mm *vmm)
-{
- return ttm_bo_mmap(filp, vma, >bdev);
-}
-
/*
* Helpers for integration with struct drm_device
*/
@@ -976,30 +971,3 @@ void drm_vram_helper_release_mm(struct drm_device *dev)
dev->vram_mm = NULL;
}
EXPORT_SYMBOL(drm_vram_helper_release_mm);
-
-/*
- * Helpers for file_operations
- */
-
-/**
- * drm_vram_mm_file_operations_mmap() - \
- Implements file_operations.mmap()
- * @filp: the mapping's file structure
- * @vma: the mapping's memory area
- *
- * Returns:
- * 0 on success, or
- * a negative error code otherwise.
- */
-int drm_vram_mm_file_operations_mmap(
- struct file *filp, struct vm_area_struct *vma)
-{
- struct drm_file *file_priv = filp->private_data;
- struct drm_device *dev = file_priv->minor->dev;
-
- if (WARN_ONCE(!dev->vram_mm, "VRAM MM not initialized"))
- return -EINVAL;
-
- return drm_vram_mm_mmap(filp, vma, dev->vram_mm);
-}
-EXPORT_SYMBOL(drm_vram_mm_file_operations_mmap);
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/8] drm/shmem: drop DEFINE_DRM_GEM_SHMEM_FOPS
DEFINE_DRM_GEM_SHMEM_FOPS is identical
to DEFINE_DRM_GEM_FOPS now, drop it.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_shmem_helper.h | 26 -
drivers/gpu/drm/cirrus/cirrus.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +-
drivers/gpu/drm/tiny/gm12u320.c | 2 +-
drivers/gpu/drm/v3d/v3d_drv.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_drv.c| 2 +-
6 files changed, 5 insertions(+), 31 deletions(-)
diff --git a/include/drm/drm_gem_shmem_helper.h
b/include/drm/drm_gem_shmem_helper.h
index d89f2116c8ab..6748379a0b44 100644
--- a/include/drm/drm_gem_shmem_helper.h
+++ b/include/drm/drm_gem_shmem_helper.h
@@ -88,32 +88,6 @@ struct drm_gem_shmem_object {
#define to_drm_gem_shmem_obj(obj) \
container_of(obj, struct drm_gem_shmem_object, base)
-/**
- * DEFINE_DRM_GEM_SHMEM_FOPS() - Macro to generate file operations for shmem
drivers
- * @name: name for the generated structure
- *
- * This macro autogenerates a suitable file_operations for shmem based
- * drivers, which can be assigned to _driver.fops. Note that this structure
- * cannot be shared between drivers, because it contains a reference to the
- * current module using THIS_MODULE.
- *
- * Note that the declaration is already marked as static - if you need a
- * non-static version of this you're probably doing it wrong and will break the
- * THIS_MODULE reference by accident.
- */
-#define DEFINE_DRM_GEM_SHMEM_FOPS(name) \
- static const struct file_operations name = {\
- .owner = THIS_MODULE,\
- .open = drm_open,\
- .release= drm_release,\
- .unlocked_ioctl = drm_ioctl,\
- .compat_ioctl = drm_compat_ioctl,\
- .poll = drm_poll,\
- .read = drm_read,\
- .llseek = noop_llseek,\
- .mmap = drm_gem_mmap, \
- }
-
struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev,
size_t size);
void drm_gem_shmem_free_object(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/cirrus/cirrus.c b/drivers/gpu/drm/cirrus/cirrus.c
index 89d9e6fdeb8c..7d08d067e1a4 100644
--- a/drivers/gpu/drm/cirrus/cirrus.c
+++ b/drivers/gpu/drm/cirrus/cirrus.c
@@ -510,7 +510,7 @@ static void cirrus_mode_config_init(struct cirrus_device
*cirrus)
/* -- */
-DEFINE_DRM_GEM_SHMEM_FOPS(cirrus_fops);
+DEFINE_DRM_GEM_FOPS(cirrus_fops);
static struct drm_driver cirrus_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index d74442d71048..a78ce21594d7 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -470,7 +470,7 @@ static const struct drm_ioctl_desc
panfrost_drm_driver_ioctls[] = {
PANFROST_IOCTL(MADVISE, madvise,DRM_RENDER_ALLOW),
};
-DEFINE_DRM_GEM_SHMEM_FOPS(panfrost_drm_driver_fops);
+DEFINE_DRM_GEM_FOPS(panfrost_drm_driver_fops);
/*
* Panfrost driver version:
diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c
index 03d0e2df6774..94fb1f593564 100644
--- a/drivers/gpu/drm/tiny/gm12u320.c
+++ b/drivers/gpu/drm/tiny/gm12u320.c
@@ -649,7 +649,7 @@ static void gm12u320_driver_release(struct drm_device *dev)
kfree(gm12u320);
}
-DEFINE_DRM_GEM_SHMEM_FOPS(gm12u320_fops);
+DEFINE_DRM_GEM_FOPS(gm12u320_fops);
static struct drm_driver gm12u320_drm_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 3506ae2723ae..03e4fbe1b92b 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -169,7 +169,7 @@ v3d_postclose(struct drm_device *dev, struct drm_file *file)
kfree(v3d_priv);
}
-DEFINE_DRM_GEM_SHMEM_FOPS(v3d_drm_fops);
+DEFINE_DRM_GEM_FOPS(v3d_drm_fops);
/* DRM_AUTH is required on SUBMIT_CL for now, while we don't have GMP
* protection between clients. Note that render nodes would be be
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index a5cb58754f7d..8dee698c90ff 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -184,7 +184,7 @@ MODULE_AUTHOR("Dave Airlie ");
MODULE_AUTHOR("Gerd Hoffmann ");
MODULE_AUTHOR("Alon Levy");
-DEFINE_DRM_GEM_SHMEM_FOPS(virtio_gpu_driver_fops);
+DEFINE_DRM_GEM_FOPS(virtio_gpu_driver_fops);
static struct drm_driver driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_RENDER |
DRIVER_ATOMIC,
--
2.18.1
[PATCH 1/8] drm: add mmap() to drm_gem_object_funcs
drm_gem_object_funcs->vm_ops alone can't handle everything which needs
to be done for mmap(), tweaking vm_flags for example. So add a new
mmap() callback to drm_gem_object_funcs where this code can go to.
Note that the vm_ops field is not used in case the mmap callback is
presnt, it is expected that the callback sets vma->vm_ops instead.
drm_gem_mmap_obj() will use the new callback for object specific mmap
setup. With this in place the need for driver-speific fops->mmap
callbacks goes away, drm_gem_mmap can be hooked instead.
drm_gem_prime_mmap() will use the new callback too to just mmap gem
objects directly instead of jumping though loops to make
drm_gem_object_lookup() and fops->mmap work.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem.h | 14 ++
drivers/gpu/drm/drm_gem.c | 27 ++-
drivers/gpu/drm/drm_prime.c | 9 +
3 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 6aaba14f5972..e71f75a2ab57 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -150,6 +150,20 @@ struct drm_gem_object_funcs {
*/
void (*vunmap)(struct drm_gem_object *obj, void *vaddr);
+ /**
+* @mmap:
+*
+* Handle mmap() of the gem object, setup vma accordingly.
+*
+* This callback is optional.
+*
+* The callback is used by by both drm_gem_mmap_obj() and
+* drm_gem_prime_mmap(). When @mmap is present @vm_ops is not
+* used, the @mmap callback must set vma->vm_ops instead.
+*
+*/
+ int (*mmap)(struct drm_gem_object *obj, struct vm_area_struct *vma);
+
/**
* @vm_ops:
*
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 6854f5867d51..56f42e0f2584 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1099,22 +1099,31 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj,
unsigned long obj_size,
struct vm_area_struct *vma)
{
struct drm_device *dev = obj->dev;
+ int ret;
/* Check for valid size. */
if (obj_size < vma->vm_end - vma->vm_start)
return -EINVAL;
- if (obj->funcs && obj->funcs->vm_ops)
- vma->vm_ops = obj->funcs->vm_ops;
- else if (dev->driver->gem_vm_ops)
- vma->vm_ops = dev->driver->gem_vm_ops;
- else
- return -EINVAL;
+ if (obj->funcs && obj->funcs->mmap) {
+ ret = obj->funcs->mmap(obj, vma);
+ if (ret)
+ return ret;
+ WARN_ON(!(vma->vm_flags & VM_DONTEXPAND));
+ } else {
+ if (obj->funcs && obj->funcs->vm_ops)
+ vma->vm_ops = obj->funcs->vm_ops;
+ else if (dev->driver->gem_vm_ops)
+ vma->vm_ops = dev->driver->gem_vm_ops;
+ else
+ return -EINVAL;
+
+ vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND |
VM_DONTDUMP;
+ vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
+ vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+ }
- vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
vma->vm_private_data = obj;
- vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
- vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
/* Take a ref for this mapping of the object, so that the fault
* handler can dereference the mmap offset's pointer to the object.
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 0a2316e0e812..0814211b0f3f 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -713,6 +713,15 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma)
struct file *fil;
int ret;
+ if (obj->funcs && obj->funcs->mmap) {
+ ret = obj->funcs->mmap(obj, vma);
+ if (ret)
+ return ret;
+ vma->vm_private_data = obj;
+ drm_gem_object_get(obj);
+ return 0;
+ }
+
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
fil = kzalloc(sizeof(*fil), GFP_KERNEL);
if (!priv || !fil) {
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8] drm/ttm: add drm_gem_ttm_mmap()
Add helper function to mmap ttm bo's using _gem_object_funcs.mmap().
Note that with this code path access verification is done by
drm_gem_mmap() (which calls drm_vma_node_is_allowed(()).
The _bo_driver.verify_access() callback is is not used.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_ttm_helper.h | 2 ++
drivers/gpu/drm/drm_gem_ttm_helper.c | 19 +++
2 files changed, 21 insertions(+)
diff --git a/include/drm/drm_gem_ttm_helper.h b/include/drm/drm_gem_ttm_helper.h
index 6268f89c5a48..118cef76f84f 100644
--- a/include/drm/drm_gem_ttm_helper.h
+++ b/include/drm/drm_gem_ttm_helper.h
@@ -15,5 +15,7 @@
void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int indent,
const struct drm_gem_object *gem);
+int drm_gem_ttm_mmap(struct drm_gem_object *gem,
+struct vm_area_struct *vma);
#endif
diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
b/drivers/gpu/drm/drm_gem_ttm_helper.c
index 9a4bafcf20df..34ce6cf78b35 100644
--- a/drivers/gpu/drm/drm_gem_ttm_helper.c
+++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
@@ -52,5 +52,24 @@ void drm_gem_ttm_print_info(struct drm_printer *p, unsigned
int indent,
}
EXPORT_SYMBOL(drm_gem_ttm_print_info);
+/**
+ * drm_gem_ttm_mmap() - mmap _buffer_object
+ * @gem: GEM object.
+ * @vma: vm area.
+ *
+ * This function can be used as _gem_object_funcs.mmap
+ * callback.
+ */
+int drm_gem_ttm_mmap(struct drm_gem_object *gem,
+struct vm_area_struct *vma)
+{
+ struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
+
+ ttm_bo_get(bo);
+ ttm_bo_mmap_vma_setup(bo, vma);
+ return 0;
+}
+EXPORT_SYMBOL(drm_gem_ttm_mmap);
+
MODULE_DESCRIPTION("DRM gem ttm helpers");
MODULE_LICENSE("GPL");
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/8] drm/shmem: switch shmem helper to _gem_object_funcs.mmap
Switch gem shmem helper to the new mmap() workflow,
from _driver.fops.mmap to _gem_object_funcs.mmap.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_shmem_helper.h | 6 ++
drivers/gpu/drm/drm_gem_shmem_helper.c | 26 -
drivers/gpu/drm/panfrost/panfrost_gem.c | 2 +-
drivers/gpu/drm/v3d/v3d_bo.c| 2 +-
drivers/gpu/drm/virtio/virtgpu_object.c | 2 +-
5 files changed, 13 insertions(+), 25 deletions(-)
diff --git a/include/drm/drm_gem_shmem_helper.h
b/include/drm/drm_gem_shmem_helper.h
index 01f514521687..d89f2116c8ab 100644
--- a/include/drm/drm_gem_shmem_helper.h
+++ b/include/drm/drm_gem_shmem_helper.h
@@ -111,7 +111,7 @@ struct drm_gem_shmem_object {
.poll = drm_poll,\
.read = drm_read,\
.llseek = noop_llseek,\
- .mmap = drm_gem_shmem_mmap, \
+ .mmap = drm_gem_mmap, \
}
struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev,
size_t size);
@@ -143,9 +143,7 @@ drm_gem_shmem_create_with_handle(struct drm_file *file_priv,
int drm_gem_shmem_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args);
-int drm_gem_shmem_mmap(struct file *filp, struct vm_area_struct *vma);
-
-extern const struct vm_operations_struct drm_gem_shmem_vm_ops;
+int drm_gem_shmem_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma);
void drm_gem_shmem_print_info(struct drm_printer *p, unsigned int indent,
const struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index f5918707672f..a104140154bb 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -32,7 +32,7 @@ static const struct drm_gem_object_funcs drm_gem_shmem_funcs
= {
.get_sg_table = drm_gem_shmem_get_sg_table,
.vmap = drm_gem_shmem_vmap,
.vunmap = drm_gem_shmem_vunmap,
- .vm_ops = _gem_shmem_vm_ops,
+ .mmap = drm_gem_shmem_mmap,
};
/**
@@ -505,39 +505,30 @@ static void drm_gem_shmem_vm_close(struct vm_area_struct
*vma)
drm_gem_vm_close(vma);
}
-const struct vm_operations_struct drm_gem_shmem_vm_ops = {
+static const struct vm_operations_struct drm_gem_shmem_vm_ops = {
.fault = drm_gem_shmem_fault,
.open = drm_gem_shmem_vm_open,
.close = drm_gem_shmem_vm_close,
};
-EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_ops);
/**
* drm_gem_shmem_mmap - Memory-map a shmem GEM object
- * @filp: File object
+ * @obj: gem object
* @vma: VMA for the area to be mapped
*
* This function implements an augmented version of the GEM DRM file mmap
* operation for shmem objects. Drivers which employ the shmem helpers should
- * use this function as their _operations.mmap handler in the DRM device
file's
- * file_operations structure.
- *
- * Instead of directly referencing this function, drivers should use the
- * DEFINE_DRM_GEM_SHMEM_FOPS() macro.
+ * use this function as their _gem_object_funcs.mmap handler.
*
* Returns:
* 0 on success or a negative error code on failure.
*/
-int drm_gem_shmem_mmap(struct file *filp, struct vm_area_struct *vma)
+int drm_gem_shmem_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
{
struct drm_gem_shmem_object *shmem;
int ret;
- ret = drm_gem_mmap(filp, vma);
- if (ret)
- return ret;
-
- shmem = to_drm_gem_shmem_obj(vma->vm_private_data);
+ shmem = to_drm_gem_shmem_obj(obj);
ret = drm_gem_shmem_get_pages(shmem);
if (ret) {
@@ -545,9 +536,8 @@ int drm_gem_shmem_mmap(struct file *filp, struct
vm_area_struct *vma)
return ret;
}
- /* VM_PFNMAP was set by drm_gem_mmap() */
- vma->vm_flags &= ~VM_PFNMAP;
- vma->vm_flags |= VM_MIXEDMAP;
+ vma->vm_flags |= (VM_MIXEDMAP|VM_DONTEXPAND);
+ vma->vm_ops = _gem_shmem_vm_ops;
/* Remove the fake offset */
vma->vm_pgoff -= drm_vma_node_start(>base.vma_node);
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index acb07fe06580..deca0c30bbd4 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -112,7 +112,7 @@ static const struct drm_gem_object_funcs panfrost_gem_funcs
= {
.get_sg_table = drm_gem_shmem_get_sg_table,
.vmap = drm_gem_shmem_vmap,
.vunmap = drm_gem_shmem_vunmap,
- .vm_ops = _gem_shmem_vm_ops,
+ .mmap = drm_gem_shmem_mmap,
};
/**
diff --git a/drivers/gpu/drm/v3d/v3d_bo.c b/drivers/gpu/drm/v3d/v3d_bo.c
index a22b75a3a533..edd299ab53d8 100644
--- a/drivers/gpu/drm/v3d/v3d_bo.c
+++ b/drivers/gpu/drm/v3d/v3d_bo.c
@@ -58,7 +58,7 @@ static const struct drm_gem_object_funcs v3d_gem_funcs = {
.get_sg_table =
[PATCH 0/8] drm: rework mmap() workflow
Add mmap callback to drm_object Gerd Hoffmann (8): drm: add mmap() to drm_gem_object_funcs drm/shmem: switch shmem helper to _gem_object_funcs.mmap drm/shmem: drop DEFINE_DRM_GEM_SHMEM_FOPS drm/ttm: factor out ttm_bo_mmap_vma_setup drm/ttm: add drm_gem_ttm_mmap() drm/vram: switch vram helper to _gem_object_funcs.mmap() drm/vram: drop verify_access drm/vram: drop DRM_VRAM_MM_FILE_OPERATIONS include/drm/drm_gem.h | 14 include/drm/drm_gem_shmem_helper.h| 30 +-- include/drm/drm_gem_ttm_helper.h | 2 + include/drm/drm_gem_vram_helper.h | 25 -- include/drm/drm_vram_mm_helper.h | 82 +++ include/drm/ttm/ttm_bo_api.h | 8 ++ drivers/gpu/drm/ast/ast_drv.c | 5 +- drivers/gpu/drm/bochs/bochs_drv.c | 5 +- drivers/gpu/drm/cirrus/cirrus.c | 2 +- drivers/gpu/drm/drm_gem.c | 27 -- drivers/gpu/drm/drm_gem_shmem_helper.c| 26 ++ drivers/gpu/drm/drm_gem_ttm_helper.c | 19 + drivers/gpu/drm/drm_gem_vram_helper.c | 56 + drivers/gpu/drm/drm_prime.c | 9 ++ .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +- drivers/gpu/drm/mgag200/mgag200_drv.c | 5 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- drivers/gpu/drm/panfrost/panfrost_gem.c | 2 +- drivers/gpu/drm/tiny/gm12u320.c | 2 +- drivers/gpu/drm/ttm/ttm_bo_vm.c | 47 ++- drivers/gpu/drm/v3d/v3d_bo.c | 2 +- drivers/gpu/drm/v3d/v3d_drv.c | 2 +- drivers/gpu/drm/vboxvideo/vbox_drv.c | 5 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +- drivers/gpu/drm/virtio/virtgpu_object.c | 2 +- 25 files changed, 200 insertions(+), 186 deletions(-) create mode 100644 include/drm/drm_vram_mm_helper.h -- 2.18.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/8] drm/vram: drop verify_access
Not needed any more.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 22 --
1 file changed, 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index e100b97ea6e3..42ee80414273 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -469,13 +469,6 @@ static void drm_gem_vram_bo_driver_evict_flags(struct
drm_gem_vram_object *gbo,
*pl = gbo->placement;
}
-static int drm_gem_vram_bo_driver_verify_access(struct drm_gem_vram_object
*gbo,
- struct file *filp)
-{
- return drm_vma_node_verify_access(>bo.base.vma_node,
- filp->private_data);
-}
-
static void drm_gem_vram_bo_driver_move_notify(struct drm_gem_vram_object *gbo,
bool evict,
struct ttm_mem_reg *new_mem)
@@ -767,20 +760,6 @@ static void bo_driver_evict_flags(struct ttm_buffer_object
*bo,
drm_gem_vram_bo_driver_evict_flags(gbo, placement);
}
-static int bo_driver_verify_access(struct ttm_buffer_object *bo,
- struct file *filp)
-{
- struct drm_gem_vram_object *gbo;
-
- /* TTM may pass BOs that are not GEM VRAM BOs. */
- if (!drm_is_gem_vram(bo))
- return -EINVAL;
-
- gbo = drm_gem_vram_of_bo(bo);
-
- return drm_gem_vram_bo_driver_verify_access(gbo, filp);
-}
-
static void bo_driver_move_notify(struct ttm_buffer_object *bo,
bool evict,
struct ttm_mem_reg *new_mem)
@@ -837,7 +816,6 @@ static struct ttm_bo_driver bo_driver = {
.init_mem_type = bo_driver_init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = bo_driver_evict_flags,
- .verify_access = bo_driver_verify_access,
.move_notify = bo_driver_move_notify,
.io_mem_reserve = bo_driver_io_mem_reserve,
.io_mem_free = bo_driver_io_mem_free,
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8] drm/ttm: factor out ttm_bo_mmap_vma_setup
Factor out ttm vma setup to a new function. Reduces
code duplication a bit and allows to implement
_gem_object_funcs.mmap in gem ttm helpers.
Signed-off-by: Gerd Hoffmann
---
include/drm/ttm/ttm_bo_api.h| 8 ++
drivers/gpu/drm/ttm/ttm_bo_vm.c | 47 ++---
2 files changed, 33 insertions(+), 22 deletions(-)
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 43c4929a2171..88c652f49602 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -734,6 +734,14 @@ int ttm_fbdev_mmap(struct vm_area_struct *vma, struct
ttm_buffer_object *bo);
int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma,
struct ttm_bo_device *bdev);
+/**
+ * ttm_bo_mmap_vma_setup - initialize vma for ttm bo mmap
+ *
+ * @bo: The buffer object.
+ * @vma: vma as input from the mmap method.
+ */
+void ttm_bo_mmap_vma_setup(struct ttm_buffer_object *bo, struct vm_area_struct
*vma);
+
void *ttm_kmap_atomic_prot(struct page *page, pgprot_t prot);
void ttm_kunmap_atomic_prot(void *addr, pgprot_t prot);
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 4aa007edffb0..7c0e85c10e0e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -426,6 +426,29 @@ static struct ttm_buffer_object *ttm_bo_vm_lookup(struct
ttm_bo_device *bdev,
return bo;
}
+void ttm_bo_mmap_vma_setup(struct ttm_buffer_object *bo, struct vm_area_struct
*vma)
+{
+ vma->vm_ops = _bo_vm_ops;
+
+ /*
+* Note: We're transferring the bo reference to
+* vma->vm_private_data here.
+*/
+
+ vma->vm_private_data = bo;
+
+ /*
+* We'd like to use VM_PFNMAP on shared mappings, where
+* (vma->vm_flags & VM_SHARED) != 0, for performance reasons,
+* but for some reason VM_PFNMAP + x86 PAT + write-combine is very
+* bad for performance. Until that has been sorted out, use
+* VM_MIXEDMAP on all mappings. See freedesktop.org bug #75719
+*/
+ vma->vm_flags |= VM_MIXEDMAP;
+ vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
+}
+EXPORT_SYMBOL(ttm_bo_mmap_vma_setup);
+
int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma,
struct ttm_bo_device *bdev)
{
@@ -449,24 +472,7 @@ int ttm_bo_mmap(struct file *filp, struct vm_area_struct
*vma,
if (unlikely(ret != 0))
goto out_unref;
- vma->vm_ops = _bo_vm_ops;
-
- /*
-* Note: We're transferring the bo reference to
-* vma->vm_private_data here.
-*/
-
- vma->vm_private_data = bo;
-
- /*
-* We'd like to use VM_PFNMAP on shared mappings, where
-* (vma->vm_flags & VM_SHARED) != 0, for performance reasons,
-* but for some reason VM_PFNMAP + x86 PAT + write-combine is very
-* bad for performance. Until that has been sorted out, use
-* VM_MIXEDMAP on all mappings. See freedesktop.org bug #75719
-*/
- vma->vm_flags |= VM_MIXEDMAP;
- vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
+ ttm_bo_mmap_vma_setup(bo, vma);
return 0;
out_unref:
ttm_bo_put(bo);
@@ -481,10 +487,7 @@ int ttm_fbdev_mmap(struct vm_area_struct *vma, struct
ttm_buffer_object *bo)
ttm_bo_get(bo);
- vma->vm_ops = _bo_vm_ops;
- vma->vm_private_data = bo;
- vma->vm_flags |= VM_MIXEDMAP;
- vma->vm_flags |= VM_IO | VM_DONTEXPAND;
+ ttm_bo_mmap_vma_setup(bo, vma);
return 0;
}
EXPORT_SYMBOL(ttm_fbdev_mmap);
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/connector: Share with non-atomic drivers the function to get the single encoder
Hi José,
Thank you for the patch.
On Thu, Sep 12, 2019 at 12:51:31PM -0700, José Roberto de Souza wrote:
> This 3 non-atomic drivers all have the same function getting the
> only encoder available in the connector, also atomic drivers have
> this fallback. So moving it a common place and sharing between atomic
> and non-atomic drivers.
>
> While at it I also removed the mention of
> drm_atomic_helper_best_encoder() that was renamed in
> commit 297e30b5d9b6 ("drm/atomic-helper: Unexport
> drm_atomic_helper_best_encoder").
>
> v3: moving drm_connector_get_single_encoder to drm_kms_helper module
>
> Suggested-by: Ville Syrjälä
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: dri-devel@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/ast/ast_mode.c | 12
> drivers/gpu/drm/drm_atomic_helper.c| 15 ++-
> drivers/gpu/drm/drm_crtc_helper.c | 17 -
> drivers/gpu/drm/drm_crtc_helper_internal.h | 3 +++
> drivers/gpu/drm/mgag200/mgag200_mode.c | 11 ---
> drivers/gpu/drm/udl/udl_connector.c| 8
> include/drm/drm_modeset_helper_vtables.h | 6 +++---
> 7 files changed, 24 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index d349c721501c..eef95e1af06b 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -687,17 +687,6 @@ static void ast_encoder_destroy(struct drm_encoder
> *encoder)
> kfree(encoder);
> }
>
> -
> -static struct drm_encoder *ast_best_single_encoder(struct drm_connector
> *connector)
> -{
> - int enc_id = connector->encoder_ids[0];
> - /* pick the encoder ids */
> - if (enc_id)
> - return drm_encoder_find(connector->dev, NULL, enc_id);
> - return NULL;
> -}
> -
> -
> static const struct drm_encoder_funcs ast_enc_funcs = {
> .destroy = ast_encoder_destroy,
> };
> @@ -847,7 +836,6 @@ static void ast_connector_destroy(struct drm_connector
> *connector)
> static const struct drm_connector_helper_funcs ast_connector_helper_funcs = {
> .mode_valid = ast_mode_valid,
> .get_modes = ast_get_modes,
> - .best_encoder = ast_best_single_encoder,
> };
>
> static const struct drm_connector_funcs ast_connector_funcs = {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 4706439fb490..9d7e4da6c292 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -97,17 +97,6 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state
> *state,
> }
> }
>
> -/*
> - * For connectors that support multiple encoders, either the
> - * .atomic_best_encoder() or .best_encoder() operation must be implemented.
> - */
> -static struct drm_encoder *
> -pick_single_encoder_for_connector(struct drm_connector *connector)
> -{
> - WARN_ON(connector->encoder_ids[1]);
> - return drm_encoder_find(connector->dev, NULL,
> connector->encoder_ids[0]);
> -}
> -
> static int handle_conflicting_encoders(struct drm_atomic_state *state,
> bool disable_conflicting_encoders)
> {
> @@ -135,7 +124,7 @@ static int handle_conflicting_encoders(struct
> drm_atomic_state *state,
> else if (funcs->best_encoder)
> new_encoder = funcs->best_encoder(connector);
> else
> - new_encoder =
> pick_single_encoder_for_connector(connector);
> + new_encoder =
> drm_connector_get_single_encoder(connector);
>
> if (new_encoder) {
> if (encoder_mask & drm_encoder_mask(new_encoder)) {
> @@ -359,7 +348,7 @@ update_connector_routing(struct drm_atomic_state *state,
> else if (funcs->best_encoder)
> new_encoder = funcs->best_encoder(connector);
> else
> - new_encoder = pick_single_encoder_for_connector(connector);
> + new_encoder = drm_connector_get_single_encoder(connector);
>
> if (!new_encoder) {
> DRM_DEBUG_ATOMIC("No suitable encoder found for
> [CONNECTOR:%d:%s]\n",
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> b/drivers/gpu/drm/drm_crtc_helper.c
> index a51824a7e7c1..4a7447a53cea 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -460,6 +460,17 @@ drm_crtc_helper_disable(struct drm_crtc *crtc)
> __drm_helper_disable_unused_functions(dev);
> }
>
> +/*
> + * For connectors that support multiple encoders, either the
> + * .atomic_best_encoder() or .best_encoder() operation must be implemented.
> + */
> +struct drm_encoder *
> +drm_connector_get_single_encoder(struct drm_connector *connector)
> +{
> + WARN_ON(connector->encoder_ids[1]);
> + return drm_encoder_find(connector->dev, NULL,
>
[Bug 111669] Navi GPU hang in Minecraft
https://bugs.freedesktop.org/show_bug.cgi?id=111669 --- Comment #2 from Pierre-Eric Pelloux-Prayer --- The kernel patch from https://bugs.freedesktop.org/show_bug.cgi?id=111481#c33 seems to prevent the hang here. Could you try it as well and report the results? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: Fix references to drm_bridge_funcs in documentation
On 22.08.2019 01:55, Laurent Pinchart wrote:
> The documentation for most of the bridge atomic operations incorrectly
> reference the non-atomic version when stating the operations are
> optional. Fix them, and make sure that all references to bridge
> operations are correctly marked with @.
>
> Signed-off-by: Laurent Pinchart
Queued to drm-misc-next.
Regards
Andrzej
> ---
> include/drm/drm_bridge.h | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 7616f6562fe4..6d76c67fb819 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -42,7 +42,7 @@ struct drm_bridge_funcs {
>* This callback is invoked whenever our bridge is being attached to a
>* _encoder.
>*
> - * The attach callback is optional.
> + * The @attach callback is optional.
>*
>* RETURNS:
>*
> @@ -56,7 +56,7 @@ struct drm_bridge_funcs {
>* This callback is invoked whenever our bridge is being detached from a
>* _encoder.
>*
> - * The detach callback is optional.
> + * The @detach callback is optional.
>*/
> void (*detach)(struct drm_bridge *bridge);
>
> @@ -76,7 +76,7 @@ struct drm_bridge_funcs {
>* atomic helpers to validate modes supplied by userspace in
>* drm_atomic_helper_check_modeset().
>*
> - * This function is optional.
> + * The @mode_valid callback is optional.
>*
>* NOTE:
>*
> @@ -108,7 +108,7 @@ struct drm_bridge_funcs {
>* this function passes all other callbacks must succeed for this
>* configuration.
>*
> - * The mode_fixup callback is optional.
> + * The @mode_fixup callback is optional.
>*
>* NOTE:
>*
> @@ -146,7 +146,7 @@ struct drm_bridge_funcs {
>* The bridge can assume that the display pipe (i.e. clocks and timing
>* signals) feeding it is still running when this callback is called.
>*
> - * The disable callback is optional.
> + * The @disable callback is optional.
>*/
> void (*disable)(struct drm_bridge *bridge);
>
> @@ -165,7 +165,7 @@ struct drm_bridge_funcs {
>* singals) feeding it is no longer running when this callback is
>* called.
>*
> - * The post_disable callback is optional.
> + * The @post_disable callback is optional.
>*/
> void (*post_disable)(struct drm_bridge *bridge);
>
> @@ -214,7 +214,7 @@ struct drm_bridge_funcs {
>* not enable the display link feeding the next bridge in the chain (if
>* there is one) when this callback is called.
>*
> - * The pre_enable callback is optional.
> + * The @pre_enable callback is optional.
>*/
> void (*pre_enable)(struct drm_bridge *bridge);
>
> @@ -234,7 +234,7 @@ struct drm_bridge_funcs {
>* callback must enable the display link feeding the next bridge in the
>* chain if there is one.
>*
> - * The enable callback is optional.
> + * The @enable callback is optional.
>*/
> void (*enable)(struct drm_bridge *bridge);
>
> @@ -283,7 +283,7 @@ struct drm_bridge_funcs {
>* would be prudent to also provide an implementation of @enable if
>* you are expecting driver calls into _bridge_enable.
>*
> - * The enable callback is optional.
> + * The @atomic_enable callback is optional.
>*/
> void (*atomic_enable)(struct drm_bridge *bridge,
> struct drm_atomic_state *state);
> @@ -305,7 +305,7 @@ struct drm_bridge_funcs {
>* would be prudent to also provide an implementation of @disable if
>* you are expecting driver calls into _bridge_disable.
>*
> - * The disable callback is optional.
> + * The @atomic_disable callback is optional.
>*/
> void (*atomic_disable)(struct drm_bridge *bridge,
> struct drm_atomic_state *state);
> @@ -330,7 +330,7 @@ struct drm_bridge_funcs {
>* @post_disable if you are expecting driver calls into
>* _bridge_post_disable.
>*
> - * The post_disable callback is optional.
> + * The @atomic_post_disable callback is optional.
>*/
> void (*atomic_post_disable)(struct drm_bridge *bridge,
> struct drm_atomic_state *state);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] drm/panfrost: Tidy up the devfreq implementation
On 9/12/19 12:28 PM, Steven Price wrote: The devfreq implementation in panfrost is unnecessarily open coded. It also tracks utilisation metrics per slot which isn't very useful. Let's tidy it up! This should be picked up along with Mark's change[1] to fix regulator_get_optional() misuse. This also deletes the code changes from 52282163dfa6 and e21dd290881b which would otherwise need reverting, see the previous discussion[2]. Both patches look great. Reviewed-by: Tomeu Vizoso Thanks! Tomeu [1] https://lore.kernel.org/lkml/20190904123032.23263-1-broo...@kernel.org/ [2] https://lore.kernel.org/lkml/ccd81530-2dbd-3c02-ca0a-1085b0066...@arm.com/ Steven Price (2): drm/panfrost: Use generic code for devfreq drm/panfrost: Simplify devfreq utilisation tracking drivers/gpu/drm/panfrost/panfrost_devfreq.c | 126 ++-- drivers/gpu/drm/panfrost/panfrost_devfreq.h | 3 +- drivers/gpu/drm/panfrost/panfrost_device.h | 14 +-- drivers/gpu/drm/panfrost/panfrost_job.c | 14 +-- 4 files changed, 48 insertions(+), 109 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/connector: Share with non-atomic drivers the function to get the single encoder
On Thu, Sep 12, 2019 at 12:51:31PM -0700, José Roberto de Souza wrote:
> This 3 non-atomic drivers all have the same function getting the
> only encoder available in the connector, also atomic drivers have
> this fallback. So moving it a common place and sharing between atomic
> and non-atomic drivers.
>
> While at it I also removed the mention of
> drm_atomic_helper_best_encoder() that was renamed in
> commit 297e30b5d9b6 ("drm/atomic-helper: Unexport
> drm_atomic_helper_best_encoder").
>
> v3: moving drm_connector_get_single_encoder to drm_kms_helper module
>
> Suggested-by: Ville Syrjälä
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: dri-devel@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Signed-off-by: José Roberto de Souza
lgtm
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/ast/ast_mode.c | 12
> drivers/gpu/drm/drm_atomic_helper.c| 15 ++-
> drivers/gpu/drm/drm_crtc_helper.c | 17 -
> drivers/gpu/drm/drm_crtc_helper_internal.h | 3 +++
> drivers/gpu/drm/mgag200/mgag200_mode.c | 11 ---
> drivers/gpu/drm/udl/udl_connector.c| 8
> include/drm/drm_modeset_helper_vtables.h | 6 +++---
> 7 files changed, 24 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index d349c721501c..eef95e1af06b 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -687,17 +687,6 @@ static void ast_encoder_destroy(struct drm_encoder
> *encoder)
> kfree(encoder);
> }
>
> -
> -static struct drm_encoder *ast_best_single_encoder(struct drm_connector
> *connector)
> -{
> - int enc_id = connector->encoder_ids[0];
> - /* pick the encoder ids */
> - if (enc_id)
> - return drm_encoder_find(connector->dev, NULL, enc_id);
> - return NULL;
> -}
> -
> -
> static const struct drm_encoder_funcs ast_enc_funcs = {
> .destroy = ast_encoder_destroy,
> };
> @@ -847,7 +836,6 @@ static void ast_connector_destroy(struct drm_connector
> *connector)
> static const struct drm_connector_helper_funcs ast_connector_helper_funcs = {
> .mode_valid = ast_mode_valid,
> .get_modes = ast_get_modes,
> - .best_encoder = ast_best_single_encoder,
> };
>
> static const struct drm_connector_funcs ast_connector_funcs = {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 4706439fb490..9d7e4da6c292 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -97,17 +97,6 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state
> *state,
> }
> }
>
> -/*
> - * For connectors that support multiple encoders, either the
> - * .atomic_best_encoder() or .best_encoder() operation must be implemented.
> - */
> -static struct drm_encoder *
> -pick_single_encoder_for_connector(struct drm_connector *connector)
> -{
> - WARN_ON(connector->encoder_ids[1]);
> - return drm_encoder_find(connector->dev, NULL,
> connector->encoder_ids[0]);
> -}
> -
> static int handle_conflicting_encoders(struct drm_atomic_state *state,
> bool disable_conflicting_encoders)
> {
> @@ -135,7 +124,7 @@ static int handle_conflicting_encoders(struct
> drm_atomic_state *state,
> else if (funcs->best_encoder)
> new_encoder = funcs->best_encoder(connector);
> else
> - new_encoder =
> pick_single_encoder_for_connector(connector);
> + new_encoder =
> drm_connector_get_single_encoder(connector);
>
> if (new_encoder) {
> if (encoder_mask & drm_encoder_mask(new_encoder)) {
> @@ -359,7 +348,7 @@ update_connector_routing(struct drm_atomic_state *state,
> else if (funcs->best_encoder)
> new_encoder = funcs->best_encoder(connector);
> else
> - new_encoder = pick_single_encoder_for_connector(connector);
> + new_encoder = drm_connector_get_single_encoder(connector);
>
> if (!new_encoder) {
> DRM_DEBUG_ATOMIC("No suitable encoder found for
> [CONNECTOR:%d:%s]\n",
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> b/drivers/gpu/drm/drm_crtc_helper.c
> index a51824a7e7c1..4a7447a53cea 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -460,6 +460,17 @@ drm_crtc_helper_disable(struct drm_crtc *crtc)
> __drm_helper_disable_unused_functions(dev);
> }
>
> +/*
> + * For connectors that support multiple encoders, either the
> + * .atomic_best_encoder() or .best_encoder() operation must be implemented.
> + */
> +struct drm_encoder *
> +drm_connector_get_single_encoder(struct drm_connector *connector)
> +{
> + WARN_ON(connector->encoder_ids[1]);
> + return drm_encoder_find(connector->dev, NULL,
>
[PATCH 9/9] drm/print: rename drm_debug to __drm_debug to discourage use
drm_debug_enabled() is the way to check. __drm_debug is now reserved for
drm print code only. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_print.c | 8
include/drm/drm_print.h | 5 +++--
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index a7c89ec5ff26..ca3c56b026f0 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -37,11 +37,11 @@
#include
/*
- * drm_debug: Enable debug output.
+ * __drm_debug: Enable debug output.
* Bitmask of DRM_UT_x. See include/drm/drm_print.h for details.
*/
-unsigned int drm_debug;
-EXPORT_SYMBOL(drm_debug);
+unsigned int __drm_debug;
+EXPORT_SYMBOL(__drm_debug);
MODULE_PARM_DESC(debug, "Enable debug output, where each bit enables a debug
category.\n"
"\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n"
@@ -52,7 +52,7 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each bit
enables a debug cat
"\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n"
"\t\tBit 7 (0x80) will enable LEASE messages (leasing code)\n"
"\t\tBit 8 (0x100) will enable DP messages (displayport code)");
-module_param_named(debug, drm_debug, int, 0600);
+module_param_named(debug, __drm_debug, int, 0600);
void __drm_puts_coredump(struct drm_printer *p, const char *str)
{
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index e13f901312a4..880bc0d1fd48 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -34,7 +34,8 @@
#include
-extern unsigned int drm_debug;
+/* Do *not* use outside of drm_print.[ch]! */
+extern unsigned int __drm_debug;
/**
* DOC: print
@@ -296,7 +297,7 @@ static inline struct drm_printer drm_err_printer(const char
*prefix)
static inline bool drm_debug_enabled(unsigned int category)
{
- return drm_debug & category;
+ return __drm_debug & category;
}
__printf(3, 4)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] drm/print: move drm_debug variable to drm_print.[ch]
Move drm_debug variable declaration and definition to where they are
relevant and needed. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_drv.c | 17 -
drivers/gpu/drm/drm_print.c | 19 +++
include/drm/drm_drv.h | 2 --
include/drm/drm_print.h | 2 ++
4 files changed, 21 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index c456c3d3def2..b5b3fffe2299 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -46,26 +46,9 @@
#include "drm_internal.h"
#include "drm_legacy.h"
-/*
- * drm_debug: Enable debug output.
- * Bitmask of DRM_UT_x. See include/drm/drm_print.h for details.
- */
-unsigned int drm_debug = 0;
-EXPORT_SYMBOL(drm_debug);
-
MODULE_AUTHOR("Gareth Hughes, Leif Delgass, José Fonseca, Jon Smirl");
MODULE_DESCRIPTION("DRM shared core routines");
MODULE_LICENSE("GPL and additional rights");
-MODULE_PARM_DESC(debug, "Enable debug output, where each bit enables a debug
category.\n"
-"\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n"
-"\t\tBit 1 (0x02) will enable DRIVER messages (drm controller code)\n"
-"\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n"
-"\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n"
-"\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n"
-"\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n"
-"\t\tBit 7 (0x80) will enable LEASE messages (leasing code)\n"
-"\t\tBit 8 (0x100) will enable DP messages (displayport code)");
-module_param_named(debug, drm_debug, int, 0600);
static DEFINE_SPINLOCK(drm_minor_lock);
static struct idr drm_minors_idr;
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index dfa27367ebb8..c9b57012d412 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
@@ -35,6 +36,24 @@
#include
#include
+/*
+ * drm_debug: Enable debug output.
+ * Bitmask of DRM_UT_x. See include/drm/drm_print.h for details.
+ */
+unsigned int drm_debug;
+EXPORT_SYMBOL(drm_debug);
+
+MODULE_PARM_DESC(debug, "Enable debug output, where each bit enables a debug
category.\n"
+"\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n"
+"\t\tBit 1 (0x02) will enable DRIVER messages (drm controller code)\n"
+"\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n"
+"\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n"
+"\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n"
+"\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n"
+"\t\tBit 7 (0x80) will enable LEASE messages (leasing code)\n"
+"\t\tBit 8 (0x100) will enable DP messages (displayport code)");
+module_param_named(debug, drm_debug, int, 0600);
+
void __drm_puts_coredump(struct drm_printer *p, const char *str)
{
struct drm_print_iterator *iterator = p->arg;
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 8976afe48c1c..cf13470810a5 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -778,8 +778,6 @@ struct drm_driver {
int dev_priv_size;
};
-extern unsigned int drm_debug;
-
int drm_dev_init(struct drm_device *dev,
struct drm_driver *driver,
struct device *parent);
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 12d4916254b4..e5c421abce48 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -34,6 +34,8 @@
#include
+extern unsigned int drm_debug;
+
/**
* DOC: print
*
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/9] drm/msm: use drm_debug_enabled() to check for debug categories
Allow better abstraction of the drm_debug global variable in the
future. No functional changes.
Cc: Rob Clark
Cc: Sean Paul
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 9e40f559c51f..00e3353f9aad 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -29,7 +29,7 @@
*/
#define DPU_DEBUG(fmt, ...)\
do { \
- if (unlikely(drm_debug & DRM_UT_KMS)) \
+ if (unlikely(drm_debug_enabled(DRM_UT_KMS))) \
DRM_DEBUG(fmt, ##__VA_ARGS__); \
else \
pr_debug(fmt, ##__VA_ARGS__); \
@@ -41,7 +41,7 @@
*/
#define DPU_DEBUG_DRIVER(fmt, ...) \
do { \
- if (unlikely(drm_debug & DRM_UT_DRIVER)) \
+ if (unlikely(drm_debug_enabled(DRM_UT_DRIVER)))\
DRM_ERROR(fmt, ##__VA_ARGS__); \
else \
pr_debug(fmt, ##__VA_ARGS__); \
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] drm/i2c/sil164: use drm_debug_enabled() to check for debug categories
Allow better abstraction of the drm_debug global variable in the
future. No functional changes.
Cc: Francisco Jerez
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i2c/sil164_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/sil164_drv.c b/drivers/gpu/drm/i2c/sil164_drv.c
index 8bcf0d199145..a839f78a4c8a 100644
--- a/drivers/gpu/drm/i2c/sil164_drv.c
+++ b/drivers/gpu/drm/i2c/sil164_drv.c
@@ -44,7 +44,7 @@ struct sil164_priv {
((struct sil164_priv *)to_encoder_slave(x)->slave_priv)
#define sil164_dbg(client, format, ...) do { \
- if (drm_debug & DRM_UT_KMS) \
+ if (drm_debug_enabled(DRM_UT_KMS)) \
dev_printk(KERN_DEBUG, >dev,\
"%s: " format, __func__, ## __VA_ARGS__); \
} while (0)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/9] drm/etnaviv: use drm_debug_enabled() to check for debug categories
Allow better abstraction of the drm_debug global variable in the
future. No functional changes.
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: etna...@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
index 7e4e2959bf4f..32d9fac587f9 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
@@ -326,7 +326,7 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
exec_state,
lockdep_assert_held(>lock);
- if (drm_debug & DRM_UT_DRIVER)
+ if (drm_debug_enabled(DRM_UT_DRIVER))
etnaviv_buffer_dump(gpu, buffer, 0, 0x50);
link_target = etnaviv_cmdbuf_get_va(cmdbuf,
@@ -459,13 +459,13 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
exec_state,
etnaviv_cmdbuf_get_va(buffer,
>mmu_context->cmdbuf_mapping)
+ buffer->user_size - 4);
- if (drm_debug & DRM_UT_DRIVER)
+ if (drm_debug_enabled(DRM_UT_DRIVER))
pr_info("stream link to 0x%08x @ 0x%08x %p\n",
return_target,
etnaviv_cmdbuf_get_va(cmdbuf,
>mmu_context->cmdbuf_mapping),
cmdbuf->vaddr);
- if (drm_debug & DRM_UT_DRIVER) {
+ if (drm_debug_enabled(DRM_UT_DRIVER)) {
print_hex_dump(KERN_INFO, "cmd ", DUMP_PREFIX_OFFSET, 16, 4,
cmdbuf->vaddr, cmdbuf->size, 0);
@@ -484,6 +484,6 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
exec_state,
VIV_FE_LINK_HEADER_PREFETCH(link_dwords),
link_target);
- if (drm_debug & DRM_UT_DRIVER)
+ if (drm_debug_enabled(DRM_UT_DRIVER))
etnaviv_buffer_dump(gpu, buffer, 0, 0x50);
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/9] drm/print: add and use drm_debug_enabled()
Hi all, just a little refactoring around drm_debug access to abstract it better. There shouldn't be any functional changes. I'd appreciate acks for merging the lot via drm-misc. If there are any objections to that, we'll need to postpone the last patch until everything has been merged and converted in drm-next. BR, Jani. Cc: Alex Deucher Cc: Christian König Cc: David (ChunMing) Zhou Cc: amd-...@lists.freedesktop.org Cc: Ben Skeggs Cc: nouv...@lists.freedesktop.org Cc: Rob Clark Cc: Sean Paul Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Cc: Francisco Jerez Cc: Lucas Stach Cc: Russell King Cc: Christian Gmeiner Cc: etna...@lists.freedesktop.org Jani Nikula (9): drm/print: move drm_debug variable to drm_print.[ch] drm/print: add drm_debug_enabled() drm/etnaviv: use drm_debug_enabled() to check for debug categories drm/i2c/sil164: use drm_debug_enabled() to check for debug categories drm/i915: use drm_debug_enabled() to check for debug categories drm/msm: use drm_debug_enabled() to check for debug categories drm/nouveau: use drm_debug_enabled() to check for debug categories drm/amdgpu: use drm_debug_enabled() to check for debug categories drm/print: rename drm_debug to __drm_debug to discourage use drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c | 4 ++-- drivers/gpu/drm/drm_atomic_uapi.c| 2 +- drivers/gpu/drm/drm_dp_mst_topology.c| 6 ++--- drivers/gpu/drm/drm_drv.c| 17 --- drivers/gpu/drm/drm_edid.c | 2 +- drivers/gpu/drm/drm_edid_load.c | 2 +- drivers/gpu/drm/drm_mipi_dbi.c | 4 ++-- drivers/gpu/drm/drm_print.c | 23 ++-- drivers/gpu/drm/drm_vblank.c | 6 ++--- drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 8 +++ drivers/gpu/drm/i2c/sil164_drv.c | 2 +- drivers/gpu/drm/i915/display/intel_display.c | 4 ++-- drivers/gpu/drm/i915/display/intel_dp.c | 2 +- drivers/gpu/drm/i915/i915_drv.c | 2 +- drivers/gpu/drm/i915/i915_gem.h | 2 +- drivers/gpu/drm/i915/i915_utils.c| 2 +- drivers/gpu/drm/i915/intel_pm.c | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 ++-- drivers/gpu/drm/nouveau/dispnv50/disp.h | 4 ++-- drivers/gpu/drm/nouveau/nouveau_drv.h| 4 ++-- include/drm/drm_drv.h| 2 -- include/drm/drm_print.h | 8 +++ 22 files changed, 60 insertions(+), 52 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/9] drm/amdgpu: use drm_debug_enabled() to check for debug categories
Allow better abstraction of the drm_debug global variable in the
future. No functional changes.
Cc: Alex Deucher
Cc: Christian König
Cc: David (ChunMing) Zhou
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
b/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
index 4a5951036927..5f17bd4899e2 100644
--- a/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
+++ b/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
@@ -234,7 +234,7 @@ static uint32_t smu_v11_0_i2c_transmit(struct i2c_adapter
*control,
DRM_DEBUG_DRIVER("I2C_Transmit(), address = %x, bytes = %d , data: ",
(uint16_t)address, numbytes);
- if (drm_debug & DRM_UT_DRIVER) {
+ if (drm_debug_enabled(DRM_UT_DRIVER)) {
print_hex_dump(KERN_INFO, "data: ", DUMP_PREFIX_NONE,
16, 1, data, numbytes, false);
}
@@ -388,7 +388,7 @@ static uint32_t smu_v11_0_i2c_receive(struct i2c_adapter
*control,
DRM_DEBUG_DRIVER("I2C_Receive(), address = %x, bytes = %d, data :",
(uint16_t)address, bytes_received);
- if (drm_debug & DRM_UT_DRIVER) {
+ if (drm_debug_enabled(DRM_UT_DRIVER)) {
print_hex_dump(KERN_INFO, "data: ", DUMP_PREFIX_NONE,
16, 1, data, bytes_received, false);
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/9] drm/i915: use drm_debug_enabled() to check for debug categories
Allow better abstraction of the drm_debug global variable in the
future. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_gem.h | 2 +-
drivers/gpu/drm/i915/i915_utils.c| 2 +-
drivers/gpu/drm/i915/intel_pm.c | 2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index a19f8c73f2e0..b0f688152bd9 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11956,7 +11956,7 @@ static void
intel_dump_infoframe(struct drm_i915_private *dev_priv,
const union hdmi_infoframe *frame)
{
- if ((drm_debug & DRM_UT_KMS) == 0)
+ if (!drm_debug_enabled(DRM_UT_KMS))
return;
hdmi_infoframe_log(KERN_DEBUG, dev_priv->drm.dev, frame);
@@ -12472,7 +12472,7 @@ pipe_config_infoframe_mismatch(struct drm_i915_private
*dev_priv,
const union hdmi_infoframe *b)
{
if (fastset) {
- if ((drm_debug & DRM_UT_KMS) == 0)
+ if (!drm_debug_enabled(DRM_UT_KMS))
return;
drm_dbg(DRM_UT_KMS, "fastset mismatch in %s infoframe", name);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index d09133a958e1..1281d52b0670 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1685,7 +1685,7 @@ static void intel_dp_print_rates(struct intel_dp
*intel_dp)
{
char str[128]; /* FIXME: too big for stack? */
- if ((drm_debug & DRM_UT_KMS) == 0)
+ if (!drm_debug_enabled(DRM_UT_KMS))
return;
snprintf_int_array(str, sizeof(str),
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0dfcb40f3162..46ed265d5e79 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1442,7 +1442,7 @@ static void i915_driver_unregister(struct
drm_i915_private *dev_priv)
static void i915_welcome_messages(struct drm_i915_private *dev_priv)
{
- if (drm_debug & DRM_UT_DRIVER) {
+ if (drm_debug_enabled(DRM_UT_DRIVER)) {
struct drm_printer p = drm_debug_printer("i915 device info:");
drm_printf(, "pciid=0x%04x rev=0x%02x platform=%s
(subplatform=0x%x) gen=%i\n",
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 167a7b56ed5b..a49b39e896b7 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -34,7 +34,7 @@ struct drm_i915_private;
#ifdef CONFIG_DRM_I915_DEBUG_GEM
-#define GEM_SHOW_DEBUG() (drm_debug & DRM_UT_DRIVER)
+#define GEM_SHOW_DEBUG() drm_debug_enabled(DRM_UT_DRIVER)
#define GEM_BUG_ON(condition) do { if (unlikely((condition))) {\
pr_err("%s:%d GEM_BUG_ON(%s)\n", \
diff --git a/drivers/gpu/drm/i915/i915_utils.c
b/drivers/gpu/drm/i915/i915_utils.c
index 16acdf7bdbe6..f66540e15793 100644
--- a/drivers/gpu/drm/i915/i915_utils.c
+++ b/drivers/gpu/drm/i915/i915_utils.c
@@ -23,7 +23,7 @@ __i915_printk(struct drm_i915_private *dev_priv, const char
*level,
struct va_format vaf;
va_list args;
- if (is_debug && !(drm_debug & DRM_UT_DRIVER))
+ if (is_debug && !drm_debug_enabled(DRM_UT_DRIVER))
return;
va_start(args, fmt);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d0ceb272551f..d173d2aa17fe 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5343,7 +5343,7 @@ skl_print_wm_changes(struct intel_atomic_state *state)
struct intel_crtc *crtc;
int i;
- if ((drm_debug & DRM_UT_KMS) == 0)
+ if (!drm_debug_enabled(DRM_UT_KMS))
return;
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/9] drm/print: add drm_debug_enabled()
Add helper to check if a drm debug category is enabled. Convert drm core
to use it. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
drivers/gpu/drm/drm_dp_mst_topology.c | 6 +++---
drivers/gpu/drm/drm_edid.c| 2 +-
drivers/gpu/drm/drm_edid_load.c | 2 +-
drivers/gpu/drm/drm_mipi_dbi.c| 4 ++--
drivers/gpu/drm/drm_print.c | 4 ++--
drivers/gpu/drm/drm_vblank.c | 6 +++---
include/drm/drm_print.h | 5 +
8 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 5a5b42db6f2a..6576cd997cbd 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1406,7 +1406,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
} else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
ret = drm_atomic_nonblocking_commit(state);
} else {
- if (unlikely(drm_debug & DRM_UT_STATE))
+ if (unlikely(drm_debug_enabled(DRM_UT_STATE)))
drm_atomic_print_state(state);
ret = drm_atomic_commit(state);
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 97216099a718..f47c5b6b51f7 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1180,7 +1180,7 @@ static int drm_dp_mst_wait_tx_reply(struct
drm_dp_mst_branch *mstb,
}
}
out:
- if (unlikely(ret == -EIO && drm_debug & DRM_UT_DP)) {
+ if (unlikely(ret == -EIO && drm_debug_enabled(DRM_UT_DP))) {
struct drm_printer p = drm_debug_printer(DBG_PREFIX);
drm_dp_mst_dump_sideband_msg_tx(, txmsg);
@@ -2321,7 +2321,7 @@ static int process_single_tx_qlock(struct
drm_dp_mst_topology_mgr *mgr,
idx += tosend + 1;
ret = drm_dp_send_sideband_msg(mgr, up, chunk, idx);
- if (unlikely(ret && drm_debug & DRM_UT_DP)) {
+ if (unlikely(ret && drm_debug_enabled(DRM_UT_DP))) {
struct drm_printer p = drm_debug_printer(DBG_PREFIX);
drm_printf(, "sideband msg failed to send\n");
@@ -2388,7 +2388,7 @@ static void drm_dp_queue_down_tx(struct
drm_dp_mst_topology_mgr *mgr,
mutex_lock(>qlock);
list_add_tail(>next, >tx_msg_downq);
- if (unlikely(drm_debug & DRM_UT_DP)) {
+ if (unlikely(drm_debug_enabled(DRM_UT_DP))) {
struct drm_printer p = drm_debug_printer(DBG_PREFIX);
drm_dp_mst_dump_sideband_msg_tx(, txmsg);
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 12c783f4d956..58dad4d24cd4 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1551,7 +1551,7 @@ static void connector_bad_edid(struct drm_connector
*connector,
{
int i;
- if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
+ if (connector->bad_edid_counter++ && !drm_debug_enabled(DRM_UT_KMS))
return;
dev_warn(connector->dev->dev,
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index d38b3b255926..37d8ba3ddb46 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -175,7 +175,7 @@ static void *edid_load(struct drm_connector *connector,
const char *name,
u8 *edid;
int fwsize, builtin;
int i, valid_extensions = 0;
- bool print_bad_edid = !connector->bad_edid_counter || (drm_debug &
DRM_UT_KMS);
+ bool print_bad_edid = !connector->bad_edid_counter ||
drm_debug_enabled(DRM_UT_KMS);
builtin = match_string(generic_edid_name, GENERIC_EDIDS, name);
if (builtin >= 0) {
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index f8154316a3b0..ccfb5b33c5e3 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -783,7 +783,7 @@ static int mipi_dbi_spi1e_transfer(struct mipi_dbi *dbi,
int dc,
int i, ret;
u8 *dst;
- if (drm_debug & DRM_UT_DRIVER)
+ if (drm_debug_enabled(DRM_UT_DRIVER))
pr_debug("[drm:%s] dc=%d, max_chunk=%zu, transfers:\n",
__func__, dc, max_chunk);
@@ -907,7 +907,7 @@ static int mipi_dbi_spi1_transfer(struct mipi_dbi *dbi, int
dc,
max_chunk = dbi->tx_buf9_len;
dst16 = dbi->tx_buf9;
- if (drm_debug & DRM_UT_DRIVER)
+ if (drm_debug_enabled(DRM_UT_DRIVER))
pr_debug("[drm:%s] dc=%d, max_chunk=%zu, transfers:\n",
__func__, dc, max_chunk);
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index c9b57012d412..a7c89ec5ff26 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -264,7 +264,7 @@ void drm_dev_dbg(const struct device *dev, unsigned int
category,
struct va_format vaf;
[PATCH 7/9] drm/nouveau: use drm_debug_enabled() to check for debug categories
Allow better abstraction of the drm_debug global variable in the
future. No functional changes.
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/nouveau/dispnv50/disp.h | 4 ++--
drivers/gpu/drm/nouveau/nouveau_drv.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.h
b/drivers/gpu/drm/nouveau/dispnv50/disp.h
index 7c41b0599d1a..c0a79531b087 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.h
@@ -78,14 +78,14 @@ void evo_kick(u32 *, struct nv50_dmac *);
#define evo_mthd(p, m, s) do { \
const u32 _m = (m), _s = (s); \
- if (drm_debug & DRM_UT_KMS) \
+ if (drm_debug_enabled(DRM_UT_KMS)) \
pr_err("%04x %d %s\n", _m, _s, __func__); \
*((p)++) = ((_s << 18) | _m); \
} while(0)
#define evo_data(p, d) do {\
const u32 _d = (d); \
- if (drm_debug & DRM_UT_KMS) \
+ if (drm_debug_enabled(DRM_UT_KMS)) \
pr_err("\t%08x\n", _d); \
*((p)++) = _d; \
} while(0)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 70f34cacc552..16283d1e51aa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -248,11 +248,11 @@ void nouveau_drm_device_remove(struct drm_device *dev);
#define NV_INFO(drm,f,a...) NV_PRINTK(info, &(drm)->client, f, ##a)
#define NV_DEBUG(drm,f,a...) do {
\
- if (unlikely(drm_debug & DRM_UT_DRIVER)) \
+ if (unlikely(drm_debug_enabled(DRM_UT_DRIVER)))\
NV_PRINTK(info, &(drm)->client, f, ##a); \
} while(0)
#define NV_ATOMIC(drm,f,a...) do {
\
- if (unlikely(drm_debug & DRM_UT_ATOMIC)) \
+ if (unlikely(drm_debug_enabled(DRM_UT_ATOMIC)))\
NV_PRINTK(info, &(drm)->client, f, ##a); \
} while(0)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/panfrost: Extend the bo_wait() ioctl
So we can choose to wait for all BO users, or just for writers.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 8 ++--
include/uapi/drm/panfrost_drm.h | 4
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 08082fd557c3..6a94aea2147f 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -322,16 +322,20 @@ panfrost_ioctl_wait_bo(struct drm_device *dev, void *data,
struct drm_panfrost_wait_bo *args = data;
struct drm_gem_object *gem_obj;
unsigned long timeout = drm_timeout_abs_to_jiffies(args->timeout_ns);
+ bool wait_all = !(args->flags & PANFROST_WAIT_BO_WRITERS);
if (args->pad)
return -EINVAL;
+ if (args->flags & ~PANFROST_WAIT_BO_WRITERS)
+ return -EINVAL;
+
gem_obj = drm_gem_object_lookup(file_priv, args->handle);
if (!gem_obj)
return -ENOENT;
- ret = dma_resv_wait_timeout_rcu(gem_obj->resv, true,
- true, timeout);
+ ret = dma_resv_wait_timeout_rcu(gem_obj->resv, wait_all,
+ true, timeout);
if (!ret)
ret = timeout ? -ETIMEDOUT : -EBUSY;
diff --git a/include/uapi/drm/panfrost_drm.h b/include/uapi/drm/panfrost_drm.h
index 029c6ae1b1f0..ac4facbcee47 100644
--- a/include/uapi/drm/panfrost_drm.h
+++ b/include/uapi/drm/panfrost_drm.h
@@ -111,6 +111,9 @@ struct drm_panfrost_submit {
__u32 pad;
};
+#define PANFROST_WAIT_ALL_BO_USERS (0 << 0)
+#define PANFROST_WAIT_BO_WRITERS (1 << 0)
+
/**
* struct drm_panfrost_wait_bo - ioctl argument for waiting for
* completion of the last DRM_PANFROST_SUBMIT on a BO.
@@ -123,6 +126,7 @@ struct drm_panfrost_wait_bo {
__u32 handle;
__u32 pad;
__s64 timeout_ns; /* absolute */
+ __u64 flags;
};
#define PANFROST_BO_NOEXEC 1
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/panfrost: Allow passing extra information about BOs used by a job
The READ/WRITE flags are particularly useful if we want to avoid
serialization of jobs that read from the same BO but never write to it.
The NO_IMPLICIT_FENCE might be useful when the user knows the BO is
shared but jobs are using different portions of the buffer.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 72 +--
drivers/gpu/drm/panfrost/panfrost_job.c | 164 +++-
drivers/gpu/drm/panfrost/panfrost_job.h | 11 +-
include/uapi/drm/panfrost_drm.h | 41 ++
4 files changed, 247 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index d74442d71048..08082fd557c3 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -119,20 +119,76 @@ panfrost_lookup_bos(struct drm_device *dev,
struct drm_panfrost_submit *args,
struct panfrost_job *job)
{
- job->bo_count = args->bo_handle_count;
+ struct drm_panfrost_submit_bo *bo_descs = NULL;
+ u32 *handles = NULL;
+ u32 i, bo_count;
+ int ret = 0;
- if (!job->bo_count)
+ bo_count = args->bo_desc_count ?
+ args->bo_desc_count : args->bo_handle_count;
+ if (!bo_count)
return 0;
- job->implicit_fences = kvmalloc_array(job->bo_count,
- sizeof(struct dma_fence *),
+ job->bos = kvmalloc_array(bo_count, sizeof(*job->bos),
GFP_KERNEL | __GFP_ZERO);
- if (!job->implicit_fences)
+ if (!job->bos)
return -ENOMEM;
- return drm_gem_objects_lookup(file_priv,
- (void __user
*)(uintptr_t)args->bo_handles,
- job->bo_count, >bos);
+ job->bo_count = bo_count;
+ bo_descs = kvmalloc_array(bo_count, sizeof(*bo_descs),
+ GFP_KERNEL | __GFP_ZERO);
+ if (!bo_descs) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ if (!args->bo_desc_count) {
+ handles = kvmalloc_array(bo_count, sizeof(*handles),
+GFP_KERNEL);
+ if (!handles) {
+ ret =-ENOMEM;
+ goto out;
+ }
+
+ if (copy_from_user(handles,
+ (void __user *)(uintptr_t)args->bo_handles,
+ job->bo_count * sizeof(*handles))) {
+ ret = -EFAULT;
+ goto out;
+ }
+
+ for (i = 0; i < job->bo_count; i++) {
+ bo_descs[i].handle = handles[i];
+ bo_descs[i].flags = PANFROST_SUBMIT_BO_WRITE |
+ PANFROST_SUBMIT_BO_READ;
+ }
+ } else if (copy_from_user(bo_descs,
+ (void __user *)(uintptr_t)args->bo_descs,
+ job->bo_count * sizeof(*bo_descs))) {
+ ret = -EFAULT;
+ goto out;
+ }
+
+ for (i = 0; i < job->bo_count; i++) {
+ if ((bo_descs[i].flags & ~PANFROST_SUBMIT_BO_VALID_FLAGS) ||
+!(bo_descs[i].flags & PANFROST_SUBMIT_BO_RW)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ job->bos[i].flags = bo_descs[i].flags;
+ job->bos[i].obj = drm_gem_object_lookup(file_priv,
+ bo_descs[i].handle);
+ if (!job->bos[i].obj) {
+ ret = -ENOENT;
+ goto out;
+ }
+ }
+
+out:
+ kvfree(handles);
+ kvfree(bo_descs);
+ return ret;
}
/**
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 05c85f45a0de..e4b74fde9339 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -193,24 +193,116 @@ static void panfrost_job_hw_submit(struct panfrost_job
*job, int js)
pm_runtime_put_autosuspend(pfdev->dev);
}
-static void panfrost_acquire_object_fences(struct drm_gem_object **bos,
- int bo_count,
- struct dma_fence **implicit_fences)
+static int panfrost_acquire_object_fences(struct panfrost_job *job)
{
- int i;
+ int i, ret;
- for (i = 0; i < bo_count; i++)
- implicit_fences[i] = dma_resv_get_excl_rcu(bos[i]->resv);
+ for (i = 0; i < job->bo_count; i++) {
+ struct panfrost_job_bo_desc *bo = >bos[i];
+ struct dma_resv *robj = bo->obj->resv;
+
+ if (!(job->bos[i].flags & PANFROST_SUBMIT_BO_WRITE)) {
+
Re: [PATCH] drm/ttm: Restore ttm prefaulting
Am 13.09.19 um 13:07 schrieb Thomas Hellström (VMware):
> On 9/13/19 12:53 PM, Koenig, Christian wrote:
>> Am 12.09.19 um 20:38 schrieb Thomas Hellström (VMware):
>>> From: Thomas Hellstrom
>>>
>>> Commit 4daa4fba3a38 ("gpu: drm: ttm: Adding new return type
>>> vm_fault_t")
>>> broke TTM prefaulting. Since vmf_insert_mixed() typically always
>>> returns
>>> VM_FAULT_NOPAGE, prefaulting stops after the second PTE.
>>>
>>> Restore (almost) the original behaviour. Unfortunately we can no longer
>>> with the new vm_fault_t return type determine whether a prefaulting
>>> PTE insertion hit an already populated PTE, and terminate the insertion
>>> loop. Instead we continue with the pre-determined number of prefaults.
>>>
>>> Fixes: 4daa4fba3a38 ("gpu: drm: ttm: Adding new return type
>>> vm_fault_t")
>>> Cc: Souptick Joarder
>>> Cc: Christian König
>>> Signed-off-by: Thomas Hellstrom
>> Reviewed-by: Christian König
>>
>> Going to pick that up when Alex rebases our upstream branch.
>>
>> Christian.
>>
>>> ---
>>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 16 +++-
>>> 1 file changed, 7 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>> index 5a580adeb9d1..aa18e8a53727 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>> @@ -290,15 +290,13 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct
>>> vm_fault *vmf,
>>> else
>>> ret = vmf_insert_pfn(, address, pfn);
>>> - /*
>>> - * Somebody beat us to this PTE or prefaulting to
>>> - * an already populated PTE, or prefaulting error.
>>> - */
>>> -
>>> - if (unlikely((ret == VM_FAULT_NOPAGE && i > 0)))
>>> - break;
>>> - else if (unlikely(ret & VM_FAULT_ERROR))
>>> - goto out_io_unlock;
>>> + /* Never error on prefaulted PTEs */
>>> + if (unlikely((ret & VM_FAULT_ERROR))) {
>>> + if (i == 0)
>>> + goto out_io_unlock;
>>> + else
>
> We could perhaps skip that else. Let me know if you want me to respin.
I would rather like to keep it, when something goes wrong we should
really stop faulting in more.
Christian.
>
> /Thomas
>
>
>
>>> + break;
>>> + }
>>> address += PAGE_SIZE;
>>> if (unlikely(++page_offset >= page_last))
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/7] mm: Add write-protect and clean utilities for address space ranges
On 9/13/19 11:32 AM, Thomas Hellström (VMware) wrote:
From: Thomas Hellstrom
Add two utilities to a) write-protect and b) clean all ptes pointing into
a range of an address space.
The utilities are intended to aid in tracking dirty pages (either
driver-allocated system memory or pci device memory).
The write-protect utility should be used in conjunction with
page_mkwrite() and pfn_mkwrite() to trigger write page-faults on page
accesses. Typically one would want to use this on sparse accesses into
large memory regions. The clean utility should be used to utilize
hardware dirtying functionality and avoid the overhead of page-faults,
typically on large accesses into small memory regions.
The added file "as_dirty_helpers.c" is initially listed as maintained by
VMware under our DRM driver. If somebody would like it elsewhere,
that's of course no problem.
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Minchan Kim
Cc: Michal Hocko
Cc: Huang Ying
Cc: Souptick Joarder
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Thomas Hellstrom
Reviewed-by: Ralph Campbell #v1
---
MAINTAINERS | 1 +
include/linux/mm.h| 13 +-
mm/Kconfig| 3 +
mm/Makefile | 1 +
mm/as_dirty_helpers.c | 392 ++
5 files changed, 409 insertions(+), 1 deletion(-)
create mode 100644 mm/as_dirty_helpers.c
diff --git a/MAINTAINERS b/MAINTAINERS
index c2d975da561f..b596c7cf4a85 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5287,6 +5287,7 @@ T:git git://people.freedesktop.org/~thomash/linux
S:Supported
F:drivers/gpu/drm/vmwgfx/
F:include/uapi/drm/vmwgfx_drm.h
+F: mm/as_dirty_helpers.c
DRM DRIVERS
M:David Airlie
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0334ca97c584..27ff341ecbdc 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2657,7 +2657,6 @@ typedef int (*pte_fn_t)(pte_t *pte, unsigned long addr,
void *data);
extern int apply_to_page_range(struct mm_struct *mm, unsigned long address,
unsigned long size, pte_fn_t fn, void *data);
-
#ifdef CONFIG_PAGE_POISONING
extern bool page_poisoning_enabled(void);
extern void kernel_poison_pages(struct page *page, int numpages, int enable);
@@ -2891,5 +2890,17 @@ void __init setup_nr_node_ids(void);
static inline void setup_nr_node_ids(void) {}
#endif
+#ifdef CONFIG_AS_DIRTY_HELPERS
+unsigned long apply_as_clean(struct address_space *mapping,
+pgoff_t first_index, pgoff_t nr,
+pgoff_t bitmap_pgoff,
+unsigned long *bitmap,
+pgoff_t *start,
+pgoff_t *end);
+
+unsigned long apply_as_wrprotect(struct address_space *mapping,
+pgoff_t first_index, pgoff_t nr);
+#endif
+
#endif /* __KERNEL__ */
#endif /* _LINUX_MM_H */
diff --git a/mm/Kconfig b/mm/Kconfig
index 56cec636a1fc..594350e9d78e 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -736,4 +736,7 @@ config ARCH_HAS_PTE_SPECIAL
config ARCH_HAS_HUGEPD
bool
+config AS_DIRTY_HELPERS
+bool
+
endmenu
diff --git a/mm/Makefile b/mm/Makefile
index d0b295c3b764..4086f1eefbc6 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -105,3 +105,4 @@ obj-$(CONFIG_PERCPU_STATS) += percpu-stats.o
obj-$(CONFIG_ZONE_DEVICE) += memremap.o
obj-$(CONFIG_HMM_MIRROR) += hmm.o
obj-$(CONFIG_MEMFD_CREATE) += memfd.o
+obj-$(CONFIG_AS_DIRTY_HELPERS) += as_dirty_helpers.o
diff --git a/mm/as_dirty_helpers.c b/mm/as_dirty_helpers.c
new file mode 100644
index ..3be06fe8f1d2
--- /dev/null
+++ b/mm/as_dirty_helpers.c
@@ -0,0 +1,392 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * struct as_walk - Argument to as_pte_fn_t
Argument to struct as_walk_ops callbacks
+ * @vma: Pointer to the struct vmw_area_struct currently being walked.
+ *
+ * Embeddable argument to struct as__pte_fn_t
Here as well.
+ */
+struct as_walk {
+ struct vm_area_struct *vma;
+};
+
+/**
+ * struct as_walk_ops - Callbacks for entries of various page table levels.
+ * extend for additional level support.
+ */
+struct as_walk_ops {
+ /**
+* pte-entry: Callback for PTEs
+* @pte: Pointer to the PTE.
+* @addr: Virtual address.
+* @asw: Struct as_walk argument for the walk. Embed for additional
+* data.
+*/
+ void (*const pte_entry) (pte_t *pte, unsigned long addr,
+struct as_walk *asw);
+};
Re: [PATCH] drm/ttm: Restore ttm prefaulting
On 9/13/19 12:53 PM, Koenig, Christian wrote:
Am 12.09.19 um 20:38 schrieb Thomas Hellström (VMware):
From: Thomas Hellstrom
Commit 4daa4fba3a38 ("gpu: drm: ttm: Adding new return type vm_fault_t")
broke TTM prefaulting. Since vmf_insert_mixed() typically always returns
VM_FAULT_NOPAGE, prefaulting stops after the second PTE.
Restore (almost) the original behaviour. Unfortunately we can no longer
with the new vm_fault_t return type determine whether a prefaulting
PTE insertion hit an already populated PTE, and terminate the insertion
loop. Instead we continue with the pre-determined number of prefaults.
Fixes: 4daa4fba3a38 ("gpu: drm: ttm: Adding new return type vm_fault_t")
Cc: Souptick Joarder
Cc: Christian König
Signed-off-by: Thomas Hellstrom
Reviewed-by: Christian König
Going to pick that up when Alex rebases our upstream branch.
Christian.
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 5a580adeb9d1..aa18e8a53727 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -290,15 +290,13 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
else
ret = vmf_insert_pfn(, address, pfn);
- /*
-* Somebody beat us to this PTE or prefaulting to
-* an already populated PTE, or prefaulting error.
-*/
-
- if (unlikely((ret == VM_FAULT_NOPAGE && i > 0)))
- break;
- else if (unlikely(ret & VM_FAULT_ERROR))
- goto out_io_unlock;
+ /* Never error on prefaulted PTEs */
+ if (unlikely((ret & VM_FAULT_ERROR))) {
+ if (i == 0)
+ goto out_io_unlock;
+ else
We could perhaps skip that else. Let me know if you want me to respin.
/Thomas
+ break;
+ }
address += PAGE_SIZE;
if (unlikely(++page_offset >= page_last))
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/virtio: Export resource handles via DMA-buf API
Hi, > > No. DMA master address space in virtual machines is pretty much the > > same it is on physical machines. So, on x86 without iommu, identical > > to (guest) physical address space. You can't re-define it like that. > > That's not true. Even on x86 without iommu the DMA address space can > be different from the physical address space. On a standard pc (like the ones emulated by qemu) that is the case. It's different on !x86, it also changes with a iommu being present. But that is not the main point here. The point is the dma master address already has a definition and you can't simply change that. > That could be still just > a simple addition/subtraction by constant, but still, the two are > explicitly defined without any guarantees about a simple mapping > between one or another existing. Sure. > "A CPU cannot reference a dma_addr_t directly because there may be > translation between its physical > address space and the DMA address space." Also note that dma address space is device-specific. In case a iommu is present in the system you can have *multiple* dma address spaces, separating (groups of) devices from each other. So passing a dma address from one device to another isn't going to work. > > > However, we could as well introduce a separate DMA address > > > space if resource handles are not the right way to refer to the memory > > > from other virtio devices. > > > > s/other virtio devices/other devices/ > > > > dma-bufs are for buffer sharing between devices, not limited to virtio. > > You can't re-define that in some virtio-specific way. > > > > We don't need to limit this to virtio devices only. In fact I actually > foresee this having a use case with the emulated USB host controller, > which isn't a virtio device. What exactly? > That said, I deliberately referred to virtio to keep the scope of the > problem in control. If there is a solution that could work without > such assumption, I'm more than open to discuss it, of course. But it might lead to taking virtio-specific (or virtualization-specific) shortcuts which will hurt in the long run ... > As per my understanding of the DMA address, anything that lets the DMA > master access the target memory would qualify and there would be no > need for an IOMMU in between. Yes. But that DMA address is already defined by the platform, you can't freely re-define it. Well, you sort-of can when you design your own virtual iommu for qemu. But even then you can't just pass around magic cookies masqueraded as dma address. You have to make sure they actually form an address space, without buffers overlapping, ... > Exactly. The very specific first scenario that we want to start with > is allocating host memory through virtio-gpu and using that memory > both as output of a video decoder and as input (texture) to Virgil3D. > The memory needs to be specifically allocated by the host as only the > host can know the requirements for memory allocation of the video > decode accelerator hardware. So you probably have some virtio-video-decoder. You allocate a gpu buffer, export it as dma-buf, import it into the decoder, then let the video decoder render to it. Right? Using dmabufs makes sense for sure. But we need an separate field in struct dma_buf for an (optional) host dmabuf identifier, we can't just hijack the dma address. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: Restore ttm prefaulting
Am 12.09.19 um 20:38 schrieb Thomas Hellström (VMware):
> From: Thomas Hellstrom
>
> Commit 4daa4fba3a38 ("gpu: drm: ttm: Adding new return type vm_fault_t")
> broke TTM prefaulting. Since vmf_insert_mixed() typically always returns
> VM_FAULT_NOPAGE, prefaulting stops after the second PTE.
>
> Restore (almost) the original behaviour. Unfortunately we can no longer
> with the new vm_fault_t return type determine whether a prefaulting
> PTE insertion hit an already populated PTE, and terminate the insertion
> loop. Instead we continue with the pre-determined number of prefaults.
>
> Fixes: 4daa4fba3a38 ("gpu: drm: ttm: Adding new return type vm_fault_t")
> Cc: Souptick Joarder
> Cc: Christian König
> Signed-off-by: Thomas Hellstrom
Reviewed-by: Christian König
Going to pick that up when Alex rebases our upstream branch.
Christian.
> ---
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 16 +++-
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 5a580adeb9d1..aa18e8a53727 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -290,15 +290,13 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault
> *vmf,
> else
> ret = vmf_insert_pfn(, address, pfn);
>
> - /*
> - * Somebody beat us to this PTE or prefaulting to
> - * an already populated PTE, or prefaulting error.
> - */
> -
> - if (unlikely((ret == VM_FAULT_NOPAGE && i > 0)))
> - break;
> - else if (unlikely(ret & VM_FAULT_ERROR))
> - goto out_io_unlock;
> + /* Never error on prefaulted PTEs */
> + if (unlikely((ret & VM_FAULT_ERROR))) {
> + if (i == 0)
> + goto out_io_unlock;
> + else
> + break;
> + }
>
> address += PAGE_SIZE;
> if (unlikely(++page_offset >= page_last))
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111682] use-after-free in amdgpu_vm_update_directories
https://bugs.freedesktop.org/show_bug.cgi?id=111682 Bug ID: 111682 Summary: use-after-free in amdgpu_vm_update_directories Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: not set Priority: not set Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: pierre-eric.pelloux-pra...@amd.com Created attachment 145345 --> https://bugs.freedesktop.org/attachment.cgi?id=145345=edit dmesg output When using amdgpu.vm_update_mode=3 the following error appears after some time (ranging from a few minutes to a few hours): BUG: KASAN: use-after-free in amdgpu_vm_update_directories I attached the relevant dmesg part. Notes: - happens on Navi10 and gfx9 (probably also on other cards but I didn't try) - reproduced on 865b4ca43816e113996c3be571d4998b6daf5f1 and 20d6b9c3b7f40ec427af912d140f2be0de098d2d -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
