Re: [PATCH] drm/scheduler: fix setting the priorty for entities - bisected

[Dieter Nützel]

Am 06.08.2018 02:13, schrieb Dieter Nützel:

Am 04.08.2018 06:18, schrieb Dieter Nützel:

Am 04.08.2018 06:12, schrieb Dieter Nützel:

Am 04.08.2018 05:27, schrieb Dieter Nützel:

Am 03.08.2018 13:09, schrieb Christian König:

Am 03.08.2018 um 03:08 schrieb Dieter Nützel:

Hello Christian, AMD guys,

this one _together_ with these series
[PATCH 1/7] drm/amdgpu: use new scheduler load balancing for VMs
https://lists.freedesktop.org/archives/amd-gfx/2018-August/024802.html

on top of
amd-staging-drm-next 53d5f1e4a6d9

freeze whole system (Intel Xeon X3470, RX580) during _first_ mouse 
move.

Same for sddm login or first move in KDE Plasma 5.
NO logs so far. - Expected?


Not even remotely, can you double check which patch from the 
"[PATCH
1/7] drm/amdgpu: use new scheduler load balancing for VMs" series 
is

causing the issue?


Ups,

_both_ 'series' on top of

bf1fd52b0632 (origin/amd-staging-drm-next) drm/amdgpu: move gem
definitions into amdgpu_gem header

works without a hitch.

But I have new (latest) µcode from openSUSE Tumbleweed.
kernel-firmware-20180730-35.1.src.rpm

Tested-by: Dieter Nützel 


I take this back.

Last much longer.
Mouse freeze.
Could grep a dmesg with remote phone ;-)

See the attachment.
Dieter


Argh, shi...
wrong dmesg version.

Should be this one. (For sure...)


Puh,

this took some time...
During the 'last' git bisect run => 'first bad commit is' I got next 
freeze.

But I could get a new dmesg.log file per remote phone (see attachment).

git bisect log show this:

SOURCE/amd-staging-drm-next> git bisect log
git bisect start
# good: [adebfff9c806afe1143d69a0174d4580cd27b23d] drm/scheduler: fix
setting the priorty for entities
git bisect good adebfff9c806afe1143d69a0174d4580cd27b23d
# bad: [43202e67a4e6fcb0e6b773e8eb1ed56e1721e882] drm/amdgpu: use
entity instead of ring for CS
git bisect bad 43202e67a4e6fcb0e6b773e8eb1ed56e1721e882
# bad: [9867b3a6ddfb73ee3105871541053f8e49949478] drm/amdgpu: use
scheduler load balancing for compute CS
git bisect bad 9867b3a6ddfb73ee3105871541053f8e49949478
# good: [5d097a4591aa2be16b21adbaa19a8abb76e47ea1] drm/amdgpu: use
scheduler load balancing for SDMA CS
git bisect good 5d097a4591aa2be16b21adbaa19a8abb76e47ea1
# first bad commit: [9867b3a6ddfb73ee3105871541053f8e49949478]
drm/amdgpu: use scheduler load balancing for compute CS

git log --oneline
5d097a4591aa (HEAD,
refs/bisect/good-5d097a4591aa2be16b21adbaa19a8abb76e47ea1) drm/amdgpu:
use scheduler load balancing for SDMA CS
d12ae5172f1f drm/amdgpu: use new scheduler load balancing for VMs
adebfff9c806
(refs/bisect/good-adebfff9c806afe1143d69a0174d4580cd27b23d)
drm/scheduler: fix setting the priorty for entities
bf1fd52b0632 (origin/amd-staging-drm-next) drm/amdgpu: move gem
definitions into amdgpu_gem header
5031ae5f9e5c drm/amdgpu: move psp macro into amdgpu_psp header
[-]

I'm not really sure that
drm/amdgpu: use scheduler load balancing for compute CS
is the offender.

One step earlier could it be, too.
drm/amdgpu: use scheduler load balancing for SDMA CS

I'm try running with the SDMA CS patch for the next days.

If you need more ask!


Hello Christian,

running the second day _without_ the 2. patch
[2/7] drm/amdgpu: use scheduler load balancing for SDMA CS
my system is stable, again.

To be clear.
I've now only #1 applied on top of amd-staging-drm-next.
'This one' is still in.
So we should switching the thread.

Dieter




Thanks,
Christian.



Greetings,
Dieter

Am 01.08.2018 16:27, schrieb Christian König:
Since we now deal with multiple rq we need to update all of them, 
not

