Re: [PATCH 2/2] drm: Revert syncobj timeline changes.
On 2018年11月12日 18:48, Chris Wilson wrote:
Quoting Christian König (2018-11-12 10:16:01)
Am 09.11.18 um 23:26 schrieb Eric Anholt:
Eric Anholt writes:
[ Unknown signature status ]
zhoucm1 writes:
On 2018年11月09日 00:52, Christian König wrote:
Am 08.11.18 um 17:07 schrieb Koenig, Christian:
Am 08.11.18 um 17:04 schrieb Eric Anholt:
Daniel suggested I submit this, since we're still
seeing regressions
from it. This is a revert to before 48197bc564c7
("drm: add syncobj
timeline support v9") and its followon fixes.
This is a harmless false positive from lockdep, Chouming
and I are
already working on a fix.
On the other hand we had enough trouble with that patch, so if
it
really bothers you feel free to add my Acked-by: Christian
König
and push it.
NAK, please no, I don't think this needed, the Warning totally
isn't
related to syncobj timeline, but fence-array implementation flaw,
just
exposed by syncobj.
In addition, Christian already has a fix for this Warning, I've
tested.
Please Christian send to public review.
I backed out my revert of #2 (#1 still necessary) after adding the
lockdep regression fix, and now my CTS run got oomkilled after just a
few hours, with these notable lines in the unreclaimable slab info
list:
[ 6314.373099] drm_sched_fence69095KB 69095KB
[ 6314.373653] kmemleak_object 428249KB 428384KB
[ 6314.373736] kmalloc-262144 256KB256KB
[ 6314.373743] kmalloc-131072 128KB128KB
[ 6314.373750] kmalloc-65536 64KB 64KB
[ 6314.373756] kmalloc-32768 1472KB 1728KB
[ 6314.373763] kmalloc-16384 64KB 64KB
[ 6314.373770] kmalloc-8192 208KB208KB
[ 6314.373778] kmalloc-40962408KB 2408KB
[ 6314.373784] kmalloc-2048 288KB336KB
[ 6314.373792] kmalloc-10241457KB 1512KB
[ 6314.373800] kmalloc-512 854KB 1048KB
[ 6314.373808] kmalloc-256 188KB268KB
[ 6314.373817] kmalloc-19269141KB 69142KB
[ 6314.373824] kmalloc-64 47703KB 47704KB
[ 6314.373886] kmalloc-12846396KB 46396KB
[ 6314.373894] kmem_cache31KB 35KB
No results from kmemleak, though.
OK, it looks like the #2 revert probably isn't related to the OOM issue.
Running a single job on otherwise unused DRM, watching /proc/slabinfo
every second for drm_sched_fence, I get:
drm_sched_fence0 0192 211 : tunables 32 168
: slabdata 0 0 0 : globalstat 0 0 000
0000 : cpustat 0 0 0 0
drm_sched_fence 16 21192 211 : tunables 32 168
: slabdata 1 1 0 : globalstat 16 16 100
0000 : cpustat 5 1 6 0
drm_sched_fence 13 21192 211 : tunables 32 168
: slabdata 1 1 0 : globalstat 16 16 100
0000 : cpustat 5 1 6 0
drm_sched_fence6 21192 211 : tunables 32 168
: slabdata 1 1 0 : globalstat 16 16 100
0000 : cpustat 5 1 6 0
drm_sched_fence4 21192 211 : tunables 32 168
: slabdata 1 1 0 : globalstat 16 16 100
0000 : cpustat 5 1 6 0
drm_sched_fence2 21192 211 : tunables 32 168
: slabdata 1 1 0 : globalstat 16 16 100
0000 : cpustat 5 1 6 0
drm_sched_fence0 21192 211 : tunables 32 168
: slabdata 0 1 0 : globalstat 16 16 100
0000 : cpustat 5 1 6 0
So we generate a ton of fences, and I guess free them slowly because of
RCU? And presumably kmemleak was sucking up lots of memory because of
how many of these objects were laying around.
That is certainly possible. Another possibility is that we don't drop the
reference in dma-fence-array early enough.
E.g. the dma-fence-array will keep the reference to its fences until it is
destroyed, which is a bit late when you chain multiple dma-fence-array objects
together.
[PATCH AUTOSEL 4.14 13/26] drm/edid: Add 6 bpc quirk for BOE panel.
From: "Lee, Shawn C"
[ Upstream commit 922dceff8dc1fb4dafc9af78139ba65671408103 ]
BOE panel (ID: 0x0771) that reports "DFP 1.x compliant TMDS".
But it's 6bpc panel only instead of 8 bpc.
Add panel ID to edid quirk list and set 6 bpc as default to
work around this issue.
Cc: Jani Nikula
Cc: Maarten Lankhorst
Cc: Gustavo Padovan
Cc: Cooper Chiou
Signed-off-by: Lee, Shawn C >
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/1540792173-7288-1-git-send-email-shawn.c@intel.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d1191ebed072..ed01e3aae0e8 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -120,6 +120,9 @@ static const struct edid_quirk {
/* SDC panel of Lenovo B50-80 reports 8 bpc, but is a 6 bpc panel */
{ "SDC", 0x3652, EDID_QUIRK_FORCE_6BPC },
+ /* BOE model 0x0771 reports 8 bpc, but is a 6 bpc panel */
+ { "BOE", 0x0771, EDID_QUIRK_FORCE_6BPC },
+
/* Belinea 10 15 55 */
{ "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
{ "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 08/17] drm/edid: Add 6 bpc quirk for BOE panel.
From: "Lee, Shawn C"
[ Upstream commit 922dceff8dc1fb4dafc9af78139ba65671408103 ]
BOE panel (ID: 0x0771) that reports "DFP 1.x compliant TMDS".
But it's 6bpc panel only instead of 8 bpc.
Add panel ID to edid quirk list and set 6 bpc as default to
work around this issue.
Cc: Jani Nikula
Cc: Maarten Lankhorst
Cc: Gustavo Padovan
Cc: Cooper Chiou
Signed-off-by: Lee, Shawn C >
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/1540792173-7288-1-git-send-email-shawn.c@intel.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 83d2f43b5a2f..c93dcfedc219 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -116,6 +116,9 @@ static const struct edid_quirk {
/* SDC panel of Lenovo B50-80 reports 8 bpc, but is a 6 bpc panel */
{ "SDC", 0x3652, EDID_QUIRK_FORCE_6BPC },
+ /* BOE model 0x0771 reports 8 bpc, but is a 6 bpc panel */
+ { "BOE", 0x0771, EDID_QUIRK_FORCE_6BPC },
+
/* Belinea 10 15 55 */
{ "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
{ "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: Revert syncobj timeline changes.
On 2018年11月12日 18:16, Christian König wrote:
Am 09.11.18 um 23:26 schrieb Eric Anholt:
Eric Anholt writes:
[ Unknown signature status ]
zhoucm1 writes:
On 2018年11月09日 00:52, Christian König wrote:
Am 08.11.18 um 17:07 schrieb Koenig, Christian:
Am 08.11.18 um 17:04 schrieb Eric Anholt:
Daniel suggested I submit this, since we're still seeing regressions
from it. This is a revert to before 48197bc564c7 ("drm: add syncobj
timeline support v9") and its followon fixes.
This is a harmless false positive from lockdep, Chouming and I are
already working on a fix.
On the other hand we had enough trouble with that patch, so if it
really bothers you feel free to add my Acked-by: Christian König
and push it.
NAK, please no, I don't think this needed, the Warning totally isn't
related to syncobj timeline, but fence-array implementation flaw, just
exposed by syncobj.
In addition, Christian already has a fix for this Warning, I've tested.
Please Christian send to public review.
I backed out my revert of #2 (#1 still necessary) after adding the
lockdep regression fix, and now my CTS run got oomkilled after just a
few hours, with these notable lines in the unreclaimable slab info list:
[ 6314.373099] drm_sched_fence69095KB 69095KB
[ 6314.373653] kmemleak_object 428249KB 428384KB
[ 6314.373736] kmalloc-262144 256KB256KB
[ 6314.373743] kmalloc-131072 128KB128KB
[ 6314.373750] kmalloc-65536 64KB 64KB
[ 6314.373756] kmalloc-32768 1472KB 1728KB
[ 6314.373763] kmalloc-16384 64KB 64KB
[ 6314.373770] kmalloc-8192 208KB208KB
[ 6314.373778] kmalloc-40962408KB 2408KB
[ 6314.373784] kmalloc-2048 288KB336KB
[ 6314.373792] kmalloc-10241457KB 1512KB
[ 6314.373800] kmalloc-512 854KB 1048KB
[ 6314.373808] kmalloc-256 188KB268KB
[ 6314.373817] kmalloc-19269141KB 69142KB
[ 6314.373824] kmalloc-64 47703KB 47704KB
[ 6314.373886] kmalloc-12846396KB 46396KB
[ 6314.373894] kmem_cache31KB 35KB
No results from kmemleak, though.
OK, it looks like the #2 revert probably isn't related to the OOM issue.
Running a single job on otherwise unused DRM, watching /proc/slabinfo
every second for drm_sched_fence, I get:
drm_sched_fence0 0192 211 : tunables 32 168 :
slabdata 0 0 0 : globalstat 0 0 0000
000 : cpustat 0 0 0 0
drm_sched_fence 16 21192 211 : tunables 32 168 :
slabdata 1 1 0 : globalstat 16 16 1000
000 : cpustat 5 1 6 0
drm_sched_fence 13 21192 211 : tunables 32 168 :
slabdata 1 1 0 : globalstat 16 16 1000
000 : cpustat 5 1 6 0
drm_sched_fence6 21192 211 : tunables 32 168 :
slabdata 1 1 0 : globalstat 16 16 1000
000 : cpustat 5 1 6 0
drm_sched_fence4 21192 211 : tunables 32 168 :
slabdata 1 1 0 : globalstat 16 16 1000
000 : cpustat 5 1 6 0
drm_sched_fence2 21192 211 : tunables 32 168 :
slabdata 1 1 0 : globalstat 16 16 1000
000 : cpustat 5 1 6 0
drm_sched_fence0 21192 211 : tunables 32 168 :
slabdata 0 1 0 : globalstat 16 16 1000
000 : cpustat 5 1 6 0
So we generate a ton of fences, and I guess free them slowly because of
RCU? And presumably kmemleak was sucking up lots of memory because of
how many of these objects were laying around.
Hi Eric,
Thanks for testing, I checked the code, we could forget signal
fence-array immediately after many reviews without callback for
fence-array, everything is waiting fence_wait or syncobj free, that's
why you see "free them slowly".
Maybe we just need one line change as attahced, Could you please have a
try with it on your tests?
btw, I also didn't find there is fence-leak, or you can point me.
Thanks,
David
That is certainly possible. Another possibility is that we don't drop
the reference in dma-fence-array early enough.
E.g. the dma-fence-array will keep the reference to its fences until
it is destroyed, which is a bit late when you chain multiple
dma-fence-array objects together.
David can you take a look at this and propose a fix? That would
probably be good to have fixed in dma-fence-array separately to the
timeline work.
Thanks,
Christian.
Re: [PATCH 04/12] drm/msm: dpu: Don't use power_event for vbif_init_memtypes
On 2018-11-12 11:42, Sean Paul wrote:
From: Sean Paul
power_events are only used for pm_runtime, and that's all handled in
dpu_kms. So just call vbif_init_memtypes at the correct times.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 21 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 -
2 files changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 23094d108e81..ae2bbaae923d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -651,10 +651,6 @@ static void _dpu_kms_hw_destroy(struct dpu_kms
*dpu_kms)
dpu_hw_intr_destroy(dpu_kms->hw_intr);
dpu_kms->hw_intr = NULL;
- if (dpu_kms->power_event)
- dpu_power_handle_unregister_event(
- _kms->phandle, dpu_kms->power_event);
-
/* safe to call these more than once during shutdown */
_dpu_debugfs_destroy(dpu_kms);
_dpu_kms_mmu_destroy(dpu_kms);
@@ -832,16 +828,6 @@ u64 dpu_kms_get_clk_rate(struct dpu_kms *dpu_kms,
char *clock_name)
return clk_get_rate(clk->clk);
}
-static void dpu_kms_handle_power_event(u32 event_type, void *usr)
-{
- struct dpu_kms *dpu_kms = usr;
-
- if (!dpu_kms)
- return;
-
- dpu_vbif_init_memtypes(dpu_kms);
-}
-
static int dpu_kms_hw_init(struct msm_kms *kms)
{
struct dpu_kms *dpu_kms;
@@ -1015,10 +1001,7 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
/*
* Handle (re)initializations during power enable
*/
Is this comment valid anymore?
- dpu_kms_handle_power_event(DPU_POWER_EVENT_ENABLE, dpu_kms);
- dpu_kms->power_event = dpu_power_handle_register_event(
- _kms->phandle, DPU_POWER_EVENT_ENABLE,
- dpu_kms_handle_power_event, dpu_kms, "kms");
+ dpu_vbif_init_memtypes(dpu_kms);
pm_runtime_put_sync(_kms->pdev->dev);
@@ -1172,6 +1155,8 @@ static int __maybe_unused
dpu_runtime_resume(struct
device *dev)
return rc;
}
+ dpu_vbif_init_memtypes(dpu_kms);
+
rc = dpu_power_resource_enable(_kms->phandle, true);
if (rc)
DPU_ERROR("resource enable failed: %d\n", rc);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index f2c78deb0854..5f08be187c86 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -114,7 +114,6 @@ struct dpu_kms {
struct dpu_mdss_cfg *catalog;
struct dpu_power_handle phandle;
- struct dpu_power_event *power_event;
/* directory entry for debugfs */
struct dentry *debugfs_root;
--
Jeykumar S
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/12] drm/msm: dpu: Move DPU_POWER_HANDLE_DBUS_ID to core_perf
On 2018-11-12 11:42, Sean Paul wrote:
From: Sean Paul
It's only used in core_perf, so stick it there (and change the name to
reflect that).
Signed-off-by: Sean Paul
---
Reviewed-by: Jeykumar Sankaran
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 34 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 17 --
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 4 +--
.../gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 13 ---
4 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index ef6dd43f8bec..bffc51e496e7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -95,20 +95,20 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms
*kms,
memset(perf, 0, sizeof(struct dpu_core_perf_params));
if (!dpu_cstate->bw_control) {
- for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
+ for (i = 0; i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
perf->bw_ctl[i] = kms->catalog->perf.max_bw_high *
1000ULL;
perf->max_per_pipe_ib[i] = perf->bw_ctl[i];
}
perf->core_clk_rate = kms->perf.max_core_clk_rate;
} else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
- for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
+ for (i = 0; i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
perf->bw_ctl[i] = 0;
perf->max_per_pipe_ib[i] = 0;
}
perf->core_clk_rate = 0;
} else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED) {
- for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
+ for (i = 0; i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
perf->bw_ctl[i] = kms->perf.fix_core_ab_vote;
perf->max_per_pipe_ib[i] =
kms->perf.fix_core_ib_vote;
}
@@ -118,12 +118,12 @@ static void _dpu_core_perf_calc_crtc(struct
dpu_kms
*kms,
DPU_DEBUG(
"crtc=%d clk_rate=%llu core_ib=%llu core_ab=%llu
llcc_ib=%llu llcc_ab=%llu mem_ib=%llu mem_ab=%llu\n",
crtc->base.id, perf->core_clk_rate,
-
perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_MNOC],
- perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_MNOC],
-
perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_LLCC],
- perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_LLCC],
-
perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_EBI],
- perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_EBI]);
+
perf->max_per_pipe_ib[DPU_CORE_PERF_DATA_BUS_ID_MNOC],
+ perf->bw_ctl[DPU_CORE_PERF_DATA_BUS_ID_MNOC],
+
perf->max_per_pipe_ib[DPU_CORE_PERF_DATA_BUS_ID_LLCC],
+ perf->bw_ctl[DPU_CORE_PERF_DATA_BUS_ID_LLCC],
+
perf->max_per_pipe_ib[DPU_CORE_PERF_DATA_BUS_ID_EBI],
+ perf->bw_ctl[DPU_CORE_PERF_DATA_BUS_ID_EBI]);
}
int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
@@ -158,8 +158,8 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
/* obtain new values */
_dpu_core_perf_calc_crtc(kms, crtc, state, _cstate->new_perf);
- for (i = DPU_POWER_HANDLE_DBUS_ID_MNOC;
- i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
+ for (i = DPU_CORE_PERF_DATA_BUS_ID_MNOC;
+ i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
bw_sum_of_intfs = dpu_cstate->new_perf.bw_ctl[i];
curr_client_type = dpu_crtc_get_client_type(crtc);
@@ -290,7 +290,7 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc
*crtc)
if (kms->perf.enable_bw_release) {
trace_dpu_cmd_release_bw(crtc->base.id);
DPU_DEBUG("Release BW crtc=%d\n", crtc->base.id);
- for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
+ for (i = 0; i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
dpu_crtc->cur_perf.bw_ctl[i] = 0;
_dpu_core_perf_crtc_update_bus(kms, crtc, i);
}
@@ -367,7 +367,7 @@ int dpu_core_perf_crtc_update(struct drm_crtc
*crtc,
new = _cstate->new_perf;
if (_dpu_core_perf_crtc_is_power_on(crtc) && !stop_req) {
- for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
+ for (i = 0; i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
/*
* cases for bus bandwidth update.
* 1. new bandwidth vote - "ab or ib vote" is
higher
@@ -409,13 +409,13 @@ int dpu_core_perf_crtc_update(struct drm_crtc
*crtc,
update_clk = 1;
}
trace_dpu_perf_crtc_update(crtc->base.id,
-
new->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_MNOC],
-
Re: [PATCH 04/12] drm/msm: dpu: Don't use power_event for vbif_init_memtypes
On 2018-11-12 11:42, Sean Paul wrote:
From: Sean Paul
power_events are only used for pm_runtime, and that's all handled in
dpu_kms. So just call vbif_init_memtypes at the correct times.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 21 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 -
2 files changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 23094d108e81..ae2bbaae923d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -651,10 +651,6 @@ static void _dpu_kms_hw_destroy(struct dpu_kms
*dpu_kms)
dpu_hw_intr_destroy(dpu_kms->hw_intr);
dpu_kms->hw_intr = NULL;
- if (dpu_kms->power_event)
- dpu_power_handle_unregister_event(
- _kms->phandle, dpu_kms->power_event);
-
/* safe to call these more than once during shutdown */
_dpu_debugfs_destroy(dpu_kms);
_dpu_kms_mmu_destroy(dpu_kms);
@@ -832,16 +828,6 @@ u64 dpu_kms_get_clk_rate(struct dpu_kms *dpu_kms,
char *clock_name)
return clk_get_rate(clk->clk);
}
-static void dpu_kms_handle_power_event(u32 event_type, void *usr)
-{
- struct dpu_kms *dpu_kms = usr;
-
- if (!dpu_kms)
- return;
-
- dpu_vbif_init_memtypes(dpu_kms);
-}
-
static int dpu_kms_hw_init(struct msm_kms *kms)
{
struct dpu_kms *dpu_kms;
@@ -1015,10 +1001,7 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
/*
* Handle (re)initializations during power enable
*/
- dpu_kms_handle_power_event(DPU_POWER_EVENT_ENABLE, dpu_kms);
- dpu_kms->power_event = dpu_power_handle_register_event(
- _kms->phandle, DPU_POWER_EVENT_ENABLE,
- dpu_kms_handle_power_event, dpu_kms, "kms");
+ dpu_vbif_init_memtypes(dpu_kms);
pm_runtime_put_sync(_kms->pdev->dev);
@@ -1172,6 +1155,8 @@ static int __maybe_unused
dpu_runtime_resume(struct
device *dev)
return rc;
}
+ dpu_vbif_init_memtypes(dpu_kms);
+
rc = dpu_power_resource_enable(_kms->phandle, true);
if (rc)
DPU_ERROR("resource enable failed: %d\n", rc);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index f2c78deb0854..5f08be187c86 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -114,7 +114,6 @@ struct dpu_kms {
struct dpu_mdss_cfg *catalog;
struct dpu_power_handle phandle;
You can get rid of the handle and header inclusions here itself
to clean up KMS from power_handle stuff!
- struct dpu_power_event *power_event;
/* directory entry for debugfs */
struct dentry *debugfs_root;
--
Jeykumar S
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/12] drm/msm: dpu: Include dpu_io_util.h directly in dpu_kms.h
On 2018-11-12 11:42, Sean Paul wrote: From: Sean Paul It's needed for struct dss_module_power, and is currently being pulled in by dpu_power_handle.h Signed-off-by: Sean Paul --- Reviewed-by: Jeykumar Sankaran drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h index 5f08be187c86..4e5acacb3065 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h @@ -29,6 +29,7 @@ #include "dpu_hw_lm.h" #include "dpu_hw_interrupts.h" #include "dpu_hw_top.h" +#include "dpu_io_util.h" #include "dpu_rm.h" #include "dpu_power_handle.h" #include "dpu_irq.h" -- Jeykumar S ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/12] drm/msm: dpu: Remove power_handle from core_perf
On 2018-11-12 11:42, Sean Paul wrote:
From: Sean Paul
It's unused
Signed-off-by: Sean Paul
---
Reviewed-by: Jeykumar Sankaran
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 3 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 5 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 -
3 files changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 22e84b3d7f98..ef6dd43f8bec 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -605,7 +605,6 @@ void dpu_core_perf_destroy(struct dpu_core_perf
*perf)
dpu_core_perf_debugfs_destroy(perf);
perf->max_core_clk_rate = 0;
perf->core_clk = NULL;
- perf->phandle = NULL;
perf->catalog = NULL;
perf->dev = NULL;
}
@@ -613,12 +612,10 @@ void dpu_core_perf_destroy(struct dpu_core_perf
*perf)
int dpu_core_perf_init(struct dpu_core_perf *perf,
struct drm_device *dev,
struct dpu_mdss_cfg *catalog,
- struct dpu_power_handle *phandle,
struct dss_clk *core_clk)
{
perf->dev = dev;
perf->catalog = catalog;
- perf->phandle = phandle;
perf->core_clk = core_clk;
perf->max_core_clk_rate = core_clk->max_rate;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
index fbcbe0c7527a..68b84d85eb8f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
@@ -19,7 +19,6 @@
#include
#include "dpu_hw_catalog.h"
-#include "dpu_power_handle.h"
#defineDPU_PERF_DEFAULT_MAX_CORE_CLK_RATE 41250
@@ -52,7 +51,6 @@ struct dpu_core_perf_tune {
* @dev: Pointer to drm device
* @debugfs_root: top level debug folder
* @catalog: Pointer to catalog configuration
- * @phandle: Pointer to power handler
* @core_clk: Pointer to core clock structure
* @core_clk_rate: current core clock rate
* @max_core_clk_rate: maximum allowable core clock rate
@@ -66,7 +64,6 @@ struct dpu_core_perf {
struct drm_device *dev;
struct dentry *debugfs_root;
struct dpu_mdss_cfg *catalog;
- struct dpu_power_handle *phandle;
struct dss_clk *core_clk;
u64 core_clk_rate;
u64 max_core_clk_rate;
@@ -113,13 +110,11 @@ void dpu_core_perf_destroy(struct dpu_core_perf
*perf);
* @perf: Pointer to core performance context
* @dev: Pointer to drm device
* @catalog: Pointer to catalog
- * @phandle: Pointer to power handle
* @core_clk: pointer to core clock
*/
int dpu_core_perf_init(struct dpu_core_perf *perf,
struct drm_device *dev,
struct dpu_mdss_cfg *catalog,
- struct dpu_power_handle *phandle,
struct dss_clk *core_clk);
/**
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 62a02c606811..bae7e86b2913 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -957,7 +957,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
}
rc = dpu_core_perf_init(_kms->perf, dev, dpu_kms->catalog,
- _kms->phandle,
_dpu_kms_get_clk(dpu_kms, "core"));
if (rc) {
DPU_ERROR("failed to init perf %d\n", rc);
--
Jeykumar S
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/12] drm/msm: dpu: Move crtc runtime resume to encoder
On 2018-11-12 11:42, Sean Paul wrote:
From: Sean Paul
The crtc runtime resume doesn't actually operate on the crtc, but
rather
its encoders. The problem with this is that we need to inspect the crtc
state to get the currently connected encoders. Since runtime resume
isn't guaranteed to be called while holding the modeset locks (although
it sometimes is), this presents a race condition.
Now that we have ->enabled on the virtual encoders, and a lock to
protect it, just call resume on each encoder and only restore the ones
that are enabled.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 24 -
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h| 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 24 +
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 +++---
5 files changed, 15 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index d8f58caf2772..9be24907f8c1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -841,30 +841,6 @@ static struct drm_crtc_state
*dpu_crtc_duplicate_state(struct drm_crtc *crtc)
return >base;
}
-void dpu_crtc_runtime_resume(struct drm_crtc *crtc)
-{
- struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
- struct drm_encoder *encoder;
-
- mutex_lock(_crtc->crtc_lock);
-
- if (!dpu_crtc->enabled)
- goto end;
-
- trace_dpu_crtc_runtime_resume(DRMID(crtc));
-
- /* restore encoder; crtc will be programmed during commit */
- drm_for_each_encoder(encoder, crtc->dev) {
- if (encoder->crtc != crtc)
- continue;
-
- dpu_encoder_virt_restore(encoder);
- }
I agree the patch provides a cleaner solution. Just for the
understanding,
won't the race condition be addressed if we acquire the
modeset lock here and iterate through crtc->state->encoder_mask?
Thanks and Regards,
Jeykumar S.
-
-end:
- mutex_unlock(_crtc->crtc_lock);
-}
-
static void dpu_crtc_disable(struct drm_crtc *crtc)
{
struct dpu_crtc *dpu_crtc;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index 1dca91d1210f..93d21a61a040 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -329,10 +329,4 @@ static inline bool dpu_crtc_is_enabled(struct
drm_crtc *crtc)
return crtc ? crtc->enabled : false;
}
-/**
- * dpu_crtc_runtime_resume - called by the top-level on
pm_runtime_resume
- * @crtc: CRTC to resume
- */
-void dpu_crtc_runtime_resume(struct drm_crtc *crtc);
-
#endif /* _DPU_CRTC_H_ */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 3daa86220d47..d89ac520f7e6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1089,28 +1089,24 @@ static void
_dpu_encoder_virt_enable_helper(struct
drm_encoder *drm_enc)
_dpu_encoder_update_vsync_source(dpu_enc, _enc->disp_info);
}
-void dpu_encoder_virt_restore(struct drm_encoder *drm_enc)
+void dpu_encoder_virt_runtime_resume(struct drm_encoder *drm_enc)
{
- struct dpu_encoder_virt *dpu_enc = NULL;
- int i;
-
- if (!drm_enc) {
- DPU_ERROR("invalid encoder\n");
- return;
- }
- dpu_enc = to_dpu_encoder_virt(drm_enc);
+ struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(drm_enc);
- for (i = 0; i < dpu_enc->num_phys_encs; i++) {
- struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
+ mutex_lock(_enc->enc_lock);
- if (phys && (phys != dpu_enc->cur_master) &&
phys->ops.restore)
- phys->ops.restore(phys);
- }
+ if (!dpu_enc->enabled)
+ goto out;
+ if (dpu_enc->cur_slave && dpu_enc->cur_slave->ops.restore)
+ dpu_enc->cur_slave->ops.restore(dpu_enc->cur_slave);
if (dpu_enc->cur_master && dpu_enc->cur_master->ops.restore)
dpu_enc->cur_master->ops.restore(dpu_enc->cur_master);
_dpu_encoder_virt_enable_helper(drm_enc);
+
+out:
+ mutex_unlock(_enc->enc_lock);
}
static void dpu_encoder_virt_enable(struct drm_encoder *drm_enc)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index 9dbf38f446d9..aa4f135218fa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -126,10 +126,10 @@ int dpu_encoder_wait_for_event(struct drm_encoder
*drm_encoder,
enum dpu_intf_mode dpu_encoder_get_intf_mode(struct drm_encoder
*encoder);
/**
- * dpu_encoder_virt_restore - restore the encoder configs
+ * dpu_encoder_virt_runtime_resume - pm runtime resume the encoder
configs
*
Re: [PATCH 03/12] drm/msm: dpu: Remove dpu_power_client
On 2018-11-12 11:42, Sean Paul wrote:
From: Sean Paul
There's only one client -- core, and it's only used for runtime pm
which
is already refcounted.
Signed-off-by: Sean Paul
Reviewed-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 22 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 -
.../gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 96 +--
.../gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 86 +
4 files changed, 6 insertions(+), 199 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 985c855796ae..23094d108e81 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -676,11 +676,6 @@ static void _dpu_kms_hw_destroy(struct dpu_kms
*dpu_kms)
dpu_hw_catalog_deinit(dpu_kms->catalog);
dpu_kms->catalog = NULL;
- if (dpu_kms->core_client)
- dpu_power_client_destroy(_kms->phandle,
- dpu_kms->core_client);
- dpu_kms->core_client = NULL;
-
if (dpu_kms->vbif[VBIF_NRT])
devm_iounmap(_kms->pdev->dev,
dpu_kms->vbif[VBIF_NRT]);
dpu_kms->vbif[VBIF_NRT] = NULL;
@@ -913,17 +908,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
dpu_kms->reg_dma_len = dpu_iomap_size(dpu_kms->pdev,
"regdma");
}
- dpu_kms->core_client = dpu_power_client_create(_kms->phandle,
- "core");
- if (IS_ERR_OR_NULL(dpu_kms->core_client)) {
- rc = PTR_ERR(dpu_kms->core_client);
- if (!dpu_kms->core_client)
- rc = -EINVAL;
- DPU_ERROR("dpu power client create failed: %d\n", rc);
- dpu_kms->core_client = NULL;
- goto error;
- }
-
pm_runtime_get_sync(_kms->pdev->dev);
_dpu_kms_core_hw_rev_init(dpu_kms);
@@ -1157,8 +1141,7 @@ static int __maybe_unused
dpu_runtime_suspend(struct
device *dev)
return rc;
}
- rc = dpu_power_resource_enable(_kms->phandle,
- dpu_kms->core_client, false);
+ rc = dpu_power_resource_enable(_kms->phandle, false);
if (rc)
DPU_ERROR("resource disable failed: %d\n", rc);
@@ -1189,8 +1172,7 @@ static int __maybe_unused
dpu_runtime_resume(struct
device *dev)
return rc;
}
- rc = dpu_power_resource_enable(_kms->phandle,
- dpu_kms->core_client, true);
+ rc = dpu_power_resource_enable(_kms->phandle, true);
if (rc)
DPU_ERROR("resource enable failed: %d\n", rc);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 2a3625eef6d3..f2c78deb0854 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -114,7 +114,6 @@ struct dpu_kms {
struct dpu_mdss_cfg *catalog;
struct dpu_power_handle phandle;
- struct dpu_power_client *core_client;
struct dpu_power_event *power_event;
/* directory entry for debugfs */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
index 8c6f92aaaf87..8e64f0a52147 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
@@ -35,59 +35,11 @@ static void dpu_power_event_trigger_locked(struct
dpu_power_handle *phandle,
}
}
-struct dpu_power_client *dpu_power_client_create(
- struct dpu_power_handle *phandle, char *client_name)
-{
- struct dpu_power_client *client;
- static u32 id;
-
- if (!client_name || !phandle) {
- pr_err("client name is null or invalid power data\n");
- return ERR_PTR(-EINVAL);
- }
-
- client = kzalloc(sizeof(struct dpu_power_client), GFP_KERNEL);
- if (!client)
- return ERR_PTR(-ENOMEM);
-
- mutex_lock(>phandle_lock);
- strlcpy(client->name, client_name, MAX_CLIENT_NAME_LEN);
- client->usecase_ndx = VOTE_INDEX_DISABLE;
- client->id = id;
- client->active = true;
- pr_debug("client %s created:%pK id :%d\n", client_name,
- client, id);
- id++;
- list_add(>list, >power_client_clist);
- mutex_unlock(>phandle_lock);
-
- return client;
-}
-
-void dpu_power_client_destroy(struct dpu_power_handle *phandle,
- struct dpu_power_client *client)
-{
- if (!client || !phandle) {
- pr_err("reg bus vote: invalid client handle\n");
- } else if (!client->active) {
- pr_err("dpu power deinit already done\n");
- kfree(client);
- } else {
- pr_debug("bus vote client %s destroyed:%pK id:%u\n",
- client->name, client, client->id);
-
Re: [PATCH 08/10] dt-bindings: panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel
On Sat, 3 Nov 2018 15:38:58 +0530, Jagan Teki wrote: > Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel. > > Add dt-bingings for it. > > Signed-off-by: Jagan Teki > --- > .../display/panel/feiyang,fy07024di26a30d.txt | 20 +++ > 1 file changed, 20 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 5/8] dt-bindings: Add bindings for the LeMaker BL035-RGB-002 LCD panel
On Wed, 7 Nov 2018 19:18:40 +0100, Paul Kocialkowski wrote: > This adds the device-tree bindings for the LeMaker BL035-RGB-002 3.5" > QVGA TFT LCD panel, compatible with simple-panel. > > Signed-off-by: Paul Kocialkowski > --- > .../bindings/display/panel/lemaker,bl035-rgb-002.txt | 12 > 1 file changed, 12 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/lemaker,bl035-rgb-002.txt > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: display: amlogic, meson-vpu: Add optional canvas provider node
On Mon, 5 Nov 2018 11:45:07 +0100, Maxime Jourdan wrote: > Allows using the new canvas provider module if present. > > Signed-off-by: Maxime Jourdan > --- > Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/12] drm/msm: dpu: Remove unused trace_dpu_perf_update_bus()
On 2018-11-12 11:42, Sean Paul wrote:
From: Sean Paul
Signed-off-by: Sean Paul
---
Reviewed-by: Jeykumar Sankaran
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 21 -
1 file changed, 21 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
index 0c122e173892..7ab0ba8224f6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
@@ -99,27 +99,6 @@ TRACE_EVENT(dpu_perf_set_ot,
__entry->vbif_idx)
)
-TRACE_EVENT(dpu_perf_update_bus,
- TP_PROTO(int client, unsigned long long ab_quota,
- unsigned long long ib_quota),
- TP_ARGS(client, ab_quota, ib_quota),
- TP_STRUCT__entry(
- __field(int, client)
- __field(u64, ab_quota)
- __field(u64, ib_quota)
- ),
- TP_fast_assign(
- __entry->client = client;
- __entry->ab_quota = ab_quota;
- __entry->ib_quota = ib_quota;
- ),
- TP_printk("Request client:%d ab=%llu ib=%llu",
- __entry->client,
- __entry->ab_quota,
- __entry->ib_quota)
-)
-
-
TRACE_EVENT(dpu_cmd_release_bw,
TP_PROTO(u32 crtc_id),
TP_ARGS(crtc_id),
--
Jeykumar S
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/12] drm/msm: dpu: Add ->enabled to dpu_encoder_virt
On 2018-11-12 11:42, Sean Paul wrote:
From: Sean Paul
Add a bool to dpu_encoder_virt to track whether the encoder is enabled
or not. Repurpose the enc_lock mutex to ensure that it is consistent
with the hw state.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 27 +
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 10a0676d1dcf..3daa86220d47 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -132,6 +132,7 @@ enum dpu_enc_rc_states {
* @base: drm_encoder base class for registration with DRM
* @enc_spinlock: Virtual-Encoder-Wide Spin Lock for IRQ purposes
* @bus_scaling_client:Client handle to the bus scaling interface
+ * @enabled: True if the encoder is active, protected by
enc_lock
* @num_phys_encs: Actual number of physical encoders contained.
* @phys_encs: Container of physical encoders managed.
* @cur_master:Pointer to the current master in this
mode. Optimization
@@ -148,8 +149,8 @@ enum dpu_enc_rc_states {
* all CTL paths
* @crtc_kickoff_cb_data: Opaque user data given to crtc_kickoff_cb
* @debugfs_root: Debug file system root file node
- * @enc_lock: Lock around physical encoder
create/destroy and
- access.
+ * @enc_lock: Lock around physical encoder
+ * create/destroy/enable/disable
* @frame_busy_mask: Bitmask tracking which phys_enc we are
still
* busy processing current command.
* Bit0 = phys_encs[0] etc.
@@ -175,6 +176,8 @@ struct dpu_encoder_virt {
spinlock_t enc_spinlock;
uint32_t bus_scaling_client;
+ bool enabled;
+
unsigned int num_phys_encs;
struct dpu_encoder_phys *phys_encs[MAX_PHYS_ENCODERS_PER_VIRTUAL];
struct dpu_encoder_phys *cur_master;
@@ -1121,6 +1124,8 @@ static void dpu_encoder_virt_enable(struct
drm_encoder *drm_enc)
return;
}
dpu_enc = to_dpu_encoder_virt(drm_enc);
+
+ mutex_lock(_enc->enc_lock);
cur_mode = _enc->base.crtc->state->adjusted_mode;
trace_dpu_enc_enable(DRMID(drm_enc), cur_mode->hdisplay,
@@ -1137,10 +1142,15 @@ static void dpu_encoder_virt_enable(struct
drm_encoder *drm_enc)
if (ret) {
DPU_ERROR_ENC(dpu_enc, "dpu resource control failed:
%d\n",
ret);
- return;
+ goto out;
}
_dpu_encoder_virt_enable_helper(drm_enc);
+
+ dpu_enc->enabled = true;
+
+out:
+ mutex_unlock(_enc->enc_lock);
}
static void dpu_encoder_virt_disable(struct drm_encoder *drm_enc)
@@ -1162,11 +1172,14 @@ static void dpu_encoder_virt_disable(struct
drm_encoder *drm_enc)
return;
}
- mode = _enc->crtc->state->adjusted_mode;
-
dpu_enc = to_dpu_encoder_virt(drm_enc);
DPU_DEBUG_ENC(dpu_enc, "\n");
+ mutex_lock(_enc->enc_lock);
Where do you expect it to go wrong if enable/disable
is not protected using enc_lock?
Thanks and Regards,
Jeykumar S.
+ dpu_enc->enabled = false;
+
+ mode = _enc->crtc->state->adjusted_mode;
+
priv = drm_enc->dev->dev_private;
dpu_kms = to_dpu_kms(priv->kms);
@@ -1200,6 +1213,8 @@ static void dpu_encoder_virt_disable(struct
drm_encoder *drm_enc)
DPU_DEBUG_ENC(dpu_enc, "encoder disabled\n");
dpu_rm_release(_kms->rm, drm_enc);
+
+ mutex_unlock(_enc->enc_lock);
}
static enum dpu_intf dpu_encoder_get_intf(struct dpu_mdss_cfg
*catalog,
@@ -2233,6 +2248,8 @@ struct drm_encoder *dpu_encoder_init(struct
drm_device *dev,
drm_encoder_helper_add(_enc->base, _encoder_helper_funcs);
+ dpu_enc->enabled = false;
+
return _enc->base;
}
--
Jeykumar S
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/12] drm/msm: dpu: Remove dpu_power_handle_get_dbus_name()
On 2018-11-12 11:42, Sean Paul wrote:
From: Sean Paul
It's only used for debugfs, so just output the enum value instead.
Signed-off-by: Sean Paul
---
Reviewed-by: Jeykumar Sankaran
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 14 --
drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 7 ---
3 files changed, 2 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index ed84cf44a222..e09209d6c469 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1381,11 +1381,9 @@ static int dpu_crtc_debugfs_state_show(struct
seq_file *s, void *v)
dpu_crtc->cur_perf.core_clk_rate);
for (i = DPU_POWER_HANDLE_DBUS_ID_MNOC;
i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
- seq_printf(s, "bw_ctl[%s]: %llu\n",
- dpu_power_handle_get_dbus_name(i),
+ seq_printf(s, "bw_ctl[%d]: %llu\n", i,
dpu_crtc->cur_perf.bw_ctl[i]);
- seq_printf(s, "max_per_pipe_ib[%s]: %llu\n",
- dpu_power_handle_get_dbus_name(i),
+ seq_printf(s, "max_per_pipe_ib[%d]: %llu\n", i,
dpu_crtc->cur_perf.max_per_pipe_ib[i]);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
index fc14116789f2..8c6f92aaaf87 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
@@ -24,20 +24,6 @@
#include "dpu_power_handle.h"
#include "dpu_trace.h"
-static const char *data_bus_name[DPU_POWER_HANDLE_DBUS_ID_MAX] = {
- [DPU_POWER_HANDLE_DBUS_ID_MNOC] = "qcom,dpu-data-bus",
- [DPU_POWER_HANDLE_DBUS_ID_LLCC] = "qcom,dpu-llcc-bus",
- [DPU_POWER_HANDLE_DBUS_ID_EBI] = "qcom,dpu-ebi-bus",
-};
-
-const char *dpu_power_handle_get_dbus_name(u32 bus_id)
-{
- if (bus_id < DPU_POWER_HANDLE_DBUS_ID_MAX)
- return data_bus_name[bus_id];
-
- return NULL;
-}
-
static void dpu_power_event_trigger_locked(struct dpu_power_handle
*phandle,
u32 event_type)
{
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
index a65b7a297f21..f627ae28ec68 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
@@ -207,11 +207,4 @@ struct dpu_power_event
*dpu_power_handle_register_event(
void dpu_power_handle_unregister_event(struct dpu_power_handle
*phandle,
struct dpu_power_event *event);
-/**
- * dpu_power_handle_get_dbus_name - get name of given data bus
identifier
- * @bus_id:data bus identifier
- * Return: Pointer to name string if success; NULL otherwise
- */
-const char *dpu_power_handle_get_dbus_name(u32 bus_id);
-
#endif /* _DPU_POWER_HANDLE_H_ */
--
Jeykumar S
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/12] drm/msm: dpu: Handle crtc pm_runtime_resume() directly
On 2018-11-12 11:42, Sean Paul wrote:
From: Sean Paul
Instead of registering through dpu_power_handle just to get a call on
runtime_resume, call the crtc function directly.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 23 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 10 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 8
4 files changed, 20 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index e09209d6c469..c55cb751e2b4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -33,7 +33,6 @@
#include "dpu_plane.h"
#include "dpu_encoder.h"
#include "dpu_vbif.h"
-#include "dpu_power_handle.h"
#include "dpu_core_perf.h"
#include "dpu_trace.h"
@@ -69,8 +68,6 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
if (!crtc)
return;
- dpu_crtc->phandle = NULL;
-
drm_crtc_cleanup(crtc);
mutex_destroy(_crtc->crtc_lock);
kfree(dpu_crtc);
@@ -844,15 +841,17 @@ static struct drm_crtc_state
*dpu_crtc_duplicate_state(struct drm_crtc *crtc)
return >base;
}
-static void dpu_crtc_handle_power_event(u32 event_type, void *arg)
+void dpu_crtc_runtime_resume(struct drm_crtc *crtc)
{
- struct drm_crtc *crtc = arg;
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
struct drm_encoder *encoder;
mutex_lock(_crtc->crtc_lock);
- trace_dpu_crtc_handle_power_event(DRMID(crtc), event_type);
+ if (!dpu_crtc->enabled)
+ goto end;
+
+ trace_dpu_crtc_runtime_resume(DRMID(crtc));
/* restore encoder; crtc will be programmed during commit */
drm_for_each_encoder(encoder, crtc->dev) {
@@ -862,6 +861,7 @@ static void dpu_crtc_handle_power_event(u32
event_type, void *arg)
dpu_encoder_virt_restore(encoder);
}
+end:
mutex_unlock(_crtc->crtc_lock);
}
@@ -917,10 +917,6 @@ static void dpu_crtc_disable(struct drm_crtc
*crtc)
dpu_encoder_register_frame_event_callback(encoder, NULL,
NULL);
}
- if (dpu_crtc->power_event)
- dpu_power_handle_unregister_event(dpu_crtc->phandle,
- dpu_crtc->power_event);
-
memset(cstate->mixers, 0, sizeof(cstate->mixers));
cstate->num_mixers = 0;
@@ -972,11 +968,6 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
/* Enable/restore vblank irq handling */
drm_crtc_vblank_on(crtc);
-
- dpu_crtc->power_event = dpu_power_handle_register_event(
- dpu_crtc->phandle, DPU_POWER_EVENT_ENABLE,
- dpu_crtc_handle_power_event, crtc, dpu_crtc->name);
-
}
struct plane_state {
@@ -1522,8 +1513,6 @@ struct drm_crtc *dpu_crtc_init(struct drm_device
*dev, struct drm_plane *plane,
/* initialize event handling */
spin_lock_init(_crtc->event_lock);
If this is for synchronizing power events, we can get rid of this too.
Thanks,
Jeykumar S.
- dpu_crtc->phandle = >phandle;
-
DPU_DEBUG("%s: successfully initialized crtc\n", dpu_crtc->name);
return crtc;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index 4822602402f9..1dca91d1210f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -151,7 +151,6 @@ struct dpu_crtc_frame_event {
* @event_worker : Event worker queue
* @event_lock: Spinlock around event handling code
* @phandle: Pointer to power handler
- * @power_event : registered power event handle
* @cur_perf : current performance committed to clock/bandwidth
driver
*/
struct dpu_crtc {
@@ -187,9 +186,6 @@ struct dpu_crtc {
/* for handling internal event thread */
spinlock_t event_lock;
- struct dpu_power_handle *phandle;
- struct dpu_power_event *power_event;
-
struct dpu_core_perf_params cur_perf;
struct dpu_crtc_smmu_state_data smmu_state;
@@ -333,4 +329,10 @@ static inline bool dpu_crtc_is_enabled(struct
drm_crtc *crtc)
return crtc ? crtc->enabled : false;
}
+/**
+ * dpu_crtc_runtime_resume - called by the top-level on
pm_runtime_resume
+ * @crtc: CRTC to resume
+ */
+void dpu_crtc_runtime_resume(struct drm_crtc *crtc);
+
#endif /* _DPU_CRTC_H_ */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index ae2bbaae923d..62a02c606811 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1140,6 +1140,7 @@ static int __maybe_unused
dpu_runtime_resume(struct
device *dev)
int rc = -1;
struct platform_device *pdev = to_platform_device(dev);
struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
+ struct drm_crtc *crtc;
Re: [PATCH 09/12] drm/msm: dpu: Remove dpu_power_handle
On 2018-11-12 11:42, Sean Paul wrote:
From: Sean Paul
Now that we don't have any event handlers, remove dpu_power_handle!
Signed-off-by: Sean Paul
Reviewed-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/Makefile | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 11 --
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 3 -
.../gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 136 --
.../gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 113 ---
5 files changed, 264 deletions(-)
delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
diff --git a/drivers/gpu/drm/msm/Makefile
b/drivers/gpu/drm/msm/Makefile
index 19ab521d4c3a..7d02ef3655b5 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -72,7 +72,6 @@ msm-y := \
disp/dpu1/dpu_kms.o \
disp/dpu1/dpu_mdss.o \
disp/dpu1/dpu_plane.o \
- disp/dpu1/dpu_power_handle.o \
disp/dpu1/dpu_rm.o \
disp/dpu1/dpu_vbif.o \
msm_atomic.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index bae7e86b2913..e42685a1d928 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1063,8 +1063,6 @@ static int dpu_bind(struct device *dev, struct
device *master, void *data)
return ret;
}
- dpu_power_resource_init(pdev, _kms->phandle);
-
platform_set_drvdata(pdev, dpu_kms);
msm_kms_init(_kms->base, _funcs);
@@ -1084,7 +1082,6 @@ static void dpu_unbind(struct device *dev, struct
device *master, void *data)
struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
struct dss_module_power *mp = _kms->mp;
- dpu_power_resource_deinit(pdev, _kms->phandle);
msm_dss_put_clk(mp->clk_config, mp->num_clk);
devm_kfree(>dev, mp->clk_config);
mp->num_clk = 0;
@@ -1123,10 +1120,6 @@ static int __maybe_unused
dpu_runtime_suspend(struct device *dev)
return rc;
}
- rc = dpu_power_resource_enable(_kms->phandle, false);
- if (rc)
- DPU_ERROR("resource disable failed: %d\n", rc);
-
rc = msm_dss_enable_clk(mp->clk_config, mp->num_clk, false);
if (rc)
DPU_ERROR("clock disable failed rc:%d\n", rc);
@@ -1160,10 +1153,6 @@ static int __maybe_unused
dpu_runtime_resume(struct
device *dev)
drm_for_each_crtc(crtc, ddev)
dpu_crtc_runtime_resume(crtc);
- rc = dpu_power_resource_enable(_kms->phandle, true);
- if (rc)
- DPU_ERROR("resource enable failed: %d\n", rc);
-
return rc;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 4e5acacb3065..59e18e2d3c59 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -31,7 +31,6 @@
#include "dpu_hw_top.h"
#include "dpu_io_util.h"
#include "dpu_rm.h"
-#include "dpu_power_handle.h"
#include "dpu_irq.h"
#include "dpu_core_perf.h"
@@ -114,8 +113,6 @@ struct dpu_kms {
int core_rev;
struct dpu_mdss_cfg *catalog;
- struct dpu_power_handle phandle;
-
/* directory entry for debugfs */
struct dentry *debugfs_root;
struct dentry *debugfs_danger;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
deleted file mode 100644
index 8e64f0a52147..
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
+++ /dev/null
@@ -1,136 +0,0 @@
-/* Copyright (c) 2014-2018, The Linux Foundation. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or
modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- */
-
-#define pr_fmt(fmt)"[drm:%s:%d]: " fmt, __func__, __LINE__
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "dpu_power_handle.h"
-#include "dpu_trace.h"
-
-static void dpu_power_event_trigger_locked(struct dpu_power_handle
*phandle,
- u32 event_type)
-{
- struct dpu_power_event *event;
-
- list_for_each_entry(event, >event_list, list) {
- if (event->event_type & event_type)
- event->cb_fnc(event_type, event->usr);
- }
-}
-
-void dpu_power_resource_init(struct platform_device *pdev,
- struct dpu_power_handle *phandle)
-{
- phandle->dev = >dev;
-
- INIT_LIST_HEAD(>event_list);
-
- mutex_init(>phandle_lock);
-}
-
-void
Re: [PATCH 10/12] drm/msm: dpu: Fix typo in dpu_encoder
On 2018-11-12 11:42, Sean Paul wrote:
From: Sean Paul
enc_spinlock instead of enc_spin_lock.
Signed-off-by: Sean Paul
---
Reviewed-by: Jeykumar Sankaran
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 82c55efb500f..10a0676d1dcf 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -130,7 +130,7 @@ enum dpu_enc_rc_states {
* Virtual encoder defers as much as possible to the physical
encoders.
* Virtual encoder registers itself with the DRM Framework as the
encoder.
* @base: drm_encoder base class for registration with DRM
- * @enc_spin_lock: Virtual-Encoder-Wide Spin Lock for IRQ purposes
+ * @enc_spinlock: Virtual-Encoder-Wide Spin Lock for IRQ purposes
* @bus_scaling_client:Client handle to the bus scaling interface
* @num_phys_encs: Actual number of physical encoders contained.
* @phys_encs: Container of physical encoders managed.
--
Jeykumar S
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/12] drm/msm: dpu: Don't use power_event for vbif_init_memtypes
On 2018-11-12 17:06, Jeykumar Sankaran wrote:
On 2018-11-12 11:42, Sean Paul wrote:
From: Sean Paul
power_events are only used for pm_runtime, and that's all handled in
dpu_kms. So just call vbif_init_memtypes at the correct times.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 21 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 -
2 files changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 23094d108e81..ae2bbaae923d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -651,10 +651,6 @@ static void _dpu_kms_hw_destroy(struct dpu_kms
*dpu_kms)
dpu_hw_intr_destroy(dpu_kms->hw_intr);
dpu_kms->hw_intr = NULL;
- if (dpu_kms->power_event)
- dpu_power_handle_unregister_event(
- _kms->phandle, dpu_kms->power_event);
-
/* safe to call these more than once during shutdown */
_dpu_debugfs_destroy(dpu_kms);
_dpu_kms_mmu_destroy(dpu_kms);
@@ -832,16 +828,6 @@ u64 dpu_kms_get_clk_rate(struct dpu_kms *dpu_kms,
char *clock_name)
return clk_get_rate(clk->clk);
}
-static void dpu_kms_handle_power_event(u32 event_type, void *usr)
-{
- struct dpu_kms *dpu_kms = usr;
-
- if (!dpu_kms)
- return;
-
- dpu_vbif_init_memtypes(dpu_kms);
-}
-
static int dpu_kms_hw_init(struct msm_kms *kms)
{
struct dpu_kms *dpu_kms;
@@ -1015,10 +1001,7 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
/*
* Handle (re)initializations during power enable
*/
- dpu_kms_handle_power_event(DPU_POWER_EVENT_ENABLE, dpu_kms);
- dpu_kms->power_event = dpu_power_handle_register_event(
- _kms->phandle, DPU_POWER_EVENT_ENABLE,
- dpu_kms_handle_power_event, dpu_kms, "kms");
+ dpu_vbif_init_memtypes(dpu_kms);
pm_runtime_put_sync(_kms->pdev->dev);
@@ -1172,6 +1155,8 @@ static int __maybe_unused
dpu_runtime_resume(struct
device *dev)
return rc;
}
+ dpu_vbif_init_memtypes(dpu_kms);
+
rc = dpu_power_resource_enable(_kms->phandle, true);
if (rc)
DPU_ERROR("resource enable failed: %d\n", rc);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index f2c78deb0854..5f08be187c86 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -114,7 +114,6 @@ struct dpu_kms {
struct dpu_mdss_cfg *catalog;
struct dpu_power_handle phandle;
You can get rid of the handle and header inclusions here itself
to clean up KMS from power_handle stuff!
nvm. I see you are taking care of this in patch 9/12.
- struct dpu_power_event *power_event;
/* directory entry for debugfs */
struct dentry *debugfs_root;
--
Jeykumar S
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dt-bindings: backlight: fix vendor prefix for ArcticSand arcxcnn driver bindings
On Wed, Nov 07, 2018 at 07:10:38AM -0500, Brian Dodge wrote:
> The vendor-prefixes.txt file properly refers to ArcticSand
> as arctic but the driver bindings improperly abbreviated the
> prefix to arc. This was a mistake in the original patch
>
Are there any users and are they okay with this changing?
> Signed-off-by: Brian Dodge
> ---
> .../bindings/leds/backlight/arcxcnn_bl.txt | 20
> ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> index 230abde..dcaa239 100644
> --- a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> +++ b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> @@ -1,8 +1,8 @@
> -Binding for ArcticSand arc2c0608 LED driver
> +Binding for ArcticSand arc family LED drivers
>
> Required properties:
> -- compatible:should be "arc,arc2c0608"
> -- reg: slave address
> +- compatible:"arctic,arc1c0608", "arctic,arc2c0608",
> "arctic,arc3c0845"
Format one per line please.
> +- reg: slave address
>
> Optional properties:
> - default-brightness:brightness value on boot, value from: 0-4095
> @@ -11,19 +11,19 @@ Optional properties:
> - led-sources: List of enabled channels from 0 to 5.
> See Documentation/devicetree/bindings/leds/common.txt
>
> -- arc,led-config-0: setting for register ILED_CONFIG_0
> -- arc,led-config-1: setting for register ILED_CONFIG_1
> -- arc,dim-freq: PWM mode frequence setting (bits [3:0] used)
> -- arc,comp-config: setting for register CONFIG_COMP
> -- arc,filter-config: setting for register FILTER_CONFIG
> -- arc,trim-config: setting for register IMAXTUNE
> +- arctic,led-config-0: setting for register ILED_CONFIG_0
> +- arctic,led-config-1: setting for register ILED_CONFIG_1
> +- arctic,dim-freq: PWM mode frequence setting (bits [3:0] used)
> +- arctic,comp-config:setting for register CONFIG_COMP
> +- arctic,filter-config: setting for register FILTER_CONFIG
> +- arctic,trim-config:setting for register IMAXTUNE
>
> Note: Optional properties not specified will default to values in IC EPROM
>
> Example:
>
> arc2c0608@30 {
> - compatible = "arc,arc2c0608";
> + compatible = "arctic,arc2c0608";
> reg = <0x30>;
> default-brightness = <500>;
> label = "lcd-backlight";
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/8] dt-bindings: Add vendor prefix for LeMaker
On Wed, 7 Nov 2018 19:18:39 +0100, Paul Kocialkowski wrote: > This introduces a new device-tree binding vendor prefix for Shenzhen > LeMaker Technology Co., Ltd. > > This vendor was already in use but it was not documented until now. > > Signed-off-by: Paul Kocialkowski > Reviewed-by: Rob Hering > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 21/44] drm/edid: Add 6 bpc quirk for BOE panel.
From: "Lee, Shawn C"
[ Upstream commit 922dceff8dc1fb4dafc9af78139ba65671408103 ]
BOE panel (ID: 0x0771) that reports "DFP 1.x compliant TMDS".
But it's 6bpc panel only instead of 8 bpc.
Add panel ID to edid quirk list and set 6 bpc as default to
work around this issue.
Cc: Jani Nikula
Cc: Maarten Lankhorst
Cc: Gustavo Padovan
Cc: Cooper Chiou
Signed-off-by: Lee, Shawn C >
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/1540792173-7288-1-git-send-email-shawn.c@intel.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ff0bfc65a8c1..b506e3622b08 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -122,6 +122,9 @@ static const struct edid_quirk {
/* SDC panel of Lenovo B50-80 reports 8 bpc, but is a 6 bpc panel */
{ "SDC", 0x3652, EDID_QUIRK_FORCE_6BPC },
+ /* BOE model 0x0771 reports 8 bpc, but is a 6 bpc panel */
+ { "BOE", 0x0771, EDID_QUIRK_FORCE_6BPC },
+
/* Belinea 10 15 55 */
{ "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
{ "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.18 19/39] drm/edid: Add 6 bpc quirk for BOE panel.
From: "Lee, Shawn C"
[ Upstream commit 922dceff8dc1fb4dafc9af78139ba65671408103 ]
BOE panel (ID: 0x0771) that reports "DFP 1.x compliant TMDS".
But it's 6bpc panel only instead of 8 bpc.
Add panel ID to edid quirk list and set 6 bpc as default to
work around this issue.
Cc: Jani Nikula
Cc: Maarten Lankhorst
Cc: Gustavo Padovan
Cc: Cooper Chiou
Signed-off-by: Lee, Shawn C >
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/1540792173-7288-1-git-send-email-shawn.c@intel.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d74d9a8cde2a..e20bfbc50ade 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -122,6 +122,9 @@ static const struct edid_quirk {
/* SDC panel of Lenovo B50-80 reports 8 bpc, but is a 6 bpc panel */
{ "SDC", 0x3652, EDID_QUIRK_FORCE_6BPC },
+ /* BOE model 0x0771 reports 8 bpc, but is a 6 bpc panel */
+ { "BOE", 0x0771, EDID_QUIRK_FORCE_6BPC },
+
/* Belinea 10 15 55 */
{ "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
{ "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: dsi: Fix missing of_platform_depopulate()
On 06/11/18 17:28, Tony Lindgren wrote:
> We're missing a call to of_platform_depopulate() on errors for dsi.
> Looks like dss is already doing this.
>
> Signed-off-by: Tony Lindgren
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -5429,15 +5429,19 @@ static int dsi_probe(struct platform_device *pdev)
> }
>
> r = of_platform_populate(dev->of_node, NULL, NULL, dev);
> - if (r)
> + if (r) {
> DSSERR("Failed to populate DSI child devices: %d\n", r);
> + goto err_uninit_output;
> + }
>
> r = component_add(>dev, _component_ops);
> if (r)
> - goto err_uninit_output;
> + goto err_of_depopulate;
>
> return 0;
>
> +err_of_depopulate:
> + of_platform_depopulate(dev);
> err_uninit_output:
> dsi_uninit_output(dsi);
> err_pm_disable:
>
Thanks, looks good to me. I'll push to drm-misc-fixes.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/vc4: Force ->x_scaling[1] should never be set to VC4_SCALING_NONE
Hi Boris & Eric.
On Thu, 8 Nov 2018 at 15:12, Eric Anholt wrote:
>
> Boris Brezillon writes:
>
> > On Thu, 08 Nov 2018 06:52:44 -0800
> > Eric Anholt wrote:
> >
> >> Boris Brezillon writes:
> >>
> >> > For the YUV conversion to work properly, ->x_scaling[0,1] should never
> >> > be set to VC4_SCALING_NONE, but vc4_get_scaling_mode() might return
> >> > VC4_SCALING_NONE if the horizontal scaling ratio exactly matches the
> >> > horizontal subsampling factor. Add a test to turn VC4_SCALING_NONE
> >> > into VC4_SCALING_PPF when that happens.
> >> >
> >> > Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.")
> >> > Signed-off-by: Boris Brezillon
> >>
> >> I couldn't find a spec justification for this -- did you have a testcase
> >> that fails?
> >
> > Yep. Just set the downscaling ratio to 0.5 with an NV12 format and
> > you'll hit the issue (I used modetest to do that):
> >
> > # modetest -M vc4 -s 29:1920x1080-60 -P 96@95:1920x1080*0.5@NV12
>
> I found that the firmware has a similar behavior to your patch ("if Y is
> !unity (x or scaling) and UV is unity, set UV to HPPF/VPPF scaling").
> They also select the unity flag after the YUV scaling fixup.
>
> Regardless, if this works, it's got my reviewed-by.
>
> Hopefully we can do some IGT with writeback or chamelium testing all of
> the X/Y scaling options with a focus on hitting these 1:1 ratios. The
> state space is big and the docs are just ambiguous enough.
Great timing as I've hit exactly this when playing back a 1080P video
on a 1080P screen. The colours were very muted in this situation,
whilst playing any other resolution or any RGB format was fine. Took
me a while to realise it wasn't the conversion matrices being set
incorrectly :-/ Applying this patch sorts the problem.
This was on the downstream 4.19 kernel, and the v2 of this set
backported fairly easily. Can I request that for stable? Otherwise we
can cherry-pick it for downstream.
Thanks
Dave
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/4] drm/virtio: add in/out fence support for explicit synchronization
Hey Gerd On 2018-11-12 10:10, Gerd Hoffmann wrote: On Fri, Nov 09, 2018 at 06:13:52PM +0100, Robert Foss wrote: Hey Gerd, On 2018-11-09 11:13, Gerd Hoffmann wrote: On Mon, Nov 05, 2018 at 05:25:05PM +, Emil Velikov wrote: On Mon, 5 Nov 2018 at 11:42, Robert Foss wrote: When the execbuf call receives an in-fence it will get the dma_fence related to that fence fd and wait on it before submitting the draw call. On the out-fence side we get fence returned by the submitted draw call and attach it to a sync_file and send the sync_file fd to userspace. On error -1 is returned to userspace. Signed-off-by: Gustavo Padovan Signed-off-by: Robert Foss Suggested-by: Rob Herring Reviewed-by: Emil Velikov --- Changes since v3: - Move all in_fence handling to the same VIRTGPU_EXECBUF_FENCE_FD_IN block Fwiw my suggestion was to explicitly document whether the IOCTL can support, simultaneously, IN and OUT fence. Yes, that would be good. Code looks like it is supposed to work, but explicitly saying so in the commit message would be nice. On it! Will send out a v5. Also: should we use separate fields for in/out fds? I'm not sure I understand which fields you're referring to. fence_in_fd & fence_out_fd in the ioctl struct (patch #2). I had a look into this and how other drivers are doing it. msm[1] and etnaviv[2] seem to use the same dual-use variable. There may be some value to keeping the virtgpu congruent with the other drivers, but I'll leave the final call up to you. [1] https://github.com/torvalds/linux/blob/master/include/uapi/drm/msm_drm.h#L223 [2] https://github.com/torvalds/linux/blob/master/include/uapi/drm/etnaviv_drm.h#L197 Rob. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: Revert syncobj timeline changes.
Quoting Christian König (2018-11-12 10:16:01)
> Am 09.11.18 um 23:26 schrieb Eric Anholt:
>
> Eric Anholt writes:
>
>
> [ Unknown signature status ]
> zhoucm1 writes:
>
>
> On 2018年11月09日 00:52, Christian König wrote:
>
> Am 08.11.18 um 17:07 schrieb Koenig, Christian:
>
> Am 08.11.18 um 17:04 schrieb Eric Anholt:
>
> Daniel suggested I submit this, since we're still
> seeing regressions
> from it. This is a revert to before 48197bc564c7
> ("drm: add syncobj
> timeline support v9") and its followon fixes.
>
> This is a harmless false positive from lockdep, Chouming
> and I are
> already working on a fix.
>
> On the other hand we had enough trouble with that patch, so
> if it
> really bothers you feel free to add my Acked-by: Christian
> König
> and push it.
>
> NAK, please no, I don't think this needed, the Warning totally
> isn't
> related to syncobj timeline, but fence-array implementation flaw,
> just
> exposed by syncobj.
> In addition, Christian already has a fix for this Warning, I've
> tested.
> Please Christian send to public review.
>
> I backed out my revert of #2 (#1 still necessary) after adding the
> lockdep regression fix, and now my CTS run got oomkilled after just a
> few hours, with these notable lines in the unreclaimable slab info
> list:
>
> [ 6314.373099] drm_sched_fence69095KB 69095KB
> [ 6314.373653] kmemleak_object 428249KB 428384KB
> [ 6314.373736] kmalloc-262144 256KB256KB
> [ 6314.373743] kmalloc-131072 128KB128KB
> [ 6314.373750] kmalloc-65536 64KB 64KB
> [ 6314.373756] kmalloc-32768 1472KB 1728KB
> [ 6314.373763] kmalloc-16384 64KB 64KB
> [ 6314.373770] kmalloc-8192 208KB208KB
> [ 6314.373778] kmalloc-40962408KB 2408KB
> [ 6314.373784] kmalloc-2048 288KB336KB
> [ 6314.373792] kmalloc-10241457KB 1512KB
> [ 6314.373800] kmalloc-512 854KB 1048KB
> [ 6314.373808] kmalloc-256 188KB268KB
> [ 6314.373817] kmalloc-19269141KB 69142KB
> [ 6314.373824] kmalloc-64 47703KB 47704KB
> [ 6314.373886] kmalloc-12846396KB 46396KB
> [ 6314.373894] kmem_cache31KB 35KB
>
> No results from kmemleak, though.
>
> OK, it looks like the #2 revert probably isn't related to the OOM issue.
> Running a single job on otherwise unused DRM, watching /proc/slabinfo
> every second for drm_sched_fence, I get:
>
> drm_sched_fence0 0192 211 : tunables 32 16
> 8 : slabdata 0 0 0 : globalstat 0 0 000
>0000 : cpustat 0 0 0 0
> drm_sched_fence 16 21192 211 : tunables 32 16
> 8 : slabdata 1 1 0 : globalstat 16 16 100
>0000 : cpustat 5 1 6 0
> drm_sched_fence 13 21192 211 : tunables 32 16
> 8 : slabdata 1 1 0 : globalstat 16 16 100
>0000 : cpustat 5 1 6 0
> drm_sched_fence6 21192 211 : tunables 32 16
> 8 : slabdata 1 1 0 : globalstat 16 16 100
>0000 : cpustat 5 1 6 0
> drm_sched_fence4 21192 211 : tunables 32 16
> 8 : slabdata 1 1 0 : globalstat 16 16 100
>0000 : cpustat 5 1 6 0
> drm_sched_fence2 21192 211 : tunables 32 16
> 8 : slabdata 1 1 0 : globalstat 16 16 100
>0000 : cpustat 5 1 6 0
> drm_sched_fence0 21192 211 : tunables 32 16
> 8 : slabdata 0 1 0 : globalstat 16 16 100
>0000 : cpustat 5 1 6 0
>
> So we generate a ton of fences, and I guess free them slowly because of
> RCU? And presumably kmemleak was sucking up lots of memory because of
> how many of these objects were laying around.
>
>
> That is certainly possible. Another possibility is that we don't drop the
> reference in dma-fence-array early enough.
>
> E.g. the dma-fence-array will keep the reference to its fences
Re: [PATCH 2/2] drm: Revert syncobj timeline changes.
On 2018年11月12日 18:16, Christian König wrote:
Am 09.11.18 um 23:26 schrieb Eric Anholt:
Eric Anholt writes:
[ Unknown signature status ]
zhoucm1 writes:
On 2018年11月09日 00:52, Christian König wrote:
Am 08.11.18 um 17:07 schrieb Koenig, Christian:
Am 08.11.18 um 17:04 schrieb Eric Anholt:
Daniel suggested I submit this, since we're still seeing regressions
from it. This is a revert to before 48197bc564c7 ("drm: add syncobj
timeline support v9") and its followon fixes.
This is a harmless false positive from lockdep, Chouming and I are
already working on a fix.
On the other hand we had enough trouble with that patch, so if it
really bothers you feel free to add my Acked-by: Christian König
and push it.
NAK, please no, I don't think this needed, the Warning totally isn't
related to syncobj timeline, but fence-array implementation flaw, just
exposed by syncobj.
In addition, Christian already has a fix for this Warning, I've tested.
Please Christian send to public review.
I backed out my revert of #2 (#1 still necessary) after adding the
lockdep regression fix, and now my CTS run got oomkilled after just a
few hours, with these notable lines in the unreclaimable slab info list:
[ 6314.373099] drm_sched_fence69095KB 69095KB
[ 6314.373653] kmemleak_object 428249KB 428384KB
[ 6314.373736] kmalloc-262144 256KB256KB
[ 6314.373743] kmalloc-131072 128KB128KB
[ 6314.373750] kmalloc-65536 64KB 64KB
[ 6314.373756] kmalloc-32768 1472KB 1728KB
[ 6314.373763] kmalloc-16384 64KB 64KB
[ 6314.373770] kmalloc-8192 208KB208KB
[ 6314.373778] kmalloc-40962408KB 2408KB
[ 6314.373784] kmalloc-2048 288KB336KB
[ 6314.373792] kmalloc-10241457KB 1512KB
[ 6314.373800] kmalloc-512 854KB 1048KB
[ 6314.373808] kmalloc-256 188KB268KB
[ 6314.373817] kmalloc-19269141KB 69142KB
[ 6314.373824] kmalloc-64 47703KB 47704KB
[ 6314.373886] kmalloc-12846396KB 46396KB
[ 6314.373894] kmem_cache31KB 35KB
No results from kmemleak, though.
OK, it looks like the #2 revert probably isn't related to the OOM issue.
Before you judge if it is memleak, to be honest, you can scan it first.
Running a single job on otherwise unused DRM, watching /proc/slabinfo
every second for drm_sched_fence, I get:
drm_sched_fence0 0192 211 : tunables 32 168 :
slabdata 0 0 0 : globalstat 0 0 0000
000 : cpustat 0 0 0 0
drm_sched_fence 16 21192 211 : tunables 32 168 :
slabdata 1 1 0 : globalstat 16 16 1000
000 : cpustat 5 1 6 0
drm_sched_fence 13 21192 211 : tunables 32 168 :
slabdata 1 1 0 : globalstat 16 16 1000
000 : cpustat 5 1 6 0
drm_sched_fence6 21192 211 : tunables 32 168 :
slabdata 1 1 0 : globalstat 16 16 1000
000 : cpustat 5 1 6 0
drm_sched_fence4 21192 211 : tunables 32 168 :
slabdata 1 1 0 : globalstat 16 16 1000
000 : cpustat 5 1 6 0
drm_sched_fence2 21192 211 : tunables 32 168 :
slabdata 1 1 0 : globalstat 16 16 1000
000 : cpustat 5 1 6 0
drm_sched_fence0 21192 211 : tunables 32 168 :
slabdata 0 1 0 : globalstat 16 16 1000
000 : cpustat 5 1 6 0
So we generate a ton of fences, and I guess free them slowly because of
RCU? And presumably kmemleak was sucking up lots of memory because of
how many of these objects were laying around.
That is certainly possible. Another possibility is that we don't drop
the reference in dma-fence-array early enough.
E.g. the dma-fence-array will keep the reference to its fences until
it is destroyed, which is a bit late when you chain multiple
dma-fence-array objects together.
Good point, but need to confirm.
David can you take a look at this and propose a fix? That would
probably be good to have fixed in dma-fence-array separately to the
timeline work.
Yeah, I would find a free time for it.
Thanks,
David Zhou
Thanks,
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
[PATCH] backlight: pwm_bl: fix devicetree parsing with auto-generated brightness tables
From: Heiko Stuebner
Commit 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED linearly
to human eye") made the parse-dt function return early when using an auto-
generated brightness-table, but didn't take into account that some more
settings were handled below the brightness handling, like power-on-delays
and also setting the pdata enable-gpio to -EINVAL.
This surfaces for example in the case of a backlight without any
enable-gpio which then tries to use gpio-0 in error.
Fix this by simply moving the trailing settings above the brightness
handling.
Fixes: 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED linearly to
human eye")
Signed-off-by: Heiko Stuebner
---
drivers/video/backlight/pwm_bl.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index bcd08b41765d..b7b5b31f3824 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -272,6 +272,16 @@ static int pwm_backlight_parse_dt(struct device *dev,
memset(data, 0, sizeof(*data));
+ /*
+* These values are optional and set as 0 by default, the out values
+* are modified only if a valid u32 value can be decoded.
+*/
+ of_property_read_u32(node, "post-pwm-on-delay-ms",
+>post_pwm_on_delay);
+ of_property_read_u32(node, "pwm-off-delay-ms", >pwm_off_delay);
+
+ data->enable_gpio = -EINVAL;
+
/*
* Determine the number of brightness levels, if this property is not
* set a default table of brightness levels will be used.
@@ -384,15 +394,6 @@ static int pwm_backlight_parse_dt(struct device *dev,
data->max_brightness--;
}
- /*
-* These values are optional and set as 0 by default, the out values
-* are modified only if a valid u32 value can be decoded.
-*/
- of_property_read_u32(node, "post-pwm-on-delay-ms",
->post_pwm_on_delay);
- of_property_read_u32(node, "pwm-off-delay-ms", >pwm_off_delay);
-
- data->enable_gpio = -EINVAL;
return 0;
}
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/4] omapdrm: Fix runtime PM issues at module load and unload time
On 10/11/18 13:16, Laurent Pinchart wrote:
> Hello,
>
> This series fixes crashes in the omapdss driver at both load and unload
> time, due to runtime PM problems related to probe deferral. The bugs got
> introduced in v4.20-rc, this should thus be considered as v4.20 fixes.
>
> At the core of the problem comes commit 27d624527d99 ("drm/omap: dss:
> Acquire next dssdev at probe time") which can cause probe deferral for
> the DSS when the encoder and panel modules are not loaded yet. As the
> omapdss module contains drivers for the DSS and all its children, this
> results in the internal encoders being probed before the DSS. Missing
> runtime PM handling around register access then caused imprecise
> external aborts.
>
> Patch 1/4 moves population of the DSS children from arch code to the
> omapdss driver. This prevents the DSS children from being probed before
> the DSS. The change can be considered as a workaround in the sense that
> runtime PM of the DSS children should operate correctly even when the
> DSS probe fail. However, given that reducing the amount of arch code is
> an improvement in itself, I believe the solution to be acceptable.
>
> Patches 2/4 and 3/4 then ensure that the HDMI4 and DSI devices are
> active at bind and probe time respectively, in order to access hardware
> registers there.
>
> Patch 4/4 finally fixes the internal encoders crash in their runtime PM
> handlers by moving DISPC runtime PM state management to omapdrm. This is
> the biggest change compared to v3 that went for a less intrusive (in my
> opinion at least) workaround. As Tomi and Tony were in favour of a real
> fix instead of a workaround, I gave the RFC fix more testing on
> Beagleboard, Pandaboard and AM57xx EVM and concluded it should be safe.
>
> Patch 1/4 touches both the mach-omap2 and omapdss, and has been acked by
> Tony to be merged through the DRM tree.
>
> Laurent Pinchart (4):
> drm/omap: Populate DSS children in omapdss driver
> drm/omap: hdmi4: Ensure the device is active during bind
> drm/omap: dsi: Ensure the device is active during probe
> drm/omap: Move DISPC runtime PM handling to omapdrm
>
> arch/arm/mach-omap2/display.c | 111 +---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 14 ++--
> drivers/gpu/drm/omapdrm/dss/dss.c | 11 ++-
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 37 +++---
> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 27 ---
> drivers/gpu/drm/omapdrm/dss/venc.c | 7 --
> drivers/gpu/drm/omapdrm/omap_crtc.c | 6 ++
> 7 files changed, 83 insertions(+), 130 deletions(-)
Thanks, looks good to me. I'll push to drm-misc-fixes.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] drm/gem: Add drm_gem_object_funcs
Am 10.11.18 um 15:56 schrieb Noralf Trønnes: > This patchset adds a GEM object function table and makes use of it in > the CMA helper. > > This was originally part of a shmem helper series[1] that didn't make > it. Daniel and Christian showed interest in the vtable part so I have > hooked it up to some refactoring in tinydrm in order to have a user. The > tinydrm refactoring is part of a long term plan to get rid of > tinydrm.ko. > > Noralf. > > [1] https://patchwork.freedesktop.org/series/27184/ > > Noralf Trønnes (5): >drm/driver: Add defaults for .gem_prime_export/import callbacks >drm/prime: Add drm_gem_prime_mmap() >drm/gem: Add drm_gem_object_funcs >drm/cma-helper: Add DRM_GEM_CMA_VMAP_DRIVER_OPS >drm/tinydrm: Use DRM_GEM_CMA_VMAP_DRIVER_OPS Acked-by: Christian König for the series. Regards, Christian. > > Documentation/gpu/todo.rst | 13 +++ > drivers/gpu/drm/drm_client.c | 12 +-- > drivers/gpu/drm/drm_gem.c | 109 ++-- > drivers/gpu/drm/drm_gem_cma_helper.c | 86 > drivers/gpu/drm/drm_prime.c| 79 +++ > drivers/gpu/drm/tinydrm/core/tinydrm-core.c| 71 -- > drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 6 ++ > drivers/gpu/drm/tinydrm/hx8357d.c | 4 +- > drivers/gpu/drm/tinydrm/ili9225.c | 5 +- > drivers/gpu/drm/tinydrm/ili9341.c | 4 +- > drivers/gpu/drm/tinydrm/mi0283qt.c | 6 +- > drivers/gpu/drm/tinydrm/mipi-dbi.c | 10 +- > drivers/gpu/drm/tinydrm/repaper.c | 4 +- > drivers/gpu/drm/tinydrm/st7586.c | 5 +- > drivers/gpu/drm/tinydrm/st7735r.c | 4 +- > include/drm/drm_drv.h | 4 + > include/drm/drm_gem.h | 131 > + > include/drm/drm_gem_cma_helper.h | 24 + > include/drm/drm_prime.h| 1 + > include/drm/tinydrm/tinydrm.h | 35 ++- > 20 files changed, 462 insertions(+), 151 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/4] drm/virtio: add in/out fence support for explicit synchronization
On Mon, Nov 12, 2018 at 11:30:57AM +0100, Robert Foss wrote: > Hey Gerd > > On 2018-11-12 10:10, Gerd Hoffmann wrote: > > On Fri, Nov 09, 2018 at 06:13:52PM +0100, Robert Foss wrote: > > > Hey Gerd, > > > > > > On 2018-11-09 11:13, Gerd Hoffmann wrote: > > > > On Mon, Nov 05, 2018 at 05:25:05PM +, Emil Velikov wrote: > > > > > On Mon, 5 Nov 2018 at 11:42, Robert Foss > > > > > wrote: > > > > > > > > > > > > When the execbuf call receives an in-fence it will get the dma_fence > > > > > > related to that fence fd and wait on it before submitting the draw > > > > > > call. > > > > > > > > > > > > On the out-fence side we get fence returned by the submitted draw > > > > > > call > > > > > > and attach it to a sync_file and send the sync_file fd to > > > > > > userspace. On > > > > > > error -1 is returned to userspace. > > > > > > > > > > > > Signed-off-by: Gustavo Padovan > > > > > > Signed-off-by: Robert Foss > > > > > > Suggested-by: Rob Herring > > > > > > Reviewed-by: Emil Velikov > > > > > > --- > > > > > > > > > > > > Changes since v3: > > > > > >- Move all in_fence handling to the same > > > > > > VIRTGPU_EXECBUF_FENCE_FD_IN block > > > > > Fwiw my suggestion was to explicitly document whether the IOCTL can > > > > > support, simultaneously, IN and OUT fence. > > > > > > > > Yes, that would be good. Code looks like it is supposed to work, but > > > > explicitly saying so in the commit message would be nice. > > > > > > On it! Will send out a v5. > > > > > > > > > > > Also: should we use separate fields for in/out fds? > > > > > > I'm not sure I understand which fields you're referring to. > > > > fence_in_fd & fence_out_fd in the ioctl struct (patch #2). > > I had a look into this and how other drivers are doing it. > msm[1] and etnaviv[2] seem to use the same dual-use variable. Ok, lets do it the same way then. What is the status of the userspace side of this? cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201439] Amdgpu: system freeze when waking up from monitor blanking
https://bugzilla.kernel.org/show_bug.cgi?id=201439 fin4...@hotmail.com changed: What|Removed |Added Summary|Amdgpu: system freeze when |Amdgpu: system freeze when |waking up from monitor |waking up from monitor |sleep |blanking -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/4] drm/virtio: add in/out fence support for explicit synchronization
On Fri, Nov 09, 2018 at 06:13:52PM +0100, Robert Foss wrote: > Hey Gerd, > > On 2018-11-09 11:13, Gerd Hoffmann wrote: > > On Mon, Nov 05, 2018 at 05:25:05PM +, Emil Velikov wrote: > > > On Mon, 5 Nov 2018 at 11:42, Robert Foss > > > wrote: > > > > > > > > When the execbuf call receives an in-fence it will get the dma_fence > > > > related to that fence fd and wait on it before submitting the draw call. > > > > > > > > On the out-fence side we get fence returned by the submitted draw call > > > > and attach it to a sync_file and send the sync_file fd to userspace. On > > > > error -1 is returned to userspace. > > > > > > > > Signed-off-by: Gustavo Padovan > > > > Signed-off-by: Robert Foss > > > > Suggested-by: Rob Herring > > > > Reviewed-by: Emil Velikov > > > > --- > > > > > > > > Changes since v3: > > > > - Move all in_fence handling to the same VIRTGPU_EXECBUF_FENCE_FD_IN > > > > block > > > Fwiw my suggestion was to explicitly document whether the IOCTL can > > > support, simultaneously, IN and OUT fence. > > > > Yes, that would be good. Code looks like it is supposed to work, but > > explicitly saying so in the commit message would be nice. > > On it! Will send out a v5. > > > > > Also: should we use separate fields for in/out fds? > > I'm not sure I understand which fields you're referring to. fence_in_fd & fence_out_fd in the ioctl struct (patch #2). cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/vc4: Force ->x_scaling[1] should never be set to VC4_SCALING_NONE
On Mon, 12 Nov 2018 10:20:35 +
Dave Stevenson wrote:
> Hi Boris & Eric.
>
> On Thu, 8 Nov 2018 at 15:12, Eric Anholt wrote:
> >
> > Boris Brezillon writes:
> >
> > > On Thu, 08 Nov 2018 06:52:44 -0800
> > > Eric Anholt wrote:
> > >
> > >> Boris Brezillon writes:
> > >>
> > >> > For the YUV conversion to work properly, ->x_scaling[0,1] should never
> > >> > be set to VC4_SCALING_NONE, but vc4_get_scaling_mode() might return
> > >> > VC4_SCALING_NONE if the horizontal scaling ratio exactly matches the
> > >> > horizontal subsampling factor. Add a test to turn VC4_SCALING_NONE
> > >> > into VC4_SCALING_PPF when that happens.
> > >> >
> > >> > Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.")
> > >> > Signed-off-by: Boris Brezillon
> > >>
> > >> I couldn't find a spec justification for this -- did you have a testcase
> > >> that fails?
> > >
> > > Yep. Just set the downscaling ratio to 0.5 with an NV12 format and
> > > you'll hit the issue (I used modetest to do that):
> > >
> > > # modetest -M vc4 -s 29:1920x1080-60 -P 96@95:1920x1080*0.5@NV12
> >
> > I found that the firmware has a similar behavior to your patch ("if Y is
> > !unity (x or scaling) and UV is unity, set UV to HPPF/VPPF scaling").
> > They also select the unity flag after the YUV scaling fixup.
> >
> > Regardless, if this works, it's got my reviewed-by.
> >
> > Hopefully we can do some IGT with writeback or chamelium testing all of
> > the X/Y scaling options with a focus on hitting these 1:1 ratios. The
> > state space is big and the docs are just ambiguous enough.
>
> Great timing as I've hit exactly this when playing back a 1080P video
> on a 1080P screen. The colours were very muted in this situation,
> whilst playing any other resolution or any RGB format was fine. Took
> me a while to realise it wasn't the conversion matrices being set
> incorrectly :-/ Applying this patch sorts the problem.
> This was on the downstream 4.19 kernel, and the v2 of this set
> backported fairly easily. Can I request that for stable? Otherwise we
> can cherry-pick it for downstream.
Sure.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 17/25] dt-bindings: panel: Add Bananapi S070WV20-CT16 ICN6211 MIPI-DSI to RGB bridge
On 10.11.2018 08:32, Jagan Teki wrote: > On Wed, Nov 7, 2018 at 2:41 PM Andrzej Hajda wrote: >> On 06.11.2018 19:08, Jagan Teki wrote: >>> On Wed, Oct 31, 2018 at 2:45 PM Andrzej Hajda wrote: On 31.10.2018 09:58, Chen-Yu Tsai wrote: > On Wed, Oct 31, 2018 at 4:53 PM Andrzej Hajda wrote: >> On 26.10.2018 16:43, Jagan Teki wrote: >>> Bananapi S070WV20-CT16 ICN6211 is 800x480, 4-lane MIPI-DSI to RGB >>> bridge panel, which is available on same PCB with 24-bit RGB interface. >>> >>> So, this patch adds DSI specific binding details on existing >>> dt-bindings file. >>> >>> Signed-off-by: Jagan Teki >>> --- >>> Changes for v3: >>> - Use existing binding doc and update dsi details >>> Changes for v2: >>> - none >>> >>> .../display/panel/bananapi,s070wv20-ct16.txt | 31 +-- >>> 1 file changed, 29 insertions(+), 2 deletions(-) >>> >>> diff --git >>> a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt >>> >>> b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt >>> index 35bc0c839f49..b7855dc7c66f 100644 >>> --- >>> a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt >>> +++ >>> b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt >>> @@ -1,12 +1,39 @@ >>> Banana Pi 7" (S070WV20-CT16) TFT LCD Panel >>> >>> +S070WV20-CT16 is 7" 800x480 panel connected through a 24-bit RGB >>> interface. >>> + >>> +Depending on the variant, the PCB attached to the panel module either >>> +supports DSI, or DSI + 24-bit RGB. DSI is converted to 24-bit RGB via >>> +an onboard ICN6211 MIPI DSI - RGB bridge chip, then fed to the panel >>> +itself >> As I understand this is display board, which contains 'pure' RGB panel >> S070WV20-CT16 and optionally ICN6211 DSI->RGB bridge. >> These are separate devices, just connected by vendor to simplify its >> assembly. Why don't you create then bridge driver for ICN6211 and RGB >> panel driver for S070WV20-CT16 - it looks more generic. >> Then you can describe both in dts and voila. >> Creating drivers for every combo of devices (panel + bridge), just >> because some vendor sells them together seems incorrect - we have >> devicetree for it. > Rob suggested this, and also the opposite: using the same > "bananapi,s070wv20-ct16" > compatible string for both types of connections, and have the driver deal > with > detecting the bus type. > > The thing about the bridge chip is that there's no available datasheet > that > describes all the parts of the init sequence, in fact none at all. I > managed > to work out some bits, but the others remain a mystery and must be > hard-coded > to match the panel. That would work against having a generic bridge > driver. But it is common for many chips - 1st version of the driver is developed on one platform and it supports only one configuration, if next platform with the same cheap appears the driver is augmented if necessary. >>> At-least few of the commands from panel initialization code, the >>> respective opcode data values are based on panel timings and even >>> clock value is different in DSI. I think it look hard to try bridge >>> driver for these restrictions, do you have any suggestions? >> >> Where do you see an issue? Since panel is RGB it should have no >> initialization sequence (beside regulator/gpio power on/off), so the >> only thing to do is to figure out which regulators/gpios belongs to >> which component - with publicly available specs it should be doable. >> >> The whole initialization sequence is for the bridge, so you put it into >> bridge driver, for starters it can be hardcoded. > Yes, I understand we can move regulators/gpio setup separately and > though we hardcode the init sequence there is difference in clock for > DSI(which I mentioned in previous mail). DSI panel can't work with > clock used by RGB panel-simple. If you mean pixel clock from timings in next patch it seems incorrect. Pixel clock should be always htotal * vtotal * vrefresh, in case of drm_display_mode result should be divided by 1000 (as .clock is in kHz). With timings provided there you have: 928*525*60 = 29232000 So pixel clock should be 29232, if other timings are correct. DSI clock is a different thing and it is private thing of DSI bridge/panel it should not be exposed via drm_display_mode. Regards Andrzej > >> Then you can: >> >> 1. Try to find other users of this ICN6211 chip and compare >> initialization sequences to guess purpose of registers. >> >> 2. Try to get specs of the chip (ask vendor, distributor, grep Internet). > As we mentioned (even Chen-Yu), we are unable to find the proper spec > for this panel, all we taken reference from AW BSP code. > >> 3. Do nothing
[PATCH xf86-video-intel v8 0/2] Added AYUV format support
sna/gen9+: Added AYUV format support for textured and sprite video adapters. Split out wm_kernel from the sna_composite_op flags Stanislav Lisovskiy (2): sna/gen9+: Split out wm_kernel from the sna_composite_op flags sna: Added AYUV format support for textured and sprite video adapters. src/render_program/Makefile.am| 2 + .../exa_wm_src_sample_argb_ayuv.g8a | 76 +++ .../exa_wm_src_sample_argb_ayuv.g8b | 8 ++ src/sna/gen9_render.c | 59 ++ src/sna/sna_render.h | 4 + src/sna/sna_video.c | 72 +- src/sna/sna_video.h | 20 + src/sna/sna_video_sprite.c| 20 - src/sna/sna_video_textured.c | 19 + 9 files changed, 262 insertions(+), 18 deletions(-) create mode 100644 src/render_program/exa_wm_src_sample_argb_ayuv.g8a create mode 100644 src/render_program/exa_wm_src_sample_argb_ayuv.g8b -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH xf86-video-intel v8 1/2] sna/gen9+: Split out wm_kernel from the sna_composite_op flags
With the extra video kernels we already ran out of bits in
the flags. To tackle that let's just split out the
wm_kernel to its own thing.
Signed-off-by: Stanislav Lisovskiy
---
src/sna/gen9_render.c | 35 ++-
src/sna/sna_render.h | 1 +
2 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/src/sna/gen9_render.c b/src/sna/gen9_render.c
index 505b98af..eb22b642 100644
--- a/src/sna/gen9_render.c
+++ b/src/sna/gen9_render.c
@@ -226,19 +226,18 @@ static const struct blendinfo {
#define COPY_SAMPLER 0
#define COPY_VERTEX VERTEX_2s2s
-#define COPY_FLAGS(a) GEN9_SET_FLAGS(COPY_SAMPLER, (a) == GXcopy ? NO_BLEND :
CLEAR, GEN9_WM_KERNEL_NOMASK, COPY_VERTEX)
+#define COPY_FLAGS(a) GEN9_SET_FLAGS(COPY_SAMPLER, (a) == GXcopy ? NO_BLEND :
CLEAR, COPY_VERTEX)
#define FILL_SAMPLER 1
#define FILL_VERTEX VERTEX_2s2s
-#define FILL_FLAGS(op, format) GEN9_SET_FLAGS(FILL_SAMPLER,
gen9_get_blend((op), false, (format)), GEN9_WM_KERNEL_NOMASK, FILL_VERTEX)
-#define FILL_FLAGS_NOBLEND GEN9_SET_FLAGS(FILL_SAMPLER, NO_BLEND,
GEN9_WM_KERNEL_NOMASK, FILL_VERTEX)
+#define FILL_FLAGS(op, format) GEN9_SET_FLAGS(FILL_SAMPLER,
gen9_get_blend((op), false, (format)), FILL_VERTEX)
+#define FILL_FLAGS_NOBLEND GEN9_SET_FLAGS(FILL_SAMPLER, NO_BLEND, FILL_VERTEX)
#define GEN9_SAMPLER(f) (((f) >> 20) & 0xfff)
#define GEN9_BLEND(f) (((f) >> 4) & 0x7ff)
#define GEN9_READS_DST(f) (((f) >> 15) & 1)
-#define GEN9_KERNEL(f) (((f) >> 16) & 0xf)
#define GEN9_VERTEX(f) (((f) >> 0) & 0xf)
-#define GEN9_SET_FLAGS(S, B, K, V) ((S) << 20 | (K) << 16 | (B) | (V))
+#define GEN9_SET_FLAGS(S, B, V) ((S) << 20 | (B) | (V))
#define OUT_BATCH(v) batch_emit(sna, v)
#define OUT_BATCH64(v) batch_emit64(sna, v)
@@ -1349,7 +1348,7 @@ gen9_emit_state(struct sna *sna,
gen9_emit_cc(sna, GEN9_BLEND(op->u.gen9.flags));
gen9_emit_sampler(sna, GEN9_SAMPLER(op->u.gen9.flags));
gen9_emit_sf(sna, GEN9_VERTEX(op->u.gen9.flags) >> 2);
- gen9_emit_wm(sna, GEN9_KERNEL(op->u.gen9.flags));
+ gen9_emit_wm(sna, op->u.gen9.wm_kernel);
gen9_emit_vertex_elements(sna, op);
gen9_emit_binding_table(sna, wm_binding_table);
@@ -1618,7 +1617,7 @@ static int gen9_get_rectangles__flush(struct sna *sna,
if (gen9_magic_ca_pass(sna, op)) {
gen9_emit_pipe_invalidate(sna);
gen9_emit_cc(sna, GEN9_BLEND(op->u.gen9.flags));
- gen9_emit_wm(sna, GEN9_KERNEL(op->u.gen9.flags));
+ gen9_emit_wm(sna, op->u.gen9.wm_kernel);
}
}
@@ -2548,11 +2547,11 @@ gen9_render_composite(struct sna *sna,
gen9_get_blend(tmp->op,
tmp->has_component_alpha,
tmp->dst.format),
- gen9_choose_composite_kernel(tmp->op,
- tmp->mask.bo !=
NULL,
-
tmp->has_component_alpha,
- tmp->is_affine),
gen4_choose_composite_emitter(sna, tmp));
+ tmp->u.gen9.wm_kernel = gen9_choose_composite_kernel(tmp->op,
+tmp->mask.bo !=
NULL,
+
tmp->has_component_alpha,
+tmp->is_affine);
tmp->blt = gen9_render_composite_blt;
tmp->box = gen9_render_composite_box;
@@ -2781,8 +2780,9 @@ gen9_render_composite_spans(struct sna *sna,
SAMPLER_FILTER_NEAREST,
SAMPLER_EXTEND_PAD),
gen9_get_blend(tmp->base.op, false,
tmp->base.dst.format),
- GEN9_WM_KERNEL_OPACITY | !tmp->base.is_affine,
gen4_choose_spans_emitter(sna, tmp));
+ tmp->base.u.gen9.wm_kernel =
+ GEN9_WM_KERNEL_OPACITY | !tmp->base.is_affine;
tmp->box = gen9_render_composite_spans_box;
tmp->boxes = gen9_render_composite_spans_boxes;
@@ -3045,6 +3045,7 @@ fallback_blt:
tmp.need_magic_ca_pass = 0;
tmp.u.gen9.flags = COPY_FLAGS(alu);
+ tmp.u.gen9.wm_kernel = GEN9_WM_KERNEL_NOMASK;
kgem_set_mode(>kgem, KGEM_RENDER, tmp.dst.bo);
if (!kgem_check_bo(>kgem, tmp.dst.bo, tmp.src.bo, NULL)) {
@@ -3214,6 +3215,7 @@ fallback:
op->base.floats_per_rect = 6;
op->base.u.gen9.flags = COPY_FLAGS(alu);
+ op->base.u.gen9.wm_kernel = GEN9_WM_KERNEL_NOMASK;
kgem_set_mode(>kgem, KGEM_RENDER, dst_bo);
if (!kgem_check_bo(>kgem, dst_bo, src_bo, NULL)) {
@@ -3366,6 +3368,7 @@ gen9_render_fill_boxes(struct sna *sna,
[PATCH xf86-video-intel v8 2/2] sna: Added AYUV format support for textured and sprite video adapters.
v2: Renamed DRM_FORMAT_XYUV to DRM_FORMAT_XYUV. Added comment about AYUV byte ordering in Gstreamer. v3: Removed sna_composite_op flags related change to the separate patch. v4: Fixed review comments, done code refactoring v5: Fixed following review comments: - Fixed comment in shader code for ayuv kernel. - Fixed naming to VIDEO_AYUV_BT601/BT709 for ayuv kernels. - Removed duplicate gen9_kernel parameter, left from previous patches - Added colorspace handling for new AYUV kernel - Fixed naming of sna_copy_packed_data_ayuv to sna_copy_ayuv_data - Started using standard bswap_32 function for byte swapping in sna_copy_ayuv_data - Removed redundant code in sna_copy_ayuv_data so that it looks more neat - Fixed XVIMAGE_AYUV structure initialization to contain proper byte sequence for GST - Fixed bogus comment about subsampling for DRM_FORMAT_XYUV - Fixed AYUV advertisement for all platforms - Removed unnecessary RGB888 declaration. v6: - Fixed surface format not to use alpha as supposed - Now doing byte swapping always during copy - Changed hack, required for GST to work to be at one place - Fixed invalid sampling values for XVIMAGE_AYUV - Fixed sprite format checking order and images_ayuv definition. v7: - Removed reverse_bytes bool parameter, now swapping bytes for XYUV unconditionally both for textured and sprite modes. v8: - Added gen9_images structure, in order to expose AYUV format to proper platforms. Signed-off-by: Stanislav Lisovskiy --- src/render_program/Makefile.am| 2 + .../exa_wm_src_sample_argb_ayuv.g8a | 76 +++ .../exa_wm_src_sample_argb_ayuv.g8b | 8 ++ src/sna/gen9_render.c | 24 +- src/sna/sna_render.h | 3 + src/sna/sna_video.c | 72 +- src/sna/sna_video.h | 20 + src/sna/sna_video_sprite.c| 20 - src/sna/sna_video_textured.c | 19 + 9 files changed, 239 insertions(+), 5 deletions(-) create mode 100644 src/render_program/exa_wm_src_sample_argb_ayuv.g8a create mode 100644 src/render_program/exa_wm_src_sample_argb_ayuv.g8b diff --git a/src/render_program/Makefile.am b/src/render_program/Makefile.am index dc58138f..e35ffa52 100644 --- a/src/render_program/Makefile.am +++ b/src/render_program/Makefile.am @@ -196,6 +196,7 @@ INTEL_G7B = \ INTEL_G8A =\ exa_wm_src_affine.g8a \ exa_wm_src_sample_argb.g8a \ + exa_wm_src_sample_argb_ayuv.g8a \ exa_wm_src_sample_nv12.g8a \ exa_wm_src_sample_planar.g8a\ exa_wm_write.g8a\ @@ -205,6 +206,7 @@ INTEL_G8A = \ INTEL_G8B =\ exa_wm_src_affine.g8b \ + exa_wm_src_sample_argb_ayuv.g8b \ exa_wm_src_sample_argb.g8b \ exa_wm_src_sample_nv12.g8b \ exa_wm_src_sample_planar.g8b\ diff --git a/src/render_program/exa_wm_src_sample_argb_ayuv.g8a b/src/render_program/exa_wm_src_sample_argb_ayuv.g8a new file mode 100644 index ..c0b84c2e --- /dev/null +++ b/src/render_program/exa_wm_src_sample_argb_ayuv.g8a @@ -0,0 +1,76 @@ +/* + * Copyright © 2006 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + * + * Authors: + *Wang Zhenyu + *Keith Packard + */ + +/* Sample the src surface */ + +include(`exa_wm.g4i') + +undefine(`src_msg') +undefine(`src_msg_ind') + +define(`src_msg', `g65') +define(`src_msg_ind', `65') + +/* prepare sampler read back gX register, which would be written back to output */ + +/* use simd16 sampler, param 0 is u, param 1 is v. */ +/* 'payload' loading, assuming tex coord
Re: [PATCH v4 3/4] drm/virtio: add in/out fence support for explicit synchronization
Hi, > > > I had a look into this and how other drivers are doing it. > > > msm[1] and etnaviv[2] seem to use the same dual-use variable. > > > > Ok, lets do it the same way then. > > What is the status of the userspace side of this? > > The patch is hosted here[1], but is as of yet unmerged. > > I know the drm subsystem requires a userspace implementation of > all features, but does it have to be upstreamed first? Which part is merged first doesn't matter much I think, but both kernel and userspace side patches should be reviewed, especially the API bits, so we don't end up with a bad API. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] udlfb: fix NULL pointer dereference in dlfb_usb_probe()
On Fri, 9 Nov 2018, Alexey Khoroshilov wrote:
> If memory allocation for dlfb fails, error handling code
> unconditionally dereference NULL pointer.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov
> Fixes: 68a958a915ca ("udlfb: handle unplug properly")
Reviewed-by: Mikulas Patocka
> ---
> drivers/video/fbdev/udlfb.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
> index 070026a7e55a..9643fe7c8349 100644
> --- a/drivers/video/fbdev/udlfb.c
> +++ b/drivers/video/fbdev/udlfb.c
> @@ -1590,7 +1590,7 @@ static int dlfb_usb_probe(struct usb_interface *intf,
> int i;
> const struct device_attribute *attr;
> struct dlfb_data *dlfb;
> - struct fb_info *info;
> + struct fb_info *info = NULL;
> int retval = -ENOMEM;
> struct usb_device *usbdev = interface_to_usbdev(intf);
>
> @@ -1701,8 +1701,8 @@ static int dlfb_usb_probe(struct usb_interface *intf,
> return 0;
>
> error:
> - if (dlfb->info) {
> - dlfb_ops_destroy(dlfb->info);
> + if (info) {
> + dlfb_ops_destroy(info);
> } else if (dlfb) {
> usb_put_dev(dlfb->udev);
> kfree(dlfb);
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/4] drm/virtio: add in/out fence support for explicit synchronization
On 2018-11-12 12:11, Gerd Hoffmann wrote: On Mon, Nov 12, 2018 at 11:30:57AM +0100, Robert Foss wrote: Hey Gerd On 2018-11-12 10:10, Gerd Hoffmann wrote: On Fri, Nov 09, 2018 at 06:13:52PM +0100, Robert Foss wrote: Hey Gerd, On 2018-11-09 11:13, Gerd Hoffmann wrote: On Mon, Nov 05, 2018 at 05:25:05PM +, Emil Velikov wrote: On Mon, 5 Nov 2018 at 11:42, Robert Foss wrote: When the execbuf call receives an in-fence it will get the dma_fence related to that fence fd and wait on it before submitting the draw call. On the out-fence side we get fence returned by the submitted draw call and attach it to a sync_file and send the sync_file fd to userspace. On error -1 is returned to userspace. Signed-off-by: Gustavo Padovan Signed-off-by: Robert Foss Suggested-by: Rob Herring Reviewed-by: Emil Velikov --- Changes since v3: - Move all in_fence handling to the same VIRTGPU_EXECBUF_FENCE_FD_IN block Fwiw my suggestion was to explicitly document whether the IOCTL can support, simultaneously, IN and OUT fence. Yes, that would be good. Code looks like it is supposed to work, but explicitly saying so in the commit message would be nice. On it! Will send out a v5. Also: should we use separate fields for in/out fds? I'm not sure I understand which fields you're referring to. fence_in_fd & fence_out_fd in the ioctl struct (patch #2). I had a look into this and how other drivers are doing it. msm[1] and etnaviv[2] seem to use the same dual-use variable. Ok, lets do it the same way then. What is the status of the userspace side of this? The patch is hosted here[1], but is as of yet unmerged. I know the drm subsystem requires a userspace implementation of all features, but does it have to be upstreamed first? [1] https://gitlab.collabora.com/robertfoss/mesa/commits/virtio_fences_v3 Rob. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: Revert syncobj timeline changes.
Am 12.11.18 um 11:48 schrieb Chris Wilson:
> Quoting Christian König (2018-11-12 10:16:01)
>> Am 09.11.18 um 23:26 schrieb Eric Anholt:
>>
>> Eric Anholt writes:
>>
>>
>> [ Unknown signature status ]
>> zhoucm1 writes:
>>
>>
>> On 2018年11月09日 00:52, Christian König wrote:
>>
>> Am 08.11.18 um 17:07 schrieb Koenig, Christian:
>>
>> Am 08.11.18 um 17:04 schrieb Eric Anholt:
>>
>> Daniel suggested I submit this, since we're still
>> seeing regressions
>> from it. This is a revert to before 48197bc564c7
>> ("drm: add syncobj
>> timeline support v9") and its followon fixes.
>>
>> This is a harmless false positive from lockdep,
>> Chouming and I are
>> already working on a fix.
>>
>> On the other hand we had enough trouble with that patch, so
>> if it
>> really bothers you feel free to add my Acked-by: Christian
>> König
>> and push it.
>>
>> NAK, please no, I don't think this needed, the Warning totally
>> isn't
>> related to syncobj timeline, but fence-array implementation
>> flaw, just
>> exposed by syncobj.
>> In addition, Christian already has a fix for this Warning, I've
>> tested.
>> Please Christian send to public review.
>>
>> I backed out my revert of #2 (#1 still necessary) after adding the
>> lockdep regression fix, and now my CTS run got oomkilled after just
>> a
>> few hours, with these notable lines in the unreclaimable slab info
>> list:
>>
>> [ 6314.373099] drm_sched_fence69095KB 69095KB
>> [ 6314.373653] kmemleak_object 428249KB 428384KB
>> [ 6314.373736] kmalloc-262144 256KB256KB
>> [ 6314.373743] kmalloc-131072 128KB128KB
>> [ 6314.373750] kmalloc-65536 64KB 64KB
>> [ 6314.373756] kmalloc-32768 1472KB 1728KB
>> [ 6314.373763] kmalloc-16384 64KB 64KB
>> [ 6314.373770] kmalloc-8192 208KB208KB
>> [ 6314.373778] kmalloc-40962408KB 2408KB
>> [ 6314.373784] kmalloc-2048 288KB336KB
>> [ 6314.373792] kmalloc-10241457KB 1512KB
>> [ 6314.373800] kmalloc-512 854KB 1048KB
>> [ 6314.373808] kmalloc-256 188KB268KB
>> [ 6314.373817] kmalloc-19269141KB 69142KB
>> [ 6314.373824] kmalloc-64 47703KB 47704KB
>> [ 6314.373886] kmalloc-12846396KB 46396KB
>> [ 6314.373894] kmem_cache31KB 35KB
>>
>> No results from kmemleak, though.
>>
>> OK, it looks like the #2 revert probably isn't related to the OOM issue.
>> Running a single job on otherwise unused DRM, watching /proc/slabinfo
>> every second for drm_sched_fence, I get:
>>
>> drm_sched_fence0 0192 211 : tunables 32 16
>> 8 : slabdata 0 0 0 : globalstat 0 0 00
>> 00000 : cpustat 0 0 0 0
>> drm_sched_fence 16 21192 211 : tunables 32 16
>> 8 : slabdata 1 1 0 : globalstat 16 16 10
>> 00000 : cpustat 5 1 6 0
>> drm_sched_fence 13 21192 211 : tunables 32 16
>> 8 : slabdata 1 1 0 : globalstat 16 16 10
>> 00000 : cpustat 5 1 6 0
>> drm_sched_fence6 21192 211 : tunables 32 16
>> 8 : slabdata 1 1 0 : globalstat 16 16 10
>> 00000 : cpustat 5 1 6 0
>> drm_sched_fence4 21192 211 : tunables 32 16
>> 8 : slabdata 1 1 0 : globalstat 16 16 10
>> 00000 : cpustat 5 1 6 0
>> drm_sched_fence2 21192 211 : tunables 32 16
>> 8 : slabdata 1 1 0 : globalstat 16 16 10
>> 00000 : cpustat 5 1 6 0
>> drm_sched_fence0 21192 211 : tunables 32 16
>> 8 : slabdata 0 1 0 : globalstat 16 16 10
>> 00000 : cpustat 5 1 6 0
>>
>> So we generate a ton of fences, and I guess free them slowly because of
>> RCU? And presumably kmemleak was sucking up lots of memory because of
>> how many of these objects were laying around.
>>
>>
>> That is
[PATCH 2/3 v6] ARM: defconfig: Update the vexpress defconfig
Update the Versatile Express defconfig to match the Kconfig changes in the kernel. Cc: Sudeep Holla Cc: Lorenzo Pieralisi Signed-off-by: Linus Walleij --- ChangeLog v5->v6: - Resending ChangeLog v4->v5: - Resending ChangeLog v3->v4: - Resending ChangeLog v1->v3: - Rebased --- arch/arm/configs/vexpress_defconfig | 12 1 file changed, 12 deletions(-) diff --git a/arch/arm/configs/vexpress_defconfig b/arch/arm/configs/vexpress_defconfig index edae1c58fe80..226fe4bfb487 100644 --- a/arch/arm/configs/vexpress_defconfig +++ b/arch/arm/configs/vexpress_defconfig @@ -21,20 +21,17 @@ CONFIG_MODULE_UNLOAD=y CONFIG_ARCH_VEXPRESS=y CONFIG_ARCH_VEXPRESS_DCSCB=y CONFIG_ARCH_VEXPRESS_TC2_PM=y -# CONFIG_SWP_EMULATE is not set CONFIG_SMP=y CONFIG_HAVE_ARM_ARCH_TIMER=y CONFIG_MCPM=y CONFIG_VMSPLIT_2G=y CONFIG_NR_CPUS=8 CONFIG_ARM_PSCI=y -CONFIG_AEABI=y CONFIG_CMA=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE="console=ttyAMA0" CONFIG_CPU_IDLE=y -CONFIG_CPU_IDLE_MULTIPLE_DRIVERS=y CONFIG_VFP=y CONFIG_NEON=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set @@ -61,7 +58,6 @@ CONFIG_MTD_PHYSMAP=y CONFIG_MTD_PHYSMAP_OF=y CONFIG_MTD_PLATRAM=y CONFIG_MTD_UBI=y -CONFIG_PROC_DEVICETREE=y CONFIG_VIRTIO_BLK=y # CONFIG_SCSI_PROC_FS is not set CONFIG_BLK_DEV_SD=y @@ -85,7 +81,6 @@ CONFIG_HW_RANDOM_VIRTIO=y CONFIG_I2C=y CONFIG_I2C_VERSATILE=y CONFIG_SENSORS_VEXPRESS=y -CONFIG_REGULATOR=y CONFIG_REGULATOR_VEXPRESS=y CONFIG_FB=y CONFIG_FB_ARMCLCD=y @@ -95,8 +90,6 @@ CONFIG_LOGO=y # CONFIG_LOGO_LINUX_VGA16 is not set CONFIG_SOUND=y CONFIG_SND=y -CONFIG_SND_MIXER_OSS=y -CONFIG_SND_PCM_OSS=y # CONFIG_SND_DRIVERS is not set CONFIG_SND_ARMAACI=y CONFIG_HID_DRAGONRISE=y @@ -133,9 +126,6 @@ CONFIG_VIRTIO_MMIO=y CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y -# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set -# CONFIG_EXT3_FS_XATTR is not set -CONFIG_EXT4_FS=y CONFIG_VFAT_FS=y CONFIG_TMPFS=y CONFIG_JFFS2_FS=y @@ -149,11 +139,9 @@ CONFIG_9P_FS=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y CONFIG_DEBUG_INFO=y -CONFIG_DEBUG_FS=y CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_KERNEL=y CONFIG_DETECT_HUNG_TASK=y # CONFIG_SCHED_DEBUG is not set CONFIG_DEBUG_USER=y -# CONFIG_CRYPTO_ANSI_CPRNG is not set # CONFIG_CRYPTO_HW is not set -- 2.17.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3 v6] ARM: dts: Modernize the Vexpress PL111 integration
The Versatile Express was submitted with the actual display
bridges unconnected (but defined in the device tree) and
mock "panels" encoded in the device tree node of the PL111
controller.
This doesn't even remotely describe the actual Versatile
Express hardware. Exploit the SiI9022 bridge by connecting
the PL111 pads to it, making it use EDID or fallback values
to drive the monitor.
The also has to use the reserved memory through the
CMA pool rather than by open coding a memory region and
remapping it explicitly in the driver. To achieve this,
a reserved-memory node must exist in the root of the
device tree, so we need to pull that out of the
motherboard .dtsi include files, and push it into each
top-level device tree instead.
We do the same manouver for all the Versatile Express
boards, taking into account the different location of the
video RAM depending on which chip select is used on
each platform.
This plays nicely with the new PL111 DRM driver and
follows the standard ways of assigning bridges and
memory pools for graphics.
Cc: Sudeep Holla
Cc: Lorenzo Pieralisi
Cc: Liviu Dudau
Cc: Mali DP Maintainers
Cc: Robin Murphy
Signed-off-by: Linus Walleij
---
ChangeLog v5->v6:
- Change the panel in the RTSMv8 to the simple panel
"arm,rtsmv8-panel" simply.
ChangeLog v4->v5:
- Fix up the RTSMv8 AEM VE by using the new simple VGA
panel I invented in the DRI simple panel.
- NOTE: This patch depends at runtime on the DRM simple
panel patch "drm/panel: simple: Support simple VGA panels"
ChangeLog v3->v4:
- Fix the ARM and ARM64 shared vexpress-v2m-rc1.dtsi
file address-cells etc so that the ports do not give
DTC warnings anymore.
- Fixed up the CA53 DTS: use the right chip select base
at 0x1800.
- Fixed up the Real-Time Systems Models Virtual Executive
RTSMv8 AEM VE:
- Added the I2C interface (whether implemented in the
emulator or not)
- Fixed the chip select of the memory node to the right
memory base 0x1800.
- Add right address-cells and size-cells to the
vexpress-v2m.dtsi dvi port as well.
- Create two endpoints for the motherboard and the
core tile in the vexpress-v2m.dtsi. This is just used
by the CA9 VExpress. Tested on both QEMU and the
actual hardware with the DRM driver. This removes the
last warnings from the DTC.
ChangeLog v2->v3:
- Add some reg = <0>; to the ports to make the DTC happy.
- Add reserved memory node to
arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
as well.
ChangeLog v1->v2:
- Fix up the memory address for the -rs1 tiles to 0x1800
- Drop a bunch of extraneous reg props from the DVI adapter
---
arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 49 +--
arch/arm/boot/dts/vexpress-v2m.dtsi | 63 +--
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 14 +
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts| 14 +
arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 14 +
arch/arm/boot/dts/vexpress-v2p-ca9.dts| 43 ++---
arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts| 23 +++
.../boot/dts/arm/rtsm_ve-motherboard.dtsi | 37 ++-
.../boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts | 14 +
9 files changed, 150 insertions(+), 121 deletions(-)
diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
index 4488c8fe213a..a9569d15de41 100644
--- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
@@ -43,11 +43,6 @@
bank-width = <4>;
};
- v2m_video_ram: vram@2, {
- compatible = "arm,vexpress-vram";
- reg = <2 0x 0x0080>;
- };
-
ethernet@2,0200 {
compatible = "smsc,lan9118", "smsc,lan9115";
reg = <2 0x0200 0x1>;
@@ -223,13 +218,24 @@
v2m_i2c_dvi: i2c@16 {
compatible = "arm,versatile-i2c";
reg = <0x16 0x1000>;
-
#address-cells = <1>;
#size-cells = <0>;
dvi-transmitter@39 {
compatible = "sil,sii9022-tpi",
"sil,sii9022";
reg = <0x39>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dvi_bridge_in:
endpoint {
+
[PATCH 3/3 v6] ARM: defconfig: Enable the PL111 DRM driver on vexpress
This updates the Versatile defconfig to use the new P111 DRM driver that is merged in the DRM subsystem. We deactivate the old CLCD driver and activate the Pl111 DRM driver and the SiI9022 HDMI bridge. We activate DMA memory allocation using CMA so that the special graphics memory for the on-board CLCD can be used. Cc: Sudeep Holla Cc: Lorenzo Pieralisi Signed-off-by: Linus Walleij --- ChangeLog v5->v6: - Resending ChangeLog v4->v5: - Resending ChangeLog v3->v4: - Resending ChangeLog v1->v3: - Rebased --- arch/arm/configs/vexpress_defconfig | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/arm/configs/vexpress_defconfig b/arch/arm/configs/vexpress_defconfig index 226fe4bfb487..392ed3b3613c 100644 --- a/arch/arm/configs/vexpress_defconfig +++ b/arch/arm/configs/vexpress_defconfig @@ -48,6 +48,7 @@ CONFIG_NET_9P=y CONFIG_NET_9P_VIRTIO=y CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_DEVTMPFS=y +CONFIG_DMA_CMA=y CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_BLOCK=y @@ -78,13 +79,16 @@ CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_VIRTIO_CONSOLE=y CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_VIRTIO=y -CONFIG_I2C=y CONFIG_I2C_VERSATILE=y CONFIG_SENSORS_VEXPRESS=y CONFIG_REGULATOR_VEXPRESS=y -CONFIG_FB=y -CONFIG_FB_ARMCLCD=y -CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_DRM=y +CONFIG_DRM_PANEL_SIMPLE=y +CONFIG_DRM_SII902X=y +CONFIG_DRM_PL111=y +CONFIG_FB_MODE_HELPERS=y +CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_LOGO=y # CONFIG_LOGO_LINUX_MONO is not set # CONFIG_LOGO_LINUX_VGA16 is not set -- 2.17.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3 v6] Switch Versatile Express to DRM
This should finally (famous last words) switch the Versatile Express to use the new PL111 DRM driver. These changes depend on patches queued in the DRM tree, so it should resolve nicely in -next, also you can probably test them easiest by simply applying them on -next. The DTS and defconfig changes should ideally come in lockstep but I guess maybe the ARM maintainers want the DTS changes in one branch and the defconfig updates in another branch. As long as they go in the same merge window all should be fine, they should just be tested together (and with the pending DRM changes). Linus Walleij (3): ARM: dts: Modernize the Vexpress PL111 integration ARM: defconfig: Update the vexpress defconfig ARM: defconfig: Enable the PL111 DRM driver on vexpress arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 49 +-- arch/arm/boot/dts/vexpress-v2m.dtsi | 63 +-- arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 14 + arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts| 14 + arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 14 + arch/arm/boot/dts/vexpress-v2p-ca9.dts| 43 ++--- arch/arm/configs/vexpress_defconfig | 24 +++ arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts| 23 +++ .../boot/dts/arm/rtsm_ve-motherboard.dtsi | 37 ++- .../boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts | 14 + 10 files changed, 158 insertions(+), 137 deletions(-) -- 2.17.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [kbuild-all] [PATCH] fbcon: Silence fbcon logo on 'quiet' boots
On 11/11/2018 10:18 PM, Rong Chen wrote: > > > On 10/29/2018 11:15 PM, Prarit Bhargava wrote: >> >> On 10/29/2018 09:56 AM, kbuild test robot wrote: >>> Hi Prarit, >>> >>> Thank you for the patch! Yet something to improve: >>> >>> [auto build test ERROR on sof-driver-fuweitax/master] >>> [also build test ERROR on v4.19 next-20181029] >>> [if your patch is applied to the wrong git tree, please drop us a note to >>> help improve the system] >>> >>> url: >>> https://github.com/0day-ci/linux/commits/Prarit-Bhargava/fbcon-Silence-fbcon-logo-on-quiet-boots/20181029-211617 >>> >>> base: https://github.com/fuweitax/linux master >>> config: m68k-multi_defconfig (attached as .config) >>> compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 >>> reproduce: >>> wget >>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O >>> ~/bin/make.cross >>> chmod +x ~/bin/make.cross >>> # save the attached .config to linux build tree >>> GCC_VERSION=7.2.0 make.cross ARCH=m68k >>> >>> All errors (new ones prefixed by >>): >>> >>> drivers/video/fbdev/core/fbcon.c: In function 'fbcon_prepare_logo': >>> drivers/video/fbdev/core/fbcon.c:680:13: error: invalid storage class >>> for >>> function 'set_blitting_type' >>> static void set_blitting_type(struct vc_data *vc, struct fb_info *info) >>> ^ >>> drivers/video/fbdev/core/fbcon.c:680:1: warning: ISO C90 forbids mixed >>> declarations and code [-Wdeclaration-after-statement] >>> static void set_blitting_type(struct vc_data *vc, struct fb_info *info) >>> ^~ >>> drivers/video/fbdev/core/fbcon.c:690:12: error: invalid storage class >>> for >>> function 'fbcon_invalid_charcount' >>> static int fbcon_invalid_charcount(struct fb_info *info, unsigned >>> charcount) >>> ^~~ >>> drivers/video/fbdev/core/fbcon.c:698:12: error: invalid storage class >>> for >>> function 'con2fb_acquire_newinfo' >>> static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info >>> *info, >>> ^~ >>> drivers/video/fbdev/core/fbcon.c:734:12: error: invalid storage class >>> for >>> function 'con2fb_release_oldinfo' >>> static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info >>> *oldinfo, >>> ^~ >>> drivers/video/fbdev/core/fbcon.c:780:13: error: invalid storage class >>> for >>> function 'con2fb_init_display' >>> static void con2fb_init_display(struct vc_data *vc, struct fb_info >>> *info, >>> ^~~ >>> drivers/video/fbdev/core/fbcon.c:825:12: error: invalid storage class >>> for >>> function 'set_con2fb_map' >>> static int set_con2fb_map(int unit, int newidx, int user) >>> ^~ >>> drivers/video/fbdev/core/fbcon.c:882:12: error: invalid storage class >>> for >>> function 'var_to_display' >>> static int var_to_display(struct display *disp, >>> ^~ >>> drivers/video/fbdev/core/fbcon.c:906:13: error: invalid storage class >>> for >>> function 'display_to_var' >>> static void display_to_var(struct fb_var_screeninfo *var, >>> ^~ >>> drivers/video/fbdev/core/fbcon.c:925:20: error: invalid storage class >>> for >>> function 'fbcon_startup' >>> static const char *fbcon_startup(void) >>> ^ >>> drivers/video/fbdev/core/fbcon.c:1036:13: error: invalid storage class >>> for function 'fbcon_init' >>> static void fbcon_init(struct vc_data *vc, int init) >>> ^~ >>> drivers/video/fbdev/core/fbcon.c:1183:13: error: invalid storage class >>> for function 'fbcon_free_font' >>> static void fbcon_free_font(struct display *p, bool freefont) >>> ^~~ >>> drivers/video/fbdev/core/fbcon.c:1191:13: error: invalid storage class >>> for function 'set_vc_hi_font' >>> static void set_vc_hi_font(struct vc_data *vc, bool set); >>> ^~ >>> drivers/video/fbdev/core/fbcon.c:1193:13: error: invalid storage class >>> for function 'fbcon_deinit' >>> static void fbcon_deinit(struct vc_data *vc) >>> ^~~~ >>> drivers/video/fbdev/core/fbcon.c: In function 'fbcon_deinit': > drivers/video/fbdev/core/fbcon.c:1229:3: error: implicit declaration of > function 'set_vc_hi_font'; did you mean 'seq_path_root'? > [-Werror=implicit-function-declaration] >>>set_vc_hi_font(vc, false); >>>^~ >> Hmm ... this doesn't look like anything that is at fault with my patch. >> >> There's a lot of warnings here, and perhaps another fix is required to make >> sure that the configs are set correctly? I can certainly take a look in >> another patch but AFAICT this isn't an issue with my patch. > > Please accept my
[PATCH] drm/etnaviv: remove unnecessary local irq state save/restore
etnaviv_gpu_recover_hang() and event_alloc() are never called from
a context where local irqs would be disabled, so we can reduce the
overhead by using the spinlock variants that don't remember the
irq state.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 8fbe77cae810..0a32193457c4 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -976,7 +976,6 @@ int etnaviv_gpu_debugfs(struct etnaviv_gpu *gpu, struct
seq_file *m)
void etnaviv_gpu_recover_hang(struct etnaviv_gpu *gpu)
{
- unsigned long flags;
unsigned int i = 0;
dev_err(gpu->dev, "recover hung GPU!\n");
@@ -989,11 +988,11 @@ void etnaviv_gpu_recover_hang(struct etnaviv_gpu *gpu)
etnaviv_hw_reset(gpu);
/* complete all events, the GPU won't do it after the reset */
- spin_lock_irqsave(>event_spinlock, flags);
+ spin_lock_irq(>event_spinlock);
for_each_set_bit_from(i, gpu->event_bitmap, ETNA_NR_EVENTS)
complete(>event_free);
bitmap_zero(gpu->event_bitmap, ETNA_NR_EVENTS);
- spin_unlock_irqrestore(>event_spinlock, flags);
+ spin_unlock_irq(>event_spinlock);
etnaviv_gpu_hw_init(gpu);
gpu->lastctx = NULL;
@@ -1083,7 +1082,7 @@ static inline bool fence_after(u32 a, u32 b)
static int event_alloc(struct etnaviv_gpu *gpu, unsigned nr_events,
unsigned int *events)
{
- unsigned long flags, timeout = msecs_to_jiffies(10 * 1);
+ unsigned long timeout = msecs_to_jiffies(10 * 1);
unsigned i, acquired = 0;
for (i = 0; i < nr_events; i++) {
@@ -1100,7 +1099,7 @@ static int event_alloc(struct etnaviv_gpu *gpu, unsigned
nr_events,
timeout = ret;
}
- spin_lock_irqsave(>event_spinlock, flags);
+ spin_lock_irq(>event_spinlock);
for (i = 0; i < nr_events; i++) {
int event = find_first_zero_bit(gpu->event_bitmap,
ETNA_NR_EVENTS);
@@ -1110,7 +1109,7 @@ static int event_alloc(struct etnaviv_gpu *gpu, unsigned
nr_events,
set_bit(event, gpu->event_bitmap);
}
- spin_unlock_irqrestore(>event_spinlock, flags);
+ spin_unlock_irq(>event_spinlock);
return 0;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108680] [CI][BAT] igt@kms_chamelium may need to wait a little bit for the network to come back up before connecting to chamelium
https://bugs.freedesktop.org/show_bug.cgi?id=108680 Lakshmi changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |petri.latv...@intel.com |.org| --- Comment #4 from Lakshmi --- IGT infrastructure issue rather than driver 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
[Bug 108270] [proton] Wolfenstein: The New Order (frame rate issue)
https://bugs.freedesktop.org/show_bug.cgi?id=108270 --- Comment #1 from Adam Lyall --- I can confirm the same experience using a Radeon R9 285 with the Mesa 18.2.* series. The game for the most part runs really smooth but as soon as I reached the bunker shown on James B's Youtube video the framerate dropped greatly and no matter how low I set the graphic settings it made no difference. - Solus OS - Mesa 18.2.1 - R9 285 (Tonga) - Ryzen 5 1600@3.85GHz -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/arm/malidp: Consider rotation memory requirement in case of AFBC framebuffer
Hi Ayan,
On Fri, Nov 09, 2018 at 10:37:19AM +, Ayan Halder wrote:
> Rotation memory for layers is shared with AFBC decoder block. Thus one needs
> to
> calculate rotation memory requirement in case of AFBC framebuffer. This is
> used later to verify if it can be sufficed by the hardware rotation memory
> availibility.
>
> Fixes: 66da13a ("drm/arm/malidp: Validate rotations for
> compressed/uncompressed framebuffers for each layer")
Reviewed-by: Alexandru Gheorghe
> Signed-off-by: Ayan Kumar halder
> ---
> drivers/gpu/drm/arm/malidp_planes.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> b/drivers/gpu/drm/arm/malidp_planes.c
> index c9a6d3e..3f4dc64 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -470,7 +470,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
> }
>
> ms->rotmem_size = 0;
> - if (state->rotation & MALIDP_ROTATED_MASK) {
> + if ((state->rotation & MALIDP_ROTATED_MASK) || fb->modifier) {
> int val;
>
> val = mp->hwdev->hw->rotmem_required(mp->hwdev, state->crtc_w,
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Performance regression in ast drm driver
On Mon, 12 Nov 2018 15:36:07 +0100, Jean Delvare wrote: > > Hi David, > > On Fri, 2018-11-09 at 10:04 +1000, David Airlie wrote: > > On Thu, Nov 8, 2018 at 10:05 PM Jean Delvare wrote: > > > > > > On Thu, 1 Nov 2018 16:27:07 +0100, Jean Delvare wrote: > > > > Hi David, > > > > > > > > The following commit: > > > > > > > > commit 7cf321d118a825c1541b43ca45294126fd474efa > > > > Author: Dave Airlie > > > > Date: Mon Oct 24 15:37:48 2016 +1000 > > > > > > > > drm/drivers: add support for using the arch wc mapping API. > > > > > > > > is causing a huge performance regression for the ast drm driver. In a > > > > text console, if I call "cat" on a large text file, it takes almost > > > > twice as much time to be displayed and scrolled completely. > > > > > > > > Can you please check that the ast driver portion of that commit is both > > > > correct and complete? > > > > > > And in the meantime, what bad will happen if we just revert the ast > > > portion of that commit? > > > > This seems likely to be a hw problem with PCI writes to the AST "GPU", > > since it's just some sort of RAM + ARM on the end of a PCIE bus, we've > > definitely seen possible issues in the past with write combining > > around some of the mga GPUs with some CPUs. > > Takashi asked me to compare the contents of > /sys/kernel/debug/x86/pat_memtype_list before and after the commit > above. Before the commit, we have: > > uncached-minus @ 0xfafe-0xfb00 > uncached-minus @ 0xfb00-0xfb005000 > write-combining @ 0xfb005000-0xfb584000 > > After the commit, we have: > > uncached-minus @ 0xfafe-0xfb00 > uncached-minus @ 0xfb00-0xfb005000 > uncached-minus @ 0xfb00-0xfb80 > uncached-minus @ 0xfb005000-0xfb584000 Just to be sure: could you double-check whether you're checking the right order (i.e. not checking against the revert)? The change above looks illogical from what I can see from the commit... thanks, Takashi > > The corresponding lines in /proc/iomem are: > > f000-fed8 : PCI Bus :00 > faf0-fb7f : PCI Bus :01 > fafe-faff : :01:01.0 > fb00-fb7f : :01:01.0 > > Does it help? Is the change of type expected? Is it not a problem that > one of the ranges is overlapping with 2 other ranges? > > -- > Jean Delvare > SUSE L3 Support > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/syncobj: Fix compilation following partial revert
We need to include the revert of commit 783195ec1cad ("drm/syncobj:
disable the timeline UAPI for now v2") along with undoing the change to
drm/i915.
Fixes: 131280a162e7 ("drm: Revert syncobj timeline changes.")
Signed-off-by: Chris Wilson
Cc: Christian König
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 4
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 90e0a6dce086..e2c5b3ca4824 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -277,10 +277,6 @@ int drm_syncobj_create(struct drm_syncobj **out_syncobj,
uint32_t flags,
int ret;
struct drm_syncobj *syncobj;
- /* Disabled for now */
- if (flags & DRM_SYNCOBJ_CREATE_TYPE_TIMELINE)
- return -EINVAL;
-
syncobj = kzalloc(sizeof(struct drm_syncobj), GFP_KERNEL);
if (!syncobj)
return -ENOMEM;
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1a1c04db6c80..1aaccbe7e1de 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2157,7 +2157,7 @@ await_fence_array(struct i915_execbuffer *eb,
if (!(flags & I915_EXEC_FENCE_WAIT))
continue;
- drm_syncobj_search_fence(syncobj, 0, 0, );
+ fence = drm_syncobj_fence_get(syncobj);
if (!fence)
return -EINVAL;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere
On Mon, Nov 12, 2018 at 04:01:14PM +0100, Maarten Lankhorst wrote:
> We already have __drm_atomic_helper_connector_reset() and
> __drm_atomic_helper_plane_reset(), extend this to crtc as well.
>
> Most drivers already have a gpu reset hook, correct it.
> Nouveau already implemented its own __drm_atomic_helper_crtc_reset(),
> convert it to the common one.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
> Cc: David Airlie
> Cc: Liviu Dudau
> Cc: Brian Starkey
> Cc: Mali DP Maintainers
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Philipp Zabel
> Cc: CK Hu
> Cc: Matthias Brugger
> Cc: Rob Clark
> Cc: Ben Skeggs
> Cc: Tomi Valkeinen
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: Sandy Huang
> Cc: "Heiko Stübner"
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: Eric Anholt
> Cc: VMware Graphics
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> Cc: Tony Cheng
> Cc: Shirish S
> Cc: Mikita Lipski
> Cc: Bhawanpreet Lakha
> Cc: David Francis
> Cc: Anthony Koo
> Cc: Jeykumar Sankaran
> Cc: Jordan Crouse
> Cc: Bruce Wang
> Cc: Sravanthi Kollukuduru
> Cc: Archit Taneja
> Cc: Steve Kowalik
> Cc: Carsten Behling
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Mahesh Kumar
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: intel-...@lists.freedesktop.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-te...@vger.kernel.org
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +--
> drivers/gpu/drm/arm/malidp_crtc.c | 5 +--
> .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 5 +--
> drivers/gpu/drm/drm_atomic_state_helper.c | 31 ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> drivers/gpu/drm/imx/ipuv3-crtc.c | 5 +--
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 5 +--
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 ++-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 6 +---
> drivers/gpu/drm/nouveau/dispnv50/head.c | 13 ++--
> drivers/gpu/drm/omapdrm/omap_crtc.c | 7 ++---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 4 +--
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +++--
> drivers/gpu/drm/tegra/dc.c| 5 +--
> drivers/gpu/drm/vc4/vc4_crtc.c| 8 ++---
> drivers/gpu/drm/vkms/vkms_crtc.c | 7 +
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 +-
> include/drm/drm_atomic_state_helper.h | 2 ++
> 18 files changed, 56 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 5064768642f3..770a71726cd1 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2802,9 +2802,7 @@ static void dm_crtc_reset_state(struct drm_crtc *crtc)
> if (WARN_ON(!state))
Can you give this the same treatment as the other allocation checks?
> return;
>
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> -
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static struct drm_crtc_state *
> diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
> b/drivers/gpu/drm/arm/malidp_crtc.c
> index e1b72782848c..9a924ff27148 100644
> --- a/drivers/gpu/drm/arm/malidp_crtc.c
> +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> @@ -474,10 +474,7 @@ static void malidp_crtc_reset(struct drm_crtc *crtc)
>
> kfree(state);
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> - }
You're changing behavior slightly here. If the allocation fails in the old code,
you just continue on (and presumably use-after-free on the next crtc->state
access). Whereas now you're going to just deref NULL. Neither one are really
desireable :)
So you probably want to continue checking the allocation and clear crtc->state
if it fails. After that you can call helper_crtc_reset with >base.
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static void malidp_crtc_destroy_state(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index 96f4082671fe..8084d549c7d1 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++
[Bug 99923] HITMAN (2016) having lighting and artefacting, and overly light room.
https://bugs.freedesktop.org/show_bug.cgi?id=99923 --- Comment #44 from Alex Smith --- We released a game update last week, which includes a workaround for the out of bounds array access in a shader that was triggering this issue (thanks to Nicolai for giving us the details). That should fix the rendering issues without having to update LLVM or wait for a backport. Obviously the game shouldn't be crashing for you after the update, if it is please contact supp...@feralinteractive.com so we can look into it. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/qxl: remove set but not used variables 'driver, qbo'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/qxl/qxl_release.c: In function
'qxl_release_fence_buffer_objects':
drivers/gpu/drm/qxl/qxl_release.c:431:17: warning:
variable 'qbo' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/qxl/qxl_release.c:430:24: warning:
variable 'driver' set but not used [-Wunused-but-set-variable]
'qbo' not used since commit f2c24b83ae90 ("drm/ttm: flip the switch, and convert
to dma_fence")
And 'driver' never used since introduction in
8002db6336dd ("qxl: convert qxl driver to proper use for reservations")
Signed-off-by: YueHaibing
---
drivers/gpu/drm/qxl/qxl_release.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index 3813ec1..0a693fe 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -427,8 +427,6 @@ void qxl_release_fence_buffer_objects(struct qxl_release
*release)
struct ttm_buffer_object *bo;
struct ttm_bo_global *glob;
struct ttm_bo_device *bdev;
- struct ttm_bo_driver *driver;
- struct qxl_bo *qbo;
struct ttm_validate_buffer *entry;
struct qxl_device *qdev;
@@ -449,14 +447,12 @@ void qxl_release_fence_buffer_objects(struct qxl_release
*release)
release->id | 0xf000, release->base.seqno);
trace_dma_fence_emit(>base);
- driver = bdev->driver;
glob = bdev->glob;
spin_lock(>lru_lock);
list_for_each_entry(entry, >bos, head) {
bo = entry->bo;
- qbo = to_qxl_bo(bo);
reservation_object_add_shared_fence(bo->resv, >base);
ttm_bo_add_to_lru(bo);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Performance regression in ast drm driver
Hi David, On Fri, 2018-11-09 at 10:04 +1000, David Airlie wrote: > On Thu, Nov 8, 2018 at 10:05 PM Jean Delvare wrote: > > > > On Thu, 1 Nov 2018 16:27:07 +0100, Jean Delvare wrote: > > > Hi David, > > > > > > The following commit: > > > > > > commit 7cf321d118a825c1541b43ca45294126fd474efa > > > Author: Dave Airlie > > > Date: Mon Oct 24 15:37:48 2016 +1000 > > > > > > drm/drivers: add support for using the arch wc mapping API. > > > > > > is causing a huge performance regression for the ast drm driver. In a > > > text console, if I call "cat" on a large text file, it takes almost > > > twice as much time to be displayed and scrolled completely. > > > > > > Can you please check that the ast driver portion of that commit is both > > > correct and complete? > > > > And in the meantime, what bad will happen if we just revert the ast > > portion of that commit? > > This seems likely to be a hw problem with PCI writes to the AST "GPU", > since it's just some sort of RAM + ARM on the end of a PCIE bus, we've > definitely seen possible issues in the past with write combining > around some of the mga GPUs with some CPUs. Takashi asked me to compare the contents of /sys/kernel/debug/x86/pat_memtype_list before and after the commit above. Before the commit, we have: uncached-minus @ 0xfafe-0xfb00 uncached-minus @ 0xfb00-0xfb005000 write-combining @ 0xfb005000-0xfb584000 After the commit, we have: uncached-minus @ 0xfafe-0xfb00 uncached-minus @ 0xfb00-0xfb005000 uncached-minus @ 0xfb00-0xfb80 uncached-minus @ 0xfb005000-0xfb584000 The corresponding lines in /proc/iomem are: f000-fed8 : PCI Bus :00 faf0-fb7f : PCI Bus :01 fafe-faff : :01:01.0 fb00-fb7f : :01:01.0 Does it help? Is the change of type expected? Is it not a problem that one of the ranges is overlapping with 2 other ranges? -- Jean Delvare SUSE L3 Support ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] mm: Replace all open encodings for NUMA_NO_NODE
On 11/12/2018 09:40 AM, Anshuman Khandual wrote: > > > On 11/12/2018 09:27 AM, Joseph Qi wrote: >> For ocfs2 part, node means host in the cluster, not NUMA node. >> > > Does not -1 indicate an invalid node which can never be present ? > My bad, got it wrong. Seems like this is nothing to do with NUMA node at all. Will drop the changes from ocfs2. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] mm: Replace all open encodings for NUMA_NO_NODE
For ocfs2 part, node means host in the cluster, not NUMA node.
Thanks,
Joseph
On 18/11/12 10:41, Anshuman Khandual wrote:
> At present there are multiple places where invalid node number is encoded
> as -1. Even though implicitly understood it is always better to have macros
> in there. Replace these open encodings for an invalid node number with the
> global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like
> 'invalid node' from various places redirecting them to a common definition.
>
> Signed-off-by: Anshuman Khandual
> ---
> Build tested this with multiple cross compiler options like alpha, sparc,
> arm64, x86, powerpc64le etc with their default config which might not have
> compiled tested all driver related changes. I will appreciate folks giving
> this a test in their respective build environment.
>
> All these places for replacement were found by running the following grep
> patterns on the entire kernel code. Please let me know if this might have
> missed some instances. This might also have replaced some false positives.
> I will appreciate suggestions, inputs and review.
>
> 1. git grep "nid == -1"
> 2. git grep "node == -1"
> 3. git grep "nid = -1"
> 4. git grep "node = -1"
>
> arch/alpha/include/asm/topology.h | 2 +-
> arch/ia64/kernel/numa.c | 2 +-
> arch/ia64/mm/discontig.c | 6 +++---
> arch/ia64/sn/kernel/io_common.c | 2 +-
> arch/powerpc/include/asm/pci-bridge.h | 2 +-
> arch/powerpc/kernel/paca.c| 2 +-
> arch/powerpc/kernel/pci-common.c | 2 +-
> arch/powerpc/mm/numa.c| 14 +++---
> arch/powerpc/platforms/powernv/memtrace.c | 4 ++--
> arch/sparc/kernel/auxio_32.c | 2 +-
> arch/sparc/kernel/pci_fire.c | 2 +-
> arch/sparc/kernel/pci_schizo.c| 2 +-
> arch/sparc/kernel/pcic.c | 6 +++---
> arch/sparc/kernel/psycho_common.c | 2 +-
> arch/sparc/kernel/sbus.c | 2 +-
> arch/sparc/mm/init_64.c | 6 +++---
> arch/sparc/prom/init_32.c | 2 +-
> arch/sparc/prom/init_64.c | 4 ++--
> arch/sparc/prom/tree_32.c | 12 ++--
> arch/sparc/prom/tree_64.c | 18 +-
> arch/x86/include/asm/pci.h| 2 +-
> arch/x86/kernel/apic/x2apic_uv_x.c| 6 +++---
> arch/x86/kernel/smpboot.c | 2 +-
> arch/x86/platform/olpc/olpc_dt.c | 16
> drivers/block/mtip32xx/mtip32xx.c | 4 ++--
> drivers/dma/dmaengine.c | 3 ++-
> drivers/infiniband/hw/hfi1/affinity.c | 2 +-
> drivers/infiniband/hw/hfi1/init.c | 2 +-
> drivers/iommu/dmar.c | 4 ++--
> drivers/iommu/intel-iommu.c | 2 +-
> drivers/media/pci/ivtv/ivtvfb.c | 2 +-
> drivers/media/platform/vivid/vivid-osd.c | 2 +-
> drivers/misc/sgi-xp/xpc_uv.c | 2 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++--
> drivers/video/fbdev/mmp/fb/mmpfb.c| 2 +-
> drivers/video/fbdev/pxa168fb.c| 2 +-
> drivers/video/fbdev/w100fb.c | 2 +-
> fs/ocfs2/dlm/dlmcommon.h | 2 +-
> fs/ocfs2/dlm/dlmdomain.c | 10 +-
> fs/ocfs2/dlm/dlmmaster.c | 2 +-
> fs/ocfs2/dlm/dlmrecovery.c| 2 +-
> fs/ocfs2/stack_user.c | 6 +++---
> init/init_task.c | 2 +-
> kernel/kthread.c | 2 +-
> kernel/sched/fair.c | 15 ---
> lib/cpumask.c | 2 +-
> mm/huge_memory.c | 12 ++--
> mm/hugetlb.c | 2 +-
> mm/ksm.c | 2 +-
> mm/memory.c | 6 +++---
> mm/memory_hotplug.c | 12 ++--
> mm/mempolicy.c| 2 +-
> mm/page_alloc.c | 4 ++--
> mm/page_ext.c | 2 +-
> net/core/pktgen.c | 2 +-
> net/qrtr/qrtr.c | 2 +-
> tools/perf/bench/numa.c | 6 +++---
> 57 files changed, 125 insertions(+), 123 deletions(-)
>
> diff --git a/arch/alpha/include/asm/topology.h
> b/arch/alpha/include/asm/topology.h
> index e6e13a8..f6dc89c 100644
> --- a/arch/alpha/include/asm/topology.h
> +++ b/arch/alpha/include/asm/topology.h
> @@ -29,7 +29,7 @@ static const struct cpumask *cpumask_of_node(int node)
> {
> int cpu;
>
> - if (node
Re: [PATCH v2 2/9] phy: Add configuration interface
Hi Maxime,
On 06/11/18 8:24 PM, Maxime Ripard wrote:
> The phy framework is only allowing to configure the power state of the PHY
> using the init and power_on hooks, and their power_off and exit
> counterparts.
>
> While it works for most, simple, PHYs supported so far, some more advanced
> PHYs need some configuration depending on runtime parameters. These PHYs
> have been supported by a number of means already, often by using ad-hoc
> drivers in their consumer drivers.
>
> That doesn't work too well however, when a consumer device needs to deal
> with multiple PHYs, or when multiple consumers need to deal with the same
> PHY (a DSI driver and a CSI driver for example).
>
> So we'll add a new interface, through two funtions, phy_validate and
> phy_configure. The first one will allow to check that a current
> configuration, for a given mode, is applicable. It will also allow the PHY
> driver to tune the settings given as parameters as it sees fit.
>
> phy_configure will actually apply that configuration in the phy itself.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/phy/phy-core.c | 61 ++-
> include/linux/phy/phy.h | 58 -
> 2 files changed, 119 insertions(+)
>
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index 35fd38c5a4a1..7bd3ed65c708 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -408,6 +408,67 @@ int phy_calibrate(struct phy *phy)
> EXPORT_SYMBOL_GPL(phy_calibrate);
>
> /**
> + * phy_configure() - Changes the phy parameters
> + * @phy: the phy returned by phy_get()
> + * @opts: New configuration to apply
> + *
> + * Used to change the PHY parameters. phy_init() must have been called
> + * on the phy. The configuration will be applied on the current phy
> + * mode, that can be changed using phy_set_mode().
> + *
> + * Returns: 0 if successful, an negative error code otherwise
> + */
> +int phy_configure(struct phy *phy, union phy_configure_opts *opts)
> +{
> + int ret;
> +
> + if (!phy)
> + return -EINVAL;
> +
> + if (!phy->ops->configure)
> + return -EOPNOTSUPP;
> +
> + mutex_lock(>mutex);
> + ret = phy->ops->configure(phy, opts);
> + mutex_unlock(>mutex);
> +
> + return ret;
> +}
EXPORT_SYMBOL_GPL is missing here and below.
> +
> +/**
> + * phy_validate() - Checks the phy parameters
> + * @phy: the phy returned by phy_get()
> + * @mode: phy_mode the configuration is applicable to.
> + * @opts: Configuration to check
> + *
> + * Used to check that the current set of parameters can be handled by
> + * the phy. Implementations are free to tune the parameters passed as
> + * arguments if needed by some implementation detail or
> + * constraints. It will not change any actual configuration of the
> + * PHY, so calling it as many times as deemed fit will have no side
> + * effect.
> + *
> + * Returns: 0 if successful, an negative error code otherwise
> + */
> +int phy_validate(struct phy *phy, enum phy_mode mode,
> + union phy_configure_opts *opts)
We are planning to switch to mode/submode combination [1], so this might have
to change.
Thanks
Kishon
[1] -> https://patchwork.kernel.org/cover/10673295/
> +{
> + int ret;
> +
> + if (!phy)
> + return -EINVAL;
> +
> + if (!phy->ops->validate)
> + return -EOPNOTSUPP;
> +
> + mutex_lock(>mutex);
> + ret = phy->ops->validate(phy, mode, opts);
> + mutex_unlock(>mutex);
> +
> + return ret;
> +}
> +
> +/**
> * _of_phy_get() - lookup and obtain a reference to a phy by phandle
> * @np: device_node for which to get the phy
> * @index: the index of the phy
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index d5c2ac7369f2..89cf8b685546 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -46,6 +46,12 @@ enum phy_mode {
> };
>
> /**
> + * union phy_configure_opts - Opaque generic phy configuration
> + */
> +union phy_configure_opts {
> +};
> +
> +/**
> * struct phy_ops - set of function pointers for performing phy operations
> * @init: operation to be performed for initializing phy
> * @exit: operation to be performed while exiting
> @@ -62,6 +68,37 @@ struct phy_ops {
> int (*power_on)(struct phy *phy);
> int (*power_off)(struct phy *phy);
> int (*set_mode)(struct phy *phy, enum phy_mode mode);
> +
> + /**
> + * @configure:
> + *
> + * Optional.
> + *
> + * Used to change the PHY parameters. phy_init() must have
> + * been called on the phy.
> + *
> + * Returns: 0 if successful, an negative error code otherwise
> + */
> + int (*configure)(struct phy *phy, union phy_configure_opts *opts);
> +
> + /**
> + * @validate:
> + *
> + * Optional.
> + *
> + * Used to check that the current set of parameters can be
> + * handled by the phy.
[RFC] mm: Replace all open encodings for NUMA_NO_NODE
At present there are multiple places where invalid node number is encoded
as -1. Even though implicitly understood it is always better to have macros
in there. Replace these open encodings for an invalid node number with the
global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like
'invalid node' from various places redirecting them to a common definition.
Signed-off-by: Anshuman Khandual
---
Build tested this with multiple cross compiler options like alpha, sparc,
arm64, x86, powerpc64le etc with their default config which might not have
compiled tested all driver related changes. I will appreciate folks giving
this a test in their respective build environment.
All these places for replacement were found by running the following grep
patterns on the entire kernel code. Please let me know if this might have
missed some instances. This might also have replaced some false positives.
I will appreciate suggestions, inputs and review.
1. git grep "nid == -1"
2. git grep "node == -1"
3. git grep "nid = -1"
4. git grep "node = -1"
arch/alpha/include/asm/topology.h | 2 +-
arch/ia64/kernel/numa.c | 2 +-
arch/ia64/mm/discontig.c | 6 +++---
arch/ia64/sn/kernel/io_common.c | 2 +-
arch/powerpc/include/asm/pci-bridge.h | 2 +-
arch/powerpc/kernel/paca.c| 2 +-
arch/powerpc/kernel/pci-common.c | 2 +-
arch/powerpc/mm/numa.c| 14 +++---
arch/powerpc/platforms/powernv/memtrace.c | 4 ++--
arch/sparc/kernel/auxio_32.c | 2 +-
arch/sparc/kernel/pci_fire.c | 2 +-
arch/sparc/kernel/pci_schizo.c| 2 +-
arch/sparc/kernel/pcic.c | 6 +++---
arch/sparc/kernel/psycho_common.c | 2 +-
arch/sparc/kernel/sbus.c | 2 +-
arch/sparc/mm/init_64.c | 6 +++---
arch/sparc/prom/init_32.c | 2 +-
arch/sparc/prom/init_64.c | 4 ++--
arch/sparc/prom/tree_32.c | 12 ++--
arch/sparc/prom/tree_64.c | 18 +-
arch/x86/include/asm/pci.h| 2 +-
arch/x86/kernel/apic/x2apic_uv_x.c| 6 +++---
arch/x86/kernel/smpboot.c | 2 +-
arch/x86/platform/olpc/olpc_dt.c | 16
drivers/block/mtip32xx/mtip32xx.c | 4 ++--
drivers/dma/dmaengine.c | 3 ++-
drivers/infiniband/hw/hfi1/affinity.c | 2 +-
drivers/infiniband/hw/hfi1/init.c | 2 +-
drivers/iommu/dmar.c | 4 ++--
drivers/iommu/intel-iommu.c | 2 +-
drivers/media/pci/ivtv/ivtvfb.c | 2 +-
drivers/media/platform/vivid/vivid-osd.c | 2 +-
drivers/misc/sgi-xp/xpc_uv.c | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++--
drivers/video/fbdev/mmp/fb/mmpfb.c| 2 +-
drivers/video/fbdev/pxa168fb.c| 2 +-
drivers/video/fbdev/w100fb.c | 2 +-
fs/ocfs2/dlm/dlmcommon.h | 2 +-
fs/ocfs2/dlm/dlmdomain.c | 10 +-
fs/ocfs2/dlm/dlmmaster.c | 2 +-
fs/ocfs2/dlm/dlmrecovery.c| 2 +-
fs/ocfs2/stack_user.c | 6 +++---
init/init_task.c | 2 +-
kernel/kthread.c | 2 +-
kernel/sched/fair.c | 15 ---
lib/cpumask.c | 2 +-
mm/huge_memory.c | 12 ++--
mm/hugetlb.c | 2 +-
mm/ksm.c | 2 +-
mm/memory.c | 6 +++---
mm/memory_hotplug.c | 12 ++--
mm/mempolicy.c| 2 +-
mm/page_alloc.c | 4 ++--
mm/page_ext.c | 2 +-
net/core/pktgen.c | 2 +-
net/qrtr/qrtr.c | 2 +-
tools/perf/bench/numa.c | 6 +++---
57 files changed, 125 insertions(+), 123 deletions(-)
diff --git a/arch/alpha/include/asm/topology.h
b/arch/alpha/include/asm/topology.h
index e6e13a8..f6dc89c 100644
--- a/arch/alpha/include/asm/topology.h
+++ b/arch/alpha/include/asm/topology.h
@@ -29,7 +29,7 @@ static const struct cpumask *cpumask_of_node(int node)
{
int cpu;
- if (node == -1)
+ if (node == NUMA_NO_NODE)
return cpu_all_mask;
cpumask_clear(_to_cpumask_map[node]);
diff --git a/arch/ia64/kernel/numa.c b/arch/ia64/kernel/numa.c
index 92c3762..1315da6 100644
--- a/arch/ia64/kernel/numa.c
+++ b/arch/ia64/kernel/numa.c
@@ -74,7 +74,7 @@ void
Re: [PATCH v2 8/9] phy: Add Cadence D-PHY support
Hi Maxime,
On 06/11/18 8:24 PM, Maxime Ripard wrote:
> Cadence has designed a D-PHY that can be used by the, currently in tree,
> DSI bridge (DRM), CSI Transceiver and CSI Receiver (v4l2) drivers.
>
> Only the DSI driver has an ad-hoc driver for that phy at the moment, while
> the v4l2 drivers are completely missing any phy support. In order to make
> that phy support available to all these drivers, without having to
> duplicate that code three times, let's create a generic phy framework
> driver.
>
> Signed-off-by: Maxime Ripard
> ---
> Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt | 21 +-
> Documentation/devicetree/bindings/phy/cdns,dphy.txt | 20 +-
> drivers/phy/cadence/Kconfig | 13 +-
> drivers/phy/cadence/Makefile | 1 +-
> drivers/phy/cadence/cdns-dphy.c | 459 +++-
> 5 files changed, 492 insertions(+), 22 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt
> create mode 100644 drivers/phy/cadence/cdns-dphy.c
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
> b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
> index f5725bb6c61c..525a4bfd8634 100644
> --- a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
> @@ -31,28 +31,7 @@ Required subnodes:
> - one subnode per DSI device connected on the DSI bus. Each DSI device should
>contain a reg property encoding its virtual channel.
>
> -Cadence DPHY
> -
> -
> -Cadence DPHY block.
> -
> -Required properties:
> -- compatible: should be set to "cdns,dphy".
> -- reg: physical base address and length of the DPHY registers.
> -- clocks: DPHY reference clocks.
> -- clock-names: must contain "psm" and "pll_ref".
> -- #phy-cells: must be set to 0.
> -
> -
> Example:
> - dphy0: dphy@fd0e{
> - compatible = "cdns,dphy";
> - reg = <0x0 0xfd0e 0x0 0x1000>;
> - clocks = <_clk>, <_ref_clk>;
> - clock-names = "psm", "pll_ref";
> - #phy-cells = <0>;
> - };
> -
> dsi0: dsi@fd0c {
> compatible = "cdns,dsi";
> reg = <0x0 0xfd0c 0x0 0x1000>;
> diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.txt
> b/Documentation/devicetree/bindings/phy/cdns,dphy.txt
> new file mode 100644
> index ..1095bc4e72d9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/cdns,dphy.txt
> @@ -0,0 +1,20 @@
> +Cadence DPHY
> +
> +
> +Cadence DPHY block.
> +
> +Required properties:
> +- compatible: should be set to "cdns,dphy".
> +- reg: physical base address and length of the DPHY registers.
> +- clocks: DPHY reference clocks.
> +- clock-names: must contain "psm" and "pll_ref".
> +- #phy-cells: must be set to 0.
> +
> +Example:
> + dphy0: dphy@fd0e{
> + compatible = "cdns,dphy";
> + reg = <0x0 0xfd0e 0x0 0x1000>;
> + clocks = <_clk>, <_ref_clk>;
> + clock-names = "psm", "pll_ref";
> + #phy-cells = <0>;
> + };
> diff --git a/drivers/phy/cadence/Kconfig b/drivers/phy/cadence/Kconfig
> index 57fff7de4031..240effa81046 100644
> --- a/drivers/phy/cadence/Kconfig
> +++ b/drivers/phy/cadence/Kconfig
> @@ -1,6 +1,7 @@
> #
> -# Phy driver for Cadence MHDP DisplayPort controller
> +# Phy drivers for Cadence IPs
> #
> +
> config PHY_CADENCE_DP
> tristate "Cadence MHDP DisplayPort PHY driver"
> depends on OF
> @@ -8,3 +9,13 @@ config PHY_CADENCE_DP
> select GENERIC_PHY
> help
> Support for Cadence MHDP DisplayPort PHY.
> +
> +config PHY_CADENCE_DPHY
> + tristate "Cadence D-PHY Support"
> + depends on HAS_IOMEM && OF
> + select GENERIC_PHY
> + select GENERIC_PHY_MIPI_DPHY
> + help
> + Choose this option if you have a Cadence D-PHY in your
> + system. If M is selected, the module will be called
> + cdns-csi.
> diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile
> index e5b0a11cf28a..64cb9ea66ceb 100644
> --- a/drivers/phy/cadence/Makefile
> +++ b/drivers/phy/cadence/Makefile
> @@ -1 +1,2 @@
> obj-$(CONFIG_PHY_CADENCE_DP) += phy-cadence-dp.o
> +obj-$(CONFIG_PHY_CADENCE_DPHY) += cdns-dphy.o
> diff --git a/drivers/phy/cadence/cdns-dphy.c b/drivers/phy/cadence/cdns-dphy.c
> new file mode 100644
> index ..a398b401e5d3
> --- /dev/null
> +++ b/drivers/phy/cadence/cdns-dphy.c
> @@ -0,0 +1,459 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright: 2017-2018 Cadence Design Systems, Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define REG_WAKEUP_TIME_NS 800
> +#define DPHY_PLL_RATE_HZ 10800
> +
> +/* DPHY registers */
Re: [RFC] mm: Replace all open encodings for NUMA_NO_NODE
On 11/12/2018 09:27 AM, Joseph Qi wrote: > For ocfs2 part, node means host in the cluster, not NUMA node. > Does not -1 indicate an invalid node which can never be present ? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] mm: Replace all open encodings for NUMA_NO_NODE
On 11/12/2018 02:13 PM, Hans Verkuil wrote: > On 11/12/2018 03:41 AM, Anshuman Khandual wrote: >> At present there are multiple places where invalid node number is encoded >> as -1. Even though implicitly understood it is always better to have macros >> in there. Replace these open encodings for an invalid node number with the >> global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like >> 'invalid node' from various places redirecting them to a common definition. >> >> Signed-off-by: Anshuman Khandual >> --- >> Build tested this with multiple cross compiler options like alpha, sparc, >> arm64, x86, powerpc64le etc with their default config which might not have >> compiled tested all driver related changes. I will appreciate folks giving >> this a test in their respective build environment. >> >> All these places for replacement were found by running the following grep >> patterns on the entire kernel code. Please let me know if this might have >> missed some instances. This might also have replaced some false positives. >> I will appreciate suggestions, inputs and review. > The 'node' in the drivers/media and the drivers/video sources has nothing to > do with numa. It's an index for a framebuffer instead (i.e. the X in > /dev/fbX). Thanks for the input. Will drop the changes there. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108704] 4.19 amdgpu Tonga powerplay regressions
https://bugs.freedesktop.org/show_bug.cgi?id=108704 --- Comment #2 from Alex Deucher --- If not, can you bisect? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere
Am Montag, 12. November 2018, 16:01:14 CET schrieb Maarten Lankhorst:
> We already have __drm_atomic_helper_connector_reset() and
> __drm_atomic_helper_plane_reset(), extend this to crtc as well.
>
> Most drivers already have a gpu reset hook, correct it.
> Nouveau already implemented its own __drm_atomic_helper_crtc_reset(),
> convert it to the common one.
>
> Signed-off-by: Maarten Lankhorst
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index fb70fb486fbf..d2d5aa676084 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -1071,13 +1071,14 @@ static void vop_crtc_destroy(struct drm_crtc *crtc)
>
> static void vop_crtc_reset(struct drm_crtc *crtc)
> {
> + struct rockchip_crtc_state *crtc_state =
> + kzalloc(sizeof(*crtc_state), GFP_KERNEL);
> +
> if (crtc->state)
> __drm_atomic_helper_crtc_destroy_state(crtc->state);
> kfree(crtc->state);
>
> - crtc->state = kzalloc(sizeof(struct rockchip_crtc_state), GFP_KERNEL);
> - if (crtc->state)
> - crtc->state->crtc = crtc;
> + __drm_atomic_helper_crtc_reset(crtc, _state->base);
> }
>
> static struct drm_crtc_state *vop_crtc_duplicate_state(struct drm_crtc *crtc)
for the Rockchip-part
Acked-by: Heiko Stuebner
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere
On Mon, Nov 12, 2018 at 04:01:14PM +0100, Maarten Lankhorst wrote: > We already have __drm_atomic_helper_connector_reset() and > __drm_atomic_helper_plane_reset(), extend this to crtc as well. > > Most drivers already have a gpu reset hook, correct it. > Nouveau already implemented its own __drm_atomic_helper_crtc_reset(), > convert it to the common one. > > Signed-off-by: Maarten Lankhorst > Cc: Harry Wentland > Cc: Leo Li > Cc: Alex Deucher > Cc: "Christian König" > Cc: "David (ChunMing) Zhou" > Cc: David Airlie > Cc: Liviu Dudau > Cc: Brian Starkey > Cc: Mali DP Maintainers > Cc: Boris Brezillon > Cc: Nicolas Ferre > Cc: Alexandre Belloni > Cc: Ludovic Desroches > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Sean Paul > Cc: Jani Nikula > Cc: Joonas Lahtinen > Cc: Rodrigo Vivi > Cc: Philipp Zabel > Cc: CK Hu > Cc: Matthias Brugger > Cc: Rob Clark > Cc: Ben Skeggs > Cc: Tomi Valkeinen > Cc: Laurent Pinchart > Cc: Kieran Bingham > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: Thierry Reding > Cc: Jonathan Hunter > Cc: Eric Anholt > Cc: VMware Graphics > Cc: Sinclair Yeh > Cc: Thomas Hellstrom > Cc: Tony Cheng > Cc: Shirish S > Cc: Mikita Lipski > Cc: Bhawanpreet Lakha > Cc: David Francis > Cc: Anthony Koo > Cc: Jeykumar Sankaran > Cc: Jordan Crouse > Cc: Bruce Wang > Cc: Sravanthi Kollukuduru > Cc: Archit Taneja > Cc: Steve Kowalik > Cc: Carsten Behling > Cc: Haneen Mohammed > Cc: Daniel Vetter > Cc: Rodrigo Siqueira > Cc: Mahesh Kumar > Cc: amd-...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-ker...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: intel-...@lists.freedesktop.org > Cc: linux-media...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-te...@vger.kernel.org > --- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +-- > drivers/gpu/drm/arm/malidp_crtc.c | 5 +-- > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 5 +-- > drivers/gpu/drm/drm_atomic_state_helper.c | 31 --- > drivers/gpu/drm/i915/intel_display.c | 2 +- > drivers/gpu/drm/imx/ipuv3-crtc.c | 5 +-- > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 5 +-- > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 ++- > drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 6 +--- > drivers/gpu/drm/nouveau/dispnv50/head.c | 13 ++-- > drivers/gpu/drm/omapdrm/omap_crtc.c | 7 ++--- > drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 4 +-- > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +++-- > drivers/gpu/drm/tegra/dc.c| 5 +-- > drivers/gpu/drm/vc4/vc4_crtc.c| 8 ++--- > drivers/gpu/drm/vkms/vkms_crtc.c | 7 + > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 +- > include/drm/drm_atomic_state_helper.h | 2 ++ > 18 files changed, 56 insertions(+), 81 deletions(-) Looks good to me: Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 3/5] drm: Document variable refresh properties
On 2018-11-08 9:43 a.m., Nicholas Kazlauskas wrote: > These include the drm_connector 'vrr_capable' and the drm_crtc > 'vrr_enabled' properties. > > Signed-off-by: Nicholas Kazlauskas > Cc: Harry Wentland > Cc: Manasi Navare > Cc: Pekka Paalanen > Cc: Ville Syrjälä > Cc: Michel Dänzer Looks good. Whole series is Reviewed-by: Harry Wentland How are we with the userspace patches? We should probably hold off pushing the kernel patches until the userspace work is all reviewed. Harry > --- > Documentation/gpu/drm-kms.rst | 7 > drivers/gpu/drm/drm_connector.c | 68 + > 2 files changed, 75 insertions(+) > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > index 4b1501b4835b..8da2a178cf85 100644 > --- a/Documentation/gpu/drm-kms.rst > +++ b/Documentation/gpu/drm-kms.rst > @@ -575,6 +575,13 @@ Explicit Fencing Properties > .. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c > :doc: explicit fencing properties > > + > +Variable Refresh Properties > +--- > + > +.. kernel-doc:: drivers/gpu/drm/drm_connector.c > + :doc: Variable refresh properties > + > Existing KMS Properties > --- > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index 49290060ab7b..0e4287461997 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -1255,6 +1255,74 @@ int drm_mode_create_scaling_mode_property(struct > drm_device *dev) > } > EXPORT_SYMBOL(drm_mode_create_scaling_mode_property); > > +/** > + * DOC: Variable refresh properties > + * > + * Variable refresh rate capable displays can dynamically adjust their > + * refresh rate by extending the duration of their vertical front porch > + * until page flip or timeout occurs. This can reduce or remove stuttering > + * and latency in scenarios where the page flip does not align with the > + * vblank interval. > + * > + * An example scenario would be an application flipping at a constant rate > + * of 48Hz on a 60Hz display. The page flip will frequently miss the vblank > + * interval and the same contents will be displayed twice. This can be > + * observed as stuttering for content with motion. > + * > + * If variable refresh rate was active on a display that supported a > + * variable refresh range from 35Hz to 60Hz no stuttering would be observable > + * for the example scenario. The minimum supported variable refresh rate of > + * 35Hz is below the page flip frequency and the vertical front porch can > + * be extended until the page flip occurs. The vblank interval will be > + * directly aligned to the page flip rate. > + * > + * Not all userspace content is suitable for use with variable refresh rate. > + * Large and frequent changes in vertical front porch duration may worsen > + * perceived stuttering for input sensitive applications. > + * > + * Panel brightness will also vary with vertical front porch duration. Some > + * panels may have noticeable differences in brightness between the minimum > + * vertical front porch duration and the maximum vertical front porch > duration. > + * Large and frequent changes in vertical front porch duration may produce > + * observable flickering for such panels. > + * > + * Userspace control for variable refresh rate is supported via properties > + * on the _connector and _crtc objects. > + * > + * "vrr_capable": > + * Optional _connector boolean property that drivers should attach > + * with drm_connector_attach_vrr_capable_property() on connectors that > + * could support variable refresh rates. Drivers should update the > + * property value by calling drm_connector_set_vrr_capable_property(). > + * > + * Absence of the property should indicate absence of support. > + * > + * "vrr_enabled": > + * Default _crtc boolean property that notifies the driver that the > + * content on the CRTC is suitable for variable refresh rate presentation. > + * The driver will take this property as a hint to enable variable > + * refresh rate support if the receiver supports it, ie. if the > + * "vrr_capable" property is true on the _connector object. The > + * vertical front porch duration will be extended until page-flip or > + * timeout when enabled. > + * > + * The minimum vertical front porch duration is defined as the vertical > + * front porch duration for the current mode. > + * > + * The maximum vertical front porch duration is greater than or equal to > + * the minimum vertical front porch duration. The duration is derived > + * from the minimum supported variable refresh rate for the connector. > + * > + * The driver may place further restrictions within these minimum > + * and maximum bounds. > + * > + * The semantics for the vertical blank timestamp differ when > + * variable refresh rate is active. The vertical blank timestamp > + * is defined to be an estimate using the current mode's fixed > +
[PATCH 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere
We already have __drm_atomic_helper_connector_reset() and
__drm_atomic_helper_plane_reset(), extend this to crtc as well.
Most drivers already have a gpu reset hook, correct it.
Nouveau already implemented its own __drm_atomic_helper_crtc_reset(),
convert it to the common one.
Signed-off-by: Maarten Lankhorst
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: David Airlie
Cc: Liviu Dudau
Cc: Brian Starkey
Cc: Mali DP Maintainers
Cc: Boris Brezillon
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc: Ludovic Desroches
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Philipp Zabel
Cc: CK Hu
Cc: Matthias Brugger
Cc: Rob Clark
Cc: Ben Skeggs
Cc: Tomi Valkeinen
Cc: Laurent Pinchart
Cc: Kieran Bingham
Cc: Sandy Huang
Cc: "Heiko Stübner"
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: Eric Anholt
Cc: VMware Graphics
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Cc: Tony Cheng
Cc: Shirish S
Cc: Mikita Lipski
Cc: Bhawanpreet Lakha
Cc: David Francis
Cc: Anthony Koo
Cc: Jeykumar Sankaran
Cc: Jordan Crouse
Cc: Bruce Wang
Cc: Sravanthi Kollukuduru
Cc: Archit Taneja
Cc: Steve Kowalik
Cc: Carsten Behling
Cc: Haneen Mohammed
Cc: Daniel Vetter
Cc: Rodrigo Siqueira
Cc: Mahesh Kumar
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: intel-...@lists.freedesktop.org
Cc: linux-media...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: linux-renesas-...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-te...@vger.kernel.org
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +--
drivers/gpu/drm/arm/malidp_crtc.c | 5 +--
.../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 5 +--
drivers/gpu/drm/drm_atomic_state_helper.c | 31 ---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/imx/ipuv3-crtc.c | 5 +--
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 5 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 ++-
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 6 +---
drivers/gpu/drm/nouveau/dispnv50/head.c | 13 ++--
drivers/gpu/drm/omapdrm/omap_crtc.c | 7 ++---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 4 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +++--
drivers/gpu/drm/tegra/dc.c| 5 +--
drivers/gpu/drm/vc4/vc4_crtc.c| 8 ++---
drivers/gpu/drm/vkms/vkms_crtc.c | 7 +
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 +-
include/drm/drm_atomic_state_helper.h | 2 ++
18 files changed, 56 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 5064768642f3..770a71726cd1 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2802,9 +2802,7 @@ static void dm_crtc_reset_state(struct drm_crtc *crtc)
if (WARN_ON(!state))
return;
- crtc->state = >base;
- crtc->state->crtc = crtc;
-
+ __drm_atomic_helper_crtc_reset(crtc, >base);
}
static struct drm_crtc_state *
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index e1b72782848c..9a924ff27148 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -474,10 +474,7 @@ static void malidp_crtc_reset(struct drm_crtc *crtc)
kfree(state);
state = kzalloc(sizeof(*state), GFP_KERNEL);
- if (state) {
- crtc->state = >base;
- crtc->state->crtc = crtc;
- }
+ __drm_atomic_helper_crtc_reset(crtc, >base);
}
static void malidp_crtc_destroy_state(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 96f4082671fe..8084d549c7d1 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -412,10 +412,7 @@ static void atmel_hlcdc_crtc_reset(struct drm_crtc *crtc)
}
state = kzalloc(sizeof(*state), GFP_KERNEL);
- if (state) {
- crtc->state = >base;
- crtc->state->crtc = crtc;
- }
+ __drm_atomic_helper_crtc_reset(crtc, >base);
}
static struct drm_crtc_state *
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 3ba996069d69..3eee1ca33fc5 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -55,6 +55,29 @@
* for these functions.
*/
+/**
+ * __drm_atomic_helper_crtc_reset - reset state on CRTC
+ * @crtc: drm CRTC
+ * @crtc_state: CRTC
[PATCH 1/2] drm/vc4: Fix memory leak during gpu reset.
__drm_atomic_helper_crtc_destroy_state does not free memory, it only
cleans it up. Fix this by calling the functions own destroy function.
Fixes: 6d6e50039187 ("drm/vc4: Allocate the right amount of space for boot-time
CRTC state.")
Cc: Eric Anholt
Cc: # v4.6+
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 3ce136ba8791..cd226e63d557 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -999,7 +999,7 @@ static void
vc4_crtc_reset(struct drm_crtc *crtc)
{
if (crtc->state)
- __drm_atomic_helper_crtc_destroy_state(crtc->state);
+ vc4_crtc_destroy_state(crtc->state);
crtc->state = kzalloc(sizeof(struct vc4_crtc_state), GFP_KERNEL);
if (crtc->state)
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere
On Mon, 12 Nov 2018 16:01:14 +0100 Maarten Lankhorst wrote: > We already have __drm_atomic_helper_connector_reset() and > __drm_atomic_helper_plane_reset(), extend this to crtc as well. > > Most drivers already have a gpu reset hook, correct it. > Nouveau already implemented its own __drm_atomic_helper_crtc_reset(), > convert it to the common one. > > Signed-off-by: Maarten Lankhorst > Cc: Harry Wentland > Cc: Leo Li > Cc: Alex Deucher > Cc: "Christian König" > Cc: "David (ChunMing) Zhou" > Cc: David Airlie > Cc: Liviu Dudau > Cc: Brian Starkey > Cc: Mali DP Maintainers > Cc: Boris Brezillon > Cc: Nicolas Ferre > Cc: Alexandre Belloni > Cc: Ludovic Desroches > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Sean Paul > Cc: Jani Nikula > Cc: Joonas Lahtinen > Cc: Rodrigo Vivi > Cc: Philipp Zabel > Cc: CK Hu > Cc: Matthias Brugger > Cc: Rob Clark > Cc: Ben Skeggs > Cc: Tomi Valkeinen > Cc: Laurent Pinchart > Cc: Kieran Bingham > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: Thierry Reding > Cc: Jonathan Hunter > Cc: Eric Anholt > Cc: VMware Graphics > Cc: Sinclair Yeh > Cc: Thomas Hellstrom > Cc: Tony Cheng > Cc: Shirish S > Cc: Mikita Lipski > Cc: Bhawanpreet Lakha > Cc: David Francis > Cc: Anthony Koo > Cc: Jeykumar Sankaran > Cc: Jordan Crouse > Cc: Bruce Wang > Cc: Sravanthi Kollukuduru > Cc: Archit Taneja > Cc: Steve Kowalik > Cc: Carsten Behling > Cc: Haneen Mohammed > Cc: Daniel Vetter > Cc: Rodrigo Siqueira > Cc: Mahesh Kumar > Cc: amd-...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-ker...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: intel-...@lists.freedesktop.org > Cc: linux-media...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-te...@vger.kernel.org > --- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +-- > drivers/gpu/drm/arm/malidp_crtc.c | 5 +-- > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 5 +-- For the atmel-hlcdc driver Acked-by: Boris Brezillon ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere
On 2018-11-12 10:01 AM, Maarten Lankhorst wrote:
> We already have __drm_atomic_helper_connector_reset() and
> __drm_atomic_helper_plane_reset(), extend this to crtc as well.
>
> Most drivers already have a gpu reset hook, correct it.
> Nouveau already implemented its own __drm_atomic_helper_crtc_reset(),
> convert it to the common one.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
> Cc: David Airlie
> Cc: Liviu Dudau
> Cc: Brian Starkey
> Cc: Mali DP Maintainers
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Philipp Zabel
> Cc: CK Hu
> Cc: Matthias Brugger
> Cc: Rob Clark
> Cc: Ben Skeggs
> Cc: Tomi Valkeinen
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: Sandy Huang
> Cc: "Heiko Stübner"
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: Eric Anholt
> Cc: VMware Graphics
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> Cc: Tony Cheng
> Cc: Shirish S
> Cc: Mikita Lipski
> Cc: Bhawanpreet Lakha
> Cc: David Francis
> Cc: Anthony Koo
> Cc: Jeykumar Sankaran
> Cc: Jordan Crouse
> Cc: Bruce Wang
> Cc: Sravanthi Kollukuduru
> Cc: Archit Taneja
> Cc: Steve Kowalik
> Cc: Carsten Behling
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Mahesh Kumar
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: intel-...@lists.freedesktop.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-te...@vger.kernel.org
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +--
> drivers/gpu/drm/arm/malidp_crtc.c | 5 +--
> .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 5 +--
> drivers/gpu/drm/drm_atomic_state_helper.c | 31 ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> drivers/gpu/drm/imx/ipuv3-crtc.c | 5 +--
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 5 +--
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 ++-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 6 +---
> drivers/gpu/drm/nouveau/dispnv50/head.c | 13 ++--
> drivers/gpu/drm/omapdrm/omap_crtc.c | 7 ++---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 4 +--
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +++--
> drivers/gpu/drm/tegra/dc.c| 5 +--
> drivers/gpu/drm/vc4/vc4_crtc.c| 8 ++---
> drivers/gpu/drm/vkms/vkms_crtc.c | 7 +
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 +-
> include/drm/drm_atomic_state_helper.h | 2 ++
> 18 files changed, 56 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 5064768642f3..770a71726cd1 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2802,9 +2802,7 @@ static void dm_crtc_reset_state(struct drm_crtc *crtc)
> if (WARN_ON(!state))
> return;
>
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> -
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static struct drm_crtc_state *
> diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
> b/drivers/gpu/drm/arm/malidp_crtc.c
> index e1b72782848c..9a924ff27148 100644
> --- a/drivers/gpu/drm/arm/malidp_crtc.c
> +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> @@ -474,10 +474,7 @@ static void malidp_crtc_reset(struct drm_crtc *crtc)
>
> kfree(state);
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> - }
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static void malidp_crtc_destroy_state(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index 96f4082671fe..8084d549c7d1 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -412,10 +412,7 @@ static void atmel_hlcdc_crtc_reset(struct drm_crtc *crtc)
> }
>
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> - }
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static struct drm_crtc_state *
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
>
Re: [PATCH] drm/syncobj: Fix compilation following partial revert
On Mon, Nov 12, 2018 at 03:21:30PM +, Chris Wilson wrote:
> We need to include the revert of commit 783195ec1cad ("drm/syncobj:
> disable the timeline UAPI for now v2") along with undoing the change to
> drm/i915.
>
> Fixes: 131280a162e7 ("drm: Revert syncobj timeline changes.")
> Signed-off-by: Chris Wilson
Thanks for your patch, Chris. I've applied it to -misc-next
Sean
> Cc: Christian König
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/drm_syncobj.c | 4
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
> 2 files changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 90e0a6dce086..e2c5b3ca4824 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -277,10 +277,6 @@ int drm_syncobj_create(struct drm_syncobj **out_syncobj,
> uint32_t flags,
> int ret;
> struct drm_syncobj *syncobj;
>
> - /* Disabled for now */
> - if (flags & DRM_SYNCOBJ_CREATE_TYPE_TIMELINE)
> - return -EINVAL;
> -
> syncobj = kzalloc(sizeof(struct drm_syncobj), GFP_KERNEL);
> if (!syncobj)
> return -ENOMEM;
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 1a1c04db6c80..1aaccbe7e1de 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -2157,7 +2157,7 @@ await_fence_array(struct i915_execbuffer *eb,
> if (!(flags & I915_EXEC_FENCE_WAIT))
> continue;
>
> - drm_syncobj_search_fence(syncobj, 0, 0, );
> + fence = drm_syncobj_fence_get(syncobj);
> if (!fence)
> return -EINVAL;
>
> --
> 2.19.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere
On 2018-11-12 10:01 a.m., Maarten Lankhorst wrote:
> We already have __drm_atomic_helper_connector_reset() and
> __drm_atomic_helper_plane_reset(), extend this to crtc as well.
>
> Most drivers already have a gpu reset hook, correct it.
> Nouveau already implemented its own __drm_atomic_helper_crtc_reset(),
> convert it to the common one.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
> Cc: David Airlie
> Cc: Liviu Dudau
> Cc: Brian Starkey
> Cc: Mali DP Maintainers
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Philipp Zabel
> Cc: CK Hu
> Cc: Matthias Brugger
> Cc: Rob Clark
> Cc: Ben Skeggs
> Cc: Tomi Valkeinen
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: Sandy Huang
> Cc: "Heiko Stübner"
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: Eric Anholt
> Cc: VMware Graphics
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> Cc: Tony Cheng
> Cc: Shirish S
> Cc: Mikita Lipski
> Cc: Bhawanpreet Lakha
> Cc: David Francis
> Cc: Anthony Koo
> Cc: Jeykumar Sankaran
> Cc: Jordan Crouse
> Cc: Bruce Wang
> Cc: Sravanthi Kollukuduru
> Cc: Archit Taneja
> Cc: Steve Kowalik
> Cc: Carsten Behling
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Mahesh Kumar
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: intel-...@lists.freedesktop.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-te...@vger.kernel.org
For amdgpu_dm and core changes
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +--
> drivers/gpu/drm/arm/malidp_crtc.c | 5 +--
> .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 5 +--
> drivers/gpu/drm/drm_atomic_state_helper.c | 31 ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> drivers/gpu/drm/imx/ipuv3-crtc.c | 5 +--
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 5 +--
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 ++-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 6 +---
> drivers/gpu/drm/nouveau/dispnv50/head.c | 13 ++--
> drivers/gpu/drm/omapdrm/omap_crtc.c | 7 ++---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 4 +--
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +++--
> drivers/gpu/drm/tegra/dc.c| 5 +--
> drivers/gpu/drm/vc4/vc4_crtc.c| 8 ++---
> drivers/gpu/drm/vkms/vkms_crtc.c | 7 +
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 +-
> include/drm/drm_atomic_state_helper.h | 2 ++
> 18 files changed, 56 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 5064768642f3..770a71726cd1 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2802,9 +2802,7 @@ static void dm_crtc_reset_state(struct drm_crtc *crtc)
> if (WARN_ON(!state))
> return;
>
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> -
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static struct drm_crtc_state *
> diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
> b/drivers/gpu/drm/arm/malidp_crtc.c
> index e1b72782848c..9a924ff27148 100644
> --- a/drivers/gpu/drm/arm/malidp_crtc.c
> +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> @@ -474,10 +474,7 @@ static void malidp_crtc_reset(struct drm_crtc *crtc)
>
> kfree(state);
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> - }
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static void malidp_crtc_destroy_state(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index 96f4082671fe..8084d549c7d1 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -412,10 +412,7 @@ static void atmel_hlcdc_crtc_reset(struct drm_crtc *crtc)
> }
>
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> - }
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static struct drm_crtc_state *
> diff --git
[Bug 108704] 4.19 amdgpu Tonga powerplay regressions
https://bugs.freedesktop.org/show_bug.cgi?id=108704 --- Comment #1 from Alex Deucher --- Does this patch fix the issue? https://patchwork.freedesktop.org/patch/259364/ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Fix compilation failure
From: Sean Paul
We had competing reverts/disable commits go in that caused issues with
each other.
Christian committed 783195ec1cad ("drm/syncobj: disable the timeline UAPI for
now v2"), which moved the CREATE_TYPE_TIMELINE #define internally and added a
check in drm_syncobj.c. When Eric reverted the entire timeline patch, he cleaned
up the #define in the new location, but failed to remove the check, causing the
boom.
The error:
../drivers/gpu/drm/drm_syncobj.c: In function ‘drm_syncobj_create’:
../drivers/gpu/drm/drm_syncobj.c:281:14: error:
‘DRM_SYNCOBJ_CREATE_TYPE_TIMELINE’ undeclared (first use in this function); did
you mean ‘DRM_SYNCOBJ_CREATE_SIGNALED’?
if (flags & DRM_SYNCOBJ_CREATE_TYPE_TIMELINE)
^~~~
DRM_SYNCOBJ_CREATE_SIGNALED
../drivers/gpu/drm/drm_syncobj.c:281:14: note: each undeclared identifier is
reported only once for each function it appears in
Fixes: 131280a162e7 ("drm: Revert syncobj timeline changes.")
Cc: Chunming Zhou
Cc: Christian König
Cc: Daniel Vetter
Cc: Eric Anholt
Cc: Joonas Lahtinen
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_syncobj.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 90e0a6dce086..e2c5b3ca4824 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -277,10 +277,6 @@ int drm_syncobj_create(struct drm_syncobj **out_syncobj,
uint32_t flags,
int ret;
struct drm_syncobj *syncobj;
- /* Disabled for now */
- if (flags & DRM_SYNCOBJ_CREATE_TYPE_TIMELINE)
- return -EINVAL;
-
syncobj = kzalloc(sizeof(struct drm_syncobj), GFP_KERNEL);
if (!syncobj)
return -ENOMEM;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/syncobj: Fix compilation following partial revert
Am 12.11.18 um 16:21 schrieb Chris Wilson:
We need to include the revert of commit 783195ec1cad ("drm/syncobj:
disable the timeline UAPI for now v2") along with undoing the change to
drm/i915.
Fixes: 131280a162e7 ("drm: Revert syncobj timeline changes.")
Signed-off-by: Chris Wilson
Cc: Christian König
Cc: Daniel Vetter
Reviewed-by: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 4
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 90e0a6dce086..e2c5b3ca4824 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -277,10 +277,6 @@ int drm_syncobj_create(struct drm_syncobj **out_syncobj,
uint32_t flags,
int ret;
struct drm_syncobj *syncobj;
- /* Disabled for now */
- if (flags & DRM_SYNCOBJ_CREATE_TYPE_TIMELINE)
- return -EINVAL;
-
syncobj = kzalloc(sizeof(struct drm_syncobj), GFP_KERNEL);
if (!syncobj)
return -ENOMEM;
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1a1c04db6c80..1aaccbe7e1de 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2157,7 +2157,7 @@ await_fence_array(struct i915_execbuffer *eb,
if (!(flags & I915_EXEC_FENCE_WAIT))
continue;
- drm_syncobj_search_fence(syncobj, 0, 0, );
+ fence = drm_syncobj_fence_get(syncobj);
if (!fence)
return -EINVAL;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix compilation failure
On Mon, Nov 12, 2018 at 10:54 AM Sean Paul wrote:
>
> From: Sean Paul
>
Just saw Chris posted a fix to the list, please disregard this.
Sean
> We had competing reverts/disable commits go in that caused issues with
> each other.
>
> Christian committed 783195ec1cad ("drm/syncobj: disable the timeline UAPI for
> now v2"), which moved the CREATE_TYPE_TIMELINE #define internally and added a
> check in drm_syncobj.c. When Eric reverted the entire timeline patch, he
> cleaned
> up the #define in the new location, but failed to remove the check, causing
> the
> boom.
>
> The error:
>
> ../drivers/gpu/drm/drm_syncobj.c: In function ‘drm_syncobj_create’:
> ../drivers/gpu/drm/drm_syncobj.c:281:14: error:
> ‘DRM_SYNCOBJ_CREATE_TYPE_TIMELINE’ undeclared (first use in this function);
> did you mean ‘DRM_SYNCOBJ_CREATE_SIGNALED’?
> if (flags & DRM_SYNCOBJ_CREATE_TYPE_TIMELINE)
> ^~~~
> DRM_SYNCOBJ_CREATE_SIGNALED
> ../drivers/gpu/drm/drm_syncobj.c:281:14: note: each undeclared identifier is
> reported only once for each function it appears in
>
> Fixes: 131280a162e7 ("drm: Revert syncobj timeline changes.")
> Cc: Chunming Zhou
> Cc: Christian König
> Cc: Daniel Vetter
> Cc: Eric Anholt
> Cc: Joonas Lahtinen
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/drm_syncobj.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 90e0a6dce086..e2c5b3ca4824 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -277,10 +277,6 @@ int drm_syncobj_create(struct drm_syncobj **out_syncobj,
> uint32_t flags,
> int ret;
> struct drm_syncobj *syncobj;
>
> - /* Disabled for now */
> - if (flags & DRM_SYNCOBJ_CREATE_TYPE_TIMELINE)
> - return -EINVAL;
> -
> syncobj = kzalloc(sizeof(struct drm_syncobj), GFP_KERNEL);
> if (!syncobj)
> return -ENOMEM;
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99923] HITMAN (2016) having lighting and artefacting, and overly light room.
https://bugs.freedesktop.org/show_bug.cgi?id=99923 --- Comment #45 from Gregor Münch --- Thats very good news. Thx for the effort! I just checked that with Vulkan the game works but standard opengl crash on start. Will contact support. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/12] drm/msm: dpu: Handle crtc pm_runtime_resume() directly
From: Sean Paul
Instead of registering through dpu_power_handle just to get a call on
runtime_resume, call the crtc function directly.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 23 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 10 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 8
4 files changed, 20 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index e09209d6c469..c55cb751e2b4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -33,7 +33,6 @@
#include "dpu_plane.h"
#include "dpu_encoder.h"
#include "dpu_vbif.h"
-#include "dpu_power_handle.h"
#include "dpu_core_perf.h"
#include "dpu_trace.h"
@@ -69,8 +68,6 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
if (!crtc)
return;
- dpu_crtc->phandle = NULL;
-
drm_crtc_cleanup(crtc);
mutex_destroy(_crtc->crtc_lock);
kfree(dpu_crtc);
@@ -844,15 +841,17 @@ static struct drm_crtc_state
*dpu_crtc_duplicate_state(struct drm_crtc *crtc)
return >base;
}
-static void dpu_crtc_handle_power_event(u32 event_type, void *arg)
+void dpu_crtc_runtime_resume(struct drm_crtc *crtc)
{
- struct drm_crtc *crtc = arg;
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
struct drm_encoder *encoder;
mutex_lock(_crtc->crtc_lock);
- trace_dpu_crtc_handle_power_event(DRMID(crtc), event_type);
+ if (!dpu_crtc->enabled)
+ goto end;
+
+ trace_dpu_crtc_runtime_resume(DRMID(crtc));
/* restore encoder; crtc will be programmed during commit */
drm_for_each_encoder(encoder, crtc->dev) {
@@ -862,6 +861,7 @@ static void dpu_crtc_handle_power_event(u32 event_type,
void *arg)
dpu_encoder_virt_restore(encoder);
}
+end:
mutex_unlock(_crtc->crtc_lock);
}
@@ -917,10 +917,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
dpu_encoder_register_frame_event_callback(encoder, NULL, NULL);
}
- if (dpu_crtc->power_event)
- dpu_power_handle_unregister_event(dpu_crtc->phandle,
- dpu_crtc->power_event);
-
memset(cstate->mixers, 0, sizeof(cstate->mixers));
cstate->num_mixers = 0;
@@ -972,11 +968,6 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
/* Enable/restore vblank irq handling */
drm_crtc_vblank_on(crtc);
-
- dpu_crtc->power_event = dpu_power_handle_register_event(
- dpu_crtc->phandle, DPU_POWER_EVENT_ENABLE,
- dpu_crtc_handle_power_event, crtc, dpu_crtc->name);
-
}
struct plane_state {
@@ -1522,8 +1513,6 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev,
struct drm_plane *plane,
/* initialize event handling */
spin_lock_init(_crtc->event_lock);
- dpu_crtc->phandle = >phandle;
-
DPU_DEBUG("%s: successfully initialized crtc\n", dpu_crtc->name);
return crtc;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index 4822602402f9..1dca91d1210f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -151,7 +151,6 @@ struct dpu_crtc_frame_event {
* @event_worker : Event worker queue
* @event_lock: Spinlock around event handling code
* @phandle: Pointer to power handler
- * @power_event : registered power event handle
* @cur_perf : current performance committed to clock/bandwidth driver
*/
struct dpu_crtc {
@@ -187,9 +186,6 @@ struct dpu_crtc {
/* for handling internal event thread */
spinlock_t event_lock;
- struct dpu_power_handle *phandle;
- struct dpu_power_event *power_event;
-
struct dpu_core_perf_params cur_perf;
struct dpu_crtc_smmu_state_data smmu_state;
@@ -333,4 +329,10 @@ static inline bool dpu_crtc_is_enabled(struct drm_crtc
*crtc)
return crtc ? crtc->enabled : false;
}
+/**
+ * dpu_crtc_runtime_resume - called by the top-level on pm_runtime_resume
+ * @crtc: CRTC to resume
+ */
+void dpu_crtc_runtime_resume(struct drm_crtc *crtc);
+
#endif /* _DPU_CRTC_H_ */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index ae2bbaae923d..62a02c606811 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1140,6 +1140,7 @@ static int __maybe_unused dpu_runtime_resume(struct
device *dev)
int rc = -1;
struct platform_device *pdev = to_platform_device(dev);
struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
+ struct drm_crtc *crtc;
struct drm_device *ddev;
struct dss_module_power *mp = _kms->mp;
@@ -1157,6 +1158,9 @@ static int
[PATCH 03/12] drm/msm: dpu: Remove dpu_power_client
From: Sean Paul
There's only one client -- core, and it's only used for runtime pm which
is already refcounted.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 22 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 -
.../gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 96 +--
.../gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 86 +
4 files changed, 6 insertions(+), 199 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 985c855796ae..23094d108e81 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -676,11 +676,6 @@ static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms)
dpu_hw_catalog_deinit(dpu_kms->catalog);
dpu_kms->catalog = NULL;
- if (dpu_kms->core_client)
- dpu_power_client_destroy(_kms->phandle,
- dpu_kms->core_client);
- dpu_kms->core_client = NULL;
-
if (dpu_kms->vbif[VBIF_NRT])
devm_iounmap(_kms->pdev->dev, dpu_kms->vbif[VBIF_NRT]);
dpu_kms->vbif[VBIF_NRT] = NULL;
@@ -913,17 +908,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
dpu_kms->reg_dma_len = dpu_iomap_size(dpu_kms->pdev, "regdma");
}
- dpu_kms->core_client = dpu_power_client_create(_kms->phandle,
- "core");
- if (IS_ERR_OR_NULL(dpu_kms->core_client)) {
- rc = PTR_ERR(dpu_kms->core_client);
- if (!dpu_kms->core_client)
- rc = -EINVAL;
- DPU_ERROR("dpu power client create failed: %d\n", rc);
- dpu_kms->core_client = NULL;
- goto error;
- }
-
pm_runtime_get_sync(_kms->pdev->dev);
_dpu_kms_core_hw_rev_init(dpu_kms);
@@ -1157,8 +1141,7 @@ static int __maybe_unused dpu_runtime_suspend(struct
device *dev)
return rc;
}
- rc = dpu_power_resource_enable(_kms->phandle,
- dpu_kms->core_client, false);
+ rc = dpu_power_resource_enable(_kms->phandle, false);
if (rc)
DPU_ERROR("resource disable failed: %d\n", rc);
@@ -1189,8 +1172,7 @@ static int __maybe_unused dpu_runtime_resume(struct
device *dev)
return rc;
}
- rc = dpu_power_resource_enable(_kms->phandle,
- dpu_kms->core_client, true);
+ rc = dpu_power_resource_enable(_kms->phandle, true);
if (rc)
DPU_ERROR("resource enable failed: %d\n", rc);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 2a3625eef6d3..f2c78deb0854 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -114,7 +114,6 @@ struct dpu_kms {
struct dpu_mdss_cfg *catalog;
struct dpu_power_handle phandle;
- struct dpu_power_client *core_client;
struct dpu_power_event *power_event;
/* directory entry for debugfs */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
index 8c6f92aaaf87..8e64f0a52147 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
@@ -35,59 +35,11 @@ static void dpu_power_event_trigger_locked(struct
dpu_power_handle *phandle,
}
}
-struct dpu_power_client *dpu_power_client_create(
- struct dpu_power_handle *phandle, char *client_name)
-{
- struct dpu_power_client *client;
- static u32 id;
-
- if (!client_name || !phandle) {
- pr_err("client name is null or invalid power data\n");
- return ERR_PTR(-EINVAL);
- }
-
- client = kzalloc(sizeof(struct dpu_power_client), GFP_KERNEL);
- if (!client)
- return ERR_PTR(-ENOMEM);
-
- mutex_lock(>phandle_lock);
- strlcpy(client->name, client_name, MAX_CLIENT_NAME_LEN);
- client->usecase_ndx = VOTE_INDEX_DISABLE;
- client->id = id;
- client->active = true;
- pr_debug("client %s created:%pK id :%d\n", client_name,
- client, id);
- id++;
- list_add(>list, >power_client_clist);
- mutex_unlock(>phandle_lock);
-
- return client;
-}
-
-void dpu_power_client_destroy(struct dpu_power_handle *phandle,
- struct dpu_power_client *client)
-{
- if (!client || !phandle) {
- pr_err("reg bus vote: invalid client handle\n");
- } else if (!client->active) {
- pr_err("dpu power deinit already done\n");
- kfree(client);
- } else {
- pr_debug("bus vote client %s destroyed:%pK id:%u\n",
- client->name, client, client->id);
- mutex_lock(>phandle_lock);
- list_del_init(>list);
-
[PATCH 04/12] drm/msm: dpu: Don't use power_event for vbif_init_memtypes
From: Sean Paul
power_events are only used for pm_runtime, and that's all handled in
dpu_kms. So just call vbif_init_memtypes at the correct times.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 21 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 -
2 files changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 23094d108e81..ae2bbaae923d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -651,10 +651,6 @@ static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms)
dpu_hw_intr_destroy(dpu_kms->hw_intr);
dpu_kms->hw_intr = NULL;
- if (dpu_kms->power_event)
- dpu_power_handle_unregister_event(
- _kms->phandle, dpu_kms->power_event);
-
/* safe to call these more than once during shutdown */
_dpu_debugfs_destroy(dpu_kms);
_dpu_kms_mmu_destroy(dpu_kms);
@@ -832,16 +828,6 @@ u64 dpu_kms_get_clk_rate(struct dpu_kms *dpu_kms, char
*clock_name)
return clk_get_rate(clk->clk);
}
-static void dpu_kms_handle_power_event(u32 event_type, void *usr)
-{
- struct dpu_kms *dpu_kms = usr;
-
- if (!dpu_kms)
- return;
-
- dpu_vbif_init_memtypes(dpu_kms);
-}
-
static int dpu_kms_hw_init(struct msm_kms *kms)
{
struct dpu_kms *dpu_kms;
@@ -1015,10 +1001,7 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
/*
* Handle (re)initializations during power enable
*/
- dpu_kms_handle_power_event(DPU_POWER_EVENT_ENABLE, dpu_kms);
- dpu_kms->power_event = dpu_power_handle_register_event(
- _kms->phandle, DPU_POWER_EVENT_ENABLE,
- dpu_kms_handle_power_event, dpu_kms, "kms");
+ dpu_vbif_init_memtypes(dpu_kms);
pm_runtime_put_sync(_kms->pdev->dev);
@@ -1172,6 +1155,8 @@ static int __maybe_unused dpu_runtime_resume(struct
device *dev)
return rc;
}
+ dpu_vbif_init_memtypes(dpu_kms);
+
rc = dpu_power_resource_enable(_kms->phandle, true);
if (rc)
DPU_ERROR("resource enable failed: %d\n", rc);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index f2c78deb0854..5f08be187c86 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -114,7 +114,6 @@ struct dpu_kms {
struct dpu_mdss_cfg *catalog;
struct dpu_power_handle phandle;
- struct dpu_power_event *power_event;
/* directory entry for debugfs */
struct dentry *debugfs_root;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/12] drm/msm: dpu: Add ->enabled to dpu_encoder_virt
From: Sean Paul
Add a bool to dpu_encoder_virt to track whether the encoder is enabled
or not. Repurpose the enc_lock mutex to ensure that it is consistent
with the hw state.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 27 +
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 10a0676d1dcf..3daa86220d47 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -132,6 +132,7 @@ enum dpu_enc_rc_states {
* @base: drm_encoder base class for registration with DRM
* @enc_spinlock: Virtual-Encoder-Wide Spin Lock for IRQ purposes
* @bus_scaling_client:Client handle to the bus scaling interface
+ * @enabled: True if the encoder is active, protected by enc_lock
* @num_phys_encs: Actual number of physical encoders contained.
* @phys_encs: Container of physical encoders managed.
* @cur_master:Pointer to the current master in this mode.
Optimization
@@ -148,8 +149,8 @@ enum dpu_enc_rc_states {
* all CTL paths
* @crtc_kickoff_cb_data: Opaque user data given to crtc_kickoff_cb
* @debugfs_root: Debug file system root file node
- * @enc_lock: Lock around physical encoder create/destroy and
- access.
+ * @enc_lock: Lock around physical encoder
+ * create/destroy/enable/disable
* @frame_busy_mask: Bitmask tracking which phys_enc we are still
* busy processing current command.
* Bit0 = phys_encs[0] etc.
@@ -175,6 +176,8 @@ struct dpu_encoder_virt {
spinlock_t enc_spinlock;
uint32_t bus_scaling_client;
+ bool enabled;
+
unsigned int num_phys_encs;
struct dpu_encoder_phys *phys_encs[MAX_PHYS_ENCODERS_PER_VIRTUAL];
struct dpu_encoder_phys *cur_master;
@@ -1121,6 +1124,8 @@ static void dpu_encoder_virt_enable(struct drm_encoder
*drm_enc)
return;
}
dpu_enc = to_dpu_encoder_virt(drm_enc);
+
+ mutex_lock(_enc->enc_lock);
cur_mode = _enc->base.crtc->state->adjusted_mode;
trace_dpu_enc_enable(DRMID(drm_enc), cur_mode->hdisplay,
@@ -1137,10 +1142,15 @@ static void dpu_encoder_virt_enable(struct drm_encoder
*drm_enc)
if (ret) {
DPU_ERROR_ENC(dpu_enc, "dpu resource control failed: %d\n",
ret);
- return;
+ goto out;
}
_dpu_encoder_virt_enable_helper(drm_enc);
+
+ dpu_enc->enabled = true;
+
+out:
+ mutex_unlock(_enc->enc_lock);
}
static void dpu_encoder_virt_disable(struct drm_encoder *drm_enc)
@@ -1162,11 +1172,14 @@ static void dpu_encoder_virt_disable(struct drm_encoder
*drm_enc)
return;
}
- mode = _enc->crtc->state->adjusted_mode;
-
dpu_enc = to_dpu_encoder_virt(drm_enc);
DPU_DEBUG_ENC(dpu_enc, "\n");
+ mutex_lock(_enc->enc_lock);
+ dpu_enc->enabled = false;
+
+ mode = _enc->crtc->state->adjusted_mode;
+
priv = drm_enc->dev->dev_private;
dpu_kms = to_dpu_kms(priv->kms);
@@ -1200,6 +1213,8 @@ static void dpu_encoder_virt_disable(struct drm_encoder
*drm_enc)
DPU_DEBUG_ENC(dpu_enc, "encoder disabled\n");
dpu_rm_release(_kms->rm, drm_enc);
+
+ mutex_unlock(_enc->enc_lock);
}
static enum dpu_intf dpu_encoder_get_intf(struct dpu_mdss_cfg *catalog,
@@ -2233,6 +2248,8 @@ struct drm_encoder *dpu_encoder_init(struct drm_device
*dev,
drm_encoder_helper_add(_enc->base, _encoder_helper_funcs);
+ dpu_enc->enabled = false;
+
return _enc->base;
}
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/12] drm/msm: dpu: Move crtc runtime resume to encoder
From: Sean Paul
The crtc runtime resume doesn't actually operate on the crtc, but rather
its encoders. The problem with this is that we need to inspect the crtc
state to get the currently connected encoders. Since runtime resume
isn't guaranteed to be called while holding the modeset locks (although
it sometimes is), this presents a race condition.
Now that we have ->enabled on the virtual encoders, and a lock to
protect it, just call resume on each encoder and only restore the ones
that are enabled.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 24 -
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h| 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 24 +
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 +++---
5 files changed, 15 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index d8f58caf2772..9be24907f8c1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -841,30 +841,6 @@ static struct drm_crtc_state
*dpu_crtc_duplicate_state(struct drm_crtc *crtc)
return >base;
}
-void dpu_crtc_runtime_resume(struct drm_crtc *crtc)
-{
- struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
- struct drm_encoder *encoder;
-
- mutex_lock(_crtc->crtc_lock);
-
- if (!dpu_crtc->enabled)
- goto end;
-
- trace_dpu_crtc_runtime_resume(DRMID(crtc));
-
- /* restore encoder; crtc will be programmed during commit */
- drm_for_each_encoder(encoder, crtc->dev) {
- if (encoder->crtc != crtc)
- continue;
-
- dpu_encoder_virt_restore(encoder);
- }
-
-end:
- mutex_unlock(_crtc->crtc_lock);
-}
-
static void dpu_crtc_disable(struct drm_crtc *crtc)
{
struct dpu_crtc *dpu_crtc;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index 1dca91d1210f..93d21a61a040 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -329,10 +329,4 @@ static inline bool dpu_crtc_is_enabled(struct drm_crtc
*crtc)
return crtc ? crtc->enabled : false;
}
-/**
- * dpu_crtc_runtime_resume - called by the top-level on pm_runtime_resume
- * @crtc: CRTC to resume
- */
-void dpu_crtc_runtime_resume(struct drm_crtc *crtc);
-
#endif /* _DPU_CRTC_H_ */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 3daa86220d47..d89ac520f7e6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1089,28 +1089,24 @@ static void _dpu_encoder_virt_enable_helper(struct
drm_encoder *drm_enc)
_dpu_encoder_update_vsync_source(dpu_enc, _enc->disp_info);
}
-void dpu_encoder_virt_restore(struct drm_encoder *drm_enc)
+void dpu_encoder_virt_runtime_resume(struct drm_encoder *drm_enc)
{
- struct dpu_encoder_virt *dpu_enc = NULL;
- int i;
-
- if (!drm_enc) {
- DPU_ERROR("invalid encoder\n");
- return;
- }
- dpu_enc = to_dpu_encoder_virt(drm_enc);
+ struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(drm_enc);
- for (i = 0; i < dpu_enc->num_phys_encs; i++) {
- struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
+ mutex_lock(_enc->enc_lock);
- if (phys && (phys != dpu_enc->cur_master) && phys->ops.restore)
- phys->ops.restore(phys);
- }
+ if (!dpu_enc->enabled)
+ goto out;
+ if (dpu_enc->cur_slave && dpu_enc->cur_slave->ops.restore)
+ dpu_enc->cur_slave->ops.restore(dpu_enc->cur_slave);
if (dpu_enc->cur_master && dpu_enc->cur_master->ops.restore)
dpu_enc->cur_master->ops.restore(dpu_enc->cur_master);
_dpu_encoder_virt_enable_helper(drm_enc);
+
+out:
+ mutex_unlock(_enc->enc_lock);
}
static void dpu_encoder_virt_enable(struct drm_encoder *drm_enc)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index 9dbf38f446d9..aa4f135218fa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -126,10 +126,10 @@ int dpu_encoder_wait_for_event(struct drm_encoder
*drm_encoder,
enum dpu_intf_mode dpu_encoder_get_intf_mode(struct drm_encoder *encoder);
/**
- * dpu_encoder_virt_restore - restore the encoder configs
+ * dpu_encoder_virt_runtime_resume - pm runtime resume the encoder configs
* @encoder: encoder pointer
*/
-void dpu_encoder_virt_restore(struct drm_encoder *encoder);
+void dpu_encoder_virt_runtime_resume(struct drm_encoder *encoder);
/**
* dpu_encoder_init - initialize virtual encoder object
diff --git
Re: [RFC] mm: Replace all open encodings for NUMA_NO_NODE
On 11/12/2018 03:41 AM, Anshuman Khandual wrote: > At present there are multiple places where invalid node number is encoded > as -1. Even though implicitly understood it is always better to have macros > in there. Replace these open encodings for an invalid node number with the > global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like > 'invalid node' from various places redirecting them to a common definition. > > Signed-off-by: Anshuman Khandual > --- > Build tested this with multiple cross compiler options like alpha, sparc, > arm64, x86, powerpc64le etc with their default config which might not have > compiled tested all driver related changes. I will appreciate folks giving > this a test in their respective build environment. > > All these places for replacement were found by running the following grep > patterns on the entire kernel code. Please let me know if this might have > missed some instances. This might also have replaced some false positives. > I will appreciate suggestions, inputs and review. The 'node' in the drivers/media and the drivers/video sources has nothing to do with numa. It's an index for a framebuffer instead (i.e. the X in /dev/fbX). Regards, Hans > > 1. git grep "nid == -1" > 2. git grep "node == -1" > 3. git grep "nid = -1" > 4. git grep "node = -1" > > arch/alpha/include/asm/topology.h | 2 +- > arch/ia64/kernel/numa.c | 2 +- > arch/ia64/mm/discontig.c | 6 +++--- > arch/ia64/sn/kernel/io_common.c | 2 +- > arch/powerpc/include/asm/pci-bridge.h | 2 +- > arch/powerpc/kernel/paca.c| 2 +- > arch/powerpc/kernel/pci-common.c | 2 +- > arch/powerpc/mm/numa.c| 14 +++--- > arch/powerpc/platforms/powernv/memtrace.c | 4 ++-- > arch/sparc/kernel/auxio_32.c | 2 +- > arch/sparc/kernel/pci_fire.c | 2 +- > arch/sparc/kernel/pci_schizo.c| 2 +- > arch/sparc/kernel/pcic.c | 6 +++--- > arch/sparc/kernel/psycho_common.c | 2 +- > arch/sparc/kernel/sbus.c | 2 +- > arch/sparc/mm/init_64.c | 6 +++--- > arch/sparc/prom/init_32.c | 2 +- > arch/sparc/prom/init_64.c | 4 ++-- > arch/sparc/prom/tree_32.c | 12 ++-- > arch/sparc/prom/tree_64.c | 18 +- > arch/x86/include/asm/pci.h| 2 +- > arch/x86/kernel/apic/x2apic_uv_x.c| 6 +++--- > arch/x86/kernel/smpboot.c | 2 +- > arch/x86/platform/olpc/olpc_dt.c | 16 > drivers/block/mtip32xx/mtip32xx.c | 4 ++-- > drivers/dma/dmaengine.c | 3 ++- > drivers/infiniband/hw/hfi1/affinity.c | 2 +- > drivers/infiniband/hw/hfi1/init.c | 2 +- > drivers/iommu/dmar.c | 4 ++-- > drivers/iommu/intel-iommu.c | 2 +- > drivers/media/pci/ivtv/ivtvfb.c | 2 +- > drivers/media/platform/vivid/vivid-osd.c | 2 +- > drivers/misc/sgi-xp/xpc_uv.c | 2 +- > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++-- > drivers/video/fbdev/mmp/fb/mmpfb.c| 2 +- > drivers/video/fbdev/pxa168fb.c| 2 +- > drivers/video/fbdev/w100fb.c | 2 +- > fs/ocfs2/dlm/dlmcommon.h | 2 +- > fs/ocfs2/dlm/dlmdomain.c | 10 +- > fs/ocfs2/dlm/dlmmaster.c | 2 +- > fs/ocfs2/dlm/dlmrecovery.c| 2 +- > fs/ocfs2/stack_user.c | 6 +++--- > init/init_task.c | 2 +- > kernel/kthread.c | 2 +- > kernel/sched/fair.c | 15 --- > lib/cpumask.c | 2 +- > mm/huge_memory.c | 12 ++-- > mm/hugetlb.c | 2 +- > mm/ksm.c | 2 +- > mm/memory.c | 6 +++--- > mm/memory_hotplug.c | 12 ++-- > mm/mempolicy.c| 2 +- > mm/page_alloc.c | 4 ++-- > mm/page_ext.c | 2 +- > net/core/pktgen.c | 2 +- > net/qrtr/qrtr.c | 2 +- > tools/perf/bench/numa.c | 6 +++--- > 57 files changed, 125 insertions(+), 123 deletions(-) > > diff --git a/arch/alpha/include/asm/topology.h > b/arch/alpha/include/asm/topology.h > index e6e13a8..f6dc89c 100644 > --- a/arch/alpha/include/asm/topology.h > +++ b/arch/alpha/include/asm/topology.h > @@ -29,7
Re: [PATCH 2/2] drm: Revert syncobj timeline changes.
Am 09.11.18 um 23:26 schrieb Eric Anholt:
Eric Anholt writes:
[ Unknown signature status ]
zhoucm1 writes:
On 2018年11月09日 00:52, Christian König wrote:
Am 08.11.18 um 17:07 schrieb Koenig, Christian:
Am 08.11.18 um 17:04 schrieb Eric Anholt:
Daniel suggested I submit this, since we're still seeing regressions
from it. This is a revert to before 48197bc564c7 ("drm: add syncobj
timeline support v9") and its followon fixes.
This is a harmless false positive from lockdep, Chouming and I are
already working on a fix.
On the other hand we had enough trouble with that patch, so if it
really bothers you feel free to add my Acked-by: Christian König
and push it.
NAK, please no, I don't think this needed, the Warning totally isn't
related to syncobj timeline, but fence-array implementation flaw, just
exposed by syncobj.
In addition, Christian already has a fix for this Warning, I've tested.
Please Christian send to public review.
I backed out my revert of #2 (#1 still necessary) after adding the
lockdep regression fix, and now my CTS run got oomkilled after just a
few hours, with these notable lines in the unreclaimable slab info list:
[ 6314.373099] drm_sched_fence69095KB 69095KB
[ 6314.373653] kmemleak_object 428249KB 428384KB
[ 6314.373736] kmalloc-262144 256KB256KB
[ 6314.373743] kmalloc-131072 128KB128KB
[ 6314.373750] kmalloc-65536 64KB 64KB
[ 6314.373756] kmalloc-32768 1472KB 1728KB
[ 6314.373763] kmalloc-16384 64KB 64KB
[ 6314.373770] kmalloc-8192 208KB208KB
[ 6314.373778] kmalloc-40962408KB 2408KB
[ 6314.373784] kmalloc-2048 288KB336KB
[ 6314.373792] kmalloc-10241457KB 1512KB
[ 6314.373800] kmalloc-512 854KB 1048KB
[ 6314.373808] kmalloc-256 188KB268KB
[ 6314.373817] kmalloc-19269141KB 69142KB
[ 6314.373824] kmalloc-64 47703KB 47704KB
[ 6314.373886] kmalloc-12846396KB 46396KB
[ 6314.373894] kmem_cache31KB 35KB
No results from kmemleak, though.
OK, it looks like the #2 revert probably isn't related to the OOM issue.
Running a single job on otherwise unused DRM, watching /proc/slabinfo
every second for drm_sched_fence, I get:
drm_sched_fence0 0192 211 : tunables 32 168 :
slabdata 0 0 0 : globalstat 0 0 0000
000 : cpustat 0 0 0 0
drm_sched_fence 16 21192 211 : tunables 32 168 :
slabdata 1 1 0 : globalstat 16 16 1000
000 : cpustat 5 1 6 0
drm_sched_fence 13 21192 211 : tunables 32 168 :
slabdata 1 1 0 : globalstat 16 16 1000
000 : cpustat 5 1 6 0
drm_sched_fence6 21192 211 : tunables 32 168 :
slabdata 1 1 0 : globalstat 16 16 1000
000 : cpustat 5 1 6 0
drm_sched_fence4 21192 211 : tunables 32 168 :
slabdata 1 1 0 : globalstat 16 16 1000
000 : cpustat 5 1 6 0
drm_sched_fence2 21192 211 : tunables 32 168 :
slabdata 1 1 0 : globalstat 16 16 1000
000 : cpustat 5 1 6 0
drm_sched_fence0 21192 211 : tunables 32 168 :
slabdata 0 1 0 : globalstat 16 16 1000
000 : cpustat 5 1 6 0
So we generate a ton of fences, and I guess free them slowly because of
RCU? And presumably kmemleak was sucking up lots of memory because of
how many of these objects were laying around.
That is certainly possible. Another possibility is that we don't drop
the reference in dma-fence-array early enough.
E.g. the dma-fence-array will keep the reference to its fences until it
is destroyed, which is a bit late when you chain multiple
dma-fence-array objects together.
David can you take a look at this and propose a fix? That would probably
be good to have fixed in dma-fence-array separately to the timeline work.
Thanks,
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere
On Mon, Nov 12, 2018 at 04:01:14PM +0100, Maarten Lankhorst wrote:
> We already have __drm_atomic_helper_connector_reset() and
> __drm_atomic_helper_plane_reset(), extend this to crtc as well.
>
> Most drivers already have a gpu reset hook, correct it.
> Nouveau already implemented its own __drm_atomic_helper_crtc_reset(),
> convert it to the common one.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
> Cc: David Airlie
> Cc: Liviu Dudau
> Cc: Brian Starkey
> Cc: Mali DP Maintainers
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Philipp Zabel
> Cc: CK Hu
> Cc: Matthias Brugger
> Cc: Rob Clark
> Cc: Ben Skeggs
> Cc: Tomi Valkeinen
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: Sandy Huang
> Cc: "Heiko Stübner"
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: Eric Anholt
> Cc: VMware Graphics
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> Cc: Tony Cheng
> Cc: Shirish S
> Cc: Mikita Lipski
> Cc: Bhawanpreet Lakha
> Cc: David Francis
> Cc: Anthony Koo
> Cc: Jeykumar Sankaran
> Cc: Jordan Crouse
> Cc: Bruce Wang
> Cc: Sravanthi Kollukuduru
> Cc: Archit Taneja
> Cc: Steve Kowalik
> Cc: Carsten Behling
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Mahesh Kumar
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: intel-...@lists.freedesktop.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-te...@vger.kernel.org
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +--
> drivers/gpu/drm/arm/malidp_crtc.c | 5 +--
> .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 5 +--
> drivers/gpu/drm/drm_atomic_state_helper.c | 31 ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> drivers/gpu/drm/imx/ipuv3-crtc.c | 5 +--
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 5 +--
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 ++-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 6 +---
> drivers/gpu/drm/nouveau/dispnv50/head.c | 13 ++--
> drivers/gpu/drm/omapdrm/omap_crtc.c | 7 ++---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 4 +--
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +++--
> drivers/gpu/drm/tegra/dc.c| 5 +--
> drivers/gpu/drm/vc4/vc4_crtc.c| 8 ++---
> drivers/gpu/drm/vkms/vkms_crtc.c | 7 +
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 +-
> include/drm/drm_atomic_state_helper.h | 2 ++
> 18 files changed, 56 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 3ba996069d69..3eee1ca33fc5 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -55,6 +55,29 @@
> * for these functions.
> */
>
> +/**
> + * __drm_atomic_helper_crtc_reset - reset state on CRTC
> + * @crtc: drm CRTC
> + * @crtc_state: CRTC state to assign
> + *
> + * Initializes the newly allocated @crtc_state and assigns it to
> + * the _conector->state pointer of @crtc, usually required when
> + * initializing the drivers or when called from the _crtc_funcs.reset
> + * hook.
> + *
> + * This is useful for drivers that subclass the CRTC state.
> + */
> +void
> +__drm_atomic_helper_crtc_reset(struct drm_crtc *crtc,
> +struct drm_crtc_state *crtc_state)
> +{
> + if (crtc_state)
> + crtc_state->crtc = crtc;
So apparently crtc and connector reset expect a NULL state, but plane
reset does not. That seems a bit inconsistent. Migth be nice to get
them all to agree on what is the correct behaviour.
> +
> + crtc->state = crtc_state;
> +}
> +EXPORT_SYMBOL(__drm_atomic_helper_crtc_reset);
> +
> /**
> * drm_atomic_helper_crtc_reset - default _crtc_funcs.reset hook for
> CRTCs
> * @crtc: drm CRTC
> @@ -64,14 +87,14 @@
> */
> void drm_atomic_helper_crtc_reset(struct drm_crtc *crtc)
> {
> + struct drm_crtc_state *crtc_state =
> + kzalloc(sizeof(*crtc->state), GFP_KERNEL);
> +
> if (crtc->state)
> __drm_atomic_helper_crtc_destroy_state(crtc->state);
>
> kfree(crtc->state);
> - crtc->state = kzalloc(sizeof(*crtc->state), GFP_KERNEL);
> -
> - if (crtc->state)
> - crtc->state->crtc = crtc;
> + __drm_atomic_helper_crtc_reset(crtc, crtc_state);
> }
>
Re: Performance regression in ast drm driver
Hi Jean Am 12.11.18 um 15:36 schrieb Jean Delvare: > Hi David, > > On Fri, 2018-11-09 at 10:04 +1000, David Airlie wrote: >> On Thu, Nov 8, 2018 at 10:05 PM Jean Delvare wrote: >>> >>> On Thu, 1 Nov 2018 16:27:07 +0100, Jean Delvare wrote: Hi David, The following commit: commit 7cf321d118a825c1541b43ca45294126fd474efa Author: Dave Airlie Date: Mon Oct 24 15:37:48 2016 +1000 drm/drivers: add support for using the arch wc mapping API. is causing a huge performance regression for the ast drm driver. In a text console, if I call "cat" on a large text file, it takes almost twice as much time to be displayed and scrolled completely. Can you please check that the ast driver portion of that commit is both correct and complete? >>> >>> And in the meantime, what bad will happen if we just revert the ast >>> portion of that commit? >> >> This seems likely to be a hw problem with PCI writes to the AST "GPU", >> since it's just some sort of RAM + ARM on the end of a PCIE bus, we've >> definitely seen possible issues in the past with write combining >> around some of the mga GPUs with some CPUs. > > Takashi asked me to compare the contents of > /sys/kernel/debug/x86/pat_memtype_list before and after the commit > above. Before the commit, we have: > > uncached-minus @ 0xfafe-0xfb00 > uncached-minus @ 0xfb00-0xfb005000 > write-combining @ 0xfb005000-0xfb584000 > > After the commit, we have: > > uncached-minus @ 0xfafe-0xfb00 > uncached-minus @ 0xfb00-0xfb005000 > uncached-minus @ 0xfb00-0xfb80 > uncached-minus @ 0xfb005000-0xfb584000 > > The corresponding lines in /proc/iomem are: > > f000-fed8 : PCI Bus :00 > faf0-fb7f : PCI Bus :01 > fafe-faff : :01:01.0 > fb00-fb7f : :01:01.0 > > Does it help? Is the change of type expected? Is it not a problem that > one of the ranges is overlapping with 2 other ranges? > I debugged this problem with an AST 2000. What happens is that the vesafb driver attaches first to the graphics device. It disables write-combining and falls back to uncached access; unless the kernel has been booted with video=vesafb:mtrr:3. Then it will set-up WC correctly. The respective code is at [1]. Best regards Thomas [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/video/fbdev/vesafb.c?h=v4.20-rc2#n415 -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, 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
[PATCH 00/12] drm/msm: dpu: Clean up runtime power handling
From: Sean Paul I started pulling a thread last week when looking at dpu locking. It led me into the power_handle code and eventually runtime suspend/resume. This set removes the power_handle stuff entirely. I'm sure it's more useful when there are multiple clients/handles/events, but for our case with one handle/client/event, it's just overcomplicating things. Once the power_handle code is out of the way, I added a few patches on the end that move the runtime resume code out of crtc and into encoder. The benefit of this is to avoid inspecting crtc->state without holding the modeset lock. There's also a few trivial changes sprinkled through the series. PTAL, Sean Sean Paul (12): drm/msm: dpu: Remove dpu_power_handle_get_dbus_name() drm/msm: dpu: Remove unused trace_dpu_perf_update_bus() drm/msm: dpu: Remove dpu_power_client drm/msm: dpu: Don't use power_event for vbif_init_memtypes drm/msm: dpu: Handle crtc pm_runtime_resume() directly drm/msm: dpu: Remove power_handle from core_perf drm/msm: dpu: Include dpu_io_util.h directly in dpu_kms.h drm/msm: dpu: Move DPU_POWER_HANDLE_DBUS_ID to core_perf drm/msm: dpu: Remove dpu_power_handle drm/msm: dpu: Fix typo in dpu_encoder drm/msm: dpu: Add ->enabled to dpu_encoder_virt drm/msm: dpu: Move crtc runtime resume to encoder drivers/gpu/drm/msm/Makefile | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 37 ++- drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 22 +- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 45 +--- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 4 - drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 53 ++-- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 4 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 53 +--- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 6 +- .../gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 240 -- .../gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 217 drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 29 +-- 12 files changed, 82 insertions(+), 629 deletions(-) delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/12] drm/msm: dpu: Remove unused trace_dpu_perf_update_bus()
From: Sean Paul
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 21 -
1 file changed, 21 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
index 0c122e173892..7ab0ba8224f6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
@@ -99,27 +99,6 @@ TRACE_EVENT(dpu_perf_set_ot,
__entry->vbif_idx)
)
-TRACE_EVENT(dpu_perf_update_bus,
- TP_PROTO(int client, unsigned long long ab_quota,
- unsigned long long ib_quota),
- TP_ARGS(client, ab_quota, ib_quota),
- TP_STRUCT__entry(
- __field(int, client)
- __field(u64, ab_quota)
- __field(u64, ib_quota)
- ),
- TP_fast_assign(
- __entry->client = client;
- __entry->ab_quota = ab_quota;
- __entry->ib_quota = ib_quota;
- ),
- TP_printk("Request client:%d ab=%llu ib=%llu",
- __entry->client,
- __entry->ab_quota,
- __entry->ib_quota)
-)
-
-
TRACE_EVENT(dpu_cmd_release_bw,
TP_PROTO(u32 crtc_id),
TP_ARGS(crtc_id),
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/12] drm/msm: dpu: Remove dpu_power_handle_get_dbus_name()
From: Sean Paul
It's only used for debugfs, so just output the enum value instead.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 14 --
drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 7 ---
3 files changed, 2 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index ed84cf44a222..e09209d6c469 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1381,11 +1381,9 @@ static int dpu_crtc_debugfs_state_show(struct seq_file
*s, void *v)
dpu_crtc->cur_perf.core_clk_rate);
for (i = DPU_POWER_HANDLE_DBUS_ID_MNOC;
i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
- seq_printf(s, "bw_ctl[%s]: %llu\n",
- dpu_power_handle_get_dbus_name(i),
+ seq_printf(s, "bw_ctl[%d]: %llu\n", i,
dpu_crtc->cur_perf.bw_ctl[i]);
- seq_printf(s, "max_per_pipe_ib[%s]: %llu\n",
- dpu_power_handle_get_dbus_name(i),
+ seq_printf(s, "max_per_pipe_ib[%d]: %llu\n", i,
dpu_crtc->cur_perf.max_per_pipe_ib[i]);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
index fc14116789f2..8c6f92aaaf87 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
@@ -24,20 +24,6 @@
#include "dpu_power_handle.h"
#include "dpu_trace.h"
-static const char *data_bus_name[DPU_POWER_HANDLE_DBUS_ID_MAX] = {
- [DPU_POWER_HANDLE_DBUS_ID_MNOC] = "qcom,dpu-data-bus",
- [DPU_POWER_HANDLE_DBUS_ID_LLCC] = "qcom,dpu-llcc-bus",
- [DPU_POWER_HANDLE_DBUS_ID_EBI] = "qcom,dpu-ebi-bus",
-};
-
-const char *dpu_power_handle_get_dbus_name(u32 bus_id)
-{
- if (bus_id < DPU_POWER_HANDLE_DBUS_ID_MAX)
- return data_bus_name[bus_id];
-
- return NULL;
-}
-
static void dpu_power_event_trigger_locked(struct dpu_power_handle *phandle,
u32 event_type)
{
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
index a65b7a297f21..f627ae28ec68 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
@@ -207,11 +207,4 @@ struct dpu_power_event *dpu_power_handle_register_event(
void dpu_power_handle_unregister_event(struct dpu_power_handle *phandle,
struct dpu_power_event *event);
-/**
- * dpu_power_handle_get_dbus_name - get name of given data bus identifier
- * @bus_id:data bus identifier
- * Return: Pointer to name string if success; NULL otherwise
- */
-const char *dpu_power_handle_get_dbus_name(u32 bus_id);
-
#endif /* _DPU_POWER_HANDLE_H_ */
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/12] drm/msm: dpu: Remove dpu_power_handle
From: Sean Paul
Now that we don't have any event handlers, remove dpu_power_handle!
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/Makefile | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 11 --
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 3 -
.../gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 136 --
.../gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 113 ---
5 files changed, 264 deletions(-)
delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 19ab521d4c3a..7d02ef3655b5 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -72,7 +72,6 @@ msm-y := \
disp/dpu1/dpu_kms.o \
disp/dpu1/dpu_mdss.o \
disp/dpu1/dpu_plane.o \
- disp/dpu1/dpu_power_handle.o \
disp/dpu1/dpu_rm.o \
disp/dpu1/dpu_vbif.o \
msm_atomic.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index bae7e86b2913..e42685a1d928 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1063,8 +1063,6 @@ static int dpu_bind(struct device *dev, struct device
*master, void *data)
return ret;
}
- dpu_power_resource_init(pdev, _kms->phandle);
-
platform_set_drvdata(pdev, dpu_kms);
msm_kms_init(_kms->base, _funcs);
@@ -1084,7 +1082,6 @@ static void dpu_unbind(struct device *dev, struct device
*master, void *data)
struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
struct dss_module_power *mp = _kms->mp;
- dpu_power_resource_deinit(pdev, _kms->phandle);
msm_dss_put_clk(mp->clk_config, mp->num_clk);
devm_kfree(>dev, mp->clk_config);
mp->num_clk = 0;
@@ -1123,10 +1120,6 @@ static int __maybe_unused dpu_runtime_suspend(struct
device *dev)
return rc;
}
- rc = dpu_power_resource_enable(_kms->phandle, false);
- if (rc)
- DPU_ERROR("resource disable failed: %d\n", rc);
-
rc = msm_dss_enable_clk(mp->clk_config, mp->num_clk, false);
if (rc)
DPU_ERROR("clock disable failed rc:%d\n", rc);
@@ -1160,10 +1153,6 @@ static int __maybe_unused dpu_runtime_resume(struct
device *dev)
drm_for_each_crtc(crtc, ddev)
dpu_crtc_runtime_resume(crtc);
- rc = dpu_power_resource_enable(_kms->phandle, true);
- if (rc)
- DPU_ERROR("resource enable failed: %d\n", rc);
-
return rc;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 4e5acacb3065..59e18e2d3c59 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -31,7 +31,6 @@
#include "dpu_hw_top.h"
#include "dpu_io_util.h"
#include "dpu_rm.h"
-#include "dpu_power_handle.h"
#include "dpu_irq.h"
#include "dpu_core_perf.h"
@@ -114,8 +113,6 @@ struct dpu_kms {
int core_rev;
struct dpu_mdss_cfg *catalog;
- struct dpu_power_handle phandle;
-
/* directory entry for debugfs */
struct dentry *debugfs_root;
struct dentry *debugfs_danger;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
deleted file mode 100644
index 8e64f0a52147..
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
+++ /dev/null
@@ -1,136 +0,0 @@
-/* Copyright (c) 2014-2018, The Linux Foundation. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- */
-
-#define pr_fmt(fmt)"[drm:%s:%d]: " fmt, __func__, __LINE__
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "dpu_power_handle.h"
-#include "dpu_trace.h"
-
-static void dpu_power_event_trigger_locked(struct dpu_power_handle *phandle,
- u32 event_type)
-{
- struct dpu_power_event *event;
-
- list_for_each_entry(event, >event_list, list) {
- if (event->event_type & event_type)
- event->cb_fnc(event_type, event->usr);
- }
-}
-
-void dpu_power_resource_init(struct platform_device *pdev,
- struct dpu_power_handle *phandle)
-{
- phandle->dev = >dev;
-
- INIT_LIST_HEAD(>event_list);
-
- mutex_init(>phandle_lock);
-}
-
-void dpu_power_resource_deinit(struct platform_device *pdev,
- struct
[PATCH 10/12] drm/msm: dpu: Fix typo in dpu_encoder
From: Sean Paul
enc_spinlock instead of enc_spin_lock.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 82c55efb500f..10a0676d1dcf 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -130,7 +130,7 @@ enum dpu_enc_rc_states {
* Virtual encoder defers as much as possible to the physical encoders.
* Virtual encoder registers itself with the DRM Framework as the encoder.
* @base: drm_encoder base class for registration with DRM
- * @enc_spin_lock: Virtual-Encoder-Wide Spin Lock for IRQ purposes
+ * @enc_spinlock: Virtual-Encoder-Wide Spin Lock for IRQ purposes
* @bus_scaling_client:Client handle to the bus scaling interface
* @num_phys_encs: Actual number of physical encoders contained.
* @phys_encs: Container of physical encoders managed.
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/12] drm/msm: dpu: Include dpu_io_util.h directly in dpu_kms.h
From: Sean Paul It's needed for struct dss_module_power, and is currently being pulled in by dpu_power_handle.h Signed-off-by: Sean Paul --- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h index 5f08be187c86..4e5acacb3065 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h @@ -29,6 +29,7 @@ #include "dpu_hw_lm.h" #include "dpu_hw_interrupts.h" #include "dpu_hw_top.h" +#include "dpu_io_util.h" #include "dpu_rm.h" #include "dpu_power_handle.h" #include "dpu_irq.h" -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/12] drm/msm: dpu: Move DPU_POWER_HANDLE_DBUS_ID to core_perf
From: Sean Paul
It's only used in core_perf, so stick it there (and change the name to
reflect that).
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 34 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 17 --
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 4 +--
.../gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 13 ---
4 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index ef6dd43f8bec..bffc51e496e7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -95,20 +95,20 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
memset(perf, 0, sizeof(struct dpu_core_perf_params));
if (!dpu_cstate->bw_control) {
- for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
+ for (i = 0; i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
perf->bw_ctl[i] = kms->catalog->perf.max_bw_high *
1000ULL;
perf->max_per_pipe_ib[i] = perf->bw_ctl[i];
}
perf->core_clk_rate = kms->perf.max_core_clk_rate;
} else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
- for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
+ for (i = 0; i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
perf->bw_ctl[i] = 0;
perf->max_per_pipe_ib[i] = 0;
}
perf->core_clk_rate = 0;
} else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED) {
- for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
+ for (i = 0; i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
perf->bw_ctl[i] = kms->perf.fix_core_ab_vote;
perf->max_per_pipe_ib[i] = kms->perf.fix_core_ib_vote;
}
@@ -118,12 +118,12 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
DPU_DEBUG(
"crtc=%d clk_rate=%llu core_ib=%llu core_ab=%llu llcc_ib=%llu
llcc_ab=%llu mem_ib=%llu mem_ab=%llu\n",
crtc->base.id, perf->core_clk_rate,
- perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_MNOC],
- perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_MNOC],
- perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_LLCC],
- perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_LLCC],
- perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_EBI],
- perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_EBI]);
+ perf->max_per_pipe_ib[DPU_CORE_PERF_DATA_BUS_ID_MNOC],
+ perf->bw_ctl[DPU_CORE_PERF_DATA_BUS_ID_MNOC],
+ perf->max_per_pipe_ib[DPU_CORE_PERF_DATA_BUS_ID_LLCC],
+ perf->bw_ctl[DPU_CORE_PERF_DATA_BUS_ID_LLCC],
+ perf->max_per_pipe_ib[DPU_CORE_PERF_DATA_BUS_ID_EBI],
+ perf->bw_ctl[DPU_CORE_PERF_DATA_BUS_ID_EBI]);
}
int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
@@ -158,8 +158,8 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
/* obtain new values */
_dpu_core_perf_calc_crtc(kms, crtc, state, _cstate->new_perf);
- for (i = DPU_POWER_HANDLE_DBUS_ID_MNOC;
- i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
+ for (i = DPU_CORE_PERF_DATA_BUS_ID_MNOC;
+ i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
bw_sum_of_intfs = dpu_cstate->new_perf.bw_ctl[i];
curr_client_type = dpu_crtc_get_client_type(crtc);
@@ -290,7 +290,7 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc)
if (kms->perf.enable_bw_release) {
trace_dpu_cmd_release_bw(crtc->base.id);
DPU_DEBUG("Release BW crtc=%d\n", crtc->base.id);
- for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
+ for (i = 0; i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
dpu_crtc->cur_perf.bw_ctl[i] = 0;
_dpu_core_perf_crtc_update_bus(kms, crtc, i);
}
@@ -367,7 +367,7 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
new = _cstate->new_perf;
if (_dpu_core_perf_crtc_is_power_on(crtc) && !stop_req) {
- for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
+ for (i = 0; i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
/*
* cases for bus bandwidth update.
* 1. new bandwidth vote - "ab or ib vote" is higher
@@ -409,13 +409,13 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
update_clk = 1;
}
trace_dpu_perf_crtc_update(crtc->base.id,
-
[PATCH 06/12] drm/msm: dpu: Remove power_handle from core_perf
From: Sean Paul
It's unused
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 3 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 5 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 -
3 files changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 22e84b3d7f98..ef6dd43f8bec 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -605,7 +605,6 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf)
dpu_core_perf_debugfs_destroy(perf);
perf->max_core_clk_rate = 0;
perf->core_clk = NULL;
- perf->phandle = NULL;
perf->catalog = NULL;
perf->dev = NULL;
}
@@ -613,12 +612,10 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf)
int dpu_core_perf_init(struct dpu_core_perf *perf,
struct drm_device *dev,
struct dpu_mdss_cfg *catalog,
- struct dpu_power_handle *phandle,
struct dss_clk *core_clk)
{
perf->dev = dev;
perf->catalog = catalog;
- perf->phandle = phandle;
perf->core_clk = core_clk;
perf->max_core_clk_rate = core_clk->max_rate;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
index fbcbe0c7527a..68b84d85eb8f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
@@ -19,7 +19,6 @@
#include
#include "dpu_hw_catalog.h"
-#include "dpu_power_handle.h"
#defineDPU_PERF_DEFAULT_MAX_CORE_CLK_RATE 41250
@@ -52,7 +51,6 @@ struct dpu_core_perf_tune {
* @dev: Pointer to drm device
* @debugfs_root: top level debug folder
* @catalog: Pointer to catalog configuration
- * @phandle: Pointer to power handler
* @core_clk: Pointer to core clock structure
* @core_clk_rate: current core clock rate
* @max_core_clk_rate: maximum allowable core clock rate
@@ -66,7 +64,6 @@ struct dpu_core_perf {
struct drm_device *dev;
struct dentry *debugfs_root;
struct dpu_mdss_cfg *catalog;
- struct dpu_power_handle *phandle;
struct dss_clk *core_clk;
u64 core_clk_rate;
u64 max_core_clk_rate;
@@ -113,13 +110,11 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf);
* @perf: Pointer to core performance context
* @dev: Pointer to drm device
* @catalog: Pointer to catalog
- * @phandle: Pointer to power handle
* @core_clk: pointer to core clock
*/
int dpu_core_perf_init(struct dpu_core_perf *perf,
struct drm_device *dev,
struct dpu_mdss_cfg *catalog,
- struct dpu_power_handle *phandle,
struct dss_clk *core_clk);
/**
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 62a02c606811..bae7e86b2913 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -957,7 +957,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
}
rc = dpu_core_perf_init(_kms->perf, dev, dpu_kms->catalog,
- _kms->phandle,
_dpu_kms_get_clk(dpu_kms, "core"));
if (rc) {
DPU_ERROR("failed to init perf %d\n", rc);
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/4] drm/virtio: add uapi for in and out explicit fences
Add a new field called fence_fd that will be used by userspace to send
in-fences to the kernel and receive out-fences created by the kernel.
This uapi enables virtio to take advantage of explicit synchronization of
dma-bufs.
There are two new flags:
* VIRTGPU_EXECBUF_FENCE_FD_IN to be used when passing an in-fence fd.
* VIRTGPU_EXECBUF_FENCE_FD_OUT to be used when requesting an out-fence fd
The execbuffer IOCTL is now read-write to allow the userspace to read the
out-fence.
On error -1 should be returned in the fence_fd field.
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
Reviewed-by: Emil Velikov
---
Changes since v4:
- Emil/Gerd: Improved commit message and fence_fd comment
Changes since v3:
- Emil: Move fence_fd assignment to after sanity checks
- Emil: Added r-b
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 5 +
include/uapi/drm/virtgpu_drm.h | 13 ++---
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index d69fc356df0a..3d497835b0f5 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -119,6 +119,11 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
if (vgdev->has_virgl_3d == false)
return -ENOSYS;
+ if ((exbuf->flags & ~VIRTGPU_EXECBUF_FLAGS))
+ return -EINVAL;
+
+ exbuf->fence_fd = -1;
+
INIT_LIST_HEAD(_list);
if (exbuf->num_bo_handles) {
diff --git a/include/uapi/drm/virtgpu_drm.h b/include/uapi/drm/virtgpu_drm.h
index 9a781f0611df..91062f4ac7c5 100644
--- a/include/uapi/drm/virtgpu_drm.h
+++ b/include/uapi/drm/virtgpu_drm.h
@@ -47,6 +47,13 @@ extern "C" {
#define DRM_VIRTGPU_WAIT 0x08
#define DRM_VIRTGPU_GET_CAPS 0x09
+#define VIRTGPU_EXECBUF_FENCE_FD_IN0x01
+#define VIRTGPU_EXECBUF_FENCE_FD_OUT 0x02
+#define VIRTGPU_EXECBUF_FLAGS (\
+ VIRTGPU_EXECBUF_FENCE_FD_IN |\
+ VIRTGPU_EXECBUF_FENCE_FD_OUT |\
+ 0)
+
struct drm_virtgpu_map {
__u64 offset; /* use for mmap system call */
__u32 handle;
@@ -54,12 +61,12 @@ struct drm_virtgpu_map {
};
struct drm_virtgpu_execbuffer {
- __u32 flags; /* for future use */
+ __u32 flags;
__u32 size;
__u64 command; /* void* */
__u64 bo_handles;
__u32 num_bo_handles;
- __u32 pad;
+ __s32 fence_fd;
};
#define VIRTGPU_PARAM_3D_FEATURES 1 /* do we have 3D features in the hw */
@@ -137,7 +144,7 @@ struct drm_virtgpu_get_caps {
DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_MAP, struct drm_virtgpu_map)
#define DRM_IOCTL_VIRTGPU_EXECBUFFER \
- DRM_IOW(DRM_COMMAND_BASE + DRM_VIRTGPU_EXECBUFFER,\
+ DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_EXECBUFFER,\
struct drm_virtgpu_execbuffer)
#define DRM_IOCTL_VIRTGPU_GETPARAM \
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
