RE: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()
From: David Laight > Sent: 16 January 2020 14:41 > > I'll do some measurements later this afternoon. > > This is an Ivy bridge cpu, so clflush (not clflushopt). > With a cond_resched for every page I get: > (Note these calls are every 10 seconds) For comparison some times booted with the original drm.ko 1) # 3125.116 us | drm_clflush_sg [drm](); 0) # 3181.705 us | drm_clflush_sg [drm](); 1) # 3108.863 us | drm_clflush_sg [drm](); 1) # 3051.926 us | drm_clflush_sg [drm](); 2) # 3088.468 us | drm_clflush_sg [drm](); 2) # 3012.729 us | drm_clflush_sg [drm](); 2) # 3191.268 us | drm_clflush_sg [drm](); 3) # 3044.294 us | drm_clflush_sg [drm](); 0) # 3163.916 us | drm_clflush_sg [drm](); 2) # 3029.307 us | drm_clflush_sg [drm](); 2) # 3116.360 us | drm_clflush_sg [drm](); 2) # 3031.620 us | drm_clflush_sg [drm](); 0) # 3349.706 us | drm_clflush_sg [drm](); Probably nothing really significant. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] thermal: devfreq_cooling: Refactor code and switch to use Energy Model
From: Lukasz Luba
The overhauled Energy Model (EM) framework support also devfreq devices.
The unified API interface of the EM can be used in the thermal subsystem to
not duplicate code. The power table now is taken from EM structure and
there is no need to maintain calculation for it locally. In case when the
EM is not provided by the device a simple interface for cooling device is
used.
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 397 +++---
include/linux/devfreq_cooling.h | 17 --
include/trace/events/thermal.h| 19 +-
3 files changed, 149 insertions(+), 284 deletions(-)
diff --git a/drivers/thermal/devfreq_cooling.c
b/drivers/thermal/devfreq_cooling.c
index ef59256887ff..202afe4de49d 100644
--- a/drivers/thermal/devfreq_cooling.c
+++ b/drivers/thermal/devfreq_cooling.c
@@ -1,17 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* devfreq_cooling: Thermal cooling device implementation for devices using
* devfreq
*
- * Copyright (C) 2014-2015 ARM Limited
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed "as is" WITHOUT ANY WARRANTY of any
- * kind, whether express or implied; without even the implied warranty
- * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
+ * Copyright (C) 2014-2020 ARM Limited
*
* TODO:
*- If OPPs are added or removed after devfreq cooling has
@@ -20,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -39,32 +32,26 @@ static DEFINE_IDA(devfreq_ida);
* @cdev: Pointer to associated thermal cooling device.
* @devfreq: Pointer to associated devfreq device.
* @cooling_state: Current cooling state.
- * @power_table: Pointer to table with maximum power draw for each
- * cooling state. State is the index into the table, and
- * the power is in mW.
- * @freq_table:Pointer to a table with the frequencies sorted in
descending
- * order. You can index the table by cooling device state
- * @freq_table_size: Size of the @freq_table and @power_table
- * @power_ops: Pointer to devfreq_cooling_power, used to generate the
- * @power_table.
+ * @max_level: It is the last index, that is, one less than the number of the
+ * OPPs
+ * @power_ops: Pointer to devfreq_cooling_power, a more precised model.
* @res_util: Resource utilization scaling factor for the power.
* It is multiplied by 100 to minimize the error. It is used
* for estimation of the power budget instead of using
* 'utilization' (which is 'busy_time / 'total_time').
- * The 'res_util' range is from 100 to (power_table[state] * 100)
- * for the corresponding 'state'.
+ * The 'res_util' range is from 100 to power * 100 for the
+ * corresponding 'state'.
+ * @em:Energy Model which represents the associated Devfreq
device
*/
struct devfreq_cooling_device {
int id;
struct thermal_cooling_device *cdev;
struct devfreq *devfreq;
unsigned long cooling_state;
- u32 *power_table;
- u32 *freq_table;
- size_t freq_table_size;
+ size_t max_level;
struct devfreq_cooling_power *power_ops;
u32 res_util;
- int capped_state;
+ struct em_perf_domain *em;
};
/**
@@ -78,16 +65,40 @@ struct devfreq_cooling_device {
static int partition_enable_opps(struct devfreq_cooling_device *dfc,
unsigned long cdev_state)
{
- int i;
struct device *dev = dfc->devfreq->dev.parent;
+ unsigned long freq = ULONG_MAX;
+ int i;
- for (i = 0; i < dfc->freq_table_size; i++) {
+ for (i = 0; i <= dfc->max_level; i++, freq--) {
struct dev_pm_opp *opp;
- int ret = 0;
- unsigned int freq = dfc->freq_table[i];
- bool want_enable = i >= cdev_state ? true : false;
-
- opp = dev_pm_opp_find_freq_exact(dev, freq, !want_enable);
+ bool want_enable;
+ int ret;
+
+ want_enable = (i >= cdev_state);
+
+ /*
+* Go through the OPP table picking up frequencies from
+* fastest to slowest and disable these which are
+* above allowed cooling state.
+*/
+ if (dfc->em) {
+ freq = dfc->em->table[dfc->max_level - i].frequency;
+ /* Frequency in EM is in kHz */
+ freq *= 1000;
+ /*
+* Take only these OPPs for which the transition
+* 'e
[PATCH 2/4] OPP: change parameter to device pointer in dev_pm_opp_of_register_em()
From: Lukasz Luba Drop the CPU specific interface with cpumask and switch to struct device. The Energy Model framework supports both: CPUs and devfreq devices. The new interface provides easy way to create a Energy Model (EM), which then might be used in i.e. thermal subsystem. Signed-off-by: Lukasz Luba --- drivers/cpufreq/cpufreq-dt.c | 2 +- drivers/cpufreq/imx6q-cpufreq.c| 2 +- drivers/cpufreq/mediatek-cpufreq.c | 2 +- drivers/cpufreq/omap-cpufreq.c | 2 +- drivers/cpufreq/qcom-cpufreq-hw.c | 2 +- drivers/cpufreq/scpi-cpufreq.c | 2 +- drivers/opp/of.c | 38 +++--- include/linux/pm_opp.h | 13 -- 8 files changed, 36 insertions(+), 27 deletions(-) diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c index d2b5f062a07b..a0db2c4c922a 100644 --- a/drivers/cpufreq/cpufreq-dt.c +++ b/drivers/cpufreq/cpufreq-dt.c @@ -275,7 +275,7 @@ static int cpufreq_init(struct cpufreq_policy *policy) policy->cpuinfo.transition_latency = transition_latency; policy->dvfs_possible_from_any_cpu = true; - dev_pm_opp_of_register_em(policy->cpus); + dev_pm_opp_of_register_em(cpu_dev); return 0; diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c index 648a09a1778a..e89a277ea385 100644 --- a/drivers/cpufreq/imx6q-cpufreq.c +++ b/drivers/cpufreq/imx6q-cpufreq.c @@ -193,7 +193,7 @@ static int imx6q_cpufreq_init(struct cpufreq_policy *policy) policy->clk = clks[ARM].clk; cpufreq_generic_init(policy, freq_table, transition_latency); policy->suspend_freq = max_freq; - dev_pm_opp_of_register_em(policy->cpus); + dev_pm_opp_of_register_em(cpu_dev); return 0; } diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c index 0c98dd08273d..946415f52c50 100644 --- a/drivers/cpufreq/mediatek-cpufreq.c +++ b/drivers/cpufreq/mediatek-cpufreq.c @@ -448,7 +448,7 @@ static int mtk_cpufreq_init(struct cpufreq_policy *policy) policy->driver_data = info; policy->clk = info->cpu_clk; - dev_pm_opp_of_register_em(policy->cpus); + dev_pm_opp_of_register_em(info->cpu_dev); return 0; } diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c index 8d14b42a8c6f..d606b6f9296b 100644 --- a/drivers/cpufreq/omap-cpufreq.c +++ b/drivers/cpufreq/omap-cpufreq.c @@ -131,7 +131,7 @@ static int omap_cpu_init(struct cpufreq_policy *policy) /* FIXME: what's the actual transition time? */ cpufreq_generic_init(policy, freq_table, 300 * 1000); - dev_pm_opp_of_register_em(policy->cpus); + dev_pm_opp_of_register_em(mpu_dev); return 0; } diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c index fc92a8842e25..3810c2aed7a9 100644 --- a/drivers/cpufreq/qcom-cpufreq-hw.c +++ b/drivers/cpufreq/qcom-cpufreq-hw.c @@ -238,7 +238,7 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy) goto error; } - dev_pm_opp_of_register_em(policy->cpus); + dev_pm_opp_of_register_em(cpu_dev); policy->fast_switch_possible = true; diff --git a/drivers/cpufreq/scpi-cpufreq.c b/drivers/cpufreq/scpi-cpufreq.c index 20d1f85d5f5a..8e7da2098b73 100644 --- a/drivers/cpufreq/scpi-cpufreq.c +++ b/drivers/cpufreq/scpi-cpufreq.c @@ -167,7 +167,7 @@ static int scpi_cpufreq_init(struct cpufreq_policy *policy) policy->fast_switch_possible = false; - dev_pm_opp_of_register_em(policy->cpus); + dev_pm_opp_of_register_em(cpu_dev); return 0; diff --git a/drivers/opp/of.c b/drivers/opp/of.c index eb2c599ca434..32f522028327 100644 --- a/drivers/opp/of.c +++ b/drivers/opp/of.c @@ -1031,18 +1031,18 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_get_of_node); /* * Callback function provided to the Energy Model framework upon registration. - * This computes the power estimated by @CPU at @kHz if it is the frequency + * This computes the power estimated by @dev at @kHz if it is the frequency * of an existing OPP, or at the frequency of the first OPP above @kHz otherwise * (see dev_pm_opp_find_freq_ceil()). This function updates @kHz to the ceiled * frequency and @mW to the associated power. The power is estimated as - * P = C * V^2 * f with C being the CPU's capacitance and V and f respectively - * the voltage and frequency of the OPP. + * P = C * V^2 * f with C being the device's capacitance and V and f + * respectively the voltage and frequency of the OPP. * - * Returns -ENODEV if the CPU device cannot be found, -EINVAL if the power - * calculation failed because of missing parameters, 0 otherwise. + * Returns -EINVAL if the power calculation failed because of missing + * parameters, 0 otherwise. */ -static int __maybe_unused _get_cpu_power(unsigned long *mW, unsigned long *kHz, -struct device *cp
[PATCH -next] drm/nv04/disp: remove set but not used variable 'width'
drivers/gpu/drm/nouveau/dispnv04/arb.c: In function nv04_calc_arb:
drivers/gpu/drm/nouveau/dispnv04/arb.c:56:21: warning:
variable width set but not used [-Wunused-but-set-variable]
'width' is never used, so remove it.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/gpu/drm/nouveau/dispnv04/arb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c
b/drivers/gpu/drm/nouveau/dispnv04/arb.c
index f607a04..9d4a2d9 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/arb.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c
@@ -53,7 +53,7 @@ struct nv_sim_state {
static void
nv04_calc_arb(struct nv_fifo_info *fifo, struct nv_sim_state *arb)
{
- int pagemiss, cas, width, bpp;
+ int pagemiss, cas, bpp;
int nvclks, mclks, crtpagemiss;
int found, mclk_extra, mclk_loop, cbs, m1, p1;
int mclk_freq, pclk_freq, nvclk_freq;
@@ -65,7 +65,6 @@ nv04_calc_arb(struct nv_fifo_info *fifo, struct nv_sim_state
*arb)
nvclk_freq = arb->nvclk_khz;
pagemiss = arb->mem_page_miss;
cas = arb->mem_latency;
- width = arb->memory_width >> 6;
bpp = arb->bpp;
cbs = 128;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/i915/display: conversion to new logging macros part 3
This patch continues the conversion of printk based logging macros to
the new struct drm_based logging macros in
drm/i915/display/intel_display.c.
This conversion was done using the following coccinelle script that
matches the existence of a straightforward struct drm_i915_private in
the functions:
@rule1@
identifier fn, T;
@@
fn(struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@rule2@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
New checkpatch warnings were fixed manually.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/display/intel_display.c | 395 +++
1 file changed, 223 insertions(+), 172 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index af8f1e0914a5..58d5333d3ad9 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12637,7 +12637,8 @@ static int intel_crtc_atomic_check(struct
intel_atomic_state *state,
if (dev_priv->display.compute_pipe_wm) {
ret = dev_priv->display.compute_pipe_wm(crtc_state);
if (ret) {
- DRM_DEBUG_KMS("Target pipe watermarks are invalid\n");
+ drm_dbg_kms(&dev_priv->drm,
+ "Target pipe watermarks are invalid\n");
return ret;
}
}
@@ -12653,7 +12654,8 @@ static int intel_crtc_atomic_check(struct
intel_atomic_state *state,
*/
ret = dev_priv->display.compute_intermediate_wm(crtc_state);
if (ret) {
- DRM_DEBUG_KMS("No valid intermediate pipe watermarks
are possible\n");
+ drm_dbg_kms(&dev_priv->drm,
+ "No valid intermediate pipe watermarks are
possible\n");
return ret;
}
}
@@ -12900,22 +12902,24 @@ static void intel_dump_pipe_config(const struct
intel_crtc_state *pipe_config,
char buf[64];
int i;
- DRM_DEBUG_KMS("[CRTC:%d:%s] enable: %s %s\n",
- crtc->base.base.id, crtc->base.name,
- yesno(pipe_config->hw.enable), context);
+ drm_dbg_kms(&dev_priv->drm, "[CRTC:%d:%s] enable: %s %s\n",
+ crtc->base.base.id, crtc->base.name,
+ yesno(pipe_config->hw.enable), context);
if (!pipe_config->hw.enable)
goto dump_planes;
snprintf_output_types(buf, sizeof(buf), pipe_config->output_types);
- DRM_DEBUG_KMS("active: %s, output_types: %s (0x%x), output format:
%s\n",
- yesno(pipe_config->hw.active),
- buf, pipe_config->output_types,
- output_formats(pipe_config->output_format));
+ drm_dbg_kms(&dev_priv->drm,
+ "active: %s, output_types: %s (0x%x), output format: %s\n",
+ yesno(pipe_config->hw.active),
+ buf, pipe_config->output_types,
+ output_formats(pipe_config->output_format));
- DRM_DEBUG_KMS("cpu_transcoder: %s, pipe bpp: %i, dithering: %i\n",
- transcoder_name(pipe_config->cpu_transcoder),
- pipe_config->pipe_bpp, pipe_config->dither);
+ drm_dbg_kms(&dev_priv->drm,
+ "cpu_transcoder: %s, pipe bpp: %i, dithering: %i\n",
+ transcoder_name(pipe_config->cpu_transcoder),
+ pipe_config->pipe_bpp, pipe_config->dither);
if (pipe_config->has_pch_encoder)
intel_dump_m_n_config(pipe_config, "fdi",
@@ -12931,13 +12935,15 @@ static void intel_dump_pipe_config(const struct
intel_crtc_state *pipe_config,
&pipe_config->dp_m2_n2);
}
- DRM_DEBUG_KMS("audio: %i, infoframes: %i, infoframes enabled: 0x%x\n",
- pipe_config->has_audio, pipe_config->has_infoframe,
- pipe_config->infoframes.enable);
+ drm_dbg_kms(&dev_priv->drm,
+ "audio: %i, infoframes: %i, infoframes enabled: 0x%x\n",
+ pipe_config->has_audio, pipe_config->has_infoframe,
+ pipe_config->infoframes.enable);
if (pipe_config->infoframes.enable &
intel_h
[PATCH] drm/i915: Fix i915_error_state_store error defination
Since commit 742379c0c4001 ("drm/i915: Start chopping up the GPU error
capture"), function 'i915_error_state_store' was defined and used with
only one parameter.
But if no 'CONFIG_DRM_I915_CAPTURE_ERROR', this function was defined
with two parameter.
This may lead compile error. This patch fix it.
Reported-by: Hulk Robot
Signed-off-by: Zhang Xiaoxu
---
drivers/gpu/drm/i915/i915_gpu_error.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 9109004956bd..41c1475e1500 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -314,8 +314,7 @@ i915_vma_capture_finish(struct intel_gt_coredump *gt,
}
static inline void
-i915_error_state_store(struct drm_i915_private *i915,
- struct i915_gpu_coredump *error)
+i915_error_state_store(struct i915_gpu_coredump *error)
{
}
--
2.17.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()
From: Chris Wilson > Sent: 16 January 2020 12:29 > > Quoting David Laight (2020-01-16 12:26:45) > > However there is a call from __i915_gem_objet_set_pages() that > > is preceded by a lockdep_assert_held() check - so mustn't sleep. > > That is a mutex; it's allowed to sleep. The might_sleep() here should > help assuage your fears. Gah. Having a mutex called mm.lock isn't entirely obvious when quickly reading code. >From what I was reading earlier it seems that clflush() (and cflushopt) are fast (well not stupidly slow) for buffers under 4k. I suspect then can do a 'mark pending', but for larger buffers have to wait for earlier requests to complete (although the graph carries on increasing to the 16k RH margin. If may well be that adding a cond_resched() after every 4k page will have ~0 performance impact because the first few clflush will be a bit faster (less slow). I'll do some measurements later this afternoon. FWIW does this code need to actually invalidate the cache lines? Or is it just forcing a writeback? David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] video: fbdev: pxa168fb: remove unnecessary platform_get_irq
commit 640ba2444fa9 ("drivers/video/pxa168fb.c: use devm_ functions")
left behind this, it can be removed.
Signed-off-by: YueHaibing
---
drivers/video/fbdev/pxa168fb.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/video/fbdev/pxa168fb.c b/drivers/video/fbdev/pxa168fb.c
index 706c6943..aef8a30 100644
--- a/drivers/video/fbdev/pxa168fb.c
+++ b/drivers/video/fbdev/pxa168fb.c
@@ -779,7 +779,6 @@ static int pxa168fb_remove(struct platform_device *pdev)
{
struct pxa168fb_info *fbi = platform_get_drvdata(pdev);
struct fb_info *info;
- int irq;
unsigned int data;
if (!fbi)
@@ -799,8 +798,6 @@ static int pxa168fb_remove(struct platform_device *pdev)
if (info->cmap.len)
fb_dealloc_cmap(&info->cmap);
- irq = platform_get_irq(pdev, 0);
-
dma_free_wc(fbi->dev, info->fix.smem_len,
info->screen_base, info->fix.smem_start);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/i915: Add mechanism to submit a context WA on ring submission
Mika Kuoppala writes: >Subject: Re: [PATCH 1/2] drm/i915: Add mechanism to submit a context WA >on ring submission I forgot to add RFC into patch subject. This should carry the RFC status as it is v2 on a RFC patch. This patch squashes Chris Wilson's ctx switch optimization and the development is still continuing. -Mika ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/i915/display: conversion to new logging macros part 1
This is the first patch that starts the conversion of the printk based
logging macros in drm/i915/display/intel_display.c to the new struct
drm_device based logging macros.
This conversion was done using the following coccinelle script that
matches based on the existence of a struct drm_i915_private device:
@rule1@
identifier fn, T;
@@
fn(struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@rule2@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
Checkpatch warnings were fixed manually.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/display/intel_display.c | 227 +++
1 file changed, 131 insertions(+), 96 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 59c375879186..e06c2e14b57d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -235,7 +235,8 @@ static void intel_update_czclk(struct drm_i915_private
*dev_priv)
dev_priv->czclk_freq = vlv_get_cck_clock_hpll(dev_priv, "czclk",
CCK_CZ_CLOCK_CONTROL);
- DRM_DEBUG_DRIVER("CZ clock rate: %d kHz\n", dev_priv->czclk_freq);
+ drm_dbg(&dev_priv->drm, "CZ clock rate: %d kHz\n",
+ dev_priv->czclk_freq);
}
static inline u32 /* units of 100MHz */
@@ -1063,8 +1064,9 @@ static void wait_for_pipe_scanline_moving(struct
intel_crtc *crtc, bool state)
/* Wait for the display line to settle/start moving */
if (wait_for(pipe_scanline_is_moving(dev_priv, pipe) == state, 100))
- DRM_ERROR("pipe %c scanline %s wait timed out\n",
- pipe_name(pipe), onoff(state));
+ drm_err(&dev_priv->drm,
+ "pipe %c scanline %s wait timed out\n",
+ pipe_name(pipe), onoff(state));
}
static void intel_wait_for_pipe_scanline_stopped(struct intel_crtc *crtc)
@@ -1397,7 +1399,7 @@ static void _vlv_enable_pll(struct intel_crtc *crtc,
udelay(150);
if (intel_de_wait_for_set(dev_priv, DPLL(pipe), DPLL_LOCK_VLV, 1))
- DRM_ERROR("DPLL %d failed to lock\n", pipe);
+ drm_err(&dev_priv->drm, "DPLL %d failed to lock\n", pipe);
}
static void vlv_enable_pll(struct intel_crtc *crtc,
@@ -1446,7 +1448,7 @@ static void _chv_enable_pll(struct intel_crtc *crtc,
/* Check PLL is locked */
if (intel_de_wait_for_set(dev_priv, DPLL(pipe), DPLL_LOCK_VLV, 1))
- DRM_ERROR("PLL %d failed to lock\n", pipe);
+ drm_err(&dev_priv->drm, "PLL %d failed to lock\n", pipe);
}
static void chv_enable_pll(struct intel_crtc *crtc,
@@ -1694,7 +1696,8 @@ static void ilk_enable_pch_transcoder(const struct
intel_crtc_state *crtc_state)
I915_WRITE(reg, val | TRANS_ENABLE);
if (intel_de_wait_for_set(dev_priv, reg, TRANS_STATE_ENABLE, 100))
- DRM_ERROR("failed to enable transcoder %c\n", pipe_name(pipe));
+ drm_err(&dev_priv->drm, "failed to enable transcoder %c\n",
+ pipe_name(pipe));
}
static void lpt_enable_pch_transcoder(struct drm_i915_private *dev_priv,
@@ -1726,7 +1729,7 @@ static void lpt_enable_pch_transcoder(struct
drm_i915_private *dev_priv,
I915_WRITE(LPT_TRANSCONF, val);
if (intel_de_wait_for_set(dev_priv, LPT_TRANSCONF,
TRANS_STATE_ENABLE, 100))
- DRM_ERROR("Failed to enable PCH transcoder\n");
+ drm_err(&dev_priv->drm, "Failed to enable PCH transcoder\n");
}
static void ilk_disable_pch_transcoder(struct drm_i915_private *dev_priv,
@@ -1748,7 +1751,8 @@ static void ilk_disable_pch_transcoder(struct
drm_i915_private *dev_priv,
I915_WRITE(reg, val);
/* wait for PCH transcoder off, transcoder state */
if (intel_de_wait_for_clear(dev_priv, reg, TRANS_STATE_ENABLE, 50))
- DRM_ERROR("failed to disable transcoder %c\n", pipe_name(pipe));
+ drm_err(&dev_priv->drm, "failed to disable transcoder %c\n",
+ pipe_name(pipe));
if (HAS_PCH_CPT(dev_priv)) {
/* Workaround: Clear the timing override chicken bit again. */
@@ -1769,7 +1773,7 @@ void lpt_disable_pch_transcoder(struct drm_i915_private
*dev_priv)
/* wait for PCH
[PATCH 0/4] Add support for devices in the Energy Model
From: Lukasz Luba Hi all, This patch set introduces support for devices in the Energy Model (EM) framework. It will unify the power model for thermal subsystem and make it simpler. The 1st patch refactors EM framework and adds support for devices. The 2nd patch changes dev_pm_opp_of_register_em() in OPP/OF which now should take as an argument struct device pointer. It touches a few trees (OMAP, NXP, mediatek) updating their CPUfreq drivers to the new interface. Patch 3 changes thermal devfreq cooling removing old code for calculating local power table. It simplifies the code and uses EM for requested power calculation. Last patch 4 is based on 'drm-misc-next' and adds EM to Panfrost driver. The patch set is based on v5.5-rc6 tag (excluding last patch). Regards, Lukasz Luba Lukasz Luba (4): PM / EM: and devices to Energy Model OPP: change parameter to device pointer in dev_pm_opp_of_register_em() thermal: devfreq_cooling: Refactor code and switch to use Energy Model drm/panfrost: Register to the Energy Model with devfreq device Documentation/power/energy-model.rst| 67 ++-- drivers/cpufreq/cpufreq-dt.c| 2 +- drivers/cpufreq/imx6q-cpufreq.c | 2 +- drivers/cpufreq/mediatek-cpufreq.c | 2 +- drivers/cpufreq/omap-cpufreq.c | 2 +- drivers/cpufreq/qcom-cpufreq-hw.c | 2 +- drivers/cpufreq/scmi-cpufreq.c | 11 +- drivers/cpufreq/scpi-cpufreq.c | 2 +- drivers/gpu/drm/panfrost/panfrost_devfreq.c | 3 + drivers/opp/of.c| 43 +-- drivers/thermal/cpu_cooling.c | 10 +- drivers/thermal/devfreq_cooling.c | 397 +++ include/linux/devfreq_cooling.h | 17 - include/linux/energy_model.h| 108 -- include/linux/pm_opp.h | 13 +- include/trace/events/thermal.h | 19 +- kernel/power/energy_model.c | 406 kernel/sched/sched.h| 2 +- kernel/sched/topology.c | 4 +- 19 files changed, 631 insertions(+), 481 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/panfrost: Register to the Energy Model with devfreq device
From: Lukasz Luba
Let Panfrost devfreq device use the Energy Model (EM). The EM can be used
in thermal subsystem (devfreq_cooling) for calculating the used power.
Signed-off-by: Lukasz Luba
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 413987038fbf..8771782f67c6 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -105,6 +105,8 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
}
pfdev->devfreq.devfreq = devfreq;
+ dev_pm_opp_of_register_em(dev);
+
cooling = of_devfreq_cooling_register(dev->of_node, devfreq);
if (IS_ERR(cooling))
DRM_DEV_INFO(dev, "Failed to register cooling device\n");
@@ -118,6 +120,7 @@ void panfrost_devfreq_fini(struct panfrost_device *pfdev)
{
if (pfdev->devfreq.cooling)
devfreq_cooling_unregister(pfdev->devfreq.cooling);
+ dev_pm_opp_of_unregister_em(&pfdev->pdev->dev);
dev_pm_opp_of_remove_table(&pfdev->pdev->dev);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 4/4] drm/i915/gvt: move public gvt headers out into global include
Hi Greg, On Thu, 2020-01-16 at 15:23 +0100, Greg KH wrote: > On Thu, Jan 16, 2020 at 03:13:01PM +0100, Julian Stecklina wrote: > > Hi Greg, Christoph, > > > > On Wed, 2020-01-15 at 16:22 +0100, Greg KH wrote: > > > On Thu, Jan 09, 2020 at 07:13:57PM +0200, Julian Stecklina wrote: > > > > Now that the GVT interface to hypervisors does not depend on i915/GVT > > > > internals anymore, we can move the headers to the global include/. > > > > > > > > This makes out-of-tree modules for hypervisor integration possible. > > > > > > What kind of out-of-tree modules do you need/want for this? > > > > The mediated virtualization support in the i915 driver needs a backend to > > the > > hypervisor. There is currently one backend for KVM in the tree > > (drivers/gpu/drm/i915/gvt/kvmgt.c) and at least 3 other hypervisor backends > > out > > of tree in various states of development that I know of. We are currently > > developing one of these. > > Great, then just submit this patch series as part of your patch series > when submitting yoru hypervisor code. That's the normal way to export > new symbols, we can't do so without an in-kernel user. Fair enough. As I already said, the KVMGT code is the in-kernel user. But I guess I can extend the already existing function pointer way of decoupling KVMGT from i915 and be on my way without exporting any symbols. Somewhat independent of the current discussion, I also think that it's valuable to have a defined API (I'm not saying stable API) for the hypervisor backends to define what's okay and not okay for them to do. Thanks, Julian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/scheduler: fix documentation by replacing rq_list with sched_list
This also replaces old artifacts with a correct one in drm_sched_entity_init()
declaration
Signed-off-by: Nirmoy Das
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_entity.c | 2 +-
include/drm/gpu_scheduler.h | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 33e2cd1089a2..ec79e8e5ad3c 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -45,7 +45,7 @@
* @guilty: atomic_t set to 1 when a job on this queue
* is found to be guilty causing a timeout
*
- * Note: the rq_list should have atleast one element to schedule
+ * Note: the sched_list should have atleast one element to schedule
* the entity
*
* Returns 0 on success or a negative error code on failure.
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 537f7a4655a5..9e71be129c30 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -52,9 +52,9 @@ enum drm_sched_priority {
* @list: used to append this struct to the list of entities in the
*runqueue.
* @rq: runqueue on which this entity is currently scheduled.
- * @rq_list: a list of run queues on which jobs from this entity can
- * be scheduled
- * @num_rq_list: number of run queues in the rq_list
+ * @sched_list: a list of drm_gpu_schedulers on which jobs from this entity can
+ * be scheduled
+ * @num_sched_list: number of drm_gpu_schedulers in the sched_list.
* @rq_lock: lock to modify the runqueue to which this entity belongs.
* @job_queue: the list of jobs of this entity.
* @fence_seq: a linearly increasing seqno incremented with each
@@ -81,8 +81,8 @@ enum drm_sched_priority {
struct drm_sched_entity {
struct list_headlist;
struct drm_sched_rq *rq;
- unsigned intnum_sched_list;
struct drm_gpu_scheduler**sched_list;
+ unsigned intnum_sched_list;
enum drm_sched_priority priority;
spinlock_t rq_lock;
@@ -315,7 +315,7 @@ void drm_sched_rq_remove_entity(struct drm_sched_rq *rq,
int drm_sched_entity_init(struct drm_sched_entity *entity,
enum drm_sched_priority priority,
struct drm_gpu_scheduler **sched_list,
- unsigned int num_rq_list,
+ unsigned int num_sched_list,
atomic_t *guilty);
long drm_sched_entity_flush(struct drm_sched_entity *entity, long timeout);
void drm_sched_entity_fini(struct drm_sched_entity *entity);
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/i915: Add mechanism to submit a context WA on ring submission
This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.
The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require rewriting the
ringbuffer. As each request would set up its own context, leaving it to
the HW to notice and elide no-op context switches, we could restart the
ring at any point, and reorder the requests freely.
However, to avoid emitting clear_residuals() between consecutive requests
in the ringbuffer of the same context, we do want to track the current
context in the ring. In doing so, we need to be careful to only record a
context switch when we are sure the next request will be emitted.
v2: elide optimization patch squashed, courtesy of Chris Wilson
Signed-off-by: Mika Kuoppala
Signed-off-by: Akeem G Abodunrin
Cc: Kumar Valsan Prathap
Cc: Chris Wilson
Cc: Balestrieri Francesco
Cc: Bloomfield Jon
Cc: Dutt Sudeep
---
.../gpu/drm/i915/gt/intel_ring_submission.c | 132 +-
1 file changed, 129 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index bc44fe8e5ffa..58500032c993 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1384,7 +1384,9 @@ static int load_pd_dir(struct i915_request *rq,
return rq->engine->emit_flush(rq, EMIT_FLUSH);
}
-static inline int mi_set_context(struct i915_request *rq, u32 flags)
+static inline int mi_set_context(struct i915_request *rq,
+struct intel_context *ce,
+u32 flags)
{
struct drm_i915_private *i915 = rq->i915;
struct intel_engine_cs *engine = rq->engine;
@@ -1459,7 +1461,7 @@ static inline int mi_set_context(struct i915_request *rq,
u32 flags)
*cs++ = MI_NOOP;
*cs++ = MI_SET_CONTEXT;
- *cs++ = i915_ggtt_offset(rq->context->state) | flags;
+ *cs++ = i915_ggtt_offset(ce->state) | flags;
/*
* w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
* WaMiSetContext_Hang:snb,ivb,vlv
@@ -1574,13 +1576,56 @@ static int switch_mm(struct i915_request *rq, struct
i915_address_space *vm)
return rq->engine->emit_flush(rq, EMIT_INVALIDATE);
}
+static int clear_residuals(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine = rq->engine;
+ int ret;
+
+ GEM_BUG_ON(!engine->kernel_context->state);
+
+ ret = switch_mm(rq, vm_alias(engine->kernel_context));
+ if (ret)
+ return ret;
+
+ ret = mi_set_context(rq,
+engine->kernel_context,
+MI_MM_SPACE_GTT | MI_RESTORE_INHIBIT);
+ if (ret)
+ return ret;
+
+ ret = engine->emit_bb_start(rq,
+ engine->wa_ctx.vma->node.start, 0,
+ 0);
+ if (ret)
+ return ret;
+
+ ret = engine->emit_flush(rq, EMIT_FLUSH);
+ if (ret)
+ return ret;
+
+ /* Always invalidate before the next switch_mm() */
+ return engine->emit_flush(rq, EMIT_INVALIDATE);
+}
+
static int switch_context(struct i915_request *rq)
{
+ struct intel_engine_cs *engine = rq->engine;
struct intel_context *ce = rq->context;
+ void **residuals = NULL;
int ret;
GEM_BUG_ON(HAS_EXECLISTS(rq->i915));
+ if (engine->wa_ctx.vma && ce != engine->kernel_context) {
+ if (engine->wa_ctx.vma->private != ce) {
+ ret = clear_residuals(rq);
+ if (ret)
+ return ret;
+
+ residuals = &engine->wa_ctx.vma->private;
+ }
+ }
+
ret = switch_mm(rq, vm_alias(ce));
if (ret)
return ret;
@@ -1600,7 +1645,7 @@ static int switch_context(struct i915_request *rq)
else
flags |= MI_RESTORE_INHIBIT;
- ret = mi_set_context(rq, flags);
+ ret = mi_set_context(rq, ce, flags);
if (ret)
return ret;
}
@@ -1609,6 +1654,20 @@ static int switch_context(struct i915_request *rq)
if (ret)
return ret;
+ /*
+* Now past the point of no return, this request _will_ be emitted.
+*
+* Or at least this preamble will be emitted, the request may be
+* interrupted prior to submitting the user payload. If so, we
+* still submit the "empty" request in order to preserve global
+* state tracking such as this, our tracking of the current
+* dirty context.
+*/
+ if (residuals) {
+ intel_context_put(*residuals);
+ *residuals = intel_context_g
Re: [PATCH v3 2/2] drm/sun4i: Add alpha property for sun8i and sun50i VI layer
Hi!
Sorry for late reply.
Dne petek, 03. januar 2020 ob 22:19:01 CET je
roman.stratiie...@globallogic.com napisal(a):
> From: Roman Stratiienko
>
> DE3.0 VI layers supports plane-global alpha channel.
> DE2.0 FCC block have GLOBAL_ALPHA register that can be used as alpha source
> for blender.
>
> Add alpha property to the DRM plane and connect it to the
> corresponding registers in the mixer.
>
> Do not add alpha property for systems with DE2.0 and more than 1 VI planes.
>
> Signed-off-by: Roman Stratiienko
This looks fine to me.
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> ---
> v2: Initial version by mistake
> v3:
> - Skip adding & applying alpha property if VI count > 1
> ---
> drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 48 +-
> drivers/gpu/drm/sun4i/sun8i_vi_layer.h | 11 ++
> 2 files changed, 51 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c index 42d445d23773..e61aec7d6d07
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> @@ -65,6 +65,36 @@ static void sun8i_vi_layer_enable(struct sun8i_mixer
> *mixer, int channel, }
> }
>
> +static void sun8i_vi_layer_update_alpha(struct sun8i_mixer *mixer, int
> channel, +int overlay, struct
drm_plane *plane)
> +{
> + u32 mask, val, ch_base;
> +
> + ch_base = sun8i_channel_base(mixer, channel);
> +
> + if (mixer->cfg->is_de3) {
> + mask = SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MASK |
> +SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MODE_MASK;
> + val = SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA
> + (plane->state->alpha >> 8);
> +
> + val |= (plane->state->alpha == DRM_BLEND_ALPHA_OPAQUE) ?
> +
SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MODE_PIXEL :
> +
SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MODE_COMBINED;
> +
> + regmap_update_bits(mixer->engine.regs,
> +
SUN8I_MIXER_CHAN_VI_LAYER_ATTR(ch_base,
> +
overlay),
> +mask, val);
> + } else if (mixer->cfg->vi_num == 1) {
> + regmap_update_bits(mixer->engine.regs,
> +
SUN8I_MIXER_FCC_GLOBAL_ALPHA_REG,
> +
SUN8I_MIXER_FCC_GLOBAL_ALPHA_MASK,
> +SUN8I_MIXER_FCC_GLOBAL_ALPHA
> + (plane->state->alpha >>
8));
> + }
> +}
> +
> static int sun8i_vi_layer_update_coord(struct sun8i_mixer *mixer, int
> channel, int overlay, struct drm_plane *plane,
> unsigned int zpos)
> @@ -248,14 +278,6 @@ static int sun8i_vi_layer_update_formats(struct
> sun8i_mixer *mixer, int channel, SUN8I_MIXER_CHAN_VI_LAYER_ATTR(ch_base,
> overlay),
> SUN8I_MIXER_CHAN_VI_LAYER_ATTR_RGB_MODE,
val);
>
> - /* It seems that YUV formats use global alpha setting. */
> - if (mixer->cfg->is_de3)
> - regmap_update_bits(mixer->engine.regs,
> -
SUN8I_MIXER_CHAN_VI_LAYER_ATTR(ch_base,
> -
overlay),
> -
SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MASK,
> -
SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA(0xff));
> -
> return 0;
> }
>
> @@ -373,6 +395,8 @@ static void sun8i_vi_layer_atomic_update(struct
> drm_plane *plane,
>
> sun8i_vi_layer_update_coord(mixer, layer->channel,
> layer->overlay, plane, zpos);
> + sun8i_vi_layer_update_alpha(mixer, layer->channel,
> + layer->overlay, plane);
> sun8i_vi_layer_update_formats(mixer, layer->channel,
> layer->overlay, plane);
> sun8i_vi_layer_update_buffer(mixer, layer->channel,
> @@ -464,6 +488,14 @@ struct sun8i_vi_layer *sun8i_vi_layer_init_one(struct
> drm_device *drm,
>
> plane_cnt = mixer->cfg->ui_num + mixer->cfg->vi_num;
>
> + if (mixer->cfg->vi_num == 1 || mixer->cfg->is_de3) {
> + ret = drm_plane_create_alpha_property(&layer->plane);
> + if (ret) {
> + dev_err(drm->dev, "Couldn't add alpha
property\n");
> + return ERR_PTR(ret);
> + }
> + }
> +
> ret = drm_plane_create_zpos_property(&layer->plane, index,
>0, plane_cnt -
1);
> if (ret) {
> diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.h
> b/drivers/gpu/drm/sun4i/sun8i_vi_layer.h index eaa6076f5dbc..48c399e1c86d
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.h
> +++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.h
> @@ -29,14 +29,25 @@
> #define SUN8I_MIXER
[PATCH 1/2] drm/i915: Add mechanism to submit a context WA on ring submission
This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.
The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require rewriting the
ringbuffer. As each request would set up its own context, leaving it to
the HW to notice and elide no-op context switches, we could restart the
ring at any point, and reorder the requests freely.
However, to avoid emitting clear_residuals() between consecutive requests
in the ringbuffer of the same context, we do want to track the current
context in the ring. In doing so, we need to be careful to only record a
context switch when we are sure the next request will be emitted.
v2: elide optimization patch squashed, courtesy of Chris Wilson
Signed-off-by: Mika Kuoppala
Signed-off-by: Akeem G Abodunrin
Cc: Kumar Valsan Prathap
Cc: Chris Wilson
Cc: Balestrieri Francesco
Cc: Bloomfield Jon
Cc: Dutt Sudeep
---
.../gpu/drm/i915/gt/intel_ring_submission.c | 132 +-
1 file changed, 129 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index bc44fe8e5ffa..58500032c993 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1384,7 +1384,9 @@ static int load_pd_dir(struct i915_request *rq,
return rq->engine->emit_flush(rq, EMIT_FLUSH);
}
-static inline int mi_set_context(struct i915_request *rq, u32 flags)
+static inline int mi_set_context(struct i915_request *rq,
+struct intel_context *ce,
+u32 flags)
{
struct drm_i915_private *i915 = rq->i915;
struct intel_engine_cs *engine = rq->engine;
@@ -1459,7 +1461,7 @@ static inline int mi_set_context(struct i915_request *rq,
u32 flags)
*cs++ = MI_NOOP;
*cs++ = MI_SET_CONTEXT;
- *cs++ = i915_ggtt_offset(rq->context->state) | flags;
+ *cs++ = i915_ggtt_offset(ce->state) | flags;
/*
* w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
* WaMiSetContext_Hang:snb,ivb,vlv
@@ -1574,13 +1576,56 @@ static int switch_mm(struct i915_request *rq, struct
i915_address_space *vm)
return rq->engine->emit_flush(rq, EMIT_INVALIDATE);
}
+static int clear_residuals(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine = rq->engine;
+ int ret;
+
+ GEM_BUG_ON(!engine->kernel_context->state);
+
+ ret = switch_mm(rq, vm_alias(engine->kernel_context));
+ if (ret)
+ return ret;
+
+ ret = mi_set_context(rq,
+engine->kernel_context,
+MI_MM_SPACE_GTT | MI_RESTORE_INHIBIT);
+ if (ret)
+ return ret;
+
+ ret = engine->emit_bb_start(rq,
+ engine->wa_ctx.vma->node.start, 0,
+ 0);
+ if (ret)
+ return ret;
+
+ ret = engine->emit_flush(rq, EMIT_FLUSH);
+ if (ret)
+ return ret;
+
+ /* Always invalidate before the next switch_mm() */
+ return engine->emit_flush(rq, EMIT_INVALIDATE);
+}
+
static int switch_context(struct i915_request *rq)
{
+ struct intel_engine_cs *engine = rq->engine;
struct intel_context *ce = rq->context;
+ void **residuals = NULL;
int ret;
GEM_BUG_ON(HAS_EXECLISTS(rq->i915));
+ if (engine->wa_ctx.vma && ce != engine->kernel_context) {
+ if (engine->wa_ctx.vma->private != ce) {
+ ret = clear_residuals(rq);
+ if (ret)
+ return ret;
+
+ residuals = &engine->wa_ctx.vma->private;
+ }
+ }
+
ret = switch_mm(rq, vm_alias(ce));
if (ret)
return ret;
@@ -1600,7 +1645,7 @@ static int switch_context(struct i915_request *rq)
else
flags |= MI_RESTORE_INHIBIT;
- ret = mi_set_context(rq, flags);
+ ret = mi_set_context(rq, ce, flags);
if (ret)
return ret;
}
@@ -1609,6 +1654,20 @@ static int switch_context(struct i915_request *rq)
if (ret)
return ret;
+ /*
+* Now past the point of no return, this request _will_ be emitted.
+*
+* Or at least this preamble will be emitted, the request may be
+* interrupted prior to submitting the user payload. If so, we
+* still submit the "empty" request in order to preserve global
+* state tracking such as this, our tracking of the current
+* dirty context.
+*/
+ if (residuals) {
+ intel_context_put(*residuals);
+ *residuals = intel_context_g
[PATCH 1/4] PM / EM: and devices to Energy Model
From: Lukasz Luba Add support of other devices into the Energy Model framework not only the CPUs. Change the interface to be more unified which can handle other devices as well. Signed-off-by: Lukasz Luba --- Documentation/power/energy-model.rst | 67 +++-- drivers/cpufreq/scmi-cpufreq.c | 11 +- drivers/opp/of.c | 9 +- drivers/thermal/cpu_cooling.c| 10 +- include/linux/energy_model.h | 108 --- kernel/power/energy_model.c | 406 +-- kernel/sched/sched.h | 2 +- kernel/sched/topology.c | 4 +- 8 files changed, 445 insertions(+), 172 deletions(-) diff --git a/Documentation/power/energy-model.rst b/Documentation/power/energy-model.rst index 90a345d57ae9..300955f3da70 100644 --- a/Documentation/power/energy-model.rst +++ b/Documentation/power/energy-model.rst @@ -1,15 +1,17 @@ - -Energy Model of CPUs - +.. SPDX-License-Identifier: GPL-2.0 + +=== +Energy Model of devices +=== 1. Overview --- The Energy Model (EM) framework serves as an interface between drivers knowing -the power consumed by CPUs at various performance levels, and the kernel +the power consumed by devices at various performance levels, and the kernel subsystems willing to use that information to make energy-aware decisions. -The source of the information about the power consumed by CPUs can vary greatly +The source of the information about the power consumed by devices can vary greatly from one platform to another. These power costs can be estimated using devicetree data in some cases. In others, the firmware will know better. Alternatively, userspace might be best positioned. And so on. In order to avoid @@ -26,7 +28,7 @@ framework, and interested clients reading the data from it:: | Thermal (IPA) | | Scheduler (EAS) | | Other | +---+ +-+ +---+ | | em_pd_energy()| - | | em_cpu_get() | + | em_dev_get() | em_cpu_get() | +-+ | +-+ | | | v v v @@ -47,12 +49,12 @@ framework, and interested clients reading the data from it:: | Device Tree | | Firmware| | ? | +--+ +---+ +--+ -The EM framework manages power cost tables per 'performance domain' in the -system. A performance domain is a group of CPUs whose performance is scaled -together. Performance domains generally have a 1-to-1 mapping with CPUFreq -policies. All CPUs in a performance domain are required to have the same -micro-architecture. CPUs in different performance domains can have different -micro-architectures. +In case of CPU devices the EM framework manages power cost tables per +'performance domain' in the system. A performance domain is a group of CPUs +whose performance is scaled together. Performance domains generally have a +1-to-1 mapping with CPUFreq policies. All CPUs in a performance domain are +required to have the same micro-architecture. CPUs in different performance +domains can have different micro-architectures. 2. Core APIs @@ -70,12 +72,12 @@ CONFIG_ENERGY_MODEL must be enabled to use the EM framework. Drivers are expected to register performance domains into the EM framework by calling the following API:: - int em_register_perf_domain(cpumask_t *span, unsigned int nr_states, + int em_register_perf_domain(struct device *dev, unsigned int nr_states, struct em_data_callback *cb); Drivers must specify the CPUs of the performance domains using the cpumask argument, and provide a callback function returning tuples -for each capacity state. The callback function provided by the driver is free +for each performance state. The callback function provided by the driver is free to fetch data from any relevant location (DT, firmware, ...), and by any mean deemed necessary. See Section 3. for an example of driver implementing this callback, and kernel/power/energy_model.c for further documentation on this @@ -85,13 +87,19 @@ API. 2.3 Accessing performance domains ^ +There is two API functions which provide the access to the energy model: +em_cpu_get() which takes CPU id as an argument and em_dev_get() with device +pointer as an argument. It depends on the subsystem which interface it is +going to use. + Subsystems interested in the energy model of a CPU can retrieve it using the em_cpu_get() API. The energy model tables are allocated once upon creation of the performance domains, and kept in memory untouched. The energy consumed by a performance domain can be estimated using the em_pd_energy() API.
[PATCH] MAINTAINERS: nouveau mailing list is moderated
From: Randy Dunlap Mark the nouveau@ mailing list as moderated for non-subscribers. Signed-off-by: Randy Dunlap --- MAINTAINERS |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- linux-next-20200116.orig/MAINTAINERS +++ linux-next-20200116/MAINTAINERS @@ -5315,7 +5315,7 @@ F:Documentation/devicetree/bindings/dis DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS M: Ben Skeggs L: dri-devel@lists.freedesktop.org -L: nouv...@lists.freedesktop.org +L: nouv...@lists.freedesktop.org (moderated for non-subscribers) T: git git://github.com/skeggsb/linux S: Supported F: drivers/gpu/drm/nouveau/ @@ -16914,7 +16914,7 @@ R: Karol Herbst R: Pekka Paalanen S: Maintained L: linux-ker...@vger.kernel.org -L: nouv...@lists.freedesktop.org +L: nouv...@lists.freedesktop.org (moderated for non-subscribers) F: kernel/trace/trace_mmiotrace.c F: include/linux/mmiotrace.h F: arch/x86/mm/kmmio.c ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Jan 16 (drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c)
On 1/16/20 1:17 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20200115: > > New tree: zonefs > > The sound-asoc tree lost its build failure. > > The net-next tree gained a build failure for which I reverted a commit. > > The keys tree still had build failures so I used the version from > next-20191211. > on i386 or x86_64: ../drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c: In function ‘gp10b_ltc_init’: ../drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c:37:9: error: implicit declaration of function ‘dev_iommu_fwspec_get’; did you mean ‘iommu_fwspec_free’? [-Werror=implicit-function-declaration] spec = dev_iommu_fwspec_get(device->dev); ^~~~ iommu_fwspec_free ../drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c:37:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion] spec = dev_iommu_fwspec_get(device->dev); ^ ../drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c:39:17: error: ‘struct iommu_fwspec’ has no member named ‘ids’ u32 sid = spec->ids[0] & 0x; ^~ Full randconfig file is attached. -- ~Randy Reported-by: Randy Dunlap # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 5.5.0-rc6 Kernel Configuration # # # Compiler: gcc (SUSE Linux) 7.5.0 # CONFIG_CC_IS_GCC=y CONFIG_GCC_VERSION=70500 CONFIG_CLANG_VERSION=0 CONFIG_CC_CAN_LINK=y CONFIG_CC_HAS_ASM_GOTO=y CONFIG_CC_HAS_ASM_INLINE=y CONFIG_CC_HAS_WARN_MAYBE_UNINITIALIZED=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_TABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION="" CONFIG_BUILD_SALT="" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_CROSS_MEMORY_ATTACH is not set # CONFIG_USELIB is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_SIM=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_IRQ_FASTEOI_HIERARCHY_HANDLERS=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y CONFIG_GENERIC_IRQ_RESERVATION_MODE=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_GENERIC_IRQ_DEBUGFS=y # end of IRQ subsystem CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_ARCH_CLOCKSOURCE_INIT=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set # end of Timers subsystem # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_COUNT=y CONFIG_PREEMPTION=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set CONFIG_IRQ_TIME_ACCOUNTING=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_PSI=y # CONFIG_PSI_DEFAULT_DISABLED is not set # end of CPU/Task time and stats accounting # CONFIG_CPU_ISOLATION is not set # # RCU Subsystem # CONFIG_TREE_RCU=y CONFIG_PREEMPT_RCU=y CONFIG_RCU_EXPERT=y CONFIG_SRCU=y CONFIG_TREE_SRCU=y CONFIG_TASKS_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_NEED_SEGCBLIST=y CONFIG_RCU_FANOUT=64 CONFIG_RCU_FANOUT_LEAF=16 CONFIG_RCU_BOOST=y CONFIG_RCU_BOOST_DELAY=500 # CONFIG_RCU_NOCB_CPU is not set # end of RCU Subsystem CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_IKHEADERS=y CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # # Scheduler features # # end of Scheduler features CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y CONFIG_CC_HAS_INT128=y CONFIG_ARCH_SUPPORTS_INT128=y # CONFIG_CGROUPS is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set CONFIG_TIME_NS=y CONFIG_IPC_NS=y # CONFIG_USER_NS is not set CONFIG_PID_NS=y CONFIG_CHECKPOINT_RESTORE=y # CONFIG_SCHED_AUTOGROUP is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y # CONFIG_RD_LZMA is not set CONFIG_RD_XZ=y CONFIG_RD_LZO=y CONFIG_RD_LZ4=y # CONFIG_INITRAMFS_COMPRESSION_NONE is not set # CONFIG_INITRAMFS_COMPRESSION_GZIP is not set # CONFIG_INITRAMFS_COMPRESSION_BZIP2 is not set # CONFIG_INITRAMFS_COMPRESSION_XZ is not set CONFIG_INITRAMFS_COMPRESSION_LZO=y # CONFIG_INITRAMFS_COMPRESSION_LZ4 is not set # CONFIG_BOOT_CONFIG is not set CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y # CO
[PATCH 0/4] drm/i915/display: conversion to new logging macros.
This series converts the printk based logging macros in drm/i915/display/intel_display.c to the new struct drm_device based logging macros. This change was split into four for manageability and due to the size of drm/i915/display/intel_display.c. Wambui Karuga (4): drm/i915/display: conversion to new logging macros part 1 drm/i915/display: conversion to new logging macros part 2 drm/i915/display: conversion to new logging macros part 3 drm/i915/display: convert to new logging macros part 4. drivers/gpu/drm/i915/display/intel_display.c | 1021 ++ 1 file changed, 596 insertions(+), 425 deletions(-) -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/i915/display: conversion to new logging macros part 2
This patch continues the conversion of printk based logging macros to
the new struct drm_based logging macros in
drm/i915/display/intel_display.c.
This conversion was done using the following coccinelle script that
matches the existence of a straightforward struct drm_i915_private in
the functions:
@rule1@
identifier fn, T;
@@
fn(struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@rule2@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
New checkpatch warnings were addressed manually.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/display/intel_display.c | 232 +++
1 file changed, 140 insertions(+), 92 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index e06c2e14b57d..af8f1e0914a5 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7535,8 +7535,9 @@ static void intel_crtc_disable_noatomic(struct intel_crtc
*crtc,
state = drm_atomic_state_alloc(&dev_priv->drm);
if (!state) {
- DRM_DEBUG_KMS("failed to disable [CRTC:%d:%s], out of memory",
- crtc->base.base.id, crtc->base.name);
+ drm_dbg_kms(&dev_priv->drm,
+ "failed to disable [CRTC:%d:%s], out of memory",
+ crtc->base.base.id, crtc->base.name);
return;
}
@@ -7552,8 +7553,9 @@ static void intel_crtc_disable_noatomic(struct intel_crtc
*crtc,
drm_atomic_state_put(state);
- DRM_DEBUG_KMS("[CRTC:%d:%s] hw state adjusted, was enabled, now
disabled\n",
- crtc->base.base.id, crtc->base.name);
+ drm_dbg_kms(&dev_priv->drm,
+ "[CRTC:%d:%s] hw state adjusted, was enabled, now
disabled\n",
+ crtc->base.base.id, crtc->base.name);
crtc->active = false;
crtc->base.enabled = false;
@@ -7598,7 +7600,8 @@ int intel_display_suspend(struct drm_device *dev)
state = drm_atomic_helper_suspend(dev);
ret = PTR_ERR_OR_ZERO(state);
if (ret)
- DRM_ERROR("Suspending crtc's failed with %i\n", ret);
+ drm_err(&dev_priv->drm, "Suspending crtc's failed with %i\n",
+ ret);
else
dev_priv->modeset_restore_state = state;
return ret;
@@ -7667,18 +7670,21 @@ static int ilk_check_fdi_lanes(struct drm_device *dev,
enum pipe pipe,
struct intel_crtc *other_crtc;
struct intel_crtc_state *other_crtc_state;
- DRM_DEBUG_KMS("checking fdi config on pipe %c, lanes %i\n",
- pipe_name(pipe), pipe_config->fdi_lanes);
+ drm_dbg_kms(&dev_priv->drm,
+ "checking fdi config on pipe %c, lanes %i\n",
+ pipe_name(pipe), pipe_config->fdi_lanes);
if (pipe_config->fdi_lanes > 4) {
- DRM_DEBUG_KMS("invalid fdi lane config on pipe %c: %i lanes\n",
- pipe_name(pipe), pipe_config->fdi_lanes);
+ drm_dbg_kms(&dev_priv->drm,
+ "invalid fdi lane config on pipe %c: %i lanes\n",
+ pipe_name(pipe), pipe_config->fdi_lanes);
return -EINVAL;
}
if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
if (pipe_config->fdi_lanes > 2) {
- DRM_DEBUG_KMS("only 2 lanes on haswell, required: %i
lanes\n",
- pipe_config->fdi_lanes);
+ drm_dbg_kms(&dev_priv->drm,
+ "only 2 lanes on haswell, required: %i
lanes\n",
+ pipe_config->fdi_lanes);
return -EINVAL;
} else {
return 0;
@@ -7703,15 +7709,17 @@ static int ilk_check_fdi_lanes(struct drm_device *dev,
enum pipe pipe,
return PTR_ERR(other_crtc_state);
if (pipe_required_fdi_lanes(other_crtc_state) > 0) {
- DRM_DEBUG_KMS("invalid shared fdi lane config on pipe
%c: %i lanes\n",
- pipe_name(pipe), pipe_config->fdi_lanes);
+ drm_dbg_kms(&dev_priv->drm,
+ "invalid shared fdi l
[PATCH 4/4] drm/i915/display: convert to new logging macros part 4.
This patch provides the final conversion of most of the printk based
logging macros instances in drm/i915/display/intel_display.c to the
struct drm_device based logging macros. The struct drm_i915_private
device is extracted from various intel types and used in the new logging
macros.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/display/intel_display.c | 167 +++
1 file changed, 102 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 58d5333d3ad9..b871cdd9f1cf 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3890,6 +3890,8 @@ static int skl_check_main_surface(struct
intel_plane_state *plane_state)
static int skl_check_nv12_aux_surface(struct intel_plane_state *plane_state)
{
+ struct drm_i915_private *i915 =
+ to_i915(plane_state->uapi.plane->dev);
const struct drm_framebuffer *fb = plane_state->hw.fb;
unsigned int rotation = plane_state->hw.rotation;
int uv_plane = 1;
@@ -3907,8 +3909,9 @@ static int skl_check_nv12_aux_surface(struct
intel_plane_state *plane_state)
/* FIXME not quite sure how/if these apply to the chroma plane */
if (w > max_width || h > max_height) {
- DRM_DEBUG_KMS("CbCr source size %dx%d too big (limit %dx%d)\n",
- w, h, max_width, max_height);
+ drm_dbg_kms(&i915->drm,
+ "CbCr source size %dx%d too big (limit %dx%d)\n",
+ w, h, max_width, max_height);
return -EINVAL;
}
@@ -3937,7 +3940,8 @@ static int skl_check_nv12_aux_surface(struct
intel_plane_state *plane_state)
if (x != plane_state->color_plane[ccs_plane].x ||
y != plane_state->color_plane[ccs_plane].y) {
- DRM_DEBUG_KMS("Unable to find suitable display surface
offset due to CCS\n");
+ drm_dbg_kms(&i915->drm,
+ "Unable to find suitable display surface
offset due to CCS\n");
return -EINVAL;
}
}
@@ -7621,10 +7625,10 @@ static void intel_connector_verify_state(struct
intel_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
+ struct drm_i915_private *i915 = to_i915(connector->base.dev);
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
- connector->base.base.id,
- connector->base.name);
+ drm_dbg_kms(&i915->drm, "[CONNECTOR:%d:%s]\n",
+ connector->base.base.id, connector->base.name);
if (connector->get_hw_state(connector)) {
struct intel_encoder *encoder = connector->encoder;
@@ -7745,6 +7749,7 @@ static int ilk_fdi_compute_config(struct intel_crtc
*intel_crtc,
struct intel_crtc_state *pipe_config)
{
struct drm_device *dev = intel_crtc->base.dev;
+ struct drm_i915_private *i915 = to_i915(dev);
const struct drm_display_mode *adjusted_mode =
&pipe_config->hw.adjusted_mode;
int lane, link_bw, fdi_dotclock, ret;
bool needs_recompute = false;
@@ -7757,7 +7762,7 @@ static int ilk_fdi_compute_config(struct intel_crtc
*intel_crtc,
* Hence the bw of each lane in terms of the mode signal
* is:
*/
- link_bw = intel_fdi_link_freq(to_i915(dev), pipe_config);
+ link_bw = intel_fdi_link_freq(i915, pipe_config);
fdi_dotclock = adjusted_mode->crtc_clock;
@@ -7775,8 +7780,9 @@ static int ilk_fdi_compute_config(struct intel_crtc
*intel_crtc,
if (ret == -EINVAL && pipe_config->pipe_bpp > 6*3) {
pipe_config->pipe_bpp -= 2*3;
- DRM_DEBUG_KMS("fdi link bw constraint, reducing pipe bpp to
%i\n",
- pipe_config->pipe_bpp);
+ drm_dbg_kms(&i915->drm,
+ "fdi link bw constraint, reducing pipe bpp to %i\n",
+ pipe_config->pipe_bpp);
needs_recompute = true;
pipe_config->bw_constrained = true;
@@ -8195,6 +8201,7 @@ static void intel_cpu_transcoder_set_m_n(const struct
intel_crtc_state *crtc_sta
void intel_dp_set_m_n(const struct intel_crtc_state *crtc_state, enum
link_m_n_set m_n)
{
const struct intel_link_m_n *dp_m_n, *dp_m2_n2 = NULL;
+ struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
if (m_n == M1_N1) {
dp_m_n = &crtc_state->dp_m_n;
@@ -8207,7 +8214,7 @@ void intel_dp_set_m_n(const struct intel_crtc_state
*crtc_state, enum link_m_n_s
*/
dp_m_n = &crtc_state->dp_m2_n2;
} else {
-
RE: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()
> I'll do some measurements later this afternoon. This is an Ivy bridge cpu, so clflush (not clflushopt). With a cond_resched for every page I get: (Note these calls are every 10 seconds) # tracer: function_graph # # CPU DURATION FUNCTION CALLS # | | | | | | | 0) # 3155.126 us | drm_clflush_sg [drm](); 1) # 3067.382 us | drm_clflush_sg [drm](); 2) # 3063.766 us | drm_clflush_sg [drm](); 3) # 3092.302 us | drm_clflush_sg [drm](); 0) # 3209.486 us | drm_clflush_sg [drm](); -- 0) kworker-7=> kworker-319 -- 0) # 3633.803 us | drm_clflush_sg [drm](); -- 1) kworker-7=> kworker-319 -- 1) # 3090.278 us | drm_clflush_sg [drm](); 2) # 3828.108 us | drm_clflush_sg [drm](); 3) # 3049.836 us | drm_clflush_sg [drm](); -- 3) kworker-319 => kworker-7 -- 3) # 3295.017 us | drm_clflush_sg [drm](); 3) # 3064.077 us | drm_clflush_sg [drm](); -- 0) kworker-319 => kworker-7 -- 0) # 3182.034 us | drm_clflush_sg [drm](); -- 3) kworker-7=> kworker-319 -- 3) # 3065.754 us | drm_clflush_sg [drm](); -- 2) kworker-319 => kworker-7 -- 2) # 3562.513 us | drm_clflush_sg [drm](); -- 3) kworker-319 => kworker-7 -- 3) # 3048.914 us | drm_clflush_sg [drm](); 3) # 3062.469 us | drm_clflush_sg [drm](); 3) # 3055.727 us | drm_clflush_sg [drm](); -- 0) kworker-7=> kworker-319 -- Without the cond_sched I suspect more of them are 3.0ms. Not really a significant difference. I guess the longer times are the scheduler looking for work? I don't understand the extra traces - I'm guessing they are process switch related. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()
From: Chris Wilson > Sent: 16 January 2020 07:40 > Quoting Daniel Vetter (2020-01-16 06:52:42) > > On Wed, Jan 15, 2020 at 08:52:45PM +, Chris Wilson wrote: > > > Since we may try and flush the cachelines associated with large buffers > > > (an 8K framebuffer is about 128MiB, even before we try HDR), this leads > > > to unacceptably long latencies (when using a voluntary CONFIG_PREEMPT). > > > If we call cond_resched() between each sg chunk, that it about every 128 > > > pages, we have a natural break point in which to check if the process > > > needs to be rescheduled. Naturally, this means that drm_clflush_sg() can > > > only be called from process context -- which is true at the moment. The > > > other clflush routines remain usable from atomic context. > > > > > > Even though flushing large objects takes a demonstrable amount to time > > > to flush all the cachelines, clflush is still preferred over a > > > system-wide wbinvd as the latter has unpredictable latencies affecting > > > the whole system not just the local task. > > > > > > Reported-by: David Laight > > > Signed-off-by: Chris Wilson > > > Cc: David Laight > > > > The original bug report is complaining about latencies for SCHED_RT > > threads, on a system that doesn't even use CONFIG_PREEMPT. I'm not sure > > it's terribly valid to cater to that use-case - all the desktop distros > > seem a lot more reasonable. So firmly *shrug* from my side ... > > Yeah, I had the same immediate response to the complaint), but otoh we've > inserted cond_resched() before when it looks like may consume entire > jiffies inside a loop. At the very minimum, we should have a > might_sleep() here and a reminder that this can be very slow (remember > byt?). I'm using RT to get more deterministic scheduling to look for long scheduling delays, rather than because we need very tight scheduling. Delays of several 100us aren't a real problem. The problem with CONFIG_PREEMPT is that the distros don't enable it and it isn't a command line option. So it is really useless unless you are able/willing to build your own kernel. I could run the code under the normal scheduler with 'nice -19'. I stlll wouldn't expect to have all but one cpu idle when I've just done a cv_broadcast() to wake up a lot of threads. I've added 'if (!(++i & 31)) cond_resched();' after the drm_clfulsh_page() call in drm_cflush_sg(). In my case that it 3600/32 reschedules in 3.3ms - plenty. However there is a call from __i915_gem_objet_set_pages() that is preceded by a lockdep_assert_held() check - so mustn't sleep. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 4/4] drm/i915/gvt: move public gvt headers out into global include
Hi Greg, Christoph, On Wed, 2020-01-15 at 16:22 +0100, Greg KH wrote: > On Thu, Jan 09, 2020 at 07:13:57PM +0200, Julian Stecklina wrote: > > Now that the GVT interface to hypervisors does not depend on i915/GVT > > internals anymore, we can move the headers to the global include/. > > > > This makes out-of-tree modules for hypervisor integration possible. > > What kind of out-of-tree modules do you need/want for this? The mediated virtualization support in the i915 driver needs a backend to the hypervisor. There is currently one backend for KVM in the tree (drivers/gpu/drm/i915/gvt/kvmgt.c) and at least 3 other hypervisor backends out of tree in various states of development that I know of. We are currently developing one of these. > > Also, as Christoph said, adding exports for functions that are not used > by anything within the kernel tree itself is not ok, that's not how we > work. The exports are used by the KVM hypervisor backend. The patchset I sent basically decouples KVMGT from i915 driver internals. So personally I would count this as a benefit in itself. There is already an indirection in place that looks like it is intended to decouple the hypervisor backends from the i915 driver core: intel_gvt_ops. This is a struct of function pointers that the hypervisor backend uses to talk to the GPU mediator code. Unfortunately, this struct doesn't cover all usecases and the KVM hypervisor backend directly touches the i915 devices' internal state in very few places. My current solution was to wrap these accesses in accessor functions and EXPORT_SYMBOL_GPL them. If the more acceptable solution is to add more function pointers to intel_gvt_ops instead of exporting symbols, I'm happy to go along this route. > And why do they somehow have to be out of the tree? We want them in the > tree, and so should you, as it will save you time and money if they are. I also want these hypervisor backends in the tree, but from a development workflow having the ability to build them as a out-of-tree modules is very convenient. I guess this is also true for the developers working on the other hypervisor backends. When I looked at the status quo in i915/gvt a couple of weeks ago, it seemed like it would be a win for everyone. Let me just clearly say that we have no intention of doing binary blob drivers. :) Thanks, Julian [1] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i915/gvt/gvt.h#L555 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/nouveau: fix build error without CONFIG_IOMMU_API
If CONFIG_IOMMU_API is n, build fails: vers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c:37:9: error: implicit declaration of function dev_iommu_fwspec_get; did you mean iommu_fwspec_free? [-Werror=implicit-function-declaration] spec = dev_iommu_fwspec_get(device->dev); ^~~~ iommu_fwspec_free drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c:37:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion] spec = dev_iommu_fwspec_get(device->dev); ^ drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c:39:17: error: struct iommu_fwspec has no member named ids u32 sid = spec->ids[0] & 0x; Seletc IOMMU_API under config DRM_NOUVEAU to fix this. Reported-by: Hulk Robot Signed-off-by: Chen Zhou --- drivers/gpu/drm/nouveau/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index 9c990266..ce03693 100644 --- a/drivers/gpu/drm/nouveau/Kconfig +++ b/drivers/gpu/drm/nouveau/Kconfig @@ -2,6 +2,7 @@ config DRM_NOUVEAU tristate "Nouveau (NVIDIA) cards" depends on DRM && PCI && MMU + select IOMMU_API select FW_LOADER select DRM_KMS_HELPER select DRM_TTM -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/nouveau/kms/nv50: remove set but not unused variable 'nv_connector'
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function nv50_pior_enable:
drivers/gpu/drm/nouveau/dispnv50/disp.c:1672:28: warning:
variable nv_connector set but not used [-Wunused-but-set-variable]
commit ac2d9275f371 ("drm/nouveau/kms/nv50-: Store the
bpc we're using in nv50_head_atom") left behind this.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 5fabe2b..a82b354 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1669,7 +1669,6 @@ nv50_pior_enable(struct drm_encoder *encoder)
{
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nouveau_crtc *nv_crtc = nouveau_crtc(encoder->crtc);
- struct nouveau_connector *nv_connector;
struct nv50_head_atom *asyh = nv50_head_atom(nv_crtc->base.state);
struct nv50_core *core = nv50_disp(encoder->dev)->core;
u8 owner = 1 << nv_crtc->index;
@@ -1677,7 +1676,6 @@ nv50_pior_enable(struct drm_encoder *encoder)
nv50_outp_acquire(nv_encoder);
- nv_connector = nouveau_encoder_connector_get(nv_encoder);
switch (asyh->or.bpc) {
case 10: asyh->or.depth = 0x6; break;
case 8: asyh->or.depth = 0x5; break;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 0/6] Add dual-LVDS panel support to EK874
Hi Laurent,
(woops, forgot to press sent)
On Wed, Dec 18, 2019 at 12:13 AM Laurent Pinchart
wrote:
> On Tue, Dec 17, 2019 at 01:45:55PM +, Fabrizio Castro wrote:
> > this series adds support for dual-LVDS panel IDK-2121WR
> > from Advantech:
> > https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm
> >
> > V6 reworks patch "drm: rcar-du: lvds: Allow for even and odd pixels swap",
> > and rebases the series on top of patch:
> > https://patchwork.kernel.org/patch/11295991/
>
> I've taken patch 1/6 to 4/6 in my tree. I expect Geert to take 6/6. For
> 5/6, I'll give Rob a chance to review the patch. Sam, could you handle
> it afterwards ?
Queuing 6/6 in renesas-devel for v5.6.
> > Fabrizio Castro (6):
> > drm: of: Add drm_of_lvds_get_dual_link_pixel_order
> > drm: rcar-du: lvds: Improve identification of panels
> > drm: rcar-du: lvds: Get dual link configuration from DT
> > drm: rcar-du: lvds: Allow for even and odd pixels swap
> > dt-bindings: display: Add idk-2121wr binding
> > arm64: dts: renesas: Add EK874 board with idk-2121wr display support
> >
> > .../display/panel/advantech,idk-2121wr.yaml| 128 +++
> > arch/arm64/boot/dts/renesas/Makefile | 3 +-
> > .../boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts | 116 +
> > drivers/gpu/drm/drm_of.c | 116 +
> > drivers/gpu/drm/rcar-du/rcar_lvds.c| 180
> > -
> > include/drm/drm_of.h | 20 +++
> > 6 files changed, 483 insertions(+), 80 deletions(-)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
> > create mode 100644
> > arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 0/6] Add dual-LVDS panel support to EK874
Hi Fabrizio/Laurent/Geert. (Thanks Geert, I recall I never replied to this mail). On Fri, Jan 17, 2020 at 09:47:22AM +0100, Geert Uytterhoeven wrote: > Hi Laurent, > > (woops, forgot to press sent) > > On Wed, Dec 18, 2019 at 12:13 AM Laurent Pinchart > wrote: > > On Tue, Dec 17, 2019 at 01:45:55PM +, Fabrizio Castro wrote: > > > this series adds support for dual-LVDS panel IDK-2121WR > > > from Advantech: > > > https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm > > > > > > V6 reworks patch "drm: rcar-du: lvds: Allow for even and odd pixels swap", > > > and rebases the series on top of patch: > > > https://patchwork.kernel.org/patch/11295991/ > > > > I've taken patch 1/6 to 4/6 in my tree. I expect Geert to take 6/6. For > > 5/6, I'll give Rob a chance to review the patch. Sam, could you handle > > it afterwards ? Rob had comments to the 5/6 patch - and I have missed if a new version was sent. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/bridge: anx78xx: fix integer type used for storing dp link rate
On 09.01.2020 09:48, Tobias Schramm wrote:
> commit ff1e8fb68ea0 ("drm/bridge: analogix-anx78xx: Avoid drm_dp_link
> helpers")
> changed the link training logic to remove use of drm_dp_link helpers. However
> the new logic stores the maximum link rate in a u8, overflowing it.
> This commit changes the logic to store the max link rate in a unsigned int
> instead.
>
> Signed-off-by: Tobias Schramm
> ---
> drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> index 274989f96a91..0f38b8c40dff 100644
> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> @@ -748,6 +748,7 @@ static int anx78xx_init_pdata(struct anx78xx *anx78xx)
> static int anx78xx_dp_link_training(struct anx78xx *anx78xx)
> {
> u8 dp_bw, dpcd[2];
> + unsigned int max_link_rate;
> int err;
>
> err = regmap_write(anx78xx->map[I2C_IDX_RX_P0], SP_HDMI_MUTE_CTRL_REG,
> @@ -866,8 +867,8 @@ static int anx78xx_dp_link_training(struct anx78xx
> *anx78xx)
> if (err)
> return err;
>
> - dpcd[0] = drm_dp_max_link_rate(anx78xx->dpcd);
> - dpcd[0] = drm_dp_link_rate_to_bw_code(dpcd[0]);
> + max_link_rate = drm_dp_max_link_rate(anx78xx->dpcd);
> + dpcd[0] = drm_dp_link_rate_to_bw_code(max_link_rate);
The code converts bw_code to rate, then reverse, maybe it should be
simplified:
dpcd[0] = anx78xx->dpcd[DP_MAX_LINK_RATE];
Regards
Andrzej
> err = regmap_write(anx78xx->map[I2C_IDX_TX_P0],
> SP_DP_MAIN_LINK_BW_SET_REG, dpcd[0]);
> if (err)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: tfp410: add pclk limits
On 13.01.2020 14:45, Tomi Valkeinen wrote:
> Add pixel clock limits to the driver as per TFP410 datasheet: min 25MHz,
> max 165MHz.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/bridge/ti-tfp410.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> index 6f6d6d1e60ae..f378a8f79bcb 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -167,10 +167,20 @@ static void tfp410_disable(struct drm_bridge *bridge)
> gpiod_set_value_cansleep(dvi->powerdown, 1);
> }
>
> +static enum drm_mode_status tfp410_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_mode
> *mode)
> +{
> + if (mode->clock < 25000 || mode->clock > 165000)
> + return MODE_BAD;
> +
> + return MODE_OK;
> +}
> +
> static const struct drm_bridge_funcs tfp410_bridge_funcs = {
> .attach = tfp410_attach,
> .enable = tfp410_enable,
> .disable= tfp410_disable,
> + .mode_valid = tfp410_mode_valid,
> };
>
> static void tfp410_hpd_work_func(struct work_struct *work)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] New: R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 Bug ID: 206231 Summary: R9 280X low performance with all games Product: Drivers Version: 2.5 Kernel Version: 5.4.0-2-amd64 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: kentos...@whiteninjastudio.com Regression: No Created attachment 286855 --> https://bugzilla.kernel.org/attachment.cgi?id=286855&action=edit Low performance and low GPU usage with Tomb Raider (Linux native) Hello, I have been experiencing performance issues with my AMD R9 280X graphics card for several months. On all games (Linux native and Proton), my performance is very low, well below the capabilities of the graphics card. The problem occurred when I migrated my system from Windows to Debian 10. I updated Debian stable to sid in order to have the latest version of the kernel and mesa. When I launch a game, the performances are low and during very complex scenes, the framerate goes down to 10/15 fps with a very low GPU use ~ 18%. The only time I've seen GPU usage hit 98% is in the main menu in Dawn of War II. Changing the graphics settings or the screen resolution changes absolutely nothing. The only game that seems to work well is Shadow Warrior, whose GPU usage rarely exceeds 70%. I have never heard the fans work since my transition to Debian so I used the radeon-profile tool to make sure the fans work manually. I forced the use of the hight profile in order to increase the memory and processor frequency as much as possible, but no difference kentosama@teradrive:~$ uname -a Linux teradrive 5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 (2020-01-05) x86_64 GNU/Linux kentosama@teradrive:~$ glxinfo | grep OpenGL OpenGL vendor string: X.Org OpenGL renderer string: AMD Radeon HD 7900 Series (TAHITI, DRM 3.35.0, 5.4.0-2-amd64, LLVM 9.0.1) OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.3.2 OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.3.2 OpenGL shading language version string: 4.50 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.3.2 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 OpenGL ES profile extensions: kentosama@teradrive:~$ vblank_mode=0 glxgears ATTENTION: default value of option vblank_mode overridden by environment. 25934 frames in 5.0 seconds = 5186.741 FPS 25239 frames in 5.0 seconds = 5047.634 FPS 25109 frames in 5.0 seconds = 5021.724 FPS 26234 frames in 5.0 seconds = 5246.724 FPS 27341 frames in 5.0 seconds = 5468.155 FPS 26836 frames in 5.0 seconds = 5367.148 FPS 27233 frames in 5.0 seconds = 5446.563 FPS 26164 frames in 5.0 seconds = 5232.749 FPS 26568 frames in 5.0 seconds = 5313.582 FPS 25854 frames in 5.0 seconds = 5170.670 FPS 26857 frames in 5.0 seconds = 5371.198 FPS 25896 frames in 5.0 seconds = 5179.152 FPS 26129 frames in 5.0 seconds = 5225.626 FPS 26181 frames in 5.0 seconds = 5236.104 FPS 25873 frames in 5.0 seconds = 5174.487 FPS 26584 frames in 5.0 seconds = 5316.643 FPS 26448 frames in 5.0 seconds = 5289.565 FPS 27543 frames in 5.0 seconds = 5508.535 FPS 26074 frames in 5.0 seconds = 5214.784 FPS 26551 frames in 5.0 seconds = 5310.126 FPS 27081 frames in 5.0 seconds = 5416.005 FPS 26073 frames in 5.0 seconds = 5214.450 FPS 25781 frames in 5.0 seconds = 5156.146 FPS 26895 frames in 5.0 seconds = 5378.962 FPS 26933 frames in 5.0 seconds = 5386.433 FPS 26197 frames in 5.0 seconds = 5239.087 FPS 26348 frames in 5.0 seconds = 5269.402 FPS 27020 frames in 5.0 seconds = 5403.997 FPS 26684 frames in 5.0 seconds = 5336.700 FPS 26798 frames in 5.0 seconds = 5359.434 FPS 27071 frames in 5.0 seconds = 5414.150 FPS 26068 frames in 5.0 seconds = 5213.525 FPS 25425 frames in 5.0 seconds = 5084.933 FPS 25963 frames in 5.0 seconds = 5192.526 FPS 26528 frames in 5.0 seconds = 5305.459 FPS 29053 frames in 5.0 seconds = 5810.492 FPS 25807 frames in 5.0 seconds = 5161.248 FPS 25978 frames in 5.0 seconds = 5195.598 FPS 25677 frames in 5.0 seconds = 5135.263 FPS 26250 frames in 5.0 seconds = 5249.852 FPS 26988 frames in 5.0 seconds = 5397.509 FPS 26183 frames in 5.0 seconds = 5236.487 FPS 25639 frames in 5.0 seconds = 5127.785 FPS 26207 frames in 5.0 seconds = 5241.383 FPS 25885 frames in 5.0 seconds = 5176.901 FPS 25660 frames in 5.0 seconds = 5131.782 FPS 25256 frames in 5.0 seconds = 5051.157 FPS 26747 frames in 5.0 seconds = 5349.287 FPS 27643 frames in 5.0 seconds = 5528.397 FPS 26030 frames in 5.0 seconds = 5205.866 FPS 26480 frames in 5.0 seconds = 5295.797 FPS 2
Re: [RESEND v3 2/2] drm: bridge: adv7511: Add support for ADV7535
On 07.01.2020 14:34, Bogdan Togorean wrote:
> ADV7535 is a DSI to HDMI bridge chip like ADV7533 but it allows
> 1080p@60Hz. v1p2 is fixed to 1.8V on ADV7535 but on ADV7533 can be 1.2V
> or 1.8V and is configurable in a register.
>
> Signed-off-by: Bogdan Togorean
> ---
> drivers/gpu/drm/bridge/adv7511/Kconfig | 13 ++
> drivers/gpu/drm/bridge/adv7511/Makefile | 3 +-
> drivers/gpu/drm/bridge/adv7511/adv7511.h | 44 +++-
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 35 ++--
> 4 files changed, 32 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig
> b/drivers/gpu/drm/bridge/adv7511/Kconfig
> index 8a56ff81f4fb..47d4eb9e845d 100644
> --- a/drivers/gpu/drm/bridge/adv7511/Kconfig
> +++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
> @@ -4,8 +4,9 @@ config DRM_I2C_ADV7511
> depends on OF
> select DRM_KMS_HELPER
> select REGMAP_I2C
> + select DRM_MIPI_DSI
> help
> - Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
> + Support for the Analog Device ADV7511(W)/13/33/35 HDMI encoders.
>
> config DRM_I2C_ADV7511_AUDIO
> bool "ADV7511 HDMI Audio driver"
> @@ -15,16 +16,8 @@ config DRM_I2C_ADV7511_AUDIO
> Support the ADV7511 HDMI Audio interface. This is used in
> conjunction with the AV7511 HDMI driver.
>
> -config DRM_I2C_ADV7533
> - bool "ADV7533 encoder"
> - depends on DRM_I2C_ADV7511
> - select DRM_MIPI_DSI
> - default y
> - help
> - Support for the Analog Devices ADV7533 DSI to HDMI encoder.
> -
> config DRM_I2C_ADV7511_CEC
> - bool "ADV7511/33 HDMI CEC driver"
> + bool "ADV7511/33/35 HDMI CEC driver"
> depends on DRM_I2C_ADV7511
> select CEC_CORE
> default y
> diff --git a/drivers/gpu/drm/bridge/adv7511/Makefile
> b/drivers/gpu/drm/bridge/adv7511/Makefile
> index b46ebeb35fd4..d8ceb534b51f 100644
> --- a/drivers/gpu/drm/bridge/adv7511/Makefile
> +++ b/drivers/gpu/drm/bridge/adv7511/Makefile
> @@ -1,6 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0-only
> -adv7511-y := adv7511_drv.o
> +adv7511-y := adv7511_drv.o adv7533.o
> adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
> adv7511-$(CONFIG_DRM_I2C_ADV7511_CEC) += adv7511_cec.o
> -adv7511-$(CONFIG_DRM_I2C_ADV7533) += adv7533.o
> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> index 52b2adfdc877..ed9cfd944098 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -220,6 +220,10 @@
>
> #define ADV7533_REG_CEC_OFFSET 0x70
>
> +#define ADV7533_REG_SUPPLY_SELECT0xe4
> +
> +#define ADV7533_V1P2_ENABLE BIT(7)
> +
> enum adv7511_input_clock {
> ADV7511_INPUT_CLOCK_1X,
> ADV7511_INPUT_CLOCK_2X,
> @@ -320,6 +324,7 @@ struct adv7511_video_config {
> enum adv7511_type {
> ADV7511,
> ADV7533,
> + ADV7535,
> };
>
> #define ADV7511_MAX_ADDRS 3
> @@ -393,7 +398,6 @@ static inline int adv7511_cec_init(struct device *dev,
> struct adv7511 *adv7511)
> }
> #endif
>
> -#ifdef CONFIG_DRM_I2C_ADV7533
> void adv7533_dsi_power_on(struct adv7511 *adv);
> void adv7533_dsi_power_off(struct adv7511 *adv);
> void adv7533_mode_set(struct adv7511 *adv, const struct drm_display_mode
> *mode);
> @@ -402,44 +406,6 @@ int adv7533_patch_cec_registers(struct adv7511 *adv);
> int adv7533_attach_dsi(struct adv7511 *adv);
> void adv7533_detach_dsi(struct adv7511 *adv);
> int adv7533_parse_dt(struct device_node *np, struct adv7511 *adv);
> -#else
> -static inline void adv7533_dsi_power_on(struct adv7511 *adv)
> -{
> -}
> -
> -static inline void adv7533_dsi_power_off(struct adv7511 *adv)
> -{
> -}
> -
> -static inline void adv7533_mode_set(struct adv7511 *adv,
> - const struct drm_display_mode *mode)
> -{
> -}
> -
> -static inline int adv7533_patch_registers(struct adv7511 *adv)
> -{
> - return -ENODEV;
> -}
> -
> -static inline int adv7533_patch_cec_registers(struct adv7511 *adv)
> -{
> - return -ENODEV;
> -}
> -
> -static inline int adv7533_attach_dsi(struct adv7511 *adv)
> -{
> - return -ENODEV;
> -}
> -
> -static inline void adv7533_detach_dsi(struct adv7511 *adv)
> -{
> -}
> -
> -static inline int adv7533_parse_dt(struct device_node *np, struct adv7511
> *adv)
> -{
> - return -ENODEV;
> -}
> -#endif
>
> #ifdef CONFIG_DRM_I2C_ADV7511_AUDIO
> int adv7511_audio_init(struct device *dev, struct adv7511 *adv7511);
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index 9e13e466e72c..35595472e771 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -367,7 +367,7 @@ static void adv7511_power_on(struct adv7511 *adv7511)
>*/
> regcache_sync(adv7511->regmap);
>
Re: [RESEND v3 2/2] drm: bridge: adv7511: Add support for ADV7535
On 17.01.2020 11:27, Andrzej Hajda wrote:
> On 07.01.2020 14:34, Bogdan Togorean wrote:
>> ADV7535 is a DSI to HDMI bridge chip like ADV7533 but it allows
>> 1080p@60Hz. v1p2 is fixed to 1.8V on ADV7535 but on ADV7533 can be 1.2V
>> or 1.8V and is configurable in a register.
>>
>> Signed-off-by: Bogdan Togorean
>> ---
>> drivers/gpu/drm/bridge/adv7511/Kconfig | 13 ++
>> drivers/gpu/drm/bridge/adv7511/Makefile | 3 +-
>> drivers/gpu/drm/bridge/adv7511/adv7511.h | 44 +++-
>> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 35 ++--
>> 4 files changed, 32 insertions(+), 63 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig
>> b/drivers/gpu/drm/bridge/adv7511/Kconfig
>> index 8a56ff81f4fb..47d4eb9e845d 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/Kconfig
>> +++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
>> @@ -4,8 +4,9 @@ config DRM_I2C_ADV7511
>> depends on OF
>> select DRM_KMS_HELPER
>> select REGMAP_I2C
>> +select DRM_MIPI_DSI
>> help
>> - Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
>> + Support for the Analog Device ADV7511(W)/13/33/35 HDMI encoders.
>>
>> config DRM_I2C_ADV7511_AUDIO
>> bool "ADV7511 HDMI Audio driver"
>> @@ -15,16 +16,8 @@ config DRM_I2C_ADV7511_AUDIO
>>Support the ADV7511 HDMI Audio interface. This is used in
>>conjunction with the AV7511 HDMI driver.
>>
>> -config DRM_I2C_ADV7533
>> -bool "ADV7533 encoder"
>> -depends on DRM_I2C_ADV7511
>> -select DRM_MIPI_DSI
>> -default y
>> -help
>> - Support for the Analog Devices ADV7533 DSI to HDMI encoder.
>> -
>> config DRM_I2C_ADV7511_CEC
>> -bool "ADV7511/33 HDMI CEC driver"
>> +bool "ADV7511/33/35 HDMI CEC driver"
>> depends on DRM_I2C_ADV7511
>> select CEC_CORE
>> default y
>> diff --git a/drivers/gpu/drm/bridge/adv7511/Makefile
>> b/drivers/gpu/drm/bridge/adv7511/Makefile
>> index b46ebeb35fd4..d8ceb534b51f 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/Makefile
>> +++ b/drivers/gpu/drm/bridge/adv7511/Makefile
>> @@ -1,6 +1,5 @@
>> # SPDX-License-Identifier: GPL-2.0-only
>> -adv7511-y := adv7511_drv.o
>> +adv7511-y := adv7511_drv.o adv7533.o
>> adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
>> adv7511-$(CONFIG_DRM_I2C_ADV7511_CEC) += adv7511_cec.o
>> -adv7511-$(CONFIG_DRM_I2C_ADV7533) += adv7533.o
>> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> b/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> index 52b2adfdc877..ed9cfd944098 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> @@ -220,6 +220,10 @@
>>
>> #define ADV7533_REG_CEC_OFFSET 0x70
>>
>> +#define ADV7533_REG_SUPPLY_SELECT 0xe4
>> +
>> +#define ADV7533_V1P2_ENABLE BIT(7)
>> +
>> enum adv7511_input_clock {
>> ADV7511_INPUT_CLOCK_1X,
>> ADV7511_INPUT_CLOCK_2X,
>> @@ -320,6 +324,7 @@ struct adv7511_video_config {
>> enum adv7511_type {
>> ADV7511,
>> ADV7533,
>> +ADV7535,
>> };
>>
>> #define ADV7511_MAX_ADDRS 3
>> @@ -393,7 +398,6 @@ static inline int adv7511_cec_init(struct device *dev,
>> struct adv7511 *adv7511)
>> }
>> #endif
>>
>> -#ifdef CONFIG_DRM_I2C_ADV7533
>> void adv7533_dsi_power_on(struct adv7511 *adv);
>> void adv7533_dsi_power_off(struct adv7511 *adv);
>> void adv7533_mode_set(struct adv7511 *adv, const struct drm_display_mode
>> *mode);
>> @@ -402,44 +406,6 @@ int adv7533_patch_cec_registers(struct adv7511 *adv);
>> int adv7533_attach_dsi(struct adv7511 *adv);
>> void adv7533_detach_dsi(struct adv7511 *adv);
>> int adv7533_parse_dt(struct device_node *np, struct adv7511 *adv);
>> -#else
>> -static inline void adv7533_dsi_power_on(struct adv7511 *adv)
>> -{
>> -}
>> -
>> -static inline void adv7533_dsi_power_off(struct adv7511 *adv)
>> -{
>> -}
>> -
>> -static inline void adv7533_mode_set(struct adv7511 *adv,
>> -const struct drm_display_mode *mode)
>> -{
>> -}
>> -
>> -static inline int adv7533_patch_registers(struct adv7511 *adv)
>> -{
>> -return -ENODEV;
>> -}
>> -
>> -static inline int adv7533_patch_cec_registers(struct adv7511 *adv)
>> -{
>> -return -ENODEV;
>> -}
>> -
>> -static inline int adv7533_attach_dsi(struct adv7511 *adv)
>> -{
>> -return -ENODEV;
>> -}
>> -
>> -static inline void adv7533_detach_dsi(struct adv7511 *adv)
>> -{
>> -}
>> -
>> -static inline int adv7533_parse_dt(struct device_node *np, struct adv7511
>> *adv)
>> -{
>> -return -ENODEV;
>> -}
>> -#endif
>>
>> #ifdef CONFIG_DRM_I2C_ADV7511_AUDIO
>> int adv7511_audio_init(struct device *dev, struct adv7511 *adv7511);
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> index 9e13e466e72c..35595472e771 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> +++ b/drivers/gpu/drm/brid
Re: [PATCH v3 4/5] drm/i915: Don't use VBT for detecting DPCD backlight controls
On Thu, 16 Jan 2020, Lyude Paul wrote:
> Despite the fact that the VBT appears to have a field for specifying
> that a system is equipped with a panel that supports standard VESA
> backlight controls over the DP AUX channel, so far every system we've
> spotted DPCD backlight control support on doesn't actually set this
> field correctly and all have it set to INTEL_BACKLIGHT_DISPLAY_DDI.
>
> While we don't know the exact reason for this VBT misuse, talking with
> some vendors indicated that there's a good number of laptop panels out
> there that supposedly support both PWM backlight controls and DPCD
> backlight controls as a workaround until Intel supports DPCD backlight
> controls across platforms universally. This being said, the X1 Extreme
> 2nd Gen that I have here (note that Lenovo is not the hardware vendor
> that informed us of this) PWM backlight controls are advertised, but
> only DPCD controls actually function. I'm going to make an educated
> guess here and say that on systems like this one, it's likely that PWM
> backlight controls might have been intended to work but were never
> really tested by QA.
>
> Since we really need backlights to work without any extra module
> parameters, let's take the risk here and rely on the standard DPCD caps
> to tell us whether AUX backlight controls are supported or not. We still
> check the VBT, but only to make sure that we don't enable DPCD backlight
> controls on a panel that uses something other then the standard VESA
> interfaces over AUX. Since panels using such non-standard interfaces
> should probably have support added to i915, we'll print a warning when
> seeing this in the VBT. We can remove this warning later if we end up
> adding support for any custom backlight interfaces.
>
> Signed-off-by: Lyude Paul
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112376
> Cc: Jani Nikula
> Cc: Perry Yuan
> Cc: AceLan Kao
> ---
> .../drm/i915/display/intel_dp_aux_backlight.c| 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index 77a759361c5c..3002b600635f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -330,13 +330,17 @@ int intel_dp_aux_init_backlight_funcs(struct
> intel_connector *intel_connector)
> struct intel_panel *panel = &intel_connector->panel;
> struct drm_i915_private *dev_priv = to_i915(intel_connector->base.dev);
>
> - if (i915_modparams.enable_dpcd_backlight == 0 ||
> - (i915_modparams.enable_dpcd_backlight == -1 &&
> - dev_priv->vbt.backlight.type !=
> INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE))
> - return -ENODEV;
> -
> - if (!intel_dp_aux_display_control_capable(intel_connector))
> + if (i915_modparams.enable_dpcd_backlight == 0)
> return -ENODEV;
> + if (i915_modparams.enable_dpcd_backlight == -1) {
> + if (dev_priv->vbt.backlight.type
> + == INTEL_BACKLIGHT_PANEL_DRIVER_INTERFACE) {
> + DRM_WARN("VBT says panel uses custom panel driver
> interface, not using DPCD backlight controls\n");
> + return -ENODEV;
> + }
> + if (!intel_dp_aux_display_control_capable(intel_connector))
> + return -ENODEV;
Functionally, I'm fine with trying this. But perhaps we should check aux
and early return first, and then check what vbt says, to reduce the
dmesg noise.
I'll probably want to see a debug message if we're enabling aux
backlight even if dev_priv->vbt.backlight.type !=
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE. It's the kind of debug trace
you'll really want to get first.
BR,
Jani.
> + }
>
> panel->backlight.setup = intel_dp_aux_setup_backlight;
> panel->backlight.enable = intel_dp_aux_enable_backlight;
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/panfrost: Add the panfrost_gem_mapping concept
On 16/01/2020 02:15, Rob Herring wrote:
> From: Boris Brezillon
>
> With the introduction of per-FD address space, the same BO can be mapped
> in different address space if the BO is globally visible (GEM_FLINK)
> and opened in different context or if the dmabuf is self-imported. The
> current implementation does not take case into account, and attaches the
> mapping directly to the panfrost_gem_object.
>
> Let's create a panfrost_gem_mapping struct and allow multiple mappings
> per BO.
>
> The mappings are refcounted which helps solve another problem where
> mappings were torn down (GEM handle closed by userspace) while GPU
> jobs accessing those BOs were still in-flight. Jobs now keep a
> reference on the mappings they use.
>
> v2 (robh):
> - Minor review comment clean-ups from Steven
> - Use list_is_singular helper
> - Just WARN if we add a mapping when madvise state is not WILLNEED.
> With that, drop the use of object_name_lock.
>
> v3 (robh):
> - Revert returning list iterator in panfrost_gem_mapping_get()
>
> Fixes: a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation")
> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
> Cc:
> Signed-off-by: Boris Brezillon
> Signed-off-by: Rob Herring
Reviewed-by: Steven Price
Thanks,
Steve
> ---
> With the actual changes committed this time...
>
> drivers/gpu/drm/panfrost/panfrost_drv.c | 91 +++--
> drivers/gpu/drm/panfrost/panfrost_gem.c | 124 +++---
> drivers/gpu/drm/panfrost/panfrost_gem.h | 41 +-
> .../gpu/drm/panfrost/panfrost_gem_shrinker.c | 3 +-
> drivers/gpu/drm/panfrost/panfrost_job.c | 13 +-
> drivers/gpu/drm/panfrost/panfrost_job.h | 1 +
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 61 +
> drivers/gpu/drm/panfrost/panfrost_mmu.h | 6 +-
> drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 34 +++--
> 9 files changed, 300 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index f61364f7c471..88b431a267af 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -78,8 +78,10 @@ static int panfrost_ioctl_get_param(struct drm_device
> *ddev, void *data, struct
> static int panfrost_ioctl_create_bo(struct drm_device *dev, void *data,
> struct drm_file *file)
> {
> + struct panfrost_file_priv *priv = file->driver_priv;
> struct panfrost_gem_object *bo;
> struct drm_panfrost_create_bo *args = data;
> + struct panfrost_gem_mapping *mapping;
>
> if (!args->size || args->pad ||
> (args->flags & ~(PANFROST_BO_NOEXEC | PANFROST_BO_HEAP)))
> @@ -95,7 +97,14 @@ static int panfrost_ioctl_create_bo(struct drm_device
> *dev, void *data,
> if (IS_ERR(bo))
> return PTR_ERR(bo);
>
> - args->offset = bo->node.start << PAGE_SHIFT;
> + mapping = panfrost_gem_mapping_get(bo, priv);
> + if (!mapping) {
> + drm_gem_object_put_unlocked(&bo->base.base);
> + return -EINVAL;
> + }
> +
> + args->offset = mapping->mmnode.start << PAGE_SHIFT;
> + panfrost_gem_mapping_put(mapping);
>
> return 0;
> }
> @@ -119,6 +128,11 @@ panfrost_lookup_bos(struct drm_device *dev,
> struct drm_panfrost_submit *args,
> struct panfrost_job *job)
> {
> + struct panfrost_file_priv *priv = file_priv->driver_priv;
> + struct panfrost_gem_object *bo;
> + unsigned int i;
> + int ret;
> +
> job->bo_count = args->bo_handle_count;
>
> if (!job->bo_count)
> @@ -130,9 +144,32 @@ panfrost_lookup_bos(struct drm_device *dev,
> if (!job->implicit_fences)
> return -ENOMEM;
>
> - return drm_gem_objects_lookup(file_priv,
> - (void __user
> *)(uintptr_t)args->bo_handles,
> - job->bo_count, &job->bos);
> + ret = drm_gem_objects_lookup(file_priv,
> + (void __user *)(uintptr_t)args->bo_handles,
> + job->bo_count, &job->bos);
> + if (ret)
> + return ret;
> +
> + job->mappings = kvmalloc_array(job->bo_count,
> +sizeof(struct panfrost_gem_mapping *),
> +GFP_KERNEL | __GFP_ZERO);
> + if (!job->mappings)
> + return -ENOMEM;
> +
> + for (i = 0; i < job->bo_count; i++) {
> + struct panfrost_gem_mapping *mapping;
> +
> + bo = to_panfrost_bo(job->bos[i]);
> + mapping = panfrost_gem_mapping_get(bo, priv);
> + if (!mapping) {
> + ret = -EINVAL;
> + break;
> + }
> +
> + job->mappings[i] = mapping;
> + }
> +
> + return ret;
> }
>
> /**
> @@ -320,7 +357,9 @@ static int panfrost_ioc
Re: [PATCH v3 4/5] drm/i915: Don't use VBT for detecting DPCD backlight controls
On Fri, 17 Jan 2020, Jani Nikula wrote:
> On Thu, 16 Jan 2020, Lyude Paul wrote:
>> Despite the fact that the VBT appears to have a field for specifying
>> that a system is equipped with a panel that supports standard VESA
>> backlight controls over the DP AUX channel, so far every system we've
>> spotted DPCD backlight control support on doesn't actually set this
>> field correctly and all have it set to INTEL_BACKLIGHT_DISPLAY_DDI.
>>
>> While we don't know the exact reason for this VBT misuse, talking with
>> some vendors indicated that there's a good number of laptop panels out
>> there that supposedly support both PWM backlight controls and DPCD
>> backlight controls as a workaround until Intel supports DPCD backlight
>> controls across platforms universally. This being said, the X1 Extreme
>> 2nd Gen that I have here (note that Lenovo is not the hardware vendor
>> that informed us of this) PWM backlight controls are advertised, but
>> only DPCD controls actually function. I'm going to make an educated
>> guess here and say that on systems like this one, it's likely that PWM
>> backlight controls might have been intended to work but were never
>> really tested by QA.
>>
>> Since we really need backlights to work without any extra module
>> parameters, let's take the risk here and rely on the standard DPCD caps
>> to tell us whether AUX backlight controls are supported or not. We still
>> check the VBT, but only to make sure that we don't enable DPCD backlight
>> controls on a panel that uses something other then the standard VESA
>> interfaces over AUX. Since panels using such non-standard interfaces
>> should probably have support added to i915, we'll print a warning when
>> seeing this in the VBT. We can remove this warning later if we end up
>> adding support for any custom backlight interfaces.
>>
>> Signed-off-by: Lyude Paul
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112376
>> Cc: Jani Nikula
>> Cc: Perry Yuan
>> Cc: AceLan Kao
>> ---
>> .../drm/i915/display/intel_dp_aux_backlight.c| 16 ++--
>> 1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> index 77a759361c5c..3002b600635f 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> @@ -330,13 +330,17 @@ int intel_dp_aux_init_backlight_funcs(struct
>> intel_connector *intel_connector)
>> struct intel_panel *panel = &intel_connector->panel;
>> struct drm_i915_private *dev_priv = to_i915(intel_connector->base.dev);
>>
>> -if (i915_modparams.enable_dpcd_backlight == 0 ||
>> -(i915_modparams.enable_dpcd_backlight == -1 &&
>> -dev_priv->vbt.backlight.type !=
>> INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE))
>> -return -ENODEV;
>> -
>> -if (!intel_dp_aux_display_control_capable(intel_connector))
>> +if (i915_modparams.enable_dpcd_backlight == 0)
>> return -ENODEV;
>> +if (i915_modparams.enable_dpcd_backlight == -1) {
>> +if (dev_priv->vbt.backlight.type
>> +== INTEL_BACKLIGHT_PANEL_DRIVER_INTERFACE) {
>> +DRM_WARN("VBT says panel uses custom panel driver
>> interface, not using DPCD backlight controls\n");
>> +return -ENODEV;
>> +}
>> +if (!intel_dp_aux_display_control_capable(intel_connector))
>> +return -ENODEV;
>
> Functionally, I'm fine with trying this. But perhaps we should check aux
> and early return first, and then check what vbt says, to reduce the
> dmesg noise.
>
> I'll probably want to see a debug message if we're enabling aux
> backlight even if dev_priv->vbt.backlight.type !=
> INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE. It's the kind of debug trace
> you'll really want to get first.
So I've gone ahead and pushed patches 1-3 and 5 in this series, as they
were tested as part of the series I posted.
BR,
Jani.
>
> BR,
> Jani.
>
>
>
>> +}
>>
>> panel->backlight.setup = intel_dp_aux_setup_backlight;
>> panel->backlight.enable = intel_dp_aux_enable_backlight;
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix i915_error_state_store error defination
Hi Zhang,
On Fri, Jan 17, 2020 at 03:34:36PM +0800, Zhang Xiaoxu wrote:
> Since commit 742379c0c4001 ("drm/i915: Start chopping up the GPU error
> capture"), function 'i915_error_state_store' was defined and used with
> only one parameter.
>
> But if no 'CONFIG_DRM_I915_CAPTURE_ERROR', this function was defined
> with two parameter.
>
> This may lead compile error. This patch fix it.
>
> Reported-by: Hulk Robot
I've never been a fan of non human accounts, we had this discussion
already in a different mailing list. Could you please find a
different way of giving credit to your CI system?
> Signed-off-by: Zhang Xiaoxu
> ---
> drivers/gpu/drm/i915/i915_gpu_error.h | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
> b/drivers/gpu/drm/i915/i915_gpu_error.h
> index 9109004956bd..41c1475e1500 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.h
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.h
> @@ -314,8 +314,7 @@ i915_vma_capture_finish(struct intel_gt_coredump *gt,
> }
>
> static inline void
> -i915_error_state_store(struct drm_i915_private *i915,
> -struct i915_gpu_coredump *error)
> +i915_error_state_store(struct i915_gpu_coredump *error)
ouch! that's an oversight.
Thanks for your patch,
Reviewed-by: Andi Shyti
Andi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: tfp410: add pclk limits
Hi Tomi,
Thank you for the patch.
On Mon, Jan 13, 2020 at 03:45:28PM +0200, Tomi Valkeinen wrote:
> Add pixel clock limits to the driver as per TFP410 datasheet: min 25MHz,
> max 165MHz.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/bridge/ti-tfp410.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> index 6f6d6d1e60ae..f378a8f79bcb 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -167,10 +167,20 @@ static void tfp410_disable(struct drm_bridge *bridge)
> gpiod_set_value_cansleep(dvi->powerdown, 1);
> }
>
> +static enum drm_mode_status tfp410_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_mode
> *mode)
> +{
> + if (mode->clock < 25000 || mode->clock > 165000)
> + return MODE_BAD;
Shouldn't you return MODE_CLOCK_LOW AND MODE_CLOCK_HIGH respectively ?
Apart from that,
Reviewed-by: Laurent Pinchart
> +
> + return MODE_OK;
> +}
> +
> static const struct drm_bridge_funcs tfp410_bridge_funcs = {
> .attach = tfp410_attach,
> .enable = tfp410_enable,
> .disable= tfp410_disable,
> + .mode_valid = tfp410_mode_valid,
> };
>
> static void tfp410_hpd_work_func(struct work_struct *work)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix i915_error_state_store error defination
On Fri, 17 Jan 2020, Andi Shyti wrote:
> Hi Zhang,
>
> On Fri, Jan 17, 2020 at 03:34:36PM +0800, Zhang Xiaoxu wrote:
>> Since commit 742379c0c4001 ("drm/i915: Start chopping up the GPU error
>> capture"), function 'i915_error_state_store' was defined and used with
>> only one parameter.
>>
>> But if no 'CONFIG_DRM_I915_CAPTURE_ERROR', this function was defined
>> with two parameter.
>>
>> This may lead compile error. This patch fix it.
>>
>> Reported-by: Hulk Robot
>
> I've never been a fan of non human accounts, we had this discussion
> already in a different mailing list. Could you please find a
> different way of giving credit to your CI system?
I don't actually mind for Reported-by credits. The history is full of
things like:
Reported-by: kbuild test robot
Reported-by: syzbot+ec24e95ea483de0a2...@syzkaller.appspotmail.com
Care to reference the discussion?
BR,
Janid.
>
>> Signed-off-by: Zhang Xiaoxu
>> ---
>> drivers/gpu/drm/i915/i915_gpu_error.h | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
>> b/drivers/gpu/drm/i915/i915_gpu_error.h
>> index 9109004956bd..41c1475e1500 100644
>> --- a/drivers/gpu/drm/i915/i915_gpu_error.h
>> +++ b/drivers/gpu/drm/i915/i915_gpu_error.h
>> @@ -314,8 +314,7 @@ i915_vma_capture_finish(struct intel_gt_coredump *gt,
>> }
>>
>> static inline void
>> -i915_error_state_store(struct drm_i915_private *i915,
>> - struct i915_gpu_coredump *error)
>> +i915_error_state_store(struct i915_gpu_coredump *error)
>
> ouch! that's an oversight.
>
> Thanks for your patch,
>
> Reviewed-by: Andi Shyti
>
> Andi
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
re: drm/amd/display: make PSR static screen entry within 30 ms
Hi,
Static analysis with Coverity has detected a division by zero in the
following commit:
commit 5b5abe9526073ccbf3032d27b5864520829cdd9c
Author: Anthony Koo
Date: Mon Dec 9 17:26:34 2019 -0500
drm/amd/display: make PSR static screen entry within 30 ms
Specifically:
unsigned int vsync_rate_hz = 0;
struct dc_static_screen_params params = {0};
/* Calculate number of static frames before generating interrupt to
* enter PSR.
*/
unsigned int frame_time_microsec = 100 / vsync_rate_hz;
vsync_rate_hz is zero, and frame_time_microsec is being assigned a value
that is being divided by zero. I'm not sure why this is coded this way
and not sure what the fix is, hence I'm reporting the issue.
Colin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 19/21] drm/vkms: Convert to CRTC VBLANK callbacks
Hi
Am 16.01.20 um 00:18 schrieb Rodrigo Siqueira:
> Hi,
>
> Thanks for the patch, I reviewed and tested it. Everything looks fine
> for VKMS.
>
> Reviewed-by: Rodrigo Siqueira
> Tested-by: Rodrigo Siqueira
Thanks a lot.
Best regards
Thomas
>
> On 01/15, Thomas Zimmermann wrote:
>> VBLANK callbacks in struct drm_driver are deprecated in favor of
>> their equivalents in struct drm_crtc_funcs. Convert vkms over.
>>
>> Signed-off-by: Thomas Zimmermann
>> ---
>> drivers/gpu/drm/vkms/vkms_crtc.c | 9 ++---
>> drivers/gpu/drm/vkms/vkms_drv.c | 1 -
>> drivers/gpu/drm/vkms/vkms_drv.h | 4
>> 3 files changed, 6 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
>> b/drivers/gpu/drm/vkms/vkms_crtc.c
>> index 74f703b8d22a..ac85e17428f8 100644
>> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
>> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
>> @@ -76,10 +76,12 @@ static void vkms_disable_vblank(struct drm_crtc *crtc)
>> hrtimer_cancel(&out->vblank_hrtimer);
>> }
>>
>> -bool vkms_get_vblank_timestamp(struct drm_device *dev, unsigned int pipe,
>> - int *max_error, ktime_t *vblank_time,
>> - bool in_vblank_irq)
>> +static bool vkms_get_vblank_timestamp(struct drm_crtc *crtc,
>> + int *max_error, ktime_t *vblank_time,
>> + bool in_vblank_irq)
>> {
>> +struct drm_device *dev = crtc->dev;
>> +unsigned int pipe = crtc->index;
>> struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev);
>> struct vkms_output *output = &vkmsdev->output;
>> struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
>> @@ -154,6 +156,7 @@ static const struct drm_crtc_funcs vkms_crtc_funcs = {
>> .atomic_destroy_state = vkms_atomic_crtc_destroy_state,
>> .enable_vblank = vkms_enable_vblank,
>> .disable_vblank = vkms_disable_vblank,
>> +.get_vblank_timestamp = vkms_get_vblank_timestamp,
>> .get_crc_sources= vkms_get_crc_sources,
>> .set_crc_source = vkms_set_crc_source,
>> .verify_crc_source = vkms_verify_crc_source,
>> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c
>> b/drivers/gpu/drm/vkms/vkms_drv.c
>> index 25bd7519295f..860de052e820 100644
>> --- a/drivers/gpu/drm/vkms/vkms_drv.c
>> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
>> @@ -103,7 +103,6 @@ static struct drm_driver vkms_driver = {
>> .dumb_create= vkms_dumb_create,
>> .gem_vm_ops = &vkms_gem_vm_ops,
>> .gem_free_object_unlocked = vkms_gem_free_object,
>> -.get_vblank_timestamp = vkms_get_vblank_timestamp,
>> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>> .gem_prime_import_sg_table = vkms_prime_import_sg_table,
>>
>> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h
>> b/drivers/gpu/drm/vkms/vkms_drv.h
>> index 7d52e24564db..eda04ffba7b1 100644
>> --- a/drivers/gpu/drm/vkms/vkms_drv.h
>> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
>> @@ -111,10 +111,6 @@ struct vkms_gem_object {
>> int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
>> struct drm_plane *primary, struct drm_plane *cursor);
>>
>> -bool vkms_get_vblank_timestamp(struct drm_device *dev, unsigned int pipe,
>> - int *max_error, ktime_t *vblank_time,
>> - bool in_vblank_irq);
>> -
>> int vkms_output_init(struct vkms_device *vkmsdev, int index);
>>
>> struct drm_plane *vkms_plane_init(struct vkms_device *vkmsdev,
>> --
>> 2.24.1
>>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/amd/display: fix for-loop with incorrectly sized loop counter
From: Colin Ian King
A for-loop is iterating from 0 up to 1000 however the loop variable count
is a u8 and hence not large enough. Fix this by making count an int.
Also remove the redundant initialization of count since this is never used
and add { } on the loop statement make the loop block clearer.
Addresses-Coverity: ("Operands don't affect result")
Fixes: ed581a0ace44 ("drm/amd/display: wait for update when setting dpg test
pattern")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 6ab298c65247..cbed738a4246 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -3680,7 +3680,7 @@ static void set_crtc_test_pattern(struct dc_link *link,
struct pipe_ctx *odm_pipe;
enum controller_dp_color_space controller_color_space;
int opp_cnt = 1;
- uint8_t count = 0;
+ int count;
switch (test_pattern_color_space) {
case DP_TEST_PATTERN_COLOR_SPACE_RGB:
@@ -3725,11 +3725,12 @@ static void set_crtc_test_pattern(struct dc_link *link,
width,
height);
/* wait for dpg to blank pixel data with test pattern */
- for (count = 0; count < 1000; count++)
+ for (count = 0; count < 1000; count++) {
if (opp->funcs->dpg_is_blanked(opp))
break;
else
udelay(100);
+ }
}
}
break;
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206017] Kernel 5.4.x unusable with GUI due to crashes (some hard)
https://bugzilla.kernel.org/show_bug.cgi?id=206017 Paul (paul.e.hi...@outlook.com) changed: What|Removed |Added CC||paul.e.hi...@outlook.com --- Comment #13 from Paul (paul.e.hi...@outlook.com) --- Hello! I am experiencing the same issue on 5.4.10 (Fedora 31, KDE Spin). I'm going to attempt the 'amdgpu.noretry=0' fix later today. I made the below bug report with Fedora: https://ask.fedoraproject.org/t/fedora-kde-amdgpu-issue/5026 Summarized: gpu: Radeon Vega 10 Issue: I discovered a lot of these entries within journalctl and dmesg after gui freezes: kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but soft recovered kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out! Thank you! -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/mst: Don't do atomic checks over disabled managers
Thanks for the catch! Makes sense to skip disabled managers there, but I wonder why it didn't cause a crash with amdgpu. Anyways looks good to me. Acked-by: Mikita Lipski On 1/16/20 8:58 PM, José Roberto de Souza wrote: When a main MST port is disconnected drivers should call drm_dp_mst_topology_mgr_set_mst() disabling the MST manager, this function will set manager mst_primary to NULL and it will cause the crash bellow on the next atomic check when trying to access mst_primary->port. As there is no use in running checks over managers that are not active this patch will skip it. [ 305.616450] [drm:drm_dp_mst_atomic_check] [MST PORT:cc2049e9] releases all VCPI slots [ 305.625085] [drm:drm_dp_mst_atomic_check] [MST PORT:020ab43e] releases all VCPI slots [ 305.633729] [drm:drm_dp_mst_atomic_check] [MST MGR:cdd467d4] mst state b67672eb VCPI avail=63 used=0 [ 305.644405] BUG: kernel NULL pointer dereference, address: 0030 [ 305.651448] #PF: supervisor read access in kernel mode [ 305.656640] #PF: error_code(0x) - not-present page [ 305.661807] PGD 0 P4D 0 [ 305.664396] Oops: [#1] PREEMPT SMP NOPTI [ 305.668789] CPU: 3 PID: 183 Comm: kworker/3:2 Not tainted 5.5.0-rc6+ #1404 [ 305.675703] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3201.A00.1905140358 05/14/2019 [ 305.689425] Workqueue: events drm_dp_delayed_destroy_work [ 305.694874] RIP: 0010:drm_dp_mst_atomic_check+0x138/0x2c0 [ 305.700306] Code: 00 00 00 41 29 d9 41 89 d8 4c 89 fa 4c 89 f1 48 c7 c6 b0 b1 34 82 bf 10 00 00 00 45 31 ed e8 3f 99 02 00 4d 8b bf 80 04 00 00 <49> 8b 47 30 49 8d 5f 30 4c 8d 60 e8 48 39 c3 74 35 49 8b 7c 24 28 [ 305.719169] RSP: 0018:c90001687b58 EFLAGS: 00010246 [ 305.724434] RAX: RBX: 003f RCX: [ 305.731611] RDX: RSI: 88849fba8cb8 RDI: [ 305.738785] RBP: R08: R09: 0001 [ 305.745962] R10: c900016879a0 R11: c900016879a5 R12: [ 305.753139] R13: R14: 8884905c9bc0 R15: [ 305.760315] FS: () GS:88849fb8() knlGS: [ 305.768452] CS: 0010 DS: ES: CR0: 80050033 [ 305.774263] CR2: 0030 CR3: 05610006 CR4: 00760ee0 [ 305.781441] PKRU: 5554 [ 305.784228] Call Trace: [ 305.786739] intel_atomic_check+0xb2e/0x2560 [i915] [ 305.791678] ? printk+0x53/0x6a [ 305.794856] ? drm_atomic_check_only+0x3e/0x810 [ 305.799417] ? __drm_dbg+0x82/0x90 [ 305.802848] drm_atomic_check_only+0x56a/0x810 [ 305.807322] drm_atomic_commit+0xe/0x50 [ 305.811185] drm_client_modeset_commit_atomic+0x1e2/0x250 [ 305.816619] drm_client_modeset_commit_force+0x4d/0x180 [ 305.821921] drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0 [ 305.827963] drm_fb_helper_set_par+0x2b/0x40 [ 305.832265] drm_fb_helper_hotplug_event.part.0+0xb2/0xd0 [ 305.837755] drm_kms_helper_hotplug_event+0x21/0x30 [ 305.842694] process_one_work+0x25b/0x5b0 [ 305.846735] worker_thread+0x4b/0x3b0 [ 305.850439] kthread+0x100/0x140 [ 305.853690] ? process_one_work+0x5b0/0x5b0 [ 305.857901] ? kthread_park+0x80/0x80 [ 305.861588] ret_from_fork+0x24/0x50 [ 305.865202] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 btusb btrtl btbcm btintel bluetooth prime_numbers snd_hda_intel snd_intel_dspcfg snd_hda_codec e1000e snd_hwdep snd_hda_core thunderbolt mei_hdcp mei_me asix cdc_ether x86_pkg_temp_thermal r8152 mei coretemp usbnet snd_pcm mii crct10dif_pclmul ptp crc32_pclmul ecdh_generic ghash_clmulni_intel pps_core ecc i2c_i801 intel_lpss_pci [ 305.903096] CR2: 0030 [ 305.906431] ---[ end trace 70ee364eed801cb0 ]--- [ 305.940816] RIP: 0010:drm_dp_mst_atomic_check+0x138/0x2c0 [ 305.946261] Code: 00 00 00 41 29 d9 41 89 d8 4c 89 fa 4c 89 f1 48 c7 c6 b0 b1 34 82 bf 10 00 00 00 45 31 ed e8 3f 99 02 00 4d 8b bf 80 04 00 00 <49> 8b 47 30 49 8d 5f 30 4c 8d 60 e8 48 39 c3 74 35 49 8b 7c 24 28 [ 305.965125] RSP: 0018:c90001687b58 EFLAGS: 00010246 [ 305.970382] RAX: RBX: 003f RCX: [ 305.977571] RDX: RSI: 88849fba8cb8 RDI: [ 305.984747] RBP: R08: R09: 0001 [ 305.991921] R10: c900016879a0 R11: c900016879a5 R12: [ 305.999099] R13: R14: 8884905c9bc0 R15: [ 306.006271] FS: () GS:88849fb8() knlGS: [ 306.014407] CS: 0010 DS: ES: CR0: 80050033 [ 306.020185] CR2: 0030 CR3: 00048b3aa003 CR4: 00760ee0 [ 306.027404] PKRU: 5554 [ 306.030127] BUG: sleeping function called from invalid context at
Re: [PATCH 0/4] drm/i915/display: conversion to new logging macros.
On Thu, 16 Jan 2020, Wambui Karuga wrote: > This series converts the printk based logging macros in > drm/i915/display/intel_display.c to the new struct drm_device based > logging macros. This change was split into four for manageability and > due to the size of drm/i915/display/intel_display.c. Please still write more descriptive commit messages than "part N". What are your basing your patches on? Our CI uses drm-tip, and it's failing to apply the patches. BR, Jani. > > Wambui Karuga (4): > drm/i915/display: conversion to new logging macros part 1 > drm/i915/display: conversion to new logging macros part 2 > drm/i915/display: conversion to new logging macros part 3 > drm/i915/display: convert to new logging macros part 4. > > drivers/gpu/drm/i915/display/intel_display.c | 1021 ++ > 1 file changed, 596 insertions(+), 425 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Do things work any better when using the radeon kernel driver rather than amdgpu? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix i915_error_state_store error defination
Hi Jani, > >> Reported-by: Hulk Robot > > > > I've never been a fan of non human accounts, we had this discussion > > already in a different mailing list. Could you please find a > > different way of giving credit to your CI system? > > I don't actually mind for Reported-by credits. The history is full of > things like: > > Reported-by: kbuild test robot > Reported-by: syzbot+ec24e95ea483de0a2...@syzkaller.appspotmail.com That's just commit log unnecessary pollution, unwanted mail reference... no one will ever answer at l...@intel.com, why reference it, then? > Care to reference the discussion? Here in the Samsung list we had a discussion with another Huawei developer about the Hulk Robot: https://lkml.org/lkml/2019/9/4/635 Andi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] video: fbdev: sh_mobile_lcdcfb: fix sparse warnings about using incorrect types
On Thu, Jan 16, 2020 at 3:51 PM Bartlomiej Zolnierkiewicz
wrote:
> Use ->screen_buffer instead of ->screen_base to fix sparse warnings.
>
> [ Please see commit 17a7b0b4d974 ("fb.h: Provide alternate screen_base
> pointer") for details. ]
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] video: fbdev: sh_mobile_lcdcfb: add COMPILE_TEST support
On Thu, Jan 16, 2020 at 3:52 PM Bartlomiej Zolnierkiewicz
wrote:
> Add COMPILE_TEST support to sh_mobile_lcdcfb driver for better compile
> testing coverage.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix i915_error_state_store error defination
On Fri, 17 Jan 2020, Andi Shyti wrote: > Hi Jani, > >> >> Reported-by: Hulk Robot >> > >> > I've never been a fan of non human accounts, we had this discussion >> > already in a different mailing list. Could you please find a >> > different way of giving credit to your CI system? >> >> I don't actually mind for Reported-by credits. The history is full of >> things like: >> >> Reported-by: kbuild test robot >> Reported-by: syzbot+ec24e95ea483de0a2...@syzkaller.appspotmail.com > > That's just commit log unnecessary pollution, unwanted mail > reference... no one will ever answer at l...@intel.com, why > reference it, then? It's not about that, it's about giving credit to whom credit is due. >> Care to reference the discussion? > > Here in the Samsung list we had a discussion with another Huawei > developer about the Hulk Robot: > > https://lkml.org/lkml/2019/9/4/635 Well, there's no consensus there either. Again, if they want to use that Reported-by: line, I'm fine with it. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/amd/display: fix for-loop with incorrectly sized loop counter
Am 17.01.2020 14:33, schrieb Colin King:
> From: Colin Ian King
>
> A for-loop is iterating from 0 up to 1000 however the loop variable count
> is a u8 and hence not large enough. Fix this by making count an int.
> Also remove the redundant initialization of count since this is never used
> and add { } on the loop statement make the loop block clearer.
>
> Addresses-Coverity: ("Operands don't affect result")
> Fixes: ed581a0ace44 ("drm/amd/display: wait for update when setting dpg test
> pattern")
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> index 6ab298c65247..cbed738a4246 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> @@ -3680,7 +3680,7 @@ static void set_crtc_test_pattern(struct dc_link *link,
> struct pipe_ctx *odm_pipe;
> enum controller_dp_color_space controller_color_space;
> int opp_cnt = 1;
> - uint8_t count = 0;
> + int count;
>
> switch (test_pattern_color_space) {
> case DP_TEST_PATTERN_COLOR_SPACE_RGB:
> @@ -3725,11 +3725,12 @@ static void set_crtc_test_pattern(struct dc_link
> *link,
> width,
> height);
> /* wait for dpg to blank pixel data with test pattern */
> - for (count = 0; count < 1000; count++)
> + for (count = 0; count < 1000; count++) {
> if (opp->funcs->dpg_is_blanked(opp))
> break;
> else
> udelay(100);
> + }
> }
> }
> break;
Nitpick:
the else is useless you can remove it.
re,
wh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #2 from kentosama (kentos...@whiteninjastudio.com) --- Hello, with the radeonsi driver, the performance is lower than the amdgpu driver. On the same scene in Tomb Raider, the graphics card displays ~ 10fps. I have a lower score with glmark2: kentosama@teradrive:~$ glmark2 -b "terrain" === glmark2 2017.07 === OpenGL Information GL_VENDOR: X.Org GL_RENDERER: AMD TAHITI (DRM 2.50.0, 5.4.0-2-amd64, LLVM 9.0.1) GL_VERSION:4.5 (Compatibility Profile) Mesa 19.3.2 === [terrain] : FPS: 1280 FrameTime: 0.781 ms === glmark2 Score: 1280 === But glxgears shows a better result kentosama@teradrive:~$ vblank_mode=0 glxgears ATTENTION: default value of option vblank_mode overridden by environment. 28092 frames in 5.0 seconds = 5618.325 FPS 29931 frames in 5.0 seconds = 5985.997 FPS 28614 frames in 5.0 seconds = 5722.756 FPS 29221 frames in 5.0 seconds = 5844.179 FPS 28387 frames in 5.0 seconds = 5677.356 FPS 29344 frames in 5.0 seconds = 5868.745 FPS 29921 frames in 5.0 seconds = 5984.118 FPS 28185 frames in 5.0 seconds = 5636.796 FPS 29347 frames in 5.0 seconds = 5869.202 FPS 29644 frames in 5.0 seconds = 5928.789 FPS 29234 frames in 5.0 seconds = 5846.652 FPS 28770 frames in 5.0 seconds = 5753.883 FPS 29134 frames in 5.0 seconds = 5826.747 FPS 29706 frames in 5.0 seconds = 5941.031 FPS 29344 frames in 5.0 seconds = 5868.780 FPS 29803 frames in 5.0 seconds = 5960.432 FPS 29425 frames in 5.0 seconds = 5884.889 FPS -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) --- radeonsi is the mesa OpenGL driver and runs over both radeon and amdgpu. Are you actually using the radeon kernel driver? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 12/18] drm/dp_mst: Add branch bandwidth validation to MST atomic check
On Fri, Dec 13, 2019 at 3:09 PM wrote: > > From: Mikita Lipski > Hi Mikita, Unfortunately this patch causes a crash on my i915 device when I unplug my MST hub. The panic is below. [ 38.514014] BUG: kernel NULL pointer dereference, address: 0030 [ 38.521801] #PF: supervisor read access in kernel mode [ 38.527556] #PF: error_code(0x) - not-present page [ 38.533299] PGD 0 P4D 0 [ 38.536127] Oops: [#1] PREEMPT SMP PTI [ 38.540798] CPU: 1 PID: 1324 Comm: DrmThread Not tainted 5.5.0-rc6-02273-g9bb4096398e7 #36 [ 38.550040] Hardware name: Google Fizz/Fizz, BIOS Google_Fizz.10139.39.0 01/04/2018 [ 38.558606] RIP: 0010:drm_dp_mst_atomic_check_bw_limit+0x11/0x102 [ 38.565418] Code: 05 ff cb bf 19 48 f7 f6 c3 0f 1f 44 00 00 55 b8 0b 80 ff 0f 48 89 e5 5d c3 55 48 89 e5 41 57 41 56 41 55 41 54 4c 8d 77 30 53 <48> 8b 47 30 49 89 fd 49 89 f7 45 31 e4 48 8d 58 e8 48 8d 53 18 4c [ 38.586422] RSP: 0018:c9000139f9d8 EFLAGS: 00010282 [ 38.592264] RAX: RBX: 888272aeac88 RCX: 888236f529e0 [ 38.600242] RDX: 888272aeac88 RSI: 888236f529e0 RDI: [ 38.608220] RBP: c9000139fa00 R08: 0031 R09: 000e [ 38.616198] R10: 888236f529e8 R11: 8882621f3440 R12: [ 38.624176] R13: 888236f529d0 R14: 0030 R15: 888236f529e0 [ 38.632153] FS: 7cd9229ce700() GS:888276c8() knlGS: [ 38.641193] CS: 0010 DS: ES: CR0: 80050033 [ 38.647616] CR2: 0030 CR3: 0002618e8004 CR4: 003606e0 [ 38.655593] Call Trace: [ 38.658329] drm_dp_mst_atomic_check+0x152/0x16d [ 38.663484] intel_atomic_check+0xcfe/0x1e6f [ 38.668259] ? trace_hardirqs_on+0x28/0x3d [ 38.672835] ? intel_pipe_config_compare+0x1b38/0x1b38 [ 38.678580] drm_atomic_check_only+0x5ab/0x70f [ 38.683547] ? drm_atomic_set_crtc_for_connector+0xf5/0x102 [ 38.689778] ? drm_atomic_helper_shutdown+0xb6/0xb6 [ 38.695221] drm_atomic_commit+0x18/0x53 [ 38.699604] drm_atomic_helper_set_config+0x5a/0x70 [ 38.705057] drm_mode_setcrtc+0x2ab/0x833 [ 38.709537] ? rcu_read_unlock+0x57/0x57 [ 38.713920] ? drm_mode_getcrtc+0x173/0x173 [ 38.718594] drm_ioctl+0x2e5/0x424 [ 38.722392] ? drm_mode_getcrtc+0x173/0x173 [ 38.727069] vfs_ioctl+0x21/0x2f [ 38.730675] do_vfs_ioctl+0x5fb/0x61e [ 38.734766] ksys_ioctl+0x55/0x75 [ 38.738469] __x64_sys_ioctl+0x1a/0x1e [ 38.742659] do_syscall_64+0x5c/0x6d [ 38.746653] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 38.752298] RIP: 0033:0x7cd92552d497 [ 38.756291] Code: 8a 66 90 48 8b 05 d1 d9 2b 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 d9 2b 00 f7 d8 64 89 01 48 [ 38.777296] RSP: 002b:7cd9229cd698 EFLAGS: 0246 ORIG_RAX: 0010 [ 38.785762] RAX: ffda RBX: 20323373da80 RCX: 7cd92552d497 [ 38.793740] RDX: 7cd9229cd6d0 RSI: c06864a2 RDI: 001c [ 38.801717] RBP: 7cd9229cd6c0 R08: R09: [ 38.809693] R10: R11: 0246 R12: 001c [ 38.817670] R13: R14: 7cd9229cd6d0 R15: c06864a2 [ 38.825642] Modules linked in: xt_nat cdc_ether r8152 bridge stp llc usbhid btusb btrtl btbcm btintel bluetooth asix usbnet ecdh_generic ecc mii snd_soc_hdac_hdmi snd_soc_dmic xhci_pci xhci_hcd snd_soc_skl snd_soc_sst_ipc snd_soc_sst_dsp snd_hda_ext_core snd_intel_dspcfg snd_hda_core usbcore usb_common acpi_als kfifo_buf industrialio xt_MASQUERADE iptable_nat nf_nat xt_mark fuse ip6table_filter iwlmvm mac80211 r8169 realtek iwlwifi lzo_rle lzo_compress zram cfg80211 [ 38.871839] CR2: 0030 [ 38.875542] ---[ end trace 6bb39ec52e30c7cb ]--- [ 38.886142] RIP: 0010:drm_dp_mst_atomic_check_bw_limit+0x11/0x102 [ 38.892957] Code: 05 ff cb bf 19 48 f7 f6 c3 0f 1f 44 00 00 55 b8 0b 80 ff 0f 48 89 e5 5d c3 55 48 89 e5 41 57 41 56 41 55 41 54 4c 8d 77 30 53 <48> 8b 47 30 49 89 fd 49 89 f7 45 31 e4 48 8d 58 e8 48 8d 53 18 4c [ 38.913964] RSP: 0018:c9000139f9d8 EFLAGS: 00010282 [ 38.919804] RAX: RBX: 888272aeac88 RCX: 888236f529e0 [ 38.927784] RDX: 888272aeac88 RSI: 888236f529e0 RDI: [ 38.935765] RBP: c9000139fa00 R08: 0031 R09: 000e [ 38.943733] R10: 888236f529e8 R11: 8882621f3440 R12: [ 38.951712] R13: 888236f529d0 R14: 0030 R15: 888236f529e0 [ 38.959692] FS: 7cd9229ce700() GS:888276c8() knlGS: [ 38.968730] CS: 0010 DS: ES: CR0: 80050033 [ 38.975144] CR2: 0030 CR3: 0002618e8004 CR4: 003606e0 [ 38.983121] Kernel panic - not syncing: Fatal exception [ 38.988967] Kernel Offset: disabled [ 38.998280]
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #4 from Michel Dänzer (mic...@daenzer.net) --- (In reply to Alex Deucher from comment #3) > Are you actually using the radeon kernel driver? "DRM 2.50.0" says yes. :) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 12/18] drm/dp_mst: Add branch bandwidth validation to MST atomic check
On 1/17/20 10:09 AM, Sean Paul wrote: On Fri, Dec 13, 2019 at 3:09 PM wrote: From: Mikita Lipski Hi Mikita, Unfortunately this patch causes a crash on my i915 device when I unplug my MST hub. The panic is below. Hi Sean, I thought this issue was fixed by Wayne Lin in https://patchwork.freedesktop.org/patch/346736/?series=71388&rev=1 but now I checked it seems it never got pushed. I will resend Wayne's patch once again. Thanks Mikita [ 38.514014] BUG: kernel NULL pointer dereference, address: 0030 [ 38.521801] #PF: supervisor read access in kernel mode [ 38.527556] #PF: error_code(0x) - not-present page [ 38.533299] PGD 0 P4D 0 [ 38.536127] Oops: [#1] PREEMPT SMP PTI [ 38.540798] CPU: 1 PID: 1324 Comm: DrmThread Not tainted 5.5.0-rc6-02273-g9bb4096398e7 #36 [ 38.550040] Hardware name: Google Fizz/Fizz, BIOS Google_Fizz.10139.39.0 01/04/2018 [ 38.558606] RIP: 0010:drm_dp_mst_atomic_check_bw_limit+0x11/0x102 [ 38.565418] Code: 05 ff cb bf 19 48 f7 f6 c3 0f 1f 44 00 00 55 b8 0b 80 ff 0f 48 89 e5 5d c3 55 48 89 e5 41 57 41 56 41 55 41 54 4c 8d 77 30 53 <48> 8b 47 30 49 89 fd 49 89 f7 45 31 e4 48 8d 58 e8 48 8d 53 18 4c [ 38.586422] RSP: 0018:c9000139f9d8 EFLAGS: 00010282 [ 38.592264] RAX: RBX: 888272aeac88 RCX: 888236f529e0 [ 38.600242] RDX: 888272aeac88 RSI: 888236f529e0 RDI: [ 38.608220] RBP: c9000139fa00 R08: 0031 R09: 000e [ 38.616198] R10: 888236f529e8 R11: 8882621f3440 R12: [ 38.624176] R13: 888236f529d0 R14: 0030 R15: 888236f529e0 [ 38.632153] FS: 7cd9229ce700() GS:888276c8() knlGS: [ 38.641193] CS: 0010 DS: ES: CR0: 80050033 [ 38.647616] CR2: 0030 CR3: 0002618e8004 CR4: 003606e0 [ 38.655593] Call Trace: [ 38.658329] drm_dp_mst_atomic_check+0x152/0x16d [ 38.663484] intel_atomic_check+0xcfe/0x1e6f [ 38.668259] ? trace_hardirqs_on+0x28/0x3d [ 38.672835] ? intel_pipe_config_compare+0x1b38/0x1b38 [ 38.678580] drm_atomic_check_only+0x5ab/0x70f [ 38.683547] ? drm_atomic_set_crtc_for_connector+0xf5/0x102 [ 38.689778] ? drm_atomic_helper_shutdown+0xb6/0xb6 [ 38.695221] drm_atomic_commit+0x18/0x53 [ 38.699604] drm_atomic_helper_set_config+0x5a/0x70 [ 38.705057] drm_mode_setcrtc+0x2ab/0x833 [ 38.709537] ? rcu_read_unlock+0x57/0x57 [ 38.713920] ? drm_mode_getcrtc+0x173/0x173 [ 38.718594] drm_ioctl+0x2e5/0x424 [ 38.722392] ? drm_mode_getcrtc+0x173/0x173 [ 38.727069] vfs_ioctl+0x21/0x2f [ 38.730675] do_vfs_ioctl+0x5fb/0x61e [ 38.734766] ksys_ioctl+0x55/0x75 [ 38.738469] __x64_sys_ioctl+0x1a/0x1e [ 38.742659] do_syscall_64+0x5c/0x6d [ 38.746653] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 38.752298] RIP: 0033:0x7cd92552d497 [ 38.756291] Code: 8a 66 90 48 8b 05 d1 d9 2b 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 d9 2b 00 f7 d8 64 89 01 48 [ 38.777296] RSP: 002b:7cd9229cd698 EFLAGS: 0246 ORIG_RAX: 0010 [ 38.785762] RAX: ffda RBX: 20323373da80 RCX: 7cd92552d497 [ 38.793740] RDX: 7cd9229cd6d0 RSI: c06864a2 RDI: 001c [ 38.801717] RBP: 7cd9229cd6c0 R08: R09: [ 38.809693] R10: R11: 0246 R12: 001c [ 38.817670] R13: R14: 7cd9229cd6d0 R15: c06864a2 [ 38.825642] Modules linked in: xt_nat cdc_ether r8152 bridge stp llc usbhid btusb btrtl btbcm btintel bluetooth asix usbnet ecdh_generic ecc mii snd_soc_hdac_hdmi snd_soc_dmic xhci_pci xhci_hcd snd_soc_skl snd_soc_sst_ipc snd_soc_sst_dsp snd_hda_ext_core snd_intel_dspcfg snd_hda_core usbcore usb_common acpi_als kfifo_buf industrialio xt_MASQUERADE iptable_nat nf_nat xt_mark fuse ip6table_filter iwlmvm mac80211 r8169 realtek iwlwifi lzo_rle lzo_compress zram cfg80211 [ 38.871839] CR2: 0030 [ 38.875542] ---[ end trace 6bb39ec52e30c7cb ]--- [ 38.886142] RIP: 0010:drm_dp_mst_atomic_check_bw_limit+0x11/0x102 [ 38.892957] Code: 05 ff cb bf 19 48 f7 f6 c3 0f 1f 44 00 00 55 b8 0b 80 ff 0f 48 89 e5 5d c3 55 48 89 e5 41 57 41 56 41 55 41 54 4c 8d 77 30 53 <48> 8b 47 30 49 89 fd 49 89 f7 45 31 e4 48 8d 58 e8 48 8d 53 18 4c [ 38.913964] RSP: 0018:c9000139f9d8 EFLAGS: 00010282 [ 38.919804] RAX: RBX: 888272aeac88 RCX: 888236f529e0 [ 38.927784] RDX: 888272aeac88 RSI: 888236f529e0 RDI: [ 38.935765] RBP: c9000139fa00 R08: 0031 R09: 000e [ 38.943733] R10: 888236f529e8 R11: 8882621f3440 R12: [ 38.951712] R13: 888236f529d0 R14: 0030 R15: 888236f529e0 [ 38.959692] FS: 7cd9229ce700() GS:888276c8() knlGS:0
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #5 from kentosama (kentos...@whiteninjastudio.com) --- (In reply to Alex Deucher from comment #3) > radeonsi is the mesa OpenGL driver and runs over both radeon and amdgpu. > Are you actually using the radeon kernel driver? Yes, i use the radeon driver after comment this line in /etc/modprobe.d/blacklist.conf : #blacklist radeon Actually i run on radeon driver. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/2] drm/modes: Apply video parameters with only reflect option
At the moment, video mode parameters like video=540x960,reflect_x, (without rotation set) are not taken into account when applying the mode in drm_client_modeset.c. One of the reasons for this is that the calculation that combines the panel_orientation with cmdline->rotation_reflection does not handle the case when cmdline->rotation_reflection does not have any rotation set. (i.e. cmdline->rotation_reflection & DRM_MODE_ROTATE_MASK == 0) However, we really should not generate such a value in the first place. Rotation values should have exactly one rotation angle set (DRM_MODE_ROTATE_0 for "no rotation"). This patch set changes the command line parser to make sure that we generate only valid rotation values (defaulting to DRM_MODE_ROTATE_0). Finally it allows DRM_MODE_ROTATE_0 when applying the rotation from the video mode parameters to make parameters without rotation work correctly. Changes in v3: - Fix the cmdline parser to generate only valid rotation values instead. (There should be exactly one rotation angle in a rotation value.) - Removed most of the original patch - combining the rotations works correctly if we only have valid rotation values v2: https://lore.kernel.org/dri-devel/20191216171017.173326-1-step...@gerhold.net/ - Clarified commit message - parameters are parsed correctly, but not taken into account when applying the mode. v1: https://lore.kernel.org/dri-devel/20191209183254.211428-1-step...@gerhold.net/ Stephan Gerhold (2): drm/modes: Make sure to parse valid rotation value from cmdline drm/modes: Allow DRM_MODE_ROTATE_0 when applying video mode parameters drivers/gpu/drm/drm_client_modeset.c | 3 ++- drivers/gpu/drm/drm_modes.c | 7 +++ drivers/gpu/drm/selftests/drm_cmdline_selftests.h | 1 + .../gpu/drm/selftests/test-drm_cmdline_parser.c | 15 +-- 4 files changed, 23 insertions(+), 3 deletions(-) -- 2.25.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/2] drm/modes: Make sure to parse valid rotation value from cmdline
A rotation value should have exactly one rotation angle.
At the moment there is no validation for this when parsing video=
parameters from the command line. This causes problems later on
when we try to combine the command line rotation with the panel
orientation.
To make sure that we generate a valid rotation value:
- Set DRM_MODE_ROTATE_0 by default (if no rotate= option is set)
- Validate that there is exactly one rotation angle set
(i.e. specifying the rotate= option multiple times is invalid)
Signed-off-by: Stephan Gerhold
---
drivers/gpu/drm/drm_modes.c | 7 +++
drivers/gpu/drm/selftests/drm_cmdline_selftests.h | 1 +
.../gpu/drm/selftests/test-drm_cmdline_parser.c | 15 +--
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 10336b144c72..d4d64518e11b 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1698,6 +1698,13 @@ static int drm_mode_parse_cmdline_options(const char
*str,
if (rotation && freestanding)
return -EINVAL;
+ if (!(rotation & DRM_MODE_ROTATE_MASK))
+ rotation |= DRM_MODE_ROTATE_0;
+
+ /* Make sure there is exactly one rotation defined */
+ if (!is_power_of_2(rotation & DRM_MODE_ROTATE_MASK))
+ return -EINVAL;
+
mode->rotation_reflection = rotation;
return 0;
diff --git a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
index ceac7af9a172..29e367db6118 100644
--- a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
@@ -53,6 +53,7 @@ cmdline_test(drm_cmdline_test_rotate_0)
cmdline_test(drm_cmdline_test_rotate_90)
cmdline_test(drm_cmdline_test_rotate_180)
cmdline_test(drm_cmdline_test_rotate_270)
+cmdline_test(drm_cmdline_test_rotate_multiple)
cmdline_test(drm_cmdline_test_rotate_invalid_val)
cmdline_test(drm_cmdline_test_rotate_truncated)
cmdline_test(drm_cmdline_test_hmirror)
diff --git a/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
b/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
index 520f3e66a384..d96cd890def6 100644
--- a/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
+++ b/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
@@ -856,6 +856,17 @@ static int drm_cmdline_test_rotate_270(void *ignored)
return 0;
}
+static int drm_cmdline_test_rotate_multiple(void *ignored)
+{
+ struct drm_cmdline_mode mode = { };
+
+
FAIL_ON(drm_mode_parse_command_line_for_connector("720x480,rotate=0,rotate=90",
+ &no_connector,
+ &mode));
+
+ return 0;
+}
+
static int drm_cmdline_test_rotate_invalid_val(void *ignored)
{
struct drm_cmdline_mode mode = { };
@@ -888,7 +899,7 @@ static int drm_cmdline_test_hmirror(void *ignored)
FAIL_ON(!mode.specified);
FAIL_ON(mode.xres != 720);
FAIL_ON(mode.yres != 480);
- FAIL_ON(mode.rotation_reflection != DRM_MODE_REFLECT_X);
+ FAIL_ON(mode.rotation_reflection != (DRM_MODE_ROTATE_0 |
DRM_MODE_REFLECT_X));
FAIL_ON(mode.refresh_specified);
@@ -913,7 +924,7 @@ static int drm_cmdline_test_vmirror(void *ignored)
FAIL_ON(!mode.specified);
FAIL_ON(mode.xres != 720);
FAIL_ON(mode.yres != 480);
- FAIL_ON(mode.rotation_reflection != DRM_MODE_REFLECT_Y);
+ FAIL_ON(mode.rotation_reflection != (DRM_MODE_ROTATE_0 |
DRM_MODE_REFLECT_Y));
FAIL_ON(mode.refresh_specified);
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm/modes: Allow DRM_MODE_ROTATE_0 when applying video mode parameters
At the moment, only DRM_MODE_ROTATE_180 is allowed when we try to apply the rotation from the video mode parameters. It is also useful to allow DRM_MODE_ROTATE_0 in case there is only a reflect option in the video mode parameter (e.g. video=540x960,reflect_x). DRM_MODE_ROTATE_0 means "no rotation" and should therefore not require any special handling, so we can just add it to the if condition. Signed-off-by: Stephan Gerhold --- drivers/gpu/drm/drm_client_modeset.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_client_modeset.c b/drivers/gpu/drm/drm_client_modeset.c index 895b73f23079..29367b6506a8 100644 --- a/drivers/gpu/drm/drm_client_modeset.c +++ b/drivers/gpu/drm/drm_client_modeset.c @@ -879,7 +879,8 @@ bool drm_client_rotation(struct drm_mode_set *modeset, unsigned int *rotation) * depending on the hardware this may require the framebuffer * to be in a specific tiling format. */ - if ((*rotation & DRM_MODE_ROTATE_MASK) != DRM_MODE_ROTATE_180 || + if (((*rotation & DRM_MODE_ROTATE_MASK) != DRM_MODE_ROTATE_0 && +(*rotation & DRM_MODE_ROTATE_MASK) != DRM_MODE_ROTATE_180) || !plane->rotation_property) return false; -- 2.25.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 12/18] drm/dp_mst: Add branch bandwidth validation to MST atomic check
On Fri, Jan 17, 2020 at 10:26 AM Mikita Lipski wrote: > > > > On 1/17/20 10:09 AM, Sean Paul wrote: > > On Fri, Dec 13, 2019 at 3:09 PM wrote: > >> > >> From: Mikita Lipski > >> > > > > Hi Mikita, > > Unfortunately this patch causes a crash on my i915 device when I > > unplug my MST hub. The panic is below. > > Hi Sean, > > I thought this issue was fixed by Wayne Lin in > https://patchwork.freedesktop.org/patch/346736/?series=71388&rev=1 > but now I checked it seems it never got pushed. I will resend Wayne's > patch once again. > No need to resend, I can push Wayne's patch. Thanks for the pointer, Sean > Thanks > Mikita > > > > [ 38.514014] BUG: kernel NULL pointer dereference, address: > > 0030 > > [ 38.521801] #PF: supervisor read access in kernel mode > > [ 38.527556] #PF: error_code(0x) - not-present page > > [ 38.533299] PGD 0 P4D 0 > > [ 38.536127] Oops: [#1] PREEMPT SMP PTI > > [ 38.540798] CPU: 1 PID: 1324 Comm: DrmThread Not tainted > > 5.5.0-rc6-02273-g9bb4096398e7 #36 > > [ 38.550040] Hardware name: Google Fizz/Fizz, BIOS > > Google_Fizz.10139.39.0 01/04/2018 > > [ 38.558606] RIP: 0010:drm_dp_mst_atomic_check_bw_limit+0x11/0x102 > > [ 38.565418] Code: 05 ff cb bf 19 48 f7 f6 c3 0f 1f 44 00 00 55 b8 > > 0b 80 ff 0f 48 89 e5 5d c3 55 48 89 e5 41 57 41 56 41 55 41 54 4c 8d > > 77 30 53 <48> 8b 47 30 49 89 fd 49 89 f7 45 31 e4 48 8d 58 e8 48 8d 53 > > 18 4c > > [ 38.586422] RSP: 0018:c9000139f9d8 EFLAGS: 00010282 > > [ 38.592264] RAX: RBX: 888272aeac88 RCX: > > 888236f529e0 > > [ 38.600242] RDX: 888272aeac88 RSI: 888236f529e0 RDI: > > > > [ 38.608220] RBP: c9000139fa00 R08: 0031 R09: > > 000e > > [ 38.616198] R10: 888236f529e8 R11: 8882621f3440 R12: > > > > [ 38.624176] R13: 888236f529d0 R14: 0030 R15: > > 888236f529e0 > > [ 38.632153] FS: 7cd9229ce700() GS:888276c8() > > knlGS: > > [ 38.641193] CS: 0010 DS: ES: CR0: 80050033 > > [ 38.647616] CR2: 0030 CR3: 0002618e8004 CR4: > > 003606e0 > > [ 38.655593] Call Trace: > > [ 38.658329] drm_dp_mst_atomic_check+0x152/0x16d > > [ 38.663484] intel_atomic_check+0xcfe/0x1e6f > > [ 38.668259] ? trace_hardirqs_on+0x28/0x3d > > [ 38.672835] ? intel_pipe_config_compare+0x1b38/0x1b38 > > [ 38.678580] drm_atomic_check_only+0x5ab/0x70f > > [ 38.683547] ? drm_atomic_set_crtc_for_connector+0xf5/0x102 > > [ 38.689778] ? drm_atomic_helper_shutdown+0xb6/0xb6 > > [ 38.695221] drm_atomic_commit+0x18/0x53 > > [ 38.699604] drm_atomic_helper_set_config+0x5a/0x70 > > [ 38.705057] drm_mode_setcrtc+0x2ab/0x833 > > [ 38.709537] ? rcu_read_unlock+0x57/0x57 > > [ 38.713920] ? drm_mode_getcrtc+0x173/0x173 > > [ 38.718594] drm_ioctl+0x2e5/0x424 > > [ 38.722392] ? drm_mode_getcrtc+0x173/0x173 > > [ 38.727069] vfs_ioctl+0x21/0x2f > > [ 38.730675] do_vfs_ioctl+0x5fb/0x61e > > [ 38.734766] ksys_ioctl+0x55/0x75 > > [ 38.738469] __x64_sys_ioctl+0x1a/0x1e > > [ 38.742659] do_syscall_64+0x5c/0x6d > > [ 38.746653] entry_SYSCALL_64_after_hwframe+0x49/0xbe > > [ 38.752298] RIP: 0033:0x7cd92552d497 > > [ 38.756291] Code: 8a 66 90 48 8b 05 d1 d9 2b 00 64 c7 00 26 00 00 > > 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 > > 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 d9 2b 00 f7 d8 64 89 > > 01 48 > > [ 38.777296] RSP: 002b:7cd9229cd698 EFLAGS: 0246 ORIG_RAX: > > 0010 > > [ 38.785762] RAX: ffda RBX: 20323373da80 RCX: > > 7cd92552d497 > > [ 38.793740] RDX: 7cd9229cd6d0 RSI: c06864a2 RDI: > > 001c > > [ 38.801717] RBP: 7cd9229cd6c0 R08: R09: > > > > [ 38.809693] R10: R11: 0246 R12: > > 001c > > [ 38.817670] R13: R14: 7cd9229cd6d0 R15: > > c06864a2 > > [ 38.825642] Modules linked in: xt_nat cdc_ether r8152 bridge stp > > llc usbhid btusb btrtl btbcm btintel bluetooth asix usbnet > > ecdh_generic ecc mii snd_soc_hdac_hdmi snd_soc_dmic xhci_pci xhci_hcd > > snd_soc_skl snd_soc_sst_ipc snd_soc_sst_dsp snd_hda_ext_core > > snd_intel_dspcfg snd_hda_core usbcore usb_common acpi_als kfifo_buf > > industrialio xt_MASQUERADE iptable_nat nf_nat xt_mark fuse > > ip6table_filter iwlmvm mac80211 r8169 realtek iwlwifi lzo_rle > > lzo_compress zram cfg80211 > > [ 38.871839] CR2: 0030 > > [ 38.875542] ---[ end trace 6bb39ec52e30c7cb ]--- > > [ 38.886142] RIP: 0010:drm_dp_mst_atomic_check_bw_limit+0x11/0x102 > > [ 38.892957] Code: 05 ff cb bf 19 48 f7 f6 c3 0f 1f 44 00 00 55 b8 > > 0b 80 ff 0f 48 89 e5 5d c3 55 48 89 e5 41 57 41 56 41 55 41 54 4c 8d > > 77 30 53 <48> 8b 47 30 49 89 fd 49 89 f7 45 31 e4 48 8d 58 e8 48 8d 53 > > 18 4c > > [ 38.
Re: [PATCH 0/5] Use new logging macros in drm/i915
On Thu, 09 Jan 2020, Wambui Karuga wrote: > This patchset continues the conversion to using the new struct > drm_device based logging macros in drm/i915. Pushed to drm-intel-next-queued, thanks for the patches. BR, Jani. > > Wambui Karuga (5): > drm/i915: conversion to new logging macros in i915/i915_vgpu.c > drm/i915: conversion to new logging macros in i915/intel_csr.c > drm/i915: conversion to new logging macros in i915/intel_device_info.c > drm/i915: convert to new logging macros in i915/intel_gvt.c > drm/i915: convert to new logging macros in i915/intel_memory_region.c > > drivers/gpu/drm/i915/i915_vgpu.c | 41 +- > drivers/gpu/drm/i915/intel_csr.c | 24 +++-- > drivers/gpu/drm/i915/intel_device_info.c | 25 +++-- > drivers/gpu/drm/i915/intel_gvt.c | 13 --- > drivers/gpu/drm/i915/intel_memory_region.c | 4 ++- > 5 files changed, 64 insertions(+), 43 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH AUTOSEL 5.4 002/205] drm/panfrost: Add missing check for pfdev->regulator
On Thu, Jan 16, 2020 at 04:39:37PM +, Sasha Levin wrote:
> From: Steven Price
>
> [ Upstream commit 52282163dfa651849e905886845bcf6850dd83c2 ]
This commit is effectively already in 5.4. Confusingly there were two
versions of this upstream:
52282163dfa6 ("drm/panfrost: Add missing check for pfdev->regulator")
c90f30812a79 ("drm/panfrost: Add missing check for pfdev->regulator")
It got merged both through a -fixes branch and through the normal merge
window. The two copies caused a bad merge in mainline and this was
effectively reverted in commit 603e398a3db2 ("drm/panfrost: Remove NULL
check for regulator").
c90f30812a79 is included in v5.4 so should already be in any v5.4.y
release.
Steve
>
> When modifying panfrost_devfreq_target() to support a device without a
> regulator defined I missed the check on the error path. Let's add it.
>
> Reported-by: Dan Carpenter
> Fixes: e21dd290881b ("drm/panfrost: Enable devfreq to work without regulator")
> Signed-off-by: Steven Price
> Signed-off-by: Rob Herring
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20190822093218.26014-1-steven.pr...@arm.com
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> index 12ff77dacc95..c1eb8cfe6aeb 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> @@ -53,8 +53,10 @@ static int panfrost_devfreq_target(struct device *dev,
> unsigned long *freq,
> if (err) {
> dev_err(dev, "Cannot set frequency %lu (%d)\n", target_rate,
> err);
> - regulator_set_voltage(pfdev->regulator, pfdev->devfreq.cur_volt,
> - pfdev->devfreq.cur_volt);
> + if (pfdev->regulator)
> + regulator_set_voltage(pfdev->regulator,
> + pfdev->devfreq.cur_volt,
> + pfdev->devfreq.cur_volt);
> return err;
> }
>
> --
> 2.20.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/dp_mst: Remove VCPI while disabling topology mgr
On Mon, Dec 9, 2019 at 12:56 AM Lin, Wayne wrote:
>
>
>
> > -Original Message-
> > From: Lyude Paul
> > Sent: Saturday, December 7, 2019 3:57 AM
> > To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> > amd-...@lists.freedesktop.org
> > Cc: Kazlauskas, Nicholas ; Wentland, Harry
> > ; Zuo, Jerry ;
> > sta...@vger.kernel.org
> > Subject: Re: [PATCH v2] drm/dp_mst: Remove VCPI while disabling topology
> > mgr
> >
> > On Fri, 2019-12-06 at 14:24 -0500, Lyude Paul wrote:
> > > Reviewed-by: Lyude Paul
> > >
> > > I'll go ahead and push this to drm-misc-next-fixes right now, thanks!
> >
> > Whoops-meant to say drm-misc-next here, anyway, pushed!
> Thanks for your time!
>
I'm getting the following warning on unplug with this patch:
[ 54.010099]
[ 54.011765] ==
[ 54.018670] WARNING: possible circular locking dependency detected
[ 54.025577] 5.5.0-rc6-02274-g77381c23ee63 #47 Not tainted
[ 54.031610] --
[ 54.038516] kworker/1:6/1040 is trying to acquire lock:
[ 54.044354] 888272af3228 (&mgr->payload_lock){+.+.}, at:
drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.054957]
[ 54.054957] but task is already holding lock:
[ 54.061473] 888272af3060 (&mgr->lock){+.+.}, at:
drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4
[ 54.071193]
[ 54.071193] which lock already depends on the new lock.
[ 54.071193]
[ 54.080334]
[ 54.080334] the existing dependency chain (in reverse order) is:
[ 54.088697]
[ 54.088697] -> #1 (&mgr->lock){+.+.}:
[ 54.094440]__mutex_lock+0xc3/0x498
[ 54.099015]drm_dp_mst_topology_get_port_validated+0x25/0x80
[ 54.106018]drm_dp_update_payload_part1+0xa2/0x2e2
[ 54.112051]intel_mst_pre_enable_dp+0x144/0x18f
[ 54.117791]intel_encoders_pre_enable+0x63/0x70
[ 54.123532]hsw_crtc_enable+0xa1/0x722
[ 54.128396]intel_update_crtc+0x50/0x194
[ 54.133455]skl_commit_modeset_enables+0x40c/0x540
[ 54.139485]intel_atomic_commit_tail+0x5f7/0x130d
[ 54.145418]intel_atomic_commit+0x2c8/0x2d8
[ 54.150770]drm_atomic_helper_set_config+0x5a/0x70
[ 54.156801]drm_mode_setcrtc+0x2ab/0x833
[ 54.161862]drm_ioctl+0x2e5/0x424
[ 54.166242]vfs_ioctl+0x21/0x2f
[ 54.170426]do_vfs_ioctl+0x5fb/0x61e
[ 54.175096]ksys_ioctl+0x55/0x75
[ 54.179377]__x64_sys_ioctl+0x1a/0x1e
[ 54.184146]do_syscall_64+0x5c/0x6d
[ 54.188721]entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 54.194946]
[ 54.194946] -> #0 (&mgr->payload_lock){+.+.}:
[ 54.201463]
[ 54.201463] other info that might help us debug this:
[ 54.201463]
[ 54.210410] Possible unsafe locking scenario:
[ 54.210410]
[ 54.217025]CPU0CPU1
[ 54.222082]
[ 54.227138] lock(&mgr->lock);
[ 54.230643]lock(&mgr->payload_lock);
[ 54.237742]lock(&mgr->lock);
[ 54.244062] lock(&mgr->payload_lock);
[ 54.248346]
[ 54.248346] *** DEADLOCK ***
[ 54.248346]
[ 54.254959] 7 locks held by kworker/1:6/1040:
[ 54.259822] #0: 888275c4f528 ((wq_completion)events){+.+.},
at: worker_thread+0x455/0x6e2
[ 54.269451] #1: c9000119beb0
((work_completion)(&(&dev_priv->hotplug.hotplug_work)->work)){+.+.},
at: worker_thread+0x455/0x6e2
[ 54.282768] #2: 888272a403f0 (&dev->mode_config.mutex){+.+.},
at: i915_hotplug_work_func+0x4b/0x2be
[ 54.293368] #3: 824fc6c0 (drm_connector_list_iter){.+.+},
at: i915_hotplug_work_func+0x17e/0x2be
[ 54.304061] #4: c9000119bc58 (crtc_ww_class_acquire){+.+.},
at: drm_helper_probe_detect_ctx+0x40/0xfd
[ 54.314855] #5: 888272a40470 (crtc_ww_class_mutex){+.+.}, at:
drm_modeset_lock+0x74/0xe2
[ 54.324385] #6: 888272af3060 (&mgr->lock){+.+.}, at:
drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4
[ 54.334597]
[ 54.334597] stack backtrace:
[ 54.339464] CPU: 1 PID: 1040 Comm: kworker/1:6 Not tainted
5.5.0-rc6-02274-g77381c23ee63 #47
[ 54.348893] Hardware name: Google Fizz/Fizz, BIOS
Google_Fizz.10139.39.0 01/04/2018
[ 54.357451] Workqueue: events i915_hotplug_work_func
[ 54.362995] Call Trace:
[ 54.365724] dump_stack+0x71/0x9c
[ 54.369427] check_noncircular+0x91/0xbc
[ 54.373809] ? __lock_acquire+0xc9e/0xf66
[ 54.378286] ? __lock_acquire+0xc9e/0xf66
[ 54.382763] ? lock_acquire+0x175/0x1ac
[ 54.387048] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.393177] ? __mutex_lock+0xc3/0x498
[ 54.397362] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.403492] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.409620] ? drm_dp_dpcd_access+0xd9/0x101
[ 54.414390] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.420517] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.426645] ? intel_digital_port_connected+0x34d/0x35c
[
[Bug 206141] VCE UVD ring test failed -110
https://bugzilla.kernel.org/show_bug.cgi?id=206141 --- Comment #7 from Janpieter Sollie (janpieter.sol...@dommel.be) --- Created attachment 286863 --> https://bugzilla.kernel.org/attachment.cgi?id=286863&action=edit dmesg with 2 GPUs OK, so this definitely looks like a HW failure, also tried to copy FW from working GPU to broken GPU, but it did not help. Is it possible to disable the UVD/VCE engine on the original GPU? I mean, it's not used anyway, so I might as well disable it completely to avoid these errors. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH AUTOSEL 5.4 002/205] drm/panfrost: Add missing check for pfdev->regulator
On Fri, Jan 17, 2020 at 04:12:27PM +, Steven Price wrote:
> On Thu, Jan 16, 2020 at 04:39:37PM +, Sasha Levin wrote:
> > From: Steven Price
> >
> > [ Upstream commit 52282163dfa651849e905886845bcf6850dd83c2 ]
>
> This commit is effectively already in 5.4. Confusingly there were two
> versions of this upstream:
>
> 52282163dfa6 ("drm/panfrost: Add missing check for pfdev->regulator")
> c90f30812a79 ("drm/panfrost: Add missing check for pfdev->regulator")
>
> It got merged both through a -fixes branch and through the normal merge
> window. The two copies caused a bad merge in mainline and this was
> effectively reverted in commit 603e398a3db2 ("drm/panfrost: Remove NULL
> check for regulator").
>
> c90f30812a79 is included in v5.4 so should already be in any v5.4.y
> release.
Have I mentioned this month just how much I hate the way the DRM tree
handles stable patches like this? This kind of fallout is a pain for
stable maintainers, I dred every time I see a drm patch tagged for
stable.
But we've been over this all before :(
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 206231] R9 280X low performance with all games
Owner and user of tahiti parts on amdgpu with a state of the art gfx stack poping in. I own "rise of the tomb raider" which gnu/linux port is vulkan only, and vulkan is only available with the "amdgpu" kernel module (as far as I know). I have not bought "shadow of the tomb raider", which is vulkan only too (the port was coded by the same company). I did clear "rise of the tomb raider" years ago, I cannot play it anymore because the driver seems to miscompile some shaders and does gpu vm faults (from my save file). I did open a bug. I heard 'southern islands' parts (tahiti...) do suffer from a critical "mip mapping" slowdown bug. That could explain the slugginesh of those hardware parts in 3d intense games (I did almost stop playing "rise of the tomb raider" because the 3d rendering was unpleasantly not smooth enough). If you want, we can try to compare our benchmarks? -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #6 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) --- Owner and user of tahiti parts on amdgpu with a state of the art gfx stack poping in. I own "rise of the tomb raider" which gnu/linux port is vulkan only, and vulkan is only available with the "amdgpu" kernel module (as far as I know). I have not bought "shadow of the tomb raider", which is vulkan only too (the port was coded by the same company). I did clear "rise of the tomb raider" years ago, I cannot play it anymore because the driver seems to miscompile some shaders and does gpu vm faults (from my save file). I did open a bug. I heard 'southern islands' parts (tahiti...) do suffer from a critical "mip mapping" slowdown bug. That could explain the slugginesh of those hardware parts in 3d intense games (I did almost stop playing "rise of the tomb raider" because the 3d rendering was unpleasantly not smooth enough). If you want, we can try to compare our benchmarks? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/5] dt-bindings: display: panel: Add boe tv101wum-n16 panel bindings
Hi Jitao.
Looks good, much better than the individual files.
Rob Herring is still listed as maintainer which I questioned in last
feedback.
With this resolved (kept only if Rob confirms), this is
Reviewed-by: Sam Ravnborg
On Thu, Jan 16, 2020 at 10:15:07AM +0800, Jitao Shi wrote:
> Add documentation for "boe,tv101wum-n16", "auo,kd101n80-45na",
> "boe,tv101wum-n53" and "auo,b101uan08.3" panels.
>
> Signed-off-by: Jitao Shi
> Reviewed-by: Sam Ravnborg
> ---
> .../display/panel/boe,tv101wum-nl6.yaml | 81 +++
> 1 file changed, 81 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> new file mode 100644
> index ..cc4e058f5eee
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> @@ -0,0 +1,81 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/boe,tv101wum-nl6.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: BOE TV101WUM-NL6 DSI Display Panel
> +
> +maintainers:
> + - Thierry Reding
> + - Sam Ravnborg
> + - Rob Herring
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +enum:
> +# BOE TV101WUM-NL6 10.1" WUXGA TFT LCD panel
> + - boe,tv101wum-nl6
> +# AUO KD101N80-45NA 10.1" WUXGA TFT LCD panel
> + - auo,kd101n80-45na
> +# BOE TV101WUM-N53 10.1" WUXGA TFT LCD panel
> + - boe,tv101wum-n53
> +# AUO B101UAN08.3 10.1" WUXGA TFT LCD panel
> + - auo,b101uan08.3
> +
> + reg:
> +description: the virtual channel number of a DSI peripheral
> +
> + enable-gpios:
> +description: a GPIO spec for the enable pin
> +
> + pp1800-supply:
> +description: core voltage supply
> +
> + avdd-supply:
> +description: phandle of the regulator that provides positive voltage
> +
> + avee-supply:
> +description: phandle of the regulator that provides negative voltage
> +
> + backlight:
> +description: phandle of the backlight device attached to the panel
> +
> + port: true
> +
> +required:
> + - compatible
> + - reg
> + - enable-gpios
> + - pp1800-supply
> + - avdd-supply
> + - avee-supply
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +dsi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +panel@0 {
> +compatible = "boe,tv101wum-nl6";
> +reg = <0>;
> +enable-gpios = <&pio 45 0>;
> +avdd-supply = <&ppvarn_lcd>;
> +avee-supply = <&ppvarp_lcd>;
> +pp1800-supply = <&pp1800_lcd>;
> +backlight = <&backlight_lcd0>;
> +status = "okay";
> +port {
> +panel_in: endpoint {
> +remote-endpoint = <&dsi_out>;
> +};
> +};
> +};
> +};
> +
> +...
> --
> 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] drm/msm: Add syncobj support.
On Fri, Jan 17, 2020 at 12:04:17AM +0100, Bas Nieuwenhuizen wrote:
> This
>
> 1) Enables core DRM syncobj support.
> 2) Adds options to the submission ioctl to wait/signal syncobjs.
>
> Just like the wait fence fd, this does inline waits. Using the
> scheduler would be nice but I believe it is out of scope for
> this work.
>
> Support for timeline syncobjs is implemented and the interface
> is ready for it, but I'm not enabling it yet until there is
> some code for turnip to use it.
>
> The reset is mostly in there because in the presence of waiting
> and signalling the same semaphores, resetting them after
> signalling can become very annoying.
>
> v2:
> - Fixed style issues
> - Removed a cleanup issue in a failure case
> - Moved to a copy_from_user per syncobj
A few nits, but nothing serious. This is looking good, thanks for the quick
turn around.
> Signed-off-by: Bas Nieuwenhuizen
> ---
> drivers/gpu/drm/msm/msm_drv.c| 6 +-
> drivers/gpu/drm/msm/msm_gem_submit.c | 236 ++-
> include/uapi/drm/msm_drm.h | 24 ++-
> 3 files changed, 262 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index c84f0a8b3f2c..5246b41798df 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -37,9 +37,10 @@
> * - 1.4.0 - softpin, MSM_RELOC_BO_DUMP, and GEM_INFO support to set/get
> * GEM object's debug name
> * - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
> + * - 1.6.0 - Syncobj support
> */
> #define MSM_VERSION_MAJOR1
> -#define MSM_VERSION_MINOR5
> +#define MSM_VERSION_MINOR6
> #define MSM_VERSION_PATCHLEVEL 0
>
> static const struct drm_mode_config_funcs mode_config_funcs = {
> @@ -988,7 +989,8 @@ static struct drm_driver msm_driver = {
> .driver_features= DRIVER_GEM |
> DRIVER_RENDER |
> DRIVER_ATOMIC |
> - DRIVER_MODESET,
> + DRIVER_MODESET |
> + DRIVER_SYNCOBJ,
> .open = msm_open,
> .postclose = msm_postclose,
> .lastclose = drm_fb_helper_lastclose,
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index be5327af16fa..6c7f95fc5cfd 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -8,7 +8,9 @@
> #include
> #include
>
> +#include
> #include
> +#include
>
> #include "msm_drv.h"
> #include "msm_gpu.h"
> @@ -394,6 +396,191 @@ static void submit_cleanup(struct msm_gem_submit
> *submit)
> ww_acquire_fini(&submit->ticket);
> }
>
> +
> +struct msm_submit_post_dep {
> + struct drm_syncobj *syncobj;
> + uint64_t point;
> + struct dma_fence_chain *chain;
> +};
> +
> +static int msm_wait_deps(struct drm_device *dev,
> + struct drm_file *file,
> + uint64_t in_syncobjs_addr,
> + uint32_t nr_in_syncobjs,
> + uint32_t syncobj_stride,
> + struct msm_ringbuffer *ring,
> + struct drm_syncobj ***syncobjs)
> +{
> + struct drm_msm_gem_submit_syncobj syncobj_desc = {0};
> + int ret = 0;
> + uint32_t i, j;
> +
> + *syncobjs = kcalloc(nr_in_syncobjs, sizeof(**syncobjs),
> + GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
Perfect - I think this will do everything we want - protect us against OOM death
but also not introduce artificial constraints on object counts.
> + if (!syncobjs) {
You should be able to just return -ENOMEM here.
> + ret = -ENOMEM;
> + goto out_syncobjs;
> + }
> +
> + for (i = 0; i < nr_in_syncobjs; ++i) {
> + uint64_t address = in_syncobjs_addr + i * syncobj_stride;
> + struct dma_fence *fence;
> +
> + if (copy_from_user(&syncobj_desc,
> +u64_to_user_ptr(address),
> +min(syncobj_stride, sizeof(syncobj_desc {
> + ret = -EFAULT;
> + goto out_syncobjs;
You can just use break here.
> + }
> +
> + if (syncobj_desc.point &&
> + !drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE)) {
> + ret = -EOPNOTSUPP;
> + break;
> + }
> +
> + if (syncobj_desc.flags & ~MSM_SUBMIT_SYNCOBJ_FLAGS) {
> + ret = -EINVAL;
> + break;
> + }
> +
> + ret = drm_syncobj_find_fence(file, syncobj_desc.handle,
> + syncobj_desc.point, 0, &fence);
> + if (ret)
> + break;
> +
> + if (!dma_fence_match_context(fence, ring->fctx->context))
Re: [PATCH v9 1/5] dt-bindings: display: panel: Add boe tv101wum-n16 panel bindings
Hi Jitao.
On Fri, Jan 17, 2020 at 07:08:17PM +0100, Sam Ravnborg wrote:
> Hi Jitao.
>
> Looks good, much better than the individual files.
> Rob Herring is still listed as maintainer which I questioned in last
> feedback.
>
> With this resolved (kept only if Rob confirms), this is
> Reviewed-by: Sam Ravnborg
Rob confirmed on irc that he is not a dedicated reviewer of this
binding. And furhtermore that it was OK I committed trivial panel
bindings.
Dropepd Rob and applied to drm-misc-next.
Sam
>
> On Thu, Jan 16, 2020 at 10:15:07AM +0800, Jitao Shi wrote:
> > Add documentation for "boe,tv101wum-n16", "auo,kd101n80-45na",
> > "boe,tv101wum-n53" and "auo,b101uan08.3" panels.
> >
> > Signed-off-by: Jitao Shi
> > Reviewed-by: Sam Ravnborg
> > ---
> > .../display/panel/boe,tv101wum-nl6.yaml | 81 +++
> > 1 file changed, 81 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> > b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> > new file mode 100644
> > index ..cc4e058f5eee
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> > @@ -0,0 +1,81 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/boe,tv101wum-nl6.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: BOE TV101WUM-NL6 DSI Display Panel
> > +
> > +maintainers:
> > + - Thierry Reding
> > + - Sam Ravnborg
> > + - Rob Herring
> > +
> > +allOf:
> > + - $ref: panel-common.yaml#
> > +
> > +properties:
> > + compatible:
> > +enum:
> > +# BOE TV101WUM-NL6 10.1" WUXGA TFT LCD panel
> > + - boe,tv101wum-nl6
> > +# AUO KD101N80-45NA 10.1" WUXGA TFT LCD panel
> > + - auo,kd101n80-45na
> > +# BOE TV101WUM-N53 10.1" WUXGA TFT LCD panel
> > + - boe,tv101wum-n53
> > +# AUO B101UAN08.3 10.1" WUXGA TFT LCD panel
> > + - auo,b101uan08.3
> > +
> > + reg:
> > +description: the virtual channel number of a DSI peripheral
> > +
> > + enable-gpios:
> > +description: a GPIO spec for the enable pin
> > +
> > + pp1800-supply:
> > +description: core voltage supply
> > +
> > + avdd-supply:
> > +description: phandle of the regulator that provides positive voltage
> > +
> > + avee-supply:
> > +description: phandle of the regulator that provides negative voltage
> > +
> > + backlight:
> > +description: phandle of the backlight device attached to the panel
> > +
> > + port: true
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - enable-gpios
> > + - pp1800-supply
> > + - avdd-supply
> > + - avee-supply
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +dsi {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +panel@0 {
> > +compatible = "boe,tv101wum-nl6";
> > +reg = <0>;
> > +enable-gpios = <&pio 45 0>;
> > +avdd-supply = <&ppvarn_lcd>;
> > +avee-supply = <&ppvarp_lcd>;
> > +pp1800-supply = <&pp1800_lcd>;
> > +backlight = <&backlight_lcd0>;
> > +status = "okay";
> > +port {
> > +panel_in: endpoint {
> > +remote-endpoint = <&dsi_out>;
> > +};
> > +};
> > +};
> > +};
> > +
> > +...
> > --
> > 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 0/5] add driver for "boe, tv101wum-nl6", "boe, tv101wum-n53", "auo, kd101n80-45na" and "auo, b101uan08.3" panels
Hi Jitao. Thanks for your perseverance on this. With the minor issue on the binding file resolved everything is now fine and patches are all applied to drm-misc-next. Thanks, Sam On Thu, Jan 16, 2020 at 10:15:06AM +0800, Jitao Shi wrote: > Changes since v8: > - merge the panel documents to one. > - delay move the drm_panel_of_backlight after drm_panel_init > > Changes since v7: > - base drm-misc-next branch > - fix document pass dt_binding_check > - remove backlight from panel driver > > Changes since v6: > - fix boe_panel_init err uninit. > - adjust the delay of backlight on. > > Changes since v5: > - covert the documents to yaml > - fine tune boe, tv101wum-n53 panel video timine > > Changes since v4: > - add auo,b101uan08.3 panel for this driver. > - add boe,tv101wum-n53 panel for this driver. > > Changes since v3: > - remove check enable_gpio. > - fine tune the auo,kd101n80-45na panel's power on timing. > > Changes since v2: > - correct the panel size > - remove blank line in Kconfig > - move auo,kd101n80-45na panel driver in this series. > > Changes since v1: > - update typo nl6 -> n16. > - update new panel config and makefile are added in alphabetically order. > - add the panel mode and panel info in driver data. > - merge auo,kd101n80-45a and boe,tv101wum-nl6 in one driver > > Jitao Shi (5): > dt-bindings: display: panel: Add boe tv101wum-n16 panel bindings > drm/panel: support for boe tv101wum-nl6 wuxga dsi video mode panel > drm/panel: support for auo,kd101n80-45na wuxga dsi video mode panel > drm/panel: support for boe,tv101wum-n53 wuxga dsi video mode panel > drm/panel: support for auo,b101uan08.3 wuxga dsi video mode panel > > .../display/panel/boe,tv101wum-nl6.yaml | 81 ++ > drivers/gpu/drm/panel/Kconfig | 9 + > drivers/gpu/drm/panel/Makefile| 1 + > .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 854 ++ > 4 files changed, 945 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml > create mode 100644 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c > > -- > 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] drm/msm: Add syncobj support.
On Fri, Jan 17, 2020 at 7:17 PM Jordan Crouse wrote:
>
> On Fri, Jan 17, 2020 at 12:04:17AM +0100, Bas Nieuwenhuizen wrote:
> > This
> >
> > 1) Enables core DRM syncobj support.
> > 2) Adds options to the submission ioctl to wait/signal syncobjs.
> >
> > Just like the wait fence fd, this does inline waits. Using the
> > scheduler would be nice but I believe it is out of scope for
> > this work.
> >
> > Support for timeline syncobjs is implemented and the interface
> > is ready for it, but I'm not enabling it yet until there is
> > some code for turnip to use it.
> >
> > The reset is mostly in there because in the presence of waiting
> > and signalling the same semaphores, resetting them after
> > signalling can become very annoying.
> >
> > v2:
> > - Fixed style issues
> > - Removed a cleanup issue in a failure case
> > - Moved to a copy_from_user per syncobj
>
> A few nits, but nothing serious. This is looking good, thanks for the quick
> turn around.
>
> > Signed-off-by: Bas Nieuwenhuizen
> > ---
> > drivers/gpu/drm/msm/msm_drv.c| 6 +-
> > drivers/gpu/drm/msm/msm_gem_submit.c | 236 ++-
> > include/uapi/drm/msm_drm.h | 24 ++-
> > 3 files changed, 262 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> > index c84f0a8b3f2c..5246b41798df 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.c
> > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > @@ -37,9 +37,10 @@
> > * - 1.4.0 - softpin, MSM_RELOC_BO_DUMP, and GEM_INFO support to set/get
> > * GEM object's debug name
> > * - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
> > + * - 1.6.0 - Syncobj support
> > */
> > #define MSM_VERSION_MAJOR1
> > -#define MSM_VERSION_MINOR5
> > +#define MSM_VERSION_MINOR6
> > #define MSM_VERSION_PATCHLEVEL 0
> >
> > static const struct drm_mode_config_funcs mode_config_funcs = {
> > @@ -988,7 +989,8 @@ static struct drm_driver msm_driver = {
> > .driver_features= DRIVER_GEM |
> > DRIVER_RENDER |
> > DRIVER_ATOMIC |
> > - DRIVER_MODESET,
> > + DRIVER_MODESET |
> > + DRIVER_SYNCOBJ,
> > .open = msm_open,
> > .postclose = msm_postclose,
> > .lastclose = drm_fb_helper_lastclose,
> > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > index be5327af16fa..6c7f95fc5cfd 100644
> > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > @@ -8,7 +8,9 @@
> > #include
> > #include
> >
> > +#include
> > #include
> > +#include
> >
> > #include "msm_drv.h"
> > #include "msm_gpu.h"
> > @@ -394,6 +396,191 @@ static void submit_cleanup(struct msm_gem_submit
> > *submit)
> > ww_acquire_fini(&submit->ticket);
> > }
> >
> > +
> > +struct msm_submit_post_dep {
> > + struct drm_syncobj *syncobj;
> > + uint64_t point;
> > + struct dma_fence_chain *chain;
> > +};
> > +
> > +static int msm_wait_deps(struct drm_device *dev,
> > + struct drm_file *file,
> > + uint64_t in_syncobjs_addr,
> > + uint32_t nr_in_syncobjs,
> > + uint32_t syncobj_stride,
> > + struct msm_ringbuffer *ring,
> > + struct drm_syncobj ***syncobjs)
> > +{
> > + struct drm_msm_gem_submit_syncobj syncobj_desc = {0};
> > + int ret = 0;
> > + uint32_t i, j;
> > +
> > + *syncobjs = kcalloc(nr_in_syncobjs, sizeof(**syncobjs),
> > + GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
>
> Perfect - I think this will do everything we want - protect us against OOM
> death
> but also not introduce artificial constraints on object counts.
>
> > + if (!syncobjs) {
>
> You should be able to just return -ENOMEM here.
>
> > + ret = -ENOMEM;
> > + goto out_syncobjs;
> > + }
>
> > +
> > + for (i = 0; i < nr_in_syncobjs; ++i) {
> > + uint64_t address = in_syncobjs_addr + i * syncobj_stride;
> > + struct dma_fence *fence;
> > +
> > + if (copy_from_user(&syncobj_desc,
> > +u64_to_user_ptr(address),
> > +min(syncobj_stride,
> > sizeof(syncobj_desc {
> > + ret = -EFAULT;
> > + goto out_syncobjs;
>
> You can just use break here.
>
> > + }
> > +
> > + if (syncobj_desc.point &&
> > + !drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE)) {
> > + ret = -EOPNOTSUPP;
> > + break;
> > + }
> > +
> > + if (syncobj_desc.flags & ~MSM_SUBMIT_SYNCOBJ_FLAGS) {
> > + ret = -EINVAL;
> > +
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #7 from kentosama (kentos...@whiteninjastudio.com) --- I noticed something strange. When I do the Tomb Raider benchmark, the GPU usage is 100% and I hear the fans running at full speed after a few seconds. The bench gives a result of a minimum of 37 fps, a maximum 70fps and an average of 55.3fps with the graphic parameters on ultimate. There is something wrong, because during the "slum" sequence, I get a 10/15 fps framerate with a ridiculous GPU load. screenshot : https://i.ibb.co/PrHj3hV/tombraider.jpg -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #8 from kentosama (kentos...@whiteninjastudio.com) --- (In reply to Sylvain BERTRAND from comment #6) > Owner and user of tahiti parts on amdgpu with a state of the art gfx stack > poping in. > > I own "rise of the tomb raider" which gnu/linux port is vulkan only, and > vulkan > is only available with the "amdgpu" kernel module (as far as I know). > > I have not bought "shadow of the tomb raider", which is vulkan only too (the > port was coded by the same company). > > I did clear "rise of the tomb raider" years ago, I cannot play it anymore > because the driver seems to miscompile some shaders and does gpu vm faults > (from my save file). I did open a bug. > > I heard 'southern islands' parts (tahiti...) do suffer from a critical "mip > mapping" slowdown bug. That could explain the slugginesh of those hardware > parts in 3d intense games (I did almost stop playing "rise of the tomb > raider" > because the 3d rendering was unpleasantly not smooth enough). > > If you want, we can try to compare our benchmarks? Sure, but I only have the first Tomb Raider, the one released in 2013 it seems to me. Do you know a command to record the game framerate log ? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/5] Add support for Pine64 PineTab
Hi Icenowy On Thu, Jan 16, 2020 at 11:36:31AM +0800, Icenowy Zheng wrote: > This patchset tries to add support for the PineTab tablet from Pine64. > > As it uses a specific MIPI-DSI panel, the support of the panel should be > introduced first, with its DT binding. > > Then a device tree is added. Compared to v1 of the patchset, the > accelerometer support is temporarily removed because a DT binding is > lacked (although a proper driver exists). > > Icenowy Zheng (5): > dt-bindings: vendor-prefix: add Shenzhen Feixin Photoelectics Co., Ltd > dt-bindings: panel: add Feixin K101 IM2BA02 MIPI-DSI panel > drm/panel: Add Feixin K101 IM2BA02 panel > dt-bindings: arm: sunxi: add binding for PineTab tablet > arm64: dts: allwinner: a64: add support for PineTab Thanks for the updates. I have applied the first three patches to drm-misc-next. The remaining two patches shall most likely go in via another tree. Sam > > .../devicetree/bindings/arm/sunxi.yaml| 5 + > .../display/panel/feixin,k101-im2ba02.yaml| 55 ++ > .../devicetree/bindings/vendor-prefixes.yaml | 2 + > MAINTAINERS | 6 + > arch/arm64/boot/dts/allwinner/Makefile| 1 + > .../boot/dts/allwinner/sun50i-a64-pinetab.dts | 460 +++ > drivers/gpu/drm/panel/Kconfig | 9 + > drivers/gpu/drm/panel/Makefile| 1 + > .../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 526 ++ > 9 files changed, 1065 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts > create mode 100644 drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c > > -- > 2.23.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 v3 0/2] drm/modes: Apply video parameters with only reflect option
On Fri, Jan 17, 2020 at 04:34:27PM +0100, Stephan Gerhold wrote: > At the moment, video mode parameters like video=540x960,reflect_x, > (without rotation set) are not taken into account when applying the > mode in drm_client_modeset.c. > > One of the reasons for this is that the calculation that > combines the panel_orientation with cmdline->rotation_reflection > does not handle the case when cmdline->rotation_reflection does > not have any rotation set. > (i.e. cmdline->rotation_reflection & DRM_MODE_ROTATE_MASK == 0) > > However, we really should not generate such a value in the first place. > Rotation values should have exactly one rotation angle set > (DRM_MODE_ROTATE_0 for "no rotation"). > > This patch set changes the command line parser to make sure that we generate > only valid rotation values (defaulting to DRM_MODE_ROTATE_0). > > Finally it allows DRM_MODE_ROTATE_0 when applying the rotation from > the video mode parameters to make parameters without rotation work correctly. For both, Acked-by: Maxime Ripard Thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/5] Add support for Pine64 PineTab
On Fri, Jan 17, 2020 at 07:50:12PM +0100, Sam Ravnborg wrote: > Hi Icenowy > > On Thu, Jan 16, 2020 at 11:36:31AM +0800, Icenowy Zheng wrote: > > This patchset tries to add support for the PineTab tablet from Pine64. > > > > As it uses a specific MIPI-DSI panel, the support of the panel should be > > introduced first, with its DT binding. > > > > Then a device tree is added. Compared to v1 of the patchset, the > > accelerometer support is temporarily removed because a DT binding is > > lacked (although a proper driver exists). > > > > Icenowy Zheng (5): > > dt-bindings: vendor-prefix: add Shenzhen Feixin Photoelectics Co., Ltd > > dt-bindings: panel: add Feixin K101 IM2BA02 MIPI-DSI panel > > drm/panel: Add Feixin K101 IM2BA02 panel > > dt-bindings: arm: sunxi: add binding for PineTab tablet > > arm64: dts: allwinner: a64: add support for PineTab > > Thanks for the updates. > I have applied the first three patches to drm-misc-next. > The remaining two patches shall most likely go in via another tree. queued the last two for 5.7, thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: arcfb: add COMPILE_TEST support
On Thu, Jan 16, 2020 at 03:49:07PM +0100, Bartlomiej Zolnierkiewicz wrote: > Add COMPILE_TEST support to arcfb driver for better compile > testing coverage. > > Signed-off-by: Bartlomiej Zolnierkiewicz Acked-by: Sam Ravnborg > --- > drivers/video/fbdev/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: b/drivers/video/fbdev/Kconfig > === > --- a/drivers/video/fbdev/Kconfig > +++ b/drivers/video/fbdev/Kconfig > @@ -435,7 +435,7 @@ config FB_FM2 > > config FB_ARC > tristate "Arc Monochrome LCD board support" > - depends on FB && X86 > + depends on FB && (X86 || COMPILE_TEST) > select FB_SYS_FILLRECT > select FB_SYS_COPYAREA > select FB_SYS_IMAGEBLIT > ___ > 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] video: fbdev: w100fb: fix sparse warnings
On Thu, Jan 16, 2020 at 03:53:20PM +0100, Bartlomiej Zolnierkiewicz wrote:
> * Add missing __iomem annotations where needed.
> * Make w100fb_probe() static.
> * Return NULL pointer (instead of using plain integer) in
> w100_get_xtal_tabl().
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by: Sam Ravnborg
> ---
> drivers/video/fbdev/w100fb.c | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> Index: b/drivers/video/fbdev/w100fb.c
> ===
> --- a/drivers/video/fbdev/w100fb.c
> +++ b/drivers/video/fbdev/w100fb.c
> @@ -61,9 +61,9 @@ struct w100_pll_info *w100_get_xtal_tabl
> #define BITS_PER_PIXEL16
>
> /* Remapped addresses for base cfg, memmapped regs and the frame buffer
> itself */
> -static void *remapped_base;
> -static void *remapped_regs;
> -static void *remapped_fbuf;
> +static void __iomem *remapped_base;
> +static void __iomem *remapped_regs;
> +static void __iomem *remapped_fbuf;
>
> #define REMAPPED_FB_LEN 0x15
>
> @@ -635,7 +635,7 @@ static int w100fb_resume(struct platform
> #endif
>
>
> -int w100fb_probe(struct platform_device *pdev)
> +static int w100fb_probe(struct platform_device *pdev)
> {
> int err = -EIO;
> struct w100fb_mach_info *inf;
> @@ -807,10 +807,11 @@ static int w100fb_remove(struct platform
>
> static void w100_soft_reset(void)
> {
> - u16 val = readw((u16 *) remapped_base + cfgSTATUS);
> - writew(val | 0x08, (u16 *) remapped_base + cfgSTATUS);
> + u16 val = readw((u16 __iomem *)remapped_base + cfgSTATUS);
> +
> + writew(val | 0x08, (u16 __iomem *)remapped_base + cfgSTATUS);
> udelay(100);
> - writew(0x00, (u16 *) remapped_base + cfgSTATUS);
> + writew(0x00, (u16 __iomem *)remapped_base + cfgSTATUS);
> udelay(100);
> }
>
> @@ -1022,7 +1023,8 @@ struct w100_pll_info *w100_get_xtal_tabl
> return pll_entry->pll_table;
> pll_entry++;
> } while (pll_entry->xtal_freq);
> - return 0;
> +
> + return NULL;
> }
>
>
> ___
> 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 2/2] video: fbdev: w100fb: add COMPILE_TEST support
On Thu, Jan 16, 2020 at 03:53:58PM +0100, Bartlomiej Zolnierkiewicz wrote: > Add COMPILE_TEST support to w100fb driver for better compile > testing coverage. > > Signed-off-by: Bartlomiej Zolnierkiewicz Acked-by: Sam Ravnborg > --- > drivers/video/fbdev/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: b/drivers/video/fbdev/Kconfig > === > --- a/drivers/video/fbdev/Kconfig > +++ b/drivers/video/fbdev/Kconfig > @@ -1827,7 +1827,7 @@ config FB_FSL_DIU > > config FB_W100 > tristate "W100 frame buffer support" > - depends on FB && ARCH_PXA > + depends on FB && HAS_IOMEM && (ARCH_PXA || COMPILE_TEST) > select FB_CFB_FILLRECT > select FB_CFB_COPYAREA > select FB_CFB_IMAGEBLIT > ___ > 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] video: fbdev: wm8505fb: fix sparse warnings about using incorrect types
On Thu, Jan 16, 2020 at 03:56:50PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Use ->screen_buffer instead of ->screen_base to fix sparse warnings.
>
> [ Please see commit 17a7b0b4d974 ("fb.h: Provide alternate screen_base
> pointer") for details. ]
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by: Sam Ravnborg
> ---
> Resend with Tony & linux-arm ML added to Cc:.
>
> drivers/video/fbdev/wm8505fb.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: b/drivers/video/fbdev/wm8505fb.c
> ===
> --- a/drivers/video/fbdev/wm8505fb.c
> +++ b/drivers/video/fbdev/wm8505fb.c
> @@ -339,7 +339,7 @@ static int wm8505fb_probe(struct platfor
>
> fbi->fb.fix.smem_start = fb_mem_phys;
> fbi->fb.fix.smem_len= fb_mem_len;
> - fbi->fb.screen_base = fb_mem_virt;
> + fbi->fb.screen_buffer = fb_mem_virt;
> fbi->fb.screen_size = fb_mem_len;
>
> fbi->contrast = 0x10;
> ___
> 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 2/2] video: fbdev: wm8505fb: add COMPILE_TEST support
On Thu, Jan 16, 2020 at 03:58:08PM +0100, Bartlomiej Zolnierkiewicz wrote: > Add COMPILE_TEST support to wm8505fb driver for better compile > testing coverage. > > Signed-off-by: Bartlomiej Zolnierkiewicz Acked-by: Sam Ravnborg > --- > drivers/video/fbdev/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: b/drivers/video/fbdev/Kconfig > === > --- a/drivers/video/fbdev/Kconfig > +++ b/drivers/video/fbdev/Kconfig > @@ -1639,7 +1639,7 @@ config FB_VT8500 > > config FB_WM8505 > bool "Wondermedia WM8xxx-series frame buffer support" > - depends on (FB = y) && ARM && ARCH_VT8500 > + depends on (FB = y) && HAS_IOMEM && (ARCH_VT8500 || COMPILE_TEST) > select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS) > select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS) > select FB_SYS_IMAGEBLIT > ___ > 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] video: fbdev: wm8505fb: fix sparse warnings about using incorrect types
On Thu, Jan 16, 2020 at 03:54:42PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Use ->screen_buffer instead of ->screen_base to fix sparse warnings.
>
> [ Please see commit 17a7b0b4d974 ("fb.h: Provide alternate screen_base
> pointer") for details. ]
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by: Sam Ravnborg
> ---
> drivers/video/fbdev/wm8505fb.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: b/drivers/video/fbdev/wm8505fb.c
> ===
> --- a/drivers/video/fbdev/wm8505fb.c
> +++ b/drivers/video/fbdev/wm8505fb.c
> @@ -339,7 +339,7 @@ static int wm8505fb_probe(struct platfor
>
> fbi->fb.fix.smem_start = fb_mem_phys;
> fbi->fb.fix.smem_len= fb_mem_len;
> - fbi->fb.screen_base = fb_mem_virt;
> + fbi->fb.screen_buffer = fb_mem_virt;
> fbi->fb.screen_size = fb_mem_len;
>
> fbi->contrast = 0x10;
> ___
> 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/6] video: fbdev: controlfb: fix sparse warning about using incorrect type
Hi Bartlomiej
On Thu, Jan 16, 2020 at 03:08:55PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Force le32_to_cpup() argument to be of proper type (const __le32 *).
>
> Also add missing inline keyword to control_par_to_var() definition
> (to match function prototype).
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/video/fbdev/controlfb.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
> index 38b61cdb5ca4..d7e53520a24c 100644
> --- a/drivers/video/fbdev/controlfb.c
> +++ b/drivers/video/fbdev/controlfb.c
> @@ -313,7 +313,7 @@ static int controlfb_blank(int blank_mode, struct fb_info
> *info)
> container_of(info, struct fb_info_control, info);
> unsigned ctrl;
>
> - ctrl = le32_to_cpup(CNTRL_REG(p,ctrl));
> + ctrl = le32_to_cpup((const __force __le32 *)CNTRL_REG(p, ctrl));
Only judging from the other code in the same driver,
I think a better fix would be to use:
ctrl = in_le32(CNTRL_REG(p,ctrl));
?
Sam
> if (blank_mode > 0)
> switch (blank_mode) {
> case FB_BLANK_VSYNC_SUSPEND:
> @@ -952,7 +952,8 @@ static int control_var_to_par(struct fb_var_screeninfo
> *var,
> * Convert hardware data in par to an fb_var_screeninfo
> */
>
> -static void control_par_to_var(struct fb_par_control *par, struct
> fb_var_screeninfo *var)
> +static inline void control_par_to_var(struct fb_par_control *par,
> + struct fb_var_screeninfo *var)
> {
> struct control_regints *rv;
>
> --
> 2.24.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: [Bug 206231] R9 280X low performance with all games
On Fri, Jan 17, 2020 at 06:45:28PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > screenshot : https://i.ibb.co/PrHj3hV/tombraider.jpg This seems to be from "shadow of the tomb raider" which I don't "own". Do you "own" "rise of the tomb raider", the previous tomb raider game (which I "own")? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #9 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) --- On Fri, Jan 17, 2020 at 06:45:28PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > screenshot : https://i.ibb.co/PrHj3hV/tombraider.jpg This seems to be from "shadow of the tomb raider" which I don't "own". Do you "own" "rise of the tomb raider", the previous tomb raider game (which I "own")? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 00/12] drm/i915: Add support for HDCP 1.4 over MST connectors
From: Sean Paul Hey all, Here's v3, which addresses all review comments in v2. Sean Sean Paul (12): drm/i915: Fix sha_text population code drm/i915: Clear the repeater bit on HDCP disable drm/i915: WARN if HDCP signalling is enabled upon disable drm/i915: Intercept Aksv writes in the aux hooks drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling drm/i915: Factor out hdcp->value assignments drm/i915: Protect workers against disappearing connectors drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it drm/i915: Support DP MST in enc_to_dig_port() function drm/i915: Use ddi_update_pipe in intel_dp_mst drm/i915: Factor out HDCP shim functions from dp for use by dp_mst drm/i915: Add HDCP 1.4 support for MST connectors drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_ddi.c | 27 +- drivers/gpu/drm/i915/display/intel_ddi.h | 2 + .../drm/i915/display/intel_display_types.h| 27 +- drivers/gpu/drm/i915/display/intel_dp.c | 619 +--- drivers/gpu/drm/i915/display/intel_dp.h | 7 + drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 680 ++ drivers/gpu/drm/i915/display/intel_dp_mst.c | 15 + drivers/gpu/drm/i915/display/intel_hdcp.c | 195 +++-- drivers/gpu/drm/i915/display/intel_hdmi.c | 18 +- include/drm/drm_hdcp.h| 3 + 11 files changed, 932 insertions(+), 662 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 02/12] drm/i915: Clear the repeater bit on HDCP disable
From: Sean Paul
On HDCP disable, clear the repeater bit. This ensures if we connect a
non-repeater sink after a repeater, the bit is in the state we expect.
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-...@lists.freedesktop.org
Cc: # v4.17+
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-3-s...@poorly.run
#v2
Changes in v2:
-Added to the set
Changes in v3:
-None
I had previously agreed that clearing the rep_ctl bits on enable would
also be a good idea. However when I committed that idea to code, it
didn't look right. So let's rely on enables and disables being paired
and everything outside of that will be considered a bug
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index eaab9008feef..c4394c8e10eb 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -773,6 +773,7 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
enum port port = intel_dig_port->base.port;
enum transcoder cpu_transcoder = hdcp->cpu_transcoder;
+ u32 repeater_ctl;
int ret;
DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
@@ -787,6 +788,10 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
return -ETIMEDOUT;
}
+ repeater_ctl = intel_hdcp_get_repeater_ctl(dev_priv, cpu_transcoder,
+ port);
+ I915_WRITE(HDCP_REP_CTL, I915_READ(HDCP_REP_CTL) & ~repeater_ctl);
+
ret = hdcp->shim->toggle_signalling(intel_dig_port, false);
if (ret) {
DRM_ERROR("Failed to disable HDCP signalling\n");
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 07/12] drm/i915: Protect workers against disappearing connectors
From: Sean Paul
This patch adds some protection against connectors being destroyed
before the HDCP workers are finished.
For check_work, we do a synchronous cancel after the connector is
unregistered which will ensure that it is finished before destruction.
In the case of prop_work, we can't do a synchronous wait since it needs
to take connection_mutex which could cause deadlock. Instead, we'll take
a reference on the connector when scheduling prop_work and give it up
once we're done.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-8-s...@poorly.run
#v2
Changes in v2:
- Added to the set
Changes in v3:
- Change the WARN_ON condition in intel_hdcp_cleanup to allow for
initializing connectors as well
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 43 ---
1 file changed, 38 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 798e7e1a19fc..fabacfb1b644 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -863,8 +863,10 @@ static void intel_hdcp_update_value(struct intel_connector
*connector,
return;
hdcp->value = value;
- if (update_property)
+ if (update_property) {
+ drm_connector_get(&connector->base);
schedule_work(&hdcp->prop_work);
+ }
}
/* Implements Part 3 of the HDCP authorization procedure */
@@ -954,6 +956,8 @@ static void intel_hdcp_prop_work(struct work_struct *work)
mutex_unlock(&hdcp->mutex);
drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ drm_connector_put(&connector->base);
}
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port)
@@ -1802,6 +1806,9 @@ static void intel_hdcp_check_work(struct work_struct
*work)
check_work);
struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
+ if (drm_connector_is_unregistered(&connector->base))
+ return;
+
if (!intel_hdcp2_check_link(connector))
schedule_delayed_work(&hdcp->check_work,
DRM_HDCP2_CHECK_PERIOD_MS);
@@ -2076,12 +2083,38 @@ void intel_hdcp_component_fini(struct drm_i915_private
*dev_priv)
void intel_hdcp_cleanup(struct intel_connector *connector)
{
- if (!connector->hdcp.shim)
+ struct intel_hdcp *hdcp = &connector->hdcp;
+
+ if (!hdcp->shim)
return;
- mutex_lock(&connector->hdcp.mutex);
- kfree(connector->hdcp.port_data.streams);
- mutex_unlock(&connector->hdcp.mutex);
+ /*
+* If the connector is registered, it's possible userspace could kick
+* off another HDCP enable, which would re-spawn the workers.
+*/
+ WARN_ON(connector->base.registration_state == DRM_CONNECTOR_REGISTERED);
+
+ /*
+* Now that the connector is not registered, check_work won't be run,
+* but cancel any outstanding instances of it
+*/
+ cancel_delayed_work_sync(&hdcp->check_work);
+
+ /*
+* We don't cancel prop_work in the same way as check_work since it
+* requires connection_mutex which could be held while calling this
+* function. Instead, we rely on the connector references grabbed before
+* scheduling prop_work to ensure the connector is alive when prop_work
+* is run. So if we're in the destroy path (which is where this
+* function should be called), we're "guaranteed" that prop_work is not
+* active (tl;dr This Should Never Happen).
+*/
+ WARN_ON(work_pending(&hdcp->prop_work));
+
+ mutex_lock(&hdcp->mutex);
+ kfree(hdcp->port_data.streams);
+ hdcp->shim = NULL;
+ mutex_unlock(&hdcp->mutex);
}
void intel_hdcp_atomic_check(struct drm_connector *connector,
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 09/12] drm/i915: Support DP MST in enc_to_dig_port() function
From: Sean Paul
Although DP_MST fake encoders are not subclassed from digital ports,
they are associated with them. Support these encoders.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-9-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-10-s...@poorly.run
#v2
Changes in v2:
-None
Changes in v3:
-None
---
.../drm/i915/display/intel_display_types.h| 21 ---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b488e8b1478e..d7f4897a1eb9 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1460,6 +1460,18 @@ static inline bool intel_encoder_is_dig_port(struct
intel_encoder *encoder)
}
}
+static inline bool intel_encoder_is_mst(struct intel_encoder *encoder)
+{
+ return encoder->type == INTEL_OUTPUT_DP_MST;
+}
+
+static inline struct intel_dp_mst_encoder *
+enc_to_mst(struct intel_encoder *encoder)
+{
+ return container_of(&encoder->base, struct intel_dp_mst_encoder,
+ base.base);
+}
+
static inline struct intel_digital_port *
enc_to_dig_port(struct intel_encoder *encoder)
{
@@ -1468,6 +1480,8 @@ enc_to_dig_port(struct intel_encoder *encoder)
if (intel_encoder_is_dig_port(intel_encoder))
return container_of(&encoder->base, struct intel_digital_port,
base.base);
+ else if (intel_encoder_is_mst(intel_encoder))
+ return enc_to_mst(encoder)->primary;
else
return NULL;
}
@@ -1478,13 +1492,6 @@ conn_to_dig_port(struct intel_connector *connector)
return enc_to_dig_port(intel_attached_encoder(connector));
}
-static inline struct intel_dp_mst_encoder *
-enc_to_mst(struct intel_encoder *encoder)
-{
- return container_of(&encoder->base, struct intel_dp_mst_encoder,
- base.base);
-}
-
static inline struct intel_dp *enc_to_intel_dp(struct intel_encoder *encoder)
{
return &enc_to_dig_port(encoder)->dp;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 10/12] drm/i915: Use ddi_update_pipe in intel_dp_mst
From: Sean Paul
In order to act upon content_protection property changes, we'll need to
implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe
for this
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-10-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-11-s...@poorly.run
#v2
Changes in v2:
-None
Changes in v3:
-None
---
drivers/gpu/drm/i915/display/intel_ddi.c| 9 +
drivers/gpu/drm/i915/display/intel_dp.h | 4
drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 +
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4073dd96b83e..43e935d3d86c 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4136,9 +4136,9 @@ static void intel_ddi_update_pipe_dp(struct intel_encoder
*encoder,
intel_panel_update_backlight(encoder, crtc_state, conn_state);
}
-static void intel_ddi_update_pipe(struct intel_encoder *encoder,
- const struct intel_crtc_state *crtc_state,
- const struct drm_connector_state *conn_state)
+void intel_ddi_update_pipe(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
{
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
@@ -4148,7 +4148,8 @@ static void intel_ddi_update_pipe(struct intel_encoder
*encoder,
conn_state->content_protection !=
DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
- if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
+ if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
+ !intel_encoder_is_mst(encoder))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
/*
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 3da166054788..0a028b58a8be 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -125,4 +125,8 @@ static inline unsigned int intel_dp_unused_lane_mask(int
lane_count)
u32 intel_dp_mode_to_fec_clock(u32 mode_clock);
+void intel_ddi_update_pipe(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state);
+
#endif /* __INTEL_DP_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index cba68c5a80fa..975d97989d3b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -774,6 +774,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port
*intel_dig_port, enum
intel_encoder->compute_config = intel_dp_mst_compute_config;
intel_encoder->disable = intel_mst_disable_dp;
intel_encoder->post_disable = intel_mst_post_disable_dp;
+ intel_encoder->update_pipe = intel_ddi_update_pipe;
intel_encoder->pre_pll_enable = intel_mst_pre_pll_enable_dp;
intel_encoder->pre_enable = intel_mst_pre_enable_dp;
intel_encoder->enable = intel_mst_enable_dp;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 01/12] drm/i915: Fix sha_text population code
From: Sean Paul
This patch fixes a few bugs:
1- We weren't taking into account sha_leftovers when adding multiple
ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
the beginning of ksv[j]
2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
being placed on the wrong half of sha_text, overlapping the leftover
ksv value
3- In the sha_leftovers == 2 case, we need to manually terminate the
byte stream with 0x80 since the hardware doesn't have enough room to
add it after writing M0
The upside is that all of the HDCP supported HDMI repeaters I could
find on Amazon just strip HDCP anyways, so it turns out to be _really_
hard to hit any of these cases without an MST hub, which is not (yet)
supported. Oh, and the sha_leftovers == 1 case works perfectly!
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-...@lists.freedesktop.org
Cc: # v4.17+
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-2-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-2-s...@poorly.run
#v2
Changes in v2:
-None
Changes in v3:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 25 +--
include/drm/drm_hdcp.h| 3 +++
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 0fdbd39f6641..eaab9008feef 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -335,8 +335,10 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
/* Fill up the empty slots in sha_text and write it out */
sha_empty = sizeof(sha_text) - sha_leftovers;
- for (j = 0; j < sha_empty; j++)
- sha_text |= ksv[j] << ((sizeof(sha_text) - j - 1) * 8);
+ for (j = 0; j < sha_empty; j++) {
+ u8 off = ((sizeof(sha_text) - j - 1 - sha_leftovers) *
8);
+ sha_text |= ksv[j] << off;
+ }
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
@@ -426,7 +428,7 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
} else if (sha_leftovers == 2) {
/* Write 32 bits of text */
I915_WRITE(HDCP_REP_CTL, rep_ctl | HDCP_SHA1_TEXT_32);
- sha_text |= bstatus[0] << 24 | bstatus[1] << 16;
+ sha_text |= bstatus[0] << 8 | bstatus[1];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
@@ -440,16 +442,27 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
return ret;
sha_idx += sizeof(sha_text);
}
+
+ /*
+* Terminate the SHA-1 stream by hand. For the other leftover
+* cases this is appended by the hardware.
+*/
+ I915_WRITE(HDCP_REP_CTL, rep_ctl | HDCP_SHA1_TEXT_32);
+ sha_text = DRM_HDCP_SHA1_TERMINATOR << 24;
+ ret = intel_write_sha_text(dev_priv, sha_text);
+ if (ret < 0)
+ return ret;
+ sha_idx += sizeof(sha_text);
} else if (sha_leftovers == 3) {
- /* Write 32 bits of text */
+ /* Write 32 bits of text (filled from LSB) */
I915_WRITE(HDCP_REP_CTL, rep_ctl | HDCP_SHA1_TEXT_32);
- sha_text |= bstatus[0] << 24;
+ sha_text |= bstatus[0];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
sha_idx += sizeof(sha_text);
- /* Write 8 bits of text, 24 bits of M0 */
+ /* Write 8 bits of text (filled from LSB), 24 bits of M0 */
I915_WRITE(HDCP_REP_CTL, rep_ctl | HDCP_SHA1_TEXT_8);
ret = intel_write_sha_text(dev_priv, bstatus[1]);
if (ret < 0)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 06a11202a097..20498c822204 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -29,6 +29,9 @@
/* Slave address for the HDCP registers in the receiver */
#define DRM_HDCP_DDC_ADDR 0x3A
+/* Value to use at the end of the SHA-1 bytestream used for repeaters */
+#define DRM_HDCP_SHA1_TERMINATOR 0x80
+
/* HDCP register offsets for HDMI/DVI devices */
#define DRM_HDCP_DDC_BKSV 0x00
#define DRM_HDCP_DDC_RI_PRIME 0x08
--
Sean Paul, Software Engineer,
[PATCH v3 12/12] drm/i915: Add HDCP 1.4 support for MST connectors
From: Sean Paul
Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
MST. Everything except for toggling the HDCP signalling and HDCP 2.2
support is the same as the DP case, so we'll re-use those callbacks
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-12-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-13-s...@poorly.run
#v2
Changes in v2:
- Toggle HDCP from encoder disable/enable
- Don't disable HDCP on MST connector destroy, leave that for encoder
disable, just ensure the check_work routine isn't running any longer
Changes in v3:
- Place the shim in the new intel_dp_hdcp.c file (Ville)
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 78 +++-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 14
2 files changed, 91 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 0b6d90980e90..a93ad675e7bb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -11,6 +11,7 @@
#include
#include "intel_display_types.h"
+#include "intel_ddi.h"
#include "intel_dp.h"
#include "intel_hdcp.h"
@@ -585,6 +586,78 @@ static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
.protocol = HDCP_PROTOCOL_DP,
};
+static int
+intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port *intel_dig_port,
+ enum transcoder cpu_transcoder,
+ bool enable)
+{
+ int ret;
+
+ ret = intel_ddi_toggle_hdcp_signalling(&intel_dig_port->base,
+ cpu_transcoder, enable);
+ if (ret)
+ DRM_DEBUG_KMS("%s HDCP signalling failed (%d)\n",
+ enable ? "Enable" : "Disable", ret);
+ return ret;
+}
+
+static
+int intel_dp_mst_hdcp2_write_msg(struct intel_digital_port *intel_dig_port,
+void *buf, size_t size)
+{
+ return -EOPNOTSUPP;
+}
+
+static
+int intel_dp_mst_hdcp2_read_msg(struct intel_digital_port *intel_dig_port,
+ u8 msg_id, void *buf, size_t size)
+{
+ return -EOPNOTSUPP;
+}
+
+static int
+intel_dp_mst_hdcp2_config_stream_type(struct intel_digital_port
*intel_dig_port,
+ bool is_repeater, u8 content_type)
+{
+ return -EOPNOTSUPP;
+}
+
+static
+int intel_dp_mst_hdcp2_check_link(struct intel_digital_port *intel_dig_port)
+{
+ return -EOPNOTSUPP;
+}
+
+static
+int intel_dp_mst_hdcp2_capable(struct intel_digital_port *intel_dig_port,
+ bool *capable)
+{
+ *capable = false;
+ return 0;
+}
+
+static const struct intel_hdcp_shim intel_dp_mst_hdcp_shim = {
+ .write_an_aksv = intel_dp_hdcp_write_an_aksv,
+ .read_bksv = intel_dp_hdcp_read_bksv,
+ .read_bstatus = intel_dp_hdcp_read_bstatus,
+ .repeater_present = intel_dp_hdcp_repeater_present,
+ .read_ri_prime = intel_dp_hdcp_read_ri_prime,
+ .read_ksv_ready = intel_dp_hdcp_read_ksv_ready,
+ .read_ksv_fifo = intel_dp_hdcp_read_ksv_fifo,
+ .read_v_prime_part = intel_dp_hdcp_read_v_prime_part,
+ .toggle_signalling = intel_dp_mst_hdcp_toggle_signalling,
+ .check_link = intel_dp_hdcp_check_link,
+ .hdcp_capable = intel_dp_hdcp_capable,
+
+ .write_2_2_msg = intel_dp_mst_hdcp2_write_msg,
+ .read_2_2_msg = intel_dp_mst_hdcp2_read_msg,
+ .config_stream_type = intel_dp_mst_hdcp2_config_stream_type,
+ .check_2_2_link = intel_dp_mst_hdcp2_check_link,
+ .hdcp_2_2_capable = intel_dp_mst_hdcp2_capable,
+
+ .protocol = HDCP_PROTOCOL_DP,
+};
+
int intel_dp_init_hdcp(struct intel_digital_port *intel_dig_port,
struct intel_connector *intel_connector)
{
@@ -597,7 +670,10 @@ int intel_dp_init_hdcp(struct intel_digital_port
*intel_dig_port,
if (!is_hdcp_supported(dev_priv, port))
return 0;
- if (!intel_dp_is_edp(intel_dp))
+ if (!intel_encoder_is_mst(intel_encoder))
+ return intel_hdcp_init(intel_connector,
+ &intel_dp_mst_hdcp_shim);
+ else if (!intel_dp_is_edp(intel_dp))
return intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim);
return 0;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 975d97989d3b..00c2032c71ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -36,6 +36,7 @@
#include "intel_dp.h"
#include "intel_dp_mst.h"
#include "intel_dpio_phy.h"
+#include "intel_hdcp.h"
static int intel_dp_mst_compute_link_config(struct intel_encoder *encoder,
struct intel_crtc_stat
[PATCH v3 08/12] drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it
From: Sean Paul
This patch is required for HDCP over MST. If a port is being used for
multiple HDCP streams, we don't want to fully disable HDCP on a port if
one of them is disabled. Instead, we just disable the HDCP signalling on
that particular pipe and exit early. The last pipe to disable HDCP will
also bring down HDCP on the port.
In order to achieve this, we need to keep a refcount in intel_digital_port
and protect it using a new hdcp_mutex.
Cc: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-8-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-9-s...@poorly.run
#v2
Changes in v2:
- Move the toggle_signalling call into _intel_hdcp_disable so it's called from
check_work
Changes in v3:
- None
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 ++
.../drm/i915/display/intel_display_types.h| 5 ++
drivers/gpu/drm/i915/display/intel_dp.c | 2 +
drivers/gpu/drm/i915/display/intel_hdcp.c | 52 +++
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +
5 files changed, 55 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index a90ce672d2cf..4073dd96b83e 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4815,6 +4815,9 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
encoder = &intel_dig_port->base;
+ mutex_init(&intel_dig_port->hdcp_mutex);
+ intel_dig_port->num_hdcp_streams = 0;
+
drm_encoder_init(&dev_priv->drm, &encoder->base, &intel_ddi_funcs,
DRM_MODE_ENCODER_TMDS, "DDI %c", port_name(port));
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 8a96fedefad3..b488e8b1478e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1355,6 +1355,11 @@ struct intel_digital_port {
enum phy_fia tc_phy_fia;
u8 tc_phy_fia_idx;
+ /* protects num_hdcp_streams reference count */
+ struct mutex hdcp_mutex;
+ /* the number of pipes using HDCP signalling out of this port */
+ unsigned int num_hdcp_streams;
+
void (*write_infoframe)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
unsigned int type,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 89501b7525a9..a91f65ba35a1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -7583,6 +7583,8 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
intel_encoder = &intel_dig_port->base;
encoder = &intel_encoder->base;
+ mutex_init(&intel_dig_port->hdcp_mutex);
+
if (drm_encoder_init(&dev_priv->drm, &intel_encoder->base,
&intel_dp_enc_funcs, DRM_MODE_ENCODER_TMDS,
"DP %c", port_name(port)))
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index fabacfb1b644..dc83d81c6df0 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -779,6 +779,19 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
connector->base.name, connector->base.base.id);
+ /*
+* If there are other connectors on this port using HDCP, don't disable
+* it. Instead, toggle the HDCP signalling off on that particular
+* connector/pipe and exit.
+*/
+ if (intel_dig_port->num_hdcp_streams > 0) {
+ ret = hdcp->shim->toggle_signalling(intel_dig_port,
+ cpu_transcoder, false);
+ if (ret)
+ DRM_ERROR("Failed to disable HDCP signalling\n");
+ return ret;
+ }
+
hdcp->hdcp_encrypted = false;
I915_WRITE(HDCP_CONF(dev_priv, cpu_transcoder, port), 0);
if (intel_de_wait_for_clear(dev_priv,
@@ -855,6 +868,7 @@ struct intel_connector *intel_hdcp_to_connector(struct
intel_hdcp *hdcp)
static void intel_hdcp_update_value(struct intel_connector *connector,
u64 value, bool update_property)
{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
struct intel_hdcp *hdcp = &connector->hdcp;
WARN_ON(!mutex_is_locked(&hdcp->mutex));
@@ -862,6 +876,15 @@ static void intel_hdcp_update_value(struct intel_connector
*connector,
if (hdcp->value == value)
return;
+ WARN_ON(!mutex_is_locked(&intel_dig_port->hdcp_mutex))
[PATCH v3 05/12] drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling
From: Sean Paul
Instead of using intel_dig_port's encoder pipe to determine which
transcoder to toggle signalling on, use the cpu_transcoder field already
stored in intel_hdmi.
This is particularly important for MST.
Suggested-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-6-s...@poorly.run
#v2
Changes in v2:
- Added to the set
Changes in v3:
- s/hdcp/hdmi/ in commit msg (Ram)
---
drivers/gpu/drm/i915/display/intel_ddi.c | 13 -
drivers/gpu/drm/i915/display/intel_ddi.h | 2 ++
.../gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 1 +
drivers/gpu/drm/i915/display/intel_hdcp.c| 11 +++
drivers/gpu/drm/i915/display/intel_hdmi.c| 16 +++-
6 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 87b8b347f682..a90ce672d2cf 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2017,12 +2017,12 @@ void intel_ddi_disable_transcoder_func(const struct
intel_crtc_state *crtc_state
}
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+enum transcoder cpu_transcoder,
bool enable)
{
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
intel_wakeref_t wakeref;
- enum pipe pipe = 0;
int ret = 0;
u32 tmp;
@@ -2031,18 +2031,13 @@ int intel_ddi_toggle_hdcp_signalling(struct
intel_encoder *intel_encoder,
if (WARN_ON(!wakeref))
return -ENXIO;
- if (WARN_ON(!intel_encoder->get_hw_state(intel_encoder, &pipe))) {
- ret = -EIO;
- goto out;
- }
-
- tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
+ tmp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (enable)
tmp |= TRANS_DDI_HDCP_SIGNALLING;
else
tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
- I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
-out:
+ I915_WRITE(TRANS_DDI_FUNC_CTL(cpu_transcoder), tmp);
+
intel_display_power_put(dev_priv, intel_encoder->power_domain, wakeref);
return ret;
}
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h
b/drivers/gpu/drm/i915/display/intel_ddi.h
index 167c6579d972..5b22daf04060 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -18,6 +18,7 @@ struct intel_crtc_state;
struct intel_dp;
struct intel_dpll_hw_state;
struct intel_encoder;
+enum transcoder;
void intel_ddi_fdi_post_disable(struct intel_encoder *intel_encoder,
const struct intel_crtc_state *old_crtc_state,
@@ -45,6 +46,7 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder);
u8 intel_ddi_dp_pre_emphasis_max(struct intel_encoder *encoder,
u8 voltage_swing);
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+enum transcoder cpu_transcoder,
bool enable);
void icl_sanitize_encoder_pll_mapping(struct intel_encoder *encoder);
int cnl_calc_wrpll_link(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index fdd943a17de3..8a96fedefad3 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -301,6 +301,7 @@ struct intel_hdcp_shim {
/* Enables HDCP signalling on the port */
int (*toggle_signalling)(struct intel_digital_port *intel_dig_port,
+enum transcoder cpu_transcoder,
bool enable);
/* Ensures the link is still protected */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0d59f62917ed..89501b7525a9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6083,6 +6083,7 @@ int intel_dp_hdcp_read_v_prime_part(struct
intel_digital_port *intel_dig_port,
static
int intel_dp_hdcp_toggle_signalling(struct intel_digital_port *intel_dig_port,
+ enum transcoder cpu_transcoder,
bool enable)
{
/* Not used for single stream DisplayPort setups */
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index c4394c8e10eb..f8d56d3b2ddb 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -693,7 +693,7 @@ static int intel_hdcp_auth(struct intel_conne
[PATCH v3 03/12] drm/i915: WARN if HDCP signalling is enabled upon disable
From: Sean Paul
HDCP signalling should not be left on, WARN if it is
Cc: Ville Syrjälä
Cc: Daniel Vetter
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-4-s...@poorly.run
#v2
Changes in v2:
- Added to the set in lieu of just clearing the bit
Changes in v3:
- None
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 32ea3c7e8b62..87b8b347f682 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1998,6 +1998,8 @@ void intel_ddi_disable_transcoder_func(const struct
intel_crtc_state *crtc_state
val = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
val &= ~TRANS_DDI_FUNC_ENABLE;
+ WARN_ON(val & TRANS_DDI_HDCP_SIGNALLING);
+
if (INTEL_GEN(dev_priv) >= 12) {
if (!intel_dp_mst_is_master_trans(crtc_state))
val &= ~TGL_TRANS_DDI_PORT_MASK;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/6] video: fbdev: controlfb: add COMPILE_TEST support
Hi Bartlomiej
On Thu, Jan 16, 2020 at 03:08:57PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Add COMPILE_TEST support to controlfb driver for better compile
> testing coverage.
This is not a nice patch to add COMPILE_TEST support :-(
But I see why you do it.
I already spent too much time being side-tracked by this, but here are
some comments to consider.
With the comments considered:
Acked-by: Sam Ravnborg
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/video/fbdev/Kconfig | 2 +-
> drivers/video/fbdev/controlfb.c | 21 +++--
> 2 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index aa9541bf964b..91c872457863 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -472,7 +472,7 @@ config FB_OF
>
> config FB_CONTROL
> bool "Apple \"control\" display support"
> - depends on (FB = y) && PPC_PMAC && PPC32
> + depends on (FB = y) && ((PPC_PMAC && PPC32) || COMPILE_TEST)
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
> index bd0f61d8bdb5..87cd817ad4c6 100644
> --- a/drivers/video/fbdev/controlfb.c
> +++ b/drivers/video/fbdev/controlfb.c
> @@ -47,12 +47,25 @@
> #include
> #include
> #include
> +#ifdef CONFIG_PPC_PMAC
> #include
> #include
> +#endif
>
> #include "macmodes.h"
> #include "controlfb.h"
>
> +#ifndef CONFIG_PPC_PMAC
> +#undef in_8
> +#undef out_8
> +#undef in_le32
> +#undef out_le32
> +#define in_8(addr) 0
> +#define out_8(addr, val)
> +#define in_le32(addr)0
> +#define out_le32(addr, val)
> +#endif
> +
> struct fb_par_control {
> int vmode, cmode;
> int xres, yres;
> @@ -278,7 +291,9 @@ static int controlfb_mmap(struct fb_info *info,
> vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> } else {
> /* framebuffer */
> +#ifdef CONFIG_PPC_PMAC
> vma->vm_page_prot = pgprot_cached_wthru(vma->vm_page_prot);
> +#endif
Add:
#define pgprot_cached_wthru(x) 0
in the CONFIG_PPC_PMAC block?
> }
>
> return vm_iomap_memory(vma, start, len);
> @@ -582,13 +597,14 @@ static void __init find_vram_size(struct
> fb_info_control *p)
>
> out_8(&p->frame_buffer[0x60], 0xb3);
> out_8(&p->frame_buffer[0x61], 0x71);
> +#ifdef CONFIG_PPC_PMAC
> asm volatile("eieio; dcbf 0,%0" : : "r" (&p->frame_buffer[0x60])
> : "memory" );
> mb();
> asm volatile("eieio; dcbi 0,%0" : : "r" (&p->frame_buffer[0x60])
> : "memory" );
> mb();
> -
> +#endif
The inline asm block could be written as:
static void invalid_vram_cache(void * addr)
{
eieio();
dcbf(addr);
mb;
eieio();
dcbi(addr);
mb();
}
And then this inline function could be in the CONFIG_PPC_PMAC block -
and a dummy in the else part.
The function name is just my best guess what the assembler does.
> bank2 = (in_8(&p->frame_buffer[0x60]) == 0xb3)
> && (in_8(&p->frame_buffer[0x61]) == 0x71);
>
> @@ -601,13 +617,14 @@ static void __init find_vram_size(struct
> fb_info_control *p)
>
> out_8(&p->frame_buffer[0], 0x5a);
> out_8(&p->frame_buffer[1], 0xc7);
> +#ifdef CONFIG_PPC_PMAC
> asm volatile("eieio; dcbf 0,%0" : : "r" (&p->frame_buffer[0])
> : "memory" );
> mb();
> asm volatile("eieio; dcbi 0,%0" : : "r" (&p->frame_buffer[0])
> : "memory" );
> mb();
> -
> +#endif
Same here.
> bank1 = (in_8(&p->frame_buffer[0]) == 0x5a)
> && (in_8(&p->frame_buffer[1]) == 0xc7);
>
> --
> 2.24.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