just the current one.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c   |  3 +--
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 36 
---

 include/drm/gpu_scheduler.h   |  5 ++---
 3 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index df6965761046..9fcc14e2dfcf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -407,12 +407,11 @@ void amdgpu_ctx_priority_override(struct 
amdgpu_ctx *ctx,

 for (i = 0; i < adev->num_rings; i++) {
 ring = adev->rings[i];
 entity = >rings[i].entity;
-    rq = >sched.sched_rq[ctx_prio];

 if (ring->funcs->type == AMDGPU_RING_TYPE_KIQ)
 continue;

-    drm_sched_entity_set_rq(entity, rq);
+    drm_sched_entity_set_priority(entity, ctx_prio);
 }
 }

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 05dc6ecd4003..85908c7f913e 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -419,29 +419,39 @@ static void 
drm_sched_entity_clear_dep(struct

dma_fence *f, struct dma_fence_cb
 }

 /**
- * drm_sched_entity_set_rq - Sets the run queue for an entity
+ * drm_sched_entity_set_rq_priority - helper for 

DRM inquiry to Backported drm kernel modules

[John Sledge]

Hi all,
The main goal is to have the SLES12 SP3 kernel version 4.4.140-94.42.1 the fix 
it needed for Kabylake graphics issue and also enable the dp aux character 
device CONFIG_DRM_DP_AUX_CHARDEV=y.
I like to inquiry if there's a way or how to proceed with this correctly.
My question is I have a Intel Kabylake graphics and the Linux OS I installed in 
my system is SLES12 SP3 with kernel version 4.4.140-94.42.1. To support and fix 
the Kabylake graphics issue under this kernel I also installed/updated the 
drm-kmp-default which is a backported drm kernel modules. From here, I also 
wanted to enable the CONFIG_DRM_DP_AUX_CHARDEV=y.
It seems to me the drm-kmp-default file (*.ko) are build by default and the 
CONFIG_DRM_DP_AUX_CHARDEV=n is disable. Is there a possible way to enable this? 
Or how to approach with this problem?
If I rebuild the drm-kmp-default into my kernel version 4.4.140-94.42.1 source, 
I got a lot of errors because I assume the drm-kmp-default is under  a higher 
drm version which is 4.9.
Please advise and have comments.
Kernel version list:SUSE/SLES/Kernel versions - MicroFocusInternationalWiki
 drm-kmp-default site:https://software.opensuse.org/package/drm-kmp-default
Thanks,John___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107518] polaris powerplay init fails: There must be 1 or more PCIE levels defined in PPTable

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107518

--- Comment #4 from Shawn Anastasio  ---
(In reply to Alex Deucher from comment #3)
> (In reply to Shawn Anastasio from comment #2)
> > Upon further testing, the issue seems to go away when the firmware is
> > removed from petitboot, preventing it from initializing the card before the
> > host OS. This indicates that it may have something to do with the GPU being
> > initialized twice.
> 
> The hw requires a special reset before it can be initialized again.  This is
> handled in driver for things like hibernate (S4) support.

Does the driver do the reset on a kexec reboot? If so, it seems insufficient to
mitigate this 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

[PATCH v3 13/13] drm/msm/dpu: use private obj to track hw resources

[Jeykumar Sankaran]

Switch to state based resource management. This patch
overhauls the resource manager and HW allocation methods by
maintaining the global resource pool and allocated hw
blocks in respective drm component states.

Global resource manager(RM) is tracked in private object.
Allocation strategy is switched from single point allocation
of HW resources for the display pipeline to per component
based allocation, where each drm component allocates HW
blocks mapped to it's domain and tracks them in their respective
state objects.

Fix resource contention due to race conditions between
user space and display thread by reserving resources
only in atomic check.

changes in v2:
- none
changes in v3:
- rebased on [1]
- fix control path bug in split LM topology

[1] https://gitlab.freedesktop.org/seanpaul/dpu-staging/commits/for-next

Change-Id: Ie9d42eb3e93257816daf3d36c444a335645d65c6
Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   | 165 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h   |  32 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 133 ++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |   2 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |  22 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  19 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|   8 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 783 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 140 ++--
 9 files changed, 451 insertions(+), 853 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 0eb369c..dbff870 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -48,6 +48,8 @@
 #define RIGHT_MIXER 1
 
 #define MISR_BUFF_SIZE 256
+#define MAX_VDISPLAY_SPLIT 1080
+
 
 static inline struct dpu_kms *_dpu_crtc_get_kms(struct drm_crtc *crtc)
 {
@@ -258,16 +260,7 @@ static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
 
DPU_DEBUG("%s\n", dpu_crtc->name);
 
-   if (cstate->num_mixers > CRTC_DUAL_MIXERS) {
-   DPU_ERROR("invalid number mixers: %d\n", cstate->num_mixers);
-   return;
-   }
-
for (i = 0; i < cstate->num_mixers; i++) {
-   if (!mixer[i].hw_lm || !mixer[i].lm_ctl) {
-   DPU_ERROR("invalid lm or ctl assigned to mixer\n");
-   return;
-   }
mixer[i].mixer_op_mode = 0;
mixer[i].flush_mask = 0;
if (mixer[i].lm_ctl->ops.clear_all_blendstages)
@@ -498,75 +491,33 @@ void dpu_crtc_complete_commit(struct drm_crtc *crtc,
trace_dpu_crtc_complete_commit(DRMID(crtc));
 }
 
-static void _dpu_crtc_setup_mixer_for_encoder(
-   struct drm_crtc *crtc,
-   struct drm_encoder *enc)
+static void _dpu_crtc_setup_mixers(struct drm_crtc_state *crtc_state)
 {
-   struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc->state);
-   struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
-   struct dpu_rm *rm = _kms->rm;
+   struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc_state);
struct dpu_crtc_mixer *mixer;
-   struct dpu_hw_ctl *last_valid_ctl = NULL;
-   int i;
-   struct dpu_rm_hw_iter lm_iter, ctl_iter;
-
-   dpu_rm_init_hw_iter(_iter, enc->base.id, DPU_HW_BLK_LM);
-   dpu_rm_init_hw_iter(_iter, enc->base.id, DPU_HW_BLK_CTL);
+   int i = 0, j = 0;
 
-   /* Set up all the mixers and ctls reserved by this encoder */
-   for (i = cstate->num_mixers; i < ARRAY_SIZE(cstate->mixers); i++) {
-   mixer = >mixers[i];
-
-   if (!dpu_rm_get_hw(rm, _iter))
-   break;
-   mixer->hw_lm = (struct dpu_hw_mixer *)lm_iter.hw;
-
-   /* CTL may be <= LMs, if <, multiple LMs controlled by 1 CTL */
-   if (!dpu_rm_get_hw(rm, _iter)) {
-   DPU_DEBUG("no ctl assigned to lm %d, using previous\n",
-   mixer->hw_lm->idx - LM_0);
-   mixer->lm_ctl = last_valid_ctl;
-   } else {
-   mixer->lm_ctl = (struct dpu_hw_ctl *)ctl_iter.hw;
-   last_valid_ctl = mixer->lm_ctl;
-   }
-
-   /* Shouldn't happen, mixers are always >= ctls */
-   if (!mixer->lm_ctl) {
-   DPU_ERROR("no valid ctls found for lm %d\n",
-   mixer->hw_lm->idx - LM_0);
-   return;
-   }
-
-   mixer->encoder = enc;
-
-   cstate->num_mixers++;
-   DPU_DEBUG("setup mixer %d: lm %d\n",
-   i, mixer->hw_lm->idx - LM_0);
-   DPU_DEBUG("setup mixer %d: ctl %d\n",
-   i, 

[PATCH v3 11/13] drm/msm/dpu: remove display H_TILE from encoder

[Jeykumar Sankaran]

Encoder H_TILE values are not used for allocating the hw blocks.
no. of hw_intf blocks provides the info.

changes in v2:
- none
changes in v3:
- none

Change-Id: I1c1c13e9b9f608fbaa8c5897f9f1892029107ac5
Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |  5 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h |  4 
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c  | 11 +--
 3 files changed, 5 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 58647ed..fe0b563 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -179,8 +179,6 @@ struct dpu_encoder_virt {
spinlock_t enc_spinlock;
uint32_t bus_scaling_client;
 
-   uint32_t display_num_of_h_tiles;
-
unsigned int num_phys_encs;
struct dpu_encoder_phys *phys_encs[MAX_PHYS_ENCODERS_PER_VIRTUAL];
struct dpu_encoder_phys *cur_master;
@@ -461,7 +459,6 @@ void dpu_encoder_get_hw_resources(struct drm_encoder 
*drm_enc,
 
/* Query resources used by phys encs, expected to be without overlap */
memset(hw_res, 0, sizeof(*hw_res));
-   hw_res->display_num_of_h_tiles = dpu_enc->display_num_of_h_tiles;
 
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
@@ -2268,8 +2265,6 @@ static int dpu_encoder_setup_display(struct 
dpu_encoder_virt *dpu_enc,
 
WARN_ON(disp_info->num_of_h_tiles < 1);
 
-   dpu_enc->display_num_of_h_tiles = disp_info->num_of_h_tiles;
-
DPU_DEBUG("dsi_info->num_of_h_tiles %d\n", disp_info->num_of_h_tiles);
 
if ((disp_info->capabilities & MSM_DISPLAY_CAP_CMD_MODE) ||
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index 60f809f..e453271 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -33,14 +33,10 @@
  * Encoder functions and data types
  * @intfs: Interfaces this encoder is using, INTF_MODE_NONE if unused
  * @needs_cdm: Encoder requests a CDM based on pixel format conversion needs
- * @display_num_of_h_tiles: Number of horizontal tiles in case of split
- *  interface
- * @topology:   Topology of the display
  */
 struct dpu_encoder_hw_resources {
enum dpu_intf_mode intfs[INTF_MAX];
bool needs_cdm;
-   u32 display_num_of_h_tiles;
 };
 
 /**
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 1457ae5..369 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -817,12 +817,11 @@ static int _dpu_rm_populate_requirements(
conn_state->connector->connector_type == DRM_MODE_CONNECTOR_DSI)
reqs->top_ctrl |= BIT(DPU_RM_TOPCTL_DS);
 
-   DRM_DEBUG_KMS("top_ctrl: 0x%llX num_h_tiles: %d\n", reqs->top_ctrl,
- reqs->hw_res.display_num_of_h_tiles);
-   DRM_DEBUG_KMS("num_lm: %d num_ctl: %d topology: %d split_display: %d\n",
- reqs->topology->num_lm, reqs->topology->num_ctl,
- reqs->topology->top_name,
- reqs->topology->needs_split_display);
+   DPU_DEBUG("top_ctrl: 0x%llX\n", reqs->top_ctrl);
+   DPU_DEBUG("num_lm: %d num_ctl: %d topology: %d split_display: %d\n",
+   reqs->topology->num_lm, reqs->topology->num_ctl,
+   reqs->topology->top_name,
+   reqs->topology->needs_split_display);
 
return 0;
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 12/13] drm/msm/dpu: add atomic private object to dpu kms

[Jeykumar Sankaran]

Subclass drm private state for DPU for handling driver
specific data. Adds atomic private object and private object
lock to dpu kms. Provides helper function to retrieve DPU
private data from current atomic state.

changes in v2:
- none
changes in v3:
- rebase on [1]

[1] https://gitlab.freedesktop.org/seanpaul/dpu-staging/commits/for-next

Change-Id: Iaab32badff224ffed024e6ef6576efc8b3af3aec
Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 61 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 15 
 2 files changed, 76 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 7dd6bd2..5e87b9d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1168,10 +1168,59 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
return rc;
 }
 
+struct dpu_private_state *dpu_get_private_state(struct drm_atomic_state *state)
+{
+   struct msm_drm_private *priv = state->dev->dev_private;
+   struct dpu_kms *dpu_kms = to_dpu_kms(priv->kms);
+   struct drm_private_state *priv_state;
+   int rc = 0;
+
+   rc = drm_modeset_lock(_kms->priv_obj_lock, state->acquire_ctx);
+   if (rc)
+   return ERR_PTR(rc);
+
+   priv_state = drm_atomic_get_private_obj_state(state,
+   _kms->priv_obj);
+   if (IS_ERR(priv_state))
+   return ERR_PTR(-ENOMEM);
+
+   return to_dpu_private_state(priv_state);
+}
+
+static struct drm_private_state *
+dpu_private_obj_duplicate_state(struct drm_private_obj *obj)
+{
+   struct dpu_private_state *dpu_priv_state;
+
+   dpu_priv_state = kmemdup(obj->state,
+   sizeof(*dpu_priv_state), GFP_KERNEL);
+   if (!dpu_priv_state)
+   return NULL;
+
+   __drm_atomic_helper_private_obj_duplicate_state(obj,
+   _priv_state->base);
+
+   return _priv_state->base;
+}
+
+static void dpu_private_obj_destroy_state(struct drm_private_obj *obj,
+ struct drm_private_state *state)
+{
+   struct dpu_private_state *dpu_priv_state = to_dpu_private_state(state);
+
+   kfree(dpu_priv_state);
+}
+
+static const struct drm_private_state_funcs priv_obj_funcs = {
+   .atomic_duplicate_state = dpu_private_obj_duplicate_state,
+   .atomic_destroy_state = dpu_private_obj_destroy_state,
+};
+
 struct msm_kms *dpu_kms_init(struct drm_device *dev)
 {
struct msm_drm_private *priv;
struct dpu_kms *dpu_kms;
+   struct dpu_private_state *dpu_priv_state;
int irq;
 
if (!dev || !dev->dev_private) {
@@ -1189,6 +1238,18 @@ struct msm_kms *dpu_kms_init(struct drm_device *dev)
}
dpu_kms->base.irq = irq;
 
+   /* Initialize private obj's */
+   drm_modeset_lock_init(_kms->priv_obj_lock);
+
+   dpu_priv_state = kzalloc(sizeof(*dpu_priv_state), GFP_KERNEL);
+   if (!dpu_priv_state)
+   return ERR_PTR(-ENOMEM);
+
+
+   drm_atomic_private_obj_init(_kms->priv_obj,
+   _priv_state->base,
+   _obj_funcs);
+
return _kms->base;
 }
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 66d4666..2579c983 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -145,6 +145,9 @@ struct dpu_kms {
struct dpu_hw_vbif *hw_vbif[VBIF_MAX];
struct dpu_hw_mdp *hw_mdp;
 
+   struct drm_modeset_lock priv_obj_lock;
+   struct drm_private_obj priv_obj;
+
bool has_danger_ctrl;
 
struct platform_device *pdev;
@@ -152,12 +155,24 @@ struct dpu_kms {
struct dss_module_power mp;
 };
 
+struct dpu_private_state {
+   struct drm_private_state base;
+};
+
 struct vsync_info {
u32 frame_count;
u32 line_count;
 };
 
 #define to_dpu_kms(x) container_of(x, struct dpu_kms, base)
+#define to_dpu_private_state(x) container_of(x, struct dpu_private_state, base)
+
+/**
+ * dpu_get_private_state - get dpu private state from atomic state
+ * @state: drm atomic state
+ * Return: pointer to dpu private state object
+ */
+struct dpu_private_state *dpu_get_private_state(struct drm_atomic_state 
*state);
 
 /* get struct msm_kms * from drm_device * */
 #define ddev_to_msm_kms(D) ((D) && (D)->dev_private ? \
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 10/13] drm/msm/dpu: remove topology name

[Jeykumar Sankaran]

Strip down the support for topology enums. It
can be replaced with simple hw count checks.

changes in v2:
- none
changes in v3:
- none

Change-Id: If9b2a4db5bbdf8545b99b6d90825e256d014382d
Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c  |  3 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h |  9 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c |  7 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c   | 12 
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h   |  9 -
 5 files changed, 10 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 7b82e2d..58647ed 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1019,7 +1019,6 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder 
*drm_enc,
struct drm_connector *conn = NULL, *conn_iter;
struct dpu_rm_hw_iter pp_iter, ctl_iter;
struct msm_display_topology topology;
-   enum dpu_rm_topology_name topology_name;
struct dpu_hw_ctl *hw_ctl[MAX_CHANNELS_PER_ENC];
 
int i = 0, ret;
@@ -1077,7 +1076,6 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder 
*drm_enc,
hw_ctl[i] = (struct dpu_hw_ctl *)ctl_iter.hw;
}
 
-   topology_name = dpu_rm_get_topology_name(topology);
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
 
@@ -1097,7 +1095,6 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder 
*drm_enc,
phys->hw_ctl = hw_ctl[i];
 
phys->connector = conn->state->connector;
-   phys->topology_name = topology_name;
if (phys->ops.mode_set)
phys->ops.mode_set(phys, mode, adj_mode);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index c7df8aa..d08b5d5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -24,6 +24,7 @@
 #include "dpu_hw_top.h"
 #include "dpu_hw_cdm.h"
 #include "dpu_encoder.h"
+#include "dpu_crtc.h"
 
 #define DPU_ENCODER_NAME_MAX   16
 
@@ -219,7 +220,6 @@ struct dpu_encoder_irq {
  * @split_role:Role to play in a split-panel configuration
  * @intf_mode: Interface mode
  * @intf_idx:  Interface index on dpu hardware
- * @topology_name: topology selected for the display
  * @enc_spinlock:  Virtual-Encoder-Wide Spin Lock for IRQ purposes
  * @enable_state:  Enable state tracking
  * @vblank_refcount:   Reference count of vblank request
@@ -249,7 +249,6 @@ struct dpu_encoder_phys {
enum dpu_enc_split_role split_role;
enum dpu_intf_mode intf_mode;
enum dpu_intf intf_idx;
-   enum dpu_rm_topology_name topology_name;
spinlock_t *enc_spinlock;
enum dpu_enc_enable_state enable_state;
atomic_t vblank_refcount;
@@ -367,11 +366,15 @@ struct dpu_encoder_phys *dpu_encoder_phys_cmd_init(
 static inline enum dpu_3d_blend_mode dpu_encoder_helper_get_3d_blend_mode(
struct dpu_encoder_phys *phys_enc)
 {
+   struct dpu_crtc_state *dpu_cstate;
+
if (!phys_enc || phys_enc->enable_state == DPU_ENC_DISABLING)
return BLEND_3D_NONE;
 
+   dpu_cstate = to_dpu_crtc_state(phys_enc->parent->crtc->state);
+
if (phys_enc->split_role == ENC_ROLE_SOLO &&
-   phys_enc->topology_name == DPU_RM_TOPOLOGY_DUALPIPE_3DMERGE)
+   (dpu_cstate->num_mixers == 2))
return BLEND_3D_H_ROW_INT;
 
return BLEND_3D_NONE;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index a0b3744..88867c3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -355,13 +355,14 @@ static void dpu_encoder_phys_vid_underrun_irq(void *arg, 
int irq_idx)
 
 static bool _dpu_encoder_phys_is_dual_ctl(struct dpu_encoder_phys *phys_enc)
 {
+   struct dpu_crtc_state *dpu_cstate;
+
if (!phys_enc)
return false;
 
-   if (phys_enc->topology_name == DPU_RM_TOPOLOGY_DUALPIPE)
-   return true;
+   dpu_cstate = to_dpu_crtc_state(phys_enc->parent->crtc->state);
 
-   return false;
+   return (dpu_cstate->num_ctls > 1);
 }
 
 static bool dpu_encoder_phys_vid_needs_single_flush(
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 13c0a36..1457ae5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -146,18 +146,6 @@ struct dpu_hw_mdp *dpu_rm_get_mdp(struct dpu_rm *rm)

[PATCH v3 06/13] drm/msm/dpu: iterate for assigned hw ctl in virtual encoder

[Jeykumar Sankaran]

Instead of iterating for hw ctrl per physical encoder, this
patch moves the iterations and assignment to the virtual encoder.

changes in v2:
- none
changes in v3:
- none

Change-Id: I896a8c36d6353986582e9d0fe3da9b2293579d4b
Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 22 --
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   | 19 ---
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   | 19 ---
 3 files changed, 20 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index a0ced79..7b82e2d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1017,9 +1017,11 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder 
*drm_enc,
struct dpu_kms *dpu_kms;
struct list_head *connector_list;
struct drm_connector *conn = NULL, *conn_iter;
-   struct dpu_rm_hw_iter pp_iter;
+   struct dpu_rm_hw_iter pp_iter, ctl_iter;
struct msm_display_topology topology;
enum dpu_rm_topology_name topology_name;
+   struct dpu_hw_ctl *hw_ctl[MAX_CHANNELS_PER_ENC];
+
int i = 0, ret;
 
if (!drm_enc) {
@@ -1067,6 +1069,14 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder 
*drm_enc,
dpu_enc->hw_pp[i] = (struct dpu_hw_pingpong *) pp_iter.hw;
}
 
+   dpu_rm_init_hw_iter(_iter, drm_enc->base.id, DPU_HW_BLK_CTL);
+   for (i = 0; i < MAX_CHANNELS_PER_ENC; i++) {
+   hw_ctl[i] = NULL;
+   if (!dpu_rm_get_hw(_kms->rm, _iter))
+   break;
+   hw_ctl[i] = (struct dpu_hw_ctl *)ctl_iter.hw;
+   }
+
topology_name = dpu_rm_get_topology_name(topology);
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
@@ -1074,10 +1084,18 @@ static void dpu_encoder_virt_mode_set(struct 
drm_encoder *drm_enc,
if (phys) {
if (!dpu_enc->hw_pp[i]) {
DPU_ERROR_ENC(dpu_enc,
-   "invalid pingpong block for the encoder\n");
+   "no pp block assigned at idx: %d\n", i);
return;
}
phys->hw_pp = dpu_enc->hw_pp[i];
+
+   if (!hw_ctl[i]) {
+   DPU_ERROR_ENC(dpu_enc,
+   "no ctl block assigned at idx: %d\n", i);
+   return;
+   }
+   phys->hw_ctl = hw_ctl[i];
+
phys->connector = conn->state->connector;
phys->topology_name = topology_name;
if (phys->ops.mode_set)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index c8c4612..5c89868 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -196,9 +196,6 @@ static void dpu_encoder_phys_cmd_mode_set(
 {
struct dpu_encoder_phys_cmd *cmd_enc =
to_dpu_encoder_phys_cmd(phys_enc);
-   struct dpu_rm *rm = _enc->dpu_kms->rm;
-   struct dpu_rm_hw_iter iter;
-   int i, instance;
 
if (!phys_enc || !mode || !adj_mode) {
DPU_ERROR("invalid args\n");
@@ -208,22 +205,6 @@ static void dpu_encoder_phys_cmd_mode_set(
DPU_DEBUG_CMDENC(cmd_enc, "caching mode:\n");
drm_mode_debug_printmodeline(adj_mode);
 
-   instance = phys_enc->split_role == ENC_ROLE_SLAVE ? 1 : 0;
-
-   /* Retrieve previously allocated HW Resources. Shouldn't fail */
-   dpu_rm_init_hw_iter(, phys_enc->parent->base.id, DPU_HW_BLK_CTL);
-   for (i = 0; i <= instance; i++) {
-   if (dpu_rm_get_hw(rm, ))
-   phys_enc->hw_ctl = (struct dpu_hw_ctl *)iter.hw;
-   }
-
-   if (IS_ERR_OR_NULL(phys_enc->hw_ctl)) {
-   DPU_ERROR_CMDENC(cmd_enc, "failed to init ctl: %ld\n",
-   PTR_ERR(phys_enc->hw_ctl));
-   phys_enc->hw_ctl = NULL;
-   return;
-   }
-
_dpu_encoder_phys_cmd_setup_irq_hw_idx(phys_enc);
 }
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index 57ece03..c0221cc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -395,9 +395,6 @@ static void dpu_encoder_phys_vid_mode_set(
struct drm_display_mode *mode,
struct drm_display_mode *adj_mode)
 {
-   struct dpu_rm *rm;
-   struct dpu_rm_hw_iter iter;
-   int i, instance;
  

[PATCH v3 07/13] drm/msm/dpu: avoid querying for hw intf before assignment

[Jeykumar Sankaran]

hw intf blocks are needed only during encoder enable to program
timing engines(for video panels). encoder->enable is triggered
only after atomic_modeset at which point we assign the
resources for the display pipeline. This patch defers the
hw_intf look-up until encoder enable.

changes in v2:
- none
changes in v3:
- none

Change-Id: Ib0a2253431468151355e50cbad7b91e2b77b6e54
Signed-off-by: Jeykumar Sankaran 
---
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   | 53 +++---
 1 file changed, 16 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index c0221cc..a0b3744 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -462,7 +462,7 @@ static void dpu_encoder_phys_vid_enable(struct 
dpu_encoder_phys *phys_enc)
 {
struct msm_drm_private *priv;
struct dpu_encoder_phys_vid *vid_enc;
-   struct dpu_hw_intf *intf;
+   struct dpu_rm_hw_iter iter;
struct dpu_hw_ctl *ctl;
u32 flush_mask = 0;
 
@@ -474,11 +474,20 @@ static void dpu_encoder_phys_vid_enable(struct 
dpu_encoder_phys *phys_enc)
priv = phys_enc->parent->dev->dev_private;
 
vid_enc = to_dpu_encoder_phys_vid(phys_enc);
-   intf = vid_enc->hw_intf;
ctl = phys_enc->hw_ctl;
-   if (!vid_enc->hw_intf || !phys_enc->hw_ctl) {
-   DPU_ERROR("invalid hw_intf %d hw_ctl %d\n",
-   vid_enc->hw_intf != 0, phys_enc->hw_ctl != 0);
+
+   dpu_rm_init_hw_iter(, phys_enc->parent->base.id, DPU_HW_BLK_INTF);
+   while (dpu_rm_get_hw(_enc->dpu_kms->rm, )) {
+   struct dpu_hw_intf *hw_intf = (struct dpu_hw_intf *)iter.hw;
+
+   if (hw_intf->idx == phys_enc->intf_idx) {
+   vid_enc->hw_intf = hw_intf;
+   break;
+   }
+   }
+
+   if (!vid_enc->hw_intf) {
+   DPU_ERROR("hw_intf not assigned\n");
return;
}
 
@@ -500,7 +509,7 @@ static void dpu_encoder_phys_vid_enable(struct 
dpu_encoder_phys *phys_enc)
!dpu_encoder_phys_vid_is_master(phys_enc))
goto skip_flush;
 
-   ctl->ops.get_bitmask_intf(ctl, _mask, intf->idx);
+   ctl->ops.get_bitmask_intf(ctl, _mask, vid_enc->hw_intf->idx);
ctl->ops.update_pending_flush(ctl, flush_mask);
 
 skip_flush:
@@ -531,22 +540,13 @@ static void dpu_encoder_phys_vid_get_hw_resources(
struct dpu_encoder_hw_resources *hw_res,
struct drm_connector_state *conn_state)
 {
-   struct dpu_encoder_phys_vid *vid_enc;
-
if (!phys_enc || !hw_res) {
DPU_ERROR("invalid arg(s), enc %d hw_res %d conn_state %d\n",
phys_enc != 0, hw_res != 0, conn_state != 0);
return;
}
 
-   vid_enc = to_dpu_encoder_phys_vid(phys_enc);
-   if (!vid_enc->hw_intf) {
-   DPU_ERROR("invalid arg(s), hw_intf\n");
-   return;
-   }
-
-   DPU_DEBUG_VIDENC(vid_enc, "\n");
-   hw_res->intfs[vid_enc->hw_intf->idx - INTF_0] = INTF_MODE_VIDEO;
+   hw_res->intfs[phys_enc->intf_idx - INTF_0] = INTF_MODE_VIDEO;
 }
 
 static int _dpu_encoder_phys_vid_wait_for_vblank(
@@ -809,7 +809,6 @@ struct dpu_encoder_phys *dpu_encoder_phys_vid_init(
 {
struct dpu_encoder_phys *phys_enc = NULL;
struct dpu_encoder_phys_vid *vid_enc = NULL;
-   struct dpu_rm_hw_iter iter;
struct dpu_encoder_irq *irq;
int i, ret = 0;
 
@@ -829,26 +828,6 @@ struct dpu_encoder_phys *dpu_encoder_phys_vid_init(
phys_enc->hw_mdptop = p->dpu_kms->hw_mdp;
phys_enc->intf_idx = p->intf_idx;
 
-   /**
-* hw_intf resource permanently assigned to this encoder
-* Other resources allocated at atomic commit time by use case
-*/
-   dpu_rm_init_hw_iter(, 0, DPU_HW_BLK_INTF);
-   while (dpu_rm_get_hw(>dpu_kms->rm, )) {
-   struct dpu_hw_intf *hw_intf = (struct dpu_hw_intf *)iter.hw;
-
-   if (hw_intf->idx == p->intf_idx) {
-   vid_enc->hw_intf = hw_intf;
-   break;
-   }
-   }
-
-   if (!vid_enc->hw_intf) {
-   ret = -EINVAL;
-   DPU_ERROR("failed to get hw_intf\n");
-   goto fail;
-   }
-
DPU_DEBUG_VIDENC(vid_enc, "\n");
 
dpu_encoder_phys_vid_init_ops(_enc->ops);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 09/13] drm/msm/dpu: rename hw_ctl to lm_ctl

[Jeykumar Sankaran]

Prep change for state based resource management.

Rename hw_ctl to lm_ctl to mean the ctl associated
with the hw layer mixer block.

changes in v2:
- none
changes in v3:
- none

Change-Id: If6e6249e089b89225cdfafe9158f7509e97b
Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 26 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h |  4 ++--
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 515b0e6..0eb369c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -175,7 +175,7 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc 
*crtc,
return;
}
 
-   ctl = mixer->hw_ctl;
+   ctl = mixer->lm_ctl;
lm = mixer->hw_lm;
stage_cfg = _crtc->stage_cfg;
cstate = to_dpu_crtc_state(crtc->state);
@@ -264,15 +264,15 @@ static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
}
 
for (i = 0; i < cstate->num_mixers; i++) {
-   if (!mixer[i].hw_lm || !mixer[i].hw_ctl) {
+   if (!mixer[i].hw_lm || !mixer[i].lm_ctl) {
DPU_ERROR("invalid lm or ctl assigned to mixer\n");
return;
}
mixer[i].mixer_op_mode = 0;
mixer[i].flush_mask = 0;
-   if (mixer[i].hw_ctl->ops.clear_all_blendstages)
-   mixer[i].hw_ctl->ops.clear_all_blendstages(
-   mixer[i].hw_ctl);
+   if (mixer[i].lm_ctl->ops.clear_all_blendstages)
+   mixer[i].lm_ctl->ops.clear_all_blendstages(
+   mixer[i].lm_ctl);
}
 
/* initialize stage cfg */
@@ -281,7 +281,7 @@ static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
_dpu_crtc_blend_setup_mixer(crtc, dpu_crtc, mixer);
 
for (i = 0; i < cstate->num_mixers; i++) {
-   ctl = mixer[i].hw_ctl;
+   ctl = mixer[i].lm_ctl;
lm = mixer[i].hw_lm;
 
lm->ops.setup_alpha_out(lm, mixer[i].mixer_op_mode);
@@ -525,14 +525,14 @@ static void _dpu_crtc_setup_mixer_for_encoder(
if (!dpu_rm_get_hw(rm, _iter)) {
DPU_DEBUG("no ctl assigned to lm %d, using previous\n",
mixer->hw_lm->idx - LM_0);
-   mixer->hw_ctl = last_valid_ctl;
+   mixer->lm_ctl = last_valid_ctl;
} else {
-   mixer->hw_ctl = (struct dpu_hw_ctl *)ctl_iter.hw;
-   last_valid_ctl = mixer->hw_ctl;
+   mixer->lm_ctl = (struct dpu_hw_ctl *)ctl_iter.hw;
+   last_valid_ctl = mixer->lm_ctl;
}
 
/* Shouldn't happen, mixers are always >= ctls */
-   if (!mixer->hw_ctl) {
+   if (!mixer->lm_ctl) {
DPU_ERROR("no valid ctls found for lm %d\n",
mixer->hw_lm->idx - LM_0);
return;
@@ -544,7 +544,7 @@ static void _dpu_crtc_setup_mixer_for_encoder(
DPU_DEBUG("setup mixer %d: lm %d\n",
i, mixer->hw_lm->idx - LM_0);
DPU_DEBUG("setup mixer %d: ctl %d\n",
-   i, mixer->hw_ctl->idx - CTL_0);
+   i, mixer->lm_ctl->idx - CTL_0);
}
 }
 
@@ -1559,11 +1559,11 @@ static int _dpu_debugfs_status_show(struct seq_file *s, 
void *data)
m = >mixers[i];
if (!m->hw_lm)
seq_printf(s, "\tmixer[%d] has no lm\n", i);
-   else if (!m->hw_ctl)
+   else if (!m->lm_ctl)
seq_printf(s, "\tmixer[%d] has no ctl\n", i);
else
seq_printf(s, "\tmixer:%d ctl:%d width:%d height:%d\n",
-   m->hw_lm->idx - LM_0, m->hw_ctl->idx - CTL_0,
+   m->hw_lm->idx - LM_0, m->lm_ctl->idx - CTL_0,
out_width, mode->vdisplay);
}
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index 9177ee6..5b85ca8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -83,14 +83,14 @@ struct dpu_crtc_smmu_state_data {
 /**
  * struct dpu_crtc_mixer: stores the map for each virtual pipeline in the CRTC
  * @hw_lm: LM HW Driver context
- * @hw_ctl:CTL Path HW driver context
+ * @lm_ctl:CTL Path HW driver context
  * @encoder:   Encoder attached to this lm & ctl
  * @mixer_op_mode: mixer blending operation mode
  * @flush_mask:mixer flush mask for ctl, mixer and pipe
  */
 struct 

[PATCH v3 08/13] drm/msm/dpu: move hw resource tracking to crtc state

[Jeykumar Sankaran]

Prep changes for state based resource management.

Moves all the hw block tracking for the crtc to the state
object.

changes in v2:
- none
changes in v3:
- none

Change-Id: I2816e9e28b27f1126b477d62eb3858a30a652747
Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 77 +---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 25 +--
 2 files changed, 54 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 1f2d223..515b0e6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -136,9 +136,9 @@ static void _dpu_crtc_program_lm_output_roi(struct drm_crtc 
*crtc)
crtc_state = to_dpu_crtc_state(crtc->state);
 
lm_horiz_position = 0;
-   for (lm_idx = 0; lm_idx < dpu_crtc->num_mixers; lm_idx++) {
+   for (lm_idx = 0; lm_idx < crtc_state->num_mixers; lm_idx++) {
const struct drm_rect *lm_roi = _state->lm_bounds[lm_idx];
-   struct dpu_hw_mixer *hw_lm = dpu_crtc->mixers[lm_idx].hw_lm;
+   struct dpu_hw_mixer *hw_lm = crtc_state->mixers[lm_idx].hw_lm;
struct dpu_hw_mixer_cfg cfg;
 
if (!lm_roi || !drm_rect_visible(lm_roi))
@@ -219,7 +219,7 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc 
*crtc,
   fb ? fb->modifier : 0);
 
/* blend config update */
-   for (lm_idx = 0; lm_idx < dpu_crtc->num_mixers; lm_idx++) {
+   for (lm_idx = 0; lm_idx < cstate->num_mixers; lm_idx++) {
_dpu_crtc_setup_blend_cfg(mixer + lm_idx, pstate);
 
mixer[lm_idx].flush_mask |= flush_mask;
@@ -242,7 +242,7 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc 
*crtc,
 static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
 {
struct dpu_crtc *dpu_crtc;
-   struct dpu_crtc_state *dpu_crtc_state;
+   struct dpu_crtc_state *cstate;
struct dpu_crtc_mixer *mixer;
struct dpu_hw_ctl *ctl;
struct dpu_hw_mixer *lm;
@@ -253,17 +253,17 @@ static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
return;
 
dpu_crtc = to_dpu_crtc(crtc);
-   dpu_crtc_state = to_dpu_crtc_state(crtc->state);
-   mixer = dpu_crtc->mixers;
+   cstate = to_dpu_crtc_state(crtc->state);
+   mixer = cstate->mixers;
 
DPU_DEBUG("%s\n", dpu_crtc->name);
 
-   if (dpu_crtc->num_mixers > CRTC_DUAL_MIXERS) {
-   DPU_ERROR("invalid number mixers: %d\n", dpu_crtc->num_mixers);
+   if (cstate->num_mixers > CRTC_DUAL_MIXERS) {
+   DPU_ERROR("invalid number mixers: %d\n", cstate->num_mixers);
return;
}
 
-   for (i = 0; i < dpu_crtc->num_mixers; i++) {
+   for (i = 0; i < cstate->num_mixers; i++) {
if (!mixer[i].hw_lm || !mixer[i].hw_ctl) {
DPU_ERROR("invalid lm or ctl assigned to mixer\n");
return;
@@ -280,7 +280,7 @@ static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
 
_dpu_crtc_blend_setup_mixer(crtc, dpu_crtc, mixer);
 
-   for (i = 0; i < dpu_crtc->num_mixers; i++) {
+   for (i = 0; i < cstate->num_mixers; i++) {
ctl = mixer[i].hw_ctl;
lm = mixer[i].hw_lm;
 
@@ -502,7 +502,7 @@ static void _dpu_crtc_setup_mixer_for_encoder(
struct drm_crtc *crtc,
struct drm_encoder *enc)
 {
-   struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
+   struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc->state);
struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
struct dpu_rm *rm = _kms->rm;
struct dpu_crtc_mixer *mixer;
@@ -514,8 +514,8 @@ static void _dpu_crtc_setup_mixer_for_encoder(
dpu_rm_init_hw_iter(_iter, enc->base.id, DPU_HW_BLK_CTL);
 
/* Set up all the mixers and ctls reserved by this encoder */
-   for (i = dpu_crtc->num_mixers; i < ARRAY_SIZE(dpu_crtc->mixers); i++) {
-   mixer = _crtc->mixers[i];
+   for (i = cstate->num_mixers; i < ARRAY_SIZE(cstate->mixers); i++) {
+   mixer = >mixers[i];
 
if (!dpu_rm_get_hw(rm, _iter))
break;
@@ -540,7 +540,7 @@ static void _dpu_crtc_setup_mixer_for_encoder(
 
mixer->encoder = enc;
 
-   dpu_crtc->num_mixers++;
+   cstate->num_mixers++;
DPU_DEBUG("setup mixer %d: lm %d\n",
i, mixer->hw_lm->idx - LM_0);
DPU_DEBUG("setup mixer %d: ctl %d\n",
@@ -551,11 +551,11 @@ static void _dpu_crtc_setup_mixer_for_encoder(
 static void _dpu_crtc_setup_mixers(struct drm_crtc *crtc)
 {
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
+   struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc->state);

[PATCH v3 04/13] drm/msm/dpu: program master-slave encoders explicitly

[Jeykumar Sankaran]

Identify slave-master encoders and program them explicitly.

changes in v2:
- none
changes in v3:
- none

Change-Id: I0ebfada05bd7f8437f842ad860490a678aa8f4cd
Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 39 ++---
 1 file changed, 24 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 1b4de34..a0ced79 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -184,6 +184,7 @@ struct dpu_encoder_virt {
unsigned int num_phys_encs;
struct dpu_encoder_phys *phys_encs[MAX_PHYS_ENCODERS_PER_VIRTUAL];
struct dpu_encoder_phys *cur_master;
+   struct dpu_encoder_phys *cur_slave;
struct dpu_hw_pingpong *hw_pp[MAX_CHANNELS_PER_ENC];
 
bool intfs_swapped;
@@ -1153,6 +1154,7 @@ void dpu_encoder_virt_restore(struct drm_encoder *drm_enc)
 static void dpu_encoder_virt_enable(struct drm_encoder *drm_enc)
 {
struct dpu_encoder_virt *dpu_enc = NULL;
+   struct dpu_encoder_phys *phys  = NULL;
int i, ret = 0;
struct drm_display_mode *cur_mode = NULL;
 
@@ -1160,6 +1162,7 @@ static void dpu_encoder_virt_enable(struct drm_encoder 
*drm_enc)
DPU_ERROR("invalid encoder\n");
return;
}
+
dpu_enc = to_dpu_encoder_virt(drm_enc);
cur_mode = _enc->base.crtc->state->adjusted_mode;
 
@@ -1167,21 +1170,36 @@ static void dpu_encoder_virt_enable(struct drm_encoder 
*drm_enc)
 cur_mode->vdisplay);
 
dpu_enc->cur_master = NULL;
+   dpu_enc->cur_slave = NULL;
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
-   struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
+   phys = dpu_enc->phys_encs[i];
+
+   if (!phys || !phys->ops.is_master)
+   continue;
 
-   if (phys && phys->ops.is_master && phys->ops.is_master(phys)) {
-   DPU_DEBUG_ENC(dpu_enc, "master is now idx %d\n", i);
+   if (phys->ops.is_master(phys)) {
+   DPU_DEBUG_ENC(dpu_enc, "master is at idx %d\n", i);
dpu_enc->cur_master = phys;
-   break;
+   } else {
+   DPU_DEBUG_ENC(dpu_enc, "slave is at idx %d\n", i);
+   dpu_enc->cur_slave = phys;
}
}
 
if (!dpu_enc->cur_master) {
-   DPU_ERROR("virt encoder has no master! num_phys %d\n", i);
+   DPU_ERROR("virt encoder has no master identified\n");
return;
}
 
+   /* always enable slave encoder before master */
+   phys = dpu_enc->cur_slave;
+   if (phys && phys->ops.enable)
+   phys->ops.enable(phys);
+
+   phys = dpu_enc->cur_master;
+   if (phys && phys->ops.enable)
+   phys->ops.enable(phys);
+
ret = dpu_encoder_resource_control(drm_enc, DPU_ENC_RC_EVENT_KICKOFF);
if (ret) {
DPU_ERROR_ENC(dpu_enc, "dpu resource control failed: %d\n",
@@ -1190,25 +1208,16 @@ static void dpu_encoder_virt_enable(struct drm_encoder 
*drm_enc)
}
 
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
-   struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
-
+   phys = dpu_enc->phys_encs[i];
if (!phys)
continue;
 
-   if (phys != dpu_enc->cur_master) {
-   if (phys->ops.enable)
-   phys->ops.enable(phys);
-   }
-
if (dpu_enc->misr_enable && (dpu_enc->disp_info.capabilities &
 MSM_DISPLAY_CAP_VID_MODE) && phys->ops.setup_misr)
phys->ops.setup_misr(phys, true,
dpu_enc->misr_frame_count);
}
 
-   if (dpu_enc->cur_master->ops.enable)
-   dpu_enc->cur_master->ops.enable(dpu_enc->cur_master);
-
_dpu_encoder_virt_enable_helper(drm_enc);
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 05/13] drm/msm/dpu: use kms stored hw mdp block

[Jeykumar Sankaran]

Avoid querying RM for hw mdp block. Use the one
stored in KMS during initialization.

changes in v2:
- none
changes in v3:
- none

Change-Id: I52129b96bd561a5547507d7f567bcaa3dbe554aa
Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 12 +---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c |  9 +
 2 files changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index 3084675..c8c4612 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -823,7 +823,6 @@ struct dpu_encoder_phys *dpu_encoder_phys_cmd_init(
 {
struct dpu_encoder_phys *phys_enc = NULL;
struct dpu_encoder_phys_cmd *cmd_enc = NULL;
-   struct dpu_hw_mdp *hw_mdp;
struct dpu_encoder_irq *irq;
int i, ret = 0;
 
@@ -836,14 +835,7 @@ struct dpu_encoder_phys *dpu_encoder_phys_cmd_init(
goto fail;
}
phys_enc = _enc->base;
-
-   hw_mdp = dpu_rm_get_mdp(>dpu_kms->rm);
-   if (IS_ERR_OR_NULL(hw_mdp)) {
-   ret = PTR_ERR(hw_mdp);
-   DPU_ERROR("failed to get mdptop\n");
-   goto fail_mdp_init;
-   }
-   phys_enc->hw_mdptop = hw_mdp;
+   phys_enc->hw_mdptop = p->dpu_kms->hw_mdp;
phys_enc->intf_idx = p->intf_idx;
 
dpu_encoder_phys_cmd_init_ops(_enc->ops);
@@ -898,8 +890,6 @@ struct dpu_encoder_phys *dpu_encoder_phys_cmd_init(
 
return phys_enc;
 
-fail_mdp_init:
-   kfree(cmd_enc);
 fail:
return ERR_PTR(ret);
 }
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index 14fc7c2..57ece03 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -829,7 +829,6 @@ struct dpu_encoder_phys *dpu_encoder_phys_vid_init(
struct dpu_encoder_phys *phys_enc = NULL;
struct dpu_encoder_phys_vid *vid_enc = NULL;
struct dpu_rm_hw_iter iter;
-   struct dpu_hw_mdp *hw_mdp;
struct dpu_encoder_irq *irq;
int i, ret = 0;
 
@@ -846,13 +845,7 @@ struct dpu_encoder_phys *dpu_encoder_phys_vid_init(
 
phys_enc = _enc->base;
 
-   hw_mdp = dpu_rm_get_mdp(>dpu_kms->rm);
-   if (IS_ERR_OR_NULL(hw_mdp)) {
-   ret = PTR_ERR(hw_mdp);
-   DPU_ERROR("failed to get mdptop\n");
-   goto fail;
-   }
-   phys_enc->hw_mdptop = hw_mdp;
+   phys_enc->hw_mdptop = p->dpu_kms->hw_mdp;
phys_enc->intf_idx = p->intf_idx;
 
/**
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 02/13] drm/msm/dpu: remove resource pool manager

[Jeykumar Sankaran]

resource pool manager utility was introduced to manage
rotator sessions. Removing the support as the rotator
feature doesn't exist.

changes in v2:
- none
changes in v3:
- rebase on [1]

[1] https://gitlab.freedesktop.org/seanpaul/dpu-staging/commits/for-next

Change-Id: Ib045f1c66269be650bce5896c459f59e1047a53f
Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 205 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h |  56 -
 2 files changed, 261 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 80cbf75..1f2d223 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -99,187 +99,6 @@ static inline int _dpu_crtc_power_enable(struct dpu_crtc 
*dpu_crtc, bool enable)
return 0;
 }
 
-/**
- * _dpu_crtc_rp_to_crtc - get crtc from resource pool object
- * @rp: Pointer to resource pool
- * return: Pointer to drm crtc if success; null otherwise
- */
-static struct drm_crtc *_dpu_crtc_rp_to_crtc(struct dpu_crtc_respool *rp)
-{
-   if (!rp)
-   return NULL;
-
-   return container_of(rp, struct dpu_crtc_state, rp)->base.crtc;
-}
-
-/**
- * _dpu_crtc_rp_reclaim - reclaim unused, or all if forced, resources in pool
- * @rp: Pointer to resource pool
- * @force: True to reclaim all resources; otherwise, reclaim only unused ones
- * return: None
- */
-static void _dpu_crtc_rp_reclaim(struct dpu_crtc_respool *rp, bool force)
-{
-   struct dpu_crtc_res *res, *next;
-   struct drm_crtc *crtc;
-
-   crtc = _dpu_crtc_rp_to_crtc(rp);
-   if (!crtc) {
-   DPU_ERROR("invalid crtc\n");
-   return;
-   }
-
-   DPU_DEBUG("crtc%d.%u %s\n", crtc->base.id, rp->sequence_id,
-   force ? "destroy" : "free_unused");
-
-   list_for_each_entry_safe(res, next, >res_list, list) {
-   if (!force && !(res->flags & DPU_CRTC_RES_FLAG_FREE))
-   continue;
-   DPU_DEBUG("crtc%d.%u reclaim res:0x%x/0x%llx/%pK/%d\n",
-   crtc->base.id, rp->sequence_id,
-   res->type, res->tag, res->val,
-   atomic_read(>refcount));
-   list_del(>list);
-   if (res->ops.put)
-   res->ops.put(res->val);
-   kfree(res);
-   }
-}
-
-/**
- * _dpu_crtc_rp_free_unused - free unused resource in pool
- * @rp: Pointer to resource pool
- * return: none
- */
-static void _dpu_crtc_rp_free_unused(struct dpu_crtc_respool *rp)
-{
-   mutex_lock(rp->rp_lock);
-   _dpu_crtc_rp_reclaim(rp, false);
-   mutex_unlock(rp->rp_lock);
-}
-
-/**
- * _dpu_crtc_rp_destroy - destroy resource pool
- * @rp: Pointer to resource pool
- * return: None
- */
-static void _dpu_crtc_rp_destroy(struct dpu_crtc_respool *rp)
-{
-   mutex_lock(rp->rp_lock);
-   list_del_init(>rp_list);
-   _dpu_crtc_rp_reclaim(rp, true);
-   mutex_unlock(rp->rp_lock);
-}
-
-/**
- * _dpu_crtc_hw_blk_get - get callback for hardware block
- * @val: Resource handle
- * @type: Resource type
- * @tag: Search tag for given resource
- * return: Resource handle
- */
-static void *_dpu_crtc_hw_blk_get(void *val, u32 type, u64 tag)
-{
-   DPU_DEBUG("res:%d/0x%llx/%pK\n", type, tag, val);
-   return dpu_hw_blk_get(val, type, tag);
-}
-
-/**
- * _dpu_crtc_hw_blk_put - put callback for hardware block
- * @val: Resource handle
- * return: None
- */
-static void _dpu_crtc_hw_blk_put(void *val)
-{
-   DPU_DEBUG("res://%pK\n", val);
-   dpu_hw_blk_put(val);
-}
-
-/**
- * _dpu_crtc_rp_duplicate - duplicate resource pool and reset reference count
- * @rp: Pointer to original resource pool
- * @dup_rp: Pointer to duplicated resource pool
- * return: None
- */
-static void _dpu_crtc_rp_duplicate(struct dpu_crtc_respool *rp,
-   struct dpu_crtc_respool *dup_rp)
-{
-   struct dpu_crtc_res *res, *dup_res;
-   struct drm_crtc *crtc;
-
-   if (!rp || !dup_rp || !rp->rp_head) {
-   DPU_ERROR("invalid resource pool\n");
-   return;
-   }
-
-   crtc = _dpu_crtc_rp_to_crtc(rp);
-   if (!crtc) {
-   DPU_ERROR("invalid crtc\n");
-   return;
-   }
-
-   DPU_DEBUG("crtc%d.%u duplicate\n", crtc->base.id, rp->sequence_id);
-
-   mutex_lock(rp->rp_lock);
-   dup_rp->sequence_id = rp->sequence_id + 1;
-   INIT_LIST_HEAD(_rp->res_list);
-   dup_rp->ops = rp->ops;
-   list_for_each_entry(res, >res_list, list) {
-   dup_res = kzalloc(sizeof(struct dpu_crtc_res), GFP_KERNEL);
-   if (!dup_res) {
-   mutex_unlock(rp->rp_lock);
-   return;
-   }
-   INIT_LIST_HEAD(_res->list);
-   atomic_set(_res->refcount, 0);
-   dup_res->type = 

[PATCH v3 01/13] drm/msm/dpu: remove scalar config definitions

[Jeykumar Sankaran]

cleans up left out scalar config definitions from headers

changes in v2:
- none
changes in v3:
- none

Change-Id: Id824dd5075c666f97b964573c97215bb786eac75
Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h|  2 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 10 --
 2 files changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index e87109e..0e9aafa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -164,7 +164,6 @@ struct dpu_crtc_frame_event {
  * @cur_perf  : current performance committed to clock/bandwidth driver
  * @rp_lock   : serialization lock for resource pool
  * @rp_head   : list of active resource pool
- * @scl3_cfg_lut  : qseed3 lut config
  */
 struct dpu_crtc {
struct drm_crtc base;
@@ -175,7 +174,6 @@ struct dpu_crtc {
u32 num_mixers;
bool mixers_swapped;
struct dpu_crtc_mixer mixers[CRTC_DUAL_MIXERS];
-   struct dpu_hw_scaler3_lut_cfg *scl3_lut_cfg;
 
struct drm_pending_vblank_event *event;
u32 vsync_count;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
index 1240f50..c5c8f60 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
@@ -148,16 +148,6 @@ struct dpu_hw_scaler3_cfg {
struct dpu_hw_scaler3_de_cfg de;
 };
 
-struct dpu_hw_scaler3_lut_cfg {
-   bool is_configured;
-   u32 *dir_lut;
-   size_t dir_len;
-   u32 *cir_lut;
-   size_t cir_len;
-   u32 *sep_lut;
-   size_t sep_len;
-};
-
 /**
  * struct dpu_drm_pix_ext_v1 - version 1 of pixel ext structure
  * @num_ext_pxls_lr: Number of total horizontal pixels
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 00/13] Atomic resource management

[Jeykumar Sankaran]

This patchset series introduces drm private object in KMS to manage HW resource
management. It modifies the resource manager by introducing API's to do per DRM
object resource allocation/cleanups.

Patches 00/13 to 11/13 are clean up patches to prepare DPU for the above
migration.

major changes in v2:
- Fix return values in kms (Jordan)
- Split irrelevant changes from master patch
  into separate patches (Sean)

changes in v3:
- Rebase on [1]
- Fix control path bug in split LM topology

[1] https://gitlab.freedesktop.org/seanpaul/dpu-staging/commits/for-next

Jeykumar Sankaran (13):
  drm/msm/dpu: remove scalar config definitions
  drm/msm/dpu: remove resource pool manager
  drm/msm/dpu: remove ping pong split topology variables
  drm/msm/dpu: program master-slave encoders explicitly
  drm/msm/dpu: use kms stored hw mdp block
  drm/msm/dpu: iterate for assigned hw ctl in virtual encoder
  drm/msm/dpu: avoid querying for hw intf before assignment
  drm/msm/dpu: move hw resource tracking to crtc state
  drm/msm/dpu: rename hw_ctl to lm_ctl
  drm/msm/dpu: remove topology name
  drm/msm/dpu: remove display H_TILE from encoder
  drm/msm/dpu: add atomic private object to dpu kms
  drm/msm/dpu: use private obj to track hw resources

 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   | 427 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h   | 120 ++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 162 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|   4 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |   9 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |  31 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |  88 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h|  10 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  80 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|  23 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 796 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 149 ++--
 12 files changed, 612 insertions(+), 1287 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 03/13] drm/msm/dpu: remove ping pong split topology variables

[Jeykumar Sankaran]

removes left out variables of previous ping pong
split topology cleanup.

changes in v2:
- none
changes in v3:
- none

Change-Id: I1bf9d242039ce7cfd271233fa27840e83184fb95
Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index e84da78..e632651 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -219,7 +219,6 @@ struct dpu_crtc {
 /**
  * struct dpu_crtc_state - dpu container for atomic crtc state
  * @base: Base drm crtc state structure
- * @is_ppsplit: Whether current topology requires PPSplit special handling
  * @bw_control: true if bw/clk controlled by core bw/clk properties
  * @bw_split_vote : true if bw controlled by llcc/dram bw properties
  * @lm_bounds : LM boundaries based on current mode full resolution, no 
ROI.
@@ -234,8 +233,6 @@ struct dpu_crtc_state {
 
bool bw_control;
bool bw_split_vote;
-
-   bool is_ppsplit;
struct drm_rect lm_bounds[CRTC_DUAL_MIXERS];
 
uint64_t input_fence_timeout_ns;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/msm/disp/dpu: fix early dereference of physical encoder

[Jeykumar Sankaran]

This change validates the physical encoder before it
is dereferenced.

Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 +++-
 1 file changed, 3 insertions(+), 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 0922d35..1b4de34 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2444,6 +2444,8 @@ int dpu_encoder_wait_for_event(struct drm_encoder 
*drm_enc,
 
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
+   if (!phys)
+   continue;
 
switch (event) {
case MSM_ENC_COMMIT_DONE:
@@ -2461,7 +2463,7 @@ int dpu_encoder_wait_for_event(struct drm_encoder 
*drm_enc,
return -EINVAL;
};
 
-   if (phys && fn_wait) {
+   if (fn_wait) {
DPU_ATRACE_BEGIN("wait_for_completion_event");
ret = fn_wait(phys);
DPU_ATRACE_END("wait_for_completion_event");
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/atomic: add ATOMIC_AMEND flag to the Atomic IOCTL.

[Gustavo Padovan]

On Tue, Aug 07, 2018 at 06:40:39PM +0200, Daniel Vetter wrote:
> On Mon, Aug 06, 2018 at 06:01:02PM +0200, Enric Balletbo i Serra wrote:
> > From: Gustavo Padovan 
> > 
> > This flag tells core to jump ahead the queued update if the conditions
> > in drm_atomic_async_check() are met. That means we are only able to do an
> > async update if no modeset is pending and update for the same plane is
> > not queued.
> > 
> > It uses the already in place infrastructure for async updates.
> > 
> > It is useful for cursor updates and async PageFlips over the atomic
> > ioctl, otherwise in some cases updates may be delayed to the point the
> > user will notice it. Note that for now it's only enabled for cursor
> > planes.
> > 
> > DRM_MODE_ATOMIC_AMEND should be passed to the Atomic IOCTL to use this
> > feature.
> > 
> > Signed-off-by: Gustavo Padovan 
> > Signed-off-by: Enric Balletbo i Serra 
> > ---
> > Hi,
> > 
> > This is an attempt to introduce the new ATOMIC_AMEND flag for atomic
> > operations, see the commit message for a more detailed description.
> > 
> > This was tested using a small program that exercises the uAPI for easy
> > sanity testing. The program created by Alexandros can be found here
> > [2]. To test, just build the program and use the --atomic flag to use the
> > cursor plane in normal (blocking mode), and --atomic-async to use the cursor
> > plane with the ATOMIC_AMEND flag. E.g.
> > 
> >   drm_cursor --atomic
> > 
> > or
> > 
> >   drm_cursor --atomic-async
> 
> Would be really lovely to bake these into igt-based regression tests. i915
> doesn't yet have async update support, but I hope we'll eventually gain
> that, and then our CI could make sure this keeps working.
> 
> > The test worked on a Samsung Chromebook Plus on top of mainline plus
> > the patch to update cursors asynchronously through atomic for the
> > drm/rockchip driver.
> > 
> > Alexandros also did a proof-of-concept to use this flag and draw cursors
> > using atomic if possible on ozone [1].
> > 
> > Best regards,
> >  Enric
> > 
> > [1] https://chromium-review.googlesource.com/c/chromium/src/+/1092711
> > [2] https://gitlab.collabora.com/alf/drm-cursor
> > 
> > 
> > Changes in v1:
> > - Only enable it if userspace requests it.
> > - Only allow async update for cursor type planes.
> > - Rename ASYNC_UPDATE for ATOMIC_AMEND.
> > 
> >  drivers/gpu/drm/drm_atomic.c|  5 +
> >  drivers/gpu/drm/drm_atomic_helper.c | 10 +-
> >  include/uapi/drm/drm_mode.h |  4 +++-
> >  3 files changed, 17 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 895741e9cd7d..7b3e4aa2874d 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -2338,6 +2338,10 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
> > return -EINVAL;
> >  
> > +   if ((arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET) &&
> > +   (arg->flags & DRM_MODE_ATOMIC_AMEND))
> > +   return -EINVAL;
> > +
> > drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
> >  
> > state = drm_atomic_state_alloc(dev);
> > @@ -2346,6 +2350,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> >  
> > state->acquire_ctx = 
> > state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
> > +   state->async_update = !!(arg->flags & DRM_MODE_ATOMIC_AMEND);
> >  
> >  retry:
> > plane_mask = 0;
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 81e32199d3ef..59495f61c583 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -902,7 +902,7 @@ int drm_atomic_helper_check(struct drm_device *dev,
> > if (ret)
> > return ret;
> >  
> > -   if (state->legacy_cursor_update)
> > +   if (state->async_update || state->legacy_cursor_update)
> 
> Hm, it would be really cool if we could rip out the legacy_cursor_update
> hack and also use async_update in the cursor compat helpers. At least if
> available.

That would be nice indeed!

> 
> > state->async_update = !drm_atomic_helper_async_check(dev, 
> > state);
> >  
> > return ret;
> > @@ -1539,6 +1539,14 @@ int drm_atomic_helper_async_check(struct drm_device 
> > *dev,
> > if (new_plane_state->fence)
> > return -EINVAL;
> >  
> > +   /* Only allow async update for cursor type planes. */
> > +   if (plane->type != DRM_PLANE_TYPE_CURSOR)
> > +   return -EINVAL;
> 
> Why limit to cursor planes? The async_update hooks are per-plane.

Two reason that I can think of, we should have mentioned this on the
commit message:
- we have no real user space use case for anything other than cursor
- Ville wants to go down the road of fences per-plane for this, we'd
  want to signal the replaced planes, but not the whole crtc. That is
  of course a 

[Bug 200645] 4.18-rc regression bisected to e03fd3f30: amdgpu polaris11/rx460 only activates on one output/monitor of two

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200645

Duncan (1i5t5.dun...@cox.net) changed:

   What|Removed |Added

 Attachment #277491|0   |1
is obsolete||

--- Comment #6 from Duncan (1i5t5.dun...@cox.net) ---
Created attachment 277749
  --> https://bugzilla.kernel.org/attachment.cgi?id=277749=edit
xrandr output (working at 60 Hz)

The previous xrandr working output was with a setting on the 4K TV hooked up to
HDMI-A-0 set wrong, so @3840x2160 it'd only give me 30 Hz (tho that shouldn't
have mattered for this bug, since the problem is with DVI-D-0, not HDMI-A-0). 
This one has the TV set correctly so HDMI-A-0 will do 3840x2160 at full 60 Hz.

The bug's still there on rc8, with a revert of the commit to once again force
bpc <= 8 still fixing it (it's what I used to get this xrandr).  So at this
point it seems release will still be bugged.

Comparing to the tested-fixed bug @ freedesktop that bisected to the same
commit, the problem there was with the HDMI forced to 30 Hz @3840x2160, while
here it's with no display on a 1920x1080 DVI-D, with the 3840x2160 HDMI-A
behaving normally -- early-boot displays on the DVI-D and the HDMI-A at the
usual low res, but the DVI-D goes blank as soon as it switches to DRM/hi-res,
while the HDMI-A behaves entirely normally.  And once in X, xrandr says there's
no modes available for the (1920x1080-resolution) DVI-D, while again the
3840x2160 HDMI-A behaves entirely normally.

So perhaps a similar fix to the one on that bug (and now in tree) for HDMI, is
needed for DVI-D, tho it could be more than that as well, since (unlike the
freedesktop bug) the DVI-D is entirely blank and xrandr says it has no modes,
not even the low resolutions it was working with just fine in grub and early
boot.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm v2] radeon, evergreen: ensure equal sizes for depth-stencil npot textures

[Gert Wollny]

On evergreen depth-stencil textures are allocated as two objects, and
when using the eg_surface_init_1d_miptrees code path the size evaluation
uses the generalized surf_minify function. Here when allocating the
depth texture the alignment takes the depth bpe value into account, and
uses bpe=1 for the stencil texture. As a result the texture pair may
consist of textures with two different nblk_x sizes and this seems to
be a problem with some textures, namely npot and small (width < 32), but
not for mipmapped textures. In the problematic cases, if the so allocated
depth texture is larger than the stencil texture, then the kernel may reject
sent data with an error message like:

 evergreen_cs_track_validate_stencil:622 stencil read bo too
  small (layer size 131072, offset 524288, max layer 1, bo size 606208)

- because apparently the expected layer size is evaluated from the depth
texture size, but the actual bo size is evaluated based on the true texture
size values. If, on the other hand, the stencil texture is larger than the
depth texture, then the data is send with a wrong alignment, and certain
dEQP-GLES31 tests fail.

In order to obtain equal texture sizes in the problematic cases magnify
the depth texture alignment requirement by its bpe, so that the relative
alignment is the same for depth and stencil texture.

v2: * Also apply correction for pot textures with small with
+ don't apply correction textures with more than one mipmap level

Fixes:
  dEQP-GLES31.functional.stencil_texturing.format
.depth32f_stencil8_2d
.depth32f_stencil8_2d_array
.depth24_stencil8_2d Pass
.depth24_stencil8_2d_array
.stencil_index8_2d
.stencil_index8_2d_array
.depth32f_stencil8_draw
.depth24_stencil8_draw

  dEQP-GLES31.functional.texture.border_clamp.formats
.stencil_index8.nearest_size_npot
.depth24_stencil8_sample_stencil.nearest_size_npot
.depth32f_stencil8_sample_stencil.nearest_size_npot

  dEQP-GLES31.functional.texture.border_clamp.per_axis_wrap_mode.texture_2d
.uint_stencil.nearest.s_clamp_to_edge_t_clamp_to_border_npot
.uint_stencil.nearest.s_repeat_t_clamp_to_border_npot
.uint_stencil.nearest.s_mirrored_repeat_t_clamp_to_border_npot

  piglits:
arb_framebuffer_object-depth-stencil-blit *stencil*
framebuffer-blit-levels draw stencil
arb_texture_stencil8/
   texwrap formats offset/gl_stencil_index8, npot
   texwrap formats/gl_stencil_index8, npot
ext_framebuffer_multisample
   accuracy all_samples stencil_resolve small depthstencil
   unaligned-blit * stencil downsample
ext_texture_array/fbo-depth-array *stencil

Signed-off-by: Gert Wollny 
---
 radeon/radeon_surface.c | 44 
 1 file changed, 32 insertions(+), 12 deletions(-)

diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 3cafcfcb..ec88e8d4 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -612,6 +612,7 @@ static int eg_surface_init_1d(struct radeon_surface_manager 
*surf_man,
   struct radeon_surface *surf,
   struct radeon_surface_level *level,
   unsigned bpe,
+  unsigned align_maginify,
   uint64_t offset, unsigned start_level)
 {
 uint32_t xalign, yalign, zalign, tilew;
@@ -620,7 +621,7 @@ static int eg_surface_init_1d(struct radeon_surface_manager 
*surf_man,
 /* compute alignment */
 tilew = 8;
 xalign = surf_man->hw_info.group_bytes / (tilew * bpe * surf->nsamples);
-xalign = MAX2(tilew, xalign);
+xalign = MAX2(tilew, xalign * align_maginify);
 yalign = tilew;
 zalign = 1;
 if (surf->flags & RADEON_SURF_SCANOUT) {
@@ -652,7 +653,8 @@ static int eg_surface_init_1d(struct radeon_surface_manager 
*surf_man,
 static int eg_surface_init_2d(struct radeon_surface_manager *surf_man,
   struct radeon_surface *surf,
   struct radeon_surface_level *level,
-  unsigned bpe, unsigned tile_split,
+  unsigned bpe, unsigned align_magnify,
+  unsigned tile_split,
   uint64_t offset, unsigned start_level)
 {
 unsigned tilew, tileh, tileb;
@@ -691,7 +693,7 @@ static int eg_surface_init_2d(struct radeon_surface_manager 
*surf_man,
 level[i].mode = RADEON_SURF_MODE_2D;
 eg_surf_minify(surf, level+i, bpe, i, slice_pt, mtilew, mtileh, 
mtileb, offset);
 if (level[i].mode == RADEON_SURF_MODE_1D) {
-return eg_surface_init_1d(surf_man, surf, level, bpe, offset, i);
+return eg_surface_init_1d(surf_man, surf, level, bpe, 
align_magnify, offset, i);
 }
 /* level0 and first mipmap need to have alignment */
 offset = surf->bo_size;
@@ -793,16 +795,26 @@ static int 

[PATCH] drm/nouveau: Don't forget to cancel hpd_work on suspend/unload

[Lyude Paul]

Currently, there's nothing in nouveau that actually cancels this work
struct. So, cancel it on suspend/unload. Otherwise, if we're unlucky
enough hpd_work might try to keep running up until the system is
suspended.

Signed-off-by: Lyude Paul 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 9 ++---
 drivers/gpu/drm/nouveau/nouveau_display.h | 2 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
 3 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index ec7861457b84..1ba3f152cfcb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -425,7 +425,7 @@ nouveau_display_init(struct drm_device *dev)
 }
 
 void
-nouveau_display_fini(struct drm_device *dev, bool suspend)
+nouveau_display_fini(struct drm_device *dev, bool suspend, bool runtime)
 {
struct nouveau_display *disp = nouveau_display(dev);
struct nouveau_drm *drm = nouveau_drm(dev);
@@ -450,6 +450,9 @@ nouveau_display_fini(struct drm_device *dev, bool suspend)
}
drm_connector_list_iter_end(_iter);
 
+   if (!runtime)
+   cancel_work_sync(>hpd_work);
+
drm_kms_helper_poll_disable(dev);
disp->fini(dev);
 }
@@ -618,11 +621,11 @@ nouveau_display_suspend(struct drm_device *dev, bool 
runtime)
}
}
 
-   nouveau_display_fini(dev, true);
+   nouveau_display_fini(dev, true, runtime);
return 0;
}
 
-   nouveau_display_fini(dev, true);
+   nouveau_display_fini(dev, true, runtime);
 
list_for_each_entry(crtc, >mode_config.crtc_list, head) {
struct nouveau_framebuffer *nouveau_fb;
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.h 
b/drivers/gpu/drm/nouveau/nouveau_display.h
index 54aa7c3fa42d..ff92b54ce448 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.h
+++ b/drivers/gpu/drm/nouveau/nouveau_display.h
@@ -62,7 +62,7 @@ nouveau_display(struct drm_device *dev)
 int  nouveau_display_create(struct drm_device *dev);
 void nouveau_display_destroy(struct drm_device *dev);
 int  nouveau_display_init(struct drm_device *dev);
-void nouveau_display_fini(struct drm_device *dev, bool suspend);
+void nouveau_display_fini(struct drm_device *dev, bool suspend, bool runtime);
 int  nouveau_display_suspend(struct drm_device *dev, bool runtime);
 void nouveau_display_resume(struct drm_device *dev, bool runtime);
 int  nouveau_display_vblank_enable(struct drm_device *, unsigned int);
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index f5d3158f0378..20d4ab647cf7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -629,7 +629,7 @@ nouveau_drm_unload(struct drm_device *dev)
nouveau_debugfs_fini(drm);
 
if (dev->mode_config.num_crtc)
-   nouveau_display_fini(dev, false);
+   nouveau_display_fini(dev, false, false);
nouveau_display_destroy(dev);
 
nouveau_bios_takedown(dev);
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107518] polaris powerplay init fails: There must be 1 or more PCIE levels defined in PPTable

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107518

--- Comment #3 from Alex Deucher  ---
(In reply to Shawn Anastasio from comment #2)
> Upon further testing, the issue seems to go away when the firmware is
> removed from petitboot, preventing it from initializing the card before the
> host OS. This indicates that it may have something to do with the GPU being
> initialized twice.

The hw requires a special reset before it can be initialized again.  This is
handled in driver for things like hibernate (S4) 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 v5 09/13] drm/nouveau: Fix deadlock with fb_helper by inhibiting it's HPD

[Lyude Paul]

I'm sure I don't need to tell you that fb_helper's locking is a mess.
That being said; fb_helper's locking mess can seriously complicate the
runtime suspend/resume operations of drivers because it can invoke
atomic commits and connector probing from anywhere that calls
drm_fb_helper_hotplug_event(). Since most drivers use
drm_fb_helper_output_poll_changed() as their output_poll_changed
handler, this can happen in every single context that can fire off a
hotplug event. An example:

[  246.669625] INFO: task kworker/4:0:37 blocked for more than 120 seconds.
[  246.673398]   Not tainted 4.18.0-rc5Lyude-Test+ #2
[  246.675271] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  246.676527] kworker/4:0 D037  2 0x8000
[  246.677580] Workqueue: events output_poll_execute [drm_kms_helper]
[  246.678704] Call Trace:
[  246.679753]  __schedule+0x322/0xaf0
[  246.680916]  schedule+0x33/0x90
[  246.681924]  schedule_preempt_disabled+0x15/0x20
[  246.683023]  __mutex_lock+0x569/0x9a0
[  246.684035]  ? kobject_uevent_env+0x117/0x7b0
[  246.685132]  ? drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper]
[  246.686179]  mutex_lock_nested+0x1b/0x20
[  246.687278]  ? mutex_lock_nested+0x1b/0x20
[  246.688307]  drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper]
[  246.689420]  drm_fb_helper_output_poll_changed+0x23/0x30 [drm_kms_helper]
[  246.690462]  drm_kms_helper_hotplug_event+0x2a/0x30 [drm_kms_helper]
[  246.691570]  output_poll_execute+0x198/0x1c0 [drm_kms_helper]
[  246.692611]  process_one_work+0x231/0x620
[  246.693725]  worker_thread+0x214/0x3a0
[  246.694756]  kthread+0x12b/0x150
[  246.695856]  ? wq_pool_ids_show+0x140/0x140
[  246.696888]  ? kthread_create_worker_on_cpu+0x70/0x70
[  246.697998]  ret_from_fork+0x3a/0x50
[  246.699034] INFO: task kworker/0:1:60 blocked for more than 120 seconds.
[  246.700153]   Not tainted 4.18.0-rc5Lyude-Test+ #2
[  246.701182] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  246.702278] kworker/0:1 D060  2 0x8000
[  246.703293] Workqueue: pm pm_runtime_work
[  246.704393] Call Trace:
[  246.705403]  __schedule+0x322/0xaf0
[  246.706439]  ? wait_for_completion+0x104/0x190
[  246.707393]  schedule+0x33/0x90
[  246.708375]  schedule_timeout+0x3a5/0x590
[  246.709289]  ? mark_held_locks+0x58/0x80
[  246.710208]  ? _raw_spin_unlock_irq+0x2c/0x40
[  246.711222]  ? wait_for_completion+0x104/0x190
[  246.712134]  ? trace_hardirqs_on_caller+0xf4/0x190
[  246.713094]  ? wait_for_completion+0x104/0x190
[  246.713964]  wait_for_completion+0x12c/0x190
[  246.714895]  ? wake_up_q+0x80/0x80
[  246.715727]  ? get_work_pool+0x90/0x90
[  246.716649]  flush_work+0x1c9/0x280
[  246.717483]  ? flush_workqueue_prep_pwqs+0x1b0/0x1b0
[  246.718442]  __cancel_work_timer+0x146/0x1d0
[  246.719247]  cancel_delayed_work_sync+0x13/0x20
[  246.720043]  drm_kms_helper_poll_disable+0x1f/0x30 [drm_kms_helper]
[  246.721123]  nouveau_pmops_runtime_suspend+0x3d/0xb0 [nouveau]
[  246.721897]  pci_pm_runtime_suspend+0x6b/0x190
[  246.722825]  ? pci_has_legacy_pm_support+0x70/0x70
[  246.723737]  __rpm_callback+0x7a/0x1d0
[  246.724721]  ? pci_has_legacy_pm_support+0x70/0x70
[  246.725607]  rpm_callback+0x24/0x80
[  246.726553]  ? pci_has_legacy_pm_support+0x70/0x70
[  246.727376]  rpm_suspend+0x142/0x6b0
[  246.728185]  pm_runtime_work+0x97/0xc0
[  246.728938]  process_one_work+0x231/0x620
[  246.729796]  worker_thread+0x44/0x3a0
[  246.730614]  kthread+0x12b/0x150
[  246.731395]  ? wq_pool_ids_show+0x140/0x140
[  246.732202]  ? kthread_create_worker_on_cpu+0x70/0x70
[  246.732878]  ret_from_fork+0x3a/0x50
[  246.733768] INFO: task kworker/4:2:422 blocked for more than 120 seconds.
[  246.734587]   Not tainted 4.18.0-rc5Lyude-Test+ #2
[  246.735393] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  246.736113] kworker/4:2 D0   422  2 0x8080
[  246.736789] Workqueue: events_long drm_dp_mst_link_probe_work 
[drm_kms_helper]
[  246.737665] Call Trace:
[  246.738490]  __schedule+0x322/0xaf0
[  246.739250]  schedule+0x33/0x90
[  246.739908]  rpm_resume+0x19c/0x850
[  246.740750]  ? finish_wait+0x90/0x90
[  246.741541]  __pm_runtime_resume+0x4e/0x90
[  246.742370]  nv50_disp_atomic_commit+0x31/0x210 [nouveau]
[  246.743124]  drm_atomic_commit+0x4a/0x50 [drm]
[  246.743775]  restore_fbdev_mode_atomic+0x1c8/0x240 [drm_kms_helper]
[  246.744603]  restore_fbdev_mode+0x31/0x140 [drm_kms_helper]
[  246.745373]  drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xb0 
[drm_kms_helper]
[  246.746220]  drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper]
[  246.746884]  drm_fb_helper_hotplug_event.part.28+0x96/0xb0 [drm_kms_helper]
[  246.747675]  drm_fb_helper_output_poll_changed+0x23/0x30 [drm_kms_helper]
[  246.748544]  drm_kms_helper_hotplug_event+0x2a/0x30 [drm_kms_helper]
[  246.749439]  nv50_mstm_hotplug+0x15/0x20 [nouveau]
[  246.750111]  

[PATCH v5 13/13] drm/nouveau: Call pm_runtime_get_noresume() from hpd handlers

[Lyude Paul]

We can't and don't need to try resuming the device from our hotplug
handlers, but hotplug events are generally something we'd like to keep
the device awake for whenever possible. So, grab a PM ref safely in our
hotplug handlers using pm_runtime_get_noresume() and mark the device as
busy once we're finished.

Signed-off-by: Lyude Paul 
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner 
Cc: Karol Herbst 
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 8409c3f2c3a1..5a8e8c1ad647 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1152,6 +1152,11 @@ nouveau_connector_hotplug(struct nvif_notify *notify)
const char *name = connector->name;
struct nouveau_encoder *nv_encoder;
 
+   /* Resuming the device here isn't possible; but the suspend PM ops
+* will wait for us to finish our work before disabling us so this
+* should be enough
+*/
+   pm_runtime_get_noresume(drm->dev->dev);
nv_connector->hpd_task = current;
 
if (rep->mask & NVIF_NOTIFY_CONN_V0_IRQ) {
@@ -1171,6 +1176,9 @@ nouveau_connector_hotplug(struct nvif_notify *notify)
}
 
nv_connector->hpd_task = NULL;
+
+   pm_runtime_mark_last_busy(drm->dev->dev);
+   pm_runtime_put_autosuspend(drm->dev->dev);
return NVIF_NOTIFY_KEEP;
 }
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 08/13] drm/nouveau: Don't ignore nouveau_do_suspend() ret value

[Lyude Paul]

Otherwise, how will we roll everything back?

Signed-off-by: Lyude Paul 
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner 
Cc: Karol Herbst 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index db56e9b6b6af..f79b435368ec 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -842,6 +842,9 @@ nouveau_pmops_runtime_suspend(struct device *dev)
}
 
ret = nouveau_do_suspend(drm_dev, true);
+   if (ret)
+   return ret;
+
nouveau_switcheroo_optimus_dsm();
pci_save_state(pdev);
pci_disable_device(pdev);
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 12/13] drm/nouveau: Fix deadlocks in nouveau_connector_detect()

[Lyude Paul]

When we disable hotplugging on the GPU, we need to be able to
synchronize with each connector's hotplug interrupt handler before the
interrupt is finally disabled. This can be a problem however, since
nouveau_connector_detect() currently grabs a runtime power reference
when handling connector probing. This will deadlock the runtime suspend
handler like so:

[  861.480896] INFO: task kworker/0:2:61 blocked for more than 120 seconds.
[  861.483290]   Tainted: G   O  4.18.0-rc6Lyude-Test+ #1
[  861.485158] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  861.486332] kworker/0:2 D061  2 0x8000
[  861.487044] Workqueue: events nouveau_display_hpd_work [nouveau]
[  861.487737] Call Trace:
[  861.488394]  __schedule+0x322/0xaf0
[  861.489070]  schedule+0x33/0x90
[  861.489744]  rpm_resume+0x19c/0x850
[  861.490392]  ? finish_wait+0x90/0x90
[  861.491068]  __pm_runtime_resume+0x4e/0x90
[  861.491753]  nouveau_display_hpd_work+0x22/0x60 [nouveau]
[  861.492416]  process_one_work+0x231/0x620
[  861.493068]  worker_thread+0x44/0x3a0
[  861.493722]  kthread+0x12b/0x150
[  861.494342]  ? wq_pool_ids_show+0x140/0x140
[  861.494991]  ? kthread_create_worker_on_cpu+0x70/0x70
[  861.495648]  ret_from_fork+0x3a/0x50
[  861.496304] INFO: task kworker/6:2:320 blocked for more than 120 seconds.
[  861.496968]   Tainted: G   O  4.18.0-rc6Lyude-Test+ #1
[  861.497654] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  861.498341] kworker/6:2 D0   320  2 0x8080
[  861.499045] Workqueue: pm pm_runtime_work
[  861.499739] Call Trace:
[  861.500428]  __schedule+0x322/0xaf0
[  861.501134]  ? wait_for_completion+0x104/0x190
[  861.501851]  schedule+0x33/0x90
[  861.502564]  schedule_timeout+0x3a5/0x590
[  861.503284]  ? mark_held_locks+0x58/0x80
[  861.503988]  ? _raw_spin_unlock_irq+0x2c/0x40
[  861.504710]  ? wait_for_completion+0x104/0x190
[  861.505417]  ? trace_hardirqs_on_caller+0xf4/0x190
[  861.506136]  ? wait_for_completion+0x104/0x190
[  861.506845]  wait_for_completion+0x12c/0x190
[  861.507555]  ? wake_up_q+0x80/0x80
[  861.508268]  flush_work+0x1c9/0x280
[  861.508990]  ? flush_workqueue_prep_pwqs+0x1b0/0x1b0
[  861.509735]  nvif_notify_put+0xb1/0xc0 [nouveau]
[  861.510482]  nouveau_display_fini+0xbd/0x170 [nouveau]
[  861.511241]  nouveau_display_suspend+0x67/0x120 [nouveau]
[  861.511969]  nouveau_do_suspend+0x5e/0x2d0 [nouveau]
[  861.512715]  nouveau_pmops_runtime_suspend+0x47/0xb0 [nouveau]
[  861.513435]  pci_pm_runtime_suspend+0x6b/0x180
[  861.514165]  ? pci_has_legacy_pm_support+0x70/0x70
[  861.514897]  __rpm_callback+0x7a/0x1d0
[  861.515618]  ? pci_has_legacy_pm_support+0x70/0x70
[  861.516313]  rpm_callback+0x24/0x80
[  861.517027]  ? pci_has_legacy_pm_support+0x70/0x70
[  861.517741]  rpm_suspend+0x142/0x6b0
[  861.518449]  pm_runtime_work+0x97/0xc0
[  861.519144]  process_one_work+0x231/0x620
[  861.519831]  worker_thread+0x44/0x3a0
[  861.520522]  kthread+0x12b/0x150
[  861.521220]  ? wq_pool_ids_show+0x140/0x140
[  861.521925]  ? kthread_create_worker_on_cpu+0x70/0x70
[  861.522622]  ret_from_fork+0x3a/0x50
[  861.523299] INFO: task kworker/6:0:1329 blocked for more than 120 seconds.
[  861.523977]   Tainted: G   O  4.18.0-rc6Lyude-Test+ #1
[  861.524644] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  861.525349] kworker/6:0 D0  1329  2 0x8000
[  861.526073] Workqueue: events nvif_notify_work [nouveau]
[  861.526751] Call Trace:
[  861.527411]  __schedule+0x322/0xaf0
[  861.528089]  schedule+0x33/0x90
[  861.528758]  rpm_resume+0x19c/0x850
[  861.529399]  ? finish_wait+0x90/0x90
[  861.530073]  __pm_runtime_resume+0x4e/0x90
[  861.530798]  nouveau_connector_detect+0x7e/0x510 [nouveau]
[  861.531459]  ? ww_mutex_lock+0x47/0x80
[  861.532097]  ? ww_mutex_lock+0x47/0x80
[  861.532819]  ? drm_modeset_lock+0x88/0x130 [drm]
[  861.533481]  drm_helper_probe_detect_ctx+0xa0/0x100 [drm_kms_helper]
[  861.534127]  drm_helper_hpd_irq_event+0xa4/0x120 [drm_kms_helper]
[  861.534940]  nouveau_connector_hotplug+0x98/0x120 [nouveau]
[  861.535556]  nvif_notify_work+0x2d/0xb0 [nouveau]
[  861.536221]  process_one_work+0x231/0x620
[  861.536994]  worker_thread+0x44/0x3a0
[  861.537757]  kthread+0x12b/0x150
[  861.538463]  ? wq_pool_ids_show+0x140/0x140
[  861.539102]  ? kthread_create_worker_on_cpu+0x70/0x70
[  861.539815]  ret_from_fork+0x3a/0x50
[  861.540521]
   Showing all locks held in the system:
[  861.541696] 2 locks held by kworker/0:2/61:
[  861.542406]  #0: 2dbf8af5 ((wq_completion)"events"){+.+.}, at: 
process_one_work+0x1b3/0x620
[  861.543071]  #1: 76868126 ((work_completion)(>hpd_work)){+.+.}, 
at: process_one_work+0x1b3/0x620
[  861.543814] 1 lock held by khungtaskd/64:
[  861.544535]  #0: 59db4b53 (rcu_read_lock){}, at: 
debug_show_all_locks+0x23/0x185
[  861.545160] 3 locks held 

[PATCH v5 11/13] drm/nouveau: Respond to HPDs by probing one conn at a time

[Lyude Paul]

There isn't actually any reason we need to call drm_hpd_irq_event() from
our hotplug handler, as we already know which connector the hotplug
event was fired for. We're also going to need to avoid probing all
connectors needlessly from hotplug handlers anyway so that we can track
when nouveau_connector_detect() is being called from the context of it's
connector's hotplug handler in order to fix the next deadlocking issue.

This is (slightly) faster anyway!

Signed-off-by: Lyude Paul 
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner 
Cc: Karol Herbst 
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 28 -
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 010d6db14cba..9714e09f17db 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1114,6 +1114,32 @@ nouveau_connector_funcs_lvds = {
.atomic_get_property = nouveau_conn_atomic_get_property,
 };
 
+static void
+nouveau_connector_hotplug_probe(struct nouveau_connector *nv_conn)
+{
+   struct drm_modeset_acquire_ctx ctx;
+   struct drm_connector *conn = _conn->base;
+   enum drm_connector_status old_status;
+   struct drm_device *dev = conn->dev;
+   bool changed;
+
+   mutex_lock(>mode_config.mutex);
+
+   drm_modeset_acquire_init(, 0);
+   drm_modeset_lock(>mode_config.connection_mutex, );
+
+   old_status = conn->status;
+   conn->status = drm_helper_probe_detect(conn, , true);
+   changed = old_status != conn->status;
+
+   drm_modeset_drop_locks();
+   drm_modeset_acquire_fini();
+   mutex_unlock(>mode_config.mutex);
+
+   if (changed)
+   drm_kms_helper_hotplug_event(dev);
+}
+
 static int
 nouveau_connector_hotplug(struct nvif_notify *notify)
 {
@@ -1138,7 +1164,7 @@ nouveau_connector_hotplug(struct nvif_notify *notify)
nv50_mstm_remove(nv_encoder->dp.mstm);
}
 
-   drm_helper_hpd_irq_event(connector->dev);
+   nouveau_connector_hotplug_probe(nv_connector);
}
 
return NVIF_NOTIFY_KEEP;
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 05/13] drm/nouveau: Remove useless poll_enable() call in drm_load()

[Lyude Paul]

Again, this doesn't do anything. drm_kms_helper_poll_enable() will have
already been called in nouveau_display_init()

Signed-off-by: Lyude Paul 
Cc: Lukas Wunner 
Cc: Karol Herbst 
[omitting stable Cc, this probably doesn't fix any real bugs]
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 5fdc1fbe2ee5..04f704b77a3c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -592,10 +592,8 @@ nouveau_drm_load(struct drm_device *dev, unsigned long 
flags)
pm_runtime_allow(dev->dev);
pm_runtime_mark_last_busy(dev->dev);
pm_runtime_put(dev->dev);
-   } else {
-   /* enable polling for external displays */
-   drm_kms_helper_poll_enable(dev);
}
+
return 0;
 
 fail_dispinit:
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 10/13] drm/nouveau: Use pm_runtime_get_noresume() in connector_detect()

[Lyude Paul]

It's true we can't resume the device from poll workers in
nouveau_connector_detect(). We can however, prevent the autosuspend
timer from elapsing immediately if it hasn't already without risking any
sort of deadlock with the runtime suspend/resume operations. So do that
instead of entirely avoiding grabbing a power reference.

Signed-off-by: Lyude Paul 
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner 
Cc: Karol Herbst 
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 2a45b4c2ceb0..010d6db14cba 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -572,12 +572,16 @@ nouveau_connector_detect(struct drm_connector *connector, 
bool force)
nv_connector->edid = NULL;
}
 
-   /* Outputs are only polled while runtime active, so acquiring a
-* runtime PM ref here is unnecessary (and would deadlock upon
-* runtime suspend because it waits for polling to finish).
+   /* Outputs are only polled while runtime active, so resuming the
+* device here is unnecessary (and would deadlock upon runtime suspend
+* because it waits for polling to finish). We do however, want to
+* prevent the autosuspend timer from elapsing during this operation
+* if possible.
 */
-   if (!drm_kms_helper_is_poll_worker()) {
-   ret = pm_runtime_get_sync(connector->dev->dev);
+   if (drm_kms_helper_is_poll_worker()) {
+   pm_runtime_get_noresume(dev->dev);
+   } else {
+   ret = pm_runtime_get_sync(dev->dev);
if (ret < 0 && ret != -EACCES)
return conn_status;
}
@@ -655,10 +659,8 @@ nouveau_connector_detect(struct drm_connector *connector, 
bool force)
 
  out:
 
-   if (!drm_kms_helper_is_poll_worker()) {
-   pm_runtime_mark_last_busy(connector->dev->dev);
-   pm_runtime_put_autosuspend(connector->dev->dev);
-   }
+   pm_runtime_mark_last_busy(dev->dev);
+   pm_runtime_put_autosuspend(dev->dev);
 
return conn_status;
 }
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 04/13] drm/nouveau: Remove useless poll_disable() call in switcheroo_set_state()

[Lyude Paul]

This won't do anything but potentially make us miss hotplugs. We already
call drm_kms_helper_poll_disable() in
nouveau_pmops_suspend()->nouveau_display_suspend()->nouveau_display_fini()

Signed-off-by: Lyude Paul 
Cc: Lukas Wunner 
Cc: Karol Herbst 
[omitting stable Cc, this likely doesn't fix anything important enough
for that]
---
 drivers/gpu/drm/nouveau/nouveau_vga.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c 
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index 09b1d8151881..8f1ce4833230 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -50,7 +50,6 @@ nouveau_switcheroo_set_state(struct pci_dev *pdev,
} else {
pr_err("VGA switcheroo: switched nouveau off\n");
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
-   drm_kms_helper_poll_disable(dev);
nouveau_switcheroo_optimus_dsm();
nouveau_pmops_suspend(>dev);
dev->switch_power_state = DRM_SWITCH_POWER_OFF;
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 06/13] drm/nouveau: Call optimus_dsm functions after nouveau_do_suspend()

[Lyude Paul]

It's not necessary to call these before we call nouveau_do_suspend().
Ideally; we shouldn't have to call this at all here, but getting that to
work will take a bit more effort. So for the time being, just move this
call after nouveau_do_suspend() to allow us to easily be able to abort
the runtime suspend process in nouveau_do_suspend()

Signed-off-by: Lyude Paul 
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner 
Cc: Karol Herbst 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 04f704b77a3c..5ea8fe992484 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -833,8 +833,8 @@ nouveau_pmops_runtime_suspend(struct device *dev)
return -EBUSY;
}
 
-   nouveau_switcheroo_optimus_dsm();
ret = nouveau_do_suspend(drm_dev, true);
+   nouveau_switcheroo_optimus_dsm();
pci_save_state(pdev);
pci_disable_device(pdev);
pci_ignore_hotplug(pdev);
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 03/13] drm/nouveau: Remove useless poll_enable() call in switcheroo_set_state()

[Lyude Paul]

This doesn't do anything, drm_kms_helper_poll_enable() gets called in
nouveau_pmops_resume()->nouveau_display_resume()->nouveau_display_init()
already.

Signed-off-by: Lyude Paul 
Cc: Lukas Wunner 
Cc: Karol Herbst 
[omitting stable Cc, this likely doesn't fix any real bugs]
---
 drivers/gpu/drm/nouveau/nouveau_vga.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c 
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index 3da5a4305aa4..09b1d8151881 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -46,7 +46,6 @@ nouveau_switcheroo_set_state(struct pci_dev *pdev,
pr_err("VGA switcheroo: switched nouveau on\n");
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
nouveau_pmops_resume(>dev);
-   drm_kms_helper_poll_enable(dev);
dev->switch_power_state = DRM_SWITCH_POWER_ON;
} else {
pr_err("VGA switcheroo: switched nouveau off\n");
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 02/13] drm/nouveau: Remove duplicate poll_enable() in pmops_runtime_suspend()

[Lyude Paul]

Since actual hotplug notifications don't get disabled until
nouveau_display_fini() is called, all this will do is cause any hotplugs
that happen between this drm_kms_helper_poll_disable() call and the
actual hotplug disablement to potentially be dropped if ACPI isn't
around to help us.

Signed-off-by: Lyude Paul 
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner 
Cc: Karol Herbst 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index c7ec86d6c3c9..5fdc1fbe2ee5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -835,7 +835,6 @@ nouveau_pmops_runtime_suspend(struct device *dev)
return -EBUSY;
}
 
-   drm_kms_helper_poll_disable(drm_dev);
nouveau_switcheroo_optimus_dsm();
ret = nouveau_do_suspend(drm_dev, true);
pci_save_state(pdev);
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 00/13] Fix connector probing deadlocks from RPM bugs

[Lyude Paul]

This is the latest version of https://patchwork.freedesktop.org/series/46815/

I moved everything out of fb_helper and back into nouveau, because it
seems that other drivers actually do have this handled already as far as
I can tell.

Lyude Paul (13):
  drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement
  drm/nouveau: Remove duplicate poll_enable() in pmops_runtime_suspend()
  drm/nouveau: Remove useless poll_enable() call in
switcheroo_set_state()
  drm/nouveau: Remove useless poll_disable() call in
switcheroo_set_state()
  drm/nouveau: Remove useless poll_enable() call in drm_load()
  drm/nouveau: Call optimus_dsm functions after nouveau_do_suspend()
  drm/nouveau: Add missing unroll functions in nouveau_do_suspend()
  drm/nouveau: Don't ignore nouveau_do_suspend() ret value
  drm/nouveau: Fix deadlock with fb_helper by inhibiting it's HPD
  drm/nouveau: Use pm_runtime_get_noresume() in connector_detect()
  drm/nouveau: Respond to HPDs by probing one conn at a time
  drm/nouveau: Fix deadlocks in nouveau_connector_detect()
  drm/nouveau: Call pm_runtime_get_noresume() from hpd handlers

 drivers/gpu/drm/nouveau/dispnv50/disp.c |  2 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c | 60 +++---
 drivers/gpu/drm/nouveau/nouveau_connector.h |  1 +
 drivers/gpu/drm/nouveau/nouveau_display.c   | 55 +
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 23 --
 drivers/gpu/drm/nouveau/nouveau_fbcon.c | 90 +
 drivers/gpu/drm/nouveau/nouveau_fbcon.h |  9 +++
 drivers/gpu/drm/nouveau/nouveau_vga.c   |  2 -
 8 files changed, 209 insertions(+), 33 deletions(-)

-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 01/13] drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement

[Lyude Paul]

Turns out this part is my fault for not noticing when reviewing
9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling"). Currently
we call drm_kms_helper_poll_enable() from nouveau_display_hpd_work().
This makes basically no sense however, because that means we're calling
drm_kms_helper_poll_enable() every time we schedule the hotplug
detection work. This is also against the advice mentioned in
drm_kms_helper_poll_enable()'s documentation:

 Note that calls to enable and disable polling must be strictly ordered,
 which is automatically the case when they're only call from
 suspend/resume callbacks.

Of course, hotplugs can't really be ordered. They could even happen
immediately after we called drm_kms_helper_poll_disable() in
nouveau_display_fini(), which can lead to all sorts of issues.

Additionally; enabling polling /after/ we call
drm_helper_hpd_irq_event() could also mean that we'd miss a hotplug
event anyway, since drm_helper_hpd_irq_event() wouldn't bother trying to
probe connectors so long as polling is disabled.

So; simply move this back into nouveau_display_init() again. The race
condition that both of these patches attempted to work around has
already been fixed properly in

  d61a5c106351 ("drm/nouveau: Fix deadlock on runtime suspend")

Fixes: 9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling")
Signed-off-by: Lyude Paul 
Cc: Lukas Wunner 
Cc: Peter Ujfalusi 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index ec7861457b84..1d36ab5d4796 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -355,8 +355,6 @@ nouveau_display_hpd_work(struct work_struct *work)
pm_runtime_get_sync(drm->dev->dev);
 
drm_helper_hpd_irq_event(drm->dev);
-   /* enable polling for external displays */
-   drm_kms_helper_poll_enable(drm->dev);
 
pm_runtime_mark_last_busy(drm->dev->dev);
pm_runtime_put_sync(drm->dev->dev);
@@ -411,6 +409,11 @@ nouveau_display_init(struct drm_device *dev)
if (ret)
return ret;
 
+   /* enable connector detection and polling for connectors without HPD
+* support
+*/
+   drm_kms_helper_poll_enable(dev);
+
/* enable hotplug interrupts */
drm_connector_list_iter_begin(dev, _iter);
nouveau_for_each_non_mst_connector_iter(connector, _iter) {
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 07/13] drm/nouveau: Add missing unroll functions in nouveau_do_suspend()

[Lyude Paul]

Currently, it appears that nouveau_do_suspend() forgets to roll back
suspending fbcon and suspending the device LEDs. We also currently skip
the entire rollback process if nouveau_display_suspend() fails. So, fix
that.

Signed-off-by: Lyude Paul 
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner 
Cc: Karol Herbst 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 5ea8fe992484..db56e9b6b6af 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -674,10 +674,11 @@ nouveau_do_suspend(struct drm_device *dev, bool runtime)
if (dev->mode_config.num_crtc) {
NV_DEBUG(drm, "suspending console...\n");
nouveau_fbcon_set_suspend(dev, 1);
+
NV_DEBUG(drm, "suspending display...\n");
ret = nouveau_display_suspend(dev, runtime);
if (ret)
-   return ret;
+   goto fail_fbcon;
}
 
NV_DEBUG(drm, "evicting buffers...\n");
@@ -719,7 +720,14 @@ nouveau_do_suspend(struct drm_device *dev, bool runtime)
if (dev->mode_config.num_crtc) {
NV_DEBUG(drm, "resuming display...\n");
nouveau_display_resume(dev, runtime);
+
+fail_fbcon:
+   NV_DEBUG(drm, "resuming console...\n");
+   nouveau_fbcon_set_suspend(dev, 0);
}
+
+   nouveau_led_resume(dev);
+
return ret;
 }
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] radeon, evergreen: ensure equal sizes for depth-stencil npot textures

[Gert Wollny]

It seems I did a wrong indication in the subject, 

Am Montag, den 06.08.2018, 10:13 +0200 schrieb Gert Wollny:
> On evergreen depth-stencil textures are allocated as two objects, and
> when using the eg_surface_init_1d_miptrees code path the size
> evaluation
> uses the generalized surf_minify function. Here when allocating the
> depth texture the alignment takes the depth bpe value into account,
> and
> uses bpe=1 for the stencil texture. As a result the texture pair may
> consist of textures with two different nblk_x sizes and this seems to
> be a problem with npot textures, i.e. if the so allocated depth
> texture
> is larger than the stencil texture, then the kernel may reject sent
> data
> with an error message like:
> 
>  evergreen_cs_track_validate_stencil:622 stencil read bo too
>   small (layer size 131072, offset 524288, max layer 1, bo size
> 606208)
> 
> because apparently the expected layer size is evaluated from the
> depth
> texture size, but the actual bo size is evaluated based on the true
> texture
> size values. If, on the other hand, the stencil texture is larger
> than the
> depth texture, then the data is send with a wrong alignment, and
> certain
> dEQP-GLES31 tests fail.
> 
> In order to obtain equal npot texture sizes magnify the depth texture
> alignment
> requirement in these cases by its bpe, so that the relative alignment
> is
> the same for depth and stencil texture.
> 
> Fixes on BARTS:
>   dEQP-GLES31.functional.stencil_texturing.format
> .depth32f_stencil8_2d
> .depth32f_stencil8_2d_array
> .depth24_stencil8_2d Pass
> .depth24_stencil8_2d_array
> .stencil_index8_2d
> .stencil_index8_2d_array
> .depth32f_stencil8_draw
> .depth24_stencil8_draw
> 
>   dEQP-GLES31.functional.texture.border_clamp.formats
> .stencil_index8.nearest_size_npot
> .depth24_stencil8_sample_stencil.nearest_size_npot
> .depth32f_stencil8_sample_stencil.nearest_size_npot
> 
>   dEQP-
> GLES31.functional.texture.border_clamp.per_axis_wrap_mode.texture_2d
> .uint_stencil.nearest.s_clamp_to_edge_t_clamp_to_border_npot
> .uint_stencil.nearest.s_repeat_t_clamp_to_border_npot
> .uint_stencil.nearest.s_mirrored_repeat_t_clamp_to_border_npot
> 
> Signed-off-by: Gert Wollny 
> ---
> Thanks for reviewing and any comments,
> Gert
> 
> PS: - I have commit rights for mesa, I'm not sure whether this also
> includes drm.
> - This is a resend, because I first tried with a mail address
> that was not 
>   subscribed to the list and the mail probably ended up in some
> moderation 
>   queue (sorry)
> 
>  radeon/radeon_surface.c | 38 +++---
>  1 file changed, 27 insertions(+), 11 deletions(-)
> 
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index 3cafcfcb..0579389c 100644
> --- a/radeon/radeon_surface.c
> +++ b/radeon/radeon_surface.c
> @@ -612,6 +612,7 @@ static int eg_surface_init_1d(struct
> radeon_surface_manager *surf_man,
>struct radeon_surface *surf,
>struct radeon_surface_level *level,
>unsigned bpe,
> +  unsigned align_maginify,
>uint64_t offset, unsigned start_level)
>  {
>  uint32_t xalign, yalign, zalign, tilew;
> @@ -620,7 +621,7 @@ static int eg_surface_init_1d(struct
> radeon_surface_manager *surf_man,
>  /* compute alignment */
>  tilew = 8;
>  xalign = surf_man->hw_info.group_bytes / (tilew * bpe * surf-
> >nsamples);
> -xalign = MAX2(tilew, xalign);
> +xalign = MAX2(tilew, xalign * align_maginify);
>  yalign = tilew;
>  zalign = 1;
>  if (surf->flags & RADEON_SURF_SCANOUT) {
> @@ -652,7 +653,8 @@ static int eg_surface_init_1d(struct
> radeon_surface_manager *surf_man,
>  static int eg_surface_init_2d(struct radeon_surface_manager
> *surf_man,
>struct radeon_surface *surf,
>struct radeon_surface_level *level,
> -  unsigned bpe, unsigned tile_split,
> +  unsigned bpe, unsigned align_magnify,
> +  unsigned tile_split,
>uint64_t offset, unsigned start_level)
>  {
>  unsigned tilew, tileh, tileb;
> @@ -691,7 +693,7 @@ static int eg_surface_init_2d(struct
> radeon_surface_manager *surf_man,
>  level[i].mode = RADEON_SURF_MODE_2D;
>  eg_surf_minify(surf, level+i, bpe, i, slice_pt, mtilew,
> mtileh, mtileb, offset);
>  if (level[i].mode == RADEON_SURF_MODE_1D) {
> -return eg_surface_init_1d(surf_man, surf, level, bpe,
> offset, i);
> +return eg_surface_init_1d(surf_man, surf, level, bpe,
> align_magnify, offset, i);
>  }
>  /* level0 and first mipmap need to have alignment */
>  offset = surf->bo_size;
> @@ -793,16 +795,24 @@ static int 

[Bug 107518] polaris powerplay init fails: There must be 1 or more PCIE levels defined in PPTable

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107518

--- Comment #2 from Shawn Anastasio  ---
Upon further testing, the issue seems to go away when the firmware is removed
from petitboot, preventing it from initializing the card before the host OS.
This indicates that it may have something to do with the GPU being initialized
twice.

-- 
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/sun4i: Avoid failing to init fbdev without any connector

[Paul Kocialkowski]

Hi,

Le mardi 07 août 2018 à 22:18 +0200, Daniel Vetter a écrit :
> On Tue, Aug 07, 2018 at 09:39:19PM +0200, Paul Kocialkowski wrote:
> > Initializing and registering fbdev requires at least one DRM connector
> > and will fail otherwise. In order to support headless setups (for
> > instance for GPU rendering with the GBM backend, where a DRI card node
> > is required to provide GEM memory reservation), add a check on the
> > number of registered connectors before initializing fbdev.
> 
> sun4i is a pure kms driver, why exactly do you need it for gbm backed
> rendering? What exactly is rendering here, and why does it insist on a
> display card node, even if that display card node is 100% defunct?

The non-free Mali blobs provide GPU support with a GBM interface that
takes a DRM fd in order to reserve the memory it needs for its rendering
targets. This uses the GEM interface available through the DRI card node
(and there is no render node with the non-free Mali driver). Allwinner
has a minimalistic out-of-tree driver pretty much only for this purpose.

I crafted this patch when someone on IRC tried to get the out-of-tree
Mali GPU driver going with the mainline kernel in order to do rendering
in a GBM buffer, since it's apparently the only option for headless
rendering with the blob.

In my opinion, supporting the pipeline of an out-of-tree GPU driver that
only works with a non-free userspace blob is not a valid reason to do
anything. Still, it felt like adding support for the headless use-case
wouldn't hurt, whatever the underlying use case for it may be. I found
that other drivers also implement the same mechanism (perhaps for
different reasons).

Cheers,

Paul

> -Daniel
> 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 10 +-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c 
> > b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
> > index 5f29850ef8ac..19a265e4a93a 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
> > @@ -49,6 +49,8 @@ static struct drm_mode_config_helper_funcs 
> > sun4i_de_mode_config_helpers = {
> >  
> >  int sun4i_framebuffer_init(struct drm_device *drm)
> >  {
> > +   int ret;
> > +
> > drm_mode_config_reset(drm);
> >  
> > drm->mode_config.max_width = 8192;
> > @@ -57,7 +59,13 @@ int sun4i_framebuffer_init(struct drm_device *drm)
> > drm->mode_config.funcs = _de_mode_config_funcs;
> > drm->mode_config.helper_private = _de_mode_config_helpers;
> >  
> > -   return drm_fb_cma_fbdev_init(drm, 32, 0);
> > +   if (drm->mode_config.num_connector > 0) {
> > +   ret = drm_fb_cma_fbdev_init(drm, 32, 0);
> > +   if (ret)
> > +   return ret;
> > +   }
> > +
> > +   return 0;
> >  }
> >  
> >  void sun4i_framebuffer_free(struct drm_device *drm)
> > -- 
> > 2.18.0
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
-- 
Developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/sun4i: Avoid failing to init fbdev without any connector

[Daniel Vetter]

On Tue, Aug 07, 2018 at 09:39:19PM +0200, Paul Kocialkowski wrote:
> Initializing and registering fbdev requires at least one DRM connector
> and will fail otherwise. In order to support headless setups (for
> instance for GPU rendering with the GBM backend, where a DRI card node
> is required to provide GEM memory reservation), add a check on the
> number of registered connectors before initializing fbdev.

sun4i is a pure kms driver, why exactly do you need it for gbm backed
rendering? What exactly is rendering here, and why does it insist on a
display card node, even if that display card node is 100% defunct?
-Daniel

> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c 
> b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
> index 5f29850ef8ac..19a265e4a93a 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
> @@ -49,6 +49,8 @@ static struct drm_mode_config_helper_funcs 
> sun4i_de_mode_config_helpers = {
>  
>  int sun4i_framebuffer_init(struct drm_device *drm)
>  {
> + int ret;
> +
>   drm_mode_config_reset(drm);
>  
>   drm->mode_config.max_width = 8192;
> @@ -57,7 +59,13 @@ int sun4i_framebuffer_init(struct drm_device *drm)
>   drm->mode_config.funcs = _de_mode_config_funcs;
>   drm->mode_config.helper_private = _de_mode_config_helpers;
>  
> - return drm_fb_cma_fbdev_init(drm, 32, 0);
> + if (drm->mode_config.num_connector > 0) {
> + ret = drm_fb_cma_fbdev_init(drm, 32, 0);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
>  }
>  
>  void sun4i_framebuffer_free(struct drm_device *drm)
> -- 
> 2.18.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/doc: clarify how to acquire required vblank event reference

[Stefan Agner]

As a driver write it is not entirely obvious that a reference to
the event e mentioned in the doc can be obtained via
drm_crtc_vblank_get(). Clarify how to obtain the reference.

Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/drm_vblank.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 28cdcf76b6f9..7610ff466ef9 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -873,8 +873,8 @@ static void send_vblank_event(struct drm_device *dev,
  * handler by calling drm_crtc_send_vblank_event() and make sure that there's 
no
  * possible race with the hardware committing the atomic update.
  *
- * Caller must hold a vblank reference for the event @e, which will be dropped
- * when the next vblank arrives.
+ * Caller must hold a vblank reference for the event @e acquired by a
+ * drm_crtc_vblank_get(), which will be dropped when the next vblank arrives.
  */
 void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
   struct drm_pending_vblank_event *e)
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [GIT PULL] tilcdc fixes for v4.19

[Dave Airlie]

On 3 August 2018 at 02:55, Jyri Sarha  wrote:
> Hi Dave,
> Please pull the tilcdc fixes for Linux v4.19. This fix has been pending
> for some while, because I was planning for a bigger clean up that would
> remove the need for this fix. But as it is the time for it - at least
> for v4.19 - is gone already so here is just this small fix.

I already had this in my tree for drm-next for v4.19

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107518] polaris powerplay init fails: There must be 1 or more PCIE levels defined in PPTable

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107518

--- Comment #1 from Shawn Anastasio  ---
Created attachment 141003
  --> https://bugs.freedesktop.org/attachment.cgi?id=141003=edit
dmesg for 4.18.0-rc8+

-- 
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 v6] drm/amdgpu: Transfer fences to dmabuf importer

[Chris Wilson]

amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As such, on exporting a dmabuf, we must either flush all
outstanding fences (for we do not know which are writes and should have
been exclusive) or alternatively create a new exclusive fence that is
the composite of all the existing shared fences, and so will only be
signaled when all earlier fences are signaled (ensuring that we can not
be signaled before the completion of any earlier write).

v2: reservation_object is already locked by amdgpu_bo_reserve()
v3: Replace looping with get_fences_rcu and special case the promotion
of a single shared fence directly to an exclusive fence, bypassing the
fence array.
v4: Drop the fence array ref after assigning to reservation_object

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341
Testcase: igt/amd_prime/amd-to-i915
References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to prime exported 
bo's. (v5)")
Signed-off-by: Chris Wilson 
Cc: Alex Deucher 
Cc: "Christian König" 
Reviewed-by: "Christian König" 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 59 ---
 1 file changed, 51 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 3fdd5688da0b..0394f5c77f81 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -37,6 +37,7 @@
 #include "amdgpu_display.h"
 #include 
 #include 
+#include 
 
 static const struct dma_buf_ops amdgpu_dmabuf_ops;
 
@@ -188,6 +189,48 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
return ERR_PTR(ret);
 }
 
+static int
+__reservation_object_make_exclusive(struct reservation_object *obj)
+{
+   struct dma_fence **fences;
+   unsigned int count;
+   int r;
+
+   if (!reservation_object_get_list(obj)) /* no shared fences to convert */
+   return 0;
+
+   r = reservation_object_get_fences_rcu(obj, NULL, , );
+   if (r)
+   return r;
+
+   if (count == 0) {
+   /* Now that was unexpected. */
+   } else if (count == 1) {
+   reservation_object_add_excl_fence(obj, fences[0]);
+   dma_fence_put(fences[0]);
+   kfree(fences);
+   } else {
+   struct dma_fence_array *array;
+
+   array = dma_fence_array_create(count, fences,
+  dma_fence_context_alloc(1), 0,
+  false);
+   if (!array)
+   goto err_fences_put;
+
+   reservation_object_add_excl_fence(obj, >base);
+   dma_fence_put(>base);
+   }
+
+   return 0;
+
+err_fences_put:
+   while (count--)
+   dma_fence_put(fences[count]);
+   kfree(fences);
+   return -ENOMEM;
+}
+
 /**
  * amdgpu_gem_map_attach - _buf_ops.attach implementation
  * @dma_buf: shared DMA buffer
@@ -219,16 +262,16 @@ static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
 
if (attach->dev->driver != adev->dev->driver) {
/*
-* Wait for all shared fences to complete before we switch to 
future
-* use of exclusive fence on this prime shared bo.
+* We only create shared fences for internal use, but importers
+* of the dmabuf rely on exclusive fences for implicitly
+* tracking write hazards. As any of the current fences may
+* correspond to a write, we need to convert all existing
+* fences on the reservation object into a single exclusive
+* fence.
 */
-   r = reservation_object_wait_timeout_rcu(bo->tbo.resv,
-   true, false,
-   MAX_SCHEDULE_TIMEOUT);
-   if (unlikely(r < 0)) {
-   DRM_DEBUG_PRIME("Fence wait failed: %li\n", r);
+   r = __reservation_object_make_exclusive(bo->tbo.resv);
+   if (r)
goto error_unreserve;
-   }
}
 
/* pin buffer into GTT */
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/sun4i: Avoid failing to init fbdev without any connector

[Paul Kocialkowski]

Initializing and registering fbdev requires at least one DRM connector
and will fail otherwise. In order to support headless setups (for
instance for GPU rendering with the GBM backend, where a DRI card node
is required to provide GEM memory reservation), add a check on the
number of registered connectors before initializing fbdev.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c 
b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
index 5f29850ef8ac..19a265e4a93a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
@@ -49,6 +49,8 @@ static struct drm_mode_config_helper_funcs 
sun4i_de_mode_config_helpers = {
 
 int sun4i_framebuffer_init(struct drm_device *drm)
 {
+   int ret;
+
drm_mode_config_reset(drm);
 
drm->mode_config.max_width = 8192;
@@ -57,7 +59,13 @@ int sun4i_framebuffer_init(struct drm_device *drm)
drm->mode_config.funcs = _de_mode_config_funcs;
drm->mode_config.helper_private = _de_mode_config_helpers;
 
-   return drm_fb_cma_fbdev_init(drm, 32, 0);
+   if (drm->mode_config.num_connector > 0) {
+   ret = drm_fb_cma_fbdev_init(drm, 32, 0);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
 }
 
 void sun4i_framebuffer_free(struct drm_device *drm)
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vc4: Make sure to emit a tile coordinates between two MSAA loads.

[Eric Anholt]

The HW only executes a load once the tile coordinates packet happens,
and only tracks one at a time, so by emitting our two MSAA loads back
to back we would end up with an undefined color or Z buffer.

Fixes dEQP-EGL.functional.render.multi_context.gles2.rgb888_window

Signed-off-by: Eric Anholt 
Cc: Boris Brezillon 
---
 drivers/gpu/drm/vc4/vc4_render_cl.c | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_render_cl.c 
b/drivers/gpu/drm/vc4/vc4_render_cl.c
index 273984f71ae2..3c918eeaf56e 100644
--- a/drivers/gpu/drm/vc4/vc4_render_cl.c
+++ b/drivers/gpu/drm/vc4/vc4_render_cl.c
@@ -148,6 +148,12 @@ static void emit_tile(struct vc4_exec_info *exec,
}
 
if (setup->zs_read) {
+   if (setup->color_read) {
+   /* Exec previous load. */
+   vc4_tile_coordinates(setup, x, y);
+   vc4_store_before_load(setup);
+   }
+
if (args->zs_read.flags &
VC4_SUBMIT_RCL_SURFACE_READ_IS_FULL_RES) {
rcl_u8(setup, VC4_PACKET_LOAD_FULL_RES_TILE_BUFFER);
@@ -156,12 +162,6 @@ static void emit_tile(struct vc4_exec_info *exec,
>zs_read, x, y) |
VC4_LOADSTORE_FULL_RES_DISABLE_COLOR);
} else {
-   if (setup->color_read) {
-   /* Exec previous load. */
-   vc4_tile_coordinates(setup, x, y);
-   vc4_store_before_load(setup);
-   }
-
rcl_u8(setup, VC4_PACKET_LOAD_TILE_BUFFER_GENERAL);
rcl_u16(setup, args->zs_read.bits);
rcl_u32(setup, setup->zs_read->paddr +
@@ -291,16 +291,15 @@ static int vc4_create_rcl_bo(struct drm_device *dev, 
struct vc4_exec_info *exec,
}
}
if (setup->zs_read) {
+   if (setup->color_read) {
+   loop_body_size += VC4_PACKET_TILE_COORDINATES_SIZE;
+   loop_body_size += 
VC4_PACKET_STORE_TILE_BUFFER_GENERAL_SIZE;
+   }
+
if (args->zs_read.flags &
VC4_SUBMIT_RCL_SURFACE_READ_IS_FULL_RES) {
loop_body_size += 
VC4_PACKET_LOAD_FULL_RES_TILE_BUFFER_SIZE;
} else {
-   if (setup->color_read &&
-   !(args->color_read.flags &
- VC4_SUBMIT_RCL_SURFACE_READ_IS_FULL_RES)) {
-   loop_body_size += 
VC4_PACKET_TILE_COORDINATES_SIZE;
-   loop_body_size += 
VC4_PACKET_STORE_TILE_BUFFER_GENERAL_SIZE;
-   }
loop_body_size += 
VC4_PACKET_LOAD_TILE_BUFFER_GENERAL_SIZE;
}
}
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107518] polaris powerplay init fails: There must be 1 or more PCIE levels defined in PPTable

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107518

Bug ID: 107518
   Summary: polaris powerplay init fails: There must be 1 or more
PCIE levels defined in PPTable
   Product: DRI
   Version: unspecified
  Hardware: PowerPC
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: shawnanasta...@yahoo.com

Created attachment 141002
  --> https://bugs.freedesktop.org/attachment.cgi?id=141002=edit
dmesg for 4.17.11-200

When booting kernel 4.17 or 4.18-rc8+ (git) on a POWER9 system with an ASUS Rx
580 GPU, the following messages are printed to the kernel log:

[   10.398837] amdgpu: [powerplay] There must be 1 or more PCIE levels defined
in PPTable.
[   10.398839] amdgpu: [powerplay] Failed to populate SCLK during
PopulateNewDPMClocksStates Function!
[   10.398840] amdgpu: [powerplay] Failed to populate and upload SCLK MCLK DPM
levels!


Note that the system is booted with the kernel argument `amdgpu.dc=0` to work
around this issue: https://bugs.freedesktop.org/show_bug.cgi?id=107049

GPU performance seems to be significantly hindered as a result of these errors.

Booting with `amdgpu.dpm=0` silences the errors but does not improve
performance.

-- 
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] dma-buf: Remove requirement for ops->map() from dma_buf_export

[Daniel Vetter]

On Tue, Aug 07, 2018 at 07:36:47PM +0100, Chris Wilson wrote:
> Since commit 9ea0dfbf972 ("dma-buf: make map_atomic and map function
> pointers optional"), the core provides the no-op functions when map and
> map_atomic are not provided, so we no longer need assert that are
> supplied by a dma-buf exporter.
> 
> Fixes: 09ea0dfbf972 ("dma-buf: make map_atomic and map function pointers 
> optional")
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Gerd Hoffmann 
> Cc: Sumit Semwal 

Ooops.

Reviewed-by: Daniel Vetter 
> ---
>  drivers/dma-buf/dma-buf.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 13884474d158..02f7f9a89979 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -405,7 +405,6 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
> || !exp_info->ops->map_dma_buf
> || !exp_info->ops->unmap_dma_buf
> || !exp_info->ops->release
> -   || !exp_info->ops->map
> || !exp_info->ops->mmap)) {
>   return ERR_PTR(-EINVAL);
>   }
> -- 
> 2.18.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 4/4] drm/mxsfb: Switch to drm_atomic_helper_commit_tail_rpm

[Stefan Agner]

On 06.08.2018 21:31, Leonard Crestez wrote:
> The lcdif block is only powered on when display is active so plane
> updates when not enabled are not valid. Writing to an unpowered IP block
> is mostly ignored but can trigger bus errors on some chips.
> 
> Prevent this situation by switching to drm_atomic_helper_commit_tail_rpm
> and having the drm core ensure atomic_plane_update is only called while
> the crtc is active. This avoids having to keep track of "enabled" bits
> inside the mxsfb driver.
> 
> This also requires handling the vblank event for disable from
> mxsfb_pipe_update.

Hm, I don't think this is a new requirement. Simple KMS Helper Reference
clearly states that it should be called from update:
https://www.kernel.org/doc/html/v4.17/gpu/drm-kms-helpers.html#simple-kms-helper-reference

Probably using drm_atomic_helper_commit_tail_rpm just exacerbates an
issue which we haven't seen before...

Since I think it is a general fix, I'd rather prefer have it in a
separate commit.

> 
> Signed-off-by: Leonard Crestez 
> Suggested-by: Stefan Agner 
> ---
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index d797dfd40d98..5777e730085b 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -96,10 +96,14 @@ static const struct drm_mode_config_funcs
> mxsfb_mode_config_funcs = {
>   .fb_create  = drm_gem_fb_create,
>   .atomic_check   = drm_atomic_helper_check,
>   .atomic_commit  = drm_atomic_helper_commit,
>  };
>  
> +static const struct drm_mode_config_helper_funcs mxsfb_mode_config_helpers = 
> {
> + .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
> +};
> +
>  static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
> struct drm_crtc_state *crtc_state,
> struct drm_plane_state *plane_state)
>  {
>   struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
> @@ -113,15 +117,25 @@ static void mxsfb_pipe_enable(struct
> drm_simple_display_pipe *pipe,
>  
>  static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
>  {

Shouldn't that be in mxsfb_pipe_update?

--
Stefan

>   struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
>   struct drm_device *drm = pipe->plane.dev;
> + struct drm_crtc *crtc = >crtc;
> + struct drm_pending_vblank_event *event;
>  
>   drm_panel_disable(mxsfb->panel);
>   mxsfb_crtc_disable(mxsfb);
>   drm_panel_unprepare(mxsfb->panel);
>   pm_runtime_put_sync(drm->dev);
> +
> + spin_lock_irq(>event_lock);
> + event = crtc->state->event;
> + if (event) {
> + crtc->state->event = NULL;
> + drm_crtc_send_vblank_event(crtc, event);
> + }
> + spin_unlock_irq(>event_lock);
>  }
>  
>  static void mxsfb_pipe_update(struct drm_simple_display_pipe *pipe,
> struct drm_plane_state *plane_state)
>  {
> @@ -232,10 +246,11 @@ static int mxsfb_load(struct drm_device *drm,
> unsigned long flags)
>   drm->mode_config.min_width  = MXSFB_MIN_XRES;
>   drm->mode_config.min_height = MXSFB_MIN_YRES;
>   drm->mode_config.max_width  = MXSFB_MAX_XRES;
>   drm->mode_config.max_height = MXSFB_MAX_YRES;
>   drm->mode_config.funcs  = _mode_config_funcs;
> + drm->mode_config.helper_private = _mode_config_helpers;
>  
>   drm_mode_config_reset(drm);
>  
>   pm_runtime_get_sync(drm->dev);
>   ret = drm_irq_install(drm, platform_get_irq(pdev, 0));
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5] drm/amdgpu: Transfer fences to dmabuf importer

[Christian König]

Am 07.08.2018 um 20:32 schrieb Chris Wilson:

amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As such, on exporting a dmabuf, we must either flush all
outstanding fences (for we do not know which are writes and should have
been exclusive) or alternatively create a new exclusive fence that is
the composite of all the existing shared fences, and so will only be
signaled when all earlier fences are signaled (ensuring that we can not
be signaled before the completion of any earlier write).

v2: reservation_object is already locked by amdgpu_bo_reserve()
v3: Replace looping with get_fences_rcu and special case the promotion
of a single shared fence directly to an exclusive fence, bypassing the
fence array.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341
Testcase: igt/amd_prime/amd-to-i915
References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to prime exported 
bo's. (v5)")
Signed-off-by: Chris Wilson 
Cc: Alex Deucher 
Cc: "Christian König" 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 58 +++
  1 file changed, 50 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 3fdd5688da0b..06a310b5b07b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -37,6 +37,7 @@
  #include "amdgpu_display.h"
  #include 
  #include 
+#include 
  
  static const struct dma_buf_ops amdgpu_dmabuf_ops;
  
@@ -188,6 +189,47 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,

return ERR_PTR(ret);
  }
  
+static int

+__reservation_object_make_exclusive(struct reservation_object *obj)
+{
+   struct dma_fence **fences;
+   unsigned int count;
+   int r;
+
+   if (!reservation_object_get_list(obj)) /* no shared fences to convert */
+   return 0;
+
+   r = reservation_object_get_fences_rcu(obj, NULL, , );
+   if (r)
+   return r;
+
+   if (count == 0) {
+   /* Now that was unexpected. */
+   } else if (count == 1) {
+   reservation_object_add_excl_fence(obj, fences[0]);
+   dma_fence_put(fences[0]);
+   kfree(fences);
+   } else {
+   struct dma_fence_array *array;
+
+   array = dma_fence_array_create(count, fences,
+  dma_fence_context_alloc(1), 0,
+  false);
+   if (!array)
+   goto err_fences_put;
+
+   reservation_object_add_excl_fence(obj, >base);
+   }
+
+   return 0;
+
+err_fences_put:
+   while (count--)
+   dma_fence_put(fences[count]);
+   kfree(fences);
+   return -ENOMEM;
+}
+
  /**
   * amdgpu_gem_map_attach - _buf_ops.attach implementation
   * @dma_buf: shared DMA buffer
@@ -219,16 +261,16 @@ static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
  
  	if (attach->dev->driver != adev->dev->driver) {

/*
-* Wait for all shared fences to complete before we switch to 
future
-* use of exclusive fence on this prime shared bo.
+* We only create shared fences for internal use, but importers
+* of the dmabuf rely on exclusive fences for implicitly
+* tracking write hazards. As any of the current fences may
+* correspond to a write, we need to convert all existing
+* fences on the reservation object into a single exclusive
+* fence.
 */
-   r = reservation_object_wait_timeout_rcu(bo->tbo.resv,
-   true, false,
-   MAX_SCHEDULE_TIMEOUT);
-   if (unlikely(r < 0)) {
-   DRM_DEBUG_PRIME("Fence wait failed: %li\n", r);
+   r = __reservation_object_make_exclusive(bo->tbo.resv);
+   if (r)
goto error_unreserve;
-   }
}
  
  	/* pin buffer into GTT */


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/4] drm/mxsfb: Add PM_SLEEP support

[Stefan Agner]

On 06.08.2018 21:31, Leonard Crestez wrote:
> Since power to the lcdif block can be lost on suspend implement
> PM_SLEEP_OPS using drm_mode_config_helper_suspend/resume to save/restore
> the current mode.
> 
> Signed-off-by: Leonard Crestez 

Reviewed-by: Stefan Agner 

> ---
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index 68d79f5dc0d3..d797dfd40d98 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -416,17 +416,38 @@ static int mxsfb_remove(struct platform_device *pdev)
>   drm_dev_unref(drm);
>  
>   return 0;
>  }
>  
> +#ifdef CONFIG_PM_SLEEP
> +static int mxsfb_suspend(struct device *dev)
> +{
> +   struct drm_device *drm = dev_get_drvdata(dev);
> +
> +   return drm_mode_config_helper_suspend(drm);
> +}
> +
> +static int mxsfb_resume(struct device *dev)
> +{
> +   struct drm_device *drm = dev_get_drvdata(dev);
> +
> +   return drm_mode_config_helper_resume(drm);
> +}
> +#endif
> +
> +static const struct dev_pm_ops mxsfb_pm_ops = {
> +   SET_SYSTEM_SLEEP_PM_OPS(mxsfb_suspend, mxsfb_resume)
> +};
> +
>  static struct platform_driver mxsfb_platform_driver = {
>   .probe  = mxsfb_probe,
>   .remove = mxsfb_remove,
>   .id_table   = mxsfb_devtype,
>   .driver = {
>   .name   = "mxsfb",
>   .of_match_table = mxsfb_dt_ids,
> + .pm = _pm_ops,
>   },
>  };
>  
>  module_platform_driver(mxsfb_platform_driver);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dma-buf: Remove requirement for ops->map() from dma_buf_export

[Chris Wilson]

Since commit 9ea0dfbf972 ("dma-buf: make map_atomic and map function
pointers optional"), the core provides the no-op functions when map and
map_atomic are not provided, so we no longer need assert that are
supplied by a dma-buf exporter.

Fixes: 09ea0dfbf972 ("dma-buf: make map_atomic and map function pointers 
optional")
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Gerd Hoffmann 
Cc: Sumit Semwal 
---
 drivers/dma-buf/dma-buf.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 13884474d158..02f7f9a89979 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -405,7 +405,6 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
  || !exp_info->ops->map_dma_buf
  || !exp_info->ops->unmap_dma_buf
  || !exp_info->ops->release
- || !exp_info->ops->map
  || !exp_info->ops->mmap)) {
return ERR_PTR(-EINVAL);
}
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/4] drm/mxsfb: Add pm_runtime calls to pipe_enable/disable

[Stefan Agner]

On 06.08.2018 21:31, Leonard Crestez wrote:
> Adding lcdif nodes to a power domain currently results in
> black/corrupted screens or hangs because power is not correctly enabled
> when required.
> 
> Ensure power is on when display is active by adding
> pm_runtime_get/put_sync to mxsfb_pipe_enable/disable.
> 
> Signed-off-by: Leonard Crestez 

Reviewed-by: Stefan Agner 

> ---
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index ffe5137ccaf8..68d79f5dc0d3 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -101,23 +101,27 @@ static const struct drm_mode_config_funcs
> mxsfb_mode_config_funcs = {
>  static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
> struct drm_crtc_state *crtc_state,
> struct drm_plane_state *plane_state)
>  {
>   struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
> + struct drm_device *drm = pipe->plane.dev;
>  
> + pm_runtime_get_sync(drm->dev);
>   drm_panel_prepare(mxsfb->panel);
>   mxsfb_crtc_enable(mxsfb);
>   drm_panel_enable(mxsfb->panel);
>  }
>  
>  static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
>  {
>   struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
> + struct drm_device *drm = pipe->plane.dev;
>  
>   drm_panel_disable(mxsfb->panel);
>   mxsfb_crtc_disable(mxsfb);
>   drm_panel_unprepare(mxsfb->panel);
> + pm_runtime_put_sync(drm->dev);
>  }
>  
>  static void mxsfb_pipe_update(struct drm_simple_display_pipe *pipe,
> struct drm_plane_state *plane_state)
>  {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5] drm/amdgpu: Transfer fences to dmabuf importer

[Chris Wilson]

amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As such, on exporting a dmabuf, we must either flush all
outstanding fences (for we do not know which are writes and should have
been exclusive) or alternatively create a new exclusive fence that is
the composite of all the existing shared fences, and so will only be
signaled when all earlier fences are signaled (ensuring that we can not
be signaled before the completion of any earlier write).

v2: reservation_object is already locked by amdgpu_bo_reserve()
v3: Replace looping with get_fences_rcu and special case the promotion
of a single shared fence directly to an exclusive fence, bypassing the
fence array.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341
Testcase: igt/amd_prime/amd-to-i915
References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to prime exported 
bo's. (v5)")
Signed-off-by: Chris Wilson 
Cc: Alex Deucher 
Cc: "Christian König" 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 58 +++
 1 file changed, 50 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 3fdd5688da0b..06a310b5b07b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -37,6 +37,7 @@
 #include "amdgpu_display.h"
 #include 
 #include 
+#include 
 
 static const struct dma_buf_ops amdgpu_dmabuf_ops;
 
@@ -188,6 +189,47 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
return ERR_PTR(ret);
 }
 
+static int
+__reservation_object_make_exclusive(struct reservation_object *obj)
+{
+   struct dma_fence **fences;
+   unsigned int count;
+   int r;
+
+   if (!reservation_object_get_list(obj)) /* no shared fences to convert */
+   return 0;
+
+   r = reservation_object_get_fences_rcu(obj, NULL, , );
+   if (r)
+   return r;
+
+   if (count == 0) {
+   /* Now that was unexpected. */
+   } else if (count == 1) {
+   reservation_object_add_excl_fence(obj, fences[0]);
+   dma_fence_put(fences[0]);
+   kfree(fences);
+   } else {
+   struct dma_fence_array *array;
+
+   array = dma_fence_array_create(count, fences,
+  dma_fence_context_alloc(1), 0,
+  false);
+   if (!array)
+   goto err_fences_put;
+
+   reservation_object_add_excl_fence(obj, >base);
+   }
+
+   return 0;
+
+err_fences_put:
+   while (count--)
+   dma_fence_put(fences[count]);
+   kfree(fences);
+   return -ENOMEM;
+}
+
 /**
  * amdgpu_gem_map_attach - _buf_ops.attach implementation
  * @dma_buf: shared DMA buffer
@@ -219,16 +261,16 @@ static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
 
if (attach->dev->driver != adev->dev->driver) {
/*
-* Wait for all shared fences to complete before we switch to 
future
-* use of exclusive fence on this prime shared bo.
+* We only create shared fences for internal use, but importers
+* of the dmabuf rely on exclusive fences for implicitly
+* tracking write hazards. As any of the current fences may
+* correspond to a write, we need to convert all existing
+* fences on the reservation object into a single exclusive
+* fence.
 */
-   r = reservation_object_wait_timeout_rcu(bo->tbo.resv,
-   true, false,
-   MAX_SCHEDULE_TIMEOUT);
-   if (unlikely(r < 0)) {
-   DRM_DEBUG_PRIME("Fence wait failed: %li\n", r);
+   r = __reservation_object_make_exclusive(bo->tbo.resv);
+   if (r)
goto error_unreserve;
-   }
}
 
/* pin buffer into GTT */
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm/amdgpu: Transfer fences to dmabuf importer

[Chris Wilson]

Quoting Christian König (2018-08-07 19:18:55)
> Am 07.08.2018 um 20:14 schrieb Chris Wilson:
> > Quoting Christian König (2018-08-07 18:57:16)
> >> Am 07.08.2018 um 18:08 schrieb Chris Wilson:
> >>> amdgpu only uses shared-fences internally, but dmabuf importers rely on
> >>> implicit write hazard tracking via the reservation_object.fence_excl.
> >>> For example, the importer use the write hazard for timing a page flip to
> >>> only occur after the exporter has finished flushing its write into the
> >>> surface. As such, on exporting a dmabuf, we must either flush all
> >>> outstanding fences (for we do not know which are writes and should have
> >>> been exclusive) or alternatively create a new exclusive fence that is
> >>> the composite of all the existing shared fences, and so will only be
> >>> signaled when all earlier fences are signaled (ensuring that we can not
> >>> be signaled before the completion of any earlier write).
> >>>
> >>> v2: reservation_object is already locked by amdgpu_bo_reserve()
> >>>
> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341
> >>> Testcase: igt/amd_prime/amd-to-i915
> >>> References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to prime 
> >>> exported bo's. (v5)")
> >>> Signed-off-by: Chris Wilson 
> >>> Cc: Alex Deucher 
> >>> Cc: "Christian König" 
> >>> ---
> >>>
> >>> This time, hopefully proofread and references complete.
> >>> -Chris
> >>>
> >>> ---
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 68 ---
> >>>1 file changed, 60 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> >>> index 1c5d97f4b4dd..dff2b01a3d89 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> >>> @@ -37,6 +37,7 @@
> >>>#include "amdgpu_display.h"
> >>>#include 
> >>>#include 
> >>> +#include 
> >>>
> >>>static const struct dma_buf_ops amdgpu_dmabuf_ops;
> >>>
> >>> @@ -188,6 +189,57 @@ amdgpu_gem_prime_import_sg_table(struct drm_device 
> >>> *dev,
> >>>return ERR_PTR(ret);
> >>>}
> >>>
> >>> +static int
> >>> +__reservation_object_make_exclusive(struct reservation_object *obj)
> >>> +{
> >>> + struct reservation_object_list *fobj;
> >>> + struct dma_fence_array *array;
> >>> + struct dma_fence **fences;
> >>> + unsigned int count, i;
> >>> +
> >>> + fobj = reservation_object_get_list(obj);
> >>> + if (!fobj)
> >>> + return 0;
> >>> +
> >>> + count = !!rcu_access_pointer(obj->fence_excl);
> >>> + count += fobj->shared_count;
> >>> +
> >>> + fences = kmalloc_array(count, sizeof(*fences), GFP_KERNEL);
> >>> + if (!fences)
> >>> + return -ENOMEM;
> >>> +
> >>> + for (i = 0; i < fobj->shared_count; i++) {
> >>> + struct dma_fence *f =
> >>> + rcu_dereference_protected(fobj->shared[i],
> >>> +   
> >>> reservation_object_held(obj));
> >>> +
> >>> + fences[i] = dma_fence_get(f);
> >>> + }
> >>> +
> >>> + if (rcu_access_pointer(obj->fence_excl)) {
> >>> + struct dma_fence *f =
> >>> + rcu_dereference_protected(obj->fence_excl,
> >>> +   
> >>> reservation_object_held(obj));
> >>> +
> >>> + fences[i] = dma_fence_get(f);
> >>> + }
> >>> +
> >>> + array = dma_fence_array_create(count, fences,
> >>> +dma_fence_context_alloc(1), 0,
> >>> +false);
> >>> + if (!array)
> >>> + goto err_fences_put;
> >>> +
> >>> + reservation_object_add_excl_fence(obj, >base);
> >>> + return 0;
> >>> +
> >>> +err_fences_put:
> >>> + for (i = 0; i < count; i++)
> >>> + dma_fence_put(fences[i]);
> >>> + kfree(fences);
> >>> + return -ENOMEM;
> >>> +}
> >>> +
> >> This can be simplified a lot. See amdgpu_pasid_free_delayed() for an
> >> example:
> > {
> >   if (!reservation_object_get_list(obj))
> >   return 0;
> >
> >   r = reservation_object_get_fences_rcu(obj, NULL, , );
> >   if (r)
> >   return r;
> >
> >   array = dma_fence_array_create(count, fences,
> >  dma_fence_context_alloc(1), 0,
> >  false);
> >   if (!array)
> >   goto err_fences_put;
> >
> >   reservation_object_add_excl_fence(obj, >base);
> >   return 0;
> >
> > err:
> >   ...
> > }
> >
> > My starting point was going to be use get_fences_rcu, but get_fences_rcu
> > can hardly be called simple for where the lock is required to be held
> > start to finish ;)
> 
> What are you talking about? get_fences_rcu doesn't require any locking 
> at all.
> 
> You only need to the locking to make sure that 

Re: [PATCH v3 1/4] drm/mxsfb: Fix initial corrupt frame when activating display

[Stefan Agner]

On 06.08.2018 21:31, Leonard Crestez wrote:
> LCDIF will repeatedly display data from CUR_BUF and set CUR_BUF to
> NEXT_BUF when done. Since we are only ever writing to NEXT_BUF the
> display will show an initial corrupt frame.
> 
> Fix by writing the FB paddr to both CUR_BUF and NEXT_BUF when
> activating the CRTC.

Really like how this patch set evolves! Only some minor thing below...

> 
> Signed-off-by: Leonard Crestez 
> ---
>  drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 42 +-
>  1 file changed, 29 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> index 0abe77675b76..db3ff5bde122 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> @@ -194,15 +194,31 @@ static int mxsfb_reset_block(void __iomem *reset_addr)
>   return ret;
>  
>   return clear_poll_bit(reset_addr, MODULE_CLKGATE);
>  }
>  
> +static dma_addr_t mxsfb_get_fb_paddr(struct mxsfb_drm_private *mxsfb)
> +{
> + struct drm_framebuffer *fb = mxsfb->pipe.plane.state->fb;
> + struct drm_gem_cma_object *gem;
> +
> + if (!fb)
> + return 0;
> +
> + gem = drm_fb_cma_get_gem_obj(fb, 0);
> + if (!gem)
> + return 0;
> +
> + return gem->paddr;
> +}
> +
>  static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
>  {
>   struct drm_display_mode *m = >pipe.crtc.state->adjusted_mode;
>   const u32 bus_flags = mxsfb->connector.display_info.bus_flags;
>   u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
> + dma_addr_t paddr;
>   int err;
>  
>   /*
>* It seems, you can't re-program the controller if it is still
>* running. This may lead to shifted pictures (FIFO issue?), so
> @@ -268,10 +284,16 @@ static void mxsfb_crtc_mode_set_nofb(struct
> mxsfb_drm_private *mxsfb)
>  mxsfb->base + LCDC_VDCTRL3);
>  
>   writel(SET_DOTCLK_H_VALID_DATA_CNT(m->hdisplay),
>  mxsfb->base + LCDC_VDCTRL4);
>  
> + /* Update cur_buf as well to avoid an initial corrupt frame */
> + paddr = mxsfb_get_fb_paddr(mxsfb);
> + if (paddr) {
> + writel(paddr, mxsfb->base + mxsfb->devdata->cur_buf);
> + writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
> + }

Traditionally mxsfb_crtc_mode_set_nofb() was used as a callback to
mode_set_nofb. And that callback should not fiddle with the fb (as the
name says).

So I rather prefer to move the new bits to mxsfb_crtc_enable(), between
mxsfb_crtc_mode_set_nofb() and mxsfb_enable_controller(). It is only
cosmetics, but I'd rather prefer to have it in the right place.

Currently the AXI clock is disabled between those functions... I suggest
to enable the AXI clock once in mxsfb_crtc_enable(). This puts an end to
the unnecessary enable/disable/enable sequence in mxsfb_crtc_enable().

So I suggest to create a patch "drm/mxsfb: simplify AXI clock handling"

--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -129,7 +129,6 @@ static void mxsfb_enable_controller(struct
mxsfb_drm_private *mxsfb)
if (mxsfb->clk_disp_axi)
clk_prepare_enable(mxsfb->clk_disp_axi);
clk_prepare_enable(mxsfb->clk);
-   mxsfb_enable_axi_clk(mxsfb);
 
/* If it was disabled, re-enable the mode again */
writel(CTRL_DOTCLK_MODE, mxsfb->base + LCDC_CTRL + REG_SET);
@@ -159,8 +158,6 @@ static void mxsfb_disable_controller(struct
mxsfb_drm_private *mxsfb)
reg &= ~VDCTRL4_SYNC_SIGNALS_ON;
writel(reg, mxsfb->base + LCDC_VDCTRL4);
 
-   mxsfb_disable_axi_clk(mxsfb);
-
clk_disable_unprepare(mxsfb->clk);
if (mxsfb->clk_disp_axi)
clk_disable_unprepare(mxsfb->clk_disp_axi);
@@ -208,7 +205,6 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
 * running. This may lead to shifted pictures (FIFO issue?), so
 * first stop the controller and drain its FIFOs.
 */
-   mxsfb_enable_axi_clk(mxsfb);
 
/* Mandatory eLCDIF reset as per the Reference Manual */
err = mxsfb_reset_block(mxsfb->base);
@@ -269,12 +265,11 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
 
writel(SET_DOTCLK_H_VALID_DATA_CNT(m->hdisplay),
   mxsfb->base + LCDC_VDCTRL4);
-
-   mxsfb_disable_axi_clk(mxsfb);
 }
 
 void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
 {
+   mxsfb_enable_axi_clk(mxsfb);
mxsfb_crtc_mode_set_nofb(mxsfb);
mxsfb_enable_controller(mxsfb);
 }
@@ -282,6 +277,7 @@ void mxsfb_crtc_enable(struct mxsfb_drm_private
*mxsfb)
 void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
 {
mxsfb_disable_controller(mxsfb);
+   mxsfb_disable_axi_clk(mxsfb);
 }
 

Then move the above section between mxsfb_crtc_mode_set_nofb() and
mxsfb_enable_controller().

--
Stefan

>   mxsfb_disable_axi_clk(mxsfb);
>  }
>  
>  void 

Re: [PATCH v4] drm/amdgpu: Transfer fences to dmabuf importer

[Christian König]

Am 07.08.2018 um 20:14 schrieb Chris Wilson:

Quoting Christian König (2018-08-07 18:57:16)

Am 07.08.2018 um 18:08 schrieb Chris Wilson:

amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As such, on exporting a dmabuf, we must either flush all
outstanding fences (for we do not know which are writes and should have
been exclusive) or alternatively create a new exclusive fence that is
the composite of all the existing shared fences, and so will only be
signaled when all earlier fences are signaled (ensuring that we can not
be signaled before the completion of any earlier write).

v2: reservation_object is already locked by amdgpu_bo_reserve()

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341
Testcase: igt/amd_prime/amd-to-i915
References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to prime exported 
bo's. (v5)")
Signed-off-by: Chris Wilson 
Cc: Alex Deucher 
Cc: "Christian König" 
---

This time, hopefully proofread and references complete.
-Chris

---
   drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 68 ---
   1 file changed, 60 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 1c5d97f4b4dd..dff2b01a3d89 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -37,6 +37,7 @@
   #include "amdgpu_display.h"
   #include 
   #include 
+#include 
   
   static const struct dma_buf_ops amdgpu_dmabuf_ops;
   
@@ -188,6 +189,57 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,

   return ERR_PTR(ret);
   }
   
+static int

+__reservation_object_make_exclusive(struct reservation_object *obj)
+{
+ struct reservation_object_list *fobj;
+ struct dma_fence_array *array;
+ struct dma_fence **fences;
+ unsigned int count, i;
+
+ fobj = reservation_object_get_list(obj);
+ if (!fobj)
+ return 0;
+
+ count = !!rcu_access_pointer(obj->fence_excl);
+ count += fobj->shared_count;
+
+ fences = kmalloc_array(count, sizeof(*fences), GFP_KERNEL);
+ if (!fences)
+ return -ENOMEM;
+
+ for (i = 0; i < fobj->shared_count; i++) {
+ struct dma_fence *f =
+ rcu_dereference_protected(fobj->shared[i],
+   reservation_object_held(obj));
+
+ fences[i] = dma_fence_get(f);
+ }
+
+ if (rcu_access_pointer(obj->fence_excl)) {
+ struct dma_fence *f =
+ rcu_dereference_protected(obj->fence_excl,
+   reservation_object_held(obj));
+
+ fences[i] = dma_fence_get(f);
+ }
+
+ array = dma_fence_array_create(count, fences,
+dma_fence_context_alloc(1), 0,
+false);
+ if (!array)
+ goto err_fences_put;
+
+ reservation_object_add_excl_fence(obj, >base);
+ return 0;
+
+err_fences_put:
+ for (i = 0; i < count; i++)
+ dma_fence_put(fences[i]);
+ kfree(fences);
+ return -ENOMEM;
+}
+

This can be simplified a lot. See amdgpu_pasid_free_delayed() for an
example:

{
if (!reservation_object_get_list(obj))
return 0;

r = reservation_object_get_fences_rcu(obj, NULL, , );
if (r)
return r;

array = dma_fence_array_create(count, fences,
   dma_fence_context_alloc(1), 0,
   false);
if (!array)
goto err_fences_put;

reservation_object_add_excl_fence(obj, >base);
return 0;

err:
...
}

My starting point was going to be use get_fences_rcu, but get_fences_rcu
can hardly be called simple for where the lock is required to be held
start to finish ;)


What are you talking about? get_fences_rcu doesn't require any locking 
at all.


You only need to the locking to make sure that between creating the 
fence array and calling reservation_object_add_excl_fence() no other 
fence is added.


Christian.


-Chris
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm/amdgpu: Transfer fences to dmabuf importer

[Chris Wilson]

Quoting Christian König (2018-08-07 18:57:16)
> Am 07.08.2018 um 18:08 schrieb Chris Wilson:
> > amdgpu only uses shared-fences internally, but dmabuf importers rely on
> > implicit write hazard tracking via the reservation_object.fence_excl.
> > For example, the importer use the write hazard for timing a page flip to
> > only occur after the exporter has finished flushing its write into the
> > surface. As such, on exporting a dmabuf, we must either flush all
> > outstanding fences (for we do not know which are writes and should have
> > been exclusive) or alternatively create a new exclusive fence that is
> > the composite of all the existing shared fences, and so will only be
> > signaled when all earlier fences are signaled (ensuring that we can not
> > be signaled before the completion of any earlier write).
> >
> > v2: reservation_object is already locked by amdgpu_bo_reserve()
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341
> > Testcase: igt/amd_prime/amd-to-i915
> > References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to prime 
> > exported bo's. (v5)")
> > Signed-off-by: Chris Wilson 
> > Cc: Alex Deucher 
> > Cc: "Christian König" 
> > ---
> >
> > This time, hopefully proofread and references complete.
> > -Chris
> >
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 68 ---
> >   1 file changed, 60 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> > index 1c5d97f4b4dd..dff2b01a3d89 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> > @@ -37,6 +37,7 @@
> >   #include "amdgpu_display.h"
> >   #include 
> >   #include 
> > +#include 
> >   
> >   static const struct dma_buf_ops amdgpu_dmabuf_ops;
> >   
> > @@ -188,6 +189,57 @@ amdgpu_gem_prime_import_sg_table(struct drm_device 
> > *dev,
> >   return ERR_PTR(ret);
> >   }
> >   
> > +static int
> > +__reservation_object_make_exclusive(struct reservation_object *obj)
> > +{
> > + struct reservation_object_list *fobj;
> > + struct dma_fence_array *array;
> > + struct dma_fence **fences;
> > + unsigned int count, i;
> > +
> > + fobj = reservation_object_get_list(obj);
> > + if (!fobj)
> > + return 0;
> > +
> > + count = !!rcu_access_pointer(obj->fence_excl);
> > + count += fobj->shared_count;
> > +
> > + fences = kmalloc_array(count, sizeof(*fences), GFP_KERNEL);
> > + if (!fences)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < fobj->shared_count; i++) {
> > + struct dma_fence *f =
> > + rcu_dereference_protected(fobj->shared[i],
> > +   
> > reservation_object_held(obj));
> > +
> > + fences[i] = dma_fence_get(f);
> > + }
> > +
> > + if (rcu_access_pointer(obj->fence_excl)) {
> > + struct dma_fence *f =
> > + rcu_dereference_protected(obj->fence_excl,
> > +   
> > reservation_object_held(obj));
> > +
> > + fences[i] = dma_fence_get(f);
> > + }
> > +
> > + array = dma_fence_array_create(count, fences,
> > +dma_fence_context_alloc(1), 0,
> > +false);
> > + if (!array)
> > + goto err_fences_put;
> > +
> > + reservation_object_add_excl_fence(obj, >base);
> > + return 0;
> > +
> > +err_fences_put:
> > + for (i = 0; i < count; i++)
> > + dma_fence_put(fences[i]);
> > + kfree(fences);
> > + return -ENOMEM;
> > +}
> > +
> 
> This can be simplified a lot. See amdgpu_pasid_free_delayed() for an 
> example:

{
if (!reservation_object_get_list(obj))
return 0;

r = reservation_object_get_fences_rcu(obj, NULL, , );
if (r)
return r;

array = dma_fence_array_create(count, fences,
   dma_fence_context_alloc(1), 0,
   false);
if (!array)
goto err_fences_put;

reservation_object_add_excl_fence(obj, >base);
return 0;

err:
...
}

My starting point was going to be use get_fences_rcu, but get_fences_rcu
can hardly be called simple for where the lock is required to be held
start to finish ;)
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm/amdgpu: Transfer fences to dmabuf importer

[Christian König]

Am 07.08.2018 um 18:08 schrieb Chris Wilson:

amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As such, on exporting a dmabuf, we must either flush all
outstanding fences (for we do not know which are writes and should have
been exclusive) or alternatively create a new exclusive fence that is
the composite of all the existing shared fences, and so will only be
signaled when all earlier fences are signaled (ensuring that we can not
be signaled before the completion of any earlier write).

v2: reservation_object is already locked by amdgpu_bo_reserve()

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341
Testcase: igt/amd_prime/amd-to-i915
References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to prime exported 
bo's. (v5)")
Signed-off-by: Chris Wilson 
Cc: Alex Deucher 
Cc: "Christian König" 
---

This time, hopefully proofread and references complete.
-Chris

---
  drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 68 ---
  1 file changed, 60 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 1c5d97f4b4dd..dff2b01a3d89 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -37,6 +37,7 @@
  #include "amdgpu_display.h"
  #include 
  #include 
+#include 
  
  static const struct dma_buf_ops amdgpu_dmabuf_ops;
  
@@ -188,6 +189,57 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,

return ERR_PTR(ret);
  }
  
+static int

+__reservation_object_make_exclusive(struct reservation_object *obj)
+{
+   struct reservation_object_list *fobj;
+   struct dma_fence_array *array;
+   struct dma_fence **fences;
+   unsigned int count, i;
+
+   fobj = reservation_object_get_list(obj);
+   if (!fobj)
+   return 0;
+
+   count = !!rcu_access_pointer(obj->fence_excl);
+   count += fobj->shared_count;
+
+   fences = kmalloc_array(count, sizeof(*fences), GFP_KERNEL);
+   if (!fences)
+   return -ENOMEM;
+
+   for (i = 0; i < fobj->shared_count; i++) {
+   struct dma_fence *f =
+   rcu_dereference_protected(fobj->shared[i],
+ reservation_object_held(obj));
+
+   fences[i] = dma_fence_get(f);
+   }
+
+   if (rcu_access_pointer(obj->fence_excl)) {
+   struct dma_fence *f =
+   rcu_dereference_protected(obj->fence_excl,
+ reservation_object_held(obj));
+
+   fences[i] = dma_fence_get(f);
+   }
+
+   array = dma_fence_array_create(count, fences,
+  dma_fence_context_alloc(1), 0,
+  false);
+   if (!array)
+   goto err_fences_put;
+
+   reservation_object_add_excl_fence(obj, >base);
+   return 0;
+
+err_fences_put:
+   for (i = 0; i < count; i++)
+   dma_fence_put(fences[i]);
+   kfree(fences);
+   return -ENOMEM;
+}
+


This can be simplified a lot. See amdgpu_pasid_free_delayed() for an 
example:
    r = reservation_object_get_fences_rcu(resv, NULL, , 
);

    if (r)
    goto fallback;

    if (count == 0) {
    amdgpu_pasid_free(pasid);
    return;
    }

    if (count == 1) {
    fence = fences[0];
    kfree(fences);
    } else {
    uint64_t context = dma_fence_context_alloc(1);
    struct dma_fence_array *array;

    array = dma_fence_array_create(count, fences, context,
   1, false);
    if (!array) {
    kfree(fences);
    goto fallback;
    }
    fence = >base;
    }



Regards,
Christian.


  /**
   * amdgpu_gem_map_attach - _buf_ops.attach implementation
   * @dma_buf: shared DMA buffer
@@ -219,16 +271,16 @@ static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
  
  	if (attach->dev->driver != adev->dev->driver) {

/*
-* Wait for all shared fences to complete before we switch to 
future
-* use of exclusive fence on this prime shared bo.
+* We only create shared fences for internal use, but importers
+* of the dmabuf rely on exclusive fences for implicitly
+* tracking write hazards. As any of the current fences may
+* correspond to a write, we need to convert all existing
+* fences on the reservation object into a single exclusive
+* 

Re: [PATCH] drm: Remove defunct dma_buf_kmap stubs

[Christian König]

Am 07.08.2018 um 19:47 schrieb Chris Wilson:

Since commit 09ea0dfbf972 ("dma-buf: make map_atomic and map function
pointers optional"), we no longer need to provide stub no-op functions
as the core now provides them directly.

References: 09ea0dfbf972 ("dma-buf: make map_atomic and map function pointers 
optional")
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Gerd Hoffmann 
Cc: Alex Deucher 
Cc: "Christian König" 


Reviewed-by: Christian König 



---
  drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c |  2 --
  drivers/gpu/drm/drm_prime.c   | 30 ---
  include/drm/drm_prime.h   |  3 ---
  3 files changed, 35 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 1c5d97f4b4dd..3fdd5688da0b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -338,8 +338,6 @@ static const struct dma_buf_ops amdgpu_dmabuf_ops = {
.unmap_dma_buf = drm_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
.begin_cpu_access = amdgpu_gem_begin_cpu_access,
-   .map = drm_gem_dmabuf_kmap,
-   .unmap = drm_gem_dmabuf_kunmap,
.mmap = drm_gem_dmabuf_mmap,
.vmap = drm_gem_dmabuf_vmap,
.vunmap = drm_gem_dmabuf_vunmap,
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 186db2e4c57a..e03d3bdaa59b 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -433,34 +433,6 @@ void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void 
*vaddr)
  }
  EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
  
-/**

- * drm_gem_dmabuf_kmap - map implementation for GEM
- * @dma_buf: buffer to be mapped
- * @page_num: page number within the buffer
- *
- * Not implemented. This can be used as the _buf_ops.map callback.
- */
-void *drm_gem_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
-{
-   return NULL;
-}
-EXPORT_SYMBOL(drm_gem_dmabuf_kmap);
-
-/**
- * drm_gem_dmabuf_kunmap - unmap implementation for GEM
- * @dma_buf: buffer to be unmapped
- * @page_num: page number within the buffer
- * @addr: virtual address of the buffer
- *
- * Not implemented. This can be used as the _buf_ops.unmap callback.
- */
-void drm_gem_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num,
-  void *addr)
-{
-
-}
-EXPORT_SYMBOL(drm_gem_dmabuf_kunmap);
-
  /**
   * drm_gem_dmabuf_mmap - dma_buf mmap implementation for GEM
   * @dma_buf: buffer to be mapped
@@ -489,8 +461,6 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  
{
.map_dma_buf = drm_gem_map_dma_buf,
.unmap_dma_buf = drm_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
-   .map = drm_gem_dmabuf_kmap,
-   .unmap = drm_gem_dmabuf_kunmap,
.mmap = drm_gem_dmabuf_mmap,
.vmap = drm_gem_dmabuf_vmap,
.vunmap = drm_gem_dmabuf_vunmap,
diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index d716d653b096..e2032fbc0f08 100644
--- a/include/drm/drm_prime.h
+++ b/include/drm/drm_prime.h
@@ -93,9 +93,6 @@ void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
   enum dma_data_direction dir);
  void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf);
  void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr);
-void *drm_gem_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num);
-void drm_gem_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num,
-  void *addr);
  int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma);
  
  int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page **pages,


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Remove defunct dma_buf_kmap stubs

[Daniel Vetter]

On Tue, Aug 07, 2018 at 06:47:48PM +0100, Chris Wilson wrote:
> Since commit 09ea0dfbf972 ("dma-buf: make map_atomic and map function
> pointers optional"), we no longer need to provide stub no-op functions
> as the core now provides them directly.
> 
> References: 09ea0dfbf972 ("dma-buf: make map_atomic and map function pointers 
> optional")
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Gerd Hoffmann 
> Cc: Alex Deucher 
> Cc: "Christian König" 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c |  2 --
>  drivers/gpu/drm/drm_prime.c   | 30 ---
>  include/drm/drm_prime.h   |  3 ---
>  3 files changed, 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> index 1c5d97f4b4dd..3fdd5688da0b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> @@ -338,8 +338,6 @@ static const struct dma_buf_ops amdgpu_dmabuf_ops = {
>   .unmap_dma_buf = drm_gem_unmap_dma_buf,
>   .release = drm_gem_dmabuf_release,
>   .begin_cpu_access = amdgpu_gem_begin_cpu_access,
> - .map = drm_gem_dmabuf_kmap,
> - .unmap = drm_gem_dmabuf_kunmap,
>   .mmap = drm_gem_dmabuf_mmap,
>   .vmap = drm_gem_dmabuf_vmap,
>   .vunmap = drm_gem_dmabuf_vunmap,
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 186db2e4c57a..e03d3bdaa59b 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -433,34 +433,6 @@ void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void 
> *vaddr)
>  }
>  EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
>  
> -/**
> - * drm_gem_dmabuf_kmap - map implementation for GEM
> - * @dma_buf: buffer to be mapped
> - * @page_num: page number within the buffer
> - *
> - * Not implemented. This can be used as the _buf_ops.map callback.
> - */
> -void *drm_gem_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
> -{
> - return NULL;
> -}
> -EXPORT_SYMBOL(drm_gem_dmabuf_kmap);
> -
> -/**
> - * drm_gem_dmabuf_kunmap - unmap implementation for GEM
> - * @dma_buf: buffer to be unmapped
> - * @page_num: page number within the buffer
> - * @addr: virtual address of the buffer
> - *
> - * Not implemented. This can be used as the _buf_ops.unmap callback.
> - */
> -void drm_gem_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num,
> -void *addr)
> -{
> -
> -}
> -EXPORT_SYMBOL(drm_gem_dmabuf_kunmap);
> -
>  /**
>   * drm_gem_dmabuf_mmap - dma_buf mmap implementation for GEM
>   * @dma_buf: buffer to be mapped
> @@ -489,8 +461,6 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops 
> =  {
>   .map_dma_buf = drm_gem_map_dma_buf,
>   .unmap_dma_buf = drm_gem_unmap_dma_buf,
>   .release = drm_gem_dmabuf_release,
> - .map = drm_gem_dmabuf_kmap,
> - .unmap = drm_gem_dmabuf_kunmap,
>   .mmap = drm_gem_dmabuf_mmap,
>   .vmap = drm_gem_dmabuf_vmap,
>   .vunmap = drm_gem_dmabuf_vunmap,
> diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
> index d716d653b096..e2032fbc0f08 100644
> --- a/include/drm/drm_prime.h
> +++ b/include/drm/drm_prime.h
> @@ -93,9 +93,6 @@ void drm_gem_unmap_dma_buf(struct dma_buf_attachment 
> *attach,
>  enum dma_data_direction dir);
>  void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf);
>  void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr);
> -void *drm_gem_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num);
> -void drm_gem_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num,
> -void *addr);
>  int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma);
>  
>  int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page 
> **pages,
> -- 
> 2.18.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Remove defunct dma_buf_kmap stubs

[Chris Wilson]

Since commit 09ea0dfbf972 ("dma-buf: make map_atomic and map function
pointers optional"), we no longer need to provide stub no-op functions
as the core now provides them directly.

References: 09ea0dfbf972 ("dma-buf: make map_atomic and map function pointers 
optional")
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Gerd Hoffmann 
Cc: Alex Deucher 
Cc: "Christian König" 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c |  2 --
 drivers/gpu/drm/drm_prime.c   | 30 ---
 include/drm/drm_prime.h   |  3 ---
 3 files changed, 35 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 1c5d97f4b4dd..3fdd5688da0b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -338,8 +338,6 @@ static const struct dma_buf_ops amdgpu_dmabuf_ops = {
.unmap_dma_buf = drm_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
.begin_cpu_access = amdgpu_gem_begin_cpu_access,
-   .map = drm_gem_dmabuf_kmap,
-   .unmap = drm_gem_dmabuf_kunmap,
.mmap = drm_gem_dmabuf_mmap,
.vmap = drm_gem_dmabuf_vmap,
.vunmap = drm_gem_dmabuf_vunmap,
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 186db2e4c57a..e03d3bdaa59b 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -433,34 +433,6 @@ void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void 
*vaddr)
 }
 EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
 
-/**
- * drm_gem_dmabuf_kmap - map implementation for GEM
- * @dma_buf: buffer to be mapped
- * @page_num: page number within the buffer
- *
- * Not implemented. This can be used as the _buf_ops.map callback.
- */
-void *drm_gem_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
-{
-   return NULL;
-}
-EXPORT_SYMBOL(drm_gem_dmabuf_kmap);
-
-/**
- * drm_gem_dmabuf_kunmap - unmap implementation for GEM
- * @dma_buf: buffer to be unmapped
- * @page_num: page number within the buffer
- * @addr: virtual address of the buffer
- *
- * Not implemented. This can be used as the _buf_ops.unmap callback.
- */
-void drm_gem_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num,
-  void *addr)
-{
-
-}
-EXPORT_SYMBOL(drm_gem_dmabuf_kunmap);
-
 /**
  * drm_gem_dmabuf_mmap - dma_buf mmap implementation for GEM
  * @dma_buf: buffer to be mapped
@@ -489,8 +461,6 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  
{
.map_dma_buf = drm_gem_map_dma_buf,
.unmap_dma_buf = drm_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
-   .map = drm_gem_dmabuf_kmap,
-   .unmap = drm_gem_dmabuf_kunmap,
.mmap = drm_gem_dmabuf_mmap,
.vmap = drm_gem_dmabuf_vmap,
.vunmap = drm_gem_dmabuf_vunmap,
diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index d716d653b096..e2032fbc0f08 100644
--- a/include/drm/drm_prime.h
+++ b/include/drm/drm_prime.h
@@ -93,9 +93,6 @@ void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
   enum dma_data_direction dir);
 void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf);
 void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr);
-void *drm_gem_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num);
-void drm_gem_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num,
-  void *addr);
 int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma);
 
 int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page **pages,
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 5/5] tinydrm: add winstar wg160160 driver

[Noralf Trønnes]

Den 02.08.2018 21.45, skrev Sam Ravnborg:

Add driver for the winstar wg160160 display.
The driver utilises pardata-dbi that
again utilise the pardata subsystem.

Signed-off-by: Sam Ravnborg 
---
  MAINTAINERS|   5 +
  drivers/gpu/drm/tinydrm/Kconfig|  10 ++
  drivers/gpu/drm/tinydrm/Makefile   |   1 +
  drivers/gpu/drm/tinydrm/wg160160.c | 298 +
  4 files changed, 314 insertions(+)
  create mode 100644 drivers/gpu/drm/tinydrm/wg160160.c



[...]


+
+/**
+ * write_reg - Write instruction on parallel bus to controller
+ *
+ * Check BUSY flag and write instruction
+ *
+ * @pdd: pardata data
+ * @reg: The register to write
+ * @value: The value of the register
+ *
+ * Returns:
+ * Zero on success, negative error code on failure
+ */
+int write_reg(struct pardata_data *pdd, unsigned int reg, unsigned int value)
+{
+   int ins[PIN_NUM];
+   int val[PIN_NUM];
+   int i;
+
+   for (i = 0; i < PIN_NUM; i++)
+   ins[PIN_DB0 + i] = !!BIT(reg);
+
+   for (i = 0; i < PIN_NUM; i++)
+   val[PIN_DB0 + i] = !!(value & BIT(i));
+
+   gpiod_set_value_cansleep(pdd->bus->pin_rs, 1);
+   gpiod_set_array_value_cansleep(PIN_NUM, pdd->bus->data_pins->desc, ins);
+   wait_busy(pdd);
+   pardata_strobe_write(pdd);
+
+   gpiod_set_value_cansleep(pdd->bus->pin_rs, 0);
+   gpiod_set_array_value_cansleep(PIN_NUM, pdd->bus->data_pins->desc, val);
+   wait_busy(pdd);
+   pardata_strobe_write(pdd);
+
+   return 0;
+}


If this controller has normal registers, you could do a regmap
implementation for pardata: drivers/base/regmap.

Noralf.


+
+/**
+ * write_buf - write buffer on parallel bus to controller
+ *
+ * @pdd: pardata data
+ * @offset: offset into display RAM
+ * @data: pointer to data to write
+ * @len: number of bytes to write
+ *
+ * Returns:
+ * Zero on success, negative error code on failure
+ */
+int write_buf(struct pardata_data *pdd, u8 offset, u8 *data, size_t len)
+{
+   int ins[PIN_NUM];
+   int val[PIN_NUM];
+   int bit;
+   int i;
+
+   /* Setup address */
+   write_reg(pdd, WG160160_ADDRSL_REG, offset & 0xff);
+   write_reg(pdd, WG160160_ADDRSL_REG, (offset >> 8) & 0xff);
+
+   /* prepare to write data */
+   for (i = 0; i < PIN_NUM; i++)
+   ins[PIN_DB0 + i] = !!(WG160160_WRITE_REG & BIT(i));
+
+   gpiod_set_value_cansleep(pdd->bus->pin_rs, 1);
+   gpiod_set_array_value_cansleep(PIN_NUM, pdd->bus->data_pins->desc, ins);
+   wait_busy(pdd);
+   pardata_strobe_write(pdd);
+
+   /* Write data byte - by byte */
+   gpiod_set_value_cansleep(pdd->bus->pin_rs, 0);
+
+   for (i = offset; i < (offset + len); i++) {
+   for (bit = 0; bit < PIN_NUM; bit++)
+   val[PIN_DB0 + bit] = !!(data[i] & BIT(bit));
+
+   gpiod_set_array_value_cansleep(PIN_NUM,
+  pdd->bus->data_pins->desc,
+  val);
+   wait_busy(pdd);
+   pardata_strobe_write(pdd);
+   }
+
+   return 0;
+}


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/7] drm: add simpledrm driver

[Daniel Vetter]

On Tue, Jul 24, 2018 at 02:27:33PM +0200, Mads Lønsethagen wrote:
> > Hey
> > 
> > On request of Noralf, I picked up the patches and prepared v5. Works
> > fine with
> > Xorg, if configured according to:
> > https://lists.freedesktop.org/archives/dri-devel/2014-January/052777.html
> > If anyone knows how to make Xorg pick it up dynamically without such a
> > static
> > configuration, please let me know.
> > 
> > Thanks
> > David
> > 
> > David Herrmann (7):
> >   x86/sysfb: add support for 64bit EFI lfb_base
> >   x86/sysfb: fix lfb_size calculation
> >   of/platform: expose of_platform_device_destroy()
> >   video: add generic framebuffer eviction
> >   drm: switch to sysfb_evict_conflicts()
> >   drm: add SimpleDRM driver
> >   drm/simpledrm: add fbdev fallback support
> > ...
> 
> Hi!
> 
> I asked Noralf about this patch set recently, and he mentioned that this
> never made it any further than this patch series...
> 
> Are there still any interest in getting this mainlined? Does the code exist
> in any repo anywhere? For my own part, this would be an awesome driver to
> have to resurrect some old hardware I have lying around...

I think no objections against merging this from upstream pov, and David
hopefully still has a git branch somewhere. Even better if you could get a
distro on board to use this instead of efifb of offb.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/vkms: Compute CRC with Cursor Plane

[Daniel Vetter]

On Mon, Aug 06, 2018 at 06:58:29AM +0300, Haneen Mohammed wrote:
> This patch compute CRC for output frame with cursor and primary plane.
> Blend cursor with primary plane and compute CRC on the resulted frame.
> 
> Signed-off-by: Haneen Mohammed 

Nice!

I assume with this you're passing all the crc based cursor tests in igt?
If so, please mention this in the commit message, so that there's a record
of the testing done on this.

One fairly huge gap we iirc have in our cursor testing is that there's not
much (if any?) alpha blending coverage. We kinda need that to make sure
this all works correctly. The usual trick is to only check the extreme
alpha values, i.e. fully opaque and fully transparent, since intermediate
values are affected by hw-specific rounding modes.
> ---
>  drivers/gpu/drm/vkms/vkms_crc.c   | 149 +-
>  drivers/gpu/drm/vkms/vkms_drv.h   |   5 +-
>  drivers/gpu/drm/vkms/vkms_plane.c |  10 +-
>  3 files changed, 137 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
> index 37d717f38e3c..4853a739ae5a 100644
> --- a/drivers/gpu/drm/vkms/vkms_crc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> @@ -1,36 +1,137 @@
>  // SPDX-License-Identifier: GPL-2.0
>  #include "vkms_drv.h"
>  #include 
> +#include 
> +#include 
>  #include 
>  
> -static uint32_t _vkms_get_crc(struct vkms_crc_data *crc_data)
> +/**
> + * compute_crc - Compute CRC value on output frame
> + *
> + * @vaddr_out: address to final framebuffer
> + * @crc_out: framebuffer's metadata
> + *
> + * returns CRC value computed using crc32 on the visible portion of
> + * the final framebuffer at vaddr_out
> + */
> +static uint32_t compute_crc(void *vaddr_out, struct vkms_crc_data *crc_out)
>  {
> - struct drm_framebuffer *fb = _data->fb;
> + int i, src_offset;
> + int x_src = crc_out->src.x1 >> 16;
> + int y_src = crc_out->src.y1 >> 16;
> + int h_src = drm_rect_height(_out->src) >> 16;
> + int w_src = drm_rect_width(_out->src) >> 16;
> + int size_byte = w_src * crc_out->cpp;
> + u32 crc = 0;
> +
> + for (i = y_src; i < y_src + h_src; i++) {
> + src_offset = crc_out->offset
> +  + (i * crc_out->pitch)
> +  + (x_src * crc_out->cpp);
> + crc = crc32_le(crc, vaddr_out + src_offset, size_byte);
> + }
> +
> + return crc;
> +}
> +
> +/**
> + * blend - belnd value at vaddr_src with value at vaddr_dst
> + * @vaddr_dst: destination address
> + * @vaddr_src: source address
> + * @crc_dst: destination framebuffer's metadata
> + * @crc_src: source framebuffer's metadata
> + *
> + * Blend value at vaddr_src with value at vaddr_dst.
> + * Currently, this function write value at vaddr_src on value
> + * at vaddr_dst using buffer's metadata to locate the new values
> + * from vaddr_src and their distenation at vaddr_dst.
> + *
> + * Todo: Use the alpha value to blend vaddr_src with vaddr_dst
> + *instead of overwriting it.

Another todo: We must clear the alpha channel in the result after
blending. This also applies to the primary plane, where the XRGB for the
pixel format mandates that we entirely ignore the alpha channel.

This is also something we should probably have an igt testcase for.

Since there's a few open ends: How many weeks are left in your outreachy
internship? We need to make sure that at least all the issues are covered
in a vkms todo file. Would be great to add that in
Documentation/gpu/vkms.rst, like we have for other drivers.
-Daniel

> + */
> +static void blend(void *vaddr_dst, void *vaddr_src,
> +   struct vkms_crc_data *crc_dst,
> +   struct vkms_crc_data *crc_src)
> +{
> + int i, j, j_dst, i_dst;
> + int offset_src, offset_dst;
> +
> + int x_src = crc_src->src.x1 >> 16;
> + int y_src = crc_src->src.y1 >> 16;
> +
> + int x_dst = crc_src->dst.x1;
> + int y_dst = crc_src->dst.y1;
> + int h_dst = drm_rect_height(_src->dst);
> + int w_dst = drm_rect_width(_src->dst);
> +
> + int y_limit = y_src + h_dst;
> + int x_limit = x_src + w_dst;
> +
> + for (i = y_src, i_dst = y_dst; i < y_limit; ++i) {
> + for (j = x_src, j_dst = x_dst; j < x_limit; ++j) {
> + offset_dst = crc_dst->offset
> +  + (i_dst * crc_dst->pitch)
> +  + (j_dst++ * crc_dst->cpp);
> + offset_src = crc_src->offset
> +  + (i * crc_src->pitch)
> +  + (j * crc_src->cpp);
> +
> + memcpy(vaddr_dst + offset_dst,
> +vaddr_src + offset_src, sizeof(u32));
> + }
> + i_dst++;
> + }
> +}
> +
> +static void compose_cursor(struct vkms_crc_data *cursor_crc,
> +struct vkms_crc_data *primary_crc, void *vaddr_out)
> +{
> + struct 

Re: [PATCH] drm/atomic: add ATOMIC_AMEND flag to the Atomic IOCTL.

[Daniel Vetter]

On Mon, Aug 06, 2018 at 06:01:02PM +0200, Enric Balletbo i Serra wrote:
> From: Gustavo Padovan 
> 
> This flag tells core to jump ahead the queued update if the conditions
> in drm_atomic_async_check() are met. That means we are only able to do an
> async update if no modeset is pending and update for the same plane is
> not queued.
> 
> It uses the already in place infrastructure for async updates.
> 
> It is useful for cursor updates and async PageFlips over the atomic
> ioctl, otherwise in some cases updates may be delayed to the point the
> user will notice it. Note that for now it's only enabled for cursor
> planes.
> 
> DRM_MODE_ATOMIC_AMEND should be passed to the Atomic IOCTL to use this
> feature.
> 
> Signed-off-by: Gustavo Padovan 
> Signed-off-by: Enric Balletbo i Serra 
> ---
> Hi,
> 
> This is an attempt to introduce the new ATOMIC_AMEND flag for atomic
> operations, see the commit message for a more detailed description.
> 
> This was tested using a small program that exercises the uAPI for easy
> sanity testing. The program created by Alexandros can be found here
> [2]. To test, just build the program and use the --atomic flag to use the
> cursor plane in normal (blocking mode), and --atomic-async to use the cursor
> plane with the ATOMIC_AMEND flag. E.g.
> 
>   drm_cursor --atomic
> 
> or
> 
>   drm_cursor --atomic-async

Would be really lovely to bake these into igt-based regression tests. i915
doesn't yet have async update support, but I hope we'll eventually gain
that, and then our CI could make sure this keeps working.

> The test worked on a Samsung Chromebook Plus on top of mainline plus
> the patch to update cursors asynchronously through atomic for the
> drm/rockchip driver.
> 
> Alexandros also did a proof-of-concept to use this flag and draw cursors
> using atomic if possible on ozone [1].
> 
> Best regards,
>  Enric
> 
> [1] https://chromium-review.googlesource.com/c/chromium/src/+/1092711
> [2] https://gitlab.collabora.com/alf/drm-cursor
> 
> 
> Changes in v1:
> - Only enable it if userspace requests it.
> - Only allow async update for cursor type planes.
> - Rename ASYNC_UPDATE for ATOMIC_AMEND.
> 
>  drivers/gpu/drm/drm_atomic.c|  5 +
>  drivers/gpu/drm/drm_atomic_helper.c | 10 +-
>  include/uapi/drm/drm_mode.h |  4 +++-
>  3 files changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 895741e9cd7d..7b3e4aa2874d 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -2338,6 +2338,10 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
>   return -EINVAL;
>  
> + if ((arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET) &&
> + (arg->flags & DRM_MODE_ATOMIC_AMEND))
> + return -EINVAL;
> +
>   drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
>  
>   state = drm_atomic_state_alloc(dev);
> @@ -2346,6 +2350,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>  
>   state->acquire_ctx = 
>   state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
> + state->async_update = !!(arg->flags & DRM_MODE_ATOMIC_AMEND);
>  
>  retry:
>   plane_mask = 0;
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 81e32199d3ef..59495f61c583 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -902,7 +902,7 @@ int drm_atomic_helper_check(struct drm_device *dev,
>   if (ret)
>   return ret;
>  
> - if (state->legacy_cursor_update)
> + if (state->async_update || state->legacy_cursor_update)

Hm, it would be really cool if we could rip out the legacy_cursor_update
hack and also use async_update in the cursor compat helpers. At least if
available.

>   state->async_update = !drm_atomic_helper_async_check(dev, 
> state);
>  
>   return ret;
> @@ -1539,6 +1539,14 @@ int drm_atomic_helper_async_check(struct drm_device 
> *dev,
>   if (new_plane_state->fence)
>   return -EINVAL;
>  
> + /* Only allow async update for cursor type planes. */
> + if (plane->type != DRM_PLANE_TYPE_CURSOR)
> + return -EINVAL;

Why limit to cursor planes? The async_update hooks are per-plane.

> +
> + /* Don't do an async update if there isn't a pending commit. */
> + if (!old_plane_state->commit)
> + return -EINVAL;

Hm, why this? Won't this break legacy cursor updates now for drivers which
implement this using async_update?

If userspace wants to avoid this, they can do so by properly tracking
their non-AMEND updates and making sure they've waited until those all
completed.

Also, how is userspace supposed to figure out async_update exists/works?
Usual approach is a getparam.

Another semantics questions: Should this fail if we fall back to a
non-async 

Re: [PATCH v1 2/5] pardata: new bus for parallel data access

[Noralf Trønnes]

Hi Sam,

Den 02.08.2018 21.45, skrev Sam Ravnborg:

The pardata supports implement a simple bus for devices
that are connected using a parallel bus driven by GPIOs.
The is often used in combination with simple displays
that is often seen in older embedded designs.
There is a demand for this support also in the linux
kernel for HW designs that uses these kind of displays.

The pardata bus uses a platfrom_driver that when probed
creates devices for all child nodes in the DT,
which are then supposed to be handled by pardata_drivers.

Signed-off-by: Sam Ravnborg 
---


From a quick look at this I have these comments:
1. There can only be one implementation of this bus, the gpio one.
   There are SOC's with parallel bus hardware so you need to allow for
   more implementations.
2. The client shouldn't do the bus signaling. This should be hidden
   behind read and write functions in pardata.
3. I would also suggest you add an address bus instead of the RS pin
4. I don't think reset belongs in the bus. It's a device thing.
5. You can use gpiod_set_array_value() in the gpio implementation.
   Some gpio drivers can set all gpios at once.

I made an attempt at implementing a bus like this a while back:
https://github.com/notro/fbdbi/tree/master/i80

Noralf.


  Documentation/driver-api/index.rst   |   1 +
  Documentation/driver-api/pardata.rst |  60 
  MAINTAINERS  |   9 ++
  drivers/Kconfig  |   2 +
  drivers/Makefile |   1 +
  drivers/pardata/Kconfig  |  17 +++
  drivers/pardata/Makefile |   5 +
  drivers/pardata/pardata.c| 282 +++
  include/linux/pardata.h  | 138 +
  9 files changed, 515 insertions(+)
  create mode 100644 Documentation/driver-api/pardata.rst
  create mode 100644 drivers/pardata/Kconfig
  create mode 100644 drivers/pardata/Makefile
  create mode 100644 drivers/pardata/pardata.c
  create mode 100644 include/linux/pardata.h

diff --git a/Documentation/driver-api/index.rst 
b/Documentation/driver-api/index.rst
index 6d9f2f9fe20e..1808fca406ae 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -41,6 +41,7 @@ available subsections can be seen below.
 miscellaneous
 w1
 rapidio
+   pardata
 s390-drivers
 vme
 80211/index
diff --git a/Documentation/driver-api/pardata.rst 
b/Documentation/driver-api/pardata.rst
new file mode 100644
index ..a811f024a0fe
--- /dev/null
+++ b/Documentation/driver-api/pardata.rst
@@ -0,0 +1,60 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+Parallel Data Bus/Drivers
+=
+
+Displays may be connected using a simple parallel bus.
+This is often seen in embedded systems with a simple MCU, but is also
+used in Linux based systems to a small extent.
+
+The bus looks like this:
+
+.. code-block:: none
+
+   +
+   |  DB0-DB7 or DB4-DB7  +
+   ===/
+   |  E - enable  |  D
+     I
+C  |  Reset   |  S
+P    P
+U  |  Read/Write (one or two) |  L
+     A
+   |  RS - instruction/data   |  Y
+   
+   |  +
+   +
+
+There may be several devices connected to the bus with individual
+reset and read/write signals.
+Two types of interfaces are supported. 8800 with a single read/write signal,
+and 6800 with individual read/write signals.
+
+Display supported by the parallel data bus: 
``_
+
+The overall code structure is
+
+.. code-block:: none
+
+  platform_device [pardata bus]   <--- pardatabus [driver]
+   |
+   +-> device
+ |
+ +-> pardata_bus_data
+
+  pardata_device
+  |
+  +-> device
+|
++->
+
+  pardatabus_bus
+
+
+API documentation
+=
+.. kernel-doc:: include/linux/pardata.h
+   :internal:
+.. kernel-doc:: drivers/pardata/pardata.c
+   :internal:
diff --git a/MAINTAINERS b/MAINTAINERS
index 96e98e206b0d..4ba7ff7c3e46 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10727,6 +10727,15 @@ L: platform-driver-...@vger.kernel.org
  S:Maintained
  F:drivers/platform/x86/panasonic-laptop.c
  
+PARALLEL DATA SUBSYSTEM

+M: Sam Ravnborg 
+S: Maintained
+F: drivers/pardata/
+F: include/linux/pardata.h
+F: drivers/gpu/drm/tinydrm/pardata-dbi.c
+F: include/drm/pardata-dbi.h
+F: Documentation/driver-api/pardata.rst
+
  PARALLEL LCD/KEYPAD PANEL DRIVER
  M:Willy Tarreau 
  M:Ksenija Stanojevic 
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 95b9ccc08165..b51b25aae9a5 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -217,4 +217,6 @@ source 

[PATCH v4] drm/amdgpu: Transfer fences to dmabuf importer

[Chris Wilson]

amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As such, on exporting a dmabuf, we must either flush all
outstanding fences (for we do not know which are writes and should have
been exclusive) or alternatively create a new exclusive fence that is
the composite of all the existing shared fences, and so will only be
signaled when all earlier fences are signaled (ensuring that we can not
be signaled before the completion of any earlier write).

v2: reservation_object is already locked by amdgpu_bo_reserve()

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341
Testcase: igt/amd_prime/amd-to-i915
References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to prime exported 
bo's. (v5)")
Signed-off-by: Chris Wilson 
Cc: Alex Deucher 
Cc: "Christian König" 
---

This time, hopefully proofread and references complete.
-Chris

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 68 ---
 1 file changed, 60 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 1c5d97f4b4dd..dff2b01a3d89 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -37,6 +37,7 @@
 #include "amdgpu_display.h"
 #include 
 #include 
+#include 
 
 static const struct dma_buf_ops amdgpu_dmabuf_ops;
 
@@ -188,6 +189,57 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
return ERR_PTR(ret);
 }
 
+static int
+__reservation_object_make_exclusive(struct reservation_object *obj)
+{
+   struct reservation_object_list *fobj;
+   struct dma_fence_array *array;
+   struct dma_fence **fences;
+   unsigned int count, i;
+
+   fobj = reservation_object_get_list(obj);
+   if (!fobj)
+   return 0;
+
+   count = !!rcu_access_pointer(obj->fence_excl);
+   count += fobj->shared_count;
+
+   fences = kmalloc_array(count, sizeof(*fences), GFP_KERNEL);
+   if (!fences)
+   return -ENOMEM;
+
+   for (i = 0; i < fobj->shared_count; i++) {
+   struct dma_fence *f =
+   rcu_dereference_protected(fobj->shared[i],
+ reservation_object_held(obj));
+
+   fences[i] = dma_fence_get(f);
+   }
+
+   if (rcu_access_pointer(obj->fence_excl)) {
+   struct dma_fence *f =
+   rcu_dereference_protected(obj->fence_excl,
+ reservation_object_held(obj));
+
+   fences[i] = dma_fence_get(f);
+   }
+
+   array = dma_fence_array_create(count, fences,
+  dma_fence_context_alloc(1), 0,
+  false);
+   if (!array)
+   goto err_fences_put;
+
+   reservation_object_add_excl_fence(obj, >base);
+   return 0;
+
+err_fences_put:
+   for (i = 0; i < count; i++)
+   dma_fence_put(fences[i]);
+   kfree(fences);
+   return -ENOMEM;
+}
+
 /**
  * amdgpu_gem_map_attach - _buf_ops.attach implementation
  * @dma_buf: shared DMA buffer
@@ -219,16 +271,16 @@ static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
 
if (attach->dev->driver != adev->dev->driver) {
/*
-* Wait for all shared fences to complete before we switch to 
future
-* use of exclusive fence on this prime shared bo.
+* We only create shared fences for internal use, but importers
+* of the dmabuf rely on exclusive fences for implicitly
+* tracking write hazards. As any of the current fences may
+* correspond to a write, we need to convert all existing
+* fences on the reservation object into a single exclusive
+* fence.
 */
-   r = reservation_object_wait_timeout_rcu(bo->tbo.resv,
-   true, false,
-   MAX_SCHEDULE_TIMEOUT);
-   if (unlikely(r < 0)) {
-   DRM_DEBUG_PRIME("Fence wait failed: %li\n", r);
+   r = __reservation_object_make_exclusive(bo->tbo.resv);
+   if (r)
goto error_unreserve;
-   }
}
 
/* pin buffer into GTT */
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/tinydrm: Replace drm_dev_unref with drm_dev_put

[Noralf Trønnes]

Den 13.07.2018 15.46, skrev Thomas Zimmermann:

This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.

Signed-off-by: Thomas Zimmermann 
---


Thanks, applied to drm-misc.

Noralf.


  drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index 19c7f70adfa5..255341ee4eb9 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -135,7 +135,7 @@ static int tinydrm_init(struct device *parent, struct 
tinydrm_device *tdev,
/*
 * We don't embed drm_device, because that prevent us from using
 * devm_kzalloc() to allocate tinydrm_device in the driver since
-* drm_dev_unref() frees the structure. The devm_ functions provide
+* drm_dev_put() frees the structure. The devm_ functions provide
 * for easy error handling.
 */
drm = drm_dev_alloc(driver, parent);
@@ -155,7 +155,7 @@ static void tinydrm_fini(struct tinydrm_device *tdev)
drm_mode_config_cleanup(tdev->drm);
mutex_destroy(>dirty_lock);
tdev->drm->dev_private = NULL;
-   drm_dev_unref(tdev->drm);
+   drm_dev_put(tdev->drm);
  }
  
  static void devm_tinydrm_release(void *data)

@@ -172,7 +172,7 @@ static void devm_tinydrm_release(void *data)
   *
   * This function initializes @tdev, the underlying DRM device and it's
   * mode_config. Resources will be automatically freed on driver detach 
(devres)
- * using drm_mode_config_cleanup() and drm_dev_unref().
+ * using drm_mode_config_cleanup() and drm_dev_put().
   *
   * Returns:
   * Zero on success, negative error code on failure.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] tests/util: Add support for stm module

[Emil Velikov]

On 7 August 2018 at 14:39, Benjamin Gaignard
 wrote:
> 2018-07-20 13:32 GMT+02:00 Benjamin Gaignard :
>> Signed-off-by: Benjamin Gaignard 
>> ---
>>  tests/util/kms.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/tests/util/kms.c b/tests/util/kms.c
>> index 8b3e7878..a2d1d7ba 100644
>> --- a/tests/util/kms.c
>> +++ b/tests/util/kms.c
>> @@ -144,6 +144,7 @@ static const char * const modules[] = {
>> "mediatek",
>> "meson",
>> "pl111",
>> +   "stm",
>>  };
>>
> Gentle ping on this small patch,
>
Thanks pushed to master.

-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103199] [CI] igt@drv_missed_irq - fail - Failed assertion: missed_rings == expect_rings

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103199

--- Comment #3 from Martin Peres  ---
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_93/fi-icl-u/igt@drv_missed_irq.html

(drv_missed_irq:1510) CRITICAL: Test assertion failure function __real_main96,
file ../tests/drv_missed_irq.c:159:
(drv_missed_irq:1510) CRITICAL: Failed assertion: missed_rings == expect_rings
(drv_missed_irq:1510) CRITICAL: Last errno: 9, Bad file descriptor
(drv_missed_irq:1510) CRITICAL: error: 0 != 0x57
Test drv_missed_irq failed.

-- 
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 107516] Firefox for WebGL fallbacks to swrast_dri.so, not using radeon_si.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107516

--- Comment #5 from Mike  ---
PS. security.sandbox.content.read_path_whitelist works.
Need to add /sys/ (with trailing slash, as
https://wiki.mozilla.org/Security/Sandbox says), and restart Firefox.

-- 
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 libdrm v3] tests/modetest: Add atomic support

[Emil Velikov]

On 7 August 2018 at 14:53, Daniel Stone  wrote:
> Hi Emil,
> This is off-topic for the list, but ...
>
> On Tue, 7 Aug 2018 at 14:46, Emil Velikov  wrote:
>> Aside: libdrm following X/Wayland in that it lacks contributor/push access 
>> docs.
>> Might be worth, copying the Mesa ones and adding a doc in-tree.
>
> https://gitlab.freedesktop.org/wayland/wayland/blob/master/CONTRIBUTING.md
> https://gitlab.freedesktop.org/wayland/weston/blob/master/CONTRIBUTING.md
>
Right, seems like I was sleeping recently. Did not see the "commit
rights" section landing ~1month ago.

On the other hand, [1] was added a few years ago ;-)
And was a well know well before that.

> xserver also has this, linked from its README:
> https://www.x.org/wiki/Development/Documentation/SubmittingPatches
>
> Is there anything in those documents you were looking for but wasn't there?
>
This page is severely out of date. This one talks about maintainers, a
concept which hasn't been applied in years.

HTH
Emil

[1] https://www.mesa3d.org/repository.html#developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/amdgpu: Transfer fences to dmabuf importer

[Daniel Vetter]

On Tue, Aug 7, 2018 at 3:54 PM, Christian König
 wrote:
> Am 07.08.2018 um 15:37 schrieb Daniel Vetter:
>>
>> On Tue, Aug 07, 2018 at 03:17:06PM +0200, Christian König wrote:
>>>
>>> Am 07.08.2018 um 14:59 schrieb Daniel Vetter:

 On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote:
>
> Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
>>
>> On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:
>>>
>>> Am 07.08.2018 um 13:05 schrieb Chris Wilson:

 amdgpu only uses shared-fences internally, but dmabuf importers rely
 on
 implicit write hazard tracking via the
 reservation_object.fence_excl.
>>>
>>> Well I would rather suggest a solution where we stop doing this.
>>>
>>> The problem here is that i915 assumes that a write operation always
>>> needs
>>> exclusive access to an object protected by an reservation object.
>>>
>>> At least for amdgpu, radeon and nouveau this assumption is incorrect,
>>> but
>>> only amdgpu has a design where userspace is not lying to the kernel
>>> about
>>> it's read/write access.
>>>
>>> What we should do instead is to add a flag to each shared fence to
>>> note if
>>> it is a write operation or not. Then we can trivially add a function
>>> to wait
>>> on on those in i915.
>>>
>>> I should have pushed harder for this solution when the problem came
>>> up
>>> initially,
>>
>> For shared buffers in an implicit syncing setup like dri2 the
>> exclusive
>> fence _is_ your write fence.
>
> And exactly that is absolutely not correct if you ask me.
>
> The exclusive fence is for two use cases, the first one is for drivers
> which
> don't care about concurrent accesses and only use serialized accesses
> and
> the second is for kernel uses under the hood of userspace, evictions,
> buffer
> moves etc..
>
> What i915 does is to abuse that concept for write once read many
> situations,
> and that in turn is the bug we need to fix here.

 Again, the exclusive fence was added for implicit sync usage like
 dri2/3.
 _Not_ for your own buffer manager. If you want to separate these two
 usages, then I guess we can do that, but claiming that i915 is the odd
 one
 out just aint true. You're arguing against all other kms drivers we have
 here.
>>>
>>> No I'm not. I discussed exactly that use case with Maarten when the
>>> reservation object was introduced.
>>>
>>> I think that Maarten named the explicit fence on purpose "explicit" fence
>>> and not "write" fence to make that distinction clear.
>>>
>>> I have to admit that this wasn't really documented, but it indeed was the
>>> original purpose to get away from the idea that writes needs to be
>>> exclusive.
>>>
>> That's how this stuff works. Note it's only
>> for implicit fencing for dri2 shared buffers. i915 lies as much as
>> everyone else for explicit syncing.
>
> That is really really ugly and should be fixed instead.

 It works and is uapi now. What's the gain in "fixing" it?
>>>
>>> It allows you to implement explicit fencing in the uapi without breaking
>>> backward compatibility.
>>>
>>> See the situation with amdgpu and intel is the same as with userspace
>>> with
>>> mixed implicit and explicit fencing.
>>>
>>> If that isn't fixed we will run into the same problem when DRI3 gets
>>> implicit fencing and some applications starts to use it while others
>>> still
>>> rely on the explicit fencing.
>>
>> I think we're a bit cross-eyed on exact semantics, but yes this is exactly
>> the use-case. Chris Wilson's use-case tries to emulate exactly what would
>> happen if implicitly fenced amdgpu rendered buffer should be displayed on
>> an i915 output. Then you need to set the exclusive fence correctly.
>
>
> Yes, exactly. That's what I totally agree on.
>
>> And yes we called them exclusive/shared because shared fences could also
>> be write fences. But for the implicitly synced userspace case, exclusive =
>> The write fence.
>>
>> So probably Chris' patch ends up syncing too much (since for explicit
>> syncing you don't want to attach an exclusive fence, because userspace
>> passes the fence around already to the atomic ioctl). But at least it's
>> correct for the implicit case. But that's entirely an optimization problem
>> within amdgpu.
>
>
> Completely agree as well, but Chris patch actually just optimizes things. It
> is not necessary for correct operation.

Duh, I didn't read the patch carefully enough ...

> See previously we just waited for the BO to be idle, now Chris patch
> collects all fences (shared and exclusive) and adds that as single elusive
> fence to avoid blocking.
>
>> Summary: If you have a shared buffer used in implicitly synced buffer
>> sharing, you _must_ set the exclusive fence to cover all write access.
>
>
> And 

[Bug 107516] Firefox for WebGL fallbacks to swrast_dri.so, not using radeon_si.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107516

Mike  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

-- 
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 107516] Firefox for WebGL fallbacks to swrast_dri.so, not using radeon_si.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107516

