[PATCH 2/2] drm/msm/dpu: remove unused arg
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 3 +--
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 4e54550c4a80..a52439e029c9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -634,7 +634,7 @@ void dpu_crtc_commit_kickoff(struct drm_crtc *crtc, bool
async)
*/
drm_for_each_encoder_mask(encoder, crtc->dev,
crtc->state->encoder_mask)
- dpu_encoder_prepare_for_kickoff(encoder, async);
+ dpu_encoder_prepare_for_kickoff(encoder);
if (!async) {
/* wait for previous frame_event_done completion */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index ed677cf2e1af..627c57594221 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1780,7 +1780,7 @@ static void dpu_encoder_vsync_event_work_handler(struct
kthread_work *work)
nsecs_to_jiffies(ktime_to_ns(wakeup_time)));
}
-void dpu_encoder_prepare_for_kickoff(struct drm_encoder *drm_enc, bool async)
+void dpu_encoder_prepare_for_kickoff(struct drm_encoder *drm_enc)
{
struct dpu_encoder_virt *dpu_enc;
struct dpu_encoder_phys *phys;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index a8bf1147fc56..997d131c2440 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -68,9 +68,8 @@ void dpu_encoder_register_frame_event_callback(struct
drm_encoder *encoder,
* Immediately: if no previous commit is outstanding.
* Delayed: Block until next trigger can be issued.
* @encoder: encoder pointer
- * @async: true if this is an asynchronous commit
*/
-void dpu_encoder_prepare_for_kickoff(struct drm_encoder *encoder, bool async);
+void dpu_encoder_prepare_for_kickoff(struct drm_encoder *encoder);
/**
* dpu_encoder_trigger_kickoff_pending - Clear the flush bits from previous
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/msm/dpu: remove some impossible error checking
From: Rob Clark
I'm sure there is plenty more to remove.. this is just some of the ones
I noticed.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 19 ---
.../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 ---
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 5 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 3 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 -
drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c | 10 --
6 files changed, 45 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 0e2f74163a16..ed677cf2e1af 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1428,12 +1428,6 @@ static void _dpu_encoder_trigger_flush(struct
drm_encoder *drm_enc,
int pending_kickoff_cnt;
u32 ret = UINT_MAX;
- if (!drm_enc || !phys) {
- DPU_ERROR("invalid argument(s), drm_enc %d, phys_enc %d\n",
- drm_enc != 0, phys != 0);
- return;
- }
-
if (!phys->hw_pp) {
DPU_ERROR("invalid pingpong hw\n");
return;
@@ -1566,11 +1560,6 @@ static void _dpu_encoder_kickoff_phys(struct
dpu_encoder_virt *dpu_enc,
uint32_t i, pending_flush;
unsigned long lock_flags;
- if (!dpu_enc) {
- DPU_ERROR("invalid encoder\n");
- return;
- }
-
pending_flush = 0x0;
/* update pending counts and trigger kickoff ctl flush atomically */
@@ -1798,10 +1787,6 @@ void dpu_encoder_prepare_for_kickoff(struct drm_encoder
*drm_enc, bool async)
bool needs_hw_reset = false;
unsigned int i;
- if (!drm_enc) {
- DPU_ERROR("invalid args\n");
- return;
- }
dpu_enc = to_dpu_encoder_virt(drm_enc);
trace_dpu_enc_prepare_kickoff(DRMID(drm_enc));
@@ -1837,10 +1822,6 @@ void dpu_encoder_kickoff(struct drm_encoder *drm_enc,
bool async)
ktime_t wakeup_time;
unsigned int i;
- if (!drm_enc) {
- DPU_ERROR("invalid encoder\n");
- return;
- }
DPU_ATRACE_BEGIN("encoder_kickoff");
dpu_enc = to_dpu_encoder_virt(drm_enc);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index 1b3ab909f367..2923b63d95fe 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -720,9 +720,6 @@ static int dpu_encoder_phys_cmd_wait_for_vblank(
static void dpu_encoder_phys_cmd_handle_post_kickoff(
struct dpu_encoder_phys *phys_enc)
{
- if (!phys_enc)
- return;
-
/**
* re-enable external TE, either for the first time after enabling
* or if disabled for Autorefresh
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index 5055a5eec869..737fe963a490 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -612,11 +612,6 @@ static void dpu_encoder_phys_vid_handle_post_kickoff(
{
unsigned long lock_flags;
- if (!phys_enc) {
- DPU_ERROR("invalid encoder\n");
- return;
- }
-
/*
* Video mode must flush CTL before enabling timing engine
* Video encoders need to turn on their interfaces now
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index b2f7b0e886b5..179e8d52cadb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -102,9 +102,6 @@ static inline void dpu_hw_ctl_update_pending_flush(struct
dpu_hw_ctl *ctx,
static u32 dpu_hw_ctl_get_pending_flush(struct dpu_hw_ctl *ctx)
{
- if (!ctx)
- return 0x0;
-
return ctx->pending_flush_mask;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 681955eb286f..b8d264bd15df 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -490,11 +490,6 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
int primary_planes_idx = 0, cursor_planes_idx = 0, i, ret;
int max_crtc_count;
- if (!dpu_kms || !dpu_kms->dev || !dpu_kms->dev->dev) {
- DPU_ERROR("invalid dpu_kms\n");
- return -EINVAL;
- }
-
dev = dpu_kms->dev;
priv = dev->dev_private;
catalog = dpu_kms->catalog;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
index 8bc3aea7cd86..f98a882318d1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
+++
linux-next: manual merge of the drm tree with the drm-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/mediatek/mtk_drm_drv.c
between commit:
4c6f3196e6ea ("drm/mediatek: use correct device to import PRIME buffers")
from the drm-fixes tree and commit:
3baeeb21983a ("drm/mtk: Drop drm_gem_prime_export/import")
from the drm tree.
I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 7f5408cb2377,2ee809a6f3dc..
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@@ -351,21 -314,8 +345,20 @@@ static const struct file_operations mtk
.compat_ioctl = drm_compat_ioctl,
};
+/*
+ * We need to override this because the device used to import the memory is
+ * not dev->dev, as drm_gem_prime_import() expects.
+ */
+struct drm_gem_object *mtk_drm_gem_prime_import(struct drm_device *dev,
+ struct dma_buf *dma_buf)
+{
+ struct mtk_drm_private *private = dev->dev_private;
+
+ return drm_gem_prime_import_dev(dev, dma_buf, private->dma_dev);
+}
+
static struct drm_driver mtk_drm_driver = {
- .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
- DRIVER_ATOMIC,
+ .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
.gem_free_object_unlocked = mtk_drm_gem_free_object,
.gem_vm_ops = _gem_cma_vm_ops,
@@@ -373,8 -323,6 +366,7 @@@
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_export = drm_gem_prime_export,
+ .gem_prime_import = mtk_drm_gem_prime_import,
.gem_prime_get_sg_table = mtk_gem_prime_get_sg_table,
.gem_prime_import_sg_table = mtk_gem_prime_import_sg_table,
.gem_prime_mmap = mtk_drm_gem_mmap_buf,
pgpIYBdP0wAEg.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
nouveau-next-5.4
Hey Dave, This is mostly just the stuff I missed last round. Various cleanup patches + fixes, improvements to display colour management, and some code to avoid loading when power cables aren't properly attached. There may be a second round next week with more changes, development system died unexpectedly during the week and held finalising things up somewhat. Thanks, Ben. The following changes since commit ae4530062620561d24683b1bd3438b8397693429: Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux into drm-next (2019-08-22 13:21:16 +1000) are available in the Git repository at: git://github.com/skeggsb/linux linux-5.4 for you to fetch changes up to a1af2afbd244089560794c260b2d4326a86e39b6: drm/nouveau/volt: Fix for some cards having 0 maximum voltage (2019-08-23 12:55:34 +1000) Ben Skeggs (15): drm/nouveau/kms/gv100: allow windows to use PACKED8BPP formats drm/nouveau/kms/tu102-: disable input lut when input is already FP16 drm/nouveau/kms/nv50-: disable input lut harder drm/nouveau/fifo/gf1xx: convert to using nvkm_fault_data drm/nouveau/fifo/gk104-: fix parsing of mmu fault data drm/nouveau/kms/gv100-: use premultiplied alpha blending between planes drm/nouveau/kms/gv100-: implement csc + enable modern colour managment properties drm/nouveau/kms/nv50-: use __drm_atomic_helper_plane_reset() drm/nouveau/kms/nv50-: create primary plane before overlay planes drm/nouveau/kms/nv50-: attach immutable zpos property to planes drm/nouveau/kms/gv100-: add support for plane zpos property drm/nouveau/kms/gv100-: attach alpha property to planes drm/nouveau/kms/gv100-: attach pixel blend mode property to planes drm/nouveau/therm: skip probing for devices not specified in thermal tables drm/nouveau/therm: don't attempt fan control where PMU is already managing it Colin Ian King (1): drm/nouveau/bios/init: fix spelling mistake "CONDITON" -> "CONDITION" Gustavo A. R. Silva (1): drm/nouveau/mmu: use struct_size() helper Hariprasad Kelam (2): drm/nouveau/dispnv04: subdev/bios.h is included more than once drm/nouveau: fix nvif/device.h is included more than once Ilia Mirkin (4): drm/nouveau/kms/nv50-: add fp16 scanout support drm/nouveau/kms/nv50-: remove overlay alpha formats drm/nouveau/kms/gf119-: add ctm property support drm/nouveau/kms/nv50-: enable modern color management properties Lyude Paul (2): drm/nouveau/dispnv04: Remove runtime PM drm/nouveau/dispnv50: Fix runtime PM ref tracking for non-blocking modesets Mark Menzynski (5): drm/nouveau/bios/gpio: sort gpios by values drm/nouveau/gpio: fail if gpu external power is missing drm/nouveau/gpio: check the gpio function 16 in the power check as well drm/nouveau/gpio: check function 76 in the power check as well drm/nouveau/volt: Fix for some cards having 0 maximum voltage Rhys Kidd (3): drm/nouveau/bios: downgrade absence of tmds table to info from an error drm/nouveau/bios/init: handle INIT_RESET_BEGUN devinit opcode drm/nouveau/bios/init: handle INIT_RESET_END devinit opcode Sam Ravnborg (4): drm/nouveau: drop use of DRM_UDELAY drm/nouveau: drop drmP.h from nouveau_drv.h drm/nouveau: drop drmP.h from all header files drm/nouveau: drop use of drmp.h Ville Syrjälä (1): drm/nouveau: Disable atomic support on a per-device basis YueHaibing (1): drm/nouveau/secboot: Make acr_r352_ls_gpccs_func static drivers/gpu/drm/nouveau/dispnv04/arb.c| 2 - drivers/gpu/drm/nouveau/dispnv04/crtc.c | 54 ++- drivers/gpu/drm/nouveau/dispnv04/cursor.c | 1 - drivers/gpu/drm/nouveau/dispnv04/dac.c| 1 - drivers/gpu/drm/nouveau/dispnv04/dfp.c| 2 +- drivers/gpu/drm/nouveau/dispnv04/disp.c | 3 +- drivers/gpu/drm/nouveau/dispnv04/disp.h | 1 - drivers/gpu/drm/nouveau/dispnv04/hw.c | 1 - drivers/gpu/drm/nouveau/dispnv04/hw.h | 1 - drivers/gpu/drm/nouveau/dispnv04/overlay.c| 1 - drivers/gpu/drm/nouveau/dispnv04/tvmodesnv17.c| 1 - drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 1 - drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 1 - drivers/gpu/drm/nouveau/dispnv50/atom.h | 14 + drivers/gpu/drm/nouveau/dispnv50/base507c.c | 26 +++-- drivers/gpu/drm/nouveau/dispnv50/base827c.c | 11 +++- drivers/gpu/drm/nouveau/dispnv50/base907c.c | 65 ++ drivers/gpu/drm/nouveau/dispnv50/base917c.c | 2 + drivers/gpu/drm/nouveau/dispnv50/corec37d.c | 2 +-
nouveau-fixes-5.3
The following changes since commit 4d352dbd5850bfc752609d46b5c8403ae0bd5163: drm/nouveau/secboot/gp102-: remove WAR for SEC2 RTOS start bug (2019-07-19 16:26:51 +1000) are available in the Git repository at: git://github.com/skeggsb/linux linux-5.3 for you to fetch changes up to c358ebf59634f06d8ed176da651ec150df3c8686: drm/nouveau: Don't retry infinitely when receiving no data on i2c over AUX (2019-08-23 12:42:43 +1000) Lyude Paul (1): drm/nouveau: Don't retry infinitely when receiving no data on i2c over AUX drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c | 24 +--- 1 file changed, 17 insertions(+), 7 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/8] drm/panfrost: Hold runtime PM reference until jobs complete
Doing a pm_runtime_put as soon as a job is submitted is wrong as it should
not happen until the job completes. It works because we are relying on the
autosuspend timeout to keep the h/w enabled.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
---
v2: new patch
drivers/gpu/drm/panfrost/panfrost_job.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 05c85f45a0de..80c9cab9a01b 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -151,7 +151,7 @@ static void panfrost_job_hw_submit(struct panfrost_job
*job, int js)
return;
if (WARN_ON(job_read(pfdev, JS_COMMAND_NEXT(js
- goto end;
+ return;
cfg = panfrost_mmu_as_get(pfdev, >file_priv->mmu);
@@ -187,10 +187,6 @@ static void panfrost_job_hw_submit(struct panfrost_job
*job, int js)
job_write(pfdev, JS_COMMAND_NEXT(js), JS_COMMAND_START);
spin_unlock_irqrestore(>hwaccess_lock, flags);
-
-end:
- pm_runtime_mark_last_busy(pfdev->dev);
- pm_runtime_put_autosuspend(pfdev->dev);
}
static void panfrost_acquire_object_fences(struct drm_gem_object **bos,
@@ -388,9 +384,13 @@ static void panfrost_job_timedout(struct drm_sched_job
*sched_job)
mutex_lock(>reset_lock);
- for (i = 0; i < NUM_JOB_SLOTS; i++)
+ for (i = 0; i < NUM_JOB_SLOTS; i++) {
drm_sched_stop(>js->queue[i].sched, sched_job);
-
+ if (pfdev->jobs[i]) {
+ pm_runtime_put_noidle(pfdev->dev);
+ pfdev->jobs[i] = NULL;
+ }
+ }
if (sched_job)
drm_sched_increase_karma(sched_job);
@@ -455,7 +455,9 @@ static irqreturn_t panfrost_job_irq_handler(int irq, void
*data)
pfdev->jobs[j] = NULL;
panfrost_mmu_as_put(pfdev, >file_priv->mmu);
panfrost_devfreq_record_transition(pfdev, j);
+
dma_fence_signal(job->done_fence);
+ pm_runtime_put_autosuspend(pfdev->dev);
}
status &= ~mask;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/8] drm/panfrost: Rework runtime PM initialization
There's a few issues with the runtime PM initialization.
The documentation states pm_runtime_set_active() should be called before
pm_runtime_enable(). The pm_runtime_put_autosuspend() could suspend the GPU
before panfrost_perfcnt_init() is called which touches the h/w. The
autosuspend delay keeps things from breaking. There's no need explicitly
power off the GPU only to wake back up with pm_runtime_get_sync(). Just
delaying pm_runtime_enable to the end of probe is sufficient.
Lets move all the runtime PM calls into the probe() function so they are
all in one place and are done after all initialization.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
---
v2: new patch
drivers/gpu/drm/panfrost/panfrost_device.c | 9 -
drivers/gpu/drm/panfrost/panfrost_drv.c| 10 ++
2 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
b/drivers/gpu/drm/panfrost/panfrost_device.c
index 4da71bb56c20..73805210834e 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -5,7 +5,6 @@
#include
#include
#include
-#include
#include
#include "panfrost_device.h"
@@ -166,14 +165,6 @@ int panfrost_device_init(struct panfrost_device *pfdev)
if (err)
goto err_out4;
- /* runtime PM will wake us up later */
- panfrost_gpu_power_off(pfdev);
-
- pm_runtime_set_active(pfdev->dev);
- pm_runtime_get_sync(pfdev->dev);
- pm_runtime_mark_last_busy(pfdev->dev);
- pm_runtime_put_autosuspend(pfdev->dev);
-
err = panfrost_perfcnt_init(pfdev);
if (err)
goto err_out5;
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index d74442d71048..f27e3d6aec12 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -523,10 +523,6 @@ static int panfrost_probe(struct platform_device *pdev)
mutex_init(>shrinker_lock);
INIT_LIST_HEAD(>shrinker_list);
- pm_runtime_use_autosuspend(pfdev->dev);
- pm_runtime_set_autosuspend_delay(pfdev->dev, 50); /* ~3 frames */
- pm_runtime_enable(pfdev->dev);
-
err = panfrost_device_init(pfdev);
if (err) {
if (err != -EPROBE_DEFER)
@@ -541,6 +537,12 @@ static int panfrost_probe(struct platform_device *pdev)
goto err_out1;
}
+ pm_runtime_set_active(pfdev->dev);
+ pm_runtime_use_autosuspend(pfdev->dev);
+ pm_runtime_set_autosuspend_delay(pfdev->dev, 0); /* ~3 frames */
+ pm_runtime_mark_last_busy(pfdev->dev);
+ pm_runtime_enable(pfdev->dev);
+
/*
* Register the DRM device with the core and the connectors with
* sysfs
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 7/8] drm/panfrost: Rework page table flushing and runtime PM interaction
There is no point in resuming the h/w just to do flush operations and
doing so takes several locks which cause lockdep issues with the shrinker.
Rework the flush operations to only happen when the h/w is already awake.
This avoids taking any locks associated with resuming.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
---
v2: new patch
drivers/gpu/drm/panfrost/panfrost_mmu.c | 41 -
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 842bdd7cf6be..ccf671a9c3fb 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -220,6 +220,23 @@ static size_t get_pgsize(u64 addr, size_t size)
return SZ_2M;
}
+void panfrost_mmu_flush_range(struct panfrost_device *pfdev,
+ struct panfrost_mmu *mmu,
+ u64 iova, size_t size)
+{
+ if (mmu->as < 0)
+ return;
+
+ /* Flush the PTs only if we're already awake */
+ if (!pm_runtime_get_if_in_use(pfdev->dev))
+ return;
+
+ mmu_hw_do_operation(pfdev, mmu, iova, size, AS_COMMAND_FLUSH_PT);
+
+ pm_runtime_mark_last_busy(pfdev->dev);
+ pm_runtime_put_autosuspend(pfdev->dev);
+}
+
static int mmu_map_sg(struct panfrost_device *pfdev, struct panfrost_mmu *mmu,
u64 iova, int prot, struct sg_table *sgt)
{
@@ -246,11 +263,10 @@ static int mmu_map_sg(struct panfrost_device *pfdev,
struct panfrost_mmu *mmu,
}
}
- mmu_hw_do_operation(pfdev, mmu, start_iova, iova - start_iova,
- AS_COMMAND_FLUSH_PT);
-
mutex_unlock(>lock);
+ panfrost_mmu_flush_range(pfdev, mmu, start_iova, iova - start_iova);
+
return 0;
}
@@ -259,7 +275,6 @@ int panfrost_mmu_map(struct panfrost_gem_object *bo)
struct drm_gem_object *obj = >base.base;
struct panfrost_device *pfdev = to_panfrost_device(obj->dev);
struct sg_table *sgt;
- int ret;
int prot = IOMMU_READ | IOMMU_WRITE;
if (WARN_ON(bo->is_mapped))
@@ -272,14 +287,7 @@ int panfrost_mmu_map(struct panfrost_gem_object *bo)
if (WARN_ON(IS_ERR(sgt)))
return PTR_ERR(sgt);
- ret = pm_runtime_get_sync(pfdev->dev);
- if (ret < 0)
- return ret;
-
mmu_map_sg(pfdev, bo->mmu, bo->node.start << PAGE_SHIFT, prot, sgt);
-
- pm_runtime_mark_last_busy(pfdev->dev);
- pm_runtime_put_autosuspend(pfdev->dev);
bo->is_mapped = true;
return 0;
@@ -293,17 +301,12 @@ void panfrost_mmu_unmap(struct panfrost_gem_object *bo)
u64 iova = bo->node.start << PAGE_SHIFT;
size_t len = bo->node.size << PAGE_SHIFT;
size_t unmapped_len = 0;
- int ret;
if (WARN_ON(!bo->is_mapped))
return;
dev_dbg(pfdev->dev, "unmap: as=%d, iova=%llx, len=%zx", bo->mmu->as,
iova, len);
- ret = pm_runtime_get_sync(pfdev->dev);
- if (ret < 0)
- return;
-
mutex_lock(>mmu->lock);
while (unmapped_len < len) {
@@ -318,13 +321,9 @@ void panfrost_mmu_unmap(struct panfrost_gem_object *bo)
unmapped_len += pgsize;
}
- mmu_hw_do_operation(pfdev, bo->mmu, bo->node.start << PAGE_SHIFT,
- bo->node.size << PAGE_SHIFT, AS_COMMAND_FLUSH_PT);
-
mutex_unlock(>mmu->lock);
- pm_runtime_mark_last_busy(pfdev->dev);
- pm_runtime_put_autosuspend(pfdev->dev);
+ panfrost_mmu_flush_range(pfdev, bo->mmu, bo->node.start << PAGE_SHIFT,
len);
bo->is_mapped = false;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/8] drm/panfrost: Use mutex_trylock in panfrost_gem_purge
Lockdep reports a circular locking dependency with pages_lock taken in
the shrinker callback. The deadlock can't actually happen with current
users at least as a BO will never be purgeable when pages_lock is held.
To be safe, let's use mutex_trylock() instead and bail if a BO is locked
already.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
---
v2: new patch
drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c
b/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c
index d191632b6197..458f0fa68111 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c
@@ -36,15 +36,18 @@ panfrost_gem_shrinker_count(struct shrinker *shrinker,
struct shrink_control *sc
return count;
}
-static void panfrost_gem_purge(struct drm_gem_object *obj)
+static bool panfrost_gem_purge(struct drm_gem_object *obj)
{
struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
- mutex_lock(>pages_lock);
+
+ if (!mutex_trylock(>pages_lock))
+ return false;
panfrost_mmu_unmap(to_panfrost_bo(obj));
drm_gem_shmem_purge_locked(obj);
mutex_unlock(>pages_lock);
+ return true;
}
static unsigned long
@@ -61,8 +64,8 @@ panfrost_gem_shrinker_scan(struct shrinker *shrinker, struct
shrink_control *sc)
list_for_each_entry_safe(shmem, tmp, >shrinker_list, madv_list) {
if (freed >= sc->nr_to_scan)
break;
- if (drm_gem_shmem_is_purgeable(shmem)) {
- panfrost_gem_purge(>base);
+ if (drm_gem_shmem_is_purgeable(shmem) &&
+ panfrost_gem_purge(>base)) {
freed += shmem->base.size >> PAGE_SHIFT;
list_del_init(>madv_list);
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/8] drm/shmem: Do dma_unmap_sg before purging pages
Calling dma_unmap_sg() in drm_gem_shmem_free_object() is too late if the
backing pages have already been released by the shrinker. The result is
the following abort:
Unable to handle kernel paging request at virtual address 898ed000
Mem abort info:
ESR = 0x96000147
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x0147
CM = 1, WnR = 1
swapper pgtable: 4k pages, 48-bit VAs, pgdp=02f51000
[898ed000] pgd=401f8003, pud=401f7003,
pmd=401b1003, pte=00e8098ed712
Internal error: Oops: 96000147 [#1] SMP
Modules linked in: panfrost gpu_sched
CPU: 5 PID: 902 Comm: gnome-shell Not tainted 5.3.0-rc1+ #95
Hardware name: 96boards Rock960 (DT)
pstate: 4005 (nZcv daif -PAN -UAO)
pc : __dma_inv_area+0x40/0x58
lr : arch_sync_dma_for_cpu+0x28/0x30
sp : 1321ba30
x29: 1321ba30 x28: 1321bd08
x27: x26: 0009
x25: c1f86170 x24:
x23: x22:
x21: 00021000 x20: 80003bb2d810
x19: 098ed000 x18:
x17: x16: 800023fd9480
x15: x14:
x13: x12:
x11: fffb9fff x10:
x9 : x8 : 800023fd9c18
x7 : x6 :
x5 : x4 : 00021000
Purging 5693440 bytes
x3 : 003f x2 : 0040
x1 : 8990e000 x0 : 898ed000
Call trace:
__dma_inv_area+0x40/0x58
dma_direct_sync_single_for_cpu+0x7c/0x80
dma_direct_unmap_page+0x80/0x88
dma_direct_unmap_sg+0x54/0x80
drm_gem_shmem_free_object+0xfc/0x108
panfrost_gem_free_object+0x118/0x128 [panfrost]
drm_gem_object_free+0x18/0x90
drm_gem_object_put_unlocked+0x58/0x80
drm_gem_object_handle_put_unlocked+0x64/0xb0
drm_gem_object_release_handle+0x70/0x98
drm_gem_handle_delete+0x64/0xb0
drm_gem_close_ioctl+0x28/0x38
drm_ioctl_kernel+0xb8/0x110
drm_ioctl+0x244/0x3f0
do_vfs_ioctl+0xbc/0x910
ksys_ioctl+0x78/0xa8
__arm64_sys_ioctl+0x1c/0x28
el0_svc_common.constprop.0+0x88/0x150
el0_svc_handler+0x28/0x78
el0_svc+0x8/0xc
Code: 8a23 5460 d50b7e20 1402 (d5087620)
Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers")
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Reviewed-by: Steven Price
Signed-off-by: Rob Herring
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index df8f2c8adb2b..5423ec56b535 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -390,6 +390,12 @@ void drm_gem_shmem_purge_locked(struct drm_gem_object *obj)
WARN_ON(!drm_gem_shmem_is_purgeable(shmem));
+ dma_unmap_sg(obj->dev->dev, shmem->sgt->sgl,
+shmem->sgt->nents, DMA_BIDIRECTIONAL);
+ sg_free_table(shmem->sgt);
+ kfree(shmem->sgt);
+ shmem->sgt = NULL;
+
drm_gem_shmem_put_pages_locked(shmem);
shmem->madv = -1;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 8/8] drm/panfrost: Remove unnecessary flushing from tlb_inv_context
tlb_inv_context() hook is only called when freeing the page tables. There's
no point in flushing only to free the page tables immediately following.
There is also a problem that we could be accessing the h/w when suspended.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
---
v2: new patch
drivers/gpu/drm/panfrost/panfrost_mmu.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index ccf671a9c3fb..9f85275a896c 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -328,11 +328,7 @@ void panfrost_mmu_unmap(struct panfrost_gem_object *bo)
}
static void mmu_tlb_inv_context_s1(void *cookie)
-{
- struct panfrost_file_priv *priv = cookie;
-
- mmu_hw_do_operation(priv->pfdev, >mmu, 0, ~0UL,
AS_COMMAND_FLUSH_MEM);
-}
+{}
static void mmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
size_t granule, bool leaf, void *cookie)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/8] drm/shmem: Use mutex_trylock in drm_gem_shmem_purge
Lockdep reports a circular locking dependency with pages_lock taken in
the shrinker callback. The deadlock can't actually happen with current
users at least as a BO will never be purgeable when pages_lock is held.
To be safe, let's use mutex_trylock() instead and bail if a BO is locked
already.
WARNING: possible circular locking dependency detected
5.3.0-rc1+ #100 Tainted: G L
--
kswapd0/171 is trying to acquire lock:
9b9823fd (>pages_lock){+.+.}, at: drm_gem_shmem_purge+0x20/0x40
but task is already holding lock:
f82369b6 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x40
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (fs_reclaim){+.+.}:
fs_reclaim_acquire.part.18+0x34/0x40
fs_reclaim_acquire+0x20/0x28
__kmalloc_node+0x6c/0x4c0
kvmalloc_node+0x38/0xa8
drm_gem_get_pages+0x80/0x1d0
drm_gem_shmem_get_pages+0x58/0xa0
drm_gem_shmem_get_pages_sgt+0x48/0xd0
panfrost_mmu_map+0x38/0xf8 [panfrost]
panfrost_gem_open+0xc0/0xe8 [panfrost]
drm_gem_handle_create_tail+0xe8/0x198
drm_gem_handle_create+0x3c/0x50
panfrost_gem_create_with_handle+0x70/0xa0 [panfrost]
panfrost_ioctl_create_bo+0x48/0x80 [panfrost]
drm_ioctl_kernel+0xb8/0x110
drm_ioctl+0x244/0x3f0
do_vfs_ioctl+0xbc/0x910
ksys_ioctl+0x78/0xa8
__arm64_sys_ioctl+0x1c/0x28
el0_svc_common.constprop.0+0x90/0x168
el0_svc_handler+0x28/0x78
el0_svc+0x8/0xc
-> #0 (>pages_lock){+.+.}:
__lock_acquire+0xa2c/0x1d70
lock_acquire+0xdc/0x228
__mutex_lock+0x8c/0x800
mutex_lock_nested+0x1c/0x28
drm_gem_shmem_purge+0x20/0x40
panfrost_gem_shrinker_scan+0xc0/0x180 [panfrost]
do_shrink_slab+0x208/0x500
shrink_slab+0x10c/0x2c0
shrink_node+0x28c/0x4d8
balance_pgdat+0x2c8/0x570
kswapd+0x22c/0x638
kthread+0x128/0x130
ret_from_fork+0x10/0x18
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(fs_reclaim);
lock(>pages_lock);
lock(fs_reclaim);
lock(>pages_lock);
*** DEADLOCK ***
3 locks held by kswapd0/171:
#0: f82369b6 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x40
#1: ceb37808 (shrinker_rwsem){}, at: shrink_slab+0xbc/0x2c0
#2: f31efa81 (>shrinker_lock){+.+.}, at:
panfrost_gem_shrinker_scan+0x34/0x180 [panfrost]
Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers")
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 7 +--
include/drm/drm_gem_shmem_helper.h | 2 +-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 5423ec56b535..f5918707672f 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -415,13 +415,16 @@ void drm_gem_shmem_purge_locked(struct drm_gem_object
*obj)
}
EXPORT_SYMBOL(drm_gem_shmem_purge_locked);
-void drm_gem_shmem_purge(struct drm_gem_object *obj)
+bool drm_gem_shmem_purge(struct drm_gem_object *obj)
{
struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
- mutex_lock(>pages_lock);
+ if (!mutex_trylock(>pages_lock))
+ return false;
drm_gem_shmem_purge_locked(obj);
mutex_unlock(>pages_lock);
+
+ return true;
}
EXPORT_SYMBOL(drm_gem_shmem_purge);
diff --git a/include/drm/drm_gem_shmem_helper.h
b/include/drm/drm_gem_shmem_helper.h
index ce1600fdfc3e..01f514521687 100644
--- a/include/drm/drm_gem_shmem_helper.h
+++ b/include/drm/drm_gem_shmem_helper.h
@@ -134,7 +134,7 @@ static inline bool drm_gem_shmem_is_purgeable(struct
drm_gem_shmem_object *shmem
}
void drm_gem_shmem_purge_locked(struct drm_gem_object *obj);
-void drm_gem_shmem_purge(struct drm_gem_object *obj);
+bool drm_gem_shmem_purge(struct drm_gem_object *obj);
struct drm_gem_shmem_object *
drm_gem_shmem_create_with_handle(struct drm_file *file_priv,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/8] drm/panfrost: Fix possible suspend in panfrost_remove
Calls to panfrost_device_fini() access the h/w, but we already done a pm_runtime_put_sync_autosuspend() beforehand. This only works if the autosuspend delay is long enough. A 0ms delay will hang the system when removing the device. Fix this by moving the pm_runtime_put_sync_suspend() after the panfrost_device_fini() call. Cc: Tomeu Vizoso Cc: Steven Price Cc: Alyssa Rosenzweig Cc: David Airlie Cc: Daniel Vetter Signed-off-by: Rob Herring --- v2: new patch drivers/gpu/drm/panfrost/panfrost_drv.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c index 44a558c6e17e..d74442d71048 100644 --- a/drivers/gpu/drm/panfrost/panfrost_drv.c +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c @@ -570,11 +570,13 @@ static int panfrost_remove(struct platform_device *pdev) drm_dev_unregister(ddev); panfrost_gem_shrinker_cleanup(ddev); + pm_runtime_get_sync(pfdev->dev); - pm_runtime_put_sync_autosuspend(pfdev->dev); - pm_runtime_disable(pfdev->dev); panfrost_devfreq_fini(pfdev); panfrost_device_fini(pfdev); + pm_runtime_put_sync_suspend(pfdev->dev); + pm_runtime_disable(pfdev->dev); + drm_dev_put(ddev); return 0; } -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[no subject]
Subject: [PATCH v2 0/8] panfrost: Locking and runtime PM fixes With further testing of recent changes with lockdep and other locking checks enabled, we've found several bugs in the shrinker code and one sleep while atomic in panfrost_gem_open(). This series addresses those issues. Delaying the unmapping of pages turns out to be a bad idea. Instead we need to rework panfrost_mmu_unmap() to not do a runtime PM resume which takes several locks and causes more lockdep warnings. Unfortunately, there initially appeared to be some mismatches between the runtime PM state and the h/w. The result is several fixes to the runtime PM initialization and handling in jobs. With this, the changes to panfrost_mmu_unmap() are working correctly. v2: - Drop already applied 'drm/panfrost: Fix sleeping while atomic in panfrost_gem_open' - Runtime PM clean-ups - Keep panfrost_gem_purge and use mutex_trylock there - Rework panfrost_mmu_unmap runtime PM Rob Rob Herring (8): drm/panfrost: Fix possible suspend in panfrost_remove drm/panfrost: Rework runtime PM initialization drm/panfrost: Hold runtime PM reference until jobs complete drm/shmem: Do dma_unmap_sg before purging pages drm/shmem: Use mutex_trylock in drm_gem_shmem_purge drm/panfrost: Use mutex_trylock in panfrost_gem_purge drm/panfrost: Rework page table flushing and runtime PM interaction drm/panfrost: Remove unnecessary flushing from tlb_inv_context drivers/gpu/drm/drm_gem_shmem_helper.c| 13 - drivers/gpu/drm/panfrost/panfrost_device.c| 9 drivers/gpu/drm/panfrost/panfrost_drv.c | 16 --- .../gpu/drm/panfrost/panfrost_gem_shrinker.c | 11 +++-- drivers/gpu/drm/panfrost/panfrost_job.c | 16 --- drivers/gpu/drm/panfrost/panfrost_mmu.c | 47 +-- include/drm/drm_gem_shmem_helper.h| 2 +- 7 files changed, 59 insertions(+), 55 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 5.3-rc6
Hi Linus, Hi Linus, Live from the laundromat after my washing machine broke down, we have the 5.3-rc6 fixes. Changelog is in the tag below, but nothing too noteworthy in here. Dave. drm-fixes-2019-08-23: drm fixes for 5.3-rc6 rcar-du: - LVDS dual-link mode fix mediatek: - of node refcount fix - prime buffer import fix - dma max seg fix komeda: - output polling fix - abfc format fix - memory-region DT fix amdgpu: - bpc display fix - ioctl memory leak fix - gfxoff fix - smu warnings fix i915: - HDMI mode readout fix The following changes since commit d1abaeb3be7b5fa6d7a1fbbd2e14e3310005c4c1: Linux 5.3-rc5 (2019-08-18 14:31:08 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-08-23 for you to fetch changes up to 75710f08ea7e41b2f7010da3f6deab061f7a853b: drm/amdgpu/powerplay: silence a warning in smu_v11_0_setup_pptable (2019-08-23 11:46:32 +1000) drm fixes for 5.3-rc6 rcar-du: - LVDS dual-link mode fix mediatek: - of node refcount fix - prime buffer import fix - dma max seg fix komeda: - output polling fix - abfc format fix - memory-region DT fix amdgpu: - bpc display fix - ioctl memory leak fix - gfxoff fix - smu warnings fix i915: - HDMI mode readout fix Alex Deucher (2): drm/amdgpu/gfx9: update pg_flags after determining if gfx off is possible drm/amdgpu/powerplay: silence a warning in smu_v11_0_setup_pptable Alexandre Courbot (2): drm/mediatek: use correct device to import PRIME buffers drm/mediatek: set DMA max segment size Dave Airlie (5): Merge tag 'du-fixes-20190816' of git://linuxtv.org/pinchartl/media into drm-fixes Merge tag 'mediatek-drm-fixes-5.3' of https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes Merge tag 'drm-fixes-5.3-2019-08-21' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2019-08-22' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'drm-misc-fixes-2019-08-22' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Imre Deak (1): drm/i915: Fix HW readout for crtc_clock in HDMI mode Jacopo Mondi (1): drm: rcar_lvds: Fix dual link mode operations Kenneth Feng (1): drm/amd/amdgpu: disable MMHUB PG for navi10 Kevin Wang (2): drm/amd/powerplay: fix variable type errors in smu_v11_0_setup_pptable drm/amd/powerplay: remove duplicate macro smu_get_uclk_dpm_states in amdgpu_smu.h Lowry Li (Arm Technology China) (2): drm/komeda: Initialize and enable output polling on Komeda drm/komeda: Adds internal bpp computing for arm afbc only format YU08 YU10 Maarten Lankhorst (1): Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixes Mihail Atanassov (1): drm/komeda: Add support for 'memory-region' DT node property Nicholas Kazlauskas (1): drm/amd/display: Calculate bpc based on max_requested_bpc Nicolai Hähnle (1): drm/amdgpu: prevent memory leaks in AMDGPU_CS ioctl Nishka Dasgupta (1): drm/mediatek: mtk_drm_drv.c: Add of_node_put() before goto Tomi Valkeinen (1): drm/omap: ensure we have a valid dma_mask drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 9 +++- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 4 ++ drivers/gpu/drm/amd/amdgpu/nv.c| 1 - drivers/gpu/drm/amd/amdgpu/soc15.c | 5 -- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 16 ++- drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 2 - drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 6 ++- drivers/gpu/drm/arm/display/komeda/komeda_dev.c| 9 .../drm/arm/display/komeda/komeda_format_caps.c| 19 .../drm/arm/display/komeda/komeda_format_caps.h| 3 ++ .../drm/arm/display/komeda/komeda_framebuffer.c| 5 +- drivers/gpu/drm/arm/display/komeda/komeda_kms.c| 5 ++ drivers/gpu/drm/i915/display/intel_ddi.c | 4 +- drivers/gpu/drm/i915/intel_drv.h | 2 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 54 -- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 + drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- drivers/gpu/drm/rcar-du/rcar_lvds.c| 6 +-- 18 files changed, 126 insertions(+), 28 deletions(-)
Re: [PATCH] drm/panfrost: Add missing check for pfdev->regulator
On Thu, Aug 22, 2019 at 4:32 AM Steven Price wrote:
>
> 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
> ---
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
Looks fine to me, but seems to be delayed getting to the list and
patchwork. I'm guessing you're not subscribed to dri-devel because all
your patches seem to get delayed.
Rob
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> index 710d903f8e0d..a1f5fa6a742a 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: [PULL] drm-intel-next
On Fri, 23 Aug 2019 at 05:29, Rodrigo Vivi wrote: > > Hi Dave and Daniel, > > Here goes the final pull request targeting 5.4. For some reason patchwork hasn't picked this up. or if it has I can't see it. Not sure whether it was the earlier patch code in it or something else malformed. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/panel: Add and fill drm_panel type field
Add a type field to the drm_panel structure to report the panel type,
using DRM_MODE_CONNECTOR_* macros (the values that make sense are LVDS,
eDP, DSI and DPI). This will be used to initialise the corresponding
connector type.
Update all panel drivers to fill the new field.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-arm-versatile.c | 1 +
.../drm/panel/panel-feiyang-fy07024di26a30d.c | 1 +
drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 1 +
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 1 +
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 1 +
.../gpu/drm/panel/panel-jdi-lt070me05000.c| 1 +
.../drm/panel/panel-kingdisplay-kd097d04.c| 1 +
drivers/gpu/drm/panel/panel-lg-lb035q02.c | 1 +
drivers/gpu/drm/panel/panel-lg-lg4573.c | 1 +
drivers/gpu/drm/panel/panel-lvds.c| 1 +
drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 1 +
drivers/gpu/drm/panel/panel-novatek-nt39016.c | 1 +
.../drm/panel/panel-olimex-lcd-olinuxino.c| 1 +
.../gpu/drm/panel/panel-orisetech-otm8009a.c | 1 +
.../drm/panel/panel-osd-osd101t2587-53ts.c| 1 +
.../drm/panel/panel-panasonic-vvx10f034n00.c | 1 +
.../drm/panel/panel-raspberrypi-touchscreen.c | 1 +
drivers/gpu/drm/panel/panel-raydium-rm67191.c | 1 +
drivers/gpu/drm/panel/panel-raydium-rm68200.c | 1 +
.../drm/panel/panel-rocktech-jh057n00900.c| 1 +
drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 1 +
drivers/gpu/drm/panel/panel-samsung-ld9040.c | 1 +
drivers/gpu/drm/panel/panel-samsung-s6d16d0.c | 1 +
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 1 +
.../gpu/drm/panel/panel-samsung-s6e63j0x03.c | 1 +
drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 1 +
drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c | 1 +
drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 1 +
.../gpu/drm/panel/panel-sharp-lq101r1sx01.c | 1 +
.../gpu/drm/panel/panel-sharp-ls037v7dw01.c | 1 +
.../gpu/drm/panel/panel-sharp-ls043t1le01.c | 1 +
drivers/gpu/drm/panel/panel-simple.c | 23 +++
drivers/gpu/drm/panel/panel-sitronix-st7701.c | 1 +
.../gpu/drm/panel/panel-sitronix-st7789v.c| 1 +
drivers/gpu/drm/panel/panel-sony-acx565akm.c | 1 +
drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 1 +
drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 1 +
drivers/gpu/drm/panel/panel-tpo-tpg110.c | 1 +
drivers/gpu/drm/panel/panel-truly-nt35597.c | 1 +
include/drm/drm_panel.h | 7 ++
40 files changed, 68 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c
b/drivers/gpu/drm/panel/panel-arm-versatile.c
index 5f72c922a04b..5c335fc1632b 100644
--- a/drivers/gpu/drm/panel/panel-arm-versatile.c
+++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
@@ -353,6 +353,7 @@ static int versatile_panel_probe(struct platform_device
*pdev)
drm_panel_init(>panel);
vpanel->panel.dev = dev;
vpanel->panel.funcs = _panel_drm_funcs;
+ vpanel->panel.type = DRM_MODE_CONNECTOR_DPI;
return drm_panel_add(>panel);
}
diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
index dabf59e0f56f..58894a4bf02c 100644
--- a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
+++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
@@ -207,6 +207,7 @@ static int feiyang_dsi_probe(struct mipi_dsi_device *dsi)
drm_panel_init(>panel);
ctx->panel.dev = >dev;
ctx->panel.funcs = _funcs;
+ ctx->panel.type = DRM_MODE_CONNECTOR_DSI;
ctx->dvdd = devm_regulator_get(>dev, "dvdd");
if (IS_ERR(ctx->dvdd)) {
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
index 3c58f63adbf7..10a6f4ab53e2 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
@@ -898,6 +898,7 @@ static int ili9322_probe(struct spi_device *spi)
drm_panel_init(>panel);
ili->panel.dev = dev;
ili->panel.funcs = _drm_funcs;
+ ili->panel.type = DRM_MODE_CONNECTOR_DPI;
return drm_panel_add(>panel);
}
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 3ad4a46c4e94..360b87ff62a1 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -436,6 +436,7 @@ static int ili9881c_dsi_probe(struct mipi_dsi_device *dsi)
drm_panel_init(>panel);
ctx->panel.dev = >dev;
ctx->panel.funcs = _funcs;
+ ctx->panel.type = DRM_MODE_CONNECTOR_DSI;
ctx->power = devm_regulator_get(>dev, "power");
if (IS_ERR(ctx->power)) {
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index d92d1c98878c..00b24662ebb5 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++
[PATCH 2/2] drm/bridge: panel: Use drm_panel.type instead of explicit connector_type
The drm panel bridge creates a connector using a connector type explicit
passed by the display controller or bridge driver that instantiates the
panel bridge. Now that drm_panel reports its connector type, use it and
remove the connector_type argument to drm_panel_bridge_add() and
devm_drm_panel_bridge_add().
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 2 +-
drivers/gpu/drm/bridge/cdns-dsi.c| 2 +-
drivers/gpu/drm/bridge/lvds-encoder.c| 2 +-
drivers/gpu/drm/bridge/panel.c | 16
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c| 2 +-
drivers/gpu/drm/ingenic/ingenic-drm.c| 6 ++
drivers/gpu/drm/mcde/mcde_dsi.c | 3 +--
drivers/gpu/drm/pl111/pl111_drv.c| 3 +--
drivers/gpu/drm/rcar-du/rcar_du_encoder.c| 3 +--
drivers/gpu/drm/rockchip/rockchip_rgb.c | 2 +-
drivers/gpu/drm/stm/ltdc.c | 3 +--
drivers/gpu/drm/tilcdc/tilcdc_external.c | 3 +--
drivers/gpu/drm/tve200/tve200_drv.c | 3 +--
drivers/gpu/drm/vc4/vc4_dpi.c| 2 +-
drivers/gpu/drm/vc4/vc4_dsi.c| 3 +--
include/drm/drm_bridge.h | 6 ++
16 files changed, 21 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index c388497366ca..34ce38217350 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -107,7 +107,7 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device
*dev, int endpoint)
output->encoder.possible_crtcs = 0x1;
if (panel) {
- bridge = drm_panel_bridge_add(panel,
DRM_MODE_CONNECTOR_Unknown);
+ bridge = drm_panel_bridge_add(panel);
if (IS_ERR(bridge))
return PTR_ERR(bridge);
}
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
b/drivers/gpu/drm/bridge/cdns-dsi.c
index 2af7f25c7413..aa109b5dc41c 100644
--- a/drivers/gpu/drm/bridge/cdns-dsi.c
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -958,7 +958,7 @@ static int cdns_dsi_attach(struct mipi_dsi_host *host,
panel = of_drm_find_panel(np);
if (!IS_ERR(panel)) {
- bridge = drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_DSI);
+ bridge = drm_panel_bridge_add(panel);
} else {
bridge = of_drm_find_bridge(dev->dev.of_node);
if (!bridge)
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds-encoder.c
index 9ebc750449cf..7b03ba65673d 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -107,7 +107,7 @@ static int lvds_encoder_probe(struct platform_device *pdev)
}
lvds_encoder->panel_bridge =
- devm_drm_panel_bridge_add(dev, panel, DRM_MODE_CONNECTOR_LVDS);
+ devm_drm_panel_bridge_add(dev, panel);
if (IS_ERR(lvds_encoder->panel_bridge))
return PTR_ERR(lvds_encoder->panel_bridge);
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index f5b8e55301ac..912b0e9ecd5f 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -16,7 +16,6 @@ struct panel_bridge {
struct drm_bridge bridge;
struct drm_connector connector;
struct drm_panel *panel;
- u32 connector_type;
};
static inline struct panel_bridge *
@@ -72,7 +71,7 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
ret = drm_connector_init(bridge->dev, connector,
_bridge_connector_funcs,
-panel_bridge->connector_type);
+panel_bridge->panel->type);
if (ret) {
DRM_ERROR("Failed to initialize connector\n");
return ret;
@@ -137,8 +136,6 @@ static const struct drm_bridge_funcs
panel_bridge_bridge_funcs = {
* just calls the appropriate functions from _panel.
*
* @panel: The drm_panel being wrapped. Must be non-NULL.
- * @connector_type: The DRM_MODE_CONNECTOR_* for the connector to be
- * created.
*
* For drivers converting from directly using drm_panel: The expected
* usage pattern is that during either encoder module probe or DSI
@@ -155,8 +152,7 @@ static const struct drm_bridge_funcs
panel_bridge_bridge_funcs = {
* See devm_drm_panel_bridge_add() for an automatically manged version of this
* function.
*/
-struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
- u32 connector_type)
+struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel)
{
struct panel_bridge *panel_bridge;
@@ -168,7 +164,6 @@ struct drm_bridge *drm_panel_bridge_add(struct drm_panel
*panel,
[PATCH 5/6] drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata
Function intel_dp_setup_hdr_metadata_infoframe_sdp handles Infoframe SDP
header and data block setup for HDR Static Metadata. It enables writing of
HDR metadata infoframe SDP to panel. Support for HDR video was introduced
in DisplayPort 1.4. It implements the CTA-861-G standard for transport of
static HDR metadata. The HDR Metadata will be provided by userspace
compositors, based on blending policies and passed to the driver through
a blob property.
Because each of GEN11 and prior GEN11 have different register size for
HDR Metadata Infoframe SDP packet, it adds and uses different register size.
Setup Infoframe SDP header and data block in function
intel_dp_setup_hdr_metadata_infoframe_sdp for HDR Static Metadata as per
dp 1.4 spec and CTA-861-F spec.
As per DP 1.4 spec, 2.2.2.5 SDP Formats. It enables Dynamic Range and
Mastering Infoframe for HDR content, which is defined in CTA-861-F spec.
According to DP 1.4 spec and CEA-861-F spec Table 5, in order to transmit
static HDR metadata, we have to use Non-audio INFOFRAME SDP v1.3.
++---+
| [ Packet Type Value ] | [ Packet Type ] |
++---+
| 80h + Non-audio INFOFRAME Type | CEA-861-F Non-audio INFOFRAME |
++---+
| [Transmission Timing] |
++
| As per CEA-861-F for INFOFRAME, including CEA-861.3 within |
| which Dynamic Range and Mastering INFOFRAME are defined|
++
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 90
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
4 files changed, 95 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index a944d7c5091b..a7b7f05a7ada 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3478,6 +3478,7 @@ static void intel_enable_ddi_dp(struct intel_encoder
*encoder,
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
+ intel_dp_hdr_metadata_enable(intel_dp, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index a9a91f675b4a..edb21b261319 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4553,6 +4553,84 @@ intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
intel_dig_port->write_infoframe(_dig_port->base,
crtc_state, DP_SDP_VSC, _sdp, sizeof(vsc_sdp));
}
+static int
+intel_dp_setup_hdr_metadata_infoframe_sdp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state
*crtc_state,
+ const struct drm_connector_state
*conn_state)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_i915_private *dev_priv =
to_i915(intel_dig_port->base.base.dev);
+ struct dp_sdp infoframe_sdp = {};
+ struct hdmi_drm_infoframe drm_infoframe = {};
+ const int infoframe_size = HDMI_INFOFRAME_HEADER_SIZE +
HDMI_DRM_INFOFRAME_SIZE;
+ unsigned char buf[HDMI_INFOFRAME_HEADER_SIZE + HDMI_DRM_INFOFRAME_SIZE];
+ ssize_t len;
+ int ret;
+
+ ret = drm_hdmi_infoframe_set_hdr_metadata(_infoframe, conn_state);
+ if (ret) {
+ DRM_DEBUG_KMS("couldn't set HDR metadata in infoframe\n");
+ return ret;
+ }
+
+ len = hdmi_drm_infoframe_pack_only(_infoframe, buf, sizeof(buf));
+ if (len < 0) {
+ DRM_DEBUG_KMS("buffer size is smaller than hdr metadata
infoframe\n");
+ return (int)len;
+ }
+
+ if (len != infoframe_size) {
+ DRM_DEBUG_KMS("wrong static hdr metadata size\n");
+ return -EINVAL;
+ }
+
+ /*
+* Set up the infoframe sdp packet for HDR static metadata.
+* Prepare VSC Header for SU as per DP 1.4a spec,
+* Table 2-100 and Table 2-101
+*/
+
+ /* Packet ID, 00h for non-Audio INFOFRAME */
+ infoframe_sdp.sdp_header.HB0 = 0;
+ /*
+* Packet Type 80h + Non-audio INFOFRAME Type value
+* HDMI_INFOFRAME_TYPE_DRM: 0x87,
+*/
+ infoframe_sdp.sdp_header.HB1 = drm_infoframe.type;
+ /*
+* Least Significant Eight Bits of (Data Byte Count – 1)
+* infoframe_size - 1,
+*/
+
[PATCH 4/6] drm/i915/dp: Attach colorspace property
It attaches the colorspace connector property to a DisplayPort connector.
Based on colorspace change, modeset will be triggered to switch to a new
colorspace.
Based on colorspace property value create a VSC SDP packet with appropriate
colorspace. This would help to enable wider color gamut like BT2020 on a
sink device.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index d2815fdcbe8f..a9a91f675b4a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6402,6 +6402,8 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
else if (INTEL_GEN(dev_priv) >= 5)
drm_connector_attach_max_bpc_property(connector, 6, 12);
+ intel_attach_colorspace_property(connector);
+
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA
When BT.2020 Colorimetry output is used for DP, we should program BT.2020
Colorimetry to MSA and VSC SDP. It adds output_colorspace to
intel_crtc_state struct as a place holder of pipe's output colorspace.
In order to distinguish needed colorimetry for VSC SDP, it adds
intel_dp_needs_vsc_colorimetry function.
If the output colorspace requires vsc sdp or output format is YCbCr 4:2:0,
it uses MSA with VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of
Color Encoding Format and Content Color Gamut] while sending
BT.2020 Colorimetry signals we should program MSA MISC1 fields which
indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_ddi.c | 8 +++---
.../drm/i915/display/intel_display_types.h| 3 +++
drivers/gpu/drm/i915/display/intel_dp.c | 25 ++-
drivers/gpu/drm/i915/display/intel_dp.h | 1 +
4 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4f7ea0a35976..a944d7c5091b 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1737,11 +1737,13 @@ void intel_ddi_set_pipe_settings(const struct
intel_crtc_state *crtc_state)
/*
* As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication
* of Color Encoding Format and Content Color Gamut] while sending
-* YCBCR 420 signals we should program MSA MISC1 fields which
-* indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
+* YCBCR 420, HDR BT.2020 signals we should program MSA MISC1 fields
+* which indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
*/
- if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ if ((crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) ||
+ (intel_dp_needs_vsc_colorimetry(crtc_state->output_colorspace)))
temp |= TRANS_MSA_USE_VSC_SDP;
+
I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 449abaea619f..9845abcf6f29 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -964,6 +964,9 @@ struct intel_crtc_state {
/* Output format RGB/YCBCR etc */
enum intel_output_format output_format;
+ /* Output colorspace sRGB/BT.2020 etc */
+ u32 output_colorspace;
+
/* Output down scaling is done in LSPCON device */
bool lspcon_downsampling;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 55d5ab97061c..d2815fdcbe8f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2164,6 +2164,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->has_pch_encoder = true;
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
+ pipe_config->output_colorspace = intel_conn_state->base.colorspace;
+
if (lspcon->active)
lspcon_ycbcr420_config(_connector->base, pipe_config);
else
@@ -4408,6 +4410,26 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp
*intel_dp,
return 0;
}
+bool
+intel_dp_needs_vsc_colorimetry(u32 colorspace)
+{
+ bool ret = false;
+
+ switch (colorspace) {
+ case DRM_MODE_COLORIMETRY_SYCC_601:
+ case DRM_MODE_COLORIMETRY_OPYCC_601:
+ case DRM_MODE_COLORIMETRY_BT2020_YCC:
+ case DRM_MODE_COLORIMETRY_BT2020_RGB:
+ case DRM_MODE_COLORIMETRY_BT2020_CYCC:
+ ret = true;
+ break;
+ default:
+ break;
+ }
+
+ return ret;
+}
+
static void
intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
@@ -4536,7 +4558,8 @@ void intel_dp_vsc_enable(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
- if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420)
+ if ((crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420) &&
+ (!intel_dp_needs_vsc_colorimetry(conn_state->colorspace)))
return;
intel_dp_setup_vsc_sdp(intel_dp, 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 91a0ee6058fe..b2da7c9998f7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -111,6 +111,7 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp);
int intel_dp_link_required(int pixel_clock, int bpp);
int
[PATCH 6/6] drm/i915/dp: Attach HDR metadata property to DP connector
It attaches HDR metadata property to DP connector on GLK+.
It enables HDR metadata infoframe sdp on GLK+ to be used to send
HDR metadata to DP sink.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_dp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index edb21b261319..af2f960a5dd2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6494,6 +6494,10 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
intel_attach_colorspace_property(connector);
+ if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11)
+ drm_object_attach_property(>base,
+
connector->dev->mode_config.hdr_output_metadata_property, 0);
+
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm: Add DisplayPort colorspace property
In order to use colorspace property to Display Port connectors, it extends
DRM_MODE_CONNECTOR_DisplayPort connector_type on
drm_mode_create_colorspace_property function.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/drm_connector.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4c766624b20d..655ada9d4c16 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1703,7 +1703,9 @@ int drm_mode_create_colorspace_property(struct
drm_connector *connector)
struct drm_property *prop;
if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
- connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
+ connector->connector_type == DRM_MODE_CONNECTOR_HDMIB ||
+ connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
+ connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
"Colorspace",
hdmi_colorspaces,
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/i915/dp: Extend program of VSC Header and DB for Colorimetry Format
It refactors and renames a function which handled vsc sdp header and data
block setup for supporting colorimetry format.
Function intel_dp_setup_vsc_sdp handles vsc sdp header and data block
setup for pixel encoding / colorimetry format.
In order to use colorspace information of a connector, it adds an argument
of drm_connector_state type.
Setup VSC header and data block in function intel_dp_setup_vsc_sdp for
pixel encoding / colorimetry format as per dp 1.4a spec, section 2.2.5.7.1,
table 2-119: VSC SDP Header Bytes, section 2.2.5.7.5,
table 2-120: VSC SDP Payload for DB16 through DB18.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.h | 2 -
drivers/gpu/drm/i915/display/intel_dp.c | 68
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
4 files changed, 60 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 8eb2b3ec01ed..4f7ea0a35976 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3475,7 +3475,7 @@ static void intel_enable_ddi_dp(struct intel_encoder
*encoder,
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
- intel_dp_ycbcr_420_enable(intel_dp, crtc_state);
+ intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index e57e6969051d..7bd59241fc32 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -499,8 +499,6 @@ void intel_dp_get_m_n(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config);
void intel_dp_set_m_n(const struct intel_crtc_state *crtc_state,
enum link_m_n_set m_n);
-void intel_dp_ycbcr_420_enable(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state);
int intel_dotclock_calculate(int link_freq, const struct intel_link_m_n *m_n);
bool bxt_find_best_dpll(struct intel_crtc_state *crtc_state,
struct dpll *best_clock);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5c45a3bb102d..55d5ab97061c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4409,8 +4409,9 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
}
static void
-intel_pixel_encoding_setup_vsc(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state)
+intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct dp_sdp vsc_sdp = {};
@@ -4431,13 +4432,55 @@ intel_pixel_encoding_setup_vsc(struct intel_dp
*intel_dp,
*/
vsc_sdp.sdp_header.HB3 = 0x13;
- /*
-* YCbCr 420 = 3h DB16[7:4] ITU-R BT.601 = 0h, ITU-R BT.709 = 1h
-* DB16[3:0] DP 1.4a spec, Table 2-120
-*/
- vsc_sdp.db[16] = 0x3 << 4; /* 0x3 << 4 , YCbCr 420*/
- /* RGB->YCBCR color conversion uses the BT.709 color space. */
- vsc_sdp.db[16] |= 0x1; /* 0x1, ITU-R BT.709 */
+ /* DP 1.4a spec, Table 2-120 */
+ switch (crtc_state->output_format) {
+ case INTEL_OUTPUT_FORMAT_YCBCR444:
+ vsc_sdp.db[16] = 0x1 << 4; /* YCbCr 444 : DB16[7:4] = 1h */
+ break;
+ case INTEL_OUTPUT_FORMAT_YCBCR420:
+ vsc_sdp.db[16] = 0x3 << 4; /* YCbCr 420 : DB16[7:4] = 3h */
+ break;
+ case INTEL_OUTPUT_FORMAT_RGB:
+ default:
+ /* RGB: DB16[7:4] = 0h */
+ break;
+ }
+
+ switch (conn_state->colorspace) {
+ case DRM_MODE_COLORIMETRY_BT709_YCC:
+ vsc_sdp.db[16] |= 0x1;
+ break;
+ case DRM_MODE_COLORIMETRY_XVYCC_601:
+ vsc_sdp.db[16] |= 0x2;
+ break;
+ case DRM_MODE_COLORIMETRY_XVYCC_709:
+ vsc_sdp.db[16] |= 0x3;
+ break;
+ case DRM_MODE_COLORIMETRY_SYCC_601:
+ vsc_sdp.db[16] |= 0x4;
+ break;
+ case DRM_MODE_COLORIMETRY_OPYCC_601:
+ vsc_sdp.db[16] |= 0x5;
+ break;
+ case DRM_MODE_COLORIMETRY_BT2020_CYCC:
+ case DRM_MODE_COLORIMETRY_BT2020_RGB:
+ vsc_sdp.db[16] |= 0x6;
+ break;
+ case DRM_MODE_COLORIMETRY_BT2020_YCC:
+ vsc_sdp.db[16] |= 0x7;
+ break;
+ case DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
+ case
[PATCH 0/6] drm/i915/dp: Support for DP HDR outputs
Support for HDR10 video was introduced in DisplayPort 1.4. On GLK+ platform, in order to use DisplayPort HDR10, we need to support BT.2020 colorimetry and HDR Static metadata. It implements the CTA-861-G standard for transport of static HDR metadata. It enables writing of HDR metadata infoframe SDP to the panel. The HDR Metadata will be provided by userspace compositors, based on blending policies and passed to the driver through a blob property. And It refactors, renames and extends a function which handled vsc sdp header and data block setup for supporting colorimetry format. And It attaches the colorspace connector property and HDR metadata property to a DisplayPort connector. These patches tested on below test environment. Test Environment: - Tested System: GLK and Gen11 platform. - Monitor: Dell UP2718Q 4K HDR Monitor. - In order to test DP HDR10, test environment uses patched Kodi-gbm, patched Media driver and HDR10 video. You can find these on below. [patched Kodi-gbm] - repo: https://github.com/Kwiboo/xbmc/tree/drmprime-hdr [download 4K HDR video file] - link: https://4kmedia.org/lg-new-york-hdr-uhd-4k-demo/ [Media Driver for GLK] - repo https://gitlab.freedesktop.org/emersion/intel-vaapi-driver master branch [Media Driver for ICL] - repo: https://github.com/harishkrupo/media-driver/tree/p010_composite Gwan-gyeong Mun (6): drm/i915/dp: Extend program of VSC Header and DB for Colorimetry Format drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA drm: Add DisplayPort colorspace property drm/i915/dp: Attach colorspace property drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata drm/i915/dp: Attach HDR metadata property to DP connector drivers/gpu/drm/drm_connector.c | 4 +- drivers/gpu/drm/i915/display/intel_ddi.c | 11 +- drivers/gpu/drm/i915/display/intel_display.h | 2 - .../drm/i915/display/intel_display_types.h| 3 + drivers/gpu/drm/i915/display/intel_dp.c | 189 -- drivers/gpu/drm/i915/display/intel_dp.h | 7 + drivers/gpu/drm/i915/i915_reg.h | 1 + 7 files changed, 197 insertions(+), 20 deletions(-) -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] MAINTAINERS: Add Steven and Alyssa as panfrost reviewers
Add Steven Price and Alyssa Rosenzweig as reviewers as they have been the primary reviewers already. Cc: Steven Price Cc: Alyssa Rosenzweig Cc: Tomeu Vizoso Signed-off-by: Rob Herring --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 67b75fc33c61..28f4a20940cb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1255,6 +1255,8 @@ F:Documentation/gpu/afbc.rst ARM MALI PANFROST DRM DRIVER M: Rob Herring M: Tomeu Vizoso +R: Steven Price +R: Alyssa Rosenzweig L: dri-devel@lists.freedesktop.org S: Supported T: git git://anongit.freedesktop.org/drm/drm-misc -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/50] drm/bridge: panel: Implement bridge connector operations
Hi Boris,
On Thu, Aug 22, 2019 at 08:02:47PM +0200, Boris Brezillon wrote:
> On Thu, 22 Aug 2019 19:35:24 +0300 Laurent Pinchart wrote:
> > On Thu, Aug 22, 2019 at 06:29:09PM +0200, Boris Brezillon wrote:
> >> On Tue, 20 Aug 2019 04:16:44 +0300 Laurent Pinchart wrote:
> >>
> >>> Implement the newly added bridge connector operations, allowing the
> >>> usage of drm_bridge_panel with drm_bridge_connector.
> >>>
> >>> Signed-off-by: Laurent Pinchart
> >>> ---
> >>> drivers/gpu/drm/bridge/panel.c | 18 +-
> >>> 1 file changed, 17 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/panel.c
> >>> b/drivers/gpu/drm/bridge/panel.c
> >>> index f5b8e55301ac..1c7f5b648f05 100644
> >>> --- a/drivers/gpu/drm/bridge/panel.c
> >>> +++ b/drivers/gpu/drm/bridge/panel.c
> >>> @@ -60,7 +60,7 @@ static int panel_bridge_attach(struct drm_bridge
> >>> *bridge,
> >>> int ret;
> >>>
> >>> if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> >>> - return -EINVAL;
> >>> + return 0;
> >>>
> >>> if (!bridge->encoder) {
> >>> DRM_ERROR("Missing encoder\n");
> >>> @@ -123,6 +123,18 @@ static void panel_bridge_post_disable(struct
> >>> drm_bridge *bridge)
> >>> drm_panel_unprepare(panel_bridge->panel);
> >>> }
> >>>
> >>> +static int panel_bridge_get_modes(struct drm_bridge *bridge,
> >>> + struct drm_connector *connector)
> >>> +{
> >>> + struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
> >>> +
> >>> + /*
> >>> + * FIXME: drm_panel_get_modes() should take the connector as an
> >>> + * argument.
> >>> + */
> >>> + return drm_panel_get_modes(panel_bridge->panel);
> >>> +}
> >>> +
> >>> static const struct drm_bridge_funcs panel_bridge_bridge_funcs = {
> >>> .attach = panel_bridge_attach,
> >>> .detach = panel_bridge_detach,
> >>> @@ -130,6 +142,7 @@ static const struct drm_bridge_funcs
> >>> panel_bridge_bridge_funcs = {
> >>> .enable = panel_bridge_enable,
> >>> .disable = panel_bridge_disable,
> >>> .post_disable = panel_bridge_post_disable,
> >>> + .get_modes = panel_bridge_get_modes,
> >>> };
> >>>
> >>> /**
> >>> @@ -175,6 +188,9 @@ struct drm_bridge *drm_panel_bridge_add(struct
> >>> drm_panel *panel,
> >>> #ifdef CONFIG_OF
> >>> panel_bridge->bridge.of_node = panel->dev->of_node;
> >>> #endif
> >>> + panel_bridge->bridge.ops = DRM_BRIDGE_OP_MODES;
> >>> + /* FIXME: The panel should report its type. */
> >>> + panel_bridge->bridge.type = DRM_MODE_CONNECTOR_DPI;
> >>
> >> Shouldn't we patch all panel drivers to expose this type before doing
> >> this change? I mean, the connector type is exposed to userspace, and I
> >> wouldn't be surprised if some userspace apps/libs decided to base their
> >> output selection logic on this field.
> >
> > Note that this type will only make it to userspace for drivers that use
> > the bridge->type field, likely through the drm bridge connector helper.
> > I do agree that panel drivers should be updated, but given the number of
> > panels in panel-simple and the fact that the information would need to
> > be researched for most of them, this will be significant work. Can't
> > this be done when converting display controller drivers on a need basis
> > ?
>
> I think setting a default value and fixing things on a need basis is
> okay, but that doesn't prevent you from adding the necessary
> infrastructure to let panel drivers pass this type (we can fallback to a
> default type in panel drivers instead of here).
I'll add the infrastructure/
> I'm also not sure why 'DPI' is chosen as the default, shouldn't we use
> 'Unknown' instead?
Mostly to avoid breaking userspace, as most panels supported by
drm_panel use DPI.
> > Or maybe we could, as an interim measure, derive the type from the bus
> > formats reported by the panel if the panel type is not set ? If the
> > panel reports MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> > MEDIA_BUS_FMT_RGB666_1X7X4_SPWG or MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA then
> > we can set the type to LVDS, otherwise we set it to DPI.
>
> Hm, aren't we better off patching panel descs exposing these bus formats
> to also explicitly set desc->type to LVDS, leaving others to Unknown
> (Unknown is 0, so you don't have to patch all panel_desc definitions)?
I was thinking about adding this logic to
drivers/gpu/drm/bridge/panel.c, which would avoid patching lots of panel
drivers as a prerequisite. With such a logic there, plus a default to
DPI, I thought we would be good enough for an initial version. It would
leave DSI unhandled, so maybe not the best :-S
> > I can submit a
> > patch to add a type field to the panel structure and implement this
> > logic.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/50] drm/bridge: Add connector-related bridge operations and data
Hi Boris,
On Thu, Aug 22, 2019 at 06:41:25PM +0200, Boris Brezillon wrote:
> On Tue, 20 Aug 2019 04:16:35 +0300 Laurent Pinchart wrote:
>
> > +/**
> > + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> > + */
> > +enum drm_bridge_ops {
> > + /**
> > +* @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> > +* its output. Bridges that set this flag shall implement the
> > +* _bridge_funcs->detect callback.
> > +*/
> > + DRM_BRIDGE_OP_DETECT = BIT(0),
> > + /**
> > +* @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> > +* connected to its output. Bridges that set this flag shall implement
> > +* the _bridge_funcs->get_edid callback.
> > +*/
> > + DRM_BRIDGE_OP_EDID = BIT(1),
> > + /**
> > +* @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> > +* without requiring polling. Bridges that set this flag shall
> > +* implement the _bridge_funcs->hpd_enable and
> > +* _bridge_funcs->hpd_disable callbacks if they support enabling
> > +* and disabling hot-plug detection dynamically.
> > +*/
> > + DRM_BRIDGE_OP_HPD = BIT(2),
> > + /**
> > +* @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> > +* by the display at its output. This does not include readind EDID
> > +* which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> > +* this flag shall implement the _bridge_funcs->get_modes callback.
> > +*/
> > + DRM_BRIDGE_OP_MODES = BIT(3),
> > +};
> > +
> > /**
> > * struct drm_bridge - central DRM bridge control structure
> > */
> > @@ -398,6 +538,33 @@ struct drm_bridge {
> > const struct drm_bridge_funcs *funcs;
> > /** @driver_private: pointer to the bridge driver's internal context */
> > void *driver_private;
> > + /** @ops: bitmask of operations supported by the bridge */
> > + enum drm_bridge_ops ops;
>
> Just realized that you're not checking ->ops and ->funcs consistency at
> attach() time (you're only checking ->ops in the tfp410 driver before
> calling ->funcs->detect() and ->funcs->get_modes() and they might be
> NULL).
Do you think that's an issue ? I would then expect the driver to crash
right away during development and the issue to be fixed.
> > + /**
> > +* @type: Type of the connection at the bridge output
> > +* (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> > +* identifies the type of connected display.
> > +*/
> > + int type;
> > + /**
> > +* @ddc: Associated I2C adapter for DDC access, if any.
> > +*/
> > + struct i2c_adapter *ddc;
> > + /** private: */
> > + /**
> > +* @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> > +*/
> > + struct mutex hpd_mutex;
> > + /**
> > +* @hpd_cb: Hot plug detection callback, registered with
> > +* drm_bridge_hpd_enable().
> > +*/
> > + void (*hpd_cb)(void *data, enum drm_connector_status status);
> > + /**
> > +* @hpd_data: Private data passed to the Hot plug detection callback
> > +* @hpd_cb.
> > +*/
> > + void *hpd_data;
> > };
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/i915: Enable CONFIG_DMA_API_DEBUG_SG for intel-ci
Now that we've fixed i915 so that it sets a max SG segment length and gotten rid of the relevant warnings, let's enable CONFIG_DMA_API_DEBUG_SG for intel-ci so that we can catch issues like this in the future as well. Changes since v2: * Also select DMA_API_DEBUG - Chris Wilson Signed-off-by: Lyude Paul Cc: Chris Wilson --- drivers/gpu/drm/i915/Kconfig.debug | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug index 00786a142ff0..cb929d0218e8 100644 --- a/drivers/gpu/drm/i915/Kconfig.debug +++ b/drivers/gpu/drm/i915/Kconfig.debug @@ -32,6 +32,8 @@ config DRM_I915_DEBUG select DRM_DEBUG_SELFTEST select DMABUF_SELFTESTS select SW_SYNC # signaling validation framework (igt/syncobj*) +select DMA_API_DEBUG +select DMA_API_DEBUG_SG select DRM_I915_SW_FENCE_DEBUG_OBJECTS select DRM_I915_SELFTEST select DRM_I915_DEBUG_RUNTIME_PM -- 2.21.0
Re: [PATCH v4 0/5] MST DSC support in drm-mst
OK-done reviewing, but there's some stuff missing here. The PBN bandwidth checks in https://patchwork.freedesktop.org/patch/325604/?series=65423=3 need to be moved into drm_dp_mst_atomic_check(), along with moving amdgpu over to using drm_dp_mst_atomic_check(). Doing so will also give us PBN bandwidth checks in both i915 and nouveau as well, and keeps the bandwidth calculation where it should be. Additionally, you still need to move the code here into an MST atomic helper or drm_dp_mst_atomic_check() as well: https://patchwork.freedesktop.org/patch/325611/?series=65423=3 Unless I'm mistaken, adding each CRTC which has a connector whose PBN requires recalculation into the atomic state is something every DRM driver is going to need to do. And, you can do this more easily by adding PBN information into drm_dp_mst_topology_state. Yes-it's a lot of locks, but since every connector in an MST topology is sharing the bandwidth on the same link it's kind of expected. I already know I'm going to have to do basically the same thing with every driver once I've got the time to actually implement fallback link rate retraining with MST topologies. If you need help figuring out how to structure this in a way that works for all drivers, I'm willing to help and I'm sure Manasi is as well. On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote: > Add necessary support for MST DSC. > (Display Stream COmpression over Multi-Stream Transport) > > v4: Split patchset and rebase onto drm-tip > > David Francis (5): > drm/dp-mst: Add PBN calculation for DSC modes > drm/dp-mst: Parse FEC capability on MST ports > drm/dp-mst: Add MST support to DP DPCD R/W functions > drm/dp-mst: Fill branch->num_ports > drm/dp-mst: Add helpers for querying and enabling MST DSC > > drivers/gpu/drm/drm_dp_aux_dev.c | 12 +- > drivers/gpu/drm/drm_dp_helper.c | 10 +- > drivers/gpu/drm/drm_dp_mst_topology.c | 243 ++ > include/drm/drm_dp_mst_helper.h | 8 +- > 4 files changed, 260 insertions(+), 13 deletions(-) > -- Cheers, Lyude Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 5/5] drm/dp-mst: Add helpers for querying and enabling MST DSC
On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote:
> Add drm_dp_mst_dsc_caps_for_port and drm_dp_mst_dsc_enable,
> two helper functions for MST DSC
>
> The former, given a port, returns the raw DPCD DSC caps off
> that port.
>
> The latter, given a port, enables or disables DSC on that port.
>
> In both cases, the port given as input should be a leaf of
> the MST tree with an attached display.
>
> The logic for this is somewhat complicated, as DSC can be
> enabled in 4 different ways.
>
> Case 1: DP-to-DP peer device
> if the branch immediately upstream has
> - PDT = DP_PEER_DEVICE_DP_MST_BRANCHING (2)
> - DPCD rev. >= DP 1.4
> - Exactly one input and one output
> - The output has PDT = DP_PEER_DEVICE_SST_SINK (3)
>
> In this case, DSC could be possible either on the endpoint
> or the peer device. Prefer the endpoint, which is possible if
> - The endpoint has DP_DSC_DECOMPRESSION_IS_SUPPORTED bit set
> - The endpoint has DP_FEC_CAPABLE bit set
> - The peer device has DSC_PASSTHROUGH_CAPABILITY bit set (from DP v2.0)
>
> Otherwise, use the peer device
>
> Case 2: DP-to-HDMI peer device
> If the output port has
> - PDT = DP_PEER_DEVICE_DP_LEGACY_CONV (4)
> - DPCD rev. >= DP 1.4
> - LDPS = true
> - MCS = false
>
> In this case, DSC can only be attempted on the peer device
> (the output port)
>
> Case 3: Virtual DP Sink (Internal Display Panel)
> If the output port has
> - DPCD rev. >= DP 1.4
> - port_num >= 8
>
> In this case, DSC can only be attempted on the peer device
> (the output port)
>
> Case 4: Synaptix Workaround
> If the output has
> - link DPCD rev. >= DP 1.4
> - link branch_dev_id = 0x90CC24 (Synaptix)
> - There is exactly one branch device between the link and output
>
> In this case, DSC can be attempted, but only using the *link*
> aux device's caps. This is a quirk.
>
> Cc: Lyude Paul
> Cc: Wenjing Liu
> Cc: Nikola Cornij
> Signed-off-by: David Francis
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 195 ++
> include/drm/drm_dp_mst_helper.h | 3 +
> 2 files changed, 198 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index af4b5cec7c84..00ddc54af65b 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4186,3 +4186,198 @@ static void drm_dp_mst_unregister_i2c_bus(struct
> drm_dp_aux *aux)
> {
> i2c_del_adapter(>ddc);
> }
> +
> +/**
> + * drm_dp_mst_is_virtual_dpcd() - Is the given port a virtual DPCD device?
> + * @port: The port to check
> + *
Mind elaborating a bit here in the kernel documentation on what a virtual DPCD
device is?
> + * Returns:
> + * true if the port is a virtual DPCD peer device, false otherwise
> + */
> +static bool drm_dp_mst_is_virtual_dpcd(struct drm_dp_mst_port *port)
> +{
> + struct drm_dp_mst_port *downstream_port;
> +
> + if (!port)
> + return false;
I'd drop this, and just move the if (!port) check into
drm_dp_mst_dsc_aux_for_port(). Makes things a little more explicit.
> +
> + /* Virtual DP Sink (Internal Display Panel) */
> + if (port->port_num >= 8 && port->dpcd_rev >= DP_DPCD_REV_14)
> + return true;
> +
> + /* DP-to-HDMI Protocol Converter */
> + if (port->pdt == DP_PEER_DEVICE_DP_LEGACY_CONV &&
> + !port->mcs &&
> + port->ldps &&
> + port->dpcd_rev >= DP_DPCD_REV_14)
> + return true;
Please fix the indenting here, most DRM code (I may have mistakenly pointed
you at the kernel style guidelines, but I realized they don't explicitly
mention this other then the rule of "your code should look like the code
around it") written with line continuations starting on the same column as the
beginning paranthesis
if (some_very_long_variable == another_very_long_variable_wow ||
every_identifier_here_is_long > but_what_if_we_have_a_sub_conditional ||
(then_we_end_up_formatting_it_like_this &&
starting_at_the_beginning_paranthesis)) {
same_for_function_calls("Which also require very long lines\n",
foo, bar, baz);
}
> +
> + /* DP-to-DP */
> + if (port->pdt == DP_PEER_DEVICE_MST_BRANCHING &&
> + port->mstb &&
> + port->dpcd_rev >= DP_DPCD_REV_14 &&
> + port->mstb->num_ports == 2) {
> + list_for_each_entry(downstream_port, >mstb->ports, next)
> {
> + if (!downstream_port->input &&
> + downstream_port->pdt ==
> DP_PEER_DEVICE_SST_SINK)
> + return true;
> + }
This isn't safe, anything that iterates downwards (so either mstb->ports, or
port->mstb) in the MST topology needs to happen under >lock, since
otherwise the port list can change under us. Note there's probably some places
this isn't followed, but I'm in the process of fixing that:
Re: [PATCH v2 34/50] drm/omap: Create connector for bridges
Hi Boris,
On Thu, Aug 22, 2019 at 07:00:11PM +0200, Boris Brezillon wrote:
> On Tue, 20 Aug 2019 04:17:05 +0300 Laurent Pinchart wrote:
> > Use the drm_bridge_connector helper to create a connector for pipelines
> > that use drm_bridge. This allows splitting connector operations across
> > multiple bridges when necessary, instead of having the last bridge in
> > the chain creating the connector and handling all connector operations
> > internally.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > Changes since v1:
> >
> > - Squash with patch "drm/omap: Detach from panels at remove time"
> > ---
> > drivers/gpu/drm/omapdrm/omap_drv.c | 82 +-
> > 1 file changed, 70 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> > b/drivers/gpu/drm/omapdrm/omap_drv.c
> > index de373fd50729..f38d95cb31ba 100644
> > --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> > +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> > @@ -11,10 +11,12 @@
> >
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -290,9 +292,14 @@ static int omap_modeset_init(struct drm_device *dev)
> >
> > if (pipe->output->bridge) {
> > ret = drm_bridge_attach(pipe->encoder,
> > - pipe->output->bridge, NULL, 0);
> > - if (ret < 0)
> > + pipe->output->bridge, NULL,
> > + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
>
> I guess the only external bridge connected to an omap display
> controller in upstream DTs is the TFP410.
No, there's also the TI OP362 (analog amplier) and TI TPD12S015 (HDMI
ESD protection and level shifter). Those are not really encoders, but
they're bridges.
> I was wondering if falling back to !DRM_BRIDGE_ATTACH_NO_CONNECTOR
> would be acceptable in case one wants to convert a display controller
> driver which is known to be used in conjunction with various external
> bridges.
Yes, a display controller can support both options. I would however
recommend addressing bridges first in a conversion, and once all bridges
used by a display controller support DRM_BRIDGE_ATTACH_NO_CONNECTOR (and
implement the connector bridge ops), switch the display controller to
DRM_BRIDGE_ATTACH_NO_CONNECTOR unconditionally.
> > + if (ret < 0) {
> > + dev_err(priv->dev,
> > + "unable to attach bridge %pOF\n",
> > + pipe->output->bridge->of_node);
> > return ret;
> > + }
> > }
> >
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] kernel.h: Add non_block_start/end()
On Tue, 20 Aug 2019 22:24:40 +0200 Daniel Vetter wrote: > Hi Peter, > > Iirc you've been involved at least somewhat in discussing this. -mm folks > are a bit undecided whether these new non_block semantics are a good idea. > Michal Hocko still is in support, but Andrew Morton and Jason Gunthorpe > are less enthusiastic. Jason said he's ok with merging the hmm side of > this if scheduler folks ack. If not, then I'll respin with the > preempt_disable/enable instead like in v1. I became mollified once Michel explained the rationale. I think it's OK. It's very specific to the oom reaper and hopefully won't be used more widely(?).
Re: [PATCH v2 2/2] drm/i915: Enable CONFIG_DMA_API_DEBUG_SG for intel-ci
Quoting Lyude Paul (2019-08-22 21:31:27) > Now that we've fixed i915 so that it sets a max SG segment length and > gotten rid of the relevant warnings, let's enable > CONFIG_DMA_API_DEBUG_SG for intel-ci so that we can catch issues like > this in the future as well. > > Signed-off-by: Lyude Paul > Cc: Chris Wilson > --- > drivers/gpu/drm/i915/Kconfig.debug | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/Kconfig.debug > b/drivers/gpu/drm/i915/Kconfig.debug > index 00786a142ff0..ad8d3cd63c9f 100644 > --- a/drivers/gpu/drm/i915/Kconfig.debug > +++ b/drivers/gpu/drm/i915/Kconfig.debug > @@ -32,6 +32,7 @@ config DRM_I915_DEBUG > select DRM_DEBUG_SELFTEST > select DMABUF_SELFTESTS > select SW_SYNC # signaling validation framework (igt/syncobj*) select DMA_API_DEBUG as well for it to be enabled, no recursive dependency solver in Kconfig. > +select DMA_API_DEBUG_SG > select DRM_I915_SW_FENCE_DEBUG_OBJECTS > select DRM_I915_SELFTEST > select DRM_I915_DEBUG_RUNTIME_PM > -- > 2.21.0 >
[PATCH] drm: Add LTTPR defines for DP 1.4
DP 1.4 specification defines Link Training Tunable PHY Repeater (LTTPR) which is required to add support for systems with Thunderbolt or other repeater devices. Cc: Abdoulaye Berthe Cc: Harry Wentland Cc: Leo Li Signed-off-by: Rodrigo Siqueira Signed-off-by: Abdoulaye Berthe --- include/drm/drm_dp_helper.h | 26 ++ 1 file changed, 26 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 8364502f92cf..8336d960da7f 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -134,6 +134,32 @@ #define DP_SUPPORTED_LINK_RATES0x010 /* eDP 1.4 */ # define DP_MAX_SUPPORTED_RATES 8 /* 16-bit little-endian */ +/** Link Training (LT)-tunable Physical Repeaters - DP 1.4 **/ +#define DP_LTTPR_REV 0xf +#define DP_LTTPR_MAX_LINK_RATE0xf0001 +#define DP_LTTPR_REPEATER_CNT 0xf0002 +#define DP_LTTPR_REPEATER_MODE0xf0003 +#define DP_LTTPR_MAX_LANE_CNT 0xf0004 +#define DP_LTTPR_EXTENDED_WAIT_TIMEOUT0xf0005 +#define DP_LTTPR_TRAINING_PATTERN_SET_REPEATER1 0xf0010 +#define DP_LTTPR_TRAINING_LANE0_SET_REPEATER1 0xf0011 +#define DP_LTTPR_TRAINING_LANE1_SET_REPEATER1 0xf0012 +#define DP_LTTPR_TRAINING_LANE2_SET_REPEATER1 0xf0013 +#define DP_LTTPR_TRAINING_LANE3_SET_REPEATER1 0xf0014 +#define DP_LTTPR_TRAINING_AUX_RD_INTERVAL_REPEATER1 0xf0020 +#define DP_LTTPR_TRANSMITTER_CAPABILITY_REPEATER1 0xf0021 +#define DP_LTTPR_LANE0_1_STATUS_REPEATER1 0xf0030 +#define DP_LTTPR_LANE2_3_STATUS_REPEATER1 0xf0031 +#define DP_LTTPR_LANE_ALIGN_STATUS_UPDATED_REPEATER1 0xf0032 +#define DP_LTTPR_ADJUST_REQUEST_LANE0_1_REPEATER1 0xf0033 +#define DP_LTTPR_ADJUST_REQUEST_LANE2_3_REPEATER1 0xf0034 +#define DP_LTTPR_SYMBOL_ERROR_COUNT_LANE0_REPEATER1 0xf0035 +#define DP_LTTPR_SYMBOL_ERROR_COUNT_LANE1_REPEATER1 0xf0037 +#define DP_LTTPR_SYMBOL_ERROR_COUNT_LANE2_REPEATER1 0xf0039 +#define DP_LTTPR_SYMBOL_ERROR_COUNT_LANE3_REPEATER1 0xf003b +#define DP_REPEATER_CONFIGURATION_AND_STATUS_OFFSET 0x50 +#define DP_LTTPR_FEC_STATUS_REPEATER1 0xf0290 + /* Multiple stream transport */ #define DP_FAUX_CAP0x020 /* 1.2 */ # define DP_FAUX_CAP_1 (1 << 0) -- 2.23.0 signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/syncobj: Add documentation for timeline syncobj
On 22/08/2019 21:24, Jason Ekstrand wrote: On Thu, Aug 22, 2019 at 9:55 AM Lionel Landwerlin mailto:lionel.g.landwer...@intel.com>> wrote: We've added a set of new APIs to manipulate syncobjs holding timelines of dma_fence. This adds a bit of documentation about how this works. Signed-off-by: Lionel Landwerlin mailto:lionel.g.landwer...@intel.com>> Cc: Christian Koenig mailto:christian.koe...@amd.com>> Cc: Jason Ekstrand mailto:ja...@jlekstrand.net>> Cc: David(ChunMing) Zhou mailto:david1.z...@amd.com>> --- drivers/gpu/drm/drm_syncobj.c | 87 +-- 1 file changed, 74 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c index b5ad73330a48..32ffded6d2c0 100644 --- a/drivers/gpu/drm/drm_syncobj.c +++ b/drivers/gpu/drm/drm_syncobj.c @@ -43,27 +43,66 @@ * - Signal a syncobj (set a trivially signaled fence) * - Wait for a syncobj's fence to appear and be signaled * + * The syncobj userspace API also provides operations to manipulate a syncobj + * in terms of a timeline of struct _fence rather than a single struct + * _fence, through the following operations: + * + * - Signal a given point on the timeline + * - Wait for a given point to appear and/or be signaled + * - Import and export from/to a given point of a timeline + * * At it's core, a syncobj is simply a wrapper around a pointer to a struct * _fence which may be NULL. * When a syncobj is first created, its pointer is either NULL or a pointer * to an already signaled fence depending on whether the * _SYNCOBJ_CREATE_SIGNALED flag is passed to * _IOCTL_SYNCOBJ_CREATE. - * When GPU work which signals a syncobj is enqueued in a DRM driver, - * the syncobj fence is replaced with a fence which will be signaled by the - * completion of that work. - * When GPU work which waits on a syncobj is enqueued in a DRM driver, the - * driver retrieves syncobj's current fence at the time the work is enqueued - * waits on that fence before submitting the work to hardware. - * If the syncobj's fence is NULL, the enqueue operation is expected to fail. - * All manipulation of the syncobjs's fence happens in terms of the current - * fence at the time the ioctl is called by userspace regardless of whether - * that operation is an immediate host-side operation (signal or reset) or - * or an operation which is enqueued in some driver queue. - * _IOCTL_SYNCOBJ_RESET and _IOCTL_SYNCOBJ_SIGNAL can be used to - * manipulate a syncobj from the host by resetting its pointer to NULL or + * + * If the syncobj is considered as a binary (signal/unsignaled) primitive, What does "considered as a binary" mean? Is it an inherent property of the syncobj given at create time? Is it a state the syncobj can be in? Or is it a property of how the submit ioctl in the DRM driver references it? I'm really hoping it's either 1 or 3 3: you either use it binary/legacy apis, or timeline apis. timeline apis also provide some binary compatibility with the point 0 (in particular for wait). + * when GPU work is enqueued in a DRM driver to signal the syncobj, the fence + * is replaced with a fence which will be signaled by the completion of that + * work. + * If the syncobj is considered as a timeline primitive, when GPU work is + * enqueued in a DRM driver to signal the a given point of the syncobj, a new + * struct _fence_chain pointing to the DRM driver's fence and also + * pointing to the previous fence that was in the syncobj. The new struct + * _fence_chain fence put into the syncobj will be signaled by completion + * of the DRM driver's work and also any work associated with the fence + * previously in the syncobj. + * + * When GPU work which waits on a syncobj is enqueued in a DRM driver, at the + * time the work is enqueued, it waits on the fence coming from the syncobj + * before submitting the work to hardware. That fence is either : + * + * - The syncobj's current fence if the syncobj is considered as a binary + * primitive. + * - The struct _fence associated with a given point if the syncobj is + * considered as a timeline primitive. + * + * If the syncobj's fence is NULL or not present in the syncobj's timeline, + * the enqueue operation is expected to fail. + * + * With binary syncobj, all manipulation of the syncobjs's fence happens in + * terms of the current fence at the time the ioctl is called by userspace + * regardless of whether that operation is an immediate host-side operation + * (signal or reset) or or an operation which
Re: linux-next: build warning after merge of the drm-fixes tree
On Thu, Aug 22, 2019 at 6:06 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the drm-fixes tree, today's linux-next build (KCONFIG_NAME)
> produced this warning:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c: In function
> 'smu_v11_0_setup_pptable':
> drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:368:40: warning: 'size'
> may be used uninitialized in this function [-Wmaybe-uninitialized]
>smu->smu_table.power_play_table_size = size;
>~^~
>
> Introduced by commit
>
> 00430144ff73 ("drm/amd/powerplay: fix variable type errors in
> smu_v11_0_setup_pptable")
>
> Looks like a false positive.
Silenced here:
https://patchwork.freedesktop.org/patch/325728/
Alex
>
> --
> Cheers,
> Stephen Rothwell
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: build warning after merge of the drm-fixes tree
Hi all,
After merging the drm-fixes tree, today's linux-next build (KCONFIG_NAME)
produced this warning:
drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c: In function
'smu_v11_0_setup_pptable':
drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:368:40: warning: 'size' may
be used uninitialized in this function [-Wmaybe-uninitialized]
smu->smu_table.power_play_table_size = size;
~^~
Introduced by commit
00430144ff73 ("drm/amd/powerplay: fix variable type errors in
smu_v11_0_setup_pptable")
Looks like a false positive.
--
Cheers,
Stephen Rothwell
pgpQGhfPiC2Tj.pgp
Description: OpenPGP digital signature
Re: [PATCH v4 4/5] drm/dp-mst: Fill branch->num_ports
On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote: > This field on drm_dp_mst_branch was never filled > > Initialize it to zero when the list of ports is created. > When a port is added to the list, increment num_ports, > and when a port is removed from the list, decrement num_ports. > > v2: remember to decrement on port removal > > Signed-off-by: David Francis > Reviewed-by: Lyude Paul > --- > drivers/gpu/drm/drm_dp_mst_topology.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c > b/drivers/gpu/drm/drm_dp_mst_topology.c > index 50a044718439..af4b5cec7c84 100644 > --- a/drivers/gpu/drm/drm_dp_mst_topology.c > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c > @@ -919,6 +919,7 @@ static struct drm_dp_mst_branch > *drm_dp_add_mst_branch_device(u8 lct, u8 *rad) > INIT_LIST_HEAD(>ports); > kref_init(>topology_kref); > kref_init(>malloc_kref); > + mstb->num_ports = 0; Just realized as well, we can drop the mstb->num_ports = 0; here, since we're allocating the struct with kzalloc() > return mstb; > } > > @@ -1669,6 +1670,7 @@ static void drm_dp_add_port(struct drm_dp_mst_branch > *mstb, > mutex_lock(>mgr->lock); > drm_dp_mst_topology_get_port(port); > list_add(>next, >ports); > + mstb->num_ports++; > mutex_unlock(>mgr->lock); > } > > @@ -1703,6 +1705,7 @@ static void drm_dp_add_port(struct drm_dp_mst_branch > *mstb, > /* remove it from the port list */ > mutex_lock(>mgr->lock); > list_del(>next); > + mstb->num_ports--; > mutex_unlock(>mgr->lock); > /* drop port list reference */ > drm_dp_mst_topology_put_port(port); -- Cheers, Lyude Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/5] drm/dp-mst: Add MST support to DP DPCD R/W functions
Mhhh, one last nitpick
On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote:
> Instead of having drm_dp_dpcd_read/write and
> drm_dp_mst_dpcd_read/write as entry points into the
> aux code, have drm_dp_dpcd_read/write handle both.
>
> This means that DRM drivers can make MST DPCD read/writes.
>
> v2: Fix spacing
>
> Cc: Leo Li
> Cc: Lyude Paul
> Signed-off-by: David Francis
> ---
> drivers/gpu/drm/drm_dp_aux_dev.c | 12 ++--
> drivers/gpu/drm/drm_dp_helper.c | 10 --
> 2 files changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c
> b/drivers/gpu/drm/drm_dp_aux_dev.c
> index 0cfb386754c3..418cad4f649a 100644
> --- a/drivers/gpu/drm/drm_dp_aux_dev.c
> +++ b/drivers/gpu/drm/drm_dp_aux_dev.c
> @@ -163,11 +163,7 @@ static ssize_t auxdev_read_iter(struct kiocb *iocb,
> struct iov_iter *to)
> break;
> }
>
> - if (aux_dev->aux->is_remote)
> - res = drm_dp_mst_dpcd_read(aux_dev->aux, pos, buf,
> -todo);
> - else
> - res = drm_dp_dpcd_read(aux_dev->aux, pos, buf, todo);
> + res = drm_dp_dpcd_read(aux_dev->aux, pos, buf, todo);
>
> if (res <= 0)
> break;
> @@ -215,11 +211,7 @@ static ssize_t auxdev_write_iter(struct kiocb *iocb,
> struct iov_iter *from)
> break;
> }
>
> - if (aux_dev->aux->is_remote)
> - res = drm_dp_mst_dpcd_write(aux_dev->aux, pos, buf,
> - todo);
> - else
> - res = drm_dp_dpcd_write(aux_dev->aux, pos, buf, todo);
> + res = drm_dp_mst_dpcd_write(aux_dev->aux, pos, buf, todo);
>
> if (res <= 0)
> break;
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c
> index ffc68d305afe..b1599760b6a3 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -30,6 +30,7 @@
> #include
>
> #include
> +#include
> #include
> #include
>
> @@ -251,7 +252,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
> request,
>
> /**
> * drm_dp_dpcd_read() - read a series of bytes from the DPCD
> - * @aux: DisplayPort AUX channel
> + * @aux: DisplayPort AUX channel (SST or MST)
> * @offset: address of the (first) register to read
> * @buffer: buffer to store the register values
> * @size: number of bytes in @buffer
> @@ -268,6 +269,8 @@ ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux,
> unsigned int offset,
> {
> int ret;
>
> + if (aux->is_remote)
> + return drm_dp_mst_dpcd_read(aux, offset, buffer, size);
Let's actually replace this with
if (aux->is_remote)
ret = drm_dp_mst_dpcd_read(aux, offset, buffer, size);
else
ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_WRITE, offset, buffer,
size);
That way we still call drm_dp_dump_access() so that we can log the DPCD read
to the kernel log.
Let's also add a space down here ⬇...
> /*
>* HP ZR24w corrupts the first DPCD access after entering power save
>* mode. Eg. on a read, the entire buffer will be filled with the same
> @@ -296,7 +299,7 @@ EXPORT_SYMBOL(drm_dp_dpcd_read);
>
> /**
> * drm_dp_dpcd_write() - write a series of bytes to the DPCD
> - * @aux: DisplayPort AUX channel
> + * @aux: DisplayPort AUX channel (SST or MST)
> * @offset: address of the (first) register to write
> * @buffer: buffer containing the values to write
> * @size: number of bytes in @buffer
> @@ -313,6 +316,9 @@ ssize_t drm_dp_dpcd_write(struct drm_dp_aux *aux,
> unsigned int offset,
> {
> int ret;
>
> + if (aux->is_remote)
> + return drm_dp_mst_dpcd_write(aux, offset, buffer, size);
> +
...and do the same thing with drm_dp_dpcd_write() that we did with
drm_dp_dpcd_read()
With those changes, this patch is:
Reviewed-by: Lyude Paul
> ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_WRITE, offset, buffer,
>size);
> drm_dp_dump_access(aux, DP_AUX_NATIVE_WRITE, offset, buffer, ret);
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/drm_connector: add additional aspect ratio values
For HDMI2.0 CTS item - HF1-35, it verifies if the source generates
video timing "64:27" video format correctly.
eg: (vic-76) 1920x1080p@60Hz,24bpp
This patch add on "64:27" and "256:135" to drm_aspect_ratio_enum_list.
Thereafter, one can specify the aspect ratio to "64:27" or "256:135"
after creating aspect ratio property.
Change-Id: Ifc9df54e8e8f78e70960fcd737a3a57e49c81152
Signed-off-by: Wayne Lin
---
drivers/gpu/drm/drm_connector.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 3a0cacb71235..c0629a01d08e 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -772,6 +772,8 @@ static const struct drm_prop_enum_list
drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_NONE, "Automatic" },
{ DRM_MODE_PICTURE_ASPECT_4_3, "4:3" },
{ DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
+ { DRM_MODE_PICTURE_ASPECT_64_27, "64:27" },
+ { DRM_MODE_PICTURE_ASPECT_256_135, "256:135" },
};
static const struct drm_prop_enum_list drm_content_type_enum_list[] = {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/5] drm/dp-mst: Add PBN calculation for DSC modes
Agh, sorry to go back on this - I'm noticing a lot more changes we should have
now that I've been able apply this locally to my tree. See below:
On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote:
> With DSC, bpp can be a multiple of 1/16, so
> drm_dp_calc_pbn_mode is insufficient.
>
> Add drm_dp_calc_pbn_mode_dsc, a function which is
> the same as drm_dp_calc_pbn_mode, but the bpp is
> in units of 1/16.
>
> Reviewed-by: Lyude Paul
> Signed-off-by: David Francis
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 43 +++
> include/drm/drm_dp_mst_helper.h | 2 +-
> 2 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 82add736e17d..8e2e731c35c5 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3591,6 +3591,49 @@ static int test_calc_pbn_mode(void)
> return 0;
> }
>
> +/**
> + * drm_dp_calc_pbn_mode_dsc() - Calculate the PBN for a mode with DSC
> enabled.
> + * @clock: dot clock for the mode
> + * @dsc_bpp: dsc bits per pixel x16 (e.g. dsc_bpp = 136 is 8.5 bpp)
> + *
> + * This uses the formula in the spec to calculate the PBN value for a mode,
> + * given that the mode is using DSC
> + * Returns:
> + * PBN required for this mode
> + */
> +int drm_dp_calc_pbn_mode_dsc(int clock, int dsc_bpp)
> +{
> + u64 kbps;
> + s64 peak_kbps;
> + u32 numerator;
> + u32 denominator;
> +
> + kbps = clock * dsc_bpp;
> +
> + /*
> + * margin 5300ppm + 300ppm ~ 0.6% as per spec, factor is 1.006
> + * The unit of 54/64Mbytes/sec is an arbitrary unit chosen based on
> + * common multiplier to render an integer PBN for all link rate/lane
> + * counts combinations
> + * calculate
> + * peak_kbps *= (1/16) bppx16 to bpp
> + * peak_kbps *= (1006/1000)
> + * peak_kbps *= (64/54)
> + * peak_kbps *= 8convert to bytes
> + *
> + * Divide numerator and denominator by 16 to avoid overflow
> + */
> +
> + numerator = 64 * 1006 / 16;
> + denominator = 54 * 8 * 1000 * 1000;
> +
> + kbps *= numerator;
> + peak_kbps = drm_fixp_from_fraction(kbps, denominator);
> +
> + return drm_fixp2int_ceil(peak_kbps);
> +}
> +EXPORT_SYMBOL(drm_dp_calc_pbn_mode_dsc);
I didn't notice until now that the only difference between the two functions
is
numerator = 64 * 1006 / 16;
So it doesn't seem like it's worth having two seperate functions for this, so
let's just get rid of drm_dp_calc_pbn_mode_dsc() and combine it with
drm_dp_calc_pbn_mode() by adding a bool parameter to specify whether or not
we're calculating for dsc
> +
> /* we want to kick the TX after we've ack the up/down IRQs. */
> static void drm_dp_mst_kick_tx(struct drm_dp_mst_topology_mgr *mgr)
> {
> diff --git a/include/drm/drm_dp_mst_helper.h
> b/include/drm/drm_dp_mst_helper.h
> index 2ba6253ea6d3..ddb518f2157a 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -611,7 +611,7 @@ struct edid *drm_dp_mst_get_edid(struct drm_connector
> *connector, struct drm_dp_
>
>
> int drm_dp_calc_pbn_mode(int clock, int bpp);
> -
> +int drm_dp_calc_pbn_mode_dsc(int clock, int dsc_bpp);
>
> bool drm_dp_mst_allocate_vcpi(struct drm_dp_mst_topology_mgr *mgr,
> struct drm_dp_mst_port *port, int pbn, int
> slots);
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/5] MST DSC support in drm-mst
Still in the process of reviewing this, but one minor change that should be done on all of the patches (which I didn't notice before, whoops): s:drm/dp-mst:drm/dp_mst:g On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote: > Add necessary support for MST DSC. > (Display Stream COmpression over Multi-Stream Transport) > > v4: Split patchset and rebase onto drm-tip > > David Francis (5): > drm/dp-mst: Add PBN calculation for DSC modes > drm/dp-mst: Parse FEC capability on MST ports > drm/dp-mst: Add MST support to DP DPCD R/W functions > drm/dp-mst: Fill branch->num_ports > drm/dp-mst: Add helpers for querying and enabling MST DSC > > drivers/gpu/drm/drm_dp_aux_dev.c | 12 +- > drivers/gpu/drm/drm_dp_helper.c | 10 +- > drivers/gpu/drm/drm_dp_mst_topology.c | 243 ++ > include/drm/drm_dp_mst_helper.h | 8 +- > 4 files changed, 260 insertions(+), 13 deletions(-) > -- Cheers, Lyude Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mcde: Fix an error handling path in 'mcde_probe()'
If we don't find any matching components, we should go through the error
handling path, in order to free some resources.
Fixes: ca5be902a87d ("drm/mcde: Fix uninitialized variable")
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/mcde/mcde_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c
index 9a09eba53182..5649887d2b90 100644
--- a/drivers/gpu/drm/mcde/mcde_drv.c
+++ b/drivers/gpu/drm/mcde/mcde_drv.c
@@ -484,7 +484,8 @@ static int mcde_probe(struct platform_device *pdev)
}
if (!match) {
dev_err(dev, "no matching components\n");
- return -ENODEV;
+ ret = -ENODEV;
+ goto clk_disable;
}
if (IS_ERR(match)) {
dev_err(dev, "could not create component match\n");
--
2.20.1
Re: [PATCH][drm-next] drm/amd/display: fix a potential null pointer dereference
On Thu, Aug 22, 2019 at 3:21 PM Harry Wentland wrote:
>
> On 2019-08-16 6:10 p.m., Colin King wrote:
> > From: Colin Ian King
> >
> > Currently the pointer init_data is dereferenced on the assignment
> > of fw_info before init_data is sanity checked to see if it is null.
> > Fix te potential null pointer dereference on init_data by only
> > performing dereference after it is null checked.
> >
> > Addresses-Coverity: ("Dereference before null check")
> > Fixes: 9adc8050bf3c ("drm/amd/display: make firmware info only load once
> > during dc_bios create")
> > Signed-off-by: Colin Ian King
>
> Reviewed-by: Harry Wentland
>
Applied. Thanks!
Alex
> Harry
>
> > ---
> > drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> > b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> > index bee81bf288be..926954c804a6 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> > @@ -1235,7 +1235,7 @@ static bool calc_pll_max_vco_construct(
> > struct calc_pll_clock_source_init_data *init_data)
> > {
> > uint32_t i;
> > - struct dc_firmware_info *fw_info = _data->bp->fw_info;
> > + struct dc_firmware_info *fw_info;
> > if (calc_pll_cs == NULL ||
> > init_data == NULL ||
> > init_data->bp == NULL)
> > @@ -1244,6 +1244,7 @@ static bool calc_pll_max_vco_construct(
> > if (init_data->bp->fw_info_valid)
> > return false;
> >
> > + fw_info = _data->bp->fw_info;
> > calc_pll_cs->ctx = init_data->ctx;
> > calc_pll_cs->ref_freq_khz = fw_info->pll_info.crystal_frequency;
> > calc_pll_cs->min_vco_khz =
> >
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/i915: Call dma_set_max_seg_size() in i915_ggtt_probe_hw()
Currently, we don't call dma_set_max_seg_size() for i915 because we
intentionally do not limit the segment length that the device supports.
However, this results in a warning being emitted if we try to map
anything larger than SZ_64K on a kernel with CONFIG_DMA_API_DEBUG_SG
enabled:
[7.751926] DMA-API: i915 :00:02.0: mapping sg segment longer
than device claims to support [len=98304] [max=65536]
[7.751934] WARNING: CPU: 5 PID: 474 at kernel/dma/debug.c:1220
debug_dma_map_sg+0x20f/0x340
This was originally brought up on
https://bugs.freedesktop.org/show_bug.cgi?id=108517 , and the consensus
there was it wasn't really useful to set a limit (and that dma-debug
isn't really all that useful for i915 in the first place). Unfortunately
though, CONFIG_DMA_API_DEBUG_SG is enabled in the debug configs for
various distro kernels. Since a WARN_ON() will disable automatic problem
reporting (and cause any CI with said option enabled to start
complaining), we really should just fix the problem.
Note that as me and Chris Wilson discussed, the other solution for this
would be to make DMA-API not make such assumptions when a driver hasn't
explicitly set a maximum segment size. But, taking a look at the commit
which originally introduced this behavior, commit 78c47830a5cb
("dma-debug: check scatterlist segments"), there is an explicit mention
of this assumption and how it applies to devices with no segment size:
Conversely, devices which are less limited than the rather
conservative defaults, or indeed have no limitations at all
(e.g. GPUs with their own internal MMU), should be encouraged to
set appropriate dma_parms, as they may get more efficient DMA
mapping performance out of it.
So unless there's any concerns (I'm open to discussion!), let's just
follow suite and call dma_set_max_seg_size() with UINT_MAX as our limit
to silence any warnings.
Signed-off-by: Lyude Paul
Cc: Chris Wilson
Cc: # v4.18+
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 0b81e0b64393..a1475039d182 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3152,6 +3152,11 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct
intel_gt *gt)
if (ret)
return ret;
+ /* We don't have a max segment size, so set it to the max so sg's
+* debugging layer doesn't complain
+*/
+ dma_set_max_seg_size(ggtt->vm.dma, UINT_MAX);
+
if ((ggtt->vm.total - 1) >> 32) {
DRM_ERROR("We never expected a Global GTT with more than 32bits"
" of address space! Found %lldM!\n",
--
2.21.0
[PATCH v2 2/2] drm/i915: Enable CONFIG_DMA_API_DEBUG_SG for intel-ci
Now that we've fixed i915 so that it sets a max SG segment length and gotten rid of the relevant warnings, let's enable CONFIG_DMA_API_DEBUG_SG for intel-ci so that we can catch issues like this in the future as well. Signed-off-by: Lyude Paul Cc: Chris Wilson --- drivers/gpu/drm/i915/Kconfig.debug | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug index 00786a142ff0..ad8d3cd63c9f 100644 --- a/drivers/gpu/drm/i915/Kconfig.debug +++ b/drivers/gpu/drm/i915/Kconfig.debug @@ -32,6 +32,7 @@ config DRM_I915_DEBUG select DRM_DEBUG_SELFTEST select DMABUF_SELFTESTS select SW_SYNC # signaling validation framework (igt/syncobj*) +select DMA_API_DEBUG_SG select DRM_I915_SW_FENCE_DEBUG_OBJECTS select DRM_I915_SELFTEST select DRM_I915_DEBUG_RUNTIME_PM -- 2.21.0
Re: [PATCH] drm/i915: Call dma_set_max_seg_size() in i915_ggtt_probe_hw()
...whoops.
Ignore this patch-Chris Wilson had requested that I send a patch along with
this one to enable CONFIG_DMA_API_DEBUG_SG in CI, but I completely forgot to
do that before sending. Will send out a reroll with that in just a moment
On Thu, 2019-08-22 at 16:04 -0400, Lyude Paul wrote:
> Currently, we don't call dma_set_max_seg_size() for i915 because we
> intentionally do not limit the segment length that the device supports.
> However, this results in a warning being emitted if we try to map
> anything larger than SZ_64K on a kernel with CONFIG_DMA_API_DEBUG_SG
> enabled:
>
> [7.751926] DMA-API: i915 :00:02.0: mapping sg segment longer
> than device claims to support [len=98304] [max=65536]
> [7.751934] WARNING: CPU: 5 PID: 474 at kernel/dma/debug.c:1220
> debug_dma_map_sg+0x20f/0x340
>
> This was originally brought up on
> https://bugs.freedesktop.org/show_bug.cgi?id=108517 , and the consensus
> there was it wasn't really useful to set a limit (and that dma-debug
> isn't really all that useful for i915 in the first place). Unfortunately
> though, CONFIG_DMA_API_DEBUG_SG is enabled in the debug configs for
> various distro kernels. Since a WARN_ON() will disable automatic problem
> reporting (and cause any CI with said option enabled to start
> complaining), we really should just fix the problem.
>
> Note that as me and Chris Wilson discussed, the other solution for this
> would be to make DMA-API not make such assumptions when a driver hasn't
> explicitly set a maximum segment size. But, taking a look at the commit
> which originally introduced this behavior, commit 78c47830a5cb
> ("dma-debug: check scatterlist segments"), there is an explicit mention
> of this assumption and how it applies to devices with no segment size:
>
> Conversely, devices which are less limited than the rather
> conservative defaults, or indeed have no limitations at all
> (e.g. GPUs with their own internal MMU), should be encouraged to
> set appropriate dma_parms, as they may get more efficient DMA
> mapping performance out of it.
>
> So unless there's any concerns (I'm open to discussion!), let's just
> follow suite and call dma_set_max_seg_size() with UINT_MAX as our limit
> to silence any warnings.
>
> Signed-off-by: Lyude Paul
> Cc: Chris Wilson
> Cc: # v4.18+
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 0b81e0b64393..a1475039d182 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3152,6 +3152,11 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt,
> struct intel_gt *gt)
> if (ret)
> return ret;
>
> + /* We don't have a max segment size, so set it to the max so sg's
> + * debugging layer doesn't complain
> + */
> + dma_set_max_seg_size(ggtt->vm.dma, UINT_MAX);
> +
> if ((ggtt->vm.total - 1) >> 32) {
> DRM_ERROR("We never expected a Global GTT with more than
> 32bits"
> " of address space! Found %lldM!\n",
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Call dma_set_max_seg_size() in i915_ggtt_probe_hw()
Currently, we don't call dma_set_max_seg_size() for i915 because we
intentionally do not limit the segment length that the device supports.
However, this results in a warning being emitted if we try to map
anything larger than SZ_64K on a kernel with CONFIG_DMA_API_DEBUG_SG
enabled:
[7.751926] DMA-API: i915 :00:02.0: mapping sg segment longer
than device claims to support [len=98304] [max=65536]
[7.751934] WARNING: CPU: 5 PID: 474 at kernel/dma/debug.c:1220
debug_dma_map_sg+0x20f/0x340
This was originally brought up on
https://bugs.freedesktop.org/show_bug.cgi?id=108517 , and the consensus
there was it wasn't really useful to set a limit (and that dma-debug
isn't really all that useful for i915 in the first place). Unfortunately
though, CONFIG_DMA_API_DEBUG_SG is enabled in the debug configs for
various distro kernels. Since a WARN_ON() will disable automatic problem
reporting (and cause any CI with said option enabled to start
complaining), we really should just fix the problem.
Note that as me and Chris Wilson discussed, the other solution for this
would be to make DMA-API not make such assumptions when a driver hasn't
explicitly set a maximum segment size. But, taking a look at the commit
which originally introduced this behavior, commit 78c47830a5cb
("dma-debug: check scatterlist segments"), there is an explicit mention
of this assumption and how it applies to devices with no segment size:
Conversely, devices which are less limited than the rather
conservative defaults, or indeed have no limitations at all
(e.g. GPUs with their own internal MMU), should be encouraged to
set appropriate dma_parms, as they may get more efficient DMA
mapping performance out of it.
So unless there's any concerns (I'm open to discussion!), let's just
follow suite and call dma_set_max_seg_size() with UINT_MAX as our limit
to silence any warnings.
Signed-off-by: Lyude Paul
Cc: Chris Wilson
Cc: # v4.18+
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 0b81e0b64393..a1475039d182 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3152,6 +3152,11 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct
intel_gt *gt)
if (ret)
return ret;
+ /* We don't have a max segment size, so set it to the max so sg's
+* debugging layer doesn't complain
+*/
+ dma_set_max_seg_size(ggtt->vm.dma, UINT_MAX);
+
if ((ggtt->vm.total - 1) >> 32) {
DRM_ERROR("We never expected a Global GTT with more than 32bits"
" of address space! Found %lldM!\n",
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [LKP] [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression
On Fri, 23 Aug 2019 at 03:25, Thomas Zimmermann wrote: > > Hi > > I was traveling and could reply earlier. Sorry for taking so long. > > Am 13.08.19 um 11:36 schrieb Feng Tang: > > Hi Thomas, > > > > On Mon, Aug 12, 2019 at 03:25:45PM +0800, Feng Tang wrote: > >> Hi Thomas, > >> > >> On Fri, Aug 09, 2019 at 04:12:29PM +0800, Rong Chen wrote: > >>> Hi, > >>> > > Actually we run the benchmark as a background process, do we need to > > disable the cursor and test again? > There's a worker thread that updates the display from the shadow buffer. > The blinking cursor periodically triggers the worker thread, but the > actual update is just the size of one character. > > The point of the test without output is to see if the regression comes > >>> >from the buffer update (i.e., the memcpy from shadow buffer to VRAM), or > >>> >from the worker thread. If the regression goes away after disabling the > blinking cursor, then the worker thread is the problem. If it already > goes away if there's simply no output from the test, the screen update > is the problem. On my machine I have to disable the blinking cursor, so > I think the worker causes the performance drop. > >>> > >>> We disabled redirecting stdout/stderr to /dev/kmsg, and the regression is > >>> gone. > >>> > >>> commit: > >>> f1f8555dfb9 drm/bochs: Use shadow buffer for bochs framebuffer console > >>> 90f479ae51a drm/mgag200: Replace struct mga_fbdev with generic > >>> framebuffer > >>> emulation > >>> > >>> f1f8555dfb9a70a2 90f479ae51afa45efab97afdde testcase/testparams/testbox > >>> -- --- > >>> %stddev change %stddev > >>> \ |\ > >>> 43785 44481 > >>> vm-scalability/300s-8T-anon-cow-seq-hugetlb/lkp-knm01 > >>> 43785 44481GEO-MEAN > >>> vm-scalability.median > >> > >> Till now, from Rong's tests: > >> 1. Disabling cursor blinking doesn't cure the regression. > >> 2. Disabling printint test results to console can workaround the > >> regression. > >> > >> Also if we set the perfer_shadown to 0, the regression is also > >> gone. > > > > We also did some further break down for the time consumed by the > > new code. > > > > The drm_fb_helper_dirty_work() calls sequentially > > 1. drm_client_buffer_vmap (290 us) > > 2. drm_fb_helper_dirty_blit_real (19240 us) > > 3. helper->fb->funcs->dirty()---> NULL for mgag200 driver > > 4. drm_client_buffer_vunmap (215 us) > > > > It's somewhat different to what I observed, but maybe I just couldn't > reproduce the problem correctly. > > > The average run time is listed after the function names. > > > > From it, we can see drm_fb_helper_dirty_blit_real() takes too long > > time (about 20ms for each run). I guess this is the root cause > > of this regression, as the original code doesn't use this dirty worker. > > True, the original code uses a temporary buffer, but updates the display > immediately. > > My guess is that this could be a caching problem. The worker runs on a > different CPU, which doesn't have the shadow buffer in cache. > > > As said in last email, setting the prefer_shadow to 0 can avoid > > the regrssion. Could it be an option? > > Unfortunately not. Without the shadow buffer, the console's display > buffer permanently resides in video memory. It consumes significant > amount of that memory (say 8 MiB out of 16 MiB). That doesn't leave > enough room for anything else. > > The best option is to not print to the console. Wait a second, I thought the driver did an eviction on modeset of the scanned out object, this was a deliberate design decision made when writing those drivers, has this been removed in favour of gem and generic code paths? Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 19/19] drm: rcar-du: kms: Update CMM in atomic commit tail
Hi Jacopo,
On Thu, Aug 22, 2019 at 09:19:25PM +0200, Jacopo Mondi wrote:
> On Tue, Aug 20, 2019 at 09:42:15PM +0300, Laurent Pinchart wrote:
> > On Sat, Jul 06, 2019 at 04:07:46PM +0200, Jacopo Mondi wrote:
> > > Update CMM settings at in the atomic commit tail helper method.
> > >
> > > The CMM is updated with new gamma values provided to the driver
> > > in the GAMMA_LUT blob property.
> > >
> > > Signed-off-by: Jacopo Mondi
> > > ---
> > > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 35 +++
> > > 1 file changed, 35 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > index b79cda2f5531..f9aece78ca5f 100644
> > > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > @@ -21,6 +21,7 @@
> > > #include
> > > #include
> > >
> > > +#include "rcar_cmm.h"
> > > #include "rcar_du_crtc.h"
> > > #include "rcar_du_drv.h"
> > > #include "rcar_du_encoder.h"
> > > @@ -287,6 +288,37 @@ rcar_du_fb_create(struct drm_device *dev, struct
> > > drm_file *file_priv,
> > > * Atomic Check and Update
> > > */
> > >
> > > +static void rcar_du_atomic_commit_update_cmm(struct drm_crtc *crtc,
> > > + struct drm_crtc_state *old_state)
> > > +{
> > > + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> > > + struct rcar_cmm_config cmm_config = {};
> > > +
> > > + if (!rcrtc->cmm || !crtc->state->color_mgmt_changed)
> > > + return;
> > > +
> > > + if (!crtc->state->gamma_lut) {
> > > + cmm_config.lut.enable = false;
> > > + rcar_cmm_setup(rcrtc->cmm, _config);
> > > +
> > > + return;
> > > + }
> > > +
> > > + cmm_config.lut.enable = true;
> > > + cmm_config.lut.table = (struct drm_color_lut *)
> > > +crtc->state->gamma_lut->data;
> > > +
> > > + /* Set LUT table size to 0 if entries should not be updated. */
> > > + if (!old_state->gamma_lut ||
> > > + old_state->gamma_lut->base.id != crtc->state->gamma_lut->base.id)
> > > + cmm_config.lut.size = crtc->state->gamma_lut->length
> > > + / sizeof(cmm_config.lut.table[0]);
> > > + else
> > > + cmm_config.lut.size = 0;
> > > +
> > > + rcar_cmm_setup(rcrtc->cmm, _config);
> > > +}
> > > +
> > > static int rcar_du_atomic_check(struct drm_device *dev,
> > > struct drm_atomic_state *state)
> > > {
> > > @@ -329,6 +361,9 @@ static void rcar_du_atomic_commit_tail(struct
> > > drm_atomic_state *old_state)
> > > rcdu->dpad1_source = rcrtc->index;
> > > }
> > >
> > > + for_each_old_crtc_in_state(old_state, crtc, crtc_state, i)
> > > + rcar_du_atomic_commit_update_cmm(crtc, crtc_state);
> > > +
> >
> > I think this looks good overall, but I wonder if we couldn't simplify
> > the CMM driver suspend/resume and LUT caching due to config while not
> > enabled by handling it on the DU side. I have a rework on the commit
> > tail handler in progress, I'll think how this could be done. For now I
> > think you can leave it as is.
>
> Does this mean I have your R-b tag ? :)
I'd like to review this in the context of v3 :-)
> > > /* Apply the atomic update. */
> > > drm_atomic_helper_commit_modeset_disables(dev, old_state);
> > > drm_atomic_helper_commit_planes(dev, old_state,
--
Regards,
Laurent Pinchart
Re: [PATCH] drm/syncobj: Add documentation for timeline syncobj
On Thu, Aug 22, 2019 at 9:55 AM Lionel Landwerlin < lionel.g.landwer...@intel.com> wrote: > We've added a set of new APIs to manipulate syncobjs holding timelines > of dma_fence. This adds a bit of documentation about how this works. > > Signed-off-by: Lionel Landwerlin > Cc: Christian Koenig > Cc: Jason Ekstrand > Cc: David(ChunMing) Zhou > --- > drivers/gpu/drm/drm_syncobj.c | 87 +-- > 1 file changed, 74 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c > index b5ad73330a48..32ffded6d2c0 100644 > --- a/drivers/gpu/drm/drm_syncobj.c > +++ b/drivers/gpu/drm/drm_syncobj.c > @@ -43,27 +43,66 @@ > * - Signal a syncobj (set a trivially signaled fence) > * - Wait for a syncobj's fence to appear and be signaled > * > + * The syncobj userspace API also provides operations to manipulate a > syncobj > + * in terms of a timeline of struct _fence rather than a single struct > + * _fence, through the following operations: > + * > + * - Signal a given point on the timeline > + * - Wait for a given point to appear and/or be signaled > + * - Import and export from/to a given point of a timeline > + * > * At it's core, a syncobj is simply a wrapper around a pointer to a > struct > * _fence which may be NULL. > * When a syncobj is first created, its pointer is either NULL or a > pointer > * to an already signaled fence depending on whether the > * _SYNCOBJ_CREATE_SIGNALED flag is passed to > * _IOCTL_SYNCOBJ_CREATE. > - * When GPU work which signals a syncobj is enqueued in a DRM driver, > - * the syncobj fence is replaced with a fence which will be signaled by > the > - * completion of that work. > - * When GPU work which waits on a syncobj is enqueued in a DRM driver, the > - * driver retrieves syncobj's current fence at the time the work is > enqueued > - * waits on that fence before submitting the work to hardware. > - * If the syncobj's fence is NULL, the enqueue operation is expected to > fail. > - * All manipulation of the syncobjs's fence happens in terms of the > current > - * fence at the time the ioctl is called by userspace regardless of > whether > - * that operation is an immediate host-side operation (signal or reset) or > - * or an operation which is enqueued in some driver queue. > - * _IOCTL_SYNCOBJ_RESET and _IOCTL_SYNCOBJ_SIGNAL can be used to > - * manipulate a syncobj from the host by resetting its pointer to NULL or > + * > + * If the syncobj is considered as a binary (signal/unsignaled) primitive, > What does "considered as a binary" mean? Is it an inherent property of the syncobj given at create time? Is it a state the syncobj can be in? Or is it a property of how the submit ioctl in the DRM driver references it? I'm really hoping it's either 1 or 3 > + * when GPU work is enqueued in a DRM driver to signal the syncobj, the > fence > + * is replaced with a fence which will be signaled by the completion of > that > + * work. > + * If the syncobj is considered as a timeline primitive, when GPU work is > + * enqueued in a DRM driver to signal the a given point of the syncobj, a > new > + * struct _fence_chain pointing to the DRM driver's fence and also > + * pointing to the previous fence that was in the syncobj. The new struct > + * _fence_chain fence put into the syncobj will be signaled by > completion > + * of the DRM driver's work and also any work associated with the fence > + * previously in the syncobj. > + * > + * When GPU work which waits on a syncobj is enqueued in a DRM driver, at > the > + * time the work is enqueued, it waits on the fence coming from the > syncobj > + * before submitting the work to hardware. That fence is either : > + * > + *- The syncobj's current fence if the syncobj is considered as a > binary > + * primitive. > + *- The struct _fence associated with a given point if the > syncobj is > + * considered as a timeline primitive. > + * > + * If the syncobj's fence is NULL or not present in the syncobj's > timeline, > + * the enqueue operation is expected to fail. > + * > + * With binary syncobj, all manipulation of the syncobjs's fence happens > in > + * terms of the current fence at the time the ioctl is called by userspace > + * regardless of whether that operation is an immediate host-side > operation > + * (signal or reset) or or an operation which is enqueued in some driver > + * queue. _IOCTL_SYNCOBJ_RESET and _IOCTL_SYNCOBJ_SIGNAL can be > used > + * to manipulate a syncobj from the host by resetting its pointer to NULL > or > * setting its pointer to a fence which is already signaled. > * > + * With timeline syncobj, all manipulation of the timeline fences happens > in > + * terms of the fence referred to in the timeline. See > + * dma_fence_chain_find_seqno() to see how a given point is found in the > + * timeline. > + * > + * Note that applications should be careful to always use timeline set of > + *
Re: [PATCH][drm-next] drm/amd/display: fix a potential null pointer dereference
On 2019-08-16 6:10 p.m., Colin King wrote:
> From: Colin Ian King
>
> Currently the pointer init_data is dereferenced on the assignment
> of fw_info before init_data is sanity checked to see if it is null.
> Fix te potential null pointer dereference on init_data by only
> performing dereference after it is null checked.
>
> Addresses-Coverity: ("Dereference before null check")
> Fixes: 9adc8050bf3c ("drm/amd/display: make firmware info only load once
> during dc_bios create")
> Signed-off-by: Colin Ian King
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> index bee81bf288be..926954c804a6 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> @@ -1235,7 +1235,7 @@ static bool calc_pll_max_vco_construct(
> struct calc_pll_clock_source_init_data *init_data)
> {
> uint32_t i;
> - struct dc_firmware_info *fw_info = _data->bp->fw_info;
> + struct dc_firmware_info *fw_info;
> if (calc_pll_cs == NULL ||
> init_data == NULL ||
> init_data->bp == NULL)
> @@ -1244,6 +1244,7 @@ static bool calc_pll_max_vco_construct(
> if (init_data->bp->fw_info_valid)
> return false;
>
> + fw_info = _data->bp->fw_info;
> calc_pll_cs->ctx = init_data->ctx;
> calc_pll_cs->ref_freq_khz = fw_info->pll_info.crystal_frequency;
> calc_pll_cs->min_vco_khz =
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 19/19] drm: rcar-du: kms: Update CMM in atomic commit tail
Hi Laurent,
On Tue, Aug 20, 2019 at 09:42:15PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Sat, Jul 06, 2019 at 04:07:46PM +0200, Jacopo Mondi wrote:
> > Update CMM settings at in the atomic commit tail helper method.
> >
> > The CMM is updated with new gamma values provided to the driver
> > in the GAMMA_LUT blob property.
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 35 +++
> > 1 file changed, 35 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > index b79cda2f5531..f9aece78ca5f 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > @@ -21,6 +21,7 @@
> > #include
> > #include
> >
> > +#include "rcar_cmm.h"
> > #include "rcar_du_crtc.h"
> > #include "rcar_du_drv.h"
> > #include "rcar_du_encoder.h"
> > @@ -287,6 +288,37 @@ rcar_du_fb_create(struct drm_device *dev, struct
> > drm_file *file_priv,
> > * Atomic Check and Update
> > */
> >
> > +static void rcar_du_atomic_commit_update_cmm(struct drm_crtc *crtc,
> > +struct drm_crtc_state *old_state)
> > +{
> > + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> > + struct rcar_cmm_config cmm_config = {};
> > +
> > + if (!rcrtc->cmm || !crtc->state->color_mgmt_changed)
> > + return;
> > +
> > + if (!crtc->state->gamma_lut) {
> > + cmm_config.lut.enable = false;
> > + rcar_cmm_setup(rcrtc->cmm, _config);
> > +
> > + return;
> > + }
> > +
> > + cmm_config.lut.enable = true;
> > + cmm_config.lut.table = (struct drm_color_lut *)
> > + crtc->state->gamma_lut->data;
> > +
> > + /* Set LUT table size to 0 if entries should not be updated. */
> > + if (!old_state->gamma_lut ||
> > + old_state->gamma_lut->base.id != crtc->state->gamma_lut->base.id)
> > + cmm_config.lut.size = crtc->state->gamma_lut->length
> > + / sizeof(cmm_config.lut.table[0]);
> > + else
> > + cmm_config.lut.size = 0;
> > +
> > + rcar_cmm_setup(rcrtc->cmm, _config);
> > +}
> > +
> > static int rcar_du_atomic_check(struct drm_device *dev,
> > struct drm_atomic_state *state)
> > {
> > @@ -329,6 +361,9 @@ static void rcar_du_atomic_commit_tail(struct
> > drm_atomic_state *old_state)
> > rcdu->dpad1_source = rcrtc->index;
> > }
> >
> > + for_each_old_crtc_in_state(old_state, crtc, crtc_state, i)
> > + rcar_du_atomic_commit_update_cmm(crtc, crtc_state);
> > +
>
> I think this looks good overall, but I wonder if we couldn't simplify
> the CMM driver suspend/resume and LUT caching due to config while not
> enabled by handling it on the DU side. I have a rework on the commit
> tail handler in progress, I'll think how this could be done. For now I
> think you can leave it as is.
>
Does this mean I have your R-b tag ? :)
Thanks
j
> > /* Apply the atomic update. */
> > drm_atomic_helper_commit_modeset_disables(dev, old_state);
> > drm_atomic_helper_commit_planes(dev, old_state,
>
> --
> Regards,
>
> Laurent Pinchart
signature.asc
Description: PGP signature
Re: [PATCH v2 16/19] drm: rcar-du: kms: Collect CMM instances
Hi Laurent,
On Tue, Aug 20, 2019 at 08:54:57PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Sat, Jul 06, 2019 at 04:07:43PM +0200, Jacopo Mondi wrote:
> > Implement device tree parsing to collect the available CMM instances
> > described by the 'cmms' property. Associate CMMs with CRTCs and store a
> > mask of active CMMs in the DU group for later enablement.
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 +++
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +
> > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 3 ++
> > drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 +
> > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 50 +
> > 5 files changed, 63 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > index 2da46e3dc4ae..23f1d6cc1719 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > @@ -1194,6 +1194,12 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
> > unsigned int swindex,
> > if (ret < 0)
> > return ret;
> >
> > + /* CMM might be disabled for this CRTC. */
> > + if (rcdu->cmms[swindex]) {
> > + rcrtc->cmm = rcdu->cmms[swindex];
> > + rgrp->cmms_mask |= BIT(hwindex % 2);
> > + }
> > +
> > drm_crtc_helper_add(crtc, _helper_funcs);
> >
> > /* Start with vertical blanking interrupt reporting disabled. */
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > index 3b7fc668996f..5f2940c42225 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > @@ -39,6 +39,7 @@ struct rcar_du_vsp;
> > * @vblank_wait: wait queue used to signal vertical blanking
> > * @vblank_count: number of vertical blanking interrupts to wait for
> > * @group: CRTC group this CRTC belongs to
> > + * @cmm: CMM associated with this CRTC
> > * @vsp: VSP feeding video to this CRTC
> > * @vsp_pipe: index of the VSP pipeline feeding video to this CRTC
> > * @writeback: the writeback connector
> > @@ -64,6 +65,7 @@ struct rcar_du_crtc {
> > unsigned int vblank_count;
> >
> > struct rcar_du_group *group;
> > + struct platform_device *cmm;
> > struct rcar_du_vsp *vsp;
> > unsigned int vsp_pipe;
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> > b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> > index a00dccc447aa..300ec60ba31b 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> > @@ -13,6 +13,7 @@
> > #include
> > #include
> >
> > +#include "rcar_cmm.h"
> > #include "rcar_du_crtc.h"
> > #include "rcar_du_group.h"
> > #include "rcar_du_vsp.h"
> > @@ -70,6 +71,7 @@ struct rcar_du_device_info {
> >
> > #define RCAR_DU_MAX_CRTCS 4
> > #define RCAR_DU_MAX_GROUPS DIV_ROUND_UP(RCAR_DU_MAX_CRTCS, 2)
> > +#define RCAR_DU_MAX_CMMS 4
> > #define RCAR_DU_MAX_VSPS 4
> >
> > struct rcar_du_device {
> > @@ -86,6 +88,7 @@ struct rcar_du_device {
> > struct rcar_du_encoder *encoders[RCAR_DU_OUTPUT_MAX];
> >
> > struct rcar_du_group groups[RCAR_DU_MAX_GROUPS];
> > + struct platform_device *cmms[RCAR_DU_MAX_CMMS];
> > struct rcar_du_vsp vsps[RCAR_DU_MAX_VSPS];
> >
> > struct {
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.h
> > b/drivers/gpu/drm/rcar-du/rcar_du_group.h
> > index 87950c1f6a52..b0c1466593a3 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_group.h
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.h
> > @@ -22,6 +22,7 @@ struct rcar_du_device;
> > * @mmio_offset: registers offset in the device memory map
> > * @index: group index
> > * @channels_mask: bitmask of populated DU channels in this group
> > + * @cmms_mask: bitmask of enabled CMMs in this group
>
> enabled or available ?
>
I considered having a 'cmm' entry in DT as enabling it, but it is
actually just available.
> > * @num_crtcs: number of CRTCs in this group (1 or 2)
> > * @use_count: number of users of the group (rcar_du_group_(get|put))
> > * @used_crtcs: number of CRTCs currently in use
> > @@ -37,6 +38,7 @@ struct rcar_du_group {
> > unsigned int index;
> >
> > unsigned int channels_mask;
> > + unsigned int cmms_mask;
> > unsigned int num_crtcs;
> > unsigned int use_count;
> > unsigned int used_crtcs;
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > index f8f7fff34dff..b79cda2f5531 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > @@ -18,6 +18,7 @@
> > #include
> >
> > #include
> > +#include
> > #include
> >
> > #include "rcar_du_crtc.h"
> > @@ -534,6 +535,51 @@ static int rcar_du_vsps_init(struct rcar_du_device
> > *rcdu)
> > return ret;
> > }
> >
> > +static int
Re: [PATCH v2 17/50] drm: Add helper to create a connector for a chain of bridges
On Tue, 20 Aug 2019 04:16:48 +0300 Laurent Pinchart wrote: > + /** > + * @bridge_detect: ^ @bridge_modes > + * > + * The last bridge in the chain (closest to the connector) that provides > + * connector modes detection, if any (see _BRIDGE_OP_MODES). > + */ > + struct drm_bridge *bridge_modes; > +}; > + ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 16/50] drm/bridge: tfp410: Allow operation without drm_connector
On Tue, 20 Aug 2019 04:16:47 +0300
Laurent Pinchart wrote:
> The tfp410 driver can operate as part of a pipeline where the
> drm_connector is created by the display controller. Enable this mode of
> operation by skipping creation of a drm_connector internally.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/bridge/ti-tfp410.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> index 65651ae6c553..16cc8abe3262 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -133,7 +133,7 @@ static int tfp410_attach(struct drm_bridge *bridge,
> return ret;
>
> if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> - return -EINVAL;
> + return 0;
>
> if (!bridge->encoder) {
> dev_err(dvi->dev, "Missing encoder\n");
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #45 from tempel.jul...@gmail.com --- Created attachment 145140 --> https://bugs.freedesktop.org/attachment.cgi?id=145140=edit new dmesg log with debug patch applied after starting Hitman 2 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #44 from tempel.jul...@gmail.com --- I applied the patch to linux 5.2 (among 0001-drm-amd-display-Allow-fast-updates-again-for-swappin.patch) and as expected, gamma adjustments have stopped working. Unfortunately, the games still show the issue. Should the debug information be contained in dmesg? After doing echo 0x4 > /sys/module/drm/parameters/debug and starting Hitman 2, there don't seem to be any comprehensive debug information inside the dmesg log, at least not to my layman eyes (attaching right now nonetheless). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/50] drm/bridge: panel: Implement bridge connector operations
On Thu, 22 Aug 2019 19:35:24 +0300
Laurent Pinchart wrote:
> Hi Boris,
>
> On Thu, Aug 22, 2019 at 06:29:09PM +0200, Boris Brezillon wrote:
> > On Tue, 20 Aug 2019 04:16:44 +0300 Laurent Pinchart wrote:
> >
> > > Implement the newly added bridge connector operations, allowing the
> > > usage of drm_bridge_panel with drm_bridge_connector.
> > >
> > > Signed-off-by: Laurent Pinchart
> > > ---
> > > drivers/gpu/drm/bridge/panel.c | 18 +-
> > > 1 file changed, 17 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/panel.c
> > > b/drivers/gpu/drm/bridge/panel.c
> > > index f5b8e55301ac..1c7f5b648f05 100644
> > > --- a/drivers/gpu/drm/bridge/panel.c
> > > +++ b/drivers/gpu/drm/bridge/panel.c
> > > @@ -60,7 +60,7 @@ static int panel_bridge_attach(struct drm_bridge
> > > *bridge,
> > > int ret;
> > >
> > > if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> > > - return -EINVAL;
> > > + return 0;
> > >
> > > if (!bridge->encoder) {
> > > DRM_ERROR("Missing encoder\n");
> > > @@ -123,6 +123,18 @@ static void panel_bridge_post_disable(struct
> > > drm_bridge *bridge)
> > > drm_panel_unprepare(panel_bridge->panel);
> > > }
> > >
> > > +static int panel_bridge_get_modes(struct drm_bridge *bridge,
> > > + struct drm_connector *connector)
> > > +{
> > > + struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
> > > +
> > > + /*
> > > + * FIXME: drm_panel_get_modes() should take the connector as an
> > > + * argument.
> > > + */
> > > + return drm_panel_get_modes(panel_bridge->panel);
> > > +}
> > > +
> > > static const struct drm_bridge_funcs panel_bridge_bridge_funcs = {
> > > .attach = panel_bridge_attach,
> > > .detach = panel_bridge_detach,
> > > @@ -130,6 +142,7 @@ static const struct drm_bridge_funcs
> > > panel_bridge_bridge_funcs = {
> > > .enable = panel_bridge_enable,
> > > .disable = panel_bridge_disable,
> > > .post_disable = panel_bridge_post_disable,
> > > + .get_modes = panel_bridge_get_modes,
> > > };
> > >
> > > /**
> > > @@ -175,6 +188,9 @@ struct drm_bridge *drm_panel_bridge_add(struct
> > > drm_panel *panel,
> > > #ifdef CONFIG_OF
> > > panel_bridge->bridge.of_node = panel->dev->of_node;
> > > #endif
> > > + panel_bridge->bridge.ops = DRM_BRIDGE_OP_MODES;
> > > + /* FIXME: The panel should report its type. */
> > > + panel_bridge->bridge.type = DRM_MODE_CONNECTOR_DPI;
> >
> > Shouldn't we patch all panel drivers to expose this type before doing
> > this change? I mean, the connector type is exposed to userspace, and I
> > wouldn't be surprised if some userspace apps/libs decided to base their
> > output selection logic on this field.
>
> Note that this type will only make it to userspace for drivers that use
> the bridge->type field, likely through the drm bridge connector helper.
> I do agree that panel drivers should be updated, but given the number of
> panels in panel-simple and the fact that the information would need to
> be researched for most of them, this will be significant work. Can't
> this be done when converting display controller drivers on a need basis
> ?
I think setting a default value and fixing things on a need basis is
okay, but that doesn't prevent you from adding the necessary
infrastructure to let panel drivers pass this type (we can fallback to a
default type in panel drivers instead of here). I'm also not sure why
'DPI' is chosen as the default, shouldn't we use 'Unknown' instead?
>
> Or maybe we could, as an interim measure, derive the type from the bus
> formats reported by the panel if the panel type is not set ? If the
> panel reports MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> MEDIA_BUS_FMT_RGB666_1X7X4_SPWG or MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA then
> we can set the type to LVDS, otherwise we set it to DPI.
Hm, aren't we better off patching panel descs exposing these bus formats
to also explicitly set desc->type to LVDS, leaving others to Unknown
(Unknown is 0, so you don't have to patch all panel_desc definitions)?
> I can submit a
> patch to add a type field to the panel structure and implement this
> logic.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [LKP] [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression
Hi I was traveling and could reply earlier. Sorry for taking so long. Am 13.08.19 um 11:36 schrieb Feng Tang: > Hi Thomas, > > On Mon, Aug 12, 2019 at 03:25:45PM +0800, Feng Tang wrote: >> Hi Thomas, >> >> On Fri, Aug 09, 2019 at 04:12:29PM +0800, Rong Chen wrote: >>> Hi, >>> > Actually we run the benchmark as a background process, do we need to > disable the cursor and test again? There's a worker thread that updates the display from the shadow buffer. The blinking cursor periodically triggers the worker thread, but the actual update is just the size of one character. The point of the test without output is to see if the regression comes >>> >from the buffer update (i.e., the memcpy from shadow buffer to VRAM), or >>> >from the worker thread. If the regression goes away after disabling the blinking cursor, then the worker thread is the problem. If it already goes away if there's simply no output from the test, the screen update is the problem. On my machine I have to disable the blinking cursor, so I think the worker causes the performance drop. >>> >>> We disabled redirecting stdout/stderr to /dev/kmsg, and the regression is >>> gone. >>> >>> commit: >>> f1f8555dfb9 drm/bochs: Use shadow buffer for bochs framebuffer console >>> 90f479ae51a drm/mgag200: Replace struct mga_fbdev with generic framebuffer >>> emulation >>> >>> f1f8555dfb9a70a2 90f479ae51afa45efab97afdde testcase/testparams/testbox >>> -- --- >>> %stddev change %stddev >>> \ | \ >>> 43785 44481 >>> vm-scalability/300s-8T-anon-cow-seq-hugetlb/lkp-knm01 >>> 43785 44481 GEO-MEAN vm-scalability.median >> >> Till now, from Rong's tests: >> 1. Disabling cursor blinking doesn't cure the regression. >> 2. Disabling printint test results to console can workaround the >> regression. >> >> Also if we set the perfer_shadown to 0, the regression is also >> gone. > > We also did some further break down for the time consumed by the > new code. > > The drm_fb_helper_dirty_work() calls sequentially > 1. drm_client_buffer_vmap (290 us) > 2. drm_fb_helper_dirty_blit_real (19240 us) > 3. helper->fb->funcs->dirty()---> NULL for mgag200 driver > 4. drm_client_buffer_vunmap (215 us) > It's somewhat different to what I observed, but maybe I just couldn't reproduce the problem correctly. > The average run time is listed after the function names. > > From it, we can see drm_fb_helper_dirty_blit_real() takes too long > time (about 20ms for each run). I guess this is the root cause > of this regression, as the original code doesn't use this dirty worker. True, the original code uses a temporary buffer, but updates the display immediately. My guess is that this could be a caching problem. The worker runs on a different CPU, which doesn't have the shadow buffer in cache. > As said in last email, setting the prefer_shadow to 0 can avoid > the regrssion. Could it be an option? Unfortunately not. Without the shadow buffer, the console's display buffer permanently resides in video memory. It consumes significant amount of that memory (say 8 MiB out of 16 MiB). That doesn't leave enough room for anything else. The best option is to not print to the console. Best regards Thomas > Thanks, > Feng > >> >> --- a/drivers/gpu/drm/mgag200/mgag200_main.c >> +++ b/drivers/gpu/drm/mgag200/mgag200_main.c >> @@ -167,7 +167,7 @@ int mgag200_driver_load(struct drm_device *dev, unsigned >> long flags) >> dev->mode_config.preferred_depth = 16; >> else >> dev->mode_config.preferred_depth = 32; >> -dev->mode_config.prefer_shadow = 1; >> +dev->mode_config.prefer_shadow = 0; >> >> And from the perf data, one obvious difference is good case don't >> call drm_fb_helper_dirty_work(), while bad case calls. >> >> Thanks, >> Feng >> >>> Best Regards, >>> Rong Chen > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 15/50] drm/bridge: tfp410: Replace manual connector handling with bridge
On Thu, 22 Aug 2019 19:54:56 +0300
Laurent Pinchart wrote:
> Hi Boris,
>
> On Thu, Aug 22, 2019 at 06:36:45PM +0200, Boris Brezillon wrote:
> > On Tue, 20 Aug 2019 04:16:46 +0300 Laurent Pinchart wrote:
> >
> > > Now that a driver is available for display connectors, replace the
> > > manual connector handling code with usage of the DRM bridge API. The
> > > tfp410 driver doesn't deal with the display connector directly anymore,
> > > but still delegates drm_connector operations to the next bridge. This
> > > brings us one step closer to having the tfp410 driver handling the
> > > TFP410 only.
> > >
> > > Signed-off-by: Laurent Pinchart
> > > ---
> > > drivers/gpu/drm/bridge/ti-tfp410.c | 195 ++---
> > > 1 file changed, 68 insertions(+), 127 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
> > > b/drivers/gpu/drm/bridge/ti-tfp410.c
> > > index 4a468f44ef69..65651ae6c553 100644
> > > --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> > > +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> > > @@ -4,14 +4,12 @@
> > > * Author: Jyri Sarha
> > > */
> > >
> > > -#include
> > > -#include
> > > #include
> > > #include
> > > -#include
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #include
> > > #include
> > > @@ -24,16 +22,13 @@
> > > struct tfp410 {
> > > struct drm_bridge bridge;
> > > struct drm_connectorconnector;
> > > - unsigned intconnector_type;
> > >
> > > u32 bus_format;
> > > - struct i2c_adapter *ddc;
> > > - struct gpio_desc*hpd;
> > > - int hpd_irq;
> > > struct delayed_work hpd_work;
> > > struct gpio_desc*powerdown;
> > >
> > > struct drm_bridge_timings timings;
> > > + struct drm_bridge *next_bridge;
> > >
> > > struct device *dev;
> > > };
> > > @@ -56,10 +51,10 @@ static int tfp410_get_modes(struct drm_connector
> > > *connector)
> > > struct edid *edid;
> > > int ret;
> > >
> > > - if (!dvi->ddc)
> > > + if (!(dvi->next_bridge->ops & DRM_BRIDGE_OP_EDID))
> > > goto fallback;
> > >
> > > - edid = drm_get_edid(connector, dvi->ddc);
> > > + edid = dvi->next_bridge->funcs->get_edid(dvi->next_bridge, connector);
> >
> > Can we create a drm_bridge_get_edid() wrapper for that?
> > Something like:
> >
> > int drm_bridge_get_edid(struct drm_bridge *bridge,
> > struct drm_connector *conn)
> > {
> > if (!(dvi->next_bridge->ops & DRM_BRIDGE_OP_EDID))
> > return -ENOTSUPP;
>
> I assume you mean ERR_PTR(-ENOTSUPP) with the return type changed to
> struct drm_edid *.
>
> >
> > return bridge->funcs->get_edid(bridge, connector);
> > }
>
> I've thought about it, but I'm not sure it's worth it. These operations
> are not meant to be called manually by bridges like in here. This is an
> interim solution until support for drm_connector can be dropped from the
> tfp410 driver, once its users will be converted. Do you think I should
> still create a wrapper (which I would make static inline then) ?
Well, this conversion is likely to take time, not to mention that other
drivers will go through the same process. And every time a bridge
driver is converted, it requires patching all display controller drivers
that are known to be connected to it before you can get rid of this
temporary solution. So yes, I still think it's worth adding those
helpers, maybe with a comment explaining that they should only be used
during the conversion phase (IOW, until the driver starts rejecting
the !DRM_BRIDGE_ATTACH_NO_CONNECTOR case).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #43 from Nicholas Kazlauskas --- Created attachment 145139 --> https://bugs.freedesktop.org/attachment.cgi?id=145139=edit 0001-drm-amd-display-Test-patch-for-disabling-color-adjus.patch >From your video it looks like something is issuing a lot of full updates. Those are slow enough that they can miss the current vblank window and be forced to wait until the next one with vsync on. I've attached a debug patch you can try that should disable color adjustments from triggering full updates. I've also added some debug information to know when full updates are being issued in case it was something other than color management. You can view that output with log level 4, ie. echo 0x4 > /sys/module/drm/parameters/debug -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [EXT] [PATCH v3 2/2] drm/bridge: Add NWL MIPI DSI host controller support
Hi Robert,
thanks for your comments! Most of this make sense, i have some comments
inline below (mostly since I only have access to the imx8mq reference
manual but not to the any NWL IP docs):
On Thu, Aug 22, 2019 at 01:18:21PM +, Robert Chiras wrote:
> Hi Guido,
>
> I added my signed-off, plus some comments inline.
>
> On Jo, 2019-08-22 at 12:44 +0200, Guido Günther wrote:
> > This adds initial support for the NWL MIPI DSI Host controller found
> > on
> > i.MX8 SoCs.
> >
> > It adds support for the i.MX8MQ but the same IP can be found on
> > e.g. the i.MX8QXP.
> >
> > It has been tested on the Librem 5 devkit using mxsfb.
> >
> > Signed-off-by: Guido Günther
> Signed-off-by: Robert Chiras
Thanks!
> > Co-developed-by: Robert Chiras
> > ---
> > drivers/gpu/drm/bridge/Kconfig | 2 +
> > drivers/gpu/drm/bridge/Makefile | 1 +
> > drivers/gpu/drm/bridge/nwl-dsi/Kconfig | 16 +
> > drivers/gpu/drm/bridge/nwl-dsi/Makefile | 4 +
> > drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c | 501
> > drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h | 65 +++
> > drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c | 700
> > +++
> > drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h | 112
> > 8 files changed, 1401 insertions(+)
> > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Makefile
> > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h
> > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c
> > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > b/drivers/gpu/drm/bridge/Kconfig
> > index 1cc9f502c1f2..7980b5c2156f 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -154,6 +154,8 @@ source "drivers/gpu/drm/bridge/analogix/Kconfig"
> >
> > source "drivers/gpu/drm/bridge/adv7511/Kconfig"
> >
> > +source "drivers/gpu/drm/bridge/nwl-dsi/Kconfig"
> > +
> > source "drivers/gpu/drm/bridge/synopsys/Kconfig"
> >
> > endmenu
> > diff --git a/drivers/gpu/drm/bridge/Makefile
> > b/drivers/gpu/drm/bridge/Makefile
> > index 4934fcf5a6f8..d9f6c0f77592 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -16,4 +16,5 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> > obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
> > obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> > +obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi/
> > obj-y += synopsys/
> > diff --git a/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> > b/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> > new file mode 100644
> > index ..3b157a9f2229
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> > @@ -0,0 +1,16 @@
> > +config DRM_NWL_MIPI_DSI
> > + tristate "Support for Northwest Logic MIPI DSI Host
> > controller"
> > + depends on DRM
> > + depends on COMMON_CLK
> > + depends on OF && HAS_IOMEM
> > + select DRM_KMS_HELPER
> > + select DRM_MIPI_DSI
> > + select DRM_PANEL_BRIDGE
> > + select GENERIC_PHY_MIPI_DPHY
> > + select MFD_SYSCON
> > + select MULTIPLEXER
> > + select REGMAP_MMIO
> > + help
> > + This enables the Northwest Logic MIPI DSI Host controller
> > as
> > + for example found on NXP's i.MX8 Processors.
> > +
> > diff --git a/drivers/gpu/drm/bridge/nwl-dsi/Makefile
> > b/drivers/gpu/drm/bridge/nwl-dsi/Makefile
> > new file mode 100644
> > index ..804baf2f1916
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/nwl-dsi/Makefile
> > @@ -0,0 +1,4 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +nwl-mipi-dsi-y := nwl-drv.o nwl-dsi.o
> > +obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-mipi-dsi.o
> > +header-test-y += nwl-drv.h nwl-dsi.h
> > diff --git a/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> > b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> > new file mode 100644
> > index ..e457438738c0
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> > @@ -0,0 +1,501 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * i.MX8 NWL MIPI DSI host driver
> > + *
> > + * Copyright (C) 2017 NXP
> > + * Copyright (C) 2019 Purism SPC
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "nwl-drv.h"
> > +#include "nwl-dsi.h"
> > +
> > +#define DRV_NAME "nwl-dsi"
> > +
> > +/* Possible platform specific clocks */
> > +#define NWL_DSI_CLK_CORE "core"
> > +
> > +static const struct regmap_config nwl_dsi_regmap_config = {
> > + .reg_bits = 16,
> > + .val_bits = 32,
> > + .reg_stride = 4,
> > + .max_register =
[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #42 from tempel.jul...@gmail.com --- (In reply to Nicholas Kazlauskas from comment #39) > Disabling the compositor doesn't make a difference as far as stuttering goes > for Hitman 2's DXVK - I don't see any commits in the log that are lock the > connector and all the planes. Thanks for trying! > I don't have Oblivion on my machine to test, but I tried running the DX9 > version of Heaven under proton and I don't see stuttering or any gamma/color > adjustment commits under that either. No issues with FreeSync when running > it either from what I can tell with vsync both on/off. I've given Heaven a try, it doesn't show the issue for me either (DX9 via D9VK). > Those commits are definitely what's causing your stuttering, but I'm not > sure what's actually creating them. My initial guess was something in the > compatibility layer for DX9 games, but I don't see that on my setup. I've attached a debug dmesg log after triggering the issue in Hitman 2. It is also what is shown in the new video capture I've provided. As you can see, there are no rendering spikes, but instead the mouse input (and perhaps partially also keyboard) seems to be discarded a lot, causing such jumps. This is also there without vsync enabled, but less obvious. Just like the render spikes in Oblivion/Skyrim, this issue completely disappears by turning off pageflipping in xorg config, switching to modesetting DDX or disabling atomic modesetting via amdgpu.dc=0. I wonder if the log confirms that it's the same issue (or the issue has the same roots)? > Is it only Oblivion that has this issue for you? I found out that also the native OpenGL renderer of Doom 2016 (which also has a free demo on Steam) shows the same behavior as Oblivion/Skyrim, despite of no 3D API wrapper involved. For whatever reason, the Vulkan renderer of the game doesn't show the issue, it seems to run flawlessly with both pageflipping + vsync. > I'm not sure how much of this can be a kernel level fix - I think we need to > lock all the planes whenever gamma or color adjustments have been made and > that probably includes the cursor plane as well. If the cursor plane is > included that will block asynchronous cursor updates from occurring until > the color adjustments have been done. This is why the cursor causes > stuttering. Would it be possible to provide a test patch that completely blocks any gamma adjustment either in Xorg or the kernel? Then we'd have ultimate proof. :) > A check could potentially be made to not lock all the planes for redundant > color management commits, but I'm not sure if the color adjustments > requested are redundant or not. It could be the case that the application is > requesting different color adjustments every single time. It seems some suboptimal behavior of Wine can trigger this issue, but I suppose it would automatically be fixed together with this issue which I reported regarding gamma adjustment performance and atomic modesetting: https://bugs.freedesktop.org/show_bug.cgi?id=108917 I btw. can reproduce that issue by simply booting Fedora 30 Workstation Gnome Live and enable the nightlight feature, the color grading phase makes everything stutter. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 34/50] drm/omap: Create connector for bridges
On Tue, 20 Aug 2019 04:17:05 +0300
Laurent Pinchart wrote:
> Use the drm_bridge_connector helper to create a connector for pipelines
> that use drm_bridge. This allows splitting connector operations across
> multiple bridges when necessary, instead of having the last bridge in
> the chain creating the connector and handling all connector operations
> internally.
>
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v1:
>
> - Squash with patch "drm/omap: Detach from panels at remove time"
> ---
> drivers/gpu/drm/omapdrm/omap_drv.c | 82 +-
> 1 file changed, 70 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index de373fd50729..f38d95cb31ba 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -11,10 +11,12 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -290,9 +292,14 @@ static int omap_modeset_init(struct drm_device *dev)
>
> if (pipe->output->bridge) {
> ret = drm_bridge_attach(pipe->encoder,
> - pipe->output->bridge, NULL, 0);
> - if (ret < 0)
> + pipe->output->bridge, NULL,
> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
I guess the only external bridge connected to an omap display
controller in upstream DTs is the TFP410. I was wondering if falling
back to !DRM_BRIDGE_ATTACH_NO_CONNECTOR would be acceptable in case one
wants to convert a display controller driver which is known to be
used in conjunction with various external bridges.
> + if (ret < 0) {
> + dev_err(priv->dev,
> + "unable to attach bridge %pOF\n",
> + pipe->output->bridge->of_node);
> return ret;
> + }
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 15/50] drm/bridge: tfp410: Replace manual connector handling with bridge
Hi Boris,
On Thu, Aug 22, 2019 at 06:36:45PM +0200, Boris Brezillon wrote:
> On Tue, 20 Aug 2019 04:16:46 +0300 Laurent Pinchart wrote:
>
> > Now that a driver is available for display connectors, replace the
> > manual connector handling code with usage of the DRM bridge API. The
> > tfp410 driver doesn't deal with the display connector directly anymore,
> > but still delegates drm_connector operations to the next bridge. This
> > brings us one step closer to having the tfp410 driver handling the
> > TFP410 only.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/bridge/ti-tfp410.c | 195 ++---
> > 1 file changed, 68 insertions(+), 127 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
> > b/drivers/gpu/drm/bridge/ti-tfp410.c
> > index 4a468f44ef69..65651ae6c553 100644
> > --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> > +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> > @@ -4,14 +4,12 @@
> > * Author: Jyri Sarha
> > */
> >
> > -#include
> > -#include
> > #include
> > #include
> > -#include
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -24,16 +22,13 @@
> > struct tfp410 {
> > struct drm_bridge bridge;
> > struct drm_connectorconnector;
> > - unsigned intconnector_type;
> >
> > u32 bus_format;
> > - struct i2c_adapter *ddc;
> > - struct gpio_desc*hpd;
> > - int hpd_irq;
> > struct delayed_work hpd_work;
> > struct gpio_desc*powerdown;
> >
> > struct drm_bridge_timings timings;
> > + struct drm_bridge *next_bridge;
> >
> > struct device *dev;
> > };
> > @@ -56,10 +51,10 @@ static int tfp410_get_modes(struct drm_connector
> > *connector)
> > struct edid *edid;
> > int ret;
> >
> > - if (!dvi->ddc)
> > + if (!(dvi->next_bridge->ops & DRM_BRIDGE_OP_EDID))
> > goto fallback;
> >
> > - edid = drm_get_edid(connector, dvi->ddc);
> > + edid = dvi->next_bridge->funcs->get_edid(dvi->next_bridge, connector);
>
> Can we create a drm_bridge_get_edid() wrapper for that?
> Something like:
>
> int drm_bridge_get_edid(struct drm_bridge *bridge,
> struct drm_connector *conn)
> {
> if (!(dvi->next_bridge->ops & DRM_BRIDGE_OP_EDID))
> return -ENOTSUPP;
I assume you mean ERR_PTR(-ENOTSUPP) with the return type changed to
struct drm_edid *.
>
> return bridge->funcs->get_edid(bridge, connector);
> }
I've thought about it, but I'm not sure it's worth it. These operations
are not meant to be called manually by bridges like in here. This is an
interim solution until support for drm_connector can be dropped from the
tfp410 driver, once its users will be converted. Do you think I should
still create a wrapper (which I would make static inline then) ?
> > if (!edid) {
> > dev_info(dvi->dev,
> > "EDID read failed. Fallback to standard modes\n");
> > @@ -93,21 +88,10 @@ tfp410_connector_detect(struct drm_connector
> > *connector, bool force)
> > {
> > struct tfp410 *dvi = drm_connector_to_tfp410(connector);
> >
> > - if (dvi->hpd) {
> > - if (gpiod_get_value_cansleep(dvi->hpd))
> > - return connector_status_connected;
> > - else
> > - return connector_status_disconnected;
> > - }
> > + if (!(dvi->next_bridge->ops & DRM_BRIDGE_OP_DETECT))
> > + return connector_status_unknown;
> >
> > - if (dvi->ddc) {
> > - if (drm_probe_ddc(dvi->ddc))
> > - return connector_status_connected;
> > - else
> > - return connector_status_disconnected;
> > - }
> > -
> > - return connector_status_unknown;
> > + return dvi->next_bridge->funcs->detect(dvi->next_bridge);
>
> Same here for the detect hook.
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 14/19] drm: rcar-du: Add support for CMM
Hi Ulrich,
On Tue, Aug 20, 2019 at 08:37:44PM +0300, Laurent Pinchart wrote:
> Hello,
>
> On Tue, Jul 16, 2019 at 03:17:04PM +0200, Ulrich Hecht wrote:
> > > On July 6, 2019 at 4:07 PM Jacopo Mondi wrote:
> > >
> > > Add a driver for the R-Car Display Unit Color Correction Module.
> > >
> > > In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
> > > to perform image enhancement and color correction.
> > >
> > > Add support for CMM through a driver that supports configuration of
> > > the 1-dimensional LUT table. More advanced CMM feature will be
> > > implemented on top of this basic one.
> > >
> > > Signed-off-by: Jacopo Mondi
> > > ---
> > > drivers/gpu/drm/rcar-du/Kconfig| 7 +
> > > drivers/gpu/drm/rcar-du/Makefile | 1 +
> > > drivers/gpu/drm/rcar-du/rcar_cmm.c | 292 +
> > > drivers/gpu/drm/rcar-du/rcar_cmm.h | 38
> > > 4 files changed, 338 insertions(+)
> > > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c
> > > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h
> > >
> > > diff --git a/drivers/gpu/drm/rcar-du/Kconfig
> > > b/drivers/gpu/drm/rcar-du/Kconfig
> > > index 1529849e217e..539d232790d1 100644
> > > --- a/drivers/gpu/drm/rcar-du/Kconfig
> > > +++ b/drivers/gpu/drm/rcar-du/Kconfig
> > > @@ -13,6 +13,13 @@ config DRM_RCAR_DU
> > > Choose this option if you have an R-Car chipset.
> > > If M is selected the module will be called rcar-du-drm.
> > >
> > > +config DRM_RCAR_CMM
> > > + bool "R-Car DU Color Management Module (CMM) Support"
> > > + depends on DRM && OF
> > > + depends on DRM_RCAR_DU
> > > + help
> > > + Enable support for R-Car Color Management Module (CMM).
> > > +
> > > config DRM_RCAR_DW_HDMI
> > > tristate "R-Car DU Gen3 HDMI Encoder Support"
> > > depends on DRM && OF
> > > diff --git a/drivers/gpu/drm/rcar-du/Makefile
> > > b/drivers/gpu/drm/rcar-du/Makefile
> > > index 6c2ed9c46467..4d1187ccc3e5 100644
> > > --- a/drivers/gpu/drm/rcar-du/Makefile
> > > +++ b/drivers/gpu/drm/rcar-du/Makefile
> > > @@ -15,6 +15,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o
> > > \
> > > rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
> > > rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
> > >
> > > +obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
> > > obj-$(CONFIG_DRM_RCAR_DU)+= rcar-du-drm.o
> > > obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
> > > obj-$(CONFIG_DRM_RCAR_LVDS) += rcar_lvds.o
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > > b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > > new file mode 100644
> > > index ..76ed3fce2b33
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > > @@ -0,0 +1,292 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * rcar_cmm.c -- R-Car Display Unit Color Management Module
> > > + *
> > > + * Copyright (C) 2019 Jacopo Mondi
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include
> > > +
> > > +#include "rcar_cmm.h"
> > > +
> > > +#define CM2_LUT_CTRL 0x
> > > +#define CM2_LUT_CTRL_EN BIT(0)
> > > +#define CM2_LUT_TBLA_BASE0x0600
> > > +#define CM2_LUT_TBLA(__i)(CM2_LUT_TBLA_BASE + (__i) * 4)
> > > +
> > > +struct rcar_cmm {
> > > + struct clk *clk;
> > > + void __iomem *base;
> > > + bool enabled;
> > > +
> > > + /*
> > > + * restore: LUT restore flag
> > > + * running: LUT operating flag
> > > + * size: Number of programmed entries in the LUT table
> > > + * table: Scratch buffer where to store the LUT table entries to be
> > > + *later restored.
> > > + */
> > > + struct {
> > > + bool restore;
> > > + bool running;
> > > + unsigned int size;
> > > + struct drm_color_lut table[CMM_GAMMA_LUT_SIZE];
> > > + } lut;
> > > +};
> > > +
> > > +static inline int rcar_cmm_read(struct rcar_cmm *rcmm, u32 reg)
> > > +{
> > > + return ioread32(rcmm->base + reg);
> > > +}
> > > +
> > > +static inline void rcar_cmm_write(struct rcar_cmm *rcmm, u32 reg, u32
> > > data)
> > > +{
> > > + iowrite32(data, rcmm->base + reg);
> > > +}
> > > +
> > > +static void rcar_cmm_lut_write(struct rcar_cmm *rcmm, unsigned int size,
> > > +struct drm_color_lut *lut)
> > > +{
> > > + unsigned int i;
> > > +
> > > + for (i = 0; i < size; ++i) {
> > > + struct drm_color_lut *entry = [i];
> > > +
> > > + u32 val = (entry->red & 0xff) << 16 |
> > > + (entry->green & 0xff) << 8 |
> > > + (entry->blue & 0xff);
> >
> > I don't think it's correct to cut off the high bits here. There is a
> > function "drm_color_lut_extract()" for converting drm_color_lut values
> > to hardware precision.
> >
Oh, I see! the value received from userspace in 16-bits precision
needs to be rescaled to the hw supported one!
Re: [PATCH v2 04/50] drm/bridge: Add connector-related bridge operations and data
On Tue, 20 Aug 2019 04:16:35 +0300
Laurent Pinchart wrote:
>
> +/**
> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> + */
> +enum drm_bridge_ops {
> + /**
> + * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> + * its output. Bridges that set this flag shall implement the
> + * _bridge_funcs->detect callback.
> + */
> + DRM_BRIDGE_OP_DETECT = BIT(0),
> + /**
> + * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> + * connected to its output. Bridges that set this flag shall implement
> + * the _bridge_funcs->get_edid callback.
> + */
> + DRM_BRIDGE_OP_EDID = BIT(1),
> + /**
> + * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> + * without requiring polling. Bridges that set this flag shall
> + * implement the _bridge_funcs->hpd_enable and
> + * _bridge_funcs->hpd_disable callbacks if they support enabling
> + * and disabling hot-plug detection dynamically.
> + */
> + DRM_BRIDGE_OP_HPD = BIT(2),
> + /**
> + * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> + * by the display at its output. This does not include readind EDID
> + * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> + * this flag shall implement the _bridge_funcs->get_modes callback.
> + */
> + DRM_BRIDGE_OP_MODES = BIT(3),
> +};
> +
> /**
> * struct drm_bridge - central DRM bridge control structure
> */
> @@ -398,6 +538,33 @@ struct drm_bridge {
> const struct drm_bridge_funcs *funcs;
> /** @driver_private: pointer to the bridge driver's internal context */
> void *driver_private;
> + /** @ops: bitmask of operations supported by the bridge */
> + enum drm_bridge_ops ops;
Just realized that you're not checking ->ops and ->funcs consistency at
attach() time (you're only checking ->ops in the tfp410 driver before
calling ->funcs->detect() and ->funcs->get_modes() and they might be
NULL).
> + /**
> + * @type: Type of the connection at the bridge output
> + * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> + * identifies the type of connected display.
> + */
> + int type;
> + /**
> + * @ddc: Associated I2C adapter for DDC access, if any.
> + */
> + struct i2c_adapter *ddc;
> + /** private: */
> + /**
> + * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> + */
> + struct mutex hpd_mutex;
> + /**
> + * @hpd_cb: Hot plug detection callback, registered with
> + * drm_bridge_hpd_enable().
> + */
> + void (*hpd_cb)(void *data, enum drm_connector_status status);
> + /**
> + * @hpd_data: Private data passed to the Hot plug detection callback
> + * @hpd_cb.
> + */
> + void *hpd_data;
> };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #41 from tempel.jul...@gmail.com --- Created attachment 145138 --> https://bugs.freedesktop.org/attachment.cgi?id=145138=edit debug dmesg.log after running Hitman 2 with the issue -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/50] drm/bridge: Add bridge driver for display connectors
Hi Boris,
On Thu, Aug 22, 2019 at 06:05:20PM +0200, Boris Brezillon wrote:
> On Tue, 20 Aug 2019 04:16:42 +0300 Laurent Pinchart wrote:
>
> > + /*
> > +* Get the HPD GPIO for DVI and HDMI connectors. If the GPIO can provide
> > +* interrupts, register an interrupt handler.
> > +*/
> > + if (type == DRM_MODE_CONNECTOR_DVII ||
> > + type == DRM_MODE_CONNECTOR_HDMIA) {
> > + conn->hpd_gpio = devm_gpiod_get_optional(>dev, "hpd",
> > +GPIOD_IN);
> > + if (IS_ERR(conn->hpd_gpio)) {
> > + if (PTR_ERR(conn->hpd_gpio) != -EPROBE_DEFER)
> > + dev_err(>dev,
> > + "Unable to retrieve HPD GPIO\n");
> > + return PTR_ERR(conn->hpd_gpio);
> > + }
> > +
> > + conn->hpd_irq = gpiod_to_irq(conn->hpd_gpio);
> > + } else {
> > + conn->hpd_irq = -EINVAL;
> > + }
> > +
> > + if (conn->hpd_irq >= 0) {
> > + ret = devm_request_threaded_irq(>dev, conn->hpd_irq,
> > + NULL, display_connector_hpd_irq,
> > + IRQF_TRIGGER_RISING |
> > + IRQF_TRIGGER_FALLING |
> > + IRQF_ONESHOT,
> > + "HPD", conn);
> > + if (ret) {
> > + dev_err(>dev,
> > + "Failed to request HPD interrupt\n");
> > + return ret;
>
> Is there anything that mandates support of edge events on GPIO chips?
> I know it's quite common, but maybe we should fallback to polling
> mode when devm_request_threaded_irq() fails.
That's a good point, I'll change this.
> > + }
> > + }
> > +
> > + /* Retrieve the DDC I2C adapter for DVI, HDMI and VGA connectors. */
> > + if (type == DRM_MODE_CONNECTOR_DVII ||
> > + type == DRM_MODE_CONNECTOR_HDMIA ||
> > + type == DRM_MODE_CONNECTOR_VGA) {
> > + struct device_node *phandle;
> > +
> > + phandle = of_parse_phandle(pdev->dev.of_node, "ddc-i2c-bus", 0);
> > + if (phandle) {
> > + conn->bridge.ddc = of_get_i2c_adapter_by_node(phandle);
> > + of_node_put(phandle);
> > + if (!conn->bridge.ddc)
> > + return -EPROBE_DEFER;
> > + } else {
> > + dev_dbg(>dev,
> > + "No I2C bus specified, disabling EDID
> > readout\n");
> > + }
> > + }
> > +
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 15/50] drm/bridge: tfp410: Replace manual connector handling with bridge
On Tue, 20 Aug 2019 04:16:46 +0300
Laurent Pinchart wrote:
> Now that a driver is available for display connectors, replace the
> manual connector handling code with usage of the DRM bridge API. The
> tfp410 driver doesn't deal with the display connector directly anymore,
> but still delegates drm_connector operations to the next bridge. This
> brings us one step closer to having the tfp410 driver handling the
> TFP410 only.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/ti-tfp410.c | 195 ++---
> 1 file changed, 68 insertions(+), 127 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> index 4a468f44ef69..65651ae6c553 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -4,14 +4,12 @@
> * Author: Jyri Sarha
> */
>
> -#include
> -#include
> #include
> #include
> -#include
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -24,16 +22,13 @@
> struct tfp410 {
> struct drm_bridge bridge;
> struct drm_connectorconnector;
> - unsigned intconnector_type;
>
> u32 bus_format;
> - struct i2c_adapter *ddc;
> - struct gpio_desc*hpd;
> - int hpd_irq;
> struct delayed_work hpd_work;
> struct gpio_desc*powerdown;
>
> struct drm_bridge_timings timings;
> + struct drm_bridge *next_bridge;
>
> struct device *dev;
> };
> @@ -56,10 +51,10 @@ static int tfp410_get_modes(struct drm_connector
> *connector)
> struct edid *edid;
> int ret;
>
> - if (!dvi->ddc)
> + if (!(dvi->next_bridge->ops & DRM_BRIDGE_OP_EDID))
> goto fallback;
>
> - edid = drm_get_edid(connector, dvi->ddc);
> + edid = dvi->next_bridge->funcs->get_edid(dvi->next_bridge, connector);
Can we create a drm_bridge_get_edid() wrapper for that?
Something like:
int drm_bridge_get_edid(struct drm_bridge *bridge,
struct drm_connector *conn)
{
if (!(dvi->next_bridge->ops & DRM_BRIDGE_OP_EDID))
return -ENOTSUPP;
return bridge->funcs->get_edid(bridge, connector);
}
> if (!edid) {
> dev_info(dvi->dev,
>"EDID read failed. Fallback to standard modes\n");
> @@ -93,21 +88,10 @@ tfp410_connector_detect(struct drm_connector *connector,
> bool force)
> {
> struct tfp410 *dvi = drm_connector_to_tfp410(connector);
>
> - if (dvi->hpd) {
> - if (gpiod_get_value_cansleep(dvi->hpd))
> - return connector_status_connected;
> - else
> - return connector_status_disconnected;
> - }
> + if (!(dvi->next_bridge->ops & DRM_BRIDGE_OP_DETECT))
> + return connector_status_unknown;
>
> - if (dvi->ddc) {
> - if (drm_probe_ddc(dvi->ddc))
> - return connector_status_connected;
> - else
> - return connector_status_disconnected;
> - }
> -
> - return connector_status_unknown;
> + return dvi->next_bridge->funcs->detect(dvi->next_bridge);
Same here for the detect hook.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/50] drm/bridge: panel: Implement bridge connector operations
Hi Boris,
On Thu, Aug 22, 2019 at 06:29:09PM +0200, Boris Brezillon wrote:
> On Tue, 20 Aug 2019 04:16:44 +0300 Laurent Pinchart wrote:
>
> > Implement the newly added bridge connector operations, allowing the
> > usage of drm_bridge_panel with drm_bridge_connector.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/bridge/panel.c | 18 +-
> > 1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> > index f5b8e55301ac..1c7f5b648f05 100644
> > --- a/drivers/gpu/drm/bridge/panel.c
> > +++ b/drivers/gpu/drm/bridge/panel.c
> > @@ -60,7 +60,7 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
> > int ret;
> >
> > if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> > - return -EINVAL;
> > + return 0;
> >
> > if (!bridge->encoder) {
> > DRM_ERROR("Missing encoder\n");
> > @@ -123,6 +123,18 @@ static void panel_bridge_post_disable(struct
> > drm_bridge *bridge)
> > drm_panel_unprepare(panel_bridge->panel);
> > }
> >
> > +static int panel_bridge_get_modes(struct drm_bridge *bridge,
> > + struct drm_connector *connector)
> > +{
> > + struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
> > +
> > + /*
> > +* FIXME: drm_panel_get_modes() should take the connector as an
> > +* argument.
> > +*/
> > + return drm_panel_get_modes(panel_bridge->panel);
> > +}
> > +
> > static const struct drm_bridge_funcs panel_bridge_bridge_funcs = {
> > .attach = panel_bridge_attach,
> > .detach = panel_bridge_detach,
> > @@ -130,6 +142,7 @@ static const struct drm_bridge_funcs
> > panel_bridge_bridge_funcs = {
> > .enable = panel_bridge_enable,
> > .disable = panel_bridge_disable,
> > .post_disable = panel_bridge_post_disable,
> > + .get_modes = panel_bridge_get_modes,
> > };
> >
> > /**
> > @@ -175,6 +188,9 @@ struct drm_bridge *drm_panel_bridge_add(struct
> > drm_panel *panel,
> > #ifdef CONFIG_OF
> > panel_bridge->bridge.of_node = panel->dev->of_node;
> > #endif
> > + panel_bridge->bridge.ops = DRM_BRIDGE_OP_MODES;
> > + /* FIXME: The panel should report its type. */
> > + panel_bridge->bridge.type = DRM_MODE_CONNECTOR_DPI;
>
> Shouldn't we patch all panel drivers to expose this type before doing
> this change? I mean, the connector type is exposed to userspace, and I
> wouldn't be surprised if some userspace apps/libs decided to base their
> output selection logic on this field.
Note that this type will only make it to userspace for drivers that use
the bridge->type field, likely through the drm bridge connector helper.
I do agree that panel drivers should be updated, but given the number of
panels in panel-simple and the fact that the information would need to
be researched for most of them, this will be significant work. Can't
this be done when converting display controller drivers on a need basis
?
Or maybe we could, as an interim measure, derive the type from the bus
formats reported by the panel if the panel type is not set ? If the
panel reports MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
MEDIA_BUS_FMT_RGB666_1X7X4_SPWG or MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA then
we can set the type to LVDS, otherwise we set it to DPI. I can submit a
patch to add a type field to the panel structure and implement this
logic.
> > drm_bridge_add(_bridge->bridge);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/50] drm/bridge: panel: Implement bridge connector operations
On Tue, 20 Aug 2019 04:16:44 +0300
Laurent Pinchart wrote:
> Implement the newly added bridge connector operations, allowing the
> usage of drm_bridge_panel with drm_bridge_connector.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/panel.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> index f5b8e55301ac..1c7f5b648f05 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -60,7 +60,7 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
> int ret;
>
> if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> - return -EINVAL;
> + return 0;
>
> if (!bridge->encoder) {
> DRM_ERROR("Missing encoder\n");
> @@ -123,6 +123,18 @@ static void panel_bridge_post_disable(struct drm_bridge
> *bridge)
> drm_panel_unprepare(panel_bridge->panel);
> }
>
> +static int panel_bridge_get_modes(struct drm_bridge *bridge,
> + struct drm_connector *connector)
> +{
> + struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
> +
> + /*
> + * FIXME: drm_panel_get_modes() should take the connector as an
> + * argument.
> + */
> + return drm_panel_get_modes(panel_bridge->panel);
> +}
> +
> static const struct drm_bridge_funcs panel_bridge_bridge_funcs = {
> .attach = panel_bridge_attach,
> .detach = panel_bridge_detach,
> @@ -130,6 +142,7 @@ static const struct drm_bridge_funcs
> panel_bridge_bridge_funcs = {
> .enable = panel_bridge_enable,
> .disable = panel_bridge_disable,
> .post_disable = panel_bridge_post_disable,
> + .get_modes = panel_bridge_get_modes,
> };
>
> /**
> @@ -175,6 +188,9 @@ struct drm_bridge *drm_panel_bridge_add(struct drm_panel
> *panel,
> #ifdef CONFIG_OF
> panel_bridge->bridge.of_node = panel->dev->of_node;
> #endif
> + panel_bridge->bridge.ops = DRM_BRIDGE_OP_MODES;
> + /* FIXME: The panel should report its type. */
> + panel_bridge->bridge.type = DRM_MODE_CONNECTOR_DPI;
Shouldn't we patch all panel drivers to expose this type before doing
this change? I mean, the connector type is exposed to userspace, and I
wouldn't be surprised if some userspace apps/libs decided to base their
output selection logic on this field.
>
> drm_bridge_add(_bridge->bridge);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #40 from tempel.jul...@gmail.com --- Created attachment 145137 --> https://bugs.freedesktop.org/attachment.cgi?id=145137=edit video demonstrating the issue in Hitman 2 (different to Oblivion/Skyrim) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110865] Rx480 consumes 20w more power in idle than under Windows
https://bugs.freedesktop.org/show_bug.cgi?id=110865 --- Comment #17 from Alex Deucher --- Note that it will only work if your monitors have identical timing. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110865] Rx480 consumes 20w more power in idle than under Windows
https://bugs.freedesktop.org/show_bug.cgi?id=110865 Alex Deucher changed: What|Removed |Added Attachment #144983|0 |1 is obsolete|| --- Comment #16 from Alex Deucher --- Created attachment 145136 --> https://bugs.freedesktop.org/attachment.cgi?id=145136=edit fix DC code Can you try this patch along with attachment 144978? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 14/50] drm/bridge: tfp410: Don't include drmP.h
On Tue, 20 Aug 2019 04:16:45 +0300
Laurent Pinchart wrote:
> The drmP.h header is deprecated, replace it with the headers
> specifically needed by the tfp410 driver. While at it, replace the DRM
> print macros with dev_info() and dev_err() instead of including
> drm_print.h
Looks like drm_print.h is still included.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/ti-tfp410.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> index a9359038f7dc..4a468f44ef69 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -14,6 +14,7 @@
> #include
>
> #include
> +#include
> #include
> #include
> #include
> @@ -60,7 +61,8 @@ static int tfp410_get_modes(struct drm_connector *connector)
>
> edid = drm_get_edid(connector, dvi->ddc);
> if (!edid) {
> - DRM_INFO("EDID read failed. Fallback to standard modes\n");
> + dev_info(dvi->dev,
> + "EDID read failed. Fallback to standard modes\n");
> goto fallback;
> }
>
> @@ -364,7 +366,7 @@ static int tfp410_init(struct device *dev, bool i2c)
> IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
> "hdmi-hpd", dvi);
> if (ret) {
> - DRM_ERROR("failed to register hpd interrupt\n");
> + dev_err(dev, "failed to register hpd interrupt\n");
> goto fail;
> }
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/7] dt-bindings: display: msm: gmu: add optional ocmem property
On Thu, Aug 22, 2019 at 9:37 AM Brian Masney wrote:
>
> Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> optional ocmem property to the Adreno Graphics Management Unit bindings.
>
> Signed-off-by: Brian Masney
> ---
> Changes since v5:
> - rename ocmem property to sram to match what TI currently has.
>
> Changes since v4:
> - None
>
> Changes since v3:
> - correct link to qcom,ocmem.yaml
>
> Changes since v2:
> - Add a3xx example with OCMEM
>
> Changes since v1:
> - None
>
> .../devicetree/bindings/display/msm/gmu.txt | 50 +++
> 1 file changed, 50 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt
> b/Documentation/devicetree/bindings/display/msm/gmu.txt
> index 90af5b0a56a9..2305a2aede5a 100644
> --- a/Documentation/devicetree/bindings/display/msm/gmu.txt
> +++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
> @@ -31,6 +31,10 @@ Required properties:
> - iommus: phandle to the adreno iommu
> - operating-points-v2: phandle to the OPP operating points
>
> +Optional properties:
> +- sram: phandle to the On Chip Memory (OCMEM) that's present on some
> Snapdragon
> +SoCs. See Documentation/devicetree/bindings/sram/qcom,ocmem.yaml.
> +
> Example:
>
> / {
> @@ -63,3 +67,49 @@ Example:
> operating-points-v2 = <_opp_table>;
> };
> };
> +
> +a3xx example with OCMEM support:
> +
> +/ {
> + ...
> +
> + gpu: adreno@fdb0 {
> + compatible = "qcom,adreno-330.2",
> +"qcom,adreno";
> + reg = <0xfdb0 0x1>;
> + reg-names = "kgsl_3d0_reg_memory";
> + interrupts = ;
> + interrupt-names = "kgsl_3d0_irq";
> + clock-names = "core",
> + "iface",
> + "mem_iface";
> + clocks = < OXILI_GFX3D_CLK>,
> +< OXILICX_AHB_CLK>,
> +< OXILICX_AXI_CLK>;
> + sram = <>;
Shouldn't this point to gmu-sram@0? You can always get the parent from
the child which is a bit easier than the other way around.
> + power-domains = < OXILICX_GDSC>;
> + operating-points-v2 = <_opp_table>;
> + iommus = <_iommu 0>;
> + };
> +
> + ocmem: ocmem@fdd0 {
> + compatible = "qcom,msm8974-ocmem";
> +
> + reg = <0xfdd0 0x2000>,
> + <0xfec0 0x18>;
> + reg-names = "ctrl",
> +"mem";
> +
> + clocks = < RPM_SMD_OCMEMGX_CLK>,
> +< OCMEMCX_OCMEMNOC_CLK>;
> + clock-names = "core",
> + "iface";
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + gmu-sram@0 {
> + reg = <0x0 0x10>;
> + };
> + };
> +};
> --
> 2.21.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/50] drm/bridge: Add bridge driver for display connectors
On Tue, 20 Aug 2019 04:16:42 +0300
Laurent Pinchart wrote:
> + /*
> + * Get the HPD GPIO for DVI and HDMI connectors. If the GPIO can provide
> + * interrupts, register an interrupt handler.
> + */
> + if (type == DRM_MODE_CONNECTOR_DVII ||
> + type == DRM_MODE_CONNECTOR_HDMIA) {
> + conn->hpd_gpio = devm_gpiod_get_optional(>dev, "hpd",
> + GPIOD_IN);
> + if (IS_ERR(conn->hpd_gpio)) {
> + if (PTR_ERR(conn->hpd_gpio) != -EPROBE_DEFER)
> + dev_err(>dev,
> + "Unable to retrieve HPD GPIO\n");
> + return PTR_ERR(conn->hpd_gpio);
> + }
> +
> + conn->hpd_irq = gpiod_to_irq(conn->hpd_gpio);
> + } else {
> + conn->hpd_irq = -EINVAL;
> + }
> +
> + if (conn->hpd_irq >= 0) {
> + ret = devm_request_threaded_irq(>dev, conn->hpd_irq,
> + NULL, display_connector_hpd_irq,
> + IRQF_TRIGGER_RISING |
> + IRQF_TRIGGER_FALLING |
> + IRQF_ONESHOT,
> + "HPD", conn);
> + if (ret) {
> + dev_err(>dev,
> + "Failed to request HPD interrupt\n");
> + return ret;
Is there anything that mandates support of edge events on GPIO chips?
I know it's quite common, but maybe we should fallback to polling
mode when devm_request_threaded_irq() fails.
> + }
> + }
> +
> + /* Retrieve the DDC I2C adapter for DVI, HDMI and VGA connectors. */
> + if (type == DRM_MODE_CONNECTOR_DVII ||
> + type == DRM_MODE_CONNECTOR_HDMIA ||
> + type == DRM_MODE_CONNECTOR_VGA) {
> + struct device_node *phandle;
> +
> + phandle = of_parse_phandle(pdev->dev.of_node, "ddc-i2c-bus", 0);
> + if (phandle) {
> + conn->bridge.ddc = of_get_i2c_adapter_by_node(phandle);
> + of_node_put(phandle);
> + if (!conn->bridge.ddc)
> + return -EPROBE_DEFER;
> + } else {
> + dev_dbg(>dev,
> + "No I2C bus specified, disabling EDID
> readout\n");
> + }
> + }
> +
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: meson: use match data to detect vpu compatibility
Hi Julien,
On 22/08/2019 16:43, Julien Masson wrote:
> This patch introduce new enum which contains all VPU family (GXBB,
> GXL, GXM and G12A).
> This enum is used to detect the VPU compatible with the device.
>
> We only need to set .data to the corresponding enum in the device
> table, no need to check .compatible string anymore.
>
> Signed-off-by: Julien Masson
> ---
>
> Changes since v1 at [1]:
> - Set .data field in struct dt_match instead of connectors_match
> - Add compat in struct meson_drm and set it the corresponding family at probe
> - Check directly compat in meson_vpu_is_compatible
>
> [1] https://patchwork.kernel.org/patch/11108855/
>
> drivers/gpu/drm/meson/meson_crtc.c | 2 +-
> drivers/gpu/drm/meson/meson_drv.c | 14 --
> drivers/gpu/drm/meson/meson_drv.h | 13 -
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 2 +-
> drivers/gpu/drm/meson/meson_overlay.c | 2 +-
> drivers/gpu/drm/meson/meson_plane.c | 10 ++--
> drivers/gpu/drm/meson/meson_vclk.c | 64 -
> drivers/gpu/drm/meson/meson_venc.c | 2 +-
> drivers/gpu/drm/meson/meson_venc_cvbs.c | 10 ++--
> drivers/gpu/drm/meson/meson_viu.c | 10 ++--
> drivers/gpu/drm/meson/meson_vpp.c | 10 ++--
> 11 files changed, 77 insertions(+), 62 deletions(-)
Tested-by: Neil Armstrong
on SEI510 (G12A), VIM2 (GXM) and Libretech-AC (GXL)
and
Acked-by: Neil Armstrong
Applying to drm-misc-next
Neil
>
> diff --git a/drivers/gpu/drm/meson/meson_crtc.c
> b/drivers/gpu/drm/meson/meson_crtc.c
> index bba25325aa9c..57ae1c13d1e6 100644
> --- a/drivers/gpu/drm/meson/meson_crtc.c
> +++ b/drivers/gpu/drm/meson/meson_crtc.c
> @@ -575,7 +575,7 @@ int meson_crtc_create(struct meson_drm *priv)
> return ret;
> }
>
> - if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
> + if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A)) {
> meson_crtc->enable_osd1 = meson_g12a_crtc_enable_osd1;
> meson_crtc->enable_vd1 = meson_g12a_crtc_enable_vd1;
> meson_crtc->viu_offset = MESON_G12A_VIU_OFFSET;
> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> b/drivers/gpu/drm/meson/meson_drv.c
> index ae0166181606..a24f8dec5adc 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -209,6 +209,8 @@ static int meson_drv_bind_master(struct device *dev, bool
> has_components)
> priv->drm = drm;
> priv->dev = dev;
>
> + priv->compat = (enum vpu_compatible)of_device_get_match_data(priv->dev);
> +
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "vpu");
> regs = devm_ioremap_resource(dev, res);
> if (IS_ERR(regs)) {
> @@ -453,10 +455,14 @@ static int meson_drv_probe(struct platform_device *pdev)
> };
>
> static const struct of_device_id dt_match[] = {
> - { .compatible = "amlogic,meson-gxbb-vpu" },
> - { .compatible = "amlogic,meson-gxl-vpu" },
> - { .compatible = "amlogic,meson-gxm-vpu" },
> - { .compatible = "amlogic,meson-g12a-vpu" },
> + { .compatible = "amlogic,meson-gxbb-vpu",
> + .data = (void *)VPU_COMPATIBLE_GXBB },
> + { .compatible = "amlogic,meson-gxl-vpu",
> + .data = (void *)VPU_COMPATIBLE_GXL },
> + { .compatible = "amlogic,meson-gxm-vpu",
> + .data = (void *)VPU_COMPATIBLE_GXM },
> + { .compatible = "amlogic,meson-g12a-vpu",
> + .data = (void *)VPU_COMPATIBLE_G12A },
> {}
> };
> MODULE_DEVICE_TABLE(of, dt_match);
> diff --git a/drivers/gpu/drm/meson/meson_drv.h
> b/drivers/gpu/drm/meson/meson_drv.h
> index c9aaec1a846e..820d07bdd42a 100644
> --- a/drivers/gpu/drm/meson/meson_drv.h
> +++ b/drivers/gpu/drm/meson/meson_drv.h
> @@ -9,6 +9,7 @@
>
> #include
> #include
> +#include
> #include
>
> struct drm_crtc;
> @@ -16,8 +17,16 @@ struct drm_device;
> struct drm_plane;
> struct meson_drm;
>
> +enum vpu_compatible {
> + VPU_COMPATIBLE_GXBB = 0,
> + VPU_COMPATIBLE_GXL = 1,
> + VPU_COMPATIBLE_GXM = 2,
> + VPU_COMPATIBLE_G12A = 3,
> +};
> +
> struct meson_drm {
> struct device *dev;
> + enum vpu_compatible compat;
> void __iomem *io_base;
> struct regmap *hhi;
> int vsync_irq;
> @@ -116,9 +125,9 @@ struct meson_drm {
> };
>
> static inline int meson_vpu_is_compatible(struct meson_drm *priv,
> - const char *compat)
> + enum vpu_compatible family)
> {
> - return of_device_is_compatible(priv->dev->of_node, compat);
> + return priv->compat == family;
> }
>
> #endif /* __MESON_DRV_H */
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index f893ebd0b799..68bbd987147b 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -937,7 +937,7 @@ static int meson_dw_hdmi_bind(struct device *dev,
[PATCH v2] drm/msm/dpu: add rotation property
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 45bfac9e3af7..970194958257 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1040,8 +1040,21 @@ static void dpu_plane_sspp_atomic_update(struct
drm_plane *plane)
pstate->multirect_mode);
if (pdpu->pipe_hw->ops.setup_format) {
+ unsigned int rotation;
+
src_flags = 0x0;
+ rotation = drm_rotation_simplify(state->rotation,
+DRM_MODE_ROTATE_0 |
+DRM_MODE_REFLECT_X |
+DRM_MODE_REFLECT_Y);
+
+ if (rotation & DRM_MODE_REFLECT_X)
+ src_flags |= DPU_SSPP_FLIP_LR;
+
+ if (rotation & DRM_MODE_REFLECT_Y)
+ src_flags |= DPU_SSPP_FLIP_UD;
+
/* update format */
pdpu->pipe_hw->ops.setup_format(pdpu->pipe_hw, fmt, src_flags,
pstate->multirect_index);
@@ -1522,6 +1535,13 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
if (ret)
DPU_ERROR("failed to install zpos property, rc = %d\n", ret);
+ drm_plane_create_rotation_property(plane,
+ DRM_MODE_ROTATE_0,
+ DRM_MODE_ROTATE_0 |
+ DRM_MODE_ROTATE_180 |
+ DRM_MODE_REFLECT_X |
+ DRM_MODE_REFLECT_Y);
+
drm_plane_enable_fb_damage_clips(plane);
/* success! finalize initialization */
--
2.21.0
Re: [PATCH v2 10/50] drm/bridge: simple-bridge: Add support for the TI OP362
On Tue, 20 Aug 2019 04:16:41 +0300
Laurent Pinchart wrote:
> The TI OP362 is an analog video amplifier controlled through a GPIO. Add
> support for it to the simple-bridge driver.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Andrzej Hajda
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/bridge/simple-bridge.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/simple-bridge.c
> b/drivers/gpu/drm/bridge/simple-bridge.c
> index 3e5031833368..52626e2de90e 100644
> --- a/drivers/gpu/drm/bridge/simple-bridge.c
> +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> @@ -302,6 +302,11 @@ static const struct of_device_id simple_bridge_match[] =
> {
> .timings = _bridge_timings,
> .connector_type = DRM_MODE_CONNECTOR_VGA,
> },
> + }, {
> + .compatible = "ti,opa362",
> + .data = &(const struct simple_bridge_info) {
> + .connector_type = DRM_MODE_CONNECTOR_Composite,
> + },
> }, {
> .compatible = "ti,ths8135",
> .data = &(const struct simple_bridge_info) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dpu: add rotation property
On Thu, Aug 22, 2019 at 5:26 AM Ville Syrjälä
wrote:
>
> On Wed, Aug 21, 2019 at 06:57:24PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 20
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > index 45bfac9e3af7..c5653771e8fa 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > @@ -1040,8 +1040,21 @@ static void dpu_plane_sspp_atomic_update(struct
> > drm_plane *plane)
> > pstate->multirect_mode);
> >
> > if (pdpu->pipe_hw->ops.setup_format) {
> > + unsigned int rotation;
> > +
> > src_flags = 0x0;
> >
> > + rotation = drm_rotation_simplify(state->rotation,
> > + DRM_MODE_ROTATE_0 |
> > + DRM_MODE_REFLECT_X |
> > + DRM_MODE_REFLECT_Y);
> > +
> > + if (rotation & DRM_MODE_REFLECT_X)
> > + src_flags |= DPU_SSPP_FLIP_UD;
> > +
> > + if (rotation & DRM_MODE_REFLECT_Y)
> > + src_flags |= DPU_SSPP_FLIP_LR;
> > +
>
> UD vs. LR (assuming those mean what I think they mean) seem the wrong
> way around here.
ahh, right, reflect "along" vs "around"..
BR,
-R
>
> >
> > /* update format */
> > pdpu->pipe_hw->ops.setup_format(pdpu->pipe_hw, fmt, src_flags,
> > pstate->multirect_index);
> > @@ -1522,6 +1535,13 @@ struct drm_plane *dpu_plane_init(struct drm_device
> > *dev,
> > if (ret)
> > DPU_ERROR("failed to install zpos property, rc = %d\n", ret);
> >
> > + drm_plane_create_rotation_property(plane,
> > + DRM_MODE_ROTATE_0,
> > + DRM_MODE_ROTATE_0 |
> > + DRM_MODE_ROTATE_180 |
> > + DRM_MODE_REFLECT_X |
> > + DRM_MODE_REFLECT_Y);
> > +
> > drm_plane_enable_fb_damage_clips(plane);
> >
> > /* success! finalize initialization */
> > --
> > 2.21.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel
Re: [PATCH v2 09/50] drm/bridge: simple-bridge: Add support for enable GPIO
On Tue, 20 Aug 2019 04:16:40 +0300
Laurent Pinchart wrote:
> If an enable GPIO is declared in the firmware, assert it when enabling
> the bridge and deassert it when disabling it.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Andrzej Hajda
> Reviewed-by: Stefan Agner
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/bridge/simple-bridge.c | 22 ++
> 1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/simple-bridge.c
> b/drivers/gpu/drm/bridge/simple-bridge.c
> index 85aa852eafb4..3e5031833368 100644
> --- a/drivers/gpu/drm/bridge/simple-bridge.c
> +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> @@ -6,6 +6,7 @@
> * Maxime Ripard
> */
>
> +#include
> #include
> #include
> #include
> @@ -29,6 +30,7 @@ struct simple_bridge {
>
> struct i2c_adapter *ddc;
> struct regulator*vdd;
> + struct gpio_desc*enable;
> };
>
> static inline struct simple_bridge *
> @@ -140,19 +142,23 @@ static int simple_bridge_attach(struct drm_bridge
> *bridge,
> static void simple_bridge_enable(struct drm_bridge *bridge)
> {
> struct simple_bridge *sbridge = drm_bridge_to_simple_bridge(bridge);
> - int ret = 0;
> + int ret;
>
> - if (sbridge->vdd)
> + if (sbridge->vdd) {
> ret = regulator_enable(sbridge->vdd);
> + if (ret)
> + DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
> + }
>
> - if (ret)
> - DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
> + gpiod_set_value_cansleep(sbridge->enable, 1);
> }
>
> static void simple_bridge_disable(struct drm_bridge *bridge)
> {
> struct simple_bridge *sbridge = drm_bridge_to_simple_bridge(bridge);
>
> + gpiod_set_value_cansleep(sbridge->enable, 0);
> +
> if (sbridge->vdd)
> regulator_disable(sbridge->vdd);
> }
> @@ -205,6 +211,14 @@ static int simple_bridge_probe(struct platform_device
> *pdev)
> dev_dbg(>dev, "No vdd regulator found: %d\n", ret);
> }
>
> + sbridge->enable = devm_gpiod_get_optional(>dev, "enable",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(sbridge->enable)) {
> + if (PTR_ERR(sbridge->enable) != -EPROBE_DEFER)
> + dev_err(>dev, "Unable to retrieve enable GPIO\n");
> + return PTR_ERR(sbridge->enable);
> + }
> +
> sbridge->ddc = simple_bridge_retrieve_ddc(>dev);
> if (IS_ERR(sbridge->ddc)) {
> if (PTR_ERR(sbridge->ddc) == -ENODEV) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/50] drm/bridge: simple-bridge: Add support for non-VGA bridges
On Tue, 20 Aug 2019 04:16:39 +0300
Laurent Pinchart wrote:
> Create a new simple_bridge_info structure that stores information about
> the bridge model, and store the bridge timings in there, along with the
> connector type. Use that new structure for of_device_id data. This
> enables support for non-VGA bridges.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Andrzej Hajda
> Reviewed-by: Stefan Agner
Reviewed-by: Boris Brezillon
> ---
> Changes since v1:
>
> - Renamed simple_bridge_info.type field to connector_type
> ---
> drivers/gpu/drm/bridge/simple-bridge.c | 41 ++
> 1 file changed, 29 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/simple-bridge.c
> b/drivers/gpu/drm/bridge/simple-bridge.c
> index 7551a361f22e..85aa852eafb4 100644
> --- a/drivers/gpu/drm/bridge/simple-bridge.c
> +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> @@ -16,10 +16,17 @@
> #include
> #include
>
> +struct simple_bridge_info {
> + const struct drm_bridge_timings *timings;
> + unsigned int connector_type;
> +};
> +
> struct simple_bridge {
> struct drm_bridge bridge;
> struct drm_connectorconnector;
>
> + const struct simple_bridge_info *info;
> +
> struct i2c_adapter *ddc;
> struct regulator*vdd;
> };
> @@ -117,7 +124,7 @@ static int simple_bridge_attach(struct drm_bridge *bridge,
>_bridge_con_helper_funcs);
> ret = drm_connector_init_with_ddc(bridge->dev, >connector,
> _bridge_con_funcs,
> - DRM_MODE_CONNECTOR_VGA,
> + sbridge->info->connector_type,
> sbridge->ddc);
> if (ret) {
> DRM_ERROR("Failed to initialize connector\n");
> @@ -187,6 +194,8 @@ static int simple_bridge_probe(struct platform_device
> *pdev)
> return -ENOMEM;
> platform_set_drvdata(pdev, sbridge);
>
> + sbridge->info = of_device_get_match_data(>dev);
> +
> sbridge->vdd = devm_regulator_get_optional(>dev, "vdd");
> if (IS_ERR(sbridge->vdd)) {
> int ret = PTR_ERR(sbridge->vdd);
> @@ -210,7 +219,7 @@ static int simple_bridge_probe(struct platform_device
> *pdev)
>
> sbridge->bridge.funcs = _bridge_bridge_funcs;
> sbridge->bridge.of_node = pdev->dev.of_node;
> - sbridge->bridge.timings = of_device_get_match_data(>dev);
> + sbridge->bridge.timings = sbridge->info->timings;
>
> drm_bridge_add(>bridge);
>
> @@ -270,19 +279,27 @@ static const struct drm_bridge_timings
> ti_ths8135_bridge_timings = {
> static const struct of_device_id simple_bridge_match[] = {
> {
> .compatible = "dumb-vga-dac",
> - .data = NULL,
> - },
> - {
> + .data = &(const struct simple_bridge_info) {
> + .connector_type = DRM_MODE_CONNECTOR_VGA,
> + },
> + }, {
> .compatible = "adi,adv7123",
> - .data = _bridge_timings,
> - },
> - {
> + .data = &(const struct simple_bridge_info) {
> + .timings = _bridge_timings,
> + .connector_type = DRM_MODE_CONNECTOR_VGA,
> + },
> + }, {
> .compatible = "ti,ths8135",
> - .data = _ths8135_bridge_timings,
> - },
> - {
> + .data = &(const struct simple_bridge_info) {
> + .timings = _ths8135_bridge_timings,
> + .connector_type = DRM_MODE_CONNECTOR_VGA,
> + },
> + }, {
> .compatible = "ti,ths8134",
> - .data = _ths8134_bridge_timings,
> + .data = &(const struct simple_bridge_info) {
> + .timings = _ths8134_bridge_timings,
> + .connector_type = DRM_MODE_CONNECTOR_VGA,
> + },
> },
> {},
> };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/50] drm/bridge: dumb-vga-dac: Rename driver to simple-bridge
On Tue, 20 Aug 2019 04:16:38 +0300
Laurent Pinchart wrote:
> The dumb-vga-dac driver can support simple DRM bridges without being
> limited to VGA DACs. Rename it to simple-bridge.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Andrzej Hajda
Reviewed-by: Boris Brezillon
> ---
> arch/arm/configs/davinci_all_defconfig | 2 +-
> arch/arm/configs/integrator_defconfig| 2 +-
> arch/arm/configs/multi_v7_defconfig | 2 +-
> arch/arm/configs/shmobile_defconfig | 2 +-
> arch/arm/configs/sunxi_defconfig | 2 +-
> arch/arm/configs/versatile_defconfig | 2 +-
> drivers/gpu/drm/bridge/Kconfig | 16
> drivers/gpu/drm/bridge/Makefile | 2 +-
> .../bridge/{dumb-vga-dac.c => simple-bridge.c} | 2 +-
> 9 files changed, 16 insertions(+), 16 deletions(-)
> rename drivers/gpu/drm/bridge/{dumb-vga-dac.c => simple-bridge.c} (99%)
>
> diff --git a/arch/arm/configs/davinci_all_defconfig
> b/arch/arm/configs/davinci_all_defconfig
> index 9a32a8c0f873..4b8cf51b2abd 100644
> --- a/arch/arm/configs/davinci_all_defconfig
> +++ b/arch/arm/configs/davinci_all_defconfig
> @@ -155,7 +155,7 @@ CONFIG_VIDEO_TVP514X=m
> CONFIG_VIDEO_ADV7343=m
> CONFIG_DRM=m
> CONFIG_DRM_TILCDC=m
> -CONFIG_DRM_DUMB_VGA_DAC=m
> +CONFIG_DRM_SIMPLE_BRIDGE=m
> CONFIG_DRM_TINYDRM=m
> CONFIG_TINYDRM_ST7586=m
> CONFIG_FB=y
> diff --git a/arch/arm/configs/integrator_defconfig
> b/arch/arm/configs/integrator_defconfig
> index 2f0a762dc3a0..a9755c501bec 100644
> --- a/arch/arm/configs/integrator_defconfig
> +++ b/arch/arm/configs/integrator_defconfig
> @@ -55,7 +55,7 @@ CONFIG_SMC91X=y
> # CONFIG_KEYBOARD_ATKBD is not set
> # CONFIG_SERIO_SERPORT is not set
> CONFIG_DRM=y
> -CONFIG_DRM_DUMB_VGA_DAC=y
> +CONFIG_DRM_SIMPLE_BRIDGE=y
> CONFIG_DRM_PL111=y
> CONFIG_FB_MODE_HELPERS=y
> CONFIG_FB_MATROX=y
> diff --git a/arch/arm/configs/multi_v7_defconfig
> b/arch/arm/configs/multi_v7_defconfig
> index 6a40bc2ef271..9eefc0cc29bc 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -644,11 +644,11 @@ CONFIG_DRM_PANEL_ORISETECH_OTM8009A=m
> CONFIG_DRM_PANEL_RAYDIUM_RM68200=m
> CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03=m
> CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=m
> -CONFIG_DRM_DUMB_VGA_DAC=m
> CONFIG_DRM_NXP_PTN3460=m
> CONFIG_DRM_PARADE_PS8622=m
> CONFIG_DRM_SII902X=m
> CONFIG_DRM_SII9234=m
> +CONFIG_DRM_SIMPLE_BRIDGE=m
> CONFIG_DRM_TOSHIBA_TC358764=m
> CONFIG_DRM_I2C_ADV7511=m
> CONFIG_DRM_I2C_ADV7511_AUDIO=y
> diff --git a/arch/arm/configs/shmobile_defconfig
> b/arch/arm/configs/shmobile_defconfig
> index c6c70355141c..a8e7827a7214 100644
> --- a/arch/arm/configs/shmobile_defconfig
> +++ b/arch/arm/configs/shmobile_defconfig
> @@ -125,8 +125,8 @@ CONFIG_VIDEO_ADV7604=y
> CONFIG_VIDEO_ML86V7667=y
> CONFIG_DRM=y
> CONFIG_DRM_RCAR_DU=y
> -CONFIG_DRM_DUMB_VGA_DAC=y
> CONFIG_DRM_SII902X=y
> +CONFIG_DRM_SIMPLE_BRIDGE=y
> CONFIG_DRM_I2C_ADV7511=y
> CONFIG_DRM_I2C_ADV7511_AUDIO=y
> CONFIG_FB_SH_MOBILE_LCDC=y
> diff --git a/arch/arm/configs/sunxi_defconfig
> b/arch/arm/configs/sunxi_defconfig
> index df433abfcb02..19cccae84a19 100644
> --- a/arch/arm/configs/sunxi_defconfig
> +++ b/arch/arm/configs/sunxi_defconfig
> @@ -99,7 +99,7 @@ CONFIG_RC_DEVICES=y
> CONFIG_IR_SUNXI=y
> CONFIG_DRM=y
> CONFIG_DRM_SUN4I=y
> -CONFIG_DRM_DUMB_VGA_DAC=y
> +CONFIG_DRM_SIMPLE_BRIDGE=y
> CONFIG_FB_SIMPLE=y
> CONFIG_SOUND=y
> CONFIG_SND=y
> diff --git a/arch/arm/configs/versatile_defconfig
> b/arch/arm/configs/versatile_defconfig
> index fe4d4b596585..767935337413 100644
> --- a/arch/arm/configs/versatile_defconfig
> +++ b/arch/arm/configs/versatile_defconfig
> @@ -59,7 +59,7 @@ CONFIG_GPIO_PL061=y
> CONFIG_DRM=y
> CONFIG_DRM_PANEL_ARM_VERSATILE=y
> CONFIG_DRM_PANEL_SIMPLE=y
> -CONFIG_DRM_DUMB_VGA_DAC=y
> +CONFIG_DRM_SIMPLE_BRIDGE=y
> CONFIG_DRM_PL111=y
> CONFIG_FB_MODE_HELPERS=y
> CONFIG_BACKLIGHT_CLASS_DEVICE=y
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 1cc9f502c1f2..d0146438b0f5 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -37,14 +37,6 @@ config DRM_CDNS_DSI
> Support Cadence DPI to DSI bridge. This is an internal
> bridge and is meant to be directly embedded in a SoC.
>
> -config DRM_DUMB_VGA_DAC
> - tristate "Dumb VGA DAC Bridge support"
> - depends on OF
> - select DRM_KMS_HELPER
> - help
> - Support for non-programmable RGB to VGA DAC bridges, such as ADI
> - ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
> -
> config DRM_LVDS_ENCODER
> tristate "Transparent parallel to LVDS encoder support"
> depends on OF
> @@ -109,6 +101,14 @@ config DRM_SII9234
> It is an I2C driver, that detects connection of MHL bridge
> and starts encapsulation of HDMI signal.
>
> +config DRM_SIMPLE_BRIDGE
> +
Re: [PATCH v2 06/50] drm/bridge: dumb-vga-dac: Rename internal symbols to simple-bridge
On Tue, 20 Aug 2019 04:16:37 +0300
Laurent Pinchart wrote:
> The dumb-vga-dac driver is a simple DRM bridge driver for simple VGA
> DACs that don't require configuration. Other non-VGA bridges fall in a
> similar category, and would benefit from a common driver. Prepare for
> this by renaming the internal symbols from dumb-vga-dac to
> simple-bridge.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Andrzej Hajda
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/bridge/dumb-vga-dac.c | 154 +-
> 1 file changed, 77 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> index 74ebca58eb1f..03ceb0cd8b9e 100644
> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> @@ -16,7 +16,7 @@
> #include
> #include
>
> -struct dumb_vga {
> +struct simple_bridge {
> struct drm_bridge bridge;
> struct drm_connectorconnector;
>
> @@ -24,28 +24,28 @@ struct dumb_vga {
> struct regulator*vdd;
> };
>
> -static inline struct dumb_vga *
> -drm_bridge_to_dumb_vga(struct drm_bridge *bridge)
> +static inline struct simple_bridge *
> +drm_bridge_to_simple_bridge(struct drm_bridge *bridge)
> {
> - return container_of(bridge, struct dumb_vga, bridge);
> + return container_of(bridge, struct simple_bridge, bridge);
> }
>
> -static inline struct dumb_vga *
> -drm_connector_to_dumb_vga(struct drm_connector *connector)
> +static inline struct simple_bridge *
> +drm_connector_to_simple_bridge(struct drm_connector *connector)
> {
> - return container_of(connector, struct dumb_vga, connector);
> + return container_of(connector, struct simple_bridge, connector);
> }
>
> -static int dumb_vga_get_modes(struct drm_connector *connector)
> +static int simple_bridge_get_modes(struct drm_connector *connector)
> {
> - struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
> + struct simple_bridge *sbridge =
> drm_connector_to_simple_bridge(connector);
> struct edid *edid;
> int ret;
>
> - if (!vga->ddc)
> + if (!sbridge->ddc)
> goto fallback;
>
> - edid = drm_get_edid(connector, vga->ddc);
> + edid = drm_get_edid(connector, sbridge->ddc);
> if (!edid) {
> DRM_INFO("EDID readout failed, falling back to standard
> modes\n");
> goto fallback;
> @@ -69,14 +69,14 @@ static int dumb_vga_get_modes(struct drm_connector
> *connector)
> return ret;
> }
>
> -static const struct drm_connector_helper_funcs dumb_vga_con_helper_funcs = {
> - .get_modes = dumb_vga_get_modes,
> +static const struct drm_connector_helper_funcs
> simple_bridge_con_helper_funcs = {
> + .get_modes = simple_bridge_get_modes,
> };
>
> static enum drm_connector_status
> -dumb_vga_connector_detect(struct drm_connector *connector, bool force)
> +simple_bridge_connector_detect(struct drm_connector *connector, bool force)
> {
> - struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
> + struct simple_bridge *sbridge =
> drm_connector_to_simple_bridge(connector);
>
> /*
>* Even if we have an I2C bus, we can't assume that the cable
> @@ -84,14 +84,14 @@ dumb_vga_connector_detect(struct drm_connector
> *connector, bool force)
>* wire the DDC pins, or the I2C bus might not be working at
>* all.
>*/
> - if (vga->ddc && drm_probe_ddc(vga->ddc))
> + if (sbridge->ddc && drm_probe_ddc(sbridge->ddc))
> return connector_status_connected;
>
> return connector_status_unknown;
> }
>
> -static const struct drm_connector_funcs dumb_vga_con_funcs = {
> - .detect = dumb_vga_connector_detect,
> +static const struct drm_connector_funcs simple_bridge_con_funcs = {
> + .detect = simple_bridge_connector_detect,
> .fill_modes = drm_helper_probe_single_connector_modes,
> .destroy= drm_connector_cleanup,
> .reset = drm_atomic_helper_connector_reset,
> @@ -99,10 +99,10 @@ static const struct drm_connector_funcs
> dumb_vga_con_funcs = {
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> };
>
> -static int dumb_vga_attach(struct drm_bridge *bridge,
> -enum drm_bridge_attach_flags flags)
> +static int simple_bridge_attach(struct drm_bridge *bridge,
> + enum drm_bridge_attach_flags flags)
> {
> - struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
> + struct simple_bridge *sbridge = drm_bridge_to_simple_bridge(bridge);
> int ret;
>
> if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> @@ -113,50 +113,50 @@ static int dumb_vga_attach(struct drm_bridge *bridge,
> return -ENODEV;
> }
>
> - drm_connector_helper_add(>connector,
> -
Re: [PATCH v2 05/50] drm/bridge: Extend bridge API to disable connector creation
On Tue, 20 Aug 2019 04:16:36 +0300
Laurent Pinchart wrote:
> Most bridge drivers create a DRM connector to model the connector at the
> output of the bridge. This model is historical and has worked pretty
> well so far, but causes several issues:
>
> - It prevents supporting more complex display pipelines where DRM
> connector operations are split over multiple components. For instance a
> pipeline with a bridge connected to the DDC signals to read EDID data,
> and another one connected to the HPD signal to detect connection and
> disconnection, will not be possible to support through this model.
>
> - It requires every bridge driver to implement similar connector
> handling code, resulting in code duplication.
>
> - It assumes that a bridge will either be wired to a connector or to
> another bridge, but doesn't support bridges that can be used in both
> positions very well (although there is some ad-hoc support for this in
> the analogix_dp bridge driver).
>
> In order to solve these issues, ownership of the connector should be
> moved to the display controller driver (where it can be implemented
> using helpers provided by the core).
>
> Extend the bridge API to allow disabling connector creation in bridge
> drivers as a first step towards the new model. The new create_connector
> argument to the bridge .attach() operation tells the bridge driver
> whether to create a connector. Set the argument to true unconditionally,
You're talking about the extra arg passed to drm_bridge_attach(), right?
I guess this commit message reflects the old implementation where
the extra arg was a boolean.
> and modify all existing bridge drivers to return an error when connector
> creation is not requested as they don't support this feature yet.
>
> The change is based on the following semantic patch, with manual review
> and edits.
>
> @ rule1 @
> identifier funcs;
> identifier fn;
> @@
> struct drm_bridge_funcs funcs = {
> ...,
> .attach = fn
> };
>
> @ depends on rule1 @
> identifier rule1.fn;
> identifier bridge;
> statement S, S1;
> @@
> int fn(
> struct drm_bridge *bridge
> + , enum drm_bridge_attach_flags flags
> )
> {
> ... when != S
> + if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> + return -EINVAL;
> +
> S1
> ...
> }
>
> @@
> expression E1, E2, E3;
> @@
> drm_bridge_attach(E1, E2, E3
> + , 0
> )
>
> Signed-off-by: Laurent Pinchart
Haven't gone through the diff but the semantic patch looks good, and
I'm pretty sure you compiled all drivers implementing the attach hook
and/or calling drm_bridge_attach().
Reviewed-by: Boris Brezillon
> ---
> Changes since v1:
>
> - Replace the create_connector boolean with a flags bitmask
> - Update ingenic driver
> - Add semantic patch to commit message
> ---
> drivers/gpu/drm/arc/arcpgu_hdmi.c | 2 +-
> .../gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 2 +-
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 +-
> drivers/gpu/drm/bridge/analogix-anx78xx.c | 6 +-
> .../drm/bridge/analogix/analogix_dp_core.c| 8 ++--
> drivers/gpu/drm/bridge/cdns-dsi.c | 6 --
> drivers/gpu/drm/bridge/dumb-vga-dac.c | 6 +-
> drivers/gpu/drm/bridge/lvds-encoder.c | 5 +++--
> .../bridge/megachips-stdp-ge-b850v3-fw.c | 6 +-
> drivers/gpu/drm/bridge/nxp-ptn3460.c | 6 +-
> drivers/gpu/drm/bridge/panel.c| 6 +-
> drivers/gpu/drm/bridge/parade-ps8622.c| 6 +-
> drivers/gpu/drm/bridge/sii902x.c | 6 +-
> drivers/gpu/drm/bridge/sil-sii8620.c | 3 ++-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 ++--
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 8 +---
> drivers/gpu/drm/bridge/tc358764.c | 6 +-
> drivers/gpu/drm/bridge/tc358767.c | 6 +-
> drivers/gpu/drm/bridge/thc63lvd1024.c | 5 +++--
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 6 +-
> drivers/gpu/drm/bridge/ti-tfp410.c| 6 +-
> drivers/gpu/drm/drm_bridge.c | 6 --
> drivers/gpu/drm/drm_simple_kms_helper.c | 2 +-
> drivers/gpu/drm/exynos/exynos_dp.c| 3 ++-
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 ++--
> drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 2 +-
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 2 +-
> drivers/gpu/drm/i2c/tda998x_drv.c | 8 ++--
> drivers/gpu/drm/imx/imx-ldb.c | 2 +-
> drivers/gpu/drm/imx/parallel-display.c| 2 +-
> drivers/gpu/drm/ingenic/ingenic-drm.c | 2 +-
> drivers/gpu/drm/mcde/mcde_dsi.c | 8 ++--
> drivers/gpu/drm/mediatek/mtk_dpi.c| 2 +-
> drivers/gpu/drm/mediatek/mtk_dsi.c| 2 +-
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 8 ++--
>
Re: [PATCH v2 04/50] drm/bridge: Add connector-related bridge operations and data
On Tue, 20 Aug 2019 04:16:35 +0300
Laurent Pinchart wrote:
> To support implementation of DRM connectors on top of DRM bridges
> instead of by bridges, the drm_bridge needs to expose new operations and
> data:
>
> - Output detection, hot-plug notification, mode retrieval and EDID
> retrieval operations
> - Bitmask of supported operations
> - Bridge output type
> - I2C adapter for DDC access
>
> Add and document these.
>
> Three new bridge helper functions are also added to handle hot plug
> notification in a way that is as transparent as possible for the
> bridges.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Boris Brezillon
> ---
> Changes since v1:
>
> - Make .hpd_enable() and .hpd_disable() optional
> - Rename .lost_hotplug() to .hpd_notify()
> - Add ddc field to drm_bridge
> ---
> drivers/gpu/drm/drm_bridge.c | 94 +++
> include/drm/drm_bridge.h | 177 ++-
> 2 files changed, 270 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index cba537c99e43..cf1fbed88410 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> */
> void drm_bridge_add(struct drm_bridge *bridge)
> {
> + mutex_init(>hpd_mutex);
> +
> mutex_lock(_lock);
> list_add_tail(>list, _list);
> mutex_unlock(_lock);
> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> mutex_lock(_lock);
> list_del_init(>list);
> mutex_unlock(_lock);
> +
> + mutex_destroy(>hpd_mutex);
> }
> EXPORT_SYMBOL(drm_bridge_remove);
>
> @@ -462,6 +466,96 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> }
> EXPORT_SYMBOL(drm_atomic_bridge_enable);
>
> +/**
> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> + * @bridge: bridge control structure
> + * @cb: hot-plug detection callback
> + * @data: data to be passed to the hot-plug detection callback
> + *
> + * Call _bridge_funcs.hpd_enable if implemented and register the given
> @cb
> + * and @data as hot plug notification callback. From now on the @cb will be
> + * called with @data when an output status change is detected by the bridge,
> + * until hot plug notification gets disabled with drm_bridge_hpd_disable().
> + *
> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set
> in
> + * bridge->ops. This function shall not be called when the flag is not set.
> + *
> + * Only one hot plug detection callback can be registered at a time, it is an
> + * error to call this function when hot plug detection is already enabled for
> + * the bridge.
> + */
> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> +void (*cb)(void *data,
> + enum drm_connector_status status),
> +void *data)
> +{
> + if (!bridge || !(bridge->ops & DRM_BRIDGE_OP_HPD))
> + return;
> +
> + mutex_lock(>hpd_mutex);
> +
> + if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> + goto unlock;
> +
> + bridge->hpd_cb = cb;
> + bridge->hpd_data = data;
> +
> + if (bridge->funcs->hpd_enable)
> + bridge->funcs->hpd_enable(bridge);
> +
> +unlock:
> + mutex_unlock(>hpd_mutex);
> +}
> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> +
> +/**
> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> + * @bridge: bridge control structure
> + *
> + * Call _bridge_funcs.hpd_disable if implemented and unregister the hot
> + * plug detection callback previously registered with
> drm_bridge_hpd_enable().
> + * Once this function returns the callback will not be called by the bridge
> + * when an output status change occurs.
> + *
> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set
> in
> + * bridge->ops. This function shall not be called when the flag is not set.
> + */
> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> +{
> + if (!bridge || !(bridge->ops & DRM_BRIDGE_OP_HPD))
> + return;
> +
> + mutex_lock(>hpd_mutex);
> + if (bridge->funcs->hpd_disable)
> + bridge->funcs->hpd_disable(bridge);
> +
> + bridge->hpd_cb = NULL;
> + bridge->hpd_data = NULL;
> + mutex_unlock(>hpd_mutex);
> +}
> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> +
> +/**
> + * drm_bridge_hpd_notify - notify hot plug detection events
> + * @bridge: bridge control structure
> + * @status: output connection status
> + *
> + * Bridge drivers shall call this function to report hot plug events when
> they
> + * detect a change in the output status, when hot plug detection has been
> + * enabled by drm_bridge_hpd_enable().
> + *
> + * This function shall be called in a context that can sleep.
> + */
> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> +enum drm_connector_status
[PATCH v9 2/6] drm: Move port definition back to i915 header
Handled the need for exposing enum port to mei_hdcp driver, by
converting the port into ddi index as per ME FW and sending to mei_hdcp.
Hence move enum port definition into I915 driver itself.
v2:
intel_display.h is included in intel_hdcp.h
v3:
enum port is declared in headers.
Signed-off-by: Ramalingam C
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bios.h| 1 +
drivers/gpu/drm/i915/display/intel_display.h | 18 ++
drivers/gpu/drm/i915/display/intel_dp.h | 1 +
drivers/gpu/drm/i915/display/intel_hdcp.h| 1 +
drivers/gpu/drm/i915/display/intel_hdmi.h| 1 +
drivers/gpu/drm/i915/display/intel_hotplug.h | 1 +
drivers/gpu/drm/i915/display/intel_sdvo.h| 1 +
include/drm/i915_drm.h | 18 --
8 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.h
b/drivers/gpu/drm/i915/display/intel_bios.h
index 4969189e620f..4c6e56a3940a 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.h
+++ b/drivers/gpu/drm/i915/display/intel_bios.h
@@ -35,6 +35,7 @@
#include
struct drm_i915_private;
+enum port;
enum intel_backlight_type {
INTEL_BACKLIGHT_PMIC,
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index e57e6969051d..40610d51327e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -182,6 +182,24 @@ enum plane_id {
for ((__p) = PLANE_PRIMARY; (__p) < I915_MAX_PLANES; (__p)++) \
for_each_if((__crtc)->plane_ids_mask & BIT(__p))
+enum port {
+ PORT_NONE = -1,
+
+ PORT_A = 0,
+ PORT_B,
+ PORT_C,
+ PORT_D,
+ PORT_E,
+ PORT_F,
+ PORT_G,
+ PORT_H,
+ PORT_I,
+
+ I915_MAX_PORTS
+};
+
+#define port_name(p) ((p) + 'A')
+
/*
* Ports identifier referenced from other drivers.
* Expected to remain stable over time
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 657bbb1f5ed0..e01d1f89409d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -13,6 +13,7 @@
#include "i915_reg.h"
enum pipe;
+enum port;
struct drm_connector_state;
struct drm_encoder;
struct drm_i915_private;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 13555b054930..59a2b40405cc 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -15,6 +15,7 @@ struct drm_connector_state;
struct drm_i915_private;
struct intel_connector;
struct intel_hdcp_shim;
+enum port;
void intel_hdcp_atomic_check(struct drm_connector *connector,
struct drm_connector_state *old_state,
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.h
b/drivers/gpu/drm/i915/display/intel_hdmi.h
index 106c2e0bc3c9..cf1ea5427639 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.h
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.h
@@ -23,6 +23,7 @@ struct intel_crtc_state;
struct intel_hdmi;
struct drm_connector_state;
union hdmi_infoframe;
+enum port;
void intel_hdmi_init(struct drm_i915_private *dev_priv, i915_reg_t hdmi_reg,
enum port port);
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.h
b/drivers/gpu/drm/i915/display/intel_hotplug.h
index b0cd447b7fbc..087b5f57b321 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.h
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.h
@@ -13,6 +13,7 @@
struct drm_i915_private;
struct intel_connector;
struct intel_encoder;
+enum port;
void intel_hpd_poll_init(struct drm_i915_private *dev_priv);
enum intel_hotplug_state intel_encoder_hotplug(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.h
b/drivers/gpu/drm/i915/display/intel_sdvo.h
index c9e05bcdd141..a66f224aa17d 100644
--- a/drivers/gpu/drm/i915/display/intel_sdvo.h
+++ b/drivers/gpu/drm/i915/display/intel_sdvo.h
@@ -14,6 +14,7 @@
struct drm_i915_private;
enum pipe;
+enum port;
bool intel_sdvo_port_enabled(struct drm_i915_private *dev_priv,
i915_reg_t sdvo_reg, enum pipe *pipe);
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 23274cf92712..6722005884db 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -100,22 +100,4 @@ extern struct resource intel_graphics_stolen_res;
#define INTEL_GEN11_BSM_DW10xc4
#define INTEL_BSM_MASK (-(1u << 20))
-enum port {
- PORT_NONE = -1,
-
- PORT_A = 0,
- PORT_B,
- PORT_C,
- PORT_D,
- PORT_E,
- PORT_F,
- PORT_G,
- PORT_H,
- PORT_I,
-
- I915_MAX_PORTS
-};
-
-#define port_name(p) ((p) + 'A')
-
#endif /* _I915_DRM_H_ */
--
2.20.1
___
dri-devel mailing list
[PATCH v9 0/6] drm/i915: Enable HDCP 1.4 and 2.2 on Gen12+
Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement from DDI into transcoder. v9: s/trans/cpu_transcoder enum port and transcoders are declared at few headers. Ramalingam C (6): drm/i915: mei_hdcp: I915 sends ddi index as per ME FW drm: Move port definition back to i915 header drm: Extend I915 mei interface for transcoder info misc/mei/hdcp: Fill transcoder index in port info drm/i915/hdcp: update current transcoder into intel_hdcp drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+ drivers/gpu/drm/i915/display/intel_bios.h | 1 + drivers/gpu/drm/i915/display/intel_display.h | 18 ++ .../drm/i915/display/intel_display_types.h| 7 + drivers/gpu/drm/i915/display/intel_dp.c | 3 + drivers/gpu/drm/i915/display/intel_dp.h | 1 + drivers/gpu/drm/i915/display/intel_hdcp.c | 210 +- drivers/gpu/drm/i915/display/intel_hdcp.h | 4 + drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +- drivers/gpu/drm/i915/display/intel_hdmi.h | 1 + drivers/gpu/drm/i915/display/intel_hotplug.h | 1 + drivers/gpu/drm/i915/display/intel_sdvo.h | 1 + drivers/gpu/drm/i915/i915_reg.h | 124 ++- drivers/misc/mei/hdcp/mei_hdcp.c | 45 ++-- drivers/misc/mei/hdcp/mei_hdcp.h | 16 +- include/drm/i915_drm.h| 18 -- include/drm/i915_mei_hdcp_interface.h | 29 ++- 16 files changed, 372 insertions(+), 120 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 6/6] drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+
From Gen12 onwards, HDCP HW block is implemented within transcoders.
Till Gen11 HDCP HW block was part of DDI.
Hence required changes in HW programming is handled here.
As ME FW needs the transcoder detail on which HDCP is enabled
on Gen12+ platform, we are populating the detail in hdcp_port_data.
v2:
_MMIO_TRANS is used [Lucas and Daniel]
platform check is moved into the caller [Lucas]
v3:
platform check is moved into a macro [Shashank]
v4:
Few optimizations in the coding [Shashank]
v5:
Fixed alignment in macro definition in i915_reg.h [Shashank]
unused variables "reg" is removed.
v6:
Configuring the transcoder at compute_config.
transcoder is used instead of pipe in macros.
Rebased.
v7:
transcoder is cached at intel_hdcp
hdcp_port_data is configured with transcoder index asper ME FW.
v8:
s/trans/cpu_transcoder
s/tc/cpu_transcoder
Signed-off-by: Ramalingam C
Reviewed-by: Shashank Sharma [v5]
Acked-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 148 ++
drivers/gpu/drm/i915/display/intel_hdmi.c | 10 +-
drivers/gpu/drm/i915/i915_reg.h | 124 --
3 files changed, 219 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 1e5548833e8f..e2084403db27 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -18,6 +18,7 @@
#include "intel_display_types.h"
#include "intel_hdcp.h"
#include "intel_sideband.h"
+#include "intel_connector.h"
#define KEY_LOAD_TRIES 5
#define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
@@ -105,24 +106,20 @@ bool intel_hdcp2_capable(struct intel_connector
*connector)
return capable;
}
-static inline bool intel_hdcp_in_use(struct intel_connector *connector)
+static inline
+bool intel_hdcp_in_use(struct drm_i915_private *dev_priv,
+ enum transcoder cpu_transcoder, enum port port)
{
- struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
- enum port port = connector->encoder->port;
- u32 reg;
-
- reg = I915_READ(PORT_HDCP_STATUS(port));
- return reg & HDCP_STATUS_ENC;
+ return I915_READ(HDCP_STATUS(dev_priv, cpu_transcoder, port)) &
+ HDCP_STATUS_ENC;
}
-static inline bool intel_hdcp2_in_use(struct intel_connector *connector)
+static inline
+bool intel_hdcp2_in_use(struct drm_i915_private *dev_priv,
+ enum transcoder cpu_transcoder, enum port port)
{
- struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
- enum port port = connector->encoder->port;
- u32 reg;
-
- reg = I915_READ(HDCP2_STATUS_DDI(port));
- return reg & LINK_ENCRYPTION_STATUS;
+ return I915_READ(HDCP2_STATUS(dev_priv, cpu_transcoder, port)) &
+ LINK_ENCRYPTION_STATUS;
}
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
@@ -253,9 +250,28 @@ static int intel_write_sha_text(struct drm_i915_private
*dev_priv, u32 sha_text)
}
static
-u32 intel_hdcp_get_repeater_ctl(struct intel_digital_port *intel_dig_port)
+u32 intel_hdcp_get_repeater_ctl(struct drm_i915_private *dev_priv,
+ enum transcoder cpu_transcoder, enum port port)
{
- enum port port = intel_dig_port->base.port;
+ if (INTEL_GEN(dev_priv) >= 12) {
+ switch (cpu_transcoder) {
+ case TRANSCODER_A:
+ return HDCP_TRANSA_REP_PRESENT |
+ HDCP_TRANSA_SHA1_M0;
+ case TRANSCODER_B:
+ return HDCP_TRANSB_REP_PRESENT |
+ HDCP_TRANSB_SHA1_M0;
+ case TRANSCODER_C:
+ return HDCP_TRANSC_REP_PRESENT |
+ HDCP_TRANSC_SHA1_M0;
+ /* FIXME: Add a case for PIPE_D */
+ default:
+ DRM_ERROR("Unknown transcoder %d\n", cpu_transcoder);
+ break;
+ }
+ return -EINVAL;
+ }
+
switch (port) {
case PORT_A:
return HDCP_DDIA_REP_PRESENT | HDCP_DDIA_SHA1_M0;
@@ -268,18 +284,21 @@ u32 intel_hdcp_get_repeater_ctl(struct intel_digital_port
*intel_dig_port)
case PORT_E:
return HDCP_DDIE_REP_PRESENT | HDCP_DDIE_SHA1_M0;
default:
+ DRM_ERROR("Unknown port %d\n", port);
break;
}
- DRM_ERROR("Unknown port %d\n", port);
return -EINVAL;
}
static
-int intel_hdcp_validate_v_prime(struct intel_digital_port *intel_dig_port,
+int intel_hdcp_validate_v_prime(struct intel_connector *connector,
const struct intel_hdcp_shim *shim,
u8 *ksv_fifo, u8 num_downstream, u8 *bstatus)
{
+ struct intel_digital_port *intel_dig_port =
[PATCH v9 3/6] drm: Extend I915 mei interface for transcoder info
I915 needs to send the index of the transcoder as per ME FW.
To support this, define enum mei_fw_ddi and add as a member into
the struct hdcp_port_data.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
include/drm/i915_mei_hdcp_interface.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/i915_mei_hdcp_interface.h
b/include/drm/i915_mei_hdcp_interface.h
index a97acf1c9710..0de629bf2f62 100644
--- a/include/drm/i915_mei_hdcp_interface.h
+++ b/include/drm/i915_mei_hdcp_interface.h
@@ -54,9 +54,21 @@ enum mei_fw_ddi {
MEI_DDI_RANGE_END = MEI_DDI_A,
};
+enum mei_fw_tc {
+ MEI_INVALID_TRANSCODER = 0x00, /* Invalid transcoder type */
+ MEI_TC_EDP, /* Transcoder for eDP */
+ MEI_TC_DSI0,/* Transcoder for DSI0 */
+ MEI_TC_DSI1,/* Transcoder for DSI1 */
+ MEI_TC_A = 0x10,/* Transcoder TCA */
+ MEI_TC_B, /* Transcoder TCB */
+ MEI_TC_C, /* Transcoder TCC */
+ MEI_TC_D/* Transcoder TCD */
+};
+
/**
* struct hdcp_port_data - intel specific HDCP port data
* @fw_ddi: ddi index as per ME FW
+ * @fw_tc: transcoder index as per ME FW
* @port_type: HDCP port type as per ME FW classification
* @protocol: HDCP adaptation as per ME FW
* @k: No of streams transmitted on a port. Only on DP MST this is != 1
@@ -69,6 +81,7 @@ enum mei_fw_ddi {
*/
struct hdcp_port_data {
enum mei_fw_ddi fw_ddi;
+ enum mei_fw_tc fw_tc;
u8 port_type;
u8 protocol;
u16 k;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 1/6] drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
I915 converts it's port value into ddi index defiend by ME FW
and pass it as a member of hdcp_port_data structure.
Hence expose the enum mei_fw_ddi to I915 through
i915_mei_interface.h.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 15 +-
drivers/misc/mei/hdcp/mei_hdcp.c | 34 ---
drivers/misc/mei/hdcp/mei_hdcp.h | 12
include/drm/i915_mei_hdcp_interface.h | 16 +--
4 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 6ec5ceeab601..534832f435dc 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1749,13 +1749,26 @@ static const struct component_ops
i915_hdcp_component_ops = {
.unbind = i915_hdcp_component_unbind,
};
+static inline
+enum mei_fw_ddi intel_get_mei_fw_ddi_index(enum port port)
+{
+ switch (port) {
+ case PORT_A:
+ return MEI_DDI_A;
+ case PORT_B ... PORT_F:
+ return (enum mei_fw_ddi)port;
+ default:
+ return MEI_DDI_INVALID_PORT;
+ }
+}
+
static inline int initialize_hdcp_port_data(struct intel_connector *connector,
const struct intel_hdcp_shim *shim)
{
struct intel_hdcp *hdcp = >hdcp;
struct hdcp_port_data *data = >port_data;
- data->port = connector->encoder->port;
+ data->fw_ddi = intel_get_mei_fw_ddi_index(connector->encoder->port);
data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
data->protocol = (u8)shim->protocol;
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index c681f6fab342..3638c77eba26 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -27,18 +27,6 @@
#include "mei_hdcp.h"
-static inline u8 mei_get_ddi_index(enum port port)
-{
- switch (port) {
- case PORT_A:
- return MEI_DDI_A;
- case PORT_B ... PORT_F:
- return (u8)port;
- default:
- return MEI_DDI_INVALID_PORT;
- }
-}
-
/**
* mei_hdcp_initiate_session() - Initiate a Wired HDCP2.2 Tx Session in ME FW
* @dev: device corresponding to the mei_cl_device
@@ -69,7 +57,7 @@ mei_hdcp_initiate_session(struct device *dev, struct
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
session_init_in.port.integrated_port_type = data->port_type;
- session_init_in.port.physical_port = mei_get_ddi_index(data->port);
+ session_init_in.port.physical_port = (u8)data->fw_ddi;
session_init_in.protocol = data->protocol;
byte = mei_cldev_send(cldev, (u8 *)_init_in,
@@ -138,7 +126,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
verify_rxcert_in.port.integrated_port_type = data->port_type;
- verify_rxcert_in.port.physical_port = mei_get_ddi_index(data->port);
+ verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
verify_rxcert_in.cert_rx = rx_cert->cert_rx;
memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
@@ -208,7 +196,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
hdcp_port_data *data,
send_hprime_in.header.buffer_len = WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
send_hprime_in.port.integrated_port_type = data->port_type;
- send_hprime_in.port.physical_port = mei_get_ddi_index(data->port);
+ send_hprime_in.port.physical_port = (u8)data->fw_ddi;
memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
HDCP_2_2_H_PRIME_LEN);
@@ -265,7 +253,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
pairing_info_in.port.integrated_port_type = data->port_type;
- pairing_info_in.port.physical_port = mei_get_ddi_index(data->port);
+ pairing_info_in.port.physical_port = (u8)data->fw_ddi;
memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
HDCP_2_2_E_KH_KM_LEN);
@@ -323,7 +311,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
lc_init_in.header.buffer_len = WIRED_CMD_BUF_LEN_INIT_LOCALITY_CHECK_IN;
lc_init_in.port.integrated_port_type = data->port_type;
- lc_init_in.port.physical_port = mei_get_ddi_index(data->port);
+ lc_init_in.port.physical_port = (u8)data->fw_ddi;
byte = mei_cldev_send(cldev, (u8 *)_init_in, sizeof(lc_init_in));
if (byte < 0) {
@@ -378,7 +366,7 @@ mei_hdcp_verify_lprime(struct device *dev, struct
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_VALIDATE_LOCALITY_IN;
[PATCH v9 5/6] drm/i915/hdcp: update current transcoder into intel_hdcp
On gen12+ platforms, HDCP HW is associated to the transcoder.
Hence on every modeset update associated transcoder into the
intel_hdcp of the port.
v2:
s/trans/cpu_transcoder [Jani]
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
.../drm/i915/display/intel_display_types.h| 7 +++
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++
drivers/gpu/drm/i915/display/intel_hdcp.c | 49 ++-
drivers/gpu/drm/i915/display/intel_hdcp.h | 3 ++
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 ++
5 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 449abaea619f..fc85b3e284d4 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -388,6 +388,13 @@ struct intel_hdcp {
wait_queue_head_t cp_irq_queue;
atomic_t cp_irq_count;
int cp_irq_count_cached;
+
+ /*
+* HDCP register access for gen12+ need the transcoder associated.
+* Transcoder attached to the connector could be changed at modeset.
+* Hence caching the transcoder here.
+*/
+ enum transcoder cpu_transcoder;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 921ad0a2f7ba..ba5317d56da7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2244,6 +2244,9 @@ intel_dp_compute_config(struct intel_encoder *encoder,
intel_psr_compute_config(intel_dp, pipe_config);
+ intel_hdcp_transcoder_config(intel_connector,
+pipe_config->cpu_transcoder);
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 534832f435dc..1e5548833e8f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1762,13 +1762,60 @@ enum mei_fw_ddi intel_get_mei_fw_ddi_index(enum port
port)
}
}
+static inline
+enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder cpu_transcoder)
+{
+ switch (cpu_transcoder) {
+ case TRANSCODER_A ... TRANSCODER_D:
+ return (enum mei_fw_tc)(cpu_transcoder | 0x10);
+ case TRANSCODER_EDP:
+ return MEI_TC_EDP;
+ case TRANSCODER_DSI_0:
+ return MEI_TC_DSI0;
+ case TRANSCODER_DSI_1:
+ return MEI_TC_DSI1;
+ default:
+ return MEI_INVALID_TRANSCODER;
+ }
+}
+
+void intel_hdcp_transcoder_config(struct intel_connector *connector,
+ enum transcoder cpu_transcoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = >hdcp;
+
+ if (!hdcp->shim)
+ return;
+
+ if (INTEL_GEN(dev_priv) >= 12) {
+ mutex_lock(>mutex);
+ hdcp->cpu_transcoder = cpu_transcoder;
+ hdcp->port_data.fw_tc = intel_get_mei_fw_tc(cpu_transcoder);
+ mutex_unlock(>mutex);
+ }
+}
+
static inline int initialize_hdcp_port_data(struct intel_connector *connector,
const struct intel_hdcp_shim *shim)
{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
struct hdcp_port_data *data = >port_data;
+ struct intel_crtc *crtc;
+
+ if (INTEL_GEN(dev_priv) < 12) {
+ data->fw_ddi =
+ intel_get_mei_fw_ddi_index(connector->encoder->port);
+ } else {
+ crtc = to_intel_crtc(connector->base.state->crtc);
+ if (crtc) {
+ hdcp->cpu_transcoder = crtc->config->cpu_transcoder;
+ data->fw_tc = intel_get_mei_fw_tc(hdcp->cpu_transcoder);
+ }
+ data->fw_ddi = intel_get_mei_fw_ddi_index(PORT_NONE);
+ }
- data->fw_ddi = intel_get_mei_fw_ddi_index(connector->encoder->port);
data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
data->protocol = (u8)shim->protocol;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 59a2b40405cc..41c1053d9e38 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -16,10 +16,13 @@ struct drm_i915_private;
struct intel_connector;
struct intel_hdcp_shim;
enum port;
+enum transcoder;
void intel_hdcp_atomic_check(struct drm_connector *connector,
struct drm_connector_state *old_state,
struct drm_connector_state *new_state);
+void intel_hdcp_transcoder_config(struct intel_connector *connector,
+ enum transcoder cpu_transcoder);
int
Re: [PATCH v2 14/19] drm: rcar-du: Add support for CMM
Hi Jacopo,
On Thu, Aug 22, 2019 at 03:01:46PM +0200, Jacopo Mondi wrote:
> On Tue, Aug 20, 2019 at 08:34:44PM +0300, Laurent Pinchart wrote:
> > On Sat, Jul 06, 2019 at 04:07:41PM +0200, Jacopo Mondi wrote:
> >> Add a driver for the R-Car Display Unit Color Correction Module.
> >>
> >> In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
> >> to perform image enhancement and color correction.
> >>
> >> Add support for CMM through a driver that supports configuration of
> >> the 1-dimensional LUT table. More advanced CMM feature will be
> >> implemented on top of this basic one.
> >>
> >> Signed-off-by: Jacopo Mondi
> >> ---
> >> drivers/gpu/drm/rcar-du/Kconfig| 7 +
> >> drivers/gpu/drm/rcar-du/Makefile | 1 +
> >> drivers/gpu/drm/rcar-du/rcar_cmm.c | 292 +
> >> drivers/gpu/drm/rcar-du/rcar_cmm.h | 38
> >> 4 files changed, 338 insertions(+)
> >> create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c
> >> create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h
> >>
> >> diff --git a/drivers/gpu/drm/rcar-du/Kconfig
> >> b/drivers/gpu/drm/rcar-du/Kconfig
> >> index 1529849e217e..539d232790d1 100644
> >> --- a/drivers/gpu/drm/rcar-du/Kconfig
> >> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> >> @@ -13,6 +13,13 @@ config DRM_RCAR_DU
> >> Choose this option if you have an R-Car chipset.
> >> If M is selected the module will be called rcar-du-drm.
> >>
> >> +config DRM_RCAR_CMM
> >> + bool "R-Car DU Color Management Module (CMM) Support"
> >> + depends on DRM && OF
> >> + depends on DRM_RCAR_DU
> >> + help
> >> +Enable support for R-Car Color Management Module (CMM).
> >> +
> >> config DRM_RCAR_DW_HDMI
> >>tristate "R-Car DU Gen3 HDMI Encoder Support"
> >>depends on DRM && OF
> >> diff --git a/drivers/gpu/drm/rcar-du/Makefile
> >> b/drivers/gpu/drm/rcar-du/Makefile
> >> index 6c2ed9c46467..4d1187ccc3e5 100644
> >> --- a/drivers/gpu/drm/rcar-du/Makefile
> >> +++ b/drivers/gpu/drm/rcar-du/Makefile
> >> @@ -15,6 +15,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o
> >> \
> >> rcar-du-drm-$(CONFIG_DRM_RCAR_VSP)+= rcar_du_vsp.o
> >> rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
> >>
> >> +obj-$(CONFIG_DRM_RCAR_CMM)+= rcar_cmm.o
> >> obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
> >> obj-$(CONFIG_DRM_RCAR_DW_HDMI)+= rcar_dw_hdmi.o
> >> obj-$(CONFIG_DRM_RCAR_LVDS) += rcar_lvds.o
> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
> >> b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> >> new file mode 100644
> >> index ..76ed3fce2b33
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> >> @@ -0,0 +1,292 @@
> >> +// SPDX-License-Identifier: GPL-2.0+
> >> +/*
> >> + * rcar_cmm.c -- R-Car Display Unit Color Management Module
> >> + *
> >> + * Copyright (C) 2019 Jacopo Mondi
> >> + */
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#include
> >
> > The only thing you need from DRM is the drm_color_lut structure, so I
> > would include drm/drm_mode.h instead.
> >
> >> +#include "rcar_cmm.h"
> >> +
> >> +#define CM2_LUT_CTRL 0x
> >> +#define CM2_LUT_CTRL_EN BIT(0)
> >
> > The datasheet names the bit LUT_EN, I would thus rename the macro to
> > CM2_LUT_CTRL_LUT_EN.
> >
> >> +#define CM2_LUT_TBLA_BASE 0x0600
> >> +#define CM2_LUT_TBLA(__i) (CM2_LUT_TBLA_BASE + (__i) * 4)
> >
> > Similarly, the datasheet names the register CM2_LUT_TBL (and the LUT
> > table B is named CM2_LUT_TBL2), would it make sense to stick to those
> > names ?
>
> Ack on all of these
>
> >> +
> >> +struct rcar_cmm {
> >> + struct clk *clk;
> >> + void __iomem *base;
> >> + bool enabled;
> >> +
> >> + /*
> >> + * restore: LUT restore flag
> >
> > I'm none the wiser after reading this comment :-)
> >
> >> + * running: LUT operating flag
> >> + * size: Number of programmed entries in the LUT table
> >> + * table: Scratch buffer where to store the LUT table entries to be
> >> + *later restored.
> >
> > If you want to document individual fields I propose using kerneldoc
> > syntax.
> >
> > * @lut.restore: ...
> > ...
>
> Yeah, might be a bit of over-documentation here. I don't mind it to be
> honest, but I'm fine if someone wants this to be dropped.
I think it's important to document all fields.
> >> + */
> >> + struct {
> >> + bool restore;
> >> + bool running;
> >> + unsigned int size;
> >> + struct drm_color_lut table[CMM_GAMMA_LUT_SIZE];
> >> + } lut;
> >
> > I think the lut.running field name is a bit confusing, as you modify it
> > based on the lut.enable field in the cmm config structure. I would name
> > it lut.enabled. That could then possibly be confused with cmm.enabled
> > (although in my opinion that's fine), if you're concerned by that I
> > would rename that field to running. It
Re: [PATCH v2 03/19] arm64: renesas: Update 'vsps' property
Hi Jacopo, On Thu, Aug 22, 2019 at 12:00:51PM +0200, Jacopo Mondi wrote: > On Wed, Aug 21, 2019 at 02:16:02PM +0200, Geert Uytterhoeven wrote: > > On Sat, Jul 6, 2019 at 4:07 PM Jacopo Mondi > > wrote: > > > Update the 'vsps' property in the R-Car Gen3 SoC device tree files to > > > match what's in in the documentation example. > > > > double in (no worries, I'll fix that up myself) > > > > > Signed-off-by: Jacopo Mondi > > > > Thanks! > > > > Reviewed-by: Geert Uytterhoeven > > i.e. will queue in renesas-devel for v5.4. > > > > BTW, any plans to add channel indices to the vsps properties in the > > remaining DTS files? > > According to what I read in the parsing 'vsps' proeprties parsing > routine rcar_du_vsps_init(), if the channel index is not specified, it > is defaulted to 0. > >/* Store the VSP pointer and pipe index in the CRTC. */ >rcdu->crtcs[i].vsp = >vsps[j]; >rcdu->crtcs[i].vsp_pipe = cells >= 1 ? args.args[0] : 0; > > The DU bindings documentation does not state that the channel index is > optional, so yes, it might be worth changing this and simplify the > parsing routing to always assume the channel index is there. > > What does Laurent think? Is this worth the effort? I think it's worth the effort to keep the upstream DT sources in sync with the latest bindings, but We can't change the code as we need to ensure backward compatibility. So, yes to the DT update, but the driver should stay unmodified (or should receive a new comment explaining the required backward compatibility if there's not one already). -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/syncobj: Add documentation for timeline syncobj
We've added a set of new APIs to manipulate syncobjs holding timelines of dma_fence. This adds a bit of documentation about how this works. Signed-off-by: Lionel Landwerlin Cc: Christian Koenig Cc: Jason Ekstrand Cc: David(ChunMing) Zhou --- drivers/gpu/drm/drm_syncobj.c | 87 +-- 1 file changed, 74 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c index b5ad73330a48..32ffded6d2c0 100644 --- a/drivers/gpu/drm/drm_syncobj.c +++ b/drivers/gpu/drm/drm_syncobj.c @@ -43,27 +43,66 @@ * - Signal a syncobj (set a trivially signaled fence) * - Wait for a syncobj's fence to appear and be signaled * + * The syncobj userspace API also provides operations to manipulate a syncobj + * in terms of a timeline of struct _fence rather than a single struct + * _fence, through the following operations: + * + * - Signal a given point on the timeline + * - Wait for a given point to appear and/or be signaled + * - Import and export from/to a given point of a timeline + * * At it's core, a syncobj is simply a wrapper around a pointer to a struct * _fence which may be NULL. * When a syncobj is first created, its pointer is either NULL or a pointer * to an already signaled fence depending on whether the * _SYNCOBJ_CREATE_SIGNALED flag is passed to * _IOCTL_SYNCOBJ_CREATE. - * When GPU work which signals a syncobj is enqueued in a DRM driver, - * the syncobj fence is replaced with a fence which will be signaled by the - * completion of that work. - * When GPU work which waits on a syncobj is enqueued in a DRM driver, the - * driver retrieves syncobj's current fence at the time the work is enqueued - * waits on that fence before submitting the work to hardware. - * If the syncobj's fence is NULL, the enqueue operation is expected to fail. - * All manipulation of the syncobjs's fence happens in terms of the current - * fence at the time the ioctl is called by userspace regardless of whether - * that operation is an immediate host-side operation (signal or reset) or - * or an operation which is enqueued in some driver queue. - * _IOCTL_SYNCOBJ_RESET and _IOCTL_SYNCOBJ_SIGNAL can be used to - * manipulate a syncobj from the host by resetting its pointer to NULL or + * + * If the syncobj is considered as a binary (signal/unsignaled) primitive, + * when GPU work is enqueued in a DRM driver to signal the syncobj, the fence + * is replaced with a fence which will be signaled by the completion of that + * work. + * If the syncobj is considered as a timeline primitive, when GPU work is + * enqueued in a DRM driver to signal the a given point of the syncobj, a new + * struct _fence_chain pointing to the DRM driver's fence and also + * pointing to the previous fence that was in the syncobj. The new struct + * _fence_chain fence put into the syncobj will be signaled by completion + * of the DRM driver's work and also any work associated with the fence + * previously in the syncobj. + * + * When GPU work which waits on a syncobj is enqueued in a DRM driver, at the + * time the work is enqueued, it waits on the fence coming from the syncobj + * before submitting the work to hardware. That fence is either : + * + *- The syncobj's current fence if the syncobj is considered as a binary + * primitive. + *- The struct _fence associated with a given point if the syncobj is + * considered as a timeline primitive. + * + * If the syncobj's fence is NULL or not present in the syncobj's timeline, + * the enqueue operation is expected to fail. + * + * With binary syncobj, all manipulation of the syncobjs's fence happens in + * terms of the current fence at the time the ioctl is called by userspace + * regardless of whether that operation is an immediate host-side operation + * (signal or reset) or or an operation which is enqueued in some driver + * queue. _IOCTL_SYNCOBJ_RESET and _IOCTL_SYNCOBJ_SIGNAL can be used + * to manipulate a syncobj from the host by resetting its pointer to NULL or * setting its pointer to a fence which is already signaled. * + * With timeline syncobj, all manipulation of the timeline fences happens in + * terms of the fence referred to in the timeline. See + * dma_fence_chain_find_seqno() to see how a given point is found in the + * timeline. + * + * Note that applications should be careful to always use timeline set of + * ioctl() when dealing with syncobj considered as timeline. Using a binary + * set of ioctl() with a syncobj considered as timeline could result incorrect + * synchronization. The use of binary syncobj is supported through the + * timeline set of ioctl() by using a point value of 0, this will reproduce + * the behavior of the binary set of ioctl() (for example replace the + * syncobj's fence when signaling). + * * * Host-side wait on syncobjs * -- @@ -87,6 +126,16 @@ * synchronize between the two. * This requirement is inherited from the