--- Comment #4 from Mike  ---
(In reply to Emil Velikov from comment #3)
> https://bugzilla.mozilla.org/show_bug.cgi?id=1480755#c1

Indeed, this is Firefox's problem.

Аlthough security.sandbox.content.read_path_whitelist trick didn't work for me,
I think this bug should be resolved as INVALID.

-- 
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 v3] drm/amdgpu: Transfer fences to dmabuf importer

[Christian König]

Am 07.08.2018 um 15:37 schrieb Daniel Vetter:

On Tue, Aug 07, 2018 at 03:17:06PM +0200, Christian König wrote:

Am 07.08.2018 um 14:59 schrieb Daniel Vetter:

On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote:

Am 07.08.2018 um 14:43 schrieb Daniel Vetter:

On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:

Am 07.08.2018 um 13:05 schrieb Chris Wilson:

amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.

Well I would rather suggest a solution where we stop doing this.

The problem here is that i915 assumes that a write operation always needs
exclusive access to an object protected by an reservation object.

At least for amdgpu, radeon and nouveau this assumption is incorrect, but
only amdgpu has a design where userspace is not lying to the kernel about
it's read/write access.

What we should do instead is to add a flag to each shared fence to note if
it is a write operation or not. Then we can trivially add a function to wait
on on those in i915.

I should have pushed harder for this solution when the problem came up
initially,

For shared buffers in an implicit syncing setup like dri2 the exclusive
fence _is_ your write fence.

And exactly that is absolutely not correct if you ask me.

The exclusive fence is for two use cases, the first one is for drivers which
don't care about concurrent accesses and only use serialized accesses and
the second is for kernel uses under the hood of userspace, evictions, buffer
moves etc..

What i915 does is to abuse that concept for write once read many situations,
and that in turn is the bug we need to fix here.

Again, the exclusive fence was added for implicit sync usage like dri2/3.
_Not_ for your own buffer manager. If you want to separate these two
usages, then I guess we can do that, but claiming that i915 is the odd one
out just aint true. You're arguing against all other kms drivers we have
here.

No I'm not. I discussed exactly that use case with Maarten when the
reservation object was introduced.

I think that Maarten named the explicit fence on purpose "explicit" fence
and not "write" fence to make that distinction clear.

I have to admit that this wasn't really documented, but it indeed was the
original purpose to get away from the idea that writes needs to be
exclusive.


That's how this stuff works. Note it's only
for implicit fencing for dri2 shared buffers. i915 lies as much as
everyone else for explicit syncing.

That is really really ugly and should be fixed instead.

It works and is uapi now. What's the gain in "fixing" it?

It allows you to implement explicit fencing in the uapi without breaking
backward compatibility.

See the situation with amdgpu and intel is the same as with userspace with
mixed implicit and explicit fencing.

If that isn't fixed we will run into the same problem when DRI3 gets
implicit fencing and some applications starts to use it while others still
rely on the explicit fencing.

I think we're a bit cross-eyed on exact semantics, but yes this is exactly
the use-case. Chris Wilson's use-case tries to emulate exactly what would
happen if implicitly fenced amdgpu rendered buffer should be displayed on
an i915 output. Then you need to set the exclusive fence correctly.


Yes, exactly. That's what I totally agree on.


And yes we called them exclusive/shared because shared fences could also
be write fences. But for the implicitly synced userspace case, exclusive =
The write fence.

So probably Chris' patch ends up syncing too much (since for explicit
syncing you don't want to attach an exclusive fence, because userspace
passes the fence around already to the atomic ioctl). But at least it's
correct for the implicit case. But that's entirely an optimization problem
within amdgpu.


Completely agree as well, but Chris patch actually just optimizes 
things. It is not necessary for correct operation.


See previously we just waited for the BO to be idle, now Chris patch 
collects all fences (shared and exclusive) and adds that as single 
elusive fence to avoid blocking.



Summary: If you have a shared buffer used in implicitly synced buffer
sharing, you _must_ set the exclusive fence to cover all write access.


And how should command submission know that?

I mean we add the exclusive or shared fence during command submission, 
but that IOCTL has not the slightest idea if the BO is then used for 
explicit or for implicit fencing.



In any other case (not shared, or not as part of implicitly synced
protocol), you can do whatever you want. So we're not conflagrating
exclusive with write here at all. And yes this is exactly what i915 and
all other drivers do - for explicit fencing we don't set the exclusive
fence, but leave that all to userspace. Also, userspace tells us (because
it knows how the protocol works, not the kernel) when to set an exclusive
fence.


To extend that at least the lower layers of the user space 

Re: [PATCH libdrm v3] tests/modetest: Add atomic support

[Daniel Stone]

Hi Emil,
This is off-topic for the list, but ...

On Tue, 7 Aug 2018 at 14:46, Emil Velikov  wrote:
> Aside: libdrm following X/Wayland in that it lacks contributor/push access 
> docs.
> Might be worth, copying the Mesa ones and adding a doc in-tree.

https://gitlab.freedesktop.org/wayland/wayland/blob/master/CONTRIBUTING.md
https://gitlab.freedesktop.org/wayland/weston/blob/master/CONTRIBUTING.md

xserver also has this, linked from its README:
https://www.x.org/wiki/Development/Documentation/SubmittingPatches

Is there anything in those documents you were looking for but wasn't there?

Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107516] Firefox for WebGL fallbacks to swrast_dri.so, not using radeon_si.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107516

--- Comment #3 from Emil Velikov  ---
The FF sandboxing is fairly, ahem, strange. The following Mozilla bug addresses
that.

https://bugzilla.mozilla.org/show_bug.cgi?id=1480755#c1

-- 
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 libdrm v3] tests/modetest: Add atomic support

[Emil Velikov]

On 25 July 2018 at 15:00, Benjamin Gaignard
 wrote:
> If "-a" option is set this make modetest use atomic API instead
> of legacy API.
>
> Test the frame rate ("-v") it does a loop and swap between two
> framebuffer for each active planes.
>
> Signed-off-by: Benjamin Gaignard 
> ---
>
> version 3:
> - merge atomic code into modetest itself
> - do not change build systems
>
Thanks for folding this, instead of the duplication.

Patch looks good. Any nitpicks can be tweaked at a later stage.
Rb and pushed to master.

Aside: libdrm following X/Wayland in that it lacks contributor/push access docs.
Might be worth, copying the Mesa ones and adding a doc in-tree.

Thanks
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107516] Firefox for WebGL fallbacks to swrast_dri.so, not using radeon_si.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107516

--- Comment #2 from Mike  ---
One more thing. This bug might be firefox-specific, because other OpenGL apps,
say, glxgears, use correct driver and get HW accel.

-- 
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 107516] Firefox for WebGL fallbacks to swrast_dri.so, not using radeon_si.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107516

Mike  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=98629

-- 
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 98629] OpenGL applications warns "MESA-LOADER: failed to retrieve device information"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98629

Mike  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=107516

-- 
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 107384] random tab crashes in firefox nightly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107384

Mike  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=107516

-- 
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 107516] Firefox for WebGL fallbacks to swrast_dri.so, not using radeon_si.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107516

--- Comment #1 from Mike  ---
Possibly related to bugs 107384 and/or 98629.

If firefox start with LIBGL_DEBUG=verbose parameter, it shows:
libGL error: MESA-LOADER: failed to retrieve device information
libGL error: unable to load driver: amdgpu_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: amdgpu

I.e. it cannot retrieve device info (and name of driver as "radeonsi"), trying
to load non-existant amdgpu_dri.so, then fallbacks to swrast_dri.so

-- 
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 107516] Firefox for WebGL fallbacks to swrast_dri.so, not using radeon_si.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107516

Mike  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=107384

-- 
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 libdrm] tests/util: Add support for stm module

[Benjamin Gaignard]

2018-07-20 13:32 GMT+02:00 Benjamin Gaignard :
> Signed-off-by: Benjamin Gaignard 
> ---
>  tests/util/kms.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/tests/util/kms.c b/tests/util/kms.c
> index 8b3e7878..a2d1d7ba 100644
> --- a/tests/util/kms.c
> +++ b/tests/util/kms.c
> @@ -144,6 +144,7 @@ static const char * const modules[] = {
> "mediatek",
> "meson",
> "pl111",
> +   "stm",
>  };
>
Gentle ping on this small patch,

Regards,
Benjamin

>  int util_open(const char *device, const char *module)
> --
> 2.15.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107516] Firefox for WebGL fallbacks to swrast_dri.so, not using radeon_si.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107516

Bug ID: 107516
   Summary: Firefox for WebGL fallbacks to swrast_dri.so, not
using radeon_si.so
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: bugs.freedesktop@pm.port0.org

With recent build of libdrm (2.4.93) Mozilla Firefox cannot use accelerated
WebGL, use software emulation instead.

HW. AMD RX560 and AMD WX2100 (RX550).

SW. Ubuntu 16.04 with kernels 4.17.X and 4.18.rc from
http://kernel.ubuntu.com/~kernel-ppa/mainline/, plus Oibaf's PPA builds of drm,
mesa, etc. https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers

Symptoms. Firefox works OK, but on site with WebGL it works very slow - due to
fallback to software GL rendering.

Note. about:support page in Firefox DOES show correct driver info:
WebGL 1 Driver Renderer X.Org -- AMD Radeon Pro WX2100 (POLARIS12, DRM 3.26.0,
4.18.0-041800rc6-generic, LLVM 6.0.1)

But, on WebGL site (ex. windy.com), swrast_dri.so get loaded and eats all CPU
cores.

-- 
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 v3] drm/amdgpu: Transfer fences to dmabuf importer

[Daniel Vetter]

On Tue, Aug 07, 2018 at 03:17:06PM +0200, Christian König wrote:
> Am 07.08.2018 um 14:59 schrieb Daniel Vetter:
> > On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote:
> > > Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
> > > > On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:
> > > > > Am 07.08.2018 um 13:05 schrieb Chris Wilson:
> > > > > > amdgpu only uses shared-fences internally, but dmabuf importers 
> > > > > > rely on
> > > > > > implicit write hazard tracking via the 
> > > > > > reservation_object.fence_excl.
> > > > > Well I would rather suggest a solution where we stop doing this.
> > > > > 
> > > > > The problem here is that i915 assumes that a write operation always 
> > > > > needs
> > > > > exclusive access to an object protected by an reservation object.
> > > > > 
> > > > > At least for amdgpu, radeon and nouveau this assumption is incorrect, 
> > > > > but
> > > > > only amdgpu has a design where userspace is not lying to the kernel 
> > > > > about
> > > > > it's read/write access.
> > > > > 
> > > > > What we should do instead is to add a flag to each shared fence to 
> > > > > note if
> > > > > it is a write operation or not. Then we can trivially add a function 
> > > > > to wait
> > > > > on on those in i915.
> > > > > 
> > > > > I should have pushed harder for this solution when the problem came up
> > > > > initially,
> > > > For shared buffers in an implicit syncing setup like dri2 the exclusive
> > > > fence _is_ your write fence.
> > > And exactly that is absolutely not correct if you ask me.
> > > 
> > > The exclusive fence is for two use cases, the first one is for drivers 
> > > which
> > > don't care about concurrent accesses and only use serialized accesses and
> > > the second is for kernel uses under the hood of userspace, evictions, 
> > > buffer
> > > moves etc..
> > > 
> > > What i915 does is to abuse that concept for write once read many 
> > > situations,
> > > and that in turn is the bug we need to fix here.
> > Again, the exclusive fence was added for implicit sync usage like dri2/3.
> > _Not_ for your own buffer manager. If you want to separate these two
> > usages, then I guess we can do that, but claiming that i915 is the odd one
> > out just aint true. You're arguing against all other kms drivers we have
> > here.
> 
> No I'm not. I discussed exactly that use case with Maarten when the
> reservation object was introduced.
> 
> I think that Maarten named the explicit fence on purpose "explicit" fence
> and not "write" fence to make that distinction clear.
> 
> I have to admit that this wasn't really documented, but it indeed was the
> original purpose to get away from the idea that writes needs to be
> exclusive.
> 
> > > > That's how this stuff works. Note it's only
> > > > for implicit fencing for dri2 shared buffers. i915 lies as much as
> > > > everyone else for explicit syncing.
> > > That is really really ugly and should be fixed instead.
> > It works and is uapi now. What's the gain in "fixing" it?
> 
> It allows you to implement explicit fencing in the uapi without breaking
> backward compatibility.
> 
> See the situation with amdgpu and intel is the same as with userspace with
> mixed implicit and explicit fencing.
> 
> If that isn't fixed we will run into the same problem when DRI3 gets
> implicit fencing and some applications starts to use it while others still
> rely on the explicit fencing.

I think we're a bit cross-eyed on exact semantics, but yes this is exactly
the use-case. Chris Wilson's use-case tries to emulate exactly what would
happen if implicitly fenced amdgpu rendered buffer should be displayed on
an i915 output. Then you need to set the exclusive fence correctly.

And yes we called them exclusive/shared because shared fences could also
be write fences. But for the implicitly synced userspace case, exclusive =
The write fence.

So probably Chris' patch ends up syncing too much (since for explicit
syncing you don't want to attach an exclusive fence, because userspace
passes the fence around already to the atomic ioctl). But at least it's
correct for the implicit case. But that's entirely an optimization problem
within amdgpu.

Summary: If you have a shared buffer used in implicitly synced buffer
sharing, you _must_ set the exclusive fence to cover all write access.

In any other case (not shared, or not as part of implicitly synced
protocol), you can do whatever you want. So we're not conflagrating
exclusive with write here at all. And yes this is exactly what i915 and
all other drivers do - for explicit fencing we don't set the exclusive
fence, but leave that all to userspace. Also, userspace tells us (because
it knows how the protocol works, not the kernel) when to set an exclusive
fence. For historical reasons the relevant uapi parts are called
read/write, but that's just an accident of (maybe too clever) uapi reuse,
not their actual semantics.
-Daniel
> 
> Regards,
> Christian.
> 
> > And this was
> > 

Re: [PATCH v2 1/2] drm/sti: do not remove the drm_bridge that was never added

[Benjamin Gaignard]

2018-08-06 8:19 GMT+02:00 Peter Rosin :
> Removing the drm_bridge_remove call should avoid a NULL dereference
> during list processing in drm_bridge_remove if the error path is ever
> taken.
>
> The more natural approach would perhaps be to add a drm_bridge_add,
> but there are several other bridges that never call drm_bridge_add.
> Just removing the drm_bridge_remove is the easier fix.
>
> Fixes: 84601dbdea36 ("drm: sti: rework init sequence")
> Acked-by: Daniel Vetter 
> Signed-off-by: Peter Rosin 

Pushed on drm-misc-next,

Thanks,
Benjamin

> ---
>  drivers/gpu/drm/sti/sti_hda.c  | 1 -
>  drivers/gpu/drm/sti/sti_hdmi.c | 1 -
>  2 files changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
> index 67bbdb49fffc..199db13f565c 100644
> --- a/drivers/gpu/drm/sti/sti_hda.c
> +++ b/drivers/gpu/drm/sti/sti_hda.c
> @@ -721,7 +721,6 @@ static int sti_hda_bind(struct device *dev, struct device 
> *master, void *data)
> return 0;
>
>  err_sysfs:
> -   drm_bridge_remove(bridge);
> return -EINVAL;
>  }
>
> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
> index 58f431102512..932724784942 100644
> --- a/drivers/gpu/drm/sti/sti_hdmi.c
> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
> @@ -1315,7 +1315,6 @@ static int sti_hdmi_bind(struct device *dev, struct 
> device *master, void *data)
> return 0;
>
>  err_sysfs:
> -   drm_bridge_remove(bridge);
> hdmi->drm_connector = NULL;
> return -EINVAL;
>  }
> --
> 2.11.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 10/10] drm/vmwgfx: Use __drm_atomic_helper_plane_reset instead of copying the logic

[Sinclair Yeh]

On Tue, Aug 07, 2018 at 09:03:27AM +0100, Alexandru-Cosmin Gheorghe wrote:
> Hi Sinclair,
> 
> Is it ok if I merge this patch through drm-misc-next ?

Sure. Thanks for handling this.

Sinclair

> Thank you,
> Alex Gheorghe
> 
> On Mon, Aug 06, 2018 at 09:57:53AM -0700, Sinclair Yeh wrote:
> > Acked-by: Sinclair Yeh 
> > 
> > On Sat, Aug 04, 2018 at 05:15:30PM +0100, Alexandru Gheorghe wrote:
> > > A new helper function(__drm_atomic_helper_plane_reset) has been added
> > > for linking a plane with its state and resetting the core
> > > properties(alpha, rotation, etc.) to their default values.
> > > Use that instead of duplicating the logic.
> > > 
> > > Reviewed-by: Sinclair Yeh 
> > > Reviewed-by: Deepak Rawat 
> > > Signed-off-by: Alexandru Gheorghe 
> > > ---
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +---
> > >  1 file changed, 1 insertion(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
> > > b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > > index 4a0f0f41afa1..61824e360619 100644
> > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > > @@ -720,9 +720,7 @@ void vmw_du_plane_reset(struct drm_plane *plane)
> > >   return;
> > >   }
> > >  
> > > - plane->state = >base;
> > > - plane->state->plane = plane;
> > > - plane->state->rotation = DRM_MODE_ROTATE_0;
> > > + __drm_atomic_helper_plane_reset(plane, >base);
> > >  }
> > >  
> > >  
> > > -- 
> > > 2.18.0
> > > 
> 
> -- 
> Cheers,
> Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] drm: Allow DRM_IOCTL_MODE_MAP_DUMB for render nodes

[Emil Velikov]

On 7 August 2018 at 13:28, Daniel Vetter  wrote:
> On Tue, Aug 07, 2018 at 12:01:50PM +0100, Emil Velikov wrote:
>> On 3 August 2018 at 20:50, Sean Paul  wrote:
>> > On Fri, Aug 03, 2018 at 06:03:50PM +0100, Emil Velikov wrote:
>> >> On 3 August 2018 at 16:06, Martin Fuzzey  
>> >> wrote:
>> >> > Hi Emil,
>> >> >
>> >> > On 03/08/18 14:35, Emil Velikov wrote:
>> >> >>
>> >> >> Hi Martin,
>> >> >>
>> >> >> On 1 August 2018 at 15:24, Martin Fuzzey 
>> >> >> wrote:
>> >> >>
>> >> >> Let's start with the not-so obvious question:
>> >> >> Why does one open the imx as render node?
>> >> >>
>> >> >> Of the top of my head:
>> >> >> There is nothing in egl/android that should require an authenticated
>> >> >> device.
>> >> >> Hence, using a card node should be fine - the etnaviv code opens the
>> >> >> render node it needs.
>> >> >
>> >> >
>> >> > Yes, the problem is not in egl/android but in the scanout buffer 
>> >> > allocation
>> >> > code.
>> >> >
>> >> > etnaviv opens the render node on the *GPU* (for submitting GPU 
>> >> > commands),
>> >> > that part is fine.
>> >> >
>> >> > But scanout buffers need to be allocated from imx-drm not etnaviv.
>> >> >
>> >> > This done by renderonly_create_kms_dumb_buffer_for_resource()
>> >> > [src/gallium/auxiliary/renderonly/renderonly.c]
>> >> > Which uses DRM_IOCTL_MODE_CREATE_DUMB followed by
>> >> > DRM_IOCTL_PRIME_FD_TO_HANDLE
>> >> > on the "kms_fd" (probably poorly named because it's not actually used 
>> >> > for
>> >> > modesetting)
>> >> > see imx_drm_screen_create()[ 
>> >> > src/gallium/winsys/imx/drm/imx_drm_winsys.c]
>> >> >
>> >> >
>> >> > If the card node is used DRM_IOCTL_MODE_CREATE_DUMB works but
>> >> > DRM_IOCTL_PRIME_FD_TO_HANDLE fails, because the permissions are
>> >> > DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW
>> >> >
>> >> Right I missed the DRM_AUTH, in the fd <> handle IOCTLs.
>> >> So in order for things to work, we'd need to either:
>> >>  - allow dumb buffers for render nodes, or
>> >>  - drop the DRM_AUTH for fd <> handle imports
>> >>
>> >> Pointing an alternative solution, for kernel developers to analyse and
>> >> make a decision.
>> >>
>> >> >
>> >> > In android 8.1 the hardware composer runs in a seperate process and it 
>> >> > has
>> >> > to use the card node and be drm master (to use the KMS API),
>> >> > therefore, when the surface flinger calls
>> >> > renderonly_create_kms_dumb_buffer_for_resource() it is not 
>> >> > authenticated.
>> >> >
>> >> > Making surface flinger use a render node fixes the problem for
>> >> > DRM_IOCTL_PRIME_FD_TO_HANDLE (because that already has 
>> >> > DRM_RENDER_ALLOW),
>> >> > but DRM_IOCTL_MODE_CREATE_DUMB now fails without the patch.
>> >> >
>> >> >
>> >> > This probably worked in previous versions of Android where surface 
>> >> > flinger
>> >> > and hwc were all in the same process.
>> >> >
>> >> There has been varying hacks for Android through the years. Bringing
>> >> details into the discussion will result in a significant diversion.
>> >> Something we could avoid, for the time being ;-)
>> >
>> > Did someone say diversion?!? The way this was handled prior to using
>> > render/control nodes in drm_hwc/[drm/gbm]_gralloc is that all modesetting 
>> > was
>> > done via gralloc which was master. The hwc implementation was basically a 
>> > proxy
>> > backchanneling all of the work to gralloc.
>> >
>> > Anyways, we probably don't want to go back there.
>> >
>> Now that we got the diversion out of the way, any input on my proposal
>> to drop the DRM_AUTH for fd <> imports.
>> Am I missing something pretty obvious that makes the idea a no-go?
>
> Dropping DRM_AUTH is only relevant for the card node. And a card node
> might not be sufficiently isolated against concurrent other clients, which
> is why we don't allow it.
>
Right. I did not spot anything that would make a distinction based on
the card vs render node used.

> What we could do is essentially check whether your driver supports render
> nodes (indicating sufficient amounts of separation), and then allow
> anything for unauthenicated clients if DRM_RENDER_ALLOW is set on the
> ioctl.
>
> But that's just reinventing render nodes on top of legacy card nodes, and
> I'm not clear on what that exactly gains us.
>
As more of a userspace person, it makes sense to keep render nodes for
GPU specifics and card ones - KMS/Display Controller.

> I think the proposal for dumb render nodes (for drivers which only do dumb
> kms buffers and no rendering at all) that's been discusson on irc a bit
> makes a lot more sense.

Ack. Thanks for shedding some light.

-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] libdrm: Fix amdgpu build failure

[Christian König]

Hi Mike,

it is not the right mailing list, but thanks for the info.

I'm going to push that patch ASAP.

Christian.

Am 07.08.2018 um 14:38 schrieb Mike Lothian:

Hi

I'm not sure if this is the right mailing list or not but the
following patch gets things building with meson again

Signed-of-by: Mike Lothian 

diff --git a/amdgpu/meson.build b/amdgpu/meson.build
index f39d7bf6..d9d7de2d 100644
--- a/amdgpu/meson.build
+++ b/amdgpu/meson.build
@@ -26,8 +26,7 @@ libdrm_amdgpu = shared_library(
[
  files(
'amdgpu_asic_id.c', 'amdgpu_bo.c', 'amdgpu_cs.c', 'amdgpu_device.c',
-  'amdgpu_gpu_info.c', 'amdgpu_vamgr.c', 'amdgpu_vm.c', 'util_hash.c',
-  'util_hash_table.c',
+  'amdgpu_gpu_info.c', 'amdgpu_vamgr.c', 'amdgpu_vm.c', 'handle_table.c',
  ),
  config_file,
],
___
mesa-dev mailing list
mesa-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/amdgpu: Transfer fences to dmabuf importer

[Christian König]

Am 07.08.2018 um 14:59 schrieb Daniel Vetter:

On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote:

Am 07.08.2018 um 14:43 schrieb Daniel Vetter:

On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:

Am 07.08.2018 um 13:05 schrieb Chris Wilson:

amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.

Well I would rather suggest a solution where we stop doing this.

The problem here is that i915 assumes that a write operation always needs
exclusive access to an object protected by an reservation object.

At least for amdgpu, radeon and nouveau this assumption is incorrect, but
only amdgpu has a design where userspace is not lying to the kernel about
it's read/write access.

What we should do instead is to add a flag to each shared fence to note if
it is a write operation or not. Then we can trivially add a function to wait
on on those in i915.

I should have pushed harder for this solution when the problem came up
initially,

For shared buffers in an implicit syncing setup like dri2 the exclusive
fence _is_ your write fence.

And exactly that is absolutely not correct if you ask me.

The exclusive fence is for two use cases, the first one is for drivers which
don't care about concurrent accesses and only use serialized accesses and
the second is for kernel uses under the hood of userspace, evictions, buffer
moves etc..

What i915 does is to abuse that concept for write once read many situations,
and that in turn is the bug we need to fix here.

Again, the exclusive fence was added for implicit sync usage like dri2/3.
_Not_ for your own buffer manager. If you want to separate these two
usages, then I guess we can do that, but claiming that i915 is the odd one
out just aint true. You're arguing against all other kms drivers we have
here.


No I'm not. I discussed exactly that use case with Maarten when the 
reservation object was introduced.


I think that Maarten named the explicit fence on purpose "explicit" 
fence and not "write" fence to make that distinction clear.


I have to admit that this wasn't really documented, but it indeed was 
the original purpose to get away from the idea that writes needs to be 
exclusive.



That's how this stuff works. Note it's only
for implicit fencing for dri2 shared buffers. i915 lies as much as
everyone else for explicit syncing.

That is really really ugly and should be fixed instead.

It works and is uapi now. What's the gain in "fixing" it?


It allows you to implement explicit fencing in the uapi without breaking 
backward compatibility.


See the situation with amdgpu and intel is the same as with userspace 
with mixed implicit and explicit fencing.


If that isn't fixed we will run into the same problem when DRI3 gets 
implicit fencing and some applications starts to use it while others 
still rely on the explicit fencing.


Regards,
Christian.


And this was
discussed at length when intel and freedreno folks talked about
implementing explicit sync and android sync pts.


Now as long as you only share within amdgpu you can do whatever you want
to, but for anything shared outside of amdgpu, if the buffer isn't shared
through an explicit syncing protocol, then you do have to set the
exclusive fence. That's at least how this stuff works right now with all
other drivers.

For i915 we had to do some uapi trickery to make this work in all cases,
since only really userspace knows whether a write should be a shared or
exclusive write. But that's stricly an issue limited to your driver, and
dosn't need changes to reservation object all throughout the stack.

You don't need to change the reservation object all throughout the stack. A
simple flag if a shared fence is a write or not should be doable.

Give me a day or two to prototype that,

See my other reply, i think that's only needed for amdgpu internal
book-keeping, so that you can create the correct exclusive fence on first
export. But yeah, adding a bitfield to track which fences need to become
exclusive shouldn't be a tricky solution to implement for amdgpu.
-Daniel


Christian.


Aside: If you want to attach multiple write fences to the exclusive fence,
that should be doable with the array fences.
-Daniel


Christian.


For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As such, on exporting a dmabuf, we must either flush all
outstanding fences (for we do not know which are writes and should have
been exclusive) or alternatively create a new exclusive fence that is
the composite of all the existing shared fences, and so will only be
signaled when all earlier fences are signaled (ensuring that we can not
be signaled before the completion of any earlier write).

v2: reservation_object is already locked by amdgpu_bo_reserve()

Testcase: igt/amd_prime/amd-to-i915
Signed-off-by: Chris Wilson 
Cc: Alex 

Re: [PATCH 1/8] devfreq: rockchip-dfi: Move GRF definitions to a common place.

[Enric Balletbo i Serra]

Hi,

On 01/08/18 10:36, Chanwoo Choi wrote:
> Hi Enric,
> 
> On 2018년 07월 30일 17:11, Enric Balletbo i Serra wrote:
>> Some rk3399 GRF (Generic Register Files) definitions can be used for
>> different drivers. Move these definitions to a common include so we
>> don't need to duplicate these definitions.
>>
>> Signed-off-by: Enric Balletbo i Serra 
>> ---
>>
>> Changes in v1:
>> - [RFC 1/10] Add Acked-by: Chanwoo Choi 
> 
> Even if you add the changes log, you are missing my Acked-by tag.
> 

Ops, right, sorry about that. I'll fix in next version.

>> - [RFC 1/10] s/Generic/General/ (Robin Murphy)
>> - [RFC 4/10] Removed from the series. I did not found a use case where not 
>> holding the mutex causes the issue.
>> - [RFC 7/10] Removed from the series. I did not found a use case where this 
>> matters.
>>
>>  drivers/devfreq/event/rockchip-dfi.c | 23 +++
>>  include/soc/rockchip/rk3399_grf.h| 21 +
>>  2 files changed, 28 insertions(+), 16 deletions(-)
>>  create mode 100644 include/soc/rockchip/rk3399_grf.h
>>
>> diff --git a/drivers/devfreq/event/rockchip-dfi.c 
>> b/drivers/devfreq/event/rockchip-dfi.c
>> index 22b113363ffc..2fbbcbeb644f 100644
>> --- a/drivers/devfreq/event/rockchip-dfi.c
>> +++ b/drivers/devfreq/event/rockchip-dfi.c
>> @@ -26,6 +26,8 @@
>>  #include 
>>  #include 
>>  
>> +#include 
>> +
>>  #define RK3399_DMC_NUM_CH   2
>>  
>>  /* DDRMON_CTRL */
>> @@ -43,18 +45,6 @@
>>  #define DDRMON_CH1_COUNT_NUM0x3c
>>  #define DDRMON_CH1_DFI_ACCESS_NUM   0x40
>>  
>> -/* pmu grf */
>> -#define PMUGRF_OS_REG2  0x308
>> -#define DDRTYPE_SHIFT   13
>> -#define DDRTYPE_MASK7
>> -
>> -enum {
>> -DDR3 = 3,
>> -LPDDR3 = 6,
>> -LPDDR4 = 7,
>> -UNUSED = 0xFF
>> -};
>> -
>>  struct dmc_usage {
>>  u32 access;
>>  u32 total;
>> @@ -83,16 +73,17 @@ static void rockchip_dfi_start_hardware_counter(struct 
>> devfreq_event_dev *edev)
>>  u32 ddr_type;
>>  
>>  /* get ddr type */
>> -regmap_read(info->regmap_pmu, PMUGRF_OS_REG2, );
>> -ddr_type = (val >> DDRTYPE_SHIFT) & DDRTYPE_MASK;
>> +regmap_read(info->regmap_pmu, RK3399_PMUGRF_OS_REG2, );
>> +ddr_type = (val >> RK3399_PMUGRF_DDRTYPE_SHIFT) &
>> +RK3399_PMUGRF_DDRTYPE_MASK;
>>  
>>  /* clear DDRMON_CTRL setting */
>>  writel_relaxed(CLR_DDRMON_CTRL, dfi_regs + DDRMON_CTRL);
>>  
>>  /* set ddr type to dfi */
>> -if (ddr_type == LPDDR3)
>> +if (ddr_type == RK3399_PMUGRF_DDRTYPE_LPDDR3)
>>  writel_relaxed(LPDDR3_EN, dfi_regs + DDRMON_CTRL);
>> -else if (ddr_type == LPDDR4)
>> +else if (ddr_type == RK3399_PMUGRF_DDRTYPE_LPDDR4)
>>  writel_relaxed(LPDDR4_EN, dfi_regs + DDRMON_CTRL);
>>  
>>  /* enable count, use software mode */
>> diff --git a/include/soc/rockchip/rk3399_grf.h 
>> b/include/soc/rockchip/rk3399_grf.h
>> new file mode 100644
>> index ..3eebabcb2812
>> --- /dev/null
>> +++ b/include/soc/rockchip/rk3399_grf.h
>> @@ -0,0 +1,21 @@
>> +/* SPDX-License-Identifier: GPL-2.0+ */
>> +/*
>> + * Rockchip General Register Files definitions
>> + *
>> + * Copyright (c) 2018, Collabora Ltd.
>> + * Author: Enric Balletbo i Serra 
>> + */
>> +
>> +#ifndef __SOC_RK3399_GRF_H
>> +#define __SOC_RK3399_GRF_H
>> +
>> +/* PMU GRF Registers */
>> +#define RK3399_PMUGRF_OS_REG2   0x308
>> +#define RK3399_PMUGRF_DDRTYPE_SHIFT 13
>> +#define RK3399_PMUGRF_DDRTYPE_MASK  7
>> +#define RK3399_PMUGRF_DDRTYPE_DDR3  3
>> +#define RK3399_PMUGRF_DDRTYPE_LPDDR25
>> +#define RK3399_PMUGRF_DDRTYPE_LPDDR36
>> +#define RK3399_PMUGRF_DDRTYPE_LPDDR47
>> +
>> +#endif
>>
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V4 0/8] backlight: qcom-wled: Support for QCOM wled driver

[kgunda]

On 2018-08-03 13:15, Daniel Thompson wrote:

On Fri, Aug 03, 2018 at 12:49:34PM +0530, kgu...@codeaurora.org wrote:

Hi Bjorn,
Can you please help review this patch series ?

Pavel, Rob, Daniel reviewed the series except the "auto string 
detection"

patch.


I did take a glance at the last patch... but in the end decided to wait
for v5 to look in depth.


Daniel.





Thanks Daniel! I will push the V5 series then.


Thanks,
Kiran

On 2018-07-09 15:52, Kiran Gunda wrote:
> This patch series renames the pm8941-wled.c driver to qcom-wled.c to add
> the support for multiple PMICs supported by qualcomm. This patch series
> supports both PM8941 and PMI8998 WLED. The PMI8998 WLED has the support
> to handle the OVP (over voltage protection) and the SC (short circuit
> protection)
> interrupts. It also has the auto string detection algorithm support to
> configure the right strings if the user specified string configuration
> is in-correct. These three features are added in this series for
> PMI8998.
>
> changes from v1:
>- Fixed the commit message for
>- backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c
>
> Changes from v2:
>- Fixed bjorn and other reviewer's comments
>- Seperated the device tree bindings
>- Splitted out the WLED4 changes in seperate patch
>- Merged OVP and auto string detection patch
>
> Changes from v3:
>   - Added Reviewed-by/Acked-by tags
>   - Fixed comments from Bjorn/Vinod/Rob
>   - Splitting the "backlight: qcom-wled: Add support for WLED4
> peripheral" patch
> to seperate the WLED3 specific restructure.
>
> Kiran Gunda (8):
>   backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c
>   backlight: qcom-wled: restructure the qcom-wled bindings
>   backlight: qcom-wled: Add new properties for PMI8998
>   backlight: qcom-wled: Rename PM8941* to WLED3
>   backlight: qcom-wled: Restructure the driver for WLED3
>   backlight: qcom-wled: Add support for WLED4 peripheral
>   backlight: qcom-wled: add support for short circuit handling
>   backlight: qcom-wled: Add auto string detection logic
>
>  .../bindings/leds/backlight/pm8941-wled.txt|   42 -
>  .../bindings/leds/backlight/qcom-wled.txt  |  150 +++
>  drivers/video/backlight/Kconfig|8 +-
>  drivers/video/backlight/Makefile   |2 +-
>  drivers/video/backlight/pm8941-wled.c  |  432 ---
>  drivers/video/backlight/qcom-wled.c| 1298
> 
>  6 files changed, 1453 insertions(+), 479 deletions(-)
>  delete mode 100644
> Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
>  create mode 100644
> Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
>  delete mode 100644 drivers/video/backlight/pm8941-wled.c
>  create mode 100644 drivers/video/backlight/qcom-wled.c

--
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] gpu/drm/hisilicon: Convert drm_atomic_helper_suspend/resume()

[Souptick Joarder]

convert drm_atomic_helper_suspend/resume() to use
drm_mode_config_helper_suspend/resume().

Fixed one sparse warning by making hibmc_drm_interrupt
static.

Signed-off-by: Ajit Negi 
Signed-off-by: Souptick Joarder 
Reviewed-by: Xinliang Liu 
---
v2: remove ret variable from both suspend and resume.
remove suspend_state from hibmc_drm_private struct.

 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 20 +++-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h |  1 -
 2 files changed, 3 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index d4f6f1f..ee24480 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -37,7 +37,7 @@
.llseek = no_llseek,
 };
 
-irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
+static irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
 {
struct drm_device *dev = (struct drm_device *)arg;
struct hibmc_drm_private *priv =
@@ -74,30 +74,16 @@ static int __maybe_unused hibmc_pm_suspend(struct device 
*dev)
 {
struct pci_dev *pdev = to_pci_dev(dev);
struct drm_device *drm_dev = pci_get_drvdata(pdev);
-   struct hibmc_drm_private *priv = drm_dev->dev_private;
-
-   drm_kms_helper_poll_disable(drm_dev);
-   priv->suspend_state = drm_atomic_helper_suspend(drm_dev);
-   if (IS_ERR(priv->suspend_state)) {
-   DRM_ERROR("drm_atomic_helper_suspend failed: %ld\n",
- PTR_ERR(priv->suspend_state));
-   drm_kms_helper_poll_enable(drm_dev);
-   return PTR_ERR(priv->suspend_state);
-   }
 
-   return 0;
+   return drm_mode_config_helper_suspend(drm_dev);
 }
 
 static int  __maybe_unused hibmc_pm_resume(struct device *dev)
 {
struct pci_dev *pdev = to_pci_dev(dev);
struct drm_device *drm_dev = pci_get_drvdata(pdev);
-   struct hibmc_drm_private *priv = drm_dev->dev_private;
 
-   drm_atomic_helper_resume(drm_dev, priv->suspend_state);
-   drm_kms_helper_poll_enable(drm_dev);
-
-   return 0;
+   return drm_mode_config_helper_resume(drm_dev);
 }
 
 static const struct dev_pm_ops hibmc_pm_ops = {
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index e195521..45c25a4 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -47,7 +47,6 @@ struct hibmc_drm_private {
/* drm */
struct drm_device  *dev;
bool mode_config_initialized;
-   struct drm_atomic_state *suspend_state;
 
/* ttm */
struct drm_global_reference mem_global_ref;
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V4 5/8] backlight: qcom-wled: Restructure the driver for WLED3

[Bjorn Andersson]

On Mon 09 Jul 03:22 PDT 2018, Kiran Gunda wrote:
> diff --git a/drivers/video/backlight/qcom-wled.c 
> b/drivers/video/backlight/qcom-wled.c
[..]
> @@ -365,6 +434,15 @@ static int wled_configure(struct wled *wled, struct 
> device *dev)
>  
>   cfg->num_strings = cfg->num_strings + 1;
>  
> + string_len = of_property_count_elems_of_size(dev->of_node,
> +  "qcom,enabled-strings",
> +  sizeof(u32));
> + if (string_len > 0)
> + rc = of_property_read_u32_array(dev->of_node,
> + "qcom,enabled-strings",
> + wled->cfg.enabled_strings,

qcom,enabled-strings is listed as optional, but without it we will end
up with qcom,num-strings zeros in an array.  Initialize
wled->cfg.enabled_strings to 0,1,2,3 and the driver will be backwards
compatible.

I also think that if you do qcom,enabled-strings = <0, 1, 2>; there's no
need to also specify qcom,num-strings = <3>; and we can just use
string_len for num_strings.

> + sizeof(u32));
> +
>   return 0;
>  }

Regards,
Bjorn
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 0/4] drm/mxsfb: Fix runtime PM for unpowering lcdif block

[Leonard Crestez]

Adding lcdif nodes to a power domain currently does work, it results in
black/corrupted screens or hangs. While the driver does enable runtime
pm it does not deal correctly with the block being unpowered.

Changes since v2:
 * Split into multiple commits.
 * Use #ifdef CONFIG_PM_SLEEP.
 * Switch to drm_atomic_helper_commit_tail_rpm

Patch 1 was split because it's useful alone.

Patches 2/3 could maybe be squashed.

I'm not sure patch 4 handles vblanks correctly. It does not replace
patch 1 because there is still a small window between enabling the pipe
and the first atomic_update and also somebody needs to write to
NEXT_BUF.

Link to v2: https://lkml.org/lkml/2018/7/17/414

 drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 42 +-
 drivers/gpu/drm/mxsfb/mxsfb_drv.c  | 40 
 2 files changed, 69 insertions(+), 13 deletions(-)

-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel