[Bug 210479] amdgpu: Monitor connected to RX 6800XT loses signal when module is loaded

[bugzilla-daemon]

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

alaps...@fastmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

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

[Bug 210479] amdgpu: Monitor connected to RX 6800XT loses signal when module is loaded

[bugzilla-daemon]

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

--- Comment #2 from alaps...@fastmail.com ---
Alex, thank you very much.

This was exactly it. I had CONFIG_DRM_AMD_DC_DCN3_0 unset. After enabling it
everything seems to work fine, including XServer.

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

RE: [PATCH] drm/amdgpu: fix debugfs creation/removal, again

[Zhou1, Tao]

[AMD Public Use]

Reviewed-by: Tao Zhou 

> -Original Message-
> From: Arnd Bergmann 
> Sent: Friday, December 4, 2020 7:07 AM
> To: Deucher, Alexander ; Koenig, Christian
> ; David Airlie ; Daniel Vetter
> ; Li, Dennis ; Zhou1, Tao
> ; Chen, Guchun 
> Cc: Arnd Bergmann ; Zhang, Hawking
> ; Clements, John ;
> Yang, Stanley ; Ma, Le ; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] drm/amdgpu: fix debugfs creation/removal, again
> 
> From: Arnd Bergmann 
> 
> There is still a warning when CONFIG_DEBUG_FS is disabled:
> 
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1145:13: error:
> 'amdgpu_ras_debugfs_create_ctrl_node' defined but not used [-
> Werror=unused-function]
>  1145 | static void amdgpu_ras_debugfs_create_ctrl_node(struct
> amdgpu_device *adev)
> 
> Change the code again to make the compiler actually drop this code but not
> warn about it.
> 
> Fixes: ae2bf61ff39e ("drm/amdgpu: guard ras debugfs creation/removal based
> on CONFIG_DEBUG_FS")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 13 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h |  6 --
>  2 files changed, 5 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> index 9d11b847e6ef..c136bd449744 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> @@ -1167,7 +1167,7 @@ static void
> amdgpu_ras_debugfs_create_ctrl_node(struct amdgpu_device *adev)
>   con->dir, &con->disable_ras_err_cnt_harvest);
>  }
> 
> -void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
> +static void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
>   struct ras_fs_if *head)
>  {
>   struct amdgpu_ras *con = amdgpu_ras_get_context(adev); @@ -1189,7
> +1189,6 @@ void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
> 
>  void amdgpu_ras_debugfs_create_all(struct amdgpu_device *adev)  { -#if
> defined(CONFIG_DEBUG_FS)
>   struct amdgpu_ras *con = amdgpu_ras_get_context(adev);
>   struct ras_manager *obj;
>   struct ras_fs_if fs_info;
> @@ -1198,7 +1197,7 @@ void amdgpu_ras_debugfs_create_all(struct
> amdgpu_device *adev)
>* it won't be called in resume path, no need to check
>* suspend and gpu reset status
>*/
> - if (!con)
> + if (!IS_ENABLED(CONFIG_DEBUG_FS) || !con)
>   return;
> 
>   amdgpu_ras_debugfs_create_ctrl_node(adev);
> @@ -1212,10 +1211,9 @@ void amdgpu_ras_debugfs_create_all(struct
> amdgpu_device *adev)
>   amdgpu_ras_debugfs_create(adev, &fs_info);
>   }
>   }
> -#endif
>  }
> 
> -void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev,
> +static void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev,
>   struct ras_common_if *head)
>  {
>   struct ras_manager *obj = amdgpu_ras_find_obj(adev, head); @@ -
> 1229,7 +1227,6 @@ void amdgpu_ras_debugfs_remove(struct amdgpu_device
> *adev,
> 
>  static void amdgpu_ras_debugfs_remove_all(struct amdgpu_device *adev)  { -
> #if defined(CONFIG_DEBUG_FS)
>   struct amdgpu_ras *con = amdgpu_ras_get_context(adev);
>   struct ras_manager *obj, *tmp;
> 
> @@ -1238,7 +1235,6 @@ static void amdgpu_ras_debugfs_remove_all(struct
> amdgpu_device *adev)
>   }
> 
>   con->dir = NULL;
> -#endif
>  }
>  /* debugfs end */
> 
> @@ -1286,7 +1282,8 @@ static int amdgpu_ras_fs_init(struct amdgpu_device
> *adev)
> 
>  static int amdgpu_ras_fs_fini(struct amdgpu_device *adev)  {
> - amdgpu_ras_debugfs_remove_all(adev);
> + if (IS_ENABLED(CONFIG_DEBUG_FS))
> + amdgpu_ras_debugfs_remove_all(adev);
>   amdgpu_ras_sysfs_remove_all(adev);
>   return 0;
>  }
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
> index 4667cce38582..762f5e46c007 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
> @@ -592,14 +592,8 @@ int amdgpu_ras_sysfs_create(struct amdgpu_device
> *adev,  int amdgpu_ras_sysfs_remove(struct amdgpu_device *adev,
>   struct ras_common_if *head);
> 
> -void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
> - struct ras_fs_if *head);
> -
>  void amdgpu_ras_debugfs_create_all(struct amdgpu_device *adev);
> 
> -void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev,
> - struct ras_common_if *head);
> -
>  int amdgpu_ras_error_query(struct amdgpu_device *adev,
>   struct ras_query_if *info);
> 
> --
> 2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev

[Zack Rusin]

> On Dec 3, 2020, at 10:12, Daniel Vetter  wrote:
> 
> On Thu, Dec 03, 2020 at 03:06:20AM +, Zack Rusin wrote:
>> 
>> 
>>> On Dec 2, 2020, at 11:03, Daniel Vetter  wrote:
>>> 
>>> On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin  wrote:
 
 
 
> On Dec 2, 2020, at 09:27, Thomas Zimmermann  wrote:
> 
> Hi
> 
> Am 02.12.20 um 09:01 schrieb Thomas Zimmermann:
>> Hi
>> Am 30.11.20 um 21:59 schrieb Zack Rusin:
>>> 
>>> 
 On Nov 24, 2020, at 06:38, Thomas Zimmermann  
 wrote:
 
 Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct
 drm_device.dev. No functional changes.
 
 Signed-off-by: Thomas Zimmermann 
 Cc: Roland Scheidegger 
 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c |  8 
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 27 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |  2 +-
>>> 
>>> Reviewed-by: Zack Rusin 
>> Could you add this patch to the vmwgfx tree?
> 
> AMD devs indicated that they'd prefer to merge the patchset trough 
> drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through 
> drm-misc-next as well.
 
 Sounds good. I’ll make sure to rebase our latest patch set on top of it 
 when it’s in. Thanks!
>>> 
>>> btw if you want to avoid multi-tree coordination headaches, we can
>>> also manage vmwgfx in drm-misc and give you & Roland commit rights
>>> there. Up to you. There is some scripting involved for now (but I hope
>>> whenever we move to gitlab we could do the checks server-side):
>> 
>> I’d be happy to take you up on that. I would like to move a lot more of
>> our development into public repos and reducing the burden of maintaining
>> multiple trees would help. Is there a lot of changes to drm core that
>> doesn’t go through drm-misc? Or alternatively is drm-misc often pulling
>> from Linus’ master? I’m trying to figure out how much would our need to
>> rebase/merge be reduced if we just used drm-misc-next/drm-misc-fixes
>> because that would also allow me to point some internal testing
>> infrastructure at it as well.
> 
> I think nowadays pretty much all the cross-driver work lands through
> drm-misc. Exception is just new stuff that's only used by a single driver.
> 
> For testing there's also drm-tip, which tries to pull it all together (but
> you might still want to point your CI at branches).
> 
> Also note that drm-misc-next doesn't have a merge window freeze period
> (with have the drm-misc-next-fixes branch during that time for merge
> window fixes), so you can treat it like a main development branch like
> e.g. in mesa, with the -fixes branches as the release branches. Only
> difference is that we don't cherry pick patches from the main branch to
> the release branches (at least not as the normal flow).
> 
> If you do need a backmerge for patches from Linus to drm-misc-next because
> of some feature work (or conflicts with other stuff in general) drm-misc
> maintainers do that. Usually happens every few weeks.

Perfect, thanks a lot! This has been something I wanted our driver to do for a 
while, I’ll go ahead and switch our internal dev to drm-misc.

z

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

[PATCH 0/5] Allow to extend the timeout without jobs disappearing (v2)

[Luben Tuikov]

Hi guys,

This series of patches implements a pending list for
jobs which are in the hardware, and a done list for
tasks which are done and need to be freed.

As tasks complete and call their DRM callback, their
fences are signalled and tasks are added to the done
list and the main scheduler thread woken up. The main
scheduler thread then frees them up.

When a task times out, the timeout function prototype
now returns a value back to DRM. The reason for this is
that the GPU driver has intimate knowledge of the
hardware and can pass back information to DRM on what
to do. Whether to attempt to abort the task (by say
calling a driver abort function, etc., as the
implementation dictates), or whether the task needs
more time. Note that the task is not moved away from
the pending list, unless it is no longer in the GPU.
(The pending list holds tasks which are pending from
DRM's point of view, i.e. the GPU has control over
them--that could be things like DMA is active, CU's are
active, for the task, etc.)

The idea really is that what DRM wants to know is
whether the task is in the GPU or not. So now
drm_sched_backend_ops::timedout_job() returns
DRM_TASK_STATUS_COMPLETE if the task is no longer with
the GPU, or DRM_TASK_STATUS_ALIVE if the task needs
more time.

This series applies to drm-misc-next at 0a260e731d6c.

Tested and works, but I get a lot of
WARN_ON(bo->pin_count)) from ttm_bo_release()
for the VCN ring of amdgpu.

Cc: Alexander Deucher 
Cc: Andrey Grodzovsky 
Cc: Christian König 
Cc: Daniel Vetter 

Luben Tuikov (5):
  drm/scheduler: "node" --> "list"
  gpu/drm: ring_mirror_list --> pending_list
  drm/scheduler: Essentialize the job done callback
  drm/scheduler: Job timeout handler returns status (v2)
  drm/sched: Make use of a "done" list (v2)

 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |   8 +-
 drivers/gpu/drm/etnaviv/etnaviv_sched.c |  10 +-
 drivers/gpu/drm/lima/lima_sched.c   |   4 +-
 drivers/gpu/drm/panfrost/panfrost_job.c |   9 +-
 drivers/gpu/drm/scheduler/sched_main.c  | 345 +++-
 drivers/gpu/drm/v3d/v3d_sched.c |  32 +-
 include/drm/gpu_scheduler.h |  38 ++-
 9 files changed, 255 insertions(+), 201 deletions(-)

-- 
2.29.2.404.ge67fbf927d

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

[PATCH 5/5] drm/sched: Make use of a "done" list (v2)

[Luben Tuikov]

The drm_sched_job_done() callback now moves done
jobs from the pending list to a "done" list.

In drm_sched_job_timeout, make use of the status
returned by a GPU driver job timeout handler to
decide whether to leave the oldest job in the
pending list, or to send it off to the done list.
If a driver's job timeout callback returns a
status that that job is done, it is added to the
done list and the done thread woken up. If that
job needs more time, it is left on the pending
list and the timeout timer restarted.

The idea is that a GPU driver can check the IP to
which the passed-in job belongs to and determine
whether the IP is alive and well, or if it needs
more time to complete this job and perhaps others
also executing on it.

In drm_sched_job_timeout(), the main scheduler
thread is now parked, before calling a driver's
timeout_job callback, so as to not compete pushing
jobs down to the GPU while the recovery method is
taking place.

Eliminate the polling mechanism of picking out done
jobs from the pending list, i.e. eliminate
drm_sched_get_cleanup_job().

This also eliminates the eldest job disappearing
from the pending list, while the driver timeout
handler is called.

Various other optimizations to the GPU scheduler
and job recovery are possible with this format.

Signed-off-by: Luben Tuikov 

Cc: Alexander Deucher 
Cc: Andrey Grodzovsky 
Cc: Christian König 
Cc: Daniel Vetter 
Cc: Lucas Stach 
Cc: Russell King 
Cc: Christian Gmeiner 
Cc: Qiang Yu 
Cc: Rob Herring 
Cc: Tomeu Vizoso 
Cc: Steven Price 
Cc: Alyssa Rosenzweig 
Cc: Eric Anholt 

v2: Dispell using a done thread, so as to keep
the cache hot on the same processor.
---
 drivers/gpu/drm/scheduler/sched_main.c | 247 +
 include/drm/gpu_scheduler.h|   4 +
 2 files changed, 134 insertions(+), 117 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index b9876cad94f2..d77180b44998 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -164,7 +164,9 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
  * drm_sched_job_done - complete a job
  * @s_job: pointer to the job which is done
  *
- * Finish the job's fence and wake up the worker thread.
+ * Move the completed task to the done list,
+ * signal the its fence to mark it finished,
+ * and wake up the worker thread.
  */
 static void drm_sched_job_done(struct drm_sched_job *s_job)
 {
@@ -176,9 +178,14 @@ static void drm_sched_job_done(struct drm_sched_job *s_job)
 
trace_drm_sched_process_job(s_fence);
 
+   spin_lock(&sched->job_list_lock);
+   list_move(&s_job->list, &sched->done_list);
+   spin_unlock(&sched->job_list_lock);
+
dma_fence_get(&s_fence->finished);
drm_sched_fence_finished(s_fence);
dma_fence_put(&s_fence->finished);
+
wake_up_interruptible(&sched->wake_up_worker);
 }
 
@@ -309,6 +316,37 @@ static void drm_sched_job_begin(struct drm_sched_job 
*s_job)
spin_unlock(&sched->job_list_lock);
 }
 
+/** drm_sched_job_timeout -- a timer timeout occurred
+ * @work: pointer to work_struct
+ *
+ * First, park the scheduler thread whose IP timed out,
+ * so that we don't race with the scheduler thread pushing
+ * jobs down the IP as we try to investigate what
+ * happened and give drivers a chance to recover.
+ *
+ * Second, take the fist job in the pending list
+ * (oldest), leave it in the pending list and call the
+ * driver's timer timeout callback to find out what
+ * happened, passing this job as the suspect one.
+ *
+ * The driver may return DRM_TASK_STATUS COMPLETE,
+ * which means the task is not in the IP(*) and we move
+ * it to the done list to free it.
+ *
+ * (*) A reason for this would be, say, that the job
+ * completed in due time, or the driver has aborted
+ * this job using driver specific methods in the
+ * timedout_job callback and has now removed it from
+ * the hardware.
+ *
+ * Or, the driver may return DRM_TASK_STATUS_ALIVE, to
+ * indicate that it had inquired about this job, and it
+ * has verified that this job is alive and well, and
+ * that the DRM layer should give this task more time
+ * to complete. In this case, we restart the timeout timer.
+ *
+ * Lastly, we unpark the scheduler thread.
+ */
 static void drm_sched_job_timedout(struct work_struct *work)
 {
struct drm_gpu_scheduler *sched;
@@ -316,37 +354,32 @@ static void drm_sched_job_timedout(struct work_struct 
*work)
 
sched = container_of(work, struct drm_gpu_scheduler, work_tdr.work);
 
-   /* Protects against concurrent deletion in drm_sched_get_cleanup_job */
+   kthread_park(sched->thread);
+
spin_lock(&sched->job_list_lock);
job = list_first_entry_or_null(&sched->pending_list,
   struct drm_sched_job, list);
+   spin_unlock(&sched->job_list_lock);
 
if (job) {
-   /*
-* Remove the bad jo

[PATCH 3/5] drm/scheduler: Essentialize the job done callback

[Luben Tuikov]

The job done callback is called from various
places, in two ways: in job done role, and
as a fence callback role.

Essentialize the callback to an atom
function to just complete the job,
and into a second function as a prototype
of fence callback which calls to complete
the job.

This is used in latter patches by the completion
code.

Signed-off-by: Luben Tuikov 
Reviewed-by: Christian König 

Cc: Alexander Deucher 
Cc: Andrey Grodzovsky 
Cc: Christian König 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/scheduler/sched_main.c | 73 ++
 1 file changed, 40 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index b694df12aaba..3eb7618a627d 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -60,8 +60,6 @@
 #define to_drm_sched_job(sched_job)\
container_of((sched_job), struct drm_sched_job, queue_node)
 
-static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb 
*cb);
-
 /**
  * drm_sched_rq_init - initialize a given run queue struct
  *
@@ -162,6 +160,40 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
return NULL;
 }
 
+/**
+ * drm_sched_job_done - complete a job
+ * @s_job: pointer to the job which is done
+ *
+ * Finish the job's fence and wake up the worker thread.
+ */
+static void drm_sched_job_done(struct drm_sched_job *s_job)
+{
+   struct drm_sched_fence *s_fence = s_job->s_fence;
+   struct drm_gpu_scheduler *sched = s_fence->sched;
+
+   atomic_dec(&sched->hw_rq_count);
+   atomic_dec(&sched->score);
+
+   trace_drm_sched_process_job(s_fence);
+
+   dma_fence_get(&s_fence->finished);
+   drm_sched_fence_finished(s_fence);
+   dma_fence_put(&s_fence->finished);
+   wake_up_interruptible(&sched->wake_up_worker);
+}
+
+/**
+ * drm_sched_job_done_cb - the callback for a done job
+ * @f: fence
+ * @cb: fence callbacks
+ */
+static void drm_sched_job_done_cb(struct dma_fence *f, struct dma_fence_cb *cb)
+{
+   struct drm_sched_job *s_job = container_of(cb, struct drm_sched_job, 
cb);
+
+   drm_sched_job_done(s_job);
+}
+
 /**
  * drm_sched_dependency_optimized
  *
@@ -473,14 +505,14 @@ void drm_sched_start(struct drm_gpu_scheduler *sched, 
bool full_recovery)
 
if (fence) {
r = dma_fence_add_callback(fence, &s_job->cb,
-  drm_sched_process_job);
+  drm_sched_job_done_cb);
if (r == -ENOENT)
-   drm_sched_process_job(fence, &s_job->cb);
+   drm_sched_job_done(s_job);
else if (r)
DRM_ERROR("fence add callback failed (%d)\n",
  r);
} else
-   drm_sched_process_job(NULL, &s_job->cb);
+   drm_sched_job_done(s_job);
}
 
if (full_recovery) {
@@ -635,31 +667,6 @@ drm_sched_select_entity(struct drm_gpu_scheduler *sched)
return entity;
 }
 
-/**
- * drm_sched_process_job - process a job
- *
- * @f: fence
- * @cb: fence callbacks
- *
- * Called after job has finished execution.
- */
-static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb *cb)
-{
-   struct drm_sched_job *s_job = container_of(cb, struct drm_sched_job, 
cb);
-   struct drm_sched_fence *s_fence = s_job->s_fence;
-   struct drm_gpu_scheduler *sched = s_fence->sched;
-
-   atomic_dec(&sched->hw_rq_count);
-   atomic_dec(&sched->score);
-
-   trace_drm_sched_process_job(s_fence);
-
-   dma_fence_get(&s_fence->finished);
-   drm_sched_fence_finished(s_fence);
-   dma_fence_put(&s_fence->finished);
-   wake_up_interruptible(&sched->wake_up_worker);
-}
-
 /**
  * drm_sched_get_cleanup_job - fetch the next finished job to be destroyed
  *
@@ -809,9 +816,9 @@ static int drm_sched_main(void *param)
if (!IS_ERR_OR_NULL(fence)) {
s_fence->parent = dma_fence_get(fence);
r = dma_fence_add_callback(fence, &sched_job->cb,
-  drm_sched_process_job);
+  drm_sched_job_done_cb);
if (r == -ENOENT)
-   drm_sched_process_job(fence, &sched_job->cb);
+   drm_sched_job_done(sched_job);
else if (r)
DRM_ERROR("fence add callback failed (%d)\n",
  r);
@@ -820,7 +827,7 @@ static int drm_sched_main(void *param)
if (IS_ERR(fence))
dma_fence_set_error(&s_fence->finished, 
PTR_ERR(fence));
 
-   d

[PATCH 2/5] gpu/drm: ring_mirror_list --> pending_list

[Luben Tuikov]

Rename "ring_mirror_list" to "pending_list",
to describe what something is, not what it does,
how it's used, or how the hardware implements it.

This also abstracts the actual hardware
implementation, i.e. how the low-level driver
communicates with the device it drives, ring, CAM,
etc., shouldn't be exposed to DRM.

The pending_list keeps jobs submitted, which are
out of our control. Usually this means they are
pending execution status in hardware, but the
latter definition is a more general (inclusive)
definition.

Signed-off-by: Luben Tuikov 
Acked-by: Christian König 

Cc: Alexander Deucher 
Cc: Andrey Grodzovsky 
Cc: Christian König 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c |  4 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |  4 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  2 +-
 drivers/gpu/drm/scheduler/sched_main.c  | 34 ++---
 include/drm/gpu_scheduler.h | 10 +++---
 5 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 8358cae0b5a4..db77a5bdfa45 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1427,7 +1427,7 @@ static void amdgpu_ib_preempt_job_recovery(struct 
drm_gpu_scheduler *sched)
struct dma_fence *fence;
 
spin_lock(&sched->job_list_lock);
-   list_for_each_entry(s_job, &sched->ring_mirror_list, list) {
+   list_for_each_entry(s_job, &sched->pending_list, list) {
fence = sched->ops->run_job(s_job);
dma_fence_put(fence);
}
@@ -1459,7 +1459,7 @@ static void amdgpu_ib_preempt_mark_partial_job(struct 
amdgpu_ring *ring)
 
 no_preempt:
spin_lock(&sched->job_list_lock);
-   list_for_each_entry_safe(s_job, tmp, &sched->ring_mirror_list, list) {
+   list_for_each_entry_safe(s_job, tmp, &sched->pending_list, list) {
if (dma_fence_is_signaled(&s_job->s_fence->finished)) {
/* remove job from ring_mirror_list */
list_del_init(&s_job->list);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 4df6de81cd41..fbae600aa5f9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4127,8 +4127,8 @@ bool amdgpu_device_has_job_running(struct amdgpu_device 
*adev)
continue;
 
spin_lock(&ring->sched.job_list_lock);
-   job = list_first_entry_or_null(&ring->sched.ring_mirror_list,
-   struct drm_sched_job, list);
+   job = list_first_entry_or_null(&ring->sched.pending_list,
+  struct drm_sched_job, list);
spin_unlock(&ring->sched.job_list_lock);
if (job)
return true;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index aca52a46b93d..ff48101bab55 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -271,7 +271,7 @@ void amdgpu_job_stop_all_jobs_on_sched(struct 
drm_gpu_scheduler *sched)
}
 
/* Signal all jobs already scheduled to HW */
-   list_for_each_entry(s_job, &sched->ring_mirror_list, list) {
+   list_for_each_entry(s_job, &sched->pending_list, list) {
struct drm_sched_fence *s_fence = s_job->s_fence;
 
dma_fence_set_error(&s_fence->finished, -EHWPOISON);
diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index c52eba407ebd..b694df12aaba 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -198,7 +198,7 @@ EXPORT_SYMBOL(drm_sched_dependency_optimized);
 static void drm_sched_start_timeout(struct drm_gpu_scheduler *sched)
 {
if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
-   !list_empty(&sched->ring_mirror_list))
+   !list_empty(&sched->pending_list))
schedule_delayed_work(&sched->work_tdr, sched->timeout);
 }
 
@@ -258,7 +258,7 @@ void drm_sched_resume_timeout(struct drm_gpu_scheduler 
*sched,
 {
spin_lock(&sched->job_list_lock);
 
-   if (list_empty(&sched->ring_mirror_list))
+   if (list_empty(&sched->pending_list))
cancel_delayed_work(&sched->work_tdr);
else
mod_delayed_work(system_wq, &sched->work_tdr, remaining);
@@ -272,7 +272,7 @@ static void drm_sched_job_begin(struct drm_sched_job *s_job)
struct drm_gpu_scheduler *sched = s_job->sched;
 
spin_lock(&sched->job_list_lock);
-   list_add_tail(&s_job->list, &sched->ring_mirror_list);
+   list_add_tail(&s_job->list, &sched->pending_list);
drm_sched_start_timeout(sched);
spin_unlock(&sched->job_list_lock);
 }
@@

[PATCH 4/5] drm/scheduler: Job timeout handler returns status (v2)

[Luben Tuikov]

The driver's job timeout handler now returns
status indicating back to the DRM layer whether
the task (job) was successfully aborted or whether
more time should be given to the task to complete.

Default behaviour as of this patch, is preserved,
except in obvious-by-comment case in the Panfrost
driver, as documented below.

All drivers which make use of the
drm_sched_backend_ops' .timedout_job() callback
have been accordingly renamed and return the
would've-been default value of
DRM_TASK_STATUS_ALIVE to restart the task's
timeout timer--this is the old behaviour, and
is preserved by this patch.

In the case of the Panfrost driver, its timedout
callback correctly first checks if the job had
completed in due time and if so, it now returns
DRM_TASK_STATUS_COMPLETE to notify the DRM layer
that the task can be moved to the done list, to be
freed later. In the other two subsequent checks,
the value of DRM_TASK_STATUS_ALIVE is returned, as
per the default behaviour.

A more involved driver's solutions can be had
in subequent patches.

Signed-off-by: Luben Tuikov 
Reported-by: kernel test robot 

Cc: Alexander Deucher 
Cc: Andrey Grodzovsky 
Cc: Christian König 
Cc: Daniel Vetter 
Cc: Lucas Stach 
Cc: Russell King 
Cc: Christian Gmeiner 
Cc: Qiang Yu 
Cc: Rob Herring 
Cc: Tomeu Vizoso 
Cc: Steven Price 
Cc: Alyssa Rosenzweig 
Cc: Eric Anholt 

v2: Use enum as the status of a driver's job
timeout callback method.
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  6 +++--
 drivers/gpu/drm/etnaviv/etnaviv_sched.c | 10 +++-
 drivers/gpu/drm/lima/lima_sched.c   |  4 +++-
 drivers/gpu/drm/panfrost/panfrost_job.c |  9 ---
 drivers/gpu/drm/scheduler/sched_main.c  |  4 +---
 drivers/gpu/drm/v3d/v3d_sched.c | 32 +
 include/drm/gpu_scheduler.h | 20 +---
 7 files changed, 57 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index ff48101bab55..a111326cbdde 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -28,7 +28,7 @@
 #include "amdgpu.h"
 #include "amdgpu_trace.h"
 
-static void amdgpu_job_timedout(struct drm_sched_job *s_job)
+static enum drm_task_status amdgpu_job_timedout(struct drm_sched_job *s_job)
 {
struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
struct amdgpu_job *job = to_amdgpu_job(s_job);
@@ -41,7 +41,7 @@ static void amdgpu_job_timedout(struct drm_sched_job *s_job)
amdgpu_ring_soft_recovery(ring, job->vmid, s_job->s_fence->parent)) 
{
DRM_ERROR("ring %s timeout, but soft recovered\n",
  s_job->sched->name);
-   return;
+   return DRM_TASK_STATUS_ALIVE;
}
 
amdgpu_vm_get_task_info(ring->adev, job->pasid, &ti);
@@ -53,10 +53,12 @@ static void amdgpu_job_timedout(struct drm_sched_job *s_job)
 
if (amdgpu_device_should_recover_gpu(ring->adev)) {
amdgpu_device_gpu_recover(ring->adev, job);
+   return DRM_TASK_STATUS_ALIVE;
} else {
drm_sched_suspend_timeout(&ring->sched);
if (amdgpu_sriov_vf(adev))
adev->virt.tdr_debug = true;
+   return DRM_TASK_STATUS_ALIVE;
}
 }
 
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c 
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index cd46c882269c..c49516942328 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -82,7 +82,8 @@ static struct dma_fence *etnaviv_sched_run_job(struct 
drm_sched_job *sched_job)
return fence;
 }
 
-static void etnaviv_sched_timedout_job(struct drm_sched_job *sched_job)
+static enum drm_task_status etnaviv_sched_timedout_job(struct drm_sched_job
+  *sched_job)
 {
struct etnaviv_gem_submit *submit = to_etnaviv_submit(sched_job);
struct etnaviv_gpu *gpu = submit->gpu;
@@ -120,9 +121,16 @@ static void etnaviv_sched_timedout_job(struct 
drm_sched_job *sched_job)
 
drm_sched_resubmit_jobs(&gpu->sched);
 
+   /* Tell the DRM scheduler that this task needs
+* more time.
+*/
+   drm_sched_start(&gpu->sched, true);
+   return DRM_TASK_STATUS_ALIVE;
+
 out_no_timeout:
/* restart scheduler after GPU is usable again */
drm_sched_start(&gpu->sched, true);
+   return DRM_TASK_STATUS_ALIVE;
 }
 
 static void etnaviv_sched_free_job(struct drm_sched_job *sched_job)
diff --git a/drivers/gpu/drm/lima/lima_sched.c 
b/drivers/gpu/drm/lima/lima_sched.c
index 63b4c5643f9c..66d9236b8760 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -415,7 +415,7 @@ static void lima_sched_build_error_task_list(struct 
lima_sched_task *task)
mutex_unlock(&dev->error_task_list_lock);
 }
 
-static void lima_sched_timedout_job(struct drm_sched_j

[PATCH 1/5] drm/scheduler: "node" --> "list"

[Luben Tuikov]

Rename "node" to "list" in struct drm_sched_job,
in order to make it consistent with what we see
being used throughout gpu_scheduler.h, for
instance in struct drm_sched_entity, as well as
the rest of DRM and the kernel.

Signed-off-by: Luben Tuikov 
Reviewed-by: Christian König 

Cc: Alexander Deucher 
Cc: Andrey Grodzovsky 
Cc: Christian König 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c |  6 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  2 +-
 drivers/gpu/drm/scheduler/sched_main.c  | 23 +++--
 include/drm/gpu_scheduler.h |  4 ++--
 5 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 5c1f3725c741..8358cae0b5a4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1427,7 +1427,7 @@ static void amdgpu_ib_preempt_job_recovery(struct 
drm_gpu_scheduler *sched)
struct dma_fence *fence;
 
spin_lock(&sched->job_list_lock);
-   list_for_each_entry(s_job, &sched->ring_mirror_list, node) {
+   list_for_each_entry(s_job, &sched->ring_mirror_list, list) {
fence = sched->ops->run_job(s_job);
dma_fence_put(fence);
}
@@ -1459,10 +1459,10 @@ static void amdgpu_ib_preempt_mark_partial_job(struct 
amdgpu_ring *ring)
 
 no_preempt:
spin_lock(&sched->job_list_lock);
-   list_for_each_entry_safe(s_job, tmp, &sched->ring_mirror_list, node) {
+   list_for_each_entry_safe(s_job, tmp, &sched->ring_mirror_list, list) {
if (dma_fence_is_signaled(&s_job->s_fence->finished)) {
/* remove job from ring_mirror_list */
-   list_del_init(&s_job->node);
+   list_del_init(&s_job->list);
sched->ops->free_job(s_job);
continue;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 7560b05e4ac1..4df6de81cd41 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4128,7 +4128,7 @@ bool amdgpu_device_has_job_running(struct amdgpu_device 
*adev)
 
spin_lock(&ring->sched.job_list_lock);
job = list_first_entry_or_null(&ring->sched.ring_mirror_list,
-   struct drm_sched_job, node);
+   struct drm_sched_job, list);
spin_unlock(&ring->sched.job_list_lock);
if (job)
return true;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index dcfe8a3b03ff..aca52a46b93d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -271,7 +271,7 @@ void amdgpu_job_stop_all_jobs_on_sched(struct 
drm_gpu_scheduler *sched)
}
 
/* Signal all jobs already scheduled to HW */
-   list_for_each_entry(s_job, &sched->ring_mirror_list, node) {
+   list_for_each_entry(s_job, &sched->ring_mirror_list, list) {
struct drm_sched_fence *s_fence = s_job->s_fence;
 
dma_fence_set_error(&s_fence->finished, -EHWPOISON);
diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index c6332d75025e..c52eba407ebd 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -272,7 +272,7 @@ static void drm_sched_job_begin(struct drm_sched_job *s_job)
struct drm_gpu_scheduler *sched = s_job->sched;
 
spin_lock(&sched->job_list_lock);
-   list_add_tail(&s_job->node, &sched->ring_mirror_list);
+   list_add_tail(&s_job->list, &sched->ring_mirror_list);
drm_sched_start_timeout(sched);
spin_unlock(&sched->job_list_lock);
 }
@@ -287,7 +287,7 @@ static void drm_sched_job_timedout(struct work_struct *work)
/* Protects against concurrent deletion in drm_sched_get_cleanup_job */
spin_lock(&sched->job_list_lock);
job = list_first_entry_or_null(&sched->ring_mirror_list,
-  struct drm_sched_job, node);
+  struct drm_sched_job, list);
 
if (job) {
/*
@@ -295,7 +295,7 @@ static void drm_sched_job_timedout(struct work_struct *work)
 * drm_sched_cleanup_jobs. It will be reinserted back after 
sched->thread
 * is parked at which point it's safe.
 */
-   list_del_init(&job->node);
+   list_del_init(&job->list);
spin_unlock(&sched->job_list_lock);
 
job->sched->ops->timedout_job(job);
@@ -392,7 +392,7 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched, struct 
drm_sched_job *bad)
  

[git pull] drm fixes for 5.10-rc7

[Dave Airlie]

Hi Linus,

This week's regular fixes. i915 has fixes for a few races,
use-after-free, gpu hangs,
tegra just has some minor fixes that I didn't see much point in
hanging on to. The
nouveau fix is for all pre-nv50 cards and was reported a few times.
Otherwise it's
just some amdgpu, and a few misc fixes.

Regards,
Dave.

drm-fixes-2020-12-04:
drm fixes for 5.10-rc7

amdgpu:
- SMU11 manual fan fix
- Renoir display clock fix
- VCN3 dynamic powergating fix

i915:
- Program mocs:63 for cache eviction on gen9
- Protect context lifetime with RCU
- Split the breadcrumb spinlock between global and contexts
- Retain default context state across shrinking
- Limit frequency drop to RPe on parking
- Return earlier from intel_modeset_init() without display
- Defer initial modeset until after GGTT is initialized

nouveau:
- pre-nv50 regression fix

rockchip:
- uninitialised LVDS property fix

omap:
- bridge fix

panel:
- race fix

mxsfb:
- fence sync fix
- modifiers fix

tegra:
- idr init fix
- sor fixes
- output/of cleanup fix
The following changes since commit b65054597872ce3aefbc6a666385eabdf9e288da:

  Linux 5.10-rc6 (2020-11-29 15:50:50 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-12-04

for you to fetch changes up to de9b485d1dc993f1fb579b5d15a8176284627f4a:

  Merge tag 'drm-misc-fixes-2020-12-03' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2020-12-04
11:53:50 +1000)


drm fixes for 5.10-rc7

amdgpu:
- SMU11 manual fan fix
- Renoir display clock fix
- VCN3 dynamic powergating fix

i915:
- Program mocs:63 for cache eviction on gen9 (Chris)
- Protect context lifetime with RCU (Chris)
- Split the breadcrumb spinlock between global and contexts (Chris)
- Retain default context state across shrinking (Venkata)
- Limit frequency drop to RPe on parking (Chris)
- Return earlier from intel_modeset_init() without display (Jani)
- Defer initial modeset until after GGTT is initialized (Chris)

nouveau:
- pre-nv50 regression fix

rockchip:
- uninitialised LVDS property fix

omap:
- bridge fix

panel:
- race fix

mxsfb:
- fence sync fix
- modifiers fix

tegra:
- idr init fix
- sor fixes
- output/of cleanup fix


Arunpravin (1):
  drm/amdgpu/pm/smu11: Fix fan set speed bug

Boyuan Zhang (2):
  drm/amdgpu/vcn3.0: stall DPG when WPTR/RPTR reset
  drm/amdgpu/vcn3.0: remove old DPG workaround

Brandon Syu (1):
  drm/amd/display: Init clock value by current vbios CLKs

Chris Wilson (5):
  drm/i915/gt: Program mocs:63 for cache eviction on gen9
  drm/i915/gt: Protect context lifetime with RCU
  drm/i915/gt: Split the breadcrumb spinlock between global and contexts
  drm/i915/gt: Limit frequency drop to RPe on parking
  drm/i915/display: Defer initial modeset until after GGTT is initialised

Christian König (1):
  drm/nouveau: make sure ret is initialized in nouveau_ttm_io_mem_reserve

Daniel Abrecht (1):
  drm: mxsfb: Implement .format_mod_supported

Dave Airlie (4):
  Merge tag 'drm/tegra/for-5.10-rc7' of
ssh://git.freedesktop.org/git/tegra/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2020-12-03' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge tag 'amd-drm-fixes-5.10-2020-12-02' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2020-12-03' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

Deepak R Varma (1):
  drm/tegra: replace idr_init() by idr_init_base()

Jani Nikula (1):
  drm/i915/display: return earlier from intel_modeset_init() without display

Jon Hunter (1):
  drm/tegra: sor: Don't warn on probe deferral

Lucas Stach (1):
  drm: mxsfb: fix fence synchronization

Marc Zyngier (1):
  drm/tegra: sor: Ensure regulators are disabled on teardown

Paul Kocialkowski (1):
  drm/rockchip: Avoid uninitialized use of endpoint id in LVDS

Qinglang Miao (1):
  drm/tegra: sor: Disable clocks on error in tegra_sor_init()

Sebastian Reichel (1):
  drm/panel: sony-acx565akm: Fix race condition in probe

Thierry Reding (1):
  drm/tegra: output: Do not put OF node twice

Tomi Valkeinen (1):
  drm/omap: sdi: fix bridge enable/disable

Venkata Ramana Nayana (1):
  drm/i915/gt: Retain default context state across shrinking

 drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c  |  25 ++-
 .../drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c  |  13 +-
 drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c |   7 +-
 drivers/gpu/drm/i915/display/intel_display.c   |  24 +--
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c| 168 +
 drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h  |   6 +-
 drivers/gpu/drm/i915/gt/intel_context.c|  15 +-
 drivers/gpu/drm/i915/gt/intel_context_types.h  |  23 ++-
 drivers/gpu/drm/i915/gt/intel_mocs.c

[PATCH] drm/msm: add IOMMU_SUPPORT dependency

[Arnd Bergmann]

From: Arnd Bergmann 

The iommu pgtable support is only available when IOMMU support
is built into the kernel:

WARNING: unmet direct dependencies detected for IOMMU_IO_PGTABLE
  Depends on [n]: IOMMU_SUPPORT [=n]
  Selected by [y]:
  - DRM_MSM [=y] && HAS_IOMEM [=y] && DRM [=y] && (ARCH_QCOM [=y] || SOC_IMX5 
|| ARM && COMPILE_TEST [=y]) && OF [=y] && COMMON_CLK [=y] && MMU [=y] && 
(QCOM_OCMEM [=y] || QCOM_OCMEM [=y]=n)

Fix the dependency accordingly. There is no need for depending on
CONFIG_MMU any more, as that is implied by the iommu support.

Fixes: b145c6e65eb0 ("drm/msm: Add support to create a local pagetable")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/msm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index e5816b498494..dabb4a1ccdcf 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -4,8 +4,8 @@ config DRM_MSM
tristate "MSM DRM"
depends on DRM
depends on ARCH_QCOM || SOC_IMX5 || (ARM && COMPILE_TEST)
+   depends on IOMMU_SUPPORT
depends on OF && COMMON_CLK
-   depends on MMU
depends on QCOM_OCMEM || QCOM_OCMEM=n
select IOMMU_IO_PGTABLE
select QCOM_MDT_LOADER if ARCH_QCOM
-- 
2.27.0

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

[PATCH] drm/amdgpu: fix debugfs creation/removal, again

[Arnd Bergmann]

From: Arnd Bergmann 

There is still a warning when CONFIG_DEBUG_FS is disabled:

drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1145:13: error: 
'amdgpu_ras_debugfs_create_ctrl_node' defined but not used 
[-Werror=unused-function]
 1145 | static void amdgpu_ras_debugfs_create_ctrl_node(struct amdgpu_device 
*adev)

Change the code again to make the compiler actually drop
this code but not warn about it.

Fixes: ae2bf61ff39e ("drm/amdgpu: guard ras debugfs creation/removal based on 
CONFIG_DEBUG_FS")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 13 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h |  6 --
 2 files changed, 5 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 9d11b847e6ef..c136bd449744 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1167,7 +1167,7 @@ static void amdgpu_ras_debugfs_create_ctrl_node(struct 
amdgpu_device *adev)
con->dir, &con->disable_ras_err_cnt_harvest);
 }
 
-void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
+static void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
struct ras_fs_if *head)
 {
struct amdgpu_ras *con = amdgpu_ras_get_context(adev);
@@ -1189,7 +1189,6 @@ void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
 
 void amdgpu_ras_debugfs_create_all(struct amdgpu_device *adev)
 {
-#if defined(CONFIG_DEBUG_FS)
struct amdgpu_ras *con = amdgpu_ras_get_context(adev);
struct ras_manager *obj;
struct ras_fs_if fs_info;
@@ -1198,7 +1197,7 @@ void amdgpu_ras_debugfs_create_all(struct amdgpu_device 
*adev)
 * it won't be called in resume path, no need to check
 * suspend and gpu reset status
 */
-   if (!con)
+   if (!IS_ENABLED(CONFIG_DEBUG_FS) || !con)
return;
 
amdgpu_ras_debugfs_create_ctrl_node(adev);
@@ -1212,10 +1211,9 @@ void amdgpu_ras_debugfs_create_all(struct amdgpu_device 
*adev)
amdgpu_ras_debugfs_create(adev, &fs_info);
}
}
-#endif
 }
 
-void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev,
+static void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev,
struct ras_common_if *head)
 {
struct ras_manager *obj = amdgpu_ras_find_obj(adev, head);
@@ -1229,7 +1227,6 @@ void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev,
 
 static void amdgpu_ras_debugfs_remove_all(struct amdgpu_device *adev)
 {
-#if defined(CONFIG_DEBUG_FS)
struct amdgpu_ras *con = amdgpu_ras_get_context(adev);
struct ras_manager *obj, *tmp;
 
@@ -1238,7 +1235,6 @@ static void amdgpu_ras_debugfs_remove_all(struct 
amdgpu_device *adev)
}
 
con->dir = NULL;
-#endif
 }
 /* debugfs end */
 
@@ -1286,7 +1282,8 @@ static int amdgpu_ras_fs_init(struct amdgpu_device *adev)
 
 static int amdgpu_ras_fs_fini(struct amdgpu_device *adev)
 {
-   amdgpu_ras_debugfs_remove_all(adev);
+   if (IS_ENABLED(CONFIG_DEBUG_FS))
+   amdgpu_ras_debugfs_remove_all(adev);
amdgpu_ras_sysfs_remove_all(adev);
return 0;
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
index 4667cce38582..762f5e46c007 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
@@ -592,14 +592,8 @@ int amdgpu_ras_sysfs_create(struct amdgpu_device *adev,
 int amdgpu_ras_sysfs_remove(struct amdgpu_device *adev,
struct ras_common_if *head);
 
-void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
-   struct ras_fs_if *head);
-
 void amdgpu_ras_debugfs_create_all(struct amdgpu_device *adev);
 
-void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev,
-   struct ras_common_if *head);
-
 int amdgpu_ras_error_query(struct amdgpu_device *adev,
struct ras_query_if *info);
 
-- 
2.27.0

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

Re: [PATCH drm/hisilicon 2/3] drm/irq: Add the new api to install irq

[Sam Ravnborg]

Hi Tian,

> > +   ret = devm_add_action_or_reset(dev->dev, devm_drm_irq_uninstall, dev);
> > +   if (ret)
> > +   devm_drm_irq_uninstall(dev);
> devm_add_action_or_reset() will call devm_drm_irq_uninstall() if ret is
> != 0. See include/device.h.
> 
> I guess that is the "_or_reset" part of the name that can tell us that.
> So you can drop the if condition as it just will cause the code to call
> drm_irq_uninstall() twice.

Noticed this was fixed in v2 - so all is fine here.

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

[Bug 209123] Bogus possible_crtcs: [ENCODER:58:TMDS-58] possible_crtcs=0xf (full crtc mask=0x7)

[bugzilla-daemon]

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

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) ---
Created attachment 293927
  --> https://bugzilla.kernel.org/attachment.cgi?id=293927&action=edit
possible fix

The warning is harmless, but I think this patch should fix it.

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

Re: [PATCH v3 6/7] drm: Validate encoder->possible_crtcs

[Alex Deucher]

On Tue, Sep 29, 2020 at 4:04 PM Alex Deucher  wrote:
>
> On Tue, Sep 29, 2020 at 8:31 AM Jan Kiszka  wrote:
> >
> > On 10.09.20 20:18, Deucher, Alexander wrote:
> > > [AMD Public Use]
> > >
> > >
> > >
> > >> -Original Message-
> > >> From: amd-gfx  On Behalf Of
> > >> Daniel Vetter
> > >> Sent: Monday, September 7, 2020 3:15 AM
> > >> To: Jan Kiszka ; amd-gfx list  > >> g...@lists.freedesktop.org>; Wentland, Harry ;
> > >> Kazlauskas, Nicholas 
> > >> Cc: dri-devel ; intel-gfx  > >> g...@lists.freedesktop.org>; Thomas Zimmermann
> > >> ; Ville Syrjala 
> > >> Subject: Re: [PATCH v3 6/7] drm: Validate encoder->possible_crtcs
> > >>
> > >> On Sun, Sep 6, 2020 at 1:19 PM Jan Kiszka  wrote:
> > >>>
> > >>> On 11.02.20 18:04, Daniel Vetter wrote:
> >  On Tue, Feb 11, 2020 at 06:22:07PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > >
> > > WARN if the encoder possible_crtcs is effectively empty or contains
> > > bits for non-existing crtcs.
> > >
> > > v2: Move to drm_mode_config_validate() (Daniel)
> > > Make the docs say we WARN when this is wrong (Daniel)
> > > Extract full_crtc_mask()
> > >
> > > Cc: Thomas Zimmermann 
> > > Cc: Daniel Vetter 
> > > Signed-off-by: Ville Syrjälä 
> > 
> >  When pushing the fixup needs to be applied before the validation
> >  patch here, because we don't want to anger the bisect gods.
> > 
> >  Reviewed-by: Daniel Vetter 
> > 
> >  I think with the fixup we should be good enough with the existing
> >  nonsense in drivers. Fingers crossed.
> >  -Daniel
> > 
> > 
> > > ---
> > >  drivers/gpu/drm/drm_mode_config.c | 27
> > >> ++-
> > >  include/drm/drm_encoder.h |  2 +-
> > >  2 files changed, 27 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > > b/drivers/gpu/drm/drm_mode_config.c
> > > index afc91447293a..4c1b350ddb95 100644
> > > --- a/drivers/gpu/drm/drm_mode_config.c
> > > +++ b/drivers/gpu/drm/drm_mode_config.c
> > > @@ -581,6 +581,29 @@ static void
> > >> validate_encoder_possible_clones(struct drm_encoder *encoder)
> > >   encoder->possible_clones, encoder_mask);  }
> > >
> > > +static u32 full_crtc_mask(struct drm_device *dev) {
> > > +struct drm_crtc *crtc;
> > > +u32 crtc_mask = 0;
> > > +
> > > +drm_for_each_crtc(crtc, dev)
> > > +crtc_mask |= drm_crtc_mask(crtc);
> > > +
> > > +return crtc_mask;
> > > +}
> > > +
> > > +static void validate_encoder_possible_crtcs(struct drm_encoder
> > > +*encoder) {
> > > +u32 crtc_mask = full_crtc_mask(encoder->dev);
> > > +
> > > +WARN((encoder->possible_crtcs & crtc_mask) == 0 ||
> > > + (encoder->possible_crtcs & ~crtc_mask) != 0,
> > > + "Bogus possible_crtcs: "
> > > + "[ENCODER:%d:%s] possible_crtcs=0x%x (full crtc 
> > > mask=0x%x)\n",
> > > + encoder->base.id, encoder->name,
> > > + encoder->possible_crtcs, crtc_mask); }
> > > +
> > >  void drm_mode_config_validate(struct drm_device *dev)  {
> > >  struct drm_encoder *encoder;
> > > @@ -588,6 +611,8 @@ void drm_mode_config_validate(struct
> > >> drm_device *dev)
> > >  drm_for_each_encoder(encoder, dev)
> > >  fixup_encoder_possible_clones(encoder);
> > >
> > > -drm_for_each_encoder(encoder, dev)
> > > +drm_for_each_encoder(encoder, dev) {
> > >  validate_encoder_possible_clones(encoder);
> > > +validate_encoder_possible_crtcs(encoder);
> > > +}
> > >  }
> > > diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
> > > index 3741963b9587..b236269f41ac 100644
> > > --- a/include/drm/drm_encoder.h
> > > +++ b/include/drm/drm_encoder.h
> > > @@ -142,7 +142,7 @@ struct drm_encoder {
> > >   * the bits for all &drm_crtc objects this encoder can be 
> > > connected to
> > >   * before calling drm_dev_register().
> > >   *
> > > - * In reality almost every driver gets this wrong.
> > > + * You will get a WARN if you get this wrong in the driver.
> > >   *
> > >   * Note that since CRTC objects can't be hotplugged the assigned
> > >> indices
> > >   * are stable and hence known before registering all objects.
> > > --
> > > 2.24.1
> > >
> > 
> > >>>
> > >>> Triggers on an Advantech AIMB-228 (R1505G, 3 DP outputs):
> > >>
> > >> Adding amdgpu display folks.
> > >
> > > I took a quick look at this and it looks like we limit the number of 
> > > crtcs later in the mode init process if the number of physical displays 
> > > can't actually use more crtcs.  E.g., the physical board configuration 
> > > would only allow for 3 active displays even if the h

[Bug 210467] amdgpu Vega 3 lock MCLK on 1200mhz

[bugzilla-daemon]

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

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) ---
Created attachment 293925
  --> https://bugzilla.kernel.org/attachment.cgi?id=293925&action=edit
possible warning fix

The warning in the log is harmless, but this patch should fix it.

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

Re: [PATCH v4 0/2] drm: add DisplayPort connector

[Sam Ravnborg]

Hi Tomi,
On Thu, Dec 03, 2020 at 01:52:21PM +0200, Tomi Valkeinen wrote:
> Hi DRM Bridge maintainers,
> 
> On 30/11/2020 13:29, Tomi Valkeinen wrote:
> > Hi,
> > 
> > This series adds the DT bindings and a driver for DisplayPort connector.
> > 
> > Minor changes since v3:
> > - Added Laurent's reviewed-bys
> > - Added $ref to graph schema
> > - Use 'ret' instead of 'r'
> > - Add the missing period
> > 
> >  Tomi
> > 
> > Tomi Valkeinen (2):
> >   dt-bindings: dp-connector: add binding for DisplayPort connector
> >   drm/bridge: display-connector: add DP support
> > 
> >  .../display/connector/dp-connector.yaml   | 56 +++
> >  drivers/gpu/drm/bridge/display-connector.c| 46 ++-
> >  2 files changed, 100 insertions(+), 2 deletions(-)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/connector/dp-connector.yaml
> > 
> 
> Is it ok for me to push this to drm-misc-next, or does one of the bridge 
> maintainers want to handle
> that?

IMO apply them to drm-misc-next.
But I am not bridge maintainer so...

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

Re: [PATCH] drm/vkms: Add setup and testing information

[Daniel Vetter]

On Thu, Dec 3, 2020 at 8:13 PM Sumera Priyadarsini
 wrote:
>
> Update the vkms documentation to contain steps to:
>
>  - setup the vkms driver
>  - run tests using igt
>
> Signed-off-by: Sumera Priyadarsini 
> ---
>  Documentation/gpu/vkms.rst | 47 ++
>  1 file changed, 47 insertions(+)
>
> diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
> index 13bab1d93bb3..d6782174d23f 100644
> --- a/Documentation/gpu/vkms.rst
> +++ b/Documentation/gpu/vkms.rst
> @@ -7,6 +7,53 @@
>  .. kernel-doc:: drivers/gpu/drm/vkms/vkms_drv.c
> :doc: vkms (Virtual Kernel Modesetting)
>
> +SETUP

Absolute bikeshed, but we generally stick to titlecase for titles, so
just "Setup" and "Testing with IGT".
> +=
> +
> +The VKMS driver can be setup with the following steps:
> +
> +To check if VKMS is loaded, run::
> +
> +  lsmod | grep vkms
> +
> +This should list the VKMS driver. If no output is obtained, then
> +you need to enable and/or load the VKMS driver.
> +Ensure that the VKMS driver has been set as a loadable module in your
> +kernel config file. The following line should be present in the .config
> +file in your kernel root::
> +
> +  CONFIG_DRM_VKMS=m
> +
> +Compile and build the kernel for the changes to get reflected.
> +If your existing config already has VKMS available as a loadable module,
> +then there is no need to build the kernel again.
> +Now, to load the driver, use::
> +
> +  sudo modprobe vkms
> +
> +On running the lsmod command now, the VKMS driver will appear listed.
> +You can also observe the driver being loaded in the dmesg logs.
> +
> +To disable the driver, use ::
> +
> +  sudo modprobe -r vkms
> +
> +TESTING WITH IGT
> +
> +
> +The IGT GPU Tools is a test suite used specifically for debugging and
> +development of the DRM drivers.
> +The IGT Tools can be installed from
> +`here `_ .
> +Once you have installed IGT, you can run tests using::
> +
> +  ./scripts/run-tests.sh -t 
> +
> +For example, to test the functionality of the igt_draw library,
> +we can run the kms_draw_crc test::
> +
> +  ./scripts/run-tests.sh -t kms_draw_crc

If we run igt tests directly, there's an option to select the right
device. This is important if you have more than one gpu driver
(usually the case if you run this directly, but even on virtual
machines there should usually be a drm driver around).  E.g. when I
run a test directly:

# tests/kms_flip --device drm:/dev/dri/card0

I'm not sure whether there's an option that's always going to select
the vkms device. I'm also not sure you can pass these options to
run-tests.sh, I kinda don't use that one myself ...

Aside from that looks all good to me.
-Daniel

> +
>  TODO
>  
>
> --
> 2.25.1
>


-- 
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] drm: Fix drm.h uapi header for Windows

[Daniel Vetter]

On Thu, Dec 3, 2020 at 7:55 PM James Park  wrote:
>
> The trailing underscore for  DRM_FOURCC_STANDALONE_ isn't intentional, right? 
> Should I put all the integer types, or just the ones that are used in that 
> file?

Yeah that trailing _ just slipped in. And I'd just do the types
already used. I don't think anything else than __u32 (for drm fourcc)
and __u64 (for drm modifier) is needed.
-Daniel

>
> Thanks,
> James
>
> On Thu, Dec 3, 2020 at 6:52 AM Daniel Vetter  wrote:
>>
>> On Thu, Dec 3, 2020 at 9:18 AM Michel Dänzer  wrote:
>> >
>> > On 2020-12-02 8:47 p.m., James Park wrote:
>> > >
>> > > If we're trying to cut ties with the drm-uapi folder entirely, the stuff
>> > > ac_surface.c need includes the AMD_FMT_MOD stuff in drm_fourcc.h,
>> > > and AMDGPU_TILING_* under amdgpu_drm.h. Is there a better spot for these
>> > > definitions?
>> >
>> > The Mesa src/amd/ code should use platform-neutral abstractions for
>> > these. This wasn't deemed necessary before, because nobody was trying to
>> > build these drivers for non-UNIX OSes. But now you are.
>>
>> I think that's a bit much busy work for not much gain. drm_fourcc.h is
>> even included as the official source of truth of some khr extensions,
>> making that header stand-alone and useable cross-platform sounds like
>> a good idea to me. Something like the below is imo perfectly fine:
>>
>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>> index ca48ed0e6bc1..0a121b3efb58 100644
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -24,7 +24,11 @@
>> #ifndef DRM_FOURCC_H
>> #define DRM_FOURCC_H
>>
>> +#ifndef DRM_FOURCC_STANDALONE_
>> +/* include the linux uapi types here */
>> +#else
>> #include "drm.h"
>> +#endif
>>
>> #if defined(__cplusplus)
>> extern "C" {
>>
>>
>> Cheers, Daniel
>>
>> >
>> >
>> > --
>> > Earthling Michel Dänzer   |   https://redhat.com
>> > Libre software enthusiast | Mesa and X developer
>> > ___
>> > 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



-- 
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 v2 7/7] dma-buf: Write down some rules for vmap usage

[Daniel Vetter]

On Thu, Dec 03, 2020 at 07:59:04PM +0100, Thomas Zimmermann wrote:
> Hi
> 
> Am 03.12.20 um 16:26 schrieb Daniel Vetter:
> > On Thu, Dec 03, 2020 at 03:02:59PM +0100, Thomas Zimmermann wrote:
> > > Dma-buf's vmap and vunmap callbacks are undocumented and various
> > > exporters currently have slightly different semantics for them. Add
> > > documentation on how to implement and use these interfaces correctly.
> > > 
> > > v2:
> > >   * document vmap semantics in struct dma_buf_ops
> > >   * add TODO item for reviewing and maybe fixing dma-buf exporters
> > > 
> > > Signed-off-by: Thomas Zimmermann 
> > 
> > I still don't think this works, we're breaking dma_buf_vmap for everyone
> > else here.
> 
> I removed the text on the importer. These notes for callers in the docs are
> more or less a consequence of the exporter semantics.

Callers are importers, so I'm not seeing how that fixes anything.

> I thought we at least agreed on the exporter semantics in the other thread,
> didn't we?
> 
> What I'm trying to do is to write dome some rules for exporters, even if not
> all exporters follow them.

This is a standard interface, everyone needs to follow the same rules. And
if they change, we need to make sure nothing breaks and we're not creating
issues.

In the past the rule was the dma_buf_vmap was allowed to take the
dma_resv_lock, and that the buffer should be pinned. Now some ttm drivers
didn't ever bother with the pinning, and mostly got away with that because
drm_prime helpers do the pinning by default at attach time, and most users
do call dma_buf_attach.

But if you look through dma-buf docs nothing ever said you have to do a
dummy attachment before you call dma_buf_vmap, that's just slightly crappy
implementations that didn't blow up yet.

> Given the circumstances, we should leave out this patch from the patchset.

So the defacto rules are already a big mess, but that's not a good excuse
to make it worse.

What I had in mind is that we split dma_buf_vmap up into two variants:

- The current one, which should guarantee that the buffer is pinned.
  Because that's what all current callers wanted, before the fbdev code
  started allowing non-pinned buffers.

- The new one, which allows vmapping with just dma_resv locked, and should
  have some caching in exporters.

Breaking code and then adding todos about that is kinda not so cool
approach here imo.

Also I guess ttm_bo_vmap should have a check that either the buffer is
pinned, or dma_resv_lock is held.

Cheers, Daniel



> 
> Best regards
> Thomas
> 
> > 
> > > ---
> > >   Documentation/gpu/todo.rst | 15 +
> > >   include/drm/drm_gem.h  |  4 
> > >   include/linux/dma-buf.h| 45 ++
> > >   3 files changed, 64 insertions(+)
> > > 
> > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > > index 009d8e6c7e3c..32bb797a84fc 100644
> > > --- a/Documentation/gpu/todo.rst
> > > +++ b/Documentation/gpu/todo.rst
> > > @@ -505,6 +505,21 @@ Contact: Thomas Zimmermann , 
> > > Christian König, Daniel Vette
> > >   Level: Intermediate
> > > +Enforce rules for dma-buf vmap and pin ops
> > > +--
> > > +
> > > +Exporter implementations of vmap and pin in struct dma_buf_ops (and 
> > > consequently
> > > +struct drm_gem_object_funcs) use a variety of locking semantics. Some 
> > > rely on
> > > +the caller holding the dma-buf's reservation lock, some do their own 
> > > locking,
> > > +some don't require any locking. VRAM helpers even used to pin as part of 
> > > vmap.
> > > +
> > > +We need to review each exporter and enforce the documented rules.
> > > +
> > > +Contact: Christian König, Daniel Vetter, Thomas Zimmermann 
> > > 
> > > +
> > > +Level: Advanced
> > > +
> > > +
> > >   Core refactorings
> > >   =
> > > diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> > > index 5e6daa1c982f..1864c6a721b1 100644
> > > --- a/include/drm/drm_gem.h
> > > +++ b/include/drm/drm_gem.h
> > > @@ -138,6 +138,8 @@ struct drm_gem_object_funcs {
> > >* drm_gem_dmabuf_vmap() helper.
> > >*
> > >* This callback is optional.
> > > +  *
> > > +  * See also struct dma_buf_ops.vmap
> > >*/
> > >   int (*vmap)(struct drm_gem_object *obj, struct dma_buf_map 
> > > *map);
> > > @@ -148,6 +150,8 @@ struct drm_gem_object_funcs {
> > >* drm_gem_dmabuf_vunmap() helper.
> > >*
> > >* This callback is optional.
> > > +  *
> > > +  * See also struct dma_buf_ops.vunmap
> > >*/
> > >   void (*vunmap)(struct drm_gem_object *obj, struct dma_buf_map 
> > > *map);
> > > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > > index cf72699cb2bc..dc81fdc01dda 100644
> > > --- a/include/linux/dma-buf.h
> > > +++ b/include/linux/dma-buf.h
> > > @@ -267,7 +267,52 @@ struct dma_buf_ops {
> > >*/
> > >   int (*mmap)(struct d

Re: [PATCH] Revert "i2c: qcom-geni: Disable DMA processing on the Lenovo Yoga C630"

[Wolfram Sang]

On Tue, Nov 24, 2020 at 12:57:43PM -0600, Bjorn Andersson wrote:
> A combination of recent bug fixes by Doug Anderson and the proper
> definition of iommu streams means that this hack is no longer needed.
> Let's clean up the code by reverting '127068abe85b ("i2c: qcom-geni:
> Disable DMA processing on the Lenovo Yoga C630")'.
> 
> Signed-off-by: Bjorn Andersson 
> ---

Added another ack from Caleb and applied to for-next, thanks!



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

Re: [PATCH drm/hisilicon 2/3] drm/irq: Add the new api to install irq

[Sam Ravnborg]

Hi Tian.

On Wed, Dec 02, 2020 at 04:47:14PM +0800, Tian Tao wrote:
> Add new api devm_drm_irq_install() to register interrupts,
> no need to call drm_irq_uninstall() when the drm module is removed.
> 
> Signed-off-by: Tian Tao 

Just a few details to fix.

Sam

> ---
>  drivers/gpu/drm/drm_irq.c | 35 +++
>  include/drm/drm_irq.h |  2 +-
>  2 files changed, 36 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 09d6e9e..b363dec 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -214,6 +214,41 @@ int drm_irq_uninstall(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_irq_uninstall);
>  
> +static void devm_drm_irq_uninstall(void *data)
> +{
> + drm_irq_uninstall(data);
> +}
> +
> +/**
> + * devm_drm_irq_install - install IRQ handler
> + * @dev: DRM device
> + * @irq: IRQ number to install the handler for
> + *
> + * devm_drm_irq_install is a  help function of drm_irq_install.
Drop the extra space after "is a"
> + *
> + * if the driver uses devm_drm_irq_install, there is no need
Start with capital "I" in If
> + * to call drm_irq_uninstall when the drm module get unloaded,
> + * as this will done automagically.
> + *
> + * Returns:
> + * Zero on success or a negative error code on failure.
> + */
> +int devm_drm_irq_install(struct drm_device *dev, int irq)
> +{
> + int ret;
> +
> + ret = drm_irq_install(dev, irq);
> + if (ret)
> + return ret;
> +
> + ret = devm_add_action_or_reset(dev->dev, devm_drm_irq_uninstall, dev);
> + if (ret)
> + devm_drm_irq_uninstall(dev);
devm_add_action_or_reset() will call devm_drm_irq_uninstall() if ret is
!= 0. See include/device.h.

I guess that is the "_or_reset" part of the name that can tell us that.
So you can drop the if condition as it just will cause the code to call
drm_irq_uninstall() twice.

> +
> + return ret;
> +}
> +EXPORT_SYMBOL(devm_drm_irq_install);
> +
>  #if IS_ENABLED(CONFIG_DRM_LEGACY)
>  int drm_legacy_irq_control(struct drm_device *dev, void *data,
>  struct drm_file *file_priv)
> diff --git a/include/drm/drm_irq.h b/include/drm/drm_irq.h
> index d77f6e6..631b22f 100644
> --- a/include/drm/drm_irq.h
> +++ b/include/drm/drm_irq.h
> @@ -28,5 +28,5 @@ struct drm_device;
>  
>  int drm_irq_install(struct drm_device *dev, int irq);
>  int drm_irq_uninstall(struct drm_device *dev);
> -
> +int devm_drm_irq_install(struct drm_device *dev, int irq);
>  #endif
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 94061] [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst

[bugzilla-daemon]

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

--- Comment #12 from mirh (m...@protonmail.ch) ---
I see that [amdgpu_]kv_smc_bapm_enable is equivalent, but the condition
guarding it seems quite different. 

Then I'm not really pretending to understand much else about the two kv_dpms.

-- 
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] drm/vkms: Add setup and testing information

[Sumera Priyadarsini]

Update the vkms documentation to contain steps to:

 - setup the vkms driver
 - run tests using igt

Signed-off-by: Sumera Priyadarsini 
---
 Documentation/gpu/vkms.rst | 47 ++
 1 file changed, 47 insertions(+)

diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 13bab1d93bb3..d6782174d23f 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -7,6 +7,53 @@
 .. kernel-doc:: drivers/gpu/drm/vkms/vkms_drv.c
:doc: vkms (Virtual Kernel Modesetting)
 
+SETUP
+=
+
+The VKMS driver can be setup with the following steps:
+
+To check if VKMS is loaded, run::
+
+  lsmod | grep vkms
+
+This should list the VKMS driver. If no output is obtained, then
+you need to enable and/or load the VKMS driver.
+Ensure that the VKMS driver has been set as a loadable module in your
+kernel config file. The following line should be present in the .config
+file in your kernel root::
+
+  CONFIG_DRM_VKMS=m
+
+Compile and build the kernel for the changes to get reflected.
+If your existing config already has VKMS available as a loadable module,
+then there is no need to build the kernel again.
+Now, to load the driver, use::
+
+  sudo modprobe vkms
+
+On running the lsmod command now, the VKMS driver will appear listed.
+You can also observe the driver being loaded in the dmesg logs.
+
+To disable the driver, use ::
+
+  sudo modprobe -r vkms
+
+TESTING WITH IGT
+
+
+The IGT GPU Tools is a test suite used specifically for debugging and
+development of the DRM drivers.
+The IGT Tools can be installed from
+`here `_ .
+Once you have installed IGT, you can run tests using::
+
+  ./scripts/run-tests.sh -t 
+
+For example, to test the functionality of the igt_draw library,
+we can run the kms_draw_crc test::
+
+  ./scripts/run-tests.sh -t kms_draw_crc
+
 TODO
 
 
-- 
2.25.1

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

Re: [PATCH v2 7/7] dma-buf: Write down some rules for vmap usage

[Thomas Zimmermann]

Hi

Am 03.12.20 um 16:26 schrieb Daniel Vetter:

On Thu, Dec 03, 2020 at 03:02:59PM +0100, Thomas Zimmermann wrote:

Dma-buf's vmap and vunmap callbacks are undocumented and various
exporters currently have slightly different semantics for them. Add
documentation on how to implement and use these interfaces correctly.

v2:
* document vmap semantics in struct dma_buf_ops
* add TODO item for reviewing and maybe fixing dma-buf exporters

Signed-off-by: Thomas Zimmermann 


I still don't think this works, we're breaking dma_buf_vmap for everyone
else here.


I removed the text on the importer. These notes for callers in the docs 
are more or less a consequence of the exporter semantics.


I thought we at least agreed on the exporter semantics in the other 
thread, didn't we?


What I'm trying to do is to write dome some rules for exporters, even if 
not all exporters follow them.


Given the circumstances, we should leave out this patch from the patchset.

Best regards
Thomas




---
  Documentation/gpu/todo.rst | 15 +
  include/drm/drm_gem.h  |  4 
  include/linux/dma-buf.h| 45 ++
  3 files changed, 64 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 009d8e6c7e3c..32bb797a84fc 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -505,6 +505,21 @@ Contact: Thomas Zimmermann , 
Christian König, Daniel Vette
  Level: Intermediate
  
  
+Enforce rules for dma-buf vmap and pin ops

+--
+
+Exporter implementations of vmap and pin in struct dma_buf_ops (and 
consequently
+struct drm_gem_object_funcs) use a variety of locking semantics. Some rely on
+the caller holding the dma-buf's reservation lock, some do their own locking,
+some don't require any locking. VRAM helpers even used to pin as part of vmap.
+
+We need to review each exporter and enforce the documented rules.
+
+Contact: Christian König, Daniel Vetter, Thomas Zimmermann 

+
+Level: Advanced
+
+
  Core refactorings
  =
  
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h

index 5e6daa1c982f..1864c6a721b1 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -138,6 +138,8 @@ struct drm_gem_object_funcs {
 * drm_gem_dmabuf_vmap() helper.
 *
 * This callback is optional.
+*
+* See also struct dma_buf_ops.vmap
 */
int (*vmap)(struct drm_gem_object *obj, struct dma_buf_map *map);
  
@@ -148,6 +150,8 @@ struct drm_gem_object_funcs {

 * drm_gem_dmabuf_vunmap() helper.
 *
 * This callback is optional.
+*
+* See also struct dma_buf_ops.vunmap
 */
void (*vunmap)(struct drm_gem_object *obj, struct dma_buf_map *map);
  
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h

index cf72699cb2bc..dc81fdc01dda 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -267,7 +267,52 @@ struct dma_buf_ops {
 */
int (*mmap)(struct dma_buf *, struct vm_area_struct *vma);
  
+	/**

+* @vmap:


There's already a @vmap and @vunamp kerneldoc at the top comment, that
needs to be removed.
-Daniel


+*
+* Returns a virtual address for the buffer.
+*
+* Notes to callers:
+*
+* - Callers must hold the struct dma_buf.resv lock before calling
+*   this interface.
+*
+* - Callers must provide means to prevent the mappings from going
+*   stale, such as holding the reservation lock or providing a
+*   move-notify callback to the exporter.
+*
+* Notes to implementors:
+*
+* - Implementations must expect pairs of @vmap and @vunmap to be
+*   called frequently and should optimize for this case.
+*
+* - Implementations should avoid additional operations, such as
+*   pinning.
+*
+* - Implementations may expect the caller to hold the dma-buf's
+*   reservation lock to protect against concurrent calls and
+*   relocation.
+*
+* - Implementations may provide additional guarantees, such as working
+*   without holding the reservation lock.
+*
+* This callback is optional.
+*
+* Returns:
+*
+* 0 on success or a negative error code on failure.
+*/
int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
+
+   /**
+* @vunmap:
+*
+* Releases the address previously returned by @vmap.
+*
+* This callback is optional.
+*
+* See also @vmap()
+*/
void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
  };
  
--

2.29.2





--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäfts

[Bug 210479] amdgpu: Monitor connected to RX 6800XT loses signal when module is loaded

[bugzilla-daemon]

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

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) ---
It looks like you don't have support for the display hardware configured in
your kernel config.  Make sure your config has:
CONFIG_DRM_AMD_DC=y
CONFIG_DRM_AMD_DC_DCN=y
CONFIG_DRM_AMD_DC_DCN3_0=y

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

[Bug 94061] [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst

[bugzilla-daemon]

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

--- Comment #11 from Alex Deucher (alexdeuc...@gmail.com) ---
The dpm code for kaveri is identical for both radeon and amdgpu.

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

Re: [PATCH V3 1/2] dt-bindings: Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge

[Dave Stevenson]

Hi Marek

On Wed, 12 Aug 2020 at 21:07, Sam Ravnborg  wrote:
>
> Hi Marek.
>
> On Sun, Aug 09, 2020 at 12:57:04PM +0200, Marek Vasut wrote:
> > Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge, this
> > one is used in the Raspberry Pi 7" touchscreen display unit.
> >
> > Signed-off-by: Marek Vasut 
> > To: dri-devel@lists.freedesktop.org
> > Cc: Eric Anholt 
> > Cc: Rob Herring 
> > Cc: Sam Ravnborg 
> > Cc: devicet...@vger.kernel.org
> > ---
> > V2: Fix dt_binding_check errors
> > V3: Add ... at the end of example
>
> With Rob's r-b it is now applied to drm-misc-next.
>
> Sam
>
> > ---
> >  .../display/bridge/toshiba,tc358762.yaml  | 127 ++
> >  1 file changed, 127 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml 
> > b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
> > new file mode 100644
> > index ..195025e6803c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
> > @@ -0,0 +1,127 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358762.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Toshiba TC358762 MIPI DSI to MIPI DPI bridge
> > +
> > +maintainers:
> > +  - Marek Vasut 
> > +
> > +description: |
> > +  The TC358762 is bridge device which converts MIPI DSI to MIPI DPI.
> > +
> > +properties:
> > +  compatible:
> > +enum:
> > +  - toshiba,tc358762
> > +
> > +  reg:
> > +maxItems: 1
> > +description: virtual channel number of a DSI peripheral
> > +
> > +  vddc-supply:
> > +description: Regulator for 1.2V internal core power.
> > +
> > +  ports:
> > +type: object
> > +
> > +properties:
> > +  "#address-cells":
> > +const: 1
> > +
> > +  "#size-cells":
> > +const: 0
> > +
> > +  port@0:
> > +type: object
> > +additionalProperties: false
> > +
> > +description: |
> > +  Video port for MIPI DSI input
> > +
> > +properties:
> > +  reg:
> > +const: 0
> > +
> > +patternProperties:
> > +  endpoint:
> > +type: object
> > +additionalProperties: false
> > +
> > +properties:
> > +  remote-endpoint: true
> > +
> > +required:
> > +  - reg
> > +
> > +  port@1:
> > +type: object
> > +additionalProperties: false
> > +
> > +description: |
> > +  Video port for MIPI DPI output (panel or connector).
> > +
> > +properties:
> > +  reg:
> > +const: 1
> > +
> > +patternProperties:
> > +  endpoint:
> > +type: object
> > +additionalProperties: false
> > +
> > +properties:
> > +  remote-endpoint: true
> > +
> > +required:
> > +  - reg
> > +
> > +required:
> > +  - "#address-cells"
> > +  - "#size-cells"
> > +  - port@0
> > +  - port@1
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - vddc-supply
> > +  - ports
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +i2c1 {

Minor point.
I've just come to use this and noticed that this example puts the
device under i2c1. Seeing as it's a DSI driver with no I2C
interaction, shouldn't it be under a dsi node?

Thanks
  Dave

> > +  #address-cells = <1>;
> > +  #size-cells = <0>;
> > +
> > +  bridge@0 {
> > +reg = <0>;
> > +compatible = "toshiba,tc358762";
> > +vddc-supply = <&vcc_1v2_reg>;
> > +
> > +ports {
> > +  #address-cells = <1>;
> > +  #size-cells = <0>;
> > +
> > +  port@0 {
> > +reg = <0>;
> > +bridge_in: endpoint {
> > +  remote-endpoint = <&dsi_out>;
> > +};
> > +  };
> > +
> > +  port@1 {
> > +reg = <1>;
> > +bridge_out: endpoint {
> > +  remote-endpoint = <&panel_in>;
> > +};
> > +  };
> > +};
> > +  };
> > +};
> > +
> > +...
> > --
> > 2.28.0
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 94061] [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst

[bugzilla-daemon]

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

mirh (m...@protonmail.ch) changed:

   What|Removed |Added

 CC||m...@protonmail.ch

--- Comment #10 from mirh (m...@protonmail.ch) ---
Stable kernels are stable exactly because you don't backport too much sensitive
cruft..

Anyway, while bapm is still disabled by default on radeon on kaveri, am I right
to understand that if you switch to amdgpu it's good to go?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c?h=v5.10-rc6#n2833

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

[Bug 78111] APU turbo core boost not working when radeon.dpm=1

[bugzilla-daemon]

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

mirh (m...@protonmail.ch) changed:

   What|Removed |Added

 CC||m...@protonmail.ch

--- Comment #14 from mirh (m...@protonmail.ch) ---
OP has a Temash/Kabini APU, that afaict has bapm enabled by default since 3.16. 

Can this be closed?

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

[Bug 210479] New: amdgpu: Monitor connected to RX 6800XT loses signal when module is loaded

[bugzilla-daemon]

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

Bug ID: 210479
   Summary: amdgpu: Monitor connected to RX 6800XT loses signal
when module is loaded
   Product: Drivers
   Version: 2.5
Kernel Version: 5.10.0-rc6
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: alaps...@fastmail.com
Regression: No

Created attachment 293923
  --> https://bugzilla.kernel.org/attachment.cgi?id=293923&action=edit
Journalctl output

When monitor is connected to RX 6800XT gpu it loses its signal as soon as
amgdpu module is loaded from initrd.

However system itself is working, I can enter LUKS password and connect via
ssh.
Adding nomodeset kernel parameter allows to see boot progress but Xserver can't
be started and user is redirected to console login prompt.

Additional info
1. This monitor works fine with same setup (hardware/OS) with Nvidia GPU and
modesetting driver.
2. This situation occurs regardless how monitor is connected (DisplayPort or
HDMI)
3. This situation also occurs with different monitor as well.
4. This GPU seems to work fine under Windows installed on same hardware.

lspci -nvv output:

2d:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Device [1002:73bf] (rev c1) (prog-if 00 [VGA controller])
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Device [1002:0e3a]
Flags: bus master, fast devsel, latency 0, IRQ 43, IOMMU group 2
Memory at 78 (64-bit, prefetchable) [size=16G]
Memory at 7c (64-bit, prefetchable) [size=256M]
I/O ports at e000 [size=256]
Memory at fc70 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at fc80 [disabled] [size=128K]
Capabilities: 
Kernel driver in use: amdgpu
Kernel modules: amdgpu

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

[PATCH v5] drm/bridge: tfp410: Set input_bus_flags in atomic_check

[Nikhil Devshatwar]

input_bus_flags are specified in drm_bridge_timings (legacy) as well
as drm_bridge_state->input_bus_cfg.flags

The flags from the timings will be deprecated. Bridges are supposed
to validate and set the bridge state flags from atomic_check.

Implement atomic_check hook for the same.

Signed-off-by: Nikhil Devshatwar 
---

Notes:
changes from v4:
* fix a warning Reported-by: kernel test robot 

 drivers/gpu/drm/bridge/ti-tfp410.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
b/drivers/gpu/drm/bridge/ti-tfp410.c
index 3def9acba86b..92963d12106b 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -233,6 +233,20 @@ static u32 *tfp410_get_input_bus_fmts(struct drm_bridge 
*bridge,
return input_fmts;
 }
 
+static int tfp410_atomic_check(struct drm_bridge *bridge,
+   struct drm_bridge_state *bridge_state,
+   struct drm_crtc_state *crtc_state,
+   struct drm_connector_state *conn_state)
+{
+   struct tfp410 *dvi = drm_bridge_to_tfp410(bridge);
+
+   /*
+* There might be flags negotiation supported in future
+* Set the bus flags in atomic_check statically for now
+*/
+   bridge_state->input_bus_cfg.flags = dvi->timings.input_bus_flags;
+}
+
 static const struct drm_bridge_funcs tfp410_bridge_funcs = {
.attach = tfp410_attach,
.detach = tfp410_detach,
@@ -243,6 +257,7 @@ static const struct drm_bridge_funcs tfp410_bridge_funcs = {
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_get_input_bus_fmts = tfp410_get_input_bus_fmts,
+   .atomic_check = tfp410_atomic_check,
 };
 
 static const struct drm_bridge_timings tfp410_default_timings = {
-- 
2.17.1

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

Re: [PATCH] drm/fb-helper: Add missed unlocks in setcmap_legacy()

[Daniel Vetter]

On Thu, Dec 3, 2020 at 5:11 PM Peter Rosin  wrote:
>
> Hi!
>
> On 2020-12-03 15:42, Chuhong Yuan wrote:
> > setcmap_legacy() does not call drm_modeset_unlock_all() in some exits,
> > add the missed unlocks with goto to fix it.
> >
> > Fixes: 964c60063bff ("drm/fb-helper: separate the fb_setcmap helper into 
> > atomic and legacy paths")
> > Signed-off-by: Chuhong Yuan 
>
> Yup, my patch fumbled the locking. Sorry, and thanks for cleaning up my mess!
>
> Acked-by: Peter Rosin 
>
> (Spelled that as Ached-by at first, what does that mean??)

Merged already before I've seen your ack here (and we don't rebase so
can't add it now), thanks for the patch and all.
-Daniel

>
> Cheers,
> Peter
>
> > ---
> >  drivers/gpu/drm/drm_fb_helper.c | 15 ++-
> >  1 file changed, 10 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 1543d9d10970..8033467db4be 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -923,11 +923,15 @@ static int setcmap_legacy(struct fb_cmap *cmap, 
> > struct fb_info *info)
> >   drm_modeset_lock_all(fb_helper->dev);
> >   drm_client_for_each_modeset(modeset, &fb_helper->client) {
> >   crtc = modeset->crtc;
> > - if (!crtc->funcs->gamma_set || !crtc->gamma_size)
> > - return -EINVAL;
> > + if (!crtc->funcs->gamma_set || !crtc->gamma_size) {
> > + ret = -EINVAL;
> > + goto out;
> > + }
> >
> > - if (cmap->start + cmap->len > crtc->gamma_size)
> > - return -EINVAL;
> > + if (cmap->start + cmap->len > crtc->gamma_size) {
> > + ret = -EINVAL;
> > + goto out;
> > + }
> >
> >   r = crtc->gamma_store;
> >   g = r + crtc->gamma_size;
> > @@ -940,8 +944,9 @@ static int setcmap_legacy(struct fb_cmap *cmap, struct 
> > fb_info *info)
> >   ret = crtc->funcs->gamma_set(crtc, r, g, b,
> >crtc->gamma_size, NULL);
> >   if (ret)
> > - return ret;
> > + goto out;
> >   }
> > +out:
> >   drm_modeset_unlock_all(fb_helper->dev);
> >
> >   return ret;
> >



-- 
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 v2 1/5] drm: add legacy support for using degamma for gamma

[Tomi Valkeinen]

On 03/12/2020 14:31, Ville Syrjälä wrote:

> BTW I have some gamma related stuff here
> git://github.com/vsyrjala/linux.git fb_helper_c8_lut_4
> 
> which tries to fix some fb_helper gamma stuff, and I'm also
> getting rid of the gamma_store stuff for the leacy uapi for
> drivers which implement the fancier color management stuff.
> In fact I just threw out the helper thing entirely and made
> the core directly call the right stuff. Not sure if that
> would be helpful, harmful or just meh here.

I didn't check your branch yet, but I just sent "[PATCH 0/2] drm: fix and 
cleanup legacy gamma support".

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/3] drm/msm: adreno: Make speed-bin support generic

[Akhil P Oommen]

On 12/2/2020 10:00 PM, Jordan Crouse wrote:

On Wed, Dec 02, 2020 at 08:53:51PM +0530, Akhil P Oommen wrote:

On 11/30/2020 10:32 PM, Jordan Crouse wrote:

On Fri, Nov 27, 2020 at 06:19:44PM +0530, Akhil P Oommen wrote:

So far a530v2 gpu has support for detecting its supported opps
based on a fuse value called speed-bin. This patch makes this
support generic across gpu families. This is in preparation to
extend speed-bin support to a6x family.

Signed-off-by: Akhil P Oommen 
---
Changes from v1:
1. Added the changes to support a618 sku to the series.
2. Avoid failing probe in case of an unsupported sku. (Rob)

  drivers/gpu/drm/msm/adreno/a5xx_gpu.c  | 34 --
  drivers/gpu/drm/msm/adreno/adreno_device.c |  4 ++
  drivers/gpu/drm/msm/adreno/adreno_gpu.c| 71 ++
  drivers/gpu/drm/msm/adreno/adreno_gpu.h|  5 +++
  4 files changed, 80 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 8fa5c91..7d42321 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1531,38 +1531,6 @@ static const struct adreno_gpu_funcs funcs = {
.get_timestamp = a5xx_get_timestamp,
  };
-static void check_speed_bin(struct device *dev)
-{
-   struct nvmem_cell *cell;
-   u32 val;
-
-   /*
-* If the OPP table specifies a opp-supported-hw property then we have
-* to set something with dev_pm_opp_set_supported_hw() or the table
-* doesn't get populated so pick an arbitrary value that should
-* ensure the default frequencies are selected but not conflict with any
-* actual bins
-*/
-   val = 0x80;
-
-   cell = nvmem_cell_get(dev, "speed_bin");
-
-   if (!IS_ERR(cell)) {
-   void *buf = nvmem_cell_read(cell, NULL);
-
-   if (!IS_ERR(buf)) {
-   u8 bin = *((u8 *) buf);
-
-   val = (1 << bin);
-   kfree(buf);
-   }
-
-   nvmem_cell_put(cell);
-   }
-
-   dev_pm_opp_set_supported_hw(dev, &val, 1);
-}
-
  struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
  {
struct msm_drm_private *priv = dev->dev_private;
@@ -1588,8 +1556,6 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
a5xx_gpu->lm_leakage = 0x4E001A;
-   check_speed_bin(&pdev->dev);
-
ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 4);
if (ret) {
a5xx_destroy(&(a5xx_gpu->base.base));
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 87c8b03..e0ff16c 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -18,6 +18,8 @@ bool snapshot_debugbus = false;
  MODULE_PARM_DESC(snapshot_debugbus, "Include debugbus sections in GPU devcoredump 
(if not fused off)");
  module_param_named(snapshot_debugbus, snapshot_debugbus, bool, 0600);
+const u32 a530v2_speedbins[] = {0, 1, 2, 3, 4, 5, 6, 7};
+
  static const struct adreno_info gpulist[] = {
{
.rev   = ADRENO_REV(2, 0, 0, 0),
@@ -163,6 +165,8 @@ static const struct adreno_info gpulist[] = {
ADRENO_QUIRK_FAULT_DETECT_MASK,
.init = a5xx_gpu_init,
.zapfw = "a530_zap.mdt",
+   .speedbins = a530v2_speedbins,
+   .speedbins_count = ARRAY_SIZE(a530v2_speedbins),
}, {
.rev = ADRENO_REV(5, 4, 0, 2),
.revn = 540,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index f21561d..b342fa4 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -14,6 +14,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include "adreno_gpu.h"
  #include "msm_gem.h"
@@ -891,6 +892,69 @@ void adreno_gpu_ocmem_cleanup(struct adreno_ocmem 
*adreno_ocmem)
   adreno_ocmem->hdl);
  }
+static int adreno_set_supported_hw(struct device *dev,
+   struct adreno_gpu *adreno_gpu)
+{
+   u8 speedbins_count = adreno_gpu->info->speedbins_count;
+   const u32 *speedbins = adreno_gpu->info->speedbins;
+   struct nvmem_cell *cell;
+   u32 bin, i;
+   u32 val = 0;
+   void *buf, *opp_table;
+
+   cell = nvmem_cell_get(dev, "speed_bin");
+   /*
+* -ENOENT means that the platform doesn't support speedbin which is
+* fine
+*/
+   if (PTR_ERR(cell) == -ENOENT)
+   return 0;
+   else if (IS_ERR(cell))
+   return PTR_ERR(cell);
+
+   if (!speedbins)
+   goto done;
+
+   buf = nvmem_cell_read(cell, NULL);
+   if (IS_ERR(buf)) {
+   nvmem_cell_put(cell);
+   return PTR_ERR(buf);
+   }
+
+   bin = *((u32 *) buf);
+
+   for (i =

Re: [PATCH] drm/sched: remove superfluous whitespace in drm_sched_resubmit_jobs

[Christian König]

Dim will probably reject that without a one line as commit message.

Am 03.12.20 um 17:02 schrieb Lucas Stach:

Signed-off-by: Lucas Stach 


Apart from that Reviewed-by: Christian König 


---
  drivers/gpu/drm/scheduler/sched_main.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index 9a0d77a68018..f517ffd53847 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -527,8 +527,6 @@ void drm_sched_resubmit_jobs(struct drm_gpu_scheduler 
*sched)
} else {
s_job->s_fence->parent = fence;
}
-
-
}
  }
  EXPORT_SYMBOL(drm_sched_resubmit_jobs);


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

[PATCH] drm/sched: remove superfluous whitespace in drm_sched_resubmit_jobs

[Lucas Stach]

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/scheduler/sched_main.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index 9a0d77a68018..f517ffd53847 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -527,8 +527,6 @@ void drm_sched_resubmit_jobs(struct drm_gpu_scheduler 
*sched)
} else {
s_job->s_fence->parent = fence;
}
-
-
}
 }
 EXPORT_SYMBOL(drm_sched_resubmit_jobs);
-- 
2.20.1

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

Re: [PATCH v4 0/2] drm: add DisplayPort connector

[Tomi Valkeinen]

Hi DRM Bridge maintainers,

On 30/11/2020 13:29, Tomi Valkeinen wrote:
> Hi,
> 
> This series adds the DT bindings and a driver for DisplayPort connector.
> 
> Minor changes since v3:
> - Added Laurent's reviewed-bys
> - Added $ref to graph schema
> - Use 'ret' instead of 'r'
> - Add the missing period
> 
>  Tomi
> 
> Tomi Valkeinen (2):
>   dt-bindings: dp-connector: add binding for DisplayPort connector
>   drm/bridge: display-connector: add DP support
> 
>  .../display/connector/dp-connector.yaml   | 56 +++
>  drivers/gpu/drm/bridge/display-connector.c| 46 ++-
>  2 files changed, 100 insertions(+), 2 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/connector/dp-connector.yaml
> 

Is it ok for me to push this to drm-misc-next, or does one of the bridge 
maintainers want to handle
that?

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] drm: fix and cleanup legacy gamma support

[Tomi Valkeinen]

Hi,

The first patch fix legacy gamma table for HW which have a degamma lut
block before CTM block, but no gamma lut after the CTM.

The second one cleans up the legacy gamma support a bit by handling
legacy gamma for modern drivers in the drm core.

 Tomi

Tomi Valkeinen (2):
  drm: add legacy support for using degamma for gamma
  drm: automatic legacy gamma support

 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   1 -
 .../gpu/drm/arm/display/komeda/komeda_crtc.c  |   1 -
 drivers/gpu/drm/arm/malidp_crtc.c |   1 -
 drivers/gpu/drm/armada/armada_crtc.c  |   1 -
 drivers/gpu/drm/ast/ast_mode.c|   1 -
 .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c|   1 -
 drivers/gpu/drm/drm_atomic_helper.c   |  70 ---
 drivers/gpu/drm/drm_color_mgmt.c  | 117 +-
 drivers/gpu/drm/drm_fb_helper.c   |  12 +-
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c |   2 -
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c   |   1 -
 drivers/gpu/drm/nouveau/dispnv50/head.c   |   2 -
 drivers/gpu/drm/omapdrm/omap_crtc.c   |   1 -
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c|   1 -
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   |   1 -
 drivers/gpu/drm/stm/ltdc.c|   1 -
 drivers/gpu/drm/vc4/vc4_crtc.c|   1 -
 drivers/gpu/drm/vc4/vc4_txp.c |   1 -
 include/drm/drm_atomic_helper.h   |   4 -
 include/drm/drm_color_mgmt.h  |   7 ++
 include/drm/drm_crtc.h|   3 +
 21 files changed, 130 insertions(+), 100 deletions(-)

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 1/2] drm: add legacy support for using degamma for gamma

[Tomi Valkeinen]

We currently have drm_atomic_helper_legacy_gamma_set() helper which can
be used to handle legacy gamma-set ioctl.
drm_atomic_helper_legacy_gamma_set() sets GAMMA_LUT, and clears
CTM and DEGAMMA_LUT. This works fine on HW where we have either:

degamma -> ctm -> gamma -> out

or

ctm -> gamma -> out

However, if the HW has gamma table before ctm, the atomic property
should be DEGAMMA_LUT, and thus we have:

degamma -> ctm -> out

This is fine for userspace which sets gamma table using the properties,
as the userspace can check for the existence of gamma & degamma, but the
legacy gamma-set ioctl does not work.

This patch fixes the issue by changing
drm_atomic_helper_legacy_gamma_set() so that GAMMA_LUT will be used if
it exists, and DEGAMMA_LUT will be used as a fallback.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/drm_atomic_helper.c | 18 +++---
 drivers/gpu/drm/drm_color_mgmt.c|  4 
 include/drm/drm_crtc.h  |  3 +++
 3 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ba1507036f26..fe59c8ea42a9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3512,6 +3512,10 @@ EXPORT_SYMBOL(drm_atomic_helper_page_flip_target);
  * that support color management through the DEGAMMA_LUT/GAMMA_LUT
  * properties. See drm_crtc_enable_color_mgmt() and the containing chapter for
  * how the atomic color management and gamma tables work.
+ *
+ * This function uses the GAMMA_LUT or DEGAMMA_LUT property for the gamma 
table.
+ * GAMMA_LUT property is used if it exists, and DEGAMMA_LUT property is used as
+ * a fallback.
  */
 int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
   u16 *red, u16 *green, u16 *blue,
@@ -3525,6 +3529,12 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc 
*crtc,
struct drm_color_lut *blob_data;
int i, ret = 0;
bool replaced;
+   bool use_degamma;
+
+   if (!crtc->has_gamma_prop && !crtc->has_degamma_prop)
+   return -ENODEV;
+
+   use_degamma = !crtc->has_gamma_prop;
 
state = drm_atomic_state_alloc(crtc->dev);
if (!state)
@@ -3554,10 +3564,12 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc 
*crtc,
goto fail;
}
 
-   /* Reset DEGAMMA_LUT and CTM properties. */
-   replaced  = drm_property_replace_blob(&crtc_state->degamma_lut, NULL);
+   /* Set GAMMA/DEGAMMA_LUT and reset DEGAMMA/GAMMA_LUT and CTM */
+   replaced  = drm_property_replace_blob(&crtc_state->degamma_lut,
+ use_degamma ? blob : NULL);
replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL);
-   replaced |= drm_property_replace_blob(&crtc_state->gamma_lut, blob);
+   replaced |= drm_property_replace_blob(&crtc_state->gamma_lut,
+ use_degamma ? NULL : blob);
crtc_state->color_mgmt_changed |= replaced;
 
ret = drm_atomic_commit(state);
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 3bcabc2f6e0e..956e59d5f6a7 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -176,6 +176,8 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
   degamma_lut_size);
}
 
+   crtc->has_degamma_prop = !!degamma_lut_size;
+
if (has_ctm)
drm_object_attach_property(&crtc->base,
   config->ctm_property, 0);
@@ -187,6 +189,8 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
   config->gamma_lut_size_property,
   gamma_lut_size);
}
+
+   crtc->has_gamma_prop = !!gamma_lut_size;
 }
 EXPORT_SYMBOL(drm_crtc_enable_color_mgmt);
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index ba839e5e357d..9e1f06047e3d 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1084,6 +1084,9 @@ struct drm_crtc {
 */
uint16_t *gamma_store;
 
+   bool has_gamma_prop;
+   bool has_degamma_prop;
+
/** @helper_private: mid-layer private data */
const struct drm_crtc_helper_funcs *helper_private;
 
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 2/2] drm: automatic legacy gamma support

[Tomi Valkeinen]

To support legacy gamma ioctls the drivers need to set
drm_crtc_funcs.gamma_set either to a custom implementation or to
drm_atomic_helper_legacy_gamma_set. Most of the atomic drivers do the
latter.

We can simplify this by making the core handle it automatically.

Add two functions: drm_crtc_supports_legacy_gamma() which tells if the
legacy gamma table can be set, and drm_crtc_legacy_gamma_set() which
does the work by either calling the drm_crtc_funcs.gamma_set or using
GAMMA_LUT or DEGAMMA_LUT.

We can then drop drm_atomic_helper_legacy_gamma_set() and remove all its
uses.

Signed-off-by: Tomi Valkeinen 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   1 -
 .../gpu/drm/arm/display/komeda/komeda_crtc.c  |   1 -
 drivers/gpu/drm/arm/malidp_crtc.c |   1 -
 drivers/gpu/drm/armada/armada_crtc.c  |   1 -
 drivers/gpu/drm/ast/ast_mode.c|   1 -
 .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c|   1 -
 drivers/gpu/drm/drm_atomic_helper.c   |  82 -
 drivers/gpu/drm/drm_color_mgmt.c  | 113 +-
 drivers/gpu/drm/drm_fb_helper.c   |  12 +-
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c |   2 -
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c   |   1 -
 drivers/gpu/drm/nouveau/dispnv50/head.c   |   2 -
 drivers/gpu/drm/omapdrm/omap_crtc.c   |   1 -
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c|   1 -
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   |   1 -
 drivers/gpu/drm/stm/ltdc.c|   1 -
 drivers/gpu/drm/vc4/vc4_crtc.c|   1 -
 drivers/gpu/drm/vc4/vc4_txp.c |   1 -
 include/drm/drm_atomic_helper.h   |   4 -
 include/drm/drm_color_mgmt.h  |   7 ++
 20 files changed, 123 insertions(+), 112 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 2855bb918535..848b06c51b0e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5396,7 +5396,6 @@ static void dm_disable_vblank(struct drm_crtc *crtc)
 static const struct drm_crtc_funcs amdgpu_dm_crtc_funcs = {
.reset = dm_crtc_reset_state,
.destroy = amdgpu_dm_crtc_destroy,
-   .gamma_set = drm_atomic_helper_legacy_gamma_set,
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
.atomic_duplicate_state = dm_crtc_duplicate_state,
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 4b485eb512e2..59172acb9738 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -550,7 +550,6 @@ static void komeda_crtc_vblank_disable(struct drm_crtc 
*crtc)
 }
 
 static const struct drm_crtc_funcs komeda_crtc_funcs = {
-   .gamma_set  = drm_atomic_helper_legacy_gamma_set,
.destroy= drm_crtc_cleanup,
.set_config = drm_atomic_helper_set_config,
.page_flip  = drm_atomic_helper_page_flip,
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
b/drivers/gpu/drm/arm/malidp_crtc.c
index 108e7a31bd26..494075ddbef6 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -510,7 +510,6 @@ static void malidp_crtc_disable_vblank(struct drm_crtc 
*crtc)
 }
 
 static const struct drm_crtc_funcs malidp_crtc_funcs = {
-   .gamma_set = drm_atomic_helper_legacy_gamma_set,
.destroy = drm_crtc_cleanup,
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 3ebcf5a52c8b..b7bb90ae787f 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -820,7 +820,6 @@ static const struct drm_crtc_funcs armada_crtc_funcs = {
.cursor_set = armada_drm_crtc_cursor_set,
.cursor_move= armada_drm_crtc_cursor_move,
.destroy= armada_drm_crtc_destroy,
-   .gamma_set  = drm_atomic_helper_legacy_gamma_set,
.set_config = drm_atomic_helper_set_config,
.page_flip  = drm_atomic_helper_page_flip,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 9db371f4054f..5b0ec785c516 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -903,7 +903,6 @@ static void ast_crtc_atomic_destroy_state(struct drm_crtc 
*crtc,
 
 static const struct drm_crtc_funcs ast_crtc_funcs = {
.reset = ast_crtc_reset,
-   .gamma_set = drm_atomic_helper_legacy_gamma_set,
.destroy = drm_crtc_cleanup,
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
diff --git a/drivers/gpu

Re: [PATCH v2 7/7] dma-buf: Write down some rules for vmap usage

[Daniel Vetter]

On Thu, Dec 03, 2020 at 03:02:59PM +0100, Thomas Zimmermann wrote:
> Dma-buf's vmap and vunmap callbacks are undocumented and various
> exporters currently have slightly different semantics for them. Add
> documentation on how to implement and use these interfaces correctly.
> 
> v2:
>   * document vmap semantics in struct dma_buf_ops
>   * add TODO item for reviewing and maybe fixing dma-buf exporters
> 
> Signed-off-by: Thomas Zimmermann 

I still don't think this works, we're breaking dma_buf_vmap for everyone
else here.

> ---
>  Documentation/gpu/todo.rst | 15 +
>  include/drm/drm_gem.h  |  4 
>  include/linux/dma-buf.h| 45 ++
>  3 files changed, 64 insertions(+)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 009d8e6c7e3c..32bb797a84fc 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -505,6 +505,21 @@ Contact: Thomas Zimmermann , 
> Christian König, Daniel Vette
>  Level: Intermediate
>  
>  
> +Enforce rules for dma-buf vmap and pin ops
> +--
> +
> +Exporter implementations of vmap and pin in struct dma_buf_ops (and 
> consequently
> +struct drm_gem_object_funcs) use a variety of locking semantics. Some rely on
> +the caller holding the dma-buf's reservation lock, some do their own locking,
> +some don't require any locking. VRAM helpers even used to pin as part of 
> vmap.
> +
> +We need to review each exporter and enforce the documented rules.
> +
> +Contact: Christian König, Daniel Vetter, Thomas Zimmermann 
> 
> +
> +Level: Advanced
> +
> +
>  Core refactorings
>  =
>  
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 5e6daa1c982f..1864c6a721b1 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -138,6 +138,8 @@ struct drm_gem_object_funcs {
>* drm_gem_dmabuf_vmap() helper.
>*
>* This callback is optional.
> +  *
> +  * See also struct dma_buf_ops.vmap
>*/
>   int (*vmap)(struct drm_gem_object *obj, struct dma_buf_map *map);
>  
> @@ -148,6 +150,8 @@ struct drm_gem_object_funcs {
>* drm_gem_dmabuf_vunmap() helper.
>*
>* This callback is optional.
> +  *
> +  * See also struct dma_buf_ops.vunmap
>*/
>   void (*vunmap)(struct drm_gem_object *obj, struct dma_buf_map *map);
>  
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index cf72699cb2bc..dc81fdc01dda 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -267,7 +267,52 @@ struct dma_buf_ops {
>*/
>   int (*mmap)(struct dma_buf *, struct vm_area_struct *vma);
>  
> + /**
> +  * @vmap:

There's already a @vmap and @vunamp kerneldoc at the top comment, that
needs to be removed.
-Daniel

> +  *
> +  * Returns a virtual address for the buffer.
> +  *
> +  * Notes to callers:
> +  *
> +  * - Callers must hold the struct dma_buf.resv lock before calling
> +  *   this interface.
> +  *
> +  * - Callers must provide means to prevent the mappings from going
> +  *   stale, such as holding the reservation lock or providing a
> +  *   move-notify callback to the exporter.
> +  *
> +  * Notes to implementors:
> +  *
> +  * - Implementations must expect pairs of @vmap and @vunmap to be
> +  *   called frequently and should optimize for this case.
> +  *
> +  * - Implementations should avoid additional operations, such as
> +  *   pinning.
> +  *
> +  * - Implementations may expect the caller to hold the dma-buf's
> +  *   reservation lock to protect against concurrent calls and
> +  *   relocation.
> +  *
> +  * - Implementations may provide additional guarantees, such as working
> +  *   without holding the reservation lock.
> +  *
> +  * This callback is optional.
> +  *
> +  * Returns:
> +  *
> +  * 0 on success or a negative error code on failure.
> +  */
>   int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
> +
> + /**
> +  * @vunmap:
> +  *
> +  * Releases the address previously returned by @vmap.
> +  *
> +  * This callback is optional.
> +  *
> +  * See also @vmap()
> +  */
>   void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
>  };
>  
> -- 
> 2.29.2
> 

-- 
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 0/8] drm/vc4: DSI improvements and BCM2711 support

[Dave Stevenson]

Hi Maxime

On Thu, 3 Dec 2020 at 13:25, Maxime Ripard  wrote:
>
> Hi,
>
> Here's a series adding support for the DSI0 controller in the BCM2835 and the
> DSI1 controller found in the BCM2711.
>
> Let me know what you think,
> Maxime

Thanks for that series - your using a variant structure is much
cleaner than the hack I had.

For those that I didn't author (ie 1, 3, and 4)
Reviewed-by: Dave Stevenson 

> Dave Stevenson (5):
>   drm/vc4: dsi: Correct DSI register definition
>   drm/vc4: dsi: Add support for DSI0
>   dt-bindings: Add compatible for BCM2711 DSI1
>   drm/vc4: dsi: Add configuration for BCM2711 DSI1
>   ARM: dts: bcm2711: Use compatible string for BCM2711 DSI1
>
> Maxime Ripard (3):
>   drm/vc4: drv: Remove the DSI pointer in vc4_drv
>   drm/vc4: dsi: Use snprintf for the PHY clocks instead of an array
>   drm/vc4: dsi: Introduce a variant structure
>
>  .../bindings/display/brcm,bcm2835-dsi0.yaml   |   1 +
>  arch/arm/boot/dts/bcm2711.dtsi|   1 +
>  drivers/gpu/drm/vc4/vc4_drv.h |   1 -
>  drivers/gpu/drm/vc4/vc4_dsi.c | 111 ++
>  4 files changed, 67 insertions(+), 47 deletions(-)
>
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev

[Daniel Vetter]

On Thu, Dec 03, 2020 at 03:06:20AM +, Zack Rusin wrote:
> 
> 
> > On Dec 2, 2020, at 11:03, Daniel Vetter  wrote:
> > 
> > On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin  wrote:
> >> 
> >> 
> >> 
> >>> On Dec 2, 2020, at 09:27, Thomas Zimmermann  wrote:
> >>> 
> >>> Hi
> >>> 
> >>> Am 02.12.20 um 09:01 schrieb Thomas Zimmermann:
>  Hi
>  Am 30.11.20 um 21:59 schrieb Zack Rusin:
> > 
> > 
> >> On Nov 24, 2020, at 06:38, Thomas Zimmermann  
> >> wrote:
> >> 
> >> Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct
> >> drm_device.dev. No functional changes.
> >> 
> >> Signed-off-by: Thomas Zimmermann 
> >> Cc: Roland Scheidegger 
> >> ---
> >> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c |  8 
> >> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 27 +-
> >> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |  2 +-
> > 
> > Reviewed-by: Zack Rusin 
>  Could you add this patch to the vmwgfx tree?
> >>> 
> >>> AMD devs indicated that they'd prefer to merge the patchset trough 
> >>> drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through 
> >>> drm-misc-next as well.
> >> 
> >> Sounds good. I’ll make sure to rebase our latest patch set on top of it 
> >> when it’s in. Thanks!
> > 
> > btw if you want to avoid multi-tree coordination headaches, we can
> > also manage vmwgfx in drm-misc and give you & Roland commit rights
> > there. Up to you. There is some scripting involved for now (but I hope
> > whenever we move to gitlab we could do the checks server-side):
> 
> I’d be happy to take you up on that. I would like to move a lot more of
> our development into public repos and reducing the burden of maintaining
> multiple trees would help. Is there a lot of changes to drm core that
> doesn’t go through drm-misc? Or alternatively is drm-misc often pulling
> from Linus’ master? I’m trying to figure out how much would our need to
> rebase/merge be reduced if we just used drm-misc-next/drm-misc-fixes
> because that would also allow me to point some internal testing
> infrastructure at it as well.

I think nowadays pretty much all the cross-driver work lands through
drm-misc. Exception is just new stuff that's only used by a single driver.

For testing there's also drm-tip, which tries to pull it all together (but
you might still want to point your CI at branches).

Also note that drm-misc-next doesn't have a merge window freeze period
(with have the drm-misc-next-fixes branch during that time for merge
window fixes), so you can treat it like a main development branch like
e.g. in mesa, with the -fixes branches as the release branches. Only
difference is that we don't cherry pick patches from the main branch to
the release branches (at least not as the normal flow).

If you do need a backmerge for patches from Linus to drm-misc-next because
of some feature work (or conflicts with other stuff in general) drm-misc
maintainers do that. Usually happens every few weeks.
-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] drm: Fix drm.h uapi header for Windows

[Daniel Vetter]

On Thu, Dec 3, 2020 at 9:18 AM Michel Dänzer  wrote:
>
> On 2020-12-02 8:47 p.m., James Park wrote:
> >
> > If we're trying to cut ties with the drm-uapi folder entirely, the stuff
> > ac_surface.c need includes the AMD_FMT_MOD stuff in drm_fourcc.h,
> > and AMDGPU_TILING_* under amdgpu_drm.h. Is there a better spot for these
> > definitions?
>
> The Mesa src/amd/ code should use platform-neutral abstractions for
> these. This wasn't deemed necessary before, because nobody was trying to
> build these drivers for non-UNIX OSes. But now you are.

I think that's a bit much busy work for not much gain. drm_fourcc.h is
even included as the official source of truth of some khr extensions,
making that header stand-alone and useable cross-platform sounds like
a good idea to me. Something like the below is imo perfectly fine:

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ca48ed0e6bc1..0a121b3efb58 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -24,7 +24,11 @@
#ifndef DRM_FOURCC_H
#define DRM_FOURCC_H

+#ifndef DRM_FOURCC_STANDALONE_
+/* include the linux uapi types here */
+#else
#include "drm.h"
+#endif

#if defined(__cplusplus)
extern "C" {


Cheers, Daniel

>
>
> --
> Earthling Michel Dänzer   |   https://redhat.com
> Libre software enthusiast | Mesa and X developer
> ___
> 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

Re: [PATCH v2 0/7] drm/vram-helper: Lock GEM BOs while they are mapped

[Thomas Zimmermann]

Am 03.12.20 um 15:02 schrieb Thomas Zimmermann:

GEM VRAM helpers used to pin the BO in their implementation of vmap, so
that they could not be relocated. In a recent discussion, [1] it became


Grrr, [1] was again supposed to point to the discussion at

  https://patchwork.freedesktop.org/patch/400054/?series=83765&rev=1


clear that this is incorrect and that vmap should rather repend on the
reservation lock to prevent relocation. This patchset addresses the issue.

Version 2 of the patchset is a significant rework. In particular, the
helper function drm_gem_vram_vmap_unlocked() is gone and importers now
acquire the reservation locks by themselves. I took Christian's A-bs only
for patches that were not affected.

Patches 1 and 2 prepare the ast cursor code for the later changes.

Patch 3 pushes the BO locking into callers of vmap and vunmap. Besides
the VRAM helpers, this affects ast, vboxvideo and the generic fbdev
emulation.

Patches 4 to 6 clean up afterwards. BO pinning is not required any longer
and the VRAM-internal helpers are not needed.

Patch 7 adds documentation to vmap and vunmap in struct dma_buf_ops. It
hopefully reflects the discussion on the patchset's version 1.

Tested on ast with GEM VRAM and also on mgag200 to verify that the fbdev
change does not interfere with GEM SHMEM.

v2:
* make importers acquire resv locks by themselves
* document dma-buf vamp/vunmap ops

Thomas Zimmermann (7):
   drm/ast: Don't pin cursor source BO explicitly during update
   drm/ast: Only map cursor BOs during updates
   drm/vram-helper: Move BO locking from vmap code into callers
   drm/vram-helper: Remove pinning from drm_gem_vram_{vmap,vunmap}()
   drm/vram-helper: Remove vmap reference counting
   drm/vram-helper: Simplify vmap implementation
   dma-buf: Write down some rules for vmap usage

  Documentation/gpu/todo.rst| 15 +
  drivers/gpu/drm/ast/ast_cursor.c  | 70 +-
  drivers/gpu/drm/ast/ast_drv.h |  2 -
  drivers/gpu/drm/drm_client.c  | 31 ++
  drivers/gpu/drm/drm_fb_helper.c   | 10 +++-
  drivers/gpu/drm/drm_gem_vram_helper.c | 85 ++-
  drivers/gpu/drm/vboxvideo/vbox_mode.c | 11 ++--
  include/drm/drm_client.h  |  2 +
  include/drm/drm_gem.h |  4 ++
  include/drm/drm_gem_vram_helper.h | 17 +-
  include/linux/dma-buf.h   | 45 ++
  11 files changed, 175 insertions(+), 117 deletions(-)

--
2.29.2



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 7/7] dma-buf: Write down some rules for vmap usage

[Thomas Zimmermann]

Dma-buf's vmap and vunmap callbacks are undocumented and various
exporters currently have slightly different semantics for them. Add
documentation on how to implement and use these interfaces correctly.

v2:
* document vmap semantics in struct dma_buf_ops
* add TODO item for reviewing and maybe fixing dma-buf exporters

Signed-off-by: Thomas Zimmermann 
---
 Documentation/gpu/todo.rst | 15 +
 include/drm/drm_gem.h  |  4 
 include/linux/dma-buf.h| 45 ++
 3 files changed, 64 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 009d8e6c7e3c..32bb797a84fc 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -505,6 +505,21 @@ Contact: Thomas Zimmermann , 
Christian König, Daniel Vette
 Level: Intermediate
 
 
+Enforce rules for dma-buf vmap and pin ops
+--
+
+Exporter implementations of vmap and pin in struct dma_buf_ops (and 
consequently
+struct drm_gem_object_funcs) use a variety of locking semantics. Some rely on
+the caller holding the dma-buf's reservation lock, some do their own locking,
+some don't require any locking. VRAM helpers even used to pin as part of vmap.
+
+We need to review each exporter and enforce the documented rules.
+
+Contact: Christian König, Daniel Vetter, Thomas Zimmermann 

+
+Level: Advanced
+
+
 Core refactorings
 =
 
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 5e6daa1c982f..1864c6a721b1 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -138,6 +138,8 @@ struct drm_gem_object_funcs {
 * drm_gem_dmabuf_vmap() helper.
 *
 * This callback is optional.
+*
+* See also struct dma_buf_ops.vmap
 */
int (*vmap)(struct drm_gem_object *obj, struct dma_buf_map *map);
 
@@ -148,6 +150,8 @@ struct drm_gem_object_funcs {
 * drm_gem_dmabuf_vunmap() helper.
 *
 * This callback is optional.
+*
+* See also struct dma_buf_ops.vunmap
 */
void (*vunmap)(struct drm_gem_object *obj, struct dma_buf_map *map);
 
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index cf72699cb2bc..dc81fdc01dda 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -267,7 +267,52 @@ struct dma_buf_ops {
 */
int (*mmap)(struct dma_buf *, struct vm_area_struct *vma);
 
+   /**
+* @vmap:
+*
+* Returns a virtual address for the buffer.
+*
+* Notes to callers:
+*
+* - Callers must hold the struct dma_buf.resv lock before calling
+*   this interface.
+*
+* - Callers must provide means to prevent the mappings from going
+*   stale, such as holding the reservation lock or providing a
+*   move-notify callback to the exporter.
+*
+* Notes to implementors:
+*
+* - Implementations must expect pairs of @vmap and @vunmap to be
+*   called frequently and should optimize for this case.
+*
+* - Implementations should avoid additional operations, such as
+*   pinning.
+*
+* - Implementations may expect the caller to hold the dma-buf's
+*   reservation lock to protect against concurrent calls and
+*   relocation.
+*
+* - Implementations may provide additional guarantees, such as working
+*   without holding the reservation lock.
+*
+* This callback is optional.
+*
+* Returns:
+*
+* 0 on success or a negative error code on failure.
+*/
int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
+
+   /**
+* @vunmap:
+*
+* Releases the address previously returned by @vmap.
+*
+* This callback is optional.
+*
+* See also @vmap()
+*/
void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
 };
 
-- 
2.29.2

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

[PATCH v2 2/7] drm/ast: Only map cursor BOs during updates

[Thomas Zimmermann]

The HW cursor's BO used to be mapped permanently into the kernel's
address space. GEM's vmap operation will be protected by locks, and
we don't want to lock the BO's for an indefinate period of time.

Change the cursor code to map the HW BOs only during updates. The
vmap operation in VRAM helpers is cheap, as a once estabished mapping
is being reused until the BO actually moves. As the HW cursor BOs are
permanently pinned, they never move at all.

v2:
* fix typos in commit description

Signed-off-by: Thomas Zimmermann 
Acked-by: Christian König 
---
 drivers/gpu/drm/ast/ast_cursor.c | 51 ++--
 drivers/gpu/drm/ast/ast_drv.h|  2 --
 2 files changed, 28 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 68bf3d33f1ed..fac1ee79c372 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -39,7 +39,6 @@ static void ast_cursor_fini(struct ast_private *ast)
 
for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
gbo = ast->cursor.gbo[i];
-   drm_gem_vram_vunmap(gbo, &ast->cursor.map[i]);
drm_gem_vram_unpin(gbo);
drm_gem_vram_put(gbo);
}
@@ -53,14 +52,13 @@ static void ast_cursor_release(struct drm_device *dev, void 
*ptr)
 }
 
 /*
- * Allocate cursor BOs and pins them at the end of VRAM.
+ * Allocate cursor BOs and pin them at the end of VRAM.
  */
 int ast_cursor_init(struct ast_private *ast)
 {
struct drm_device *dev = &ast->base;
size_t size, i;
struct drm_gem_vram_object *gbo;
-   struct dma_buf_map map;
int ret;
 
size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
@@ -77,15 +75,7 @@ int ast_cursor_init(struct ast_private *ast)
drm_gem_vram_put(gbo);
goto err_drm_gem_vram_put;
}
-   ret = drm_gem_vram_vmap(gbo, &map);
-   if (ret) {
-   drm_gem_vram_unpin(gbo);
-   drm_gem_vram_put(gbo);
-   goto err_drm_gem_vram_put;
-   }
-
ast->cursor.gbo[i] = gbo;
-   ast->cursor.map[i] = map;
}
 
return drmm_add_action_or_reset(dev, ast_cursor_release, NULL);
@@ -94,7 +84,6 @@ int ast_cursor_init(struct ast_private *ast)
while (i) {
--i;
gbo = ast->cursor.gbo[i];
-   drm_gem_vram_vunmap(gbo, &ast->cursor.map[i]);
drm_gem_vram_unpin(gbo);
drm_gem_vram_put(gbo);
}
@@ -168,31 +157,38 @@ static void update_cursor_image(u8 __iomem *dst, const u8 
*src, int width, int h
 int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb)
 {
struct drm_device *dev = &ast->base;
-   struct drm_gem_vram_object *gbo;
-   struct dma_buf_map map;
-   int ret;
-   void *src;
+   struct drm_gem_vram_object *dst_gbo = 
ast->cursor.gbo[ast->cursor.next_index];
+   struct drm_gem_vram_object *src_gbo = drm_gem_vram_of_gem(fb->obj[0]);
+   struct dma_buf_map src_map, dst_map;
void __iomem *dst;
+   void *src;
+   int ret;
 
if (drm_WARN_ON_ONCE(dev, fb->width > AST_MAX_HWC_WIDTH) ||
drm_WARN_ON_ONCE(dev, fb->height > AST_MAX_HWC_HEIGHT))
return -EINVAL;
 
-   gbo = drm_gem_vram_of_gem(fb->obj[0]);
-
-   ret = drm_gem_vram_vmap(gbo, &map);
+   ret = drm_gem_vram_vmap(src_gbo, &src_map);
if (ret)
return ret;
-   src = map.vaddr; /* TODO: Use mapping abstraction properly */
+   src = src_map.vaddr; /* TODO: Use mapping abstraction properly */
 
-   dst = ast->cursor.map[ast->cursor.next_index].vaddr_iomem;
+   ret = drm_gem_vram_vmap(dst_gbo, &dst_map);
+   if (ret)
+   goto err_drm_gem_vram_vunmap;
+   dst = dst_map.vaddr_iomem; /* TODO: Use mapping abstraction properly */
 
/* do data transfer to cursor BO */
update_cursor_image(dst, src, fb->width, fb->height);
 
-   drm_gem_vram_vunmap(gbo, &map);
+   drm_gem_vram_vunmap(dst_gbo, &dst_map);
+   drm_gem_vram_vunmap(src_gbo, &src_map);
 
return 0;
+
+err_drm_gem_vram_vunmap:
+   drm_gem_vram_vunmap(src_gbo, &src_map);
+   return ret;
 }
 
 static void ast_cursor_set_base(struct ast_private *ast, u64 address)
@@ -243,17 +239,26 @@ static void ast_cursor_set_location(struct ast_private 
*ast, u16 x, u16 y,
 void ast_cursor_show(struct ast_private *ast, int x, int y,
 unsigned int offset_x, unsigned int offset_y)
 {
+   struct drm_device *dev = &ast->base;
+   struct drm_gem_vram_object *gbo = 
ast->cursor.gbo[ast->cursor.next_index];
+   struct dma_buf_map map;
u8 x_offset, y_offset;
u8 __iomem *dst;
u8 __iomem *sig;
u8 jreg;
+   int ret;
 
-   dst = ast->curs

[PATCH v2 5/7] drm/vram-helper: Remove vmap reference counting

[Thomas Zimmermann]

Overlapping or nested mappings of the same BO are not allowed by the
semantics of the GEM vmap/vunmap operations. Concurent access to the
GEM object is prevented by reservation locks.

So we don't need the reference counter in the GEM VRAM object. Remove
it.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem_vram_helper.c | 19 ---
 include/drm/drm_gem_vram_helper.h | 17 +++--
 2 files changed, 7 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 760d77c6c3c0..276e8f8ea663 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -113,7 +113,6 @@ static void drm_gem_vram_cleanup(struct drm_gem_vram_object 
*gbo)
 * up; only release the GEM object.
 */
 
-   WARN_ON(gbo->vmap_use_count);
WARN_ON(dma_buf_map_is_set(&gbo->map));
 
drm_gem_object_release(&gbo->bo.base);
@@ -384,15 +383,10 @@ static int drm_gem_vram_kmap_locked(struct 
drm_gem_vram_object *gbo,
 {
int ret;
 
-   if (gbo->vmap_use_count > 0)
-   goto out;
-
ret = ttm_bo_vmap(&gbo->bo, &gbo->map);
if (ret)
return ret;
 
-out:
-   ++gbo->vmap_use_count;
*map = gbo->map;
 
return 0;
@@ -403,15 +397,9 @@ static void drm_gem_vram_kunmap_locked(struct 
drm_gem_vram_object *gbo,
 {
struct drm_device *dev = gbo->bo.base.dev;
 
-   if (drm_WARN_ON_ONCE(dev, !gbo->vmap_use_count))
-   return;
-
if (drm_WARN_ON_ONCE(dev, !dma_buf_map_is_equal(&gbo->map, map)))
return; /* BUG: map not mapped from this BO */
 
-   if (--gbo->vmap_use_count > 0)
-   return;
-
/*
 * Permanently mapping and unmapping buffers adds overhead from
 * updating the page tables and creates debugging output. Therefore,
@@ -545,12 +533,13 @@ static void drm_gem_vram_bo_driver_move_notify(struct 
drm_gem_vram_object *gbo,
   struct ttm_resource *new_mem)
 {
struct ttm_buffer_object *bo = &gbo->bo;
-   struct drm_device *dev = bo->base.dev;
+   struct dma_buf_map *map = &gbo->map;
 
-   if (drm_WARN_ON_ONCE(dev, gbo->vmap_use_count))
+   if (dma_buf_map_is_null(map))
return;
 
-   ttm_bo_vunmap(bo, &gbo->map);
+   ttm_bo_vunmap(bo, map);
+   dma_buf_map_clear(map);
 }
 
 static int drm_gem_vram_bo_driver_move(struct drm_gem_vram_object *gbo,
diff --git a/include/drm/drm_gem_vram_helper.h 
b/include/drm/drm_gem_vram_helper.h
index a4bac02249c2..48af238b5ca9 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -41,25 +41,14 @@ struct vm_area_struct;
  * dedicated memory. The buffer object can be evicted to system memory if
  * video memory becomes scarce.
  *
- * GEM VRAM objects perform reference counting for pin and mapping
- * operations. So a buffer object that has been pinned N times with
- * drm_gem_vram_pin() must be unpinned N times with
- * drm_gem_vram_unpin(). The same applies to pairs of
- * drm_gem_vram_kmap() and drm_gem_vram_kunmap(), as well as pairs of
- * drm_gem_vram_vmap() and drm_gem_vram_vunmap().
+ * GEM VRAM objects perform reference counting for pin operations. So a
+ * buffer object that has been pinned N times with drm_gem_vram_pin() must
+ * be unpinned N times with drm_gem_vram_unpin().
  */
 struct drm_gem_vram_object {
struct ttm_buffer_object bo;
struct dma_buf_map map;
 
-   /**
-* @vmap_use_count:
-*
-* Reference count on the virtual address.
-* The address are un-mapped when the count reaches zero.
-*/
-   unsigned int vmap_use_count;
-
/* Supported placements are %TTM_PL_VRAM and %TTM_PL_SYSTEM */
struct ttm_placement placement;
struct ttm_place placements[2];
-- 
2.29.2

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

[PATCH v2 3/7] drm/vram-helper: Move BO locking from vmap code into callers

[Thomas Zimmermann]

Implementations of the vmap/vunmap callbacks may expect that the caller
holds the reservation lock. Therefore push the locking from vmap and
vunmap into the callers.

This affects fbdev emulation, and cursor updates in ast and vboxvideo.
Ast and vboxvideo acquire the BO's reservation lock directly.

Fbdev emulation uses DRM client helpers for locking. This is solely done
for consistency with the rest of the interface. Fbdev emulation tries to
avoid calling GEM interfaces.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_cursor.c  | 21 --
 drivers/gpu/drm/drm_client.c  | 31 +++
 drivers/gpu/drm/drm_fb_helper.c   | 10 +++--
 drivers/gpu/drm/drm_gem_vram_helper.c | 18 +++-
 drivers/gpu/drm/vboxvideo/vbox_mode.c | 11 ++
 include/drm/drm_client.h  |  2 ++
 6 files changed, 70 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index fac1ee79c372..15e5c4fd301d 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -159,6 +159,8 @@ int ast_cursor_blit(struct ast_private *ast, struct 
drm_framebuffer *fb)
struct drm_device *dev = &ast->base;
struct drm_gem_vram_object *dst_gbo = 
ast->cursor.gbo[ast->cursor.next_index];
struct drm_gem_vram_object *src_gbo = drm_gem_vram_of_gem(fb->obj[0]);
+   struct drm_gem_object *objs[] = {&src_gbo->bo.base, &dst_gbo->bo.base};
+   struct ww_acquire_ctx ctx;
struct dma_buf_map src_map, dst_map;
void __iomem *dst;
void *src;
@@ -168,9 +170,13 @@ int ast_cursor_blit(struct ast_private *ast, struct 
drm_framebuffer *fb)
drm_WARN_ON_ONCE(dev, fb->height > AST_MAX_HWC_HEIGHT))
return -EINVAL;
 
-   ret = drm_gem_vram_vmap(src_gbo, &src_map);
+   ret = drm_gem_lock_reservations(objs, ARRAY_SIZE(objs), &ctx);
if (ret)
return ret;
+
+   ret = drm_gem_vram_vmap(src_gbo, &src_map);
+   if (ret)
+   goto err_drm_gem_unlock_reservations;
src = src_map.vaddr; /* TODO: Use mapping abstraction properly */
 
ret = drm_gem_vram_vmap(dst_gbo, &dst_map);
@@ -184,10 +190,14 @@ int ast_cursor_blit(struct ast_private *ast, struct 
drm_framebuffer *fb)
drm_gem_vram_vunmap(dst_gbo, &dst_map);
drm_gem_vram_vunmap(src_gbo, &src_map);
 
+   drm_gem_unlock_reservations(objs, ARRAY_SIZE(objs), &ctx);
+
return 0;
 
 err_drm_gem_vram_vunmap:
drm_gem_vram_vunmap(src_gbo, &src_map);
+err_drm_gem_unlock_reservations:
+   drm_gem_unlock_reservations(objs, ARRAY_SIZE(objs), &ctx);
return ret;
 }
 
@@ -241,6 +251,7 @@ void ast_cursor_show(struct ast_private *ast, int x, int y,
 {
struct drm_device *dev = &ast->base;
struct drm_gem_vram_object *gbo = 
ast->cursor.gbo[ast->cursor.next_index];
+   struct drm_gem_object *obj = &gbo->bo.base;
struct dma_buf_map map;
u8 x_offset, y_offset;
u8 __iomem *dst;
@@ -248,9 +259,14 @@ void ast_cursor_show(struct ast_private *ast, int x, int y,
u8 jreg;
int ret;
 
+   ret = dma_resv_lock(obj->resv, NULL);
+   if (ret)
+   return;
ret = drm_gem_vram_vmap(gbo, &map);
-   if (drm_WARN_ONCE(dev, ret, "drm_gem_vram_vmap() failed, ret=%d\n", 
ret))
+   if (drm_WARN_ONCE(dev, ret, "drm_gem_vram_vmap() failed, ret=%d\n", 
ret)) {
+   dma_resv_unlock(obj->resv);
return;
+   }
dst = map.vaddr_iomem; /* TODO: Use mapping abstraction properly */
 
sig = dst + AST_HWC_SIZE;
@@ -258,6 +274,7 @@ void ast_cursor_show(struct ast_private *ast, int x, int y,
writel(y, sig + AST_HWC_SIGNATURE_Y);
 
drm_gem_vram_vunmap(gbo, &map);
+   dma_resv_unlock(obj->resv);
 
if (x < 0) {
x_offset = (-x) + offset_x;
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index ce45e380f4a2..82453ca0b3ec 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -288,6 +288,37 @@ drm_client_buffer_create(struct drm_client_dev *client, 
u32 width, u32 height, u
return ERR_PTR(ret);
 }
 
+/**
+ * drm_client_buffer_lock - Locks the DRM client buffer
+ * @buffer: DRM client buffer
+ *
+ * This function locks the client buffer by acquiring the buffer
+ * object's reservation lock.
+ *
+ * Unlock the buffer with drm_client_buffer_unlock().
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ */
+int
+drm_client_buffer_lock(struct drm_client_buffer *buffer)
+{
+   return dma_resv_lock(buffer->gem->resv, NULL);
+}
+EXPORT_SYMBOL(drm_client_buffer_lock);
+
+/**
+ * drm_client_buffer_unlock - Unlock DRM client buffer
+ * @buffer: DRM client buffer
+ *
+ * Unlocks a client buffer. See drm_client_buffer_lock().
+ */
+void drm_client_buffer_unlock(struct drm_client_buffer *b

[PATCH v2 6/7] drm/vram-helper: Simplify vmap implementation

[Thomas Zimmermann]

After removing the pinning operations, the vmap/vunmap code as been
reduced to what used to be an internal helper. Inline the helper to
simplify the implementation.

Signed-off-by: Thomas Zimmermann 
Acked-by: Christian König 
---
 drivers/gpu/drm/drm_gem_vram_helper.c | 52 +++
 1 file changed, 20 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 276e8f8ea663..6159f5dc8f1f 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -378,36 +378,6 @@ int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo)
 }
 EXPORT_SYMBOL(drm_gem_vram_unpin);
 
-static int drm_gem_vram_kmap_locked(struct drm_gem_vram_object *gbo,
-   struct dma_buf_map *map)
-{
-   int ret;
-
-   ret = ttm_bo_vmap(&gbo->bo, &gbo->map);
-   if (ret)
-   return ret;
-
-   *map = gbo->map;
-
-   return 0;
-}
-
-static void drm_gem_vram_kunmap_locked(struct drm_gem_vram_object *gbo,
-  struct dma_buf_map *map)
-{
-   struct drm_device *dev = gbo->bo.base.dev;
-
-   if (drm_WARN_ON_ONCE(dev, !dma_buf_map_is_equal(&gbo->map, map)))
-   return; /* BUG: map not mapped from this BO */
-
-   /*
-* Permanently mapping and unmapping buffers adds overhead from
-* updating the page tables and creates debugging output. Therefore,
-* we delay the actual unmap operation until the BO gets evicted
-* from memory. See drm_gem_vram_bo_driver_move_notify().
-*/
-}
-
 /**
  * drm_gem_vram_vmap() - Pins and maps a GEM VRAM object into kernel address
  *   space
@@ -426,9 +396,17 @@ static void drm_gem_vram_kunmap_locked(struct 
drm_gem_vram_object *gbo,
  */
 int drm_gem_vram_vmap(struct drm_gem_vram_object *gbo, struct dma_buf_map *map)
 {
+   int ret;
+
dma_resv_assert_held(gbo->bo.base.resv);
 
-   return drm_gem_vram_kmap_locked(gbo, map);
+   ret = ttm_bo_vmap(&gbo->bo, &gbo->map);
+   if (ret)
+   return ret;
+
+   *map = gbo->map;
+
+   return 0;
 }
 EXPORT_SYMBOL(drm_gem_vram_vmap);
 
@@ -442,9 +420,19 @@ EXPORT_SYMBOL(drm_gem_vram_vmap);
  */
 void drm_gem_vram_vunmap(struct drm_gem_vram_object *gbo, struct dma_buf_map 
*map)
 {
+   struct drm_device *dev = gbo->bo.base.dev;
+
dma_resv_assert_held(gbo->bo.base.resv);
 
-   drm_gem_vram_kunmap_locked(gbo, map);
+   if (drm_WARN_ON_ONCE(dev, !dma_buf_map_is_equal(&gbo->map, map)))
+   return; /* BUG: map not mapped from this BO */
+
+   /*
+* Permanently mapping and unmapping buffers adds overhead from
+* updating the page tables and creates debugging output. Therefore,
+* we delay the actual unmap operation until the BO gets evicted
+* from memory. See drm_gem_vram_bo_driver_move_notify().
+*/
 }
 EXPORT_SYMBOL(drm_gem_vram_vunmap);
 
-- 
2.29.2

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

[PATCH v2 4/7] drm/vram-helper: Remove pinning from drm_gem_vram_{vmap, vunmap}()

[Thomas Zimmermann]

BO pinning was never meant to be part of a GEM object's vmap operation.
Remove it from the related code in VRAM helpers.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem_vram_helper.c | 16 +---
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 35a30dafccce..760d77c6c3c0 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -438,22 +438,9 @@ static void drm_gem_vram_kunmap_locked(struct 
drm_gem_vram_object *gbo,
  */
 int drm_gem_vram_vmap(struct drm_gem_vram_object *gbo, struct dma_buf_map *map)
 {
-   int ret;
-
dma_resv_assert_held(gbo->bo.base.resv);
 
-   ret = drm_gem_vram_pin_locked(gbo, 0);
-   if (ret)
-   return ret;
-   ret = drm_gem_vram_kmap_locked(gbo, map);
-   if (ret)
-   goto err_drm_gem_vram_unpin_locked;
-
-   return 0;
-
-err_drm_gem_vram_unpin_locked:
-   drm_gem_vram_unpin_locked(gbo);
-   return ret;
+   return drm_gem_vram_kmap_locked(gbo, map);
 }
 EXPORT_SYMBOL(drm_gem_vram_vmap);
 
@@ -470,7 +457,6 @@ void drm_gem_vram_vunmap(struct drm_gem_vram_object *gbo, 
struct dma_buf_map *ma
dma_resv_assert_held(gbo->bo.base.resv);
 
drm_gem_vram_kunmap_locked(gbo, map);
-   drm_gem_vram_unpin_locked(gbo);
 }
 EXPORT_SYMBOL(drm_gem_vram_vunmap);
 
-- 
2.29.2

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

[PATCH v2 0/7] drm/vram-helper: Lock GEM BOs while they are mapped

[Thomas Zimmermann]

GEM VRAM helpers used to pin the BO in their implementation of vmap, so
that they could not be relocated. In a recent discussion, [1] it became
clear that this is incorrect and that vmap should rather repend on the
reservation lock to prevent relocation. This patchset addresses the issue.

Version 2 of the patchset is a significant rework. In particular, the
helper function drm_gem_vram_vmap_unlocked() is gone and importers now
acquire the reservation locks by themselves. I took Christian's A-bs only
for patches that were not affected.

Patches 1 and 2 prepare the ast cursor code for the later changes.

Patch 3 pushes the BO locking into callers of vmap and vunmap. Besides
the VRAM helpers, this affects ast, vboxvideo and the generic fbdev
emulation.

Patches 4 to 6 clean up afterwards. BO pinning is not required any longer
and the VRAM-internal helpers are not needed.

Patch 7 adds documentation to vmap and vunmap in struct dma_buf_ops. It
hopefully reflects the discussion on the patchset's version 1.

Tested on ast with GEM VRAM and also on mgag200 to verify that the fbdev
change does not interfere with GEM SHMEM.

v2:
* make importers acquire resv locks by themselves
* document dma-buf vamp/vunmap ops

Thomas Zimmermann (7):
  drm/ast: Don't pin cursor source BO explicitly during update
  drm/ast: Only map cursor BOs during updates
  drm/vram-helper: Move BO locking from vmap code into callers
  drm/vram-helper: Remove pinning from drm_gem_vram_{vmap,vunmap}()
  drm/vram-helper: Remove vmap reference counting
  drm/vram-helper: Simplify vmap implementation
  dma-buf: Write down some rules for vmap usage

 Documentation/gpu/todo.rst| 15 +
 drivers/gpu/drm/ast/ast_cursor.c  | 70 +-
 drivers/gpu/drm/ast/ast_drv.h |  2 -
 drivers/gpu/drm/drm_client.c  | 31 ++
 drivers/gpu/drm/drm_fb_helper.c   | 10 +++-
 drivers/gpu/drm/drm_gem_vram_helper.c | 85 ++-
 drivers/gpu/drm/vboxvideo/vbox_mode.c | 11 ++--
 include/drm/drm_client.h  |  2 +
 include/drm/drm_gem.h |  4 ++
 include/drm/drm_gem_vram_helper.h | 17 +-
 include/linux/dma-buf.h   | 45 ++
 11 files changed, 175 insertions(+), 117 deletions(-)

--
2.29.2

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

[PATCH v2 1/7] drm/ast: Don't pin cursor source BO explicitly during update

[Thomas Zimmermann]

Vmapping the cursor source BO contains an implicit pin operation,
so there's no need to do this manually.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_cursor.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 742d43a7edf4..68bf3d33f1ed 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -180,12 +180,9 @@ int ast_cursor_blit(struct ast_private *ast, struct 
drm_framebuffer *fb)
 
gbo = drm_gem_vram_of_gem(fb->obj[0]);
 
-   ret = drm_gem_vram_pin(gbo, 0);
-   if (ret)
-   return ret;
ret = drm_gem_vram_vmap(gbo, &map);
if (ret)
-   goto err_drm_gem_vram_unpin;
+   return ret;
src = map.vaddr; /* TODO: Use mapping abstraction properly */
 
dst = ast->cursor.map[ast->cursor.next_index].vaddr_iomem;
@@ -194,13 +191,8 @@ int ast_cursor_blit(struct ast_private *ast, struct 
drm_framebuffer *fb)
update_cursor_image(dst, src, fb->width, fb->height);
 
drm_gem_vram_vunmap(gbo, &map);
-   drm_gem_vram_unpin(gbo);
 
return 0;
-
-err_drm_gem_vram_unpin:
-   drm_gem_vram_unpin(gbo);
-   return ret;
 }
 
 static void ast_cursor_set_base(struct ast_private *ast, u64 address)
-- 
2.29.2

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

[PULL] drm-intel-fixes v2

[Rodrigo Vivi]

Hi Dave and Daniel,

Please ignore the pull request I had sent yesterday and use only this one.

I had missed one patch: 14d1eaf08845 ("drm/i915/gt: Protect context lifetime 
with RCU").

Also, please notice that the commit 6db58901c2aa ("drm/i915/display: return 
earlier from
+intel_modeset_init() without display") was not actually a crucial fix, but it
+allowed a clean pick of the use-after-free one.

Here goes drm-intel-fixes-2020-12-03:
Fixes for GPU hang, null dereference, suspend-resume, power consumption, and 
use-after-free.

- Program mocs:63 for cache eviction on gen9 (Chris)
- Protect context lifetime with RCU (Chris)
- Split the breadcrumb spinlock between global and contexts (Chris)
- Retain default context state across shrinking (Venkata)
- Limit frequency drop to RPe on parking (Chris)
- Return earlier from intel_modeset_init() without display (Jani)
- Defer initial modeset until after GGTT is initialized (Chris)

Thanks,
Rodrigo.

The following changes since commit b65054597872ce3aefbc6a666385eabdf9e288da:

  Linux 5.10-rc6 (2020-11-29 15:50:50 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-12-03

for you to fetch changes up to ccc9e67ab26feda7e62749bb54c05d7abe07dca9:

  drm/i915/display: Defer initial modeset until after GGTT is initialised 
(2020-12-02 17:05:58 -0800)


Fixes for GPU hang, null dereference, suspend-resume, power consumption, and 
use-after-free.

- Program mocs:63 for cache eviction on gen9 (Chris)
- Protect context lifetime with RCU (Chris)
- Split the breadcrumb spinlock between global and contexts (Chris)
- Retain default context state across shrinking (Venkata)
- Limit frequency drop to RPe on parking (Chris)
- Return earlier from intel_modeset_init() without display (Jani)
- Defer initial modeset until after GGTT is initialized (Chris)


Chris Wilson (5):
  drm/i915/gt: Program mocs:63 for cache eviction on gen9
  drm/i915/gt: Protect context lifetime with RCU
  drm/i915/gt: Split the breadcrumb spinlock between global and contexts
  drm/i915/gt: Limit frequency drop to RPe on parking
  drm/i915/display: Defer initial modeset until after GGTT is initialised

Jani Nikula (1):
  drm/i915/display: return earlier from intel_modeset_init() without display

Venkata Ramana Nayana (1):
  drm/i915/gt: Retain default context state across shrinking

 drivers/gpu/drm/i915/display/intel_display.c  |  24 ++--
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c   | 168 ++
 drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h |   6 +-
 drivers/gpu/drm/i915/gt/intel_context.c   |  15 +-
 drivers/gpu/drm/i915/gt/intel_context_types.h |  23 ++-
 drivers/gpu/drm/i915/gt/intel_mocs.c  |  14 +-
 drivers/gpu/drm/i915/gt/intel_rps.c   |   4 +
 drivers/gpu/drm/i915/gt/shmem_utils.c |   7 +-
 drivers/gpu/drm/i915/i915_request.h   |   6 +-
 9 files changed, 143 insertions(+), 124 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: Check the correct variable

[Dan Carpenter]

There is a copy and paste bug in this code.  It's supposed to check
"obj2" instead of checking "obj" a second time.

Fixes: 80f0b679d6f0 ("drm/i915: Add an implementation for i915_gem_ww_ctx 
locking, v2.")
Signed-off-by: Dan Carpenter 
---
 drivers/gpu/drm/i915/selftests/i915_gem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c 
b/drivers/gpu/drm/i915/selftests/i915_gem.c
index 23a6132c5f4e..412e21604a05 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
@@ -211,8 +211,8 @@ static int igt_gem_ww_ctx(void *arg)
return PTR_ERR(obj);
 
obj2 = i915_gem_object_create_internal(i915, PAGE_SIZE);
-   if (IS_ERR(obj)) {
-   err = PTR_ERR(obj);
+   if (IS_ERR(obj2)) {
+   err = PTR_ERR(obj2);
goto put1;
}
 
-- 
2.29.2

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

[PATCH AUTOSEL 5.9 20/39] drm/exynos: depend on COMMON_CLK to fix compile tests

[Sasha Levin]

From: Krzysztof Kozlowski 

[ Upstream commit e2d3d2e904ad3d381753798dcd5cae03e3c47242 ]

The Exynos DRM uses Common Clock Framework thus it cannot be built on
platforms without it (e.g. compile test on MIPS with RALINK and
SOC_RT305X):

/usr/bin/mips-linux-gnu-ld: drivers/gpu/drm/exynos/exynos_mixer.o: in 
function `mixer_bind':
exynos_mixer.c:(.text+0x958): undefined reference to `clk_set_parent'

Reported-by: kernel test robot 
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Inki Dae 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/exynos/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 6417f374b923a..951d5f708e92b 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -1,7 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config DRM_EXYNOS
tristate "DRM Support for Samsung SoC Exynos Series"
-   depends on OF && DRM && (ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS || 
ARCH_MULTIPLATFORM || COMPILE_TEST)
+   depends on OF && DRM && COMMON_CLK
+   depends on ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS || 
ARCH_MULTIPLATFORM || COMPILE_TEST
depends on MMU
select DRM_KMS_HELPER
select VIDEOMODE_HELPERS
-- 
2.27.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Check the correct variable

[Chris Wilson]

Quoting Andi Shyti (2020-12-03 11:12:24)
> Hi Dan,
> 
> > There is a copy and paste bug in this code.  It's supposed to check
> > "obj2" instead of checking "obj" a second time.
> > 
> > Fixes: 80f0b679d6f0 ("drm/i915: Add an implementation for i915_gem_ww_ctx 
> > locking, v2.")
> > Signed-off-by: Dan Carpenter 
> > ---
> >  drivers/gpu/drm/i915/selftests/i915_gem.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c 
> > b/drivers/gpu/drm/i915/selftests/i915_gem.c
> > index 23a6132c5f4e..412e21604a05 100644
> > --- a/drivers/gpu/drm/i915/selftests/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
> > @@ -211,8 +211,8 @@ static int igt_gem_ww_ctx(void *arg)
> >   return PTR_ERR(obj);
> >  
> >   obj2 = i915_gem_object_create_internal(i915, PAGE_SIZE);
> > - if (IS_ERR(obj)) {
> > - err = PTR_ERR(obj);
> > + if (IS_ERR(obj2)) {
> > + err = PTR_ERR(obj2);
> 
> Reviewed-by: Andi Shyti 

I gave up waiting for patchwork to spot the original patch, and pushed.

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

Re: [PATCH] drm: Fix drm.h uapi header for Windows

[Simon Ser]

On Thursday, December 3, 2020 1:54 PM, Ville Syrjälä 
 wrote:

> > The drm_fourcc.h maybe makes some sense (I think in some places mesa
> > uses these internally, and many drivers use the modifiers directly in
> > the main driver). But the amdgpu header should be all ioctl stuff,
> > which should be all entirely in the winsys only.
> > Also kinda disappointing that drm_fourcc.h includes drm.h and isn't
> > standalone, but I guess that sailed (at least for linux).
>
> Isn't the only thing it needs the __u32? I would think we could just
> replace those with unsigned int (DRM_FORMAT_BIG_ENDIAN already assumes
> int is 32bit it seems) and drop the drm.h.
>
> Or are we're worried something already depends on getting drm.h via
> just including drm_fourcc.h?

Yes, some user-space might only include drm_fourcc.h and use stuff
coming from drm.h.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Fix drm.h uapi header for Windows

[Ville Syrjälä]

On Wed, Dec 02, 2020 at 11:25:58PM +0100, Daniel Vetter wrote:
> On Wed, Dec 2, 2020 at 8:48 PM James Park  wrote:
> >
> > I can avoid modifying drm.h by doing this to drm_fourcc.h:
> >
> > #ifdef _WIN32
> > #include 
> > typedef uint64_t __u64;
> > #else
> > #include "drm.h"
> > #endif
> >
> > And this to amdgpu_drm.h:
> >
> > #ifdef _WIN32
> > #include 
> > typedef int32_t  __s32;
> > typedef uint32_t __u32;
> > typedef uint64_t __u64;
> > #else
> > #include "drm.h"
> > #endif
> >
> > But now I'm touching two files under drm-uapi instead of one, and weirdly.
> >
> > If we're trying to cut ties with the drm-uapi folder entirely, the stuff 
> > ac_surface.c need includes the AMD_FMT_MOD stuff in drm_fourcc.h, and 
> > AMDGPU_TILING_* under amdgpu_drm.h. Is there a better spot for these 
> > definitions?
> 
> The drm_fourcc.h maybe makes some sense (I think in some places mesa
> uses these internally, and many drivers use the modifiers directly in
> the main driver). But the amdgpu header should be all ioctl stuff,
> which should be all entirely in the winsys only.
> 
> Also kinda disappointing that drm_fourcc.h includes drm.h and isn't
> standalone, but I guess that sailed (at least for linux).

Isn't the only thing it needs the __u32? I would think we could just
replace those with unsigned int (DRM_FORMAT_BIG_ENDIAN already assumes
int is 32bit it seems) and drop the drm.h.

Or are we're worried something already depends on getting drm.h via
just including drm_fourcc.h?

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/5] drm: add legacy support for using degamma for gamma

[Ville Syrjälä]

On Wed, Dec 02, 2020 at 01:38:42PM +0100, Daniel Vetter wrote:
> On Wed, Dec 2, 2020 at 12:52 PM Tomi Valkeinen  wrote:
> >
> > On 30/11/2020 16:10, Daniel Vetter wrote:
> >
> > > The thing is, the legacy helpers should be able to pull off what userspace
> > > needs to do when it's using atomic anyway. Hard-coding information in the
> > > kernel means we have a gap here. Hence imo legacy helpers doing the right
> > > thing in all reasonable cases is imo better.
> > >
> > > In many cases I think we should even go further, and ditch driver ability
> > > to overwrite legacy helper hooks like this. I thought we'd need that
> > > flexibility for legacy userspace being incompatible in awkward ways, but
> > > wasn't ever really needed. Worse, many drivers forget to wire up the
> > > compat hooks.
> > >
> > > tldr, imo right thing to do here:
> > > - move legacy gamma function from helpers into core code
> > > - call it unconditionally for all atomic drivers (if there's no legacy
> > >   drivers using the hook left then we can outright remove it)
> > > - make sure it dtrt in all cases
> >
> > There are atomic drivers which have their custom gamma_set function. I 
> > guess they don't support
> > atomic color mgmt, but do support (legacy) gamma.
> 
> Hm yeah, but it's this kind of feature disparity which is why I think
> we should at least try to unify more.
> 
> > We could make the core code call the gamma legacy helper automatically for 
> > atomic drivers that don't
> > have gamma_set defined but do have GAMMA_LUT or DEGAMMA_LUT. But the 
> > gamma_set function is called
> > also in a few places from drm_fb_helper.c, so this code wouldn't be fully 
> > inside drm_color_mgmt.c.
> >
> > Or we could just change drm_atomic_helper_legacy_gamma_set() to do the 
> > right thing, depending on
> > GAMMA_LUT & DEGAMMA_LUT existence.
> 
> Yeah that would be at least better than pushing more decisions onto
> drivers as hard-coding. I still think that maybe just automatically
> calling the helper when either a GAMMA or DEGAMMA lut is set up would
> be better.

BTW I have some gamma related stuff here
git://github.com/vsyrjala/linux.git fb_helper_c8_lut_4

which tries to fix some fb_helper gamma stuff, and I'm also
getting rid of the gamma_store stuff for the leacy uapi for
drivers which implement the fancier color management stuff.
In fact I just threw out the helper thing entirely and made
the core directly call the right stuff. Not sure if that
would be helpful, harmful or just meh here.

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] iommu/io-pgtable: Remove tlb_flush_leaf

[Will Deacon]

On Wed, Nov 25, 2020 at 05:29:39PM +, Robin Murphy wrote:
> The only user of tlb_flush_leaf is a particularly hairy corner of the
> Arm short-descriptor code, which wants a synchronous invalidation to
> minimise the races inherent in trying to split a large page mapping.
> This is already far enough into "here be dragons" territory that no
> sensible caller should ever hit it, and thus it really doesn't need
> optimising. Although using tlb_flush_walk there may technically be
> more heavyweight than needed, it does the job and saves everyone else
> having to carry around useless baggage.
> 
> Signed-off-by: Robin Murphy 
> ---
> 
> Reviewing the Mediatek TLB optimisation patches just left me thinking
> "why do we even have this?"... Panfrost folks, this has zero functional
> impact to you, merely wants an ack for straying outside drivers/iommu.

Thanks, this looks good to me, but I'll defer queuing it until the last
minute so that I can merge all the iommu component branches together
first and then apply this on top. Should happen next week.

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

[Bug 210467] amdgpu Vega 3 lock MCLK on 1200mhz

[bugzilla-daemon]

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

Alexey (intervio...@gmail.com) changed:

   What|Removed |Added

Summary|Vega 3 lock MCLK on 1200mhz |amdgpu Vega 3 lock MCLK on
   ||1200mhz

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

[Bug 210467] Vega 3 lock MCLK on 1200mhz

[bugzilla-daemon]

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

--- Comment #3 from Alexey (intervio...@gmail.com) ---
Created attachment 293917
  --> https://bugzilla.kernel.org/attachment.cgi?id=293917&action=edit
dmesg debug mode

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

[Bug 210467] Vega 3 lock MCLK on 1200mhz

[bugzilla-daemon]

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

--- Comment #2 from Alexey (intervio...@gmail.com) ---
Created attachment 293915
  --> https://bugzilla.kernel.org/attachment.cgi?id=293915&action=edit
dmesg

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

[Bug 210467] Vega 3 lock MCLK on 1200mhz

[bugzilla-daemon]

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

--- Comment #1 from Alexey (intervio...@gmail.com) ---
*** Bug 210465 has been marked as a duplicate of this bug. ***

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

[Bug 210465] Vega 3 lock MCLK on 1200mhz

[bugzilla-daemon]

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

Alexey (intervio...@gmail.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE
   Severity|blocking|normal

--- Comment #1 from Alexey (intervio...@gmail.com) ---


*** This bug has been marked as a duplicate of bug 210467 ***

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

[Bug 210467] New: Vega 3 lock MCLK on 1200mhz

[bugzilla-daemon]

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

Bug ID: 210467
   Summary: Vega 3 lock MCLK on 1200mhz
   Product: Drivers
   Version: 2.5
Kernel Version: 5.9.11, 5.4.80-2
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: intervio...@gmail.com
Regression: No

Lock at start (disabled display manager, check in console):
[root@hard alex]# cat /sys/class/drm/card0/device/pp_dpm_mclk
0: 400Mhz 
1: 933Mhz 
2: 1067Mhz 
3: 1200Mhz *

Found two warnings in dmesg:

[   18.539019] [ cut here ]
[   18.539021] Bogus possible_crtcs: [ENCODER:65:TMDS-65] possible_crtcs=0xf
(full crtc mask=0x7)
[   18.539077] WARNING: CPU: 3 PID: 439 at
drivers/gpu/drm/drm_mode_config.c:617 drm_mode_config_validate+0x178/0x200
[drm]
[   18.539077] Modules linked in: cmac algif_hash algif_skcipher af_alg bnep
8821ce(OE) btusb btrtl btbcm edac_mce_amd btintel kvm_amd rtw88_8821ce
amdgpu(+) nls_iso8859_1 bluetooth rtw88_8821c nls_cp437 vfat fat rtw88_pci kvm
rtw88_core ecdh_generic wmi_bmof ecc mac80211 uvcvideo snd_hda_codec_realtek
pcspkr snd_hda_codec_generic irqbypass rapl ledtrig_audio snd_hda_codec_hdmi
videobuf2_vmalloc videobuf2_memops rndis_host snd_rn_pci_acp3x k10temp
cdc_ether snd_hda_intel snd_pci_acp3x videobuf2_v4l2 usbnet snd_intel_dspcfg
videobuf2_common mousedev input_leds snd_hda_codec i2c_hid snd_hda_core joydev
mii videodev r8169 snd_hwdep snd_pcm mc cfg80211 realtek snd_timer mdio_devres
of_mdio snd fixed_phy ideapad_laptop gpu_sched sp5100_tco sparse_keymap
i2c_algo_bit soundcore libphy libarc4 rfkill battery i2c_piix4 ac elan_i2c
mac_hid evdev wmi pinctrl_amd acpi_cpufreq vboxnetflt(OE) vboxnetadp(OE)
vboxdrv(OE) vboxvideo drm_vram_helper drm_ttm_helper ttm drm_kms_helper cec
rc_core drm syscopyarea
[   18.539113]  sysfillrect sysimgblt fb_sys_fops vboxsf fuse vboxguest
crypto_user acpi_call(OE) agpgart ip_tables x_tables ext4 crc32c_generic crc16
mbcache jbd2 dm_crypt cbc encrypted_keys trusted tpm hid_generic usbhid hid
dm_mod serio_raw atkbd libps2 crct10dif_pclmul crc32_pclmul crc32c_intel
ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper xhci_pci
xhci_pci_renesas ccp xhci_hcd rng_core i8042 serio
[   18.539134] CPU: 3 PID: 439 Comm: systemd-udevd Tainted: G   OE
5.9.11-arch2-1 #1
[   18.539135] Hardware name: LENOVO 81LW/LNVNB161216, BIOS ARCN32WW 07/11/2019
[   18.539150] RIP: 0010:drm_mode_config_validate+0x178/0x200 [drm]
[   18.539153] Code: 39 d6 75 e6 45 85 c8 74 0a 44 89 c0 f7 d0 44 85 c8 74 19
49 8b 55 38 41 8b 75 18 44 89 c9 48 c7 c7 70 61 46 c0 e8 38 9f 79 d1 <0f> 0b 49
8b 45 08 4c 8d 68 f8 49 39 c4 0f 85 ed fe ff ff 5b 5d 41
[   18.539155] RSP: 0018:af0e405cfa58 EFLAGS: 00010282
[   18.539157] RAX:  RBX: 9f25700c1ad0 RCX:

[   18.539158] RDX: 0001 RSI: 92559a97 RDI:

[   18.539159] RBP: 0001 R08: 044f R09:
0001
[   18.539160] R10:  R11: 0001 R12:
9f25700c1ad8
[   18.539161] R13: 9f25649ffc00 R14: 9f25700c1ad8 R15:
001f
[   18.539163] FS:  7fc5ceee7ec0() GS:9f2574ac()
knlGS:
[   18.539164] CS:  0010 DS:  ES:  CR0: 80050033
[   18.539165] CR2: 7fa743c07270 CR3: 0002b0202000 CR4:
003506e0
[   18.539166] Call Trace:
[   18.539188]  drm_dev_register+0x158/0x1b0 [drm]
[   18.539303]  amdgpu_pci_probe+0x107/0x180 [amdgpu]
[   18.539310]  local_pci_probe+0x42/0x80
[   18.539313]  ? pci_match_device+0xd7/0x100
[   18.539317]  pci_device_probe+0xfa/0x1b0
[   18.539322]  really_probe+0x205/0x460
[   18.539325]  driver_probe_device+0xe1/0x150
[   18.539329]  device_driver_attach+0xa1/0xb0
[   18.539332]  __driver_attach+0x8a/0x150
[   18.539334]  ? device_driver_attach+0xb0/0xb0
[   18.539336]  ? device_driver_attach+0xb0/0xb0
[   18.539338]  bus_for_each_dev+0x89/0xd0
[   18.539340]  bus_add_driver+0x12b/0x1e0
[   18.539342]  driver_register+0x8b/0xe0
[   18.539345]  ? 0xc17d2000
[   18.539348]  do_one_initcall+0x59/0x240
[   18.539353]  do_init_module+0x5c/0x260
[   18.539359]  load_module+0x21a7/0x2450
[   18.539365]  __do_sys_init_module+0x12d/0x180
[   18.539373]  do_syscall_64+0x33/0x40
[   18.539376]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   18.539378] RIP: 0033:0x7fc5cf7d6e4e
[   18.539380] Code: 48 8b 0d 25 10 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e
0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d f2 0f 0c 00 f7 d8 64 89 01 48
[   18.539381] RSP: 002b:7ffd09434ca8 EFLAGS: 0246 ORIG_RAX:
00af
[   18.539383] RAX: ffda RBX: 5634744ec9f0 RCX:
7fc5cf

[Bug 210465] New: Vega 3 lock MCLK on 1200mhz

[bugzilla-daemon]

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

Bug ID: 210465
   Summary: Vega 3 lock MCLK on 1200mhz
   Product: Drivers
   Version: 2.5
Kernel Version: 5.9.11, 5.4.80-2
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: blocking
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: intervio...@gmail.com
Regression: No

Created attachment 293913
  --> https://bugzilla.kernel.org/attachment.cgi?id=293913&action=edit
dmesg

Lock at start (disabled display manager, check in console):
[root@hard alex]# cat /sys/class/drm/card0/device/pp_dpm_mclk
0: 400Mhz 
1: 933Mhz 
2: 1067Mhz 
3: 1200Mhz *

Suspend does not work: freeze black screen. Low battery life.

Found two warnings in dmesg:

[   18.539019] [ cut here ]
[   18.539021] Bogus possible_crtcs: [ENCODER:65:TMDS-65] possible_crtcs=0xf
(full crtc mask=0x7)
[   18.539077] WARNING: CPU: 3 PID: 439 at
drivers/gpu/drm/drm_mode_config.c:617 drm_mode_config_validate+0x178/0x200
[drm]
[   18.539077] Modules linked in: cmac algif_hash algif_skcipher af_alg bnep
8821ce(OE) btusb btrtl btbcm edac_mce_amd btintel kvm_amd rtw88_8821ce
amdgpu(+) nls_iso8859_1 bluetooth rtw88_8821c nls_cp437 vfat fat rtw88_pci kvm
rtw88_core ecdh_generic wmi_bmof ecc mac80211 uvcvideo snd_hda_codec_realtek
pcspkr snd_hda_codec_generic irqbypass rapl ledtrig_audio snd_hda_codec_hdmi
videobuf2_vmalloc videobuf2_memops rndis_host snd_rn_pci_acp3x k10temp
cdc_ether snd_hda_intel snd_pci_acp3x videobuf2_v4l2 usbnet snd_intel_dspcfg
videobuf2_common mousedev input_leds snd_hda_codec i2c_hid snd_hda_core joydev
mii videodev r8169 snd_hwdep snd_pcm mc cfg80211 realtek snd_timer mdio_devres
of_mdio snd fixed_phy ideapad_laptop gpu_sched sp5100_tco sparse_keymap
i2c_algo_bit soundcore libphy libarc4 rfkill battery i2c_piix4 ac elan_i2c
mac_hid evdev wmi pinctrl_amd acpi_cpufreq vboxnetflt(OE) vboxnetadp(OE)
vboxdrv(OE) vboxvideo drm_vram_helper drm_ttm_helper ttm drm_kms_helper cec
rc_core drm syscopyarea
[   18.539113]  sysfillrect sysimgblt fb_sys_fops vboxsf fuse vboxguest
crypto_user acpi_call(OE) agpgart ip_tables x_tables ext4 crc32c_generic crc16
mbcache jbd2 dm_crypt cbc encrypted_keys trusted tpm hid_generic usbhid hid
dm_mod serio_raw atkbd libps2 crct10dif_pclmul crc32_pclmul crc32c_intel
ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper xhci_pci
xhci_pci_renesas ccp xhci_hcd rng_core i8042 serio
[   18.539134] CPU: 3 PID: 439 Comm: systemd-udevd Tainted: G   OE
5.9.11-arch2-1 #1
[   18.539135] Hardware name: LENOVO 81LW/LNVNB161216, BIOS ARCN32WW 07/11/2019
[   18.539150] RIP: 0010:drm_mode_config_validate+0x178/0x200 [drm]
[   18.539153] Code: 39 d6 75 e6 45 85 c8 74 0a 44 89 c0 f7 d0 44 85 c8 74 19
49 8b 55 38 41 8b 75 18 44 89 c9 48 c7 c7 70 61 46 c0 e8 38 9f 79 d1 <0f> 0b 49
8b 45 08 4c 8d 68 f8 49 39 c4 0f 85 ed fe ff ff 5b 5d 41
[   18.539155] RSP: 0018:af0e405cfa58 EFLAGS: 00010282
[   18.539157] RAX:  RBX: 9f25700c1ad0 RCX:

[   18.539158] RDX: 0001 RSI: 92559a97 RDI:

[   18.539159] RBP: 0001 R08: 044f R09:
0001
[   18.539160] R10:  R11: 0001 R12:
9f25700c1ad8
[   18.539161] R13: 9f25649ffc00 R14: 9f25700c1ad8 R15:
001f
[   18.539163] FS:  7fc5ceee7ec0() GS:9f2574ac()
knlGS:
[   18.539164] CS:  0010 DS:  ES:  CR0: 80050033
[   18.539165] CR2: 7fa743c07270 CR3: 0002b0202000 CR4:
003506e0
[   18.539166] Call Trace:
[   18.539188]  drm_dev_register+0x158/0x1b0 [drm]
[   18.539303]  amdgpu_pci_probe+0x107/0x180 [amdgpu]
[   18.539310]  local_pci_probe+0x42/0x80
[   18.539313]  ? pci_match_device+0xd7/0x100
[   18.539317]  pci_device_probe+0xfa/0x1b0
[   18.539322]  really_probe+0x205/0x460
[   18.539325]  driver_probe_device+0xe1/0x150
[   18.539329]  device_driver_attach+0xa1/0xb0
[   18.539332]  __driver_attach+0x8a/0x150
[   18.539334]  ? device_driver_attach+0xb0/0xb0
[   18.539336]  ? device_driver_attach+0xb0/0xb0
[   18.539338]  bus_for_each_dev+0x89/0xd0
[   18.539340]  bus_add_driver+0x12b/0x1e0
[   18.539342]  driver_register+0x8b/0xe0
[   18.539345]  ? 0xc17d2000
[   18.539348]  do_one_initcall+0x59/0x240
[   18.539353]  do_init_module+0x5c/0x260
[   18.539359]  load_module+0x21a7/0x2450
[   18.539365]  __do_sys_init_module+0x12d/0x180
[   18.539373]  do_syscall_64+0x33/0x40
[   18.539376]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   18.539378] RIP: 0033:0x7fc5cf7d6e4e
[   18.539380] Code: 48 8b 0d 25 10 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e
0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d f2 0f 0c 00 f7 d8 64 

Re: [PATCH] drm/i915: Check the correct variable

[Andi Shyti]

Hi Dan,

> There is a copy and paste bug in this code.  It's supposed to check
> "obj2" instead of checking "obj" a second time.
> 
> Fixes: 80f0b679d6f0 ("drm/i915: Add an implementation for i915_gem_ww_ctx 
> locking, v2.")
> Signed-off-by: Dan Carpenter 
> ---
>  drivers/gpu/drm/i915/selftests/i915_gem.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c 
> b/drivers/gpu/drm/i915/selftests/i915_gem.c
> index 23a6132c5f4e..412e21604a05 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
> @@ -211,8 +211,8 @@ static int igt_gem_ww_ctx(void *arg)
>   return PTR_ERR(obj);
>  
>   obj2 = i915_gem_object_create_internal(i915, PAGE_SIZE);
> - if (IS_ERR(obj)) {
> - err = PTR_ERR(obj);
> + if (IS_ERR(obj2)) {
> + err = PTR_ERR(obj2);

Reviewed-by: Andi Shyti 

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

Re: [PATCH] drm/i915: Check the correct variable

[Chris Wilson]

Quoting Dan Carpenter (2020-12-03 08:45:17)
> There is a copy and paste bug in this code.  It's supposed to check
> "obj2" instead of checking "obj" a second time.
> 
> Fixes: 80f0b679d6f0 ("drm/i915: Add an implementation for i915_gem_ww_ctx 
> locking, v2.")
> Signed-off-by: Dan Carpenter 
> ---
>  drivers/gpu/drm/i915/selftests/i915_gem.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c 
> b/drivers/gpu/drm/i915/selftests/i915_gem.c
> index 23a6132c5f4e..412e21604a05 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
> @@ -211,8 +211,8 @@ static int igt_gem_ww_ctx(void *arg)
> return PTR_ERR(obj);
>  
> obj2 = i915_gem_object_create_internal(i915, PAGE_SIZE);
> -   if (IS_ERR(obj)) {
> -   err = PTR_ERR(obj);
> +   if (IS_ERR(obj2)) {
> +   err = PTR_ERR(obj2);

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

Re: [PATCH] gma500: clean up error handling in init

[Patrik Jakobsson]

On Thu, Dec 3, 2020 at 9:41 AM Dan Carpenter  wrote:
>
> The main problem with this error handling was that it didn't clean up if
> i2c_add_numbered_adapter() failed.  This code is pretty old, and doesn't
> match with today's checkpatch.pl standards so I took the opportunity to
> tidy it up a bit.  I changed the NULL comparison, and removed the
> WARNING message if kzalloc() fails and updated the label names.

Thanks! Looks good.

I'll apply this to drm-misc-next

-Patrik

>
> Fixes: 1b082ccf5901 ("gma500: Add Oaktrail support")
> Signed-off-by: Dan Carpenter 
> ---
>  drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c | 22 +-
>  1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c 
> b/drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c
> index e28107061148..fc9a34ed58bd 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c
> @@ -279,11 +279,8 @@ int oaktrail_hdmi_i2c_init(struct pci_dev *dev)
> hdmi_dev = pci_get_drvdata(dev);
>
> i2c_dev = kzalloc(sizeof(struct hdmi_i2c_dev), GFP_KERNEL);
> -   if (i2c_dev == NULL) {
> -   DRM_ERROR("Can't allocate interface\n");
> -   ret = -ENOMEM;
> -   goto exit;
> -   }
> +   if (!i2c_dev)
> +   return -ENOMEM;
>
> i2c_dev->adap = &oaktrail_hdmi_i2c_adapter;
> i2c_dev->status = I2C_STAT_INIT;
> @@ -300,16 +297,23 @@ int oaktrail_hdmi_i2c_init(struct pci_dev *dev)
>   oaktrail_hdmi_i2c_adapter.name, hdmi_dev);
> if (ret) {
> DRM_ERROR("Failed to request IRQ for I2C controller\n");
> -   goto err;
> +   goto free_dev;
> }
>
> /* Adapter registration */
> ret = i2c_add_numbered_adapter(&oaktrail_hdmi_i2c_adapter);
> -   return ret;
> +   if (ret) {
> +   DRM_ERROR("Failed to add I2C adapter\n");
> +   goto free_irq;
> +   }
>
> -err:
> +   return 0;
> +
> +free_irq:
> +   free_irq(dev->irq, hdmi_dev);
> +free_dev:
> kfree(i2c_dev);
> -exit:
> +
> return ret;
>  }
>
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/hisilicon: Deletted the entire file hibmc_ttm.c

[Thomas Zimmermann]

Hi

Am 03.12.20 um 10:05 schrieb Tian Tao:

Deletted the entire file hibmc_ttm.c. drmm_vram_helper_init() can be


Deletted -> Delete

Here and in the subject line.


called directly from hibmc_load(). hibmc_dumb_create() and
hibmc_mode_funcs can go to hibmc_drm_drv.c

Signed-off-by: Tian Tao 


Code changes look good.

Reviewed-by: Thomas Zimmermann 


---
  drivers/gpu/drm/hisilicon/hibmc/Makefile|  2 +-
  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 21 ++-
  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h |  4 --
  drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 50 -
  4 files changed, 20 insertions(+), 57 deletions(-)
  delete mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c

diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile 
b/drivers/gpu/drm/hisilicon/hibmc/Makefile
index 684ef79..d25c75e 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/Makefile
+++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
@@ -1,4 +1,4 @@
  # SPDX-License-Identifier: GPL-2.0-only
-hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_de.o hibmc_drm_vdac.o hibmc_ttm.o 
hibmc_drm_i2c.o
+hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_de.o hibmc_drm_vdac.o hibmc_drm_i2c.o
  
  obj-$(CONFIG_DRM_HISI_HIBMC) += hibmc-drm.o

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 5aea2e9..3687753 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -16,6 +16,7 @@
  
  #include 

  #include 
+#include 
  #include 
  #include 
  #include 
@@ -43,6 +44,12 @@ static irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
return IRQ_HANDLED;
  }
  
+static int hibmc_dumb_create(struct drm_file *file, struct drm_device *dev,

+struct drm_mode_create_dumb *args)
+{
+   return drm_gem_vram_fill_create_dumb(file, dev, 0, 128, args);
+}
+
  static const struct drm_driver hibmc_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.fops   = &hibmc_fops,
@@ -77,6 +84,13 @@ static const struct dev_pm_ops hibmc_pm_ops = {
hibmc_pm_resume)
  };
  
+static const struct drm_mode_config_funcs hibmc_mode_funcs = {

+   .mode_valid = drm_vram_helper_mode_valid,
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
+   .fb_create = drm_gem_fb_create,
+};
+
  static int hibmc_kms_init(struct hibmc_drm_private *priv)
  {
struct drm_device *dev = &priv->dev;
@@ -262,9 +276,12 @@ static int hibmc_load(struct drm_device *dev)
if (ret)
goto err;
  
-	ret = hibmc_mm_init(priv);

-   if (ret)
+   ret = drmm_vram_helper_init(dev, pci_resource_start(dev->pdev, 0),
+   priv->fb_size);
+   if (ret) {
+   drm_err(dev, "Error initializing VRAM MM; %d\n", ret);
goto err;
+   }
  
  	ret = hibmc_kms_init(priv);

if (ret)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index 2786de5..a49c10e 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -64,10 +64,6 @@ int hibmc_de_init(struct hibmc_drm_private *priv);
  int hibmc_vdac_init(struct hibmc_drm_private *priv);
  
  int hibmc_mm_init(struct hibmc_drm_private *hibmc);

-int hibmc_dumb_create(struct drm_file *file, struct drm_device *dev,
- struct drm_mode_create_dumb *args);
  int hibmc_ddc_create(struct drm_device *drm_dev, struct hibmc_connector 
*connector);
  
-extern const struct drm_mode_config_funcs hibmc_mode_funcs;

-
  #endif
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
deleted file mode 100644
index 892d566..000
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
+++ /dev/null
@@ -1,50 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/* Hisilicon Hibmc SoC drm driver
- *
- * Based on the bochs drm driver.
- *
- * Copyright (c) 2016 Huawei Limited.
- *
- * Author:
- * Rongrong Zou 
- * Rongrong Zou 
- * Jianhua Li 
- */
-
-#include 
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "hibmc_drm_drv.h"
-
-int hibmc_mm_init(struct hibmc_drm_private *hibmc)
-{
-   int ret;
-   struct drm_device *dev = &hibmc->dev;
-
-   ret = drmm_vram_helper_init(dev, pci_resource_start(dev->pdev, 0),
-   hibmc->fb_size);
-   if (ret) {
-   drm_err(dev, "Error initializing VRAM MM; %d\n", ret);
-   return ret;
-   }
-
-   return 0;
-}
-
-int hibmc_dumb_create(struct drm_file *file, struct drm_device *dev,
- struct drm_mode_create_dumb *args)
-{
-   return drm_gem_vram_fill_create_dumb(file, dev, 0, 128, args);
-}
-
-const struct drm_mode_co

Re: [PATCH] drm: Fix drm.h uapi header for Windows

[Pekka Paalanen]

On Wed, 2 Dec 2020 23:25:58 +0100
Daniel Vetter  wrote:

> Also kinda disappointing that drm_fourcc.h includes drm.h and isn't
> standalone, but I guess that sailed (at least for linux).

Hi,

FWIW, libweston core needs drm_fourcc.h too, even if nothing would ever
use DRM or need libdrm otherwise. A stand-alone drm_fourcc.h
replacement would make sense, although distributing it through libdrm
would still make libweston require libdrm headers at build time, even
if it doesn't need libdrm.so. Not a big deal, and I don't know if
anyone actually builds libweston without DRM-backend.

Inventing yet another pixel format enumeration just because you don't
want to depend on a specific piece of other software really sucks, so
libweston went with DRM formats as the canonical enumeration. And
Wayland protocols use it too - Wayland clients rarely have any use for
libdrm otherwise.

Maybe a new header drm_formats.h that is what drm_fourcc.h should have
been, and make drm_fourcc.h include that to be backwards API compatible?


Thanks,
pq


pgp5qHYg283de.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] gma500: clean up error handling in init

[Dan Carpenter]

The main problem with this error handling was that it didn't clean up if
i2c_add_numbered_adapter() failed.  This code is pretty old, and doesn't
match with today's checkpatch.pl standards so I took the opportunity to
tidy it up a bit.  I changed the NULL comparison, and removed the
WARNING message if kzalloc() fails and updated the label names.

Fixes: 1b082ccf5901 ("gma500: Add Oaktrail support")
Signed-off-by: Dan Carpenter 
---
 drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c 
b/drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c
index e28107061148..fc9a34ed58bd 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c
@@ -279,11 +279,8 @@ int oaktrail_hdmi_i2c_init(struct pci_dev *dev)
hdmi_dev = pci_get_drvdata(dev);
 
i2c_dev = kzalloc(sizeof(struct hdmi_i2c_dev), GFP_KERNEL);
-   if (i2c_dev == NULL) {
-   DRM_ERROR("Can't allocate interface\n");
-   ret = -ENOMEM;
-   goto exit;
-   }
+   if (!i2c_dev)
+   return -ENOMEM;
 
i2c_dev->adap = &oaktrail_hdmi_i2c_adapter;
i2c_dev->status = I2C_STAT_INIT;
@@ -300,16 +297,23 @@ int oaktrail_hdmi_i2c_init(struct pci_dev *dev)
  oaktrail_hdmi_i2c_adapter.name, hdmi_dev);
if (ret) {
DRM_ERROR("Failed to request IRQ for I2C controller\n");
-   goto err;
+   goto free_dev;
}
 
/* Adapter registration */
ret = i2c_add_numbered_adapter(&oaktrail_hdmi_i2c_adapter);
-   return ret;
+   if (ret) {
+   DRM_ERROR("Failed to add I2C adapter\n");
+   goto free_irq;
+   }
 
-err:
+   return 0;
+
+free_irq:
+   free_irq(dev->irq, hdmi_dev);
+free_dev:
kfree(i2c_dev);
-exit:
+
return ret;
 }
 
-- 
2.29.2

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

Re: [PATCH] drm: Fix drm.h uapi header for Windows

[Michel Dänzer]

On 2020-12-02 8:47 p.m., James Park wrote:


If we're trying to cut ties with the drm-uapi folder entirely, the stuff 
ac_surface.c need includes the AMD_FMT_MOD stuff in drm_fourcc.h, 
and AMDGPU_TILING_* under amdgpu_drm.h. Is there a better spot for these 
definitions?


The Mesa src/amd/ code should use platform-neutral abstractions for 
these. This wasn't deemed necessary before, because nobody was trying to 
build these drivers for non-UNIX OSes. But now you are.



--
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH drm/hisilicon 3/3] drm/hisilicon: Use the new api devm_drm_irq_install

[Tian Tao]

Use devm_drm_irq_install to register interrupts so that
drm_irq_uninstall is not called when hibmc is removed.

Signed-off-by: Tian Tao 
Reviewed-by: Thomas Zimmermann 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 13e8a28..8020604 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -247,9 +247,6 @@ static int hibmc_unload(struct drm_device *dev)
 
drm_atomic_helper_shutdown(dev);
 
-   if (dev->irq_enabled)
-   drm_irq_uninstall(dev);
-
pci_disable_msi(dev->pdev);
hibmc_kms_fini(priv);
hibmc_mm_fini(priv);
@@ -284,7 +281,7 @@ static int hibmc_load(struct drm_device *dev)
if (ret) {
drm_warn(dev, "enabling MSI failed: %d\n", ret);
} else {
-   ret = drm_irq_install(dev, dev->pdev->irq);
+   ret = devm_drm_irq_install(dev, dev->pdev->irq);
if (ret)
drm_warn(dev, "install irq failed: %d\n", ret);
}
-- 
2.7.4

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

[PATCH v2 4/6] drm/atomic: Avoid unused-but-set-variable warning on for_each_old_plane_in_state

[Liu Ying]

Artifically use 'plane' and 'old_plane_state' to avoid 'not used' warning.
The precedent has already been set by other macros in the same file.

Signed-off-by: Liu Ying 
---
v1->v2:
* No change.

 include/drm/drm_atomic.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 54e051a..9da1e35a3 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -888,7 +888,9 @@ void drm_state_dump(struct drm_device *dev, struct 
drm_printer *p);
 (__i)++)   \
for_each_if ((__state)->planes[__i].ptr &&  \
 ((plane) = (__state)->planes[__i].ptr, \
- (old_plane_state) = 
(__state)->planes[__i].old_state, 1))
+ (void)(plane) /* Only to avoid 
unused-but-set-variable warning */, \
+ (old_plane_state) = 
(__state)->planes[__i].old_state, \
+ (void)(old_plane_state) /* Only to avoid 
unused-but-set-variable warning */, 1))
 /**
  * for_each_new_plane_in_state - iterate over all planes in an atomic update
  * @__state: &struct drm_atomic_state pointer
-- 
2.7.4

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

[PATCH v6 7/8] dt-bindings: arm: fsl: add Plymovent BAS board

[Oleksij Rempel]

Add Plymovent Group BV BAS iMX6dl based board

Signed-off-by: Oleksij Rempel 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 36c5a0c5ace2..490cbc75b18a 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -364,6 +364,7 @@ properties:
   - fsl,imx6dl-sabresd# i.MX6 DualLite SABRE Smart Device 
Board
   - karo,imx6dl-tx6dl # Ka-Ro electronics TX6U Modules
   - kontron,imx6dl-samx6i # Kontron i.MX6 Solo SMARC Module
+  - ply,plybas# Plymovent BAS board
   - ply,plym2m# Plymovent M2M board
   - poslab,imx6dl-savageboard # Poslab SavageBoard Dual
   - prt,prtrvt# Protonic RVT board
-- 
2.29.2

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

[PATCH v6 8/8] ARM: dts: add Plymovent BAS board

[Oleksij Rempel]

Plymovent BAS is a base system controller produced for the Plymovent filter
systems.

Co-Developed-by: David Jander 
Signed-off-by: David Jander 
Signed-off-by: Oleksij Rempel 
---
 arch/arm/boot/dts/Makefile  |   1 +
 arch/arm/boot/dts/imx6dl-plybas.dts | 394 
 2 files changed, 395 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6dl-plybas.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 31249fc5f85c..ee725aebc3a8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -461,6 +461,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-pico-hobbit.dtb \
imx6dl-pico-nymph.dtb \
imx6dl-pico-pi.dtb \
+   imx6dl-plybas.dtb \
imx6dl-plym2m.dtb \
imx6dl-prtrvt.dtb \
imx6dl-prtvt7.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-plybas.dts 
b/arch/arm/boot/dts/imx6dl-plybas.dts
new file mode 100644
index ..333c306aa946
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-plybas.dts
@@ -0,0 +1,394 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2014 Protonic Holland
+ * Copyright (c) 2020 Oleksij Rempel , Pengutronix
+ */
+
+/dts-v1/;
+#include 
+#include 
+#include "imx6dl.dtsi"
+
+/ {
+   model = "Plymovent BAS board";
+   compatible = "ply,plybas", "fsl,imx6dl";
+
+   chosen {
+   stdout-path = &uart4;
+   };
+
+   gpio_keys {
+   compatible = "gpio-keys";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   autorepeat;
+
+   button@20 {
+   label = "START";
+   linux,code = <31>;
+   gpios = <&gpio5 8 GPIO_ACTIVE_LOW>;
+   };
+
+   button@21 {
+   label = "CLEAN";
+   linux,code = <46>;
+   gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_leds>;
+
+   led-0 {
+   label = "debug0";
+   gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+   };
+
+   led-1 {
+   label = "debug1";
+   gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
+   };
+
+   led-2 {
+   label = "light_tower1";
+   gpios = <&gpio4 22 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   };
+
+   led-3 {
+   label = "light_tower2";
+   gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
+   };
+
+   led-4 {
+   label = "light_tower3";
+   gpios = <&gpio4 24 GPIO_ACTIVE_HIGH>;
+   };
+
+   led-5 {
+   label = "light_tower4";
+   gpios = <&gpio4 25 GPIO_ACTIVE_HIGH>;
+   };
+   };
+
+   clk50m_phy: phy-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <5000>;
+   };
+
+   reg_5v0: regulator-5v0 {
+   compatible = "regulator-fixed";
+   regulator-name = "5v0";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+};
+
+&can1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_can1>;
+   xceiver-supply = <®_5v0>;
+   status = "okay";
+};
+
+&can2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_can2>;
+   xceiver-supply = <®_5v0>;
+   status = "okay";
+};
+
+&ecspi1 {
+   cs-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_ecspi1>;
+   status = "okay";
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <2000>;
+   };
+};
+
+&fec {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_enet>;
+   phy-mode = "rmii";
+   clocks = <&clks IMX6QDL_CLK_ENET>,
+<&clks IMX6QDL_CLK_ENET>,
+<&clk50m_phy>;
+   clock-names = "ipg", "ahb", "ptp";
+   phy-handle = <&rgmii_phy>;
+   status = "okay";
+
+   mdio {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* Microchip KSZ8081RNA PHY */
+   rgmii_phy: ethernet-phy@0 {
+   reg = <0>;
+   interrupts-extended = <&gpio4 30 IRQ_TYPE_LEVEL_LOW>;
+   reset-gpios = <&gpio4 26 GPIO_ACTIVE_LOW>;
+   reset-assert-us = <1>;
+   reset-deassert-us = <300>;
+   };
+   };
+};
+
+&gpio1 {
+   gpio-line-names =

[PATCH drm/hisilicon 2/3] drm/irq: Add the new api to install irq

[Tian Tao]

Add new api devm_drm_irq_install() to register interrupts,
no need to call drm_irq_uninstall() when the drm module is removed.

Signed-off-by: Tian Tao 
---
 drivers/gpu/drm/drm_irq.c | 35 +++
 include/drm/drm_irq.h |  2 +-
 2 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 09d6e9e..b363dec 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -214,6 +214,41 @@ int drm_irq_uninstall(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_irq_uninstall);
 
+static void devm_drm_irq_uninstall(void *data)
+{
+   drm_irq_uninstall(data);
+}
+
+/**
+ * devm_drm_irq_install - install IRQ handler
+ * @dev: DRM device
+ * @irq: IRQ number to install the handler for
+ *
+ * devm_drm_irq_install is a  help function of drm_irq_install.
+ *
+ * if the driver uses devm_drm_irq_install, there is no need
+ * to call drm_irq_uninstall when the drm module get unloaded,
+ * as this will done automagically.
+ *
+ * Returns:
+ * Zero on success or a negative error code on failure.
+ */
+int devm_drm_irq_install(struct drm_device *dev, int irq)
+{
+   int ret;
+
+   ret = drm_irq_install(dev, irq);
+   if (ret)
+   return ret;
+
+   ret = devm_add_action_or_reset(dev->dev, devm_drm_irq_uninstall, dev);
+   if (ret)
+   devm_drm_irq_uninstall(dev);
+
+   return ret;
+}
+EXPORT_SYMBOL(devm_drm_irq_install);
+
 #if IS_ENABLED(CONFIG_DRM_LEGACY)
 int drm_legacy_irq_control(struct drm_device *dev, void *data,
   struct drm_file *file_priv)
diff --git a/include/drm/drm_irq.h b/include/drm/drm_irq.h
index d77f6e6..631b22f 100644
--- a/include/drm/drm_irq.h
+++ b/include/drm/drm_irq.h
@@ -28,5 +28,5 @@ struct drm_device;
 
 int drm_irq_install(struct drm_device *dev, int irq);
 int drm_irq_uninstall(struct drm_device *dev);
-
+int devm_drm_irq_install(struct drm_device *dev, int irq);
 #endif
-- 
2.7.4

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

Re: [PATCH 2/2] powerpc/ps3: make system bus's remove and shutdown callbacks return void

[Michael Ellerman]

Uwe Kleine-König  writes:
> Hello Michael,
>
> On Sat, Nov 28, 2020 at 09:48:30AM +0100, Takashi Iwai wrote:
>> On Thu, 26 Nov 2020 17:59:50 +0100,
>> Uwe Kleine-König wrote:
>> > 
>> > The driver core ignores the return value of struct device_driver::remove
>> > because there is only little that can be done. For the shutdown callback
>> > it's ps3_system_bus_shutdown() which ignores the return value.
>> > 
>> > To simplify the quest to make struct device_driver::remove return void,
>> > let struct ps3_system_bus_driver::remove return void, too. All users
>> > already unconditionally return 0, this commit makes it obvious that
>> > returning an error code is a bad idea and ensures future users behave
>> > accordingly.
>> > 
>> > Signed-off-by: Uwe Kleine-König 
>> 
>> For the sound bit:
>> Acked-by: Takashi Iwai 
>
> assuming that you are the one who will apply this patch: Note that it
> depends on patch 1 that Takashi already applied to his tree. So you
> either have to wait untils patch 1 appears in some tree that you merge
> before applying, or you have to take patch 1, too. (With Takashi
> optinally dropping it then.)

Thanks. I've picked up both patches.

If Takashi doesn't want to rebase his tree to drop patch 1 that's OK, it
will just arrive in mainline via two paths, but git should handle it.

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

Re: [PATCH drm/hisilicon 1/3] drm/hisilicon: Code refactoring for hibmc_drm_drv

[tiantao (H)]

Hi

在 2020/12/2 17:02, Thomas Zimmermann 写道:



Am 02.12.20 um 09:47 schrieb Tian Tao:

Use the devm_drm_dev_alloc provided by the drm framework to alloc
a structure hibmc_drm_private.

Signed-off-by: Tian Tao 


This looks good now. Thanks for sticking to it.



Thank you for your continued patience and guidance.


Acked-by: Thomas Zimmermann 


---
  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c   |  2 +-
  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c  | 46 
+++-

  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h  |  4 +--
  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c |  2 +-
  drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c  |  8 +++--
  5 files changed, 30 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c

index ea962ac..096eea9 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -499,7 +499,7 @@ static const struct drm_crtc_helper_funcs 
hibmc_crtc_helper_funcs = {

  int hibmc_de_init(struct hibmc_drm_private *priv)
  {
-    struct drm_device *dev = priv->dev;
+    struct drm_device *dev = &priv->dev;
  struct drm_crtc *crtc = &priv->crtc;
  struct drm_plane *plane = &priv->primary_plane;
  int ret;
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c

index d845657..13e8a28 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -79,31 +79,32 @@ static const struct dev_pm_ops hibmc_pm_ops = {
  static int hibmc_kms_init(struct hibmc_drm_private *priv)
  {
+    struct drm_device *dev = &priv->dev;
  int ret;
-    drm_mode_config_init(priv->dev);
+    drm_mode_config_init(dev);
  priv->mode_config_initialized = true;
-    priv->dev->mode_config.min_width = 0;
-    priv->dev->mode_config.min_height = 0;
-    priv->dev->mode_config.max_width = 1920;
-    priv->dev->mode_config.max_height = 1200;
+    dev->mode_config.min_width = 0;
+    dev->mode_config.min_height = 0;
+    dev->mode_config.max_width = 1920;
+    dev->mode_config.max_height = 1200;
-    priv->dev->mode_config.fb_base = priv->fb_base;
-    priv->dev->mode_config.preferred_depth = 32;
-    priv->dev->mode_config.prefer_shadow = 1;
+    dev->mode_config.fb_base = priv->fb_base;
+    dev->mode_config.preferred_depth = 32;
+    dev->mode_config.prefer_shadow = 1;
-    priv->dev->mode_config.funcs = (void *)&hibmc_mode_funcs;
+    dev->mode_config.funcs = (void *)&hibmc_mode_funcs;
  ret = hibmc_de_init(priv);
  if (ret) {
-    drm_err(priv->dev, "failed to init de: %d\n", ret);
+    drm_err(dev, "failed to init de: %d\n", ret);
  return ret;
  }
  ret = hibmc_vdac_init(priv);
  if (ret) {
-    drm_err(priv->dev, "failed to init vdac: %d\n", ret);
+    drm_err(dev, "failed to init vdac: %d\n", ret);
  return ret;
  }
@@ -113,7 +114,7 @@ static int hibmc_kms_init(struct hibmc_drm_private 
*priv)

  static void hibmc_kms_fini(struct hibmc_drm_private *priv)
  {
  if (priv->mode_config_initialized) {
-    drm_mode_config_cleanup(priv->dev);
+    drm_mode_config_cleanup(&priv->dev);
  priv->mode_config_initialized = false;
  }
  }
@@ -202,7 +203,7 @@ static void hibmc_hw_config(struct 
hibmc_drm_private *priv)

  static int hibmc_hw_map(struct hibmc_drm_private *priv)
  {
-    struct drm_device *dev = priv->dev;
+    struct drm_device *dev = &priv->dev;
  struct pci_dev *pdev = dev->pdev;
  resource_size_t addr, size, ioaddr, iosize;
@@ -258,17 +259,9 @@ static int hibmc_unload(struct drm_device *dev)
  static int hibmc_load(struct drm_device *dev)
  {
-    struct hibmc_drm_private *priv;
+    struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
  int ret;
-    priv = drmm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
-    if (!priv) {
-    drm_err(dev, "no memory to allocate for hibmc_drm_private\n");
-    return -ENOMEM;
-    }
-    dev->dev_private = priv;
-    priv->dev = dev;
-
  ret = hibmc_hw_init(priv);
  if (ret)
  goto err;
@@ -310,6 +303,7 @@ static int hibmc_load(struct drm_device *dev)
  static int hibmc_pci_probe(struct pci_dev *pdev,
 const struct pci_device_id *ent)
  {
+    struct hibmc_drm_private *priv;
  struct drm_device *dev;
  int ret;
@@ -318,12 +312,14 @@ static int hibmc_pci_probe(struct pci_dev *pdev,
  if (ret)
  return ret;
-    dev = drm_dev_alloc(&hibmc_driver, &pdev->dev);
-    if (IS_ERR(dev)) {
+    priv = devm_drm_dev_alloc(&pdev->dev, &hibmc_driver,
+  struct hibmc_drm_private, dev);
+    if (IS_ERR(priv)) {
  DRM_ERROR("failed to allocate drm_device\n");
-    return PTR_ERR(dev);
+    return PTR_ERR(priv);
  }
+    dev = &priv->dev;
  dev->pdev = pdev;
  pci_set_drvdata(pdev, dev);
diff --git a/

[PATCH v2 1/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding

[Liu Ying]

This patch adds bindings for i.MX8qxp/qm Display Processing Unit.

Signed-off-by: Liu Ying 
---
Note that this depends on the 'two cell binding' clock patch set which has
already landed in Shawn's i.MX clk/imx git branch.  Otherwise, imx8-lpcg.h
won't be found.

v1->v2:
* Fix yamllint warnings.
* Require bypass0 and bypass1 clocks for both i.MX8qxp and i.MX8qm, as the
  display controller subsystem spec does say that they exist.
* Use new dt binding way to add clocks in the example.
* Trivial tweaks for the example.

 .../bindings/display/imx/fsl,imx8qxp-dpu.yaml  | 416 +
 1 file changed, 416 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml

diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml 
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml
new file mode 100644
index ..045df5a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml
@@ -0,0 +1,416 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Processing Unit
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The Freescale i.MX8qm/qxp Display Processing Unit(DPU) is comprised of two
+  main components that include a blit engine for 2D graphics accelerations
+  and a display controller for display output processing, as well as a command
+  sequencer.
+
+properties:
+  compatible:
+oneOf:
+  - const: fsl,imx8qxp-dpu
+  - const: fsl,imx8qm-dpu
+
+  reg:
+maxItems: 1
+
+  interrupts:
+items:
+  - description: |
+  store9 shadow load interrupt(blit engine)
+  - description: |
+  store9 frame complete interrupt(blit engine)
+  - description: |
+  store9 sequence complete interrupt(blit engine)
+  - description: |
+  extdst0 shadow load interrupt
+  (display controller, content stream 0)
+  - description: |
+  extdst0 frame complete interrupt
+  (display controller, content stream 0)
+  - description: |
+  extdst0 sequence complete interrupt
+  (display controller, content stream 0)
+  - description: |
+  extdst4 shadow load interrupt
+  (display controller, safety stream 0)
+  - description: |
+  extdst4 frame complete interrupt
+  (display controller, safety stream 0)
+  - description: |
+  extdst4 sequence complete interrupt
+  (display controller, safety stream 0)
+  - description: |
+  extdst1 shadow load interrupt
+  (display controller, content stream 1)
+  - description: |
+  extdst1 frame complete interrupt
+  (display controller, content stream 1)
+  - description: |
+  extdst1 sequence complete interrupt
+  (display controller, content stream 1)
+  - description: |
+  extdst5 shadow load interrupt
+  (display controller, safety stream 1)
+  - description: |
+  extdst5 frame complete interrupt
+  (display controller, safety stream 1)
+  - description: |
+  extdst5 sequence complete interrupt
+  (display controller, safety stream 1)
+  - description: |
+  disengcfg0 shadow load interrupt
+  (display controller, display stream 0)
+  - description: |
+  disengcfg0 frame complete interrupt
+  (display controller, display stream 0)
+  - description: |
+  disengcfg0 sequence complete interrupt
+  (display controller, display stream 0)
+  - description: |
+  framegen0 programmable interrupt0
+  (display controller, display stream 0)
+  - description: |
+  framegen0 programmable interrupt1
+  (display controller, display stream 0)
+  - description: |
+  framegen0 programmable interrupt2
+  (display controller, display stream 0)
+  - description: |
+  framegen0 programmable interrupt3
+  (display controller, display stream 0)
+  - description: |
+  signature0 shadow load interrupt
+  (display controller, display stream 0)
+  - description: |
+  signature0 measurement valid interrupt
+  (display controller, display stream 0)
+  - description: |
+  signature0 error condition interrupt
+  (display controller, display stream 0)
+  - description: |
+  disengcfg1 shadow load interrupt
+  (display controller, display stream 1)
+  - description: |
+  disengcfg1 frame complete interrupt
+  (display controller, display stream 1)
+  - description: |
+  disengcfg1 sequence complete interrupt
+  (display controller, display stream 1)
+  - description: |
+  frameg

[PATCH drm/hisilicon 0/3] Add the new api to install irq

[Tian Tao]

patch #1 is code refactorings to use devm_drm_dev_alloc.
patch #2 add the new api to install irq, patch #3 is hibmc driver uses
the newly added api to register interrupts.

Tian Tao (3):
  drm/hisilicon: Code refactoring for hibmc_drm_drv
  drm/irq: Add the new api to install irq
  drm/hisilicon: Use the new api devm_drm_irq_install

 drivers/gpu/drm/drm_irq.c| 35 
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c   |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c  | 51 ++--
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h  |  4 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c  |  8 ++--
 include/drm/drm_irq.h|  2 +-
 7 files changed, 67 insertions(+), 37 deletions(-)

-- 
2.7.4

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

Re: [PATCH] drm: Fix drm.h uapi header for Windows

[James Park]

If the definitions in drm_fourcc.h make sense to live there, and we can't
remove drm.h from that header for backward compatibility, and the code that
I'm trying to compile on Windows needs the definitions in drm_fourcc.h,
then doesn't it make sense to adjust drm.h?

The patch that I'm proposing doesn't change very much. It might be easier
to read here:
https://github.com/jpark37/linux/commit/648e9281824ddc943c3ea6b34d6d6c154717a0a3

Thanks,
James

On Wed, Dec 2, 2020 at 2:26 PM Daniel Vetter  wrote:

> On Wed, Dec 2, 2020 at 8:48 PM James Park 
> wrote:
> >
> > I can avoid modifying drm.h by doing this to drm_fourcc.h:
> >
> > #ifdef _WIN32
> > #include 
> > typedef uint64_t __u64;
> > #else
> > #include "drm.h"
> > #endif
> >
> > And this to amdgpu_drm.h:
> >
> > #ifdef _WIN32
> > #include 
> > typedef int32_t  __s32;
> > typedef uint32_t __u32;
> > typedef uint64_t __u64;
> > #else
> > #include "drm.h"
> > #endif
> >
> > But now I'm touching two files under drm-uapi instead of one, and
> weirdly.
> >
> > If we're trying to cut ties with the drm-uapi folder entirely, the stuff
> ac_surface.c need includes the AMD_FMT_MOD stuff in drm_fourcc.h, and
> AMDGPU_TILING_* under amdgpu_drm.h. Is there a better spot for these
> definitions?
>
> The drm_fourcc.h maybe makes some sense (I think in some places mesa
> uses these internally, and many drivers use the modifiers directly in
> the main driver). But the amdgpu header should be all ioctl stuff,
> which should be all entirely in the winsys only.
>
> Also kinda disappointing that drm_fourcc.h includes drm.h and isn't
> standalone, but I guess that sailed (at least for linux).
> -Daniel
>
> > Thanks,
> > James
> >
> > On Wed, Dec 2, 2020 at 10:06 AM Michel Dänzer 
> wrote:
> >>
> >> On 2020-12-02 1:46 p.m., Daniel Vetter wrote:
> >> > On Wed, Dec 2, 2020 at 12:43 PM Michel Dänzer 
> wrote:
> >> >>
> >> >> On 2020-12-01 11:01 a.m., James Park wrote:
> >> >>> This will allow Mesa to port code to Windows more easily.
> >> >>
> >> >> As discussed in
> >> >>
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6162#note_712779
> >> >> , including drm.h makes no sense when building for Windows.
> >> >
> >> > Yeah I think it'd be cleanest if we can avoid this. If not I think the
> >> > right fix would be to split out the actually needed parts from drm.h
> >> > into a new header (still included by drm.h for backwards compat
> >> > reasons) which mesa can use. Since it looks like the problematic parts
> >> > are the legacy gunk, and not the new ioctl structures. Pulling out
> >> > drm_render.h for all the render stuff and mabe drm_vblank.h for the
> >> > vblank stuff (which would fit better in drm_mode.h but mistakes were
> >> > made, oops).
> >>
> >> If anything currently in drm.h is needed while building for Windows, it
> >> points to a broken abstraction somewhere in userspace. (Specifically,
> >> the Mesa Gallium/Vulkan winsys is supposed to abstract away platform
> >> details like these)
> >>
> >>
> >> --
> >> Earthling Michel Dänzer   |
> https://redhat.com
> >> Libre software enthusiast | Mesa and X developer
>
>
>
> --
> 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 v2 3/5] thermal: devfreq_cooling: add new registration functions with Energy Model

[Lukasz Luba]

Hi Ionela,

On 12/2/20 10:24 AM, Ionela Voinescu wrote:

Hi Lukasz,

On Wednesday 18 Nov 2020 at 12:03:56 (+), Lukasz Luba wrote:


[snip]


+   struct device_node *np = NULL;


[snip]


+
+   if (dev->of_node)
+   np = of_node_get(dev->of_node);
+


Should np be checked before use? I'm not sure if it's better to do the
assign first and then the check on np before use. It depends on the
consequences of passing a NULL node pointer later on.


The np is actually dev->of_node (or left NULL, as set at the begging).
The only meaning of the line above is to increment the counter and then
decrement if CONFIG_OF_DYNAMIC was used.
The devfreq_cooling_register() has np = NULL and the registration can
handle it, so we should be OK here as well.




+   cdev = of_devfreq_cooling_register_power(np, df, dfc_power);
+
+   if (np)
+   of_node_put(np);
+


[snip]





Otherwise it looks good to me:

Reviewed-by: Ionela Voinescu 


Thank you for the review.

Regards,
Lukasz



Ionela.


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

[PATCH v6 4/8] dt-bindings: vendor-prefixes: Add an entry for Plymovent

[Oleksij Rempel]

Add "ply" entry for Plymovent Group BV: https://www.plymovent.com/

Signed-off-by: Oleksij Rempel 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 6a9be2bbbcb6..8332d50301ea 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -840,6 +840,8 @@ patternProperties:
 description: PLDA
   "^plx,.*":
 description: Broadcom Corporation (formerly PLX Technology)
+  "^ply,.*":
+description: Plymovent Group BV
   "^pni,.*":
 description: PNI Sensor Corporation
   "^pocketbook,.*":
-- 
2.29.2

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

[PATCH v6 6/8] ARM: dts: add Plymovent M2M board

[Oleksij Rempel]

Plymovent M2M is a control interface produced for the Plymovent filter
systems.

Co-Developed-by: David Jander 
Signed-off-by: David Jander 
Signed-off-by: Oleksij Rempel 
---
 arch/arm/boot/dts/Makefile  |   1 +
 arch/arm/boot/dts/imx6dl-plym2m.dts | 446 
 2 files changed, 447 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6dl-plym2m.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 3ab9d58428cf..31249fc5f85c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -461,6 +461,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-pico-hobbit.dtb \
imx6dl-pico-nymph.dtb \
imx6dl-pico-pi.dtb \
+   imx6dl-plym2m.dtb \
imx6dl-prtrvt.dtb \
imx6dl-prtvt7.dtb \
imx6dl-rex-basic.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-plym2m.dts 
b/arch/arm/boot/dts/imx6dl-plym2m.dts
new file mode 100644
index ..4d0d3d3386af
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-plym2m.dts
@@ -0,0 +1,446 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2014 Protonic Holland
+ * Copyright (c) 2020 Oleksij Rempel , Pengutronix
+ */
+
+/dts-v1/;
+#include 
+#include 
+#include "imx6dl.dtsi"
+
+/ {
+   model = "Plymovent M2M board";
+   compatible = "ply,plym2m", "fsl,imx6dl";
+
+   chosen {
+   stdout-path = &uart4;
+   };
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = <&pwm1 0 500 0>;
+   brightness-levels = <0 1000>;
+   num-interpolated-steps = <20>;
+   default-brightness-level = <19>;
+   power-supply = <®_12v0>;
+   };
+
+   display {
+   compatible = "fsl,imx-parallel-display";
+   pinctrl-0 = <&pinctrl_ipu1_disp>;
+   pinctrl-names = "default";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   display_in: endpoint {
+   remote-endpoint = <&ipu1_di0_disp0>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   display_out: endpoint {
+   remote-endpoint = <&panel_in>;
+   };
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_leds>;
+
+   led-0 {
+   label = "debug0";
+   function = LED_FUNCTION_STATUS;
+   gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   };
+   };
+
+   panel {
+   compatible = "edt,etm0700g0bdh6";
+   backlight = <&backlight>;
+   power-supply = <®_3v3>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <&display_out>;
+   };
+   };
+   };
+
+   clk50m_phy: phy-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <5000>;
+   };
+
+   reg_3v3: regulator-3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   reg_5v0: regulator-5v0 {
+   compatible = "regulator-fixed";
+   regulator-name = "5v0";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
+   reg_12v0: regulator-12v0 {
+   compatible = "regulator-fixed";
+   regulator-name = "12v0";
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+};
+
+&can1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_can1>;
+   xceiver-supply = <®_5v0>;
+   status = "okay";
+};
+
+&ecspi1 {
+   cs-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_ecspi1>;
+   status = "okay";
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <2000>;
+   };
+};
+
+&ecspi2 {
+   cs-gpios = <&gpio2 26 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_ecspi2>;
+   status = "okay";
+
+   touchscreen@0 {
+   compatible = "ti,tsc2046";
+   reg = <0>;
+   pinctrl-0 = <&pinctrl_tsc2046>;
+   pinctrl-names ="default";
+   spi-max-frequency = <10>;
+   interrupts-extended = <&gpio3 20 I

[PATCH drm/hisilicon v2 1/3] drm/hisilicon: Code refactoring for hibmc_drm_drv

[Tian Tao]

Use the devm_drm_dev_alloc provided by the drm framework to alloc
a structure hibmc_drm_private.

Signed-off-by: Tian Tao 
Acked-by: Thomas Zimmermann 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c   |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c  | 46 +++-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h  |  4 +--
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c  |  8 +++--
 5 files changed, 30 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index ea962ac..096eea9 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -499,7 +499,7 @@ static const struct drm_crtc_helper_funcs 
hibmc_crtc_helper_funcs = {
 
 int hibmc_de_init(struct hibmc_drm_private *priv)
 {
-   struct drm_device *dev = priv->dev;
+   struct drm_device *dev = &priv->dev;
struct drm_crtc *crtc = &priv->crtc;
struct drm_plane *plane = &priv->primary_plane;
int ret;
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index d845657..13e8a28 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -79,31 +79,32 @@ static const struct dev_pm_ops hibmc_pm_ops = {
 
 static int hibmc_kms_init(struct hibmc_drm_private *priv)
 {
+   struct drm_device *dev = &priv->dev;
int ret;
 
-   drm_mode_config_init(priv->dev);
+   drm_mode_config_init(dev);
priv->mode_config_initialized = true;
 
-   priv->dev->mode_config.min_width = 0;
-   priv->dev->mode_config.min_height = 0;
-   priv->dev->mode_config.max_width = 1920;
-   priv->dev->mode_config.max_height = 1200;
+   dev->mode_config.min_width = 0;
+   dev->mode_config.min_height = 0;
+   dev->mode_config.max_width = 1920;
+   dev->mode_config.max_height = 1200;
 
-   priv->dev->mode_config.fb_base = priv->fb_base;
-   priv->dev->mode_config.preferred_depth = 32;
-   priv->dev->mode_config.prefer_shadow = 1;
+   dev->mode_config.fb_base = priv->fb_base;
+   dev->mode_config.preferred_depth = 32;
+   dev->mode_config.prefer_shadow = 1;
 
-   priv->dev->mode_config.funcs = (void *)&hibmc_mode_funcs;
+   dev->mode_config.funcs = (void *)&hibmc_mode_funcs;
 
ret = hibmc_de_init(priv);
if (ret) {
-   drm_err(priv->dev, "failed to init de: %d\n", ret);
+   drm_err(dev, "failed to init de: %d\n", ret);
return ret;
}
 
ret = hibmc_vdac_init(priv);
if (ret) {
-   drm_err(priv->dev, "failed to init vdac: %d\n", ret);
+   drm_err(dev, "failed to init vdac: %d\n", ret);
return ret;
}
 
@@ -113,7 +114,7 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
 static void hibmc_kms_fini(struct hibmc_drm_private *priv)
 {
if (priv->mode_config_initialized) {
-   drm_mode_config_cleanup(priv->dev);
+   drm_mode_config_cleanup(&priv->dev);
priv->mode_config_initialized = false;
}
 }
@@ -202,7 +203,7 @@ static void hibmc_hw_config(struct hibmc_drm_private *priv)
 
 static int hibmc_hw_map(struct hibmc_drm_private *priv)
 {
-   struct drm_device *dev = priv->dev;
+   struct drm_device *dev = &priv->dev;
struct pci_dev *pdev = dev->pdev;
resource_size_t addr, size, ioaddr, iosize;
 
@@ -258,17 +259,9 @@ static int hibmc_unload(struct drm_device *dev)
 
 static int hibmc_load(struct drm_device *dev)
 {
-   struct hibmc_drm_private *priv;
+   struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
int ret;
 
-   priv = drmm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
-   if (!priv) {
-   drm_err(dev, "no memory to allocate for hibmc_drm_private\n");
-   return -ENOMEM;
-   }
-   dev->dev_private = priv;
-   priv->dev = dev;
-
ret = hibmc_hw_init(priv);
if (ret)
goto err;
@@ -310,6 +303,7 @@ static int hibmc_load(struct drm_device *dev)
 static int hibmc_pci_probe(struct pci_dev *pdev,
   const struct pci_device_id *ent)
 {
+   struct hibmc_drm_private *priv;
struct drm_device *dev;
int ret;
 
@@ -318,12 +312,14 @@ static int hibmc_pci_probe(struct pci_dev *pdev,
if (ret)
return ret;
 
-   dev = drm_dev_alloc(&hibmc_driver, &pdev->dev);
-   if (IS_ERR(dev)) {
+   priv = devm_drm_dev_alloc(&pdev->dev, &hibmc_driver,
+ struct hibmc_drm_private, dev);
+   if (IS_ERR(priv)) {
DRM_ERROR("failed to allocate drm_device\n");
-   return PTR_ERR(dev);
+   return PTR_ERR(priv);
}
 
+   

[PATCH v2] drm/vc4: hdmi: Don't poll for the infoframes status on setup

[Maxime Ripard]

The infoframes are sent at a regular interval as a data island packet,
so we don't need to wait for them to be sent when we're setting them up.

However, we do need to poll when we're enabling since the we can't
update the packet RAM until it has been sent.

Let's add a boolean flag to tell whether we want to poll or not to
support both cases.

Suggested-by: Dave Stevenson 
Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Inverted when to poll
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index a2c5b5e9786a..d3c4a9b5bb6d 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -265,7 +265,8 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
 }
 
 static int vc4_hdmi_stop_packet(struct drm_encoder *encoder,
-   enum hdmi_infoframe_type type)
+   enum hdmi_infoframe_type type,
+   bool poll)
 {
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
u32 packet_id = type - 0x80;
@@ -273,6 +274,9 @@ static int vc4_hdmi_stop_packet(struct drm_encoder *encoder,
HDMI_WRITE(HDMI_RAM_PACKET_CONFIG,
   HDMI_READ(HDMI_RAM_PACKET_CONFIG) & ~BIT(packet_id));
 
+   if (!poll)
+   return 0;
+
return wait_for(!(HDMI_READ(HDMI_RAM_PACKET_STATUS) &
  BIT(packet_id)), 100);
 }
@@ -299,7 +303,7 @@ static void vc4_hdmi_write_infoframe(struct drm_encoder 
*encoder,
if (len < 0)
return;
 
-   ret = vc4_hdmi_stop_packet(encoder, frame->any.type);
+   ret = vc4_hdmi_stop_packet(encoder, frame->any.type, true);
if (ret) {
DRM_ERROR("Failed to wait for infoframe to go idle: %d\n", ret);
return;
@@ -1056,7 +1060,7 @@ static void vc4_hdmi_audio_reset(struct vc4_hdmi 
*vc4_hdmi)
int ret;
 
vc4_hdmi->audio.streaming = false;
-   ret = vc4_hdmi_stop_packet(encoder, HDMI_INFOFRAME_TYPE_AUDIO);
+   ret = vc4_hdmi_stop_packet(encoder, HDMI_INFOFRAME_TYPE_AUDIO, false);
if (ret)
dev_err(dev, "Failed to stop audio infoframe: %d\n", ret);
 
-- 
2.28.0

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

Re: [PATCH v2 4/5] thermal: devfreq_cooling: remove old power model and use EM

[Ionela Voinescu]

On Wednesday 18 Nov 2020 at 12:03:57 (+), Lukasz Luba wrote:
> Remove old power model and use new Energy Model to calculate the power
> budget. It drops static + dynamic power calculations and power table
> in order to use Energy Model performance domain data. This model
> should be easy to use and could find more users. It is also less
> complicated to setup the needed structures.
> 
> Signed-off-by: Lukasz Luba 
> ---
>  drivers/thermal/devfreq_cooling.c | 302 ++
>  include/linux/devfreq_cooling.h   |  17 --
>  2 files changed, 96 insertions(+), 223 deletions(-)
> 
> diff --git a/drivers/thermal/devfreq_cooling.c 
> b/drivers/thermal/devfreq_cooling.c
> index b354271742c5..28754ad46b96 100644
> --- a/drivers/thermal/devfreq_cooling.c
> +++ b/drivers/thermal/devfreq_cooling.c
> @@ -33,20 +33,17 @@ static DEFINE_IDA(devfreq_ida);
>   * @cdev:Pointer to associated thermal cooling device.
>   * @devfreq: Pointer to associated devfreq device.
>   * @cooling_state:   Current cooling state.
> - * @power_table: Pointer to table with maximum power draw for each
> - *   cooling state. State is the index into the table, and
> - *   the power is in mW.
>   * @freq_table:  Pointer to a table with the frequencies sorted in 
> descending
>   *   order.  You can index the table by cooling device state
> - * @freq_table_size: Size of the @freq_table and @power_table
> - * @power_ops:   Pointer to devfreq_cooling_power, used to generate the
> - *   @power_table.
> + * @max_state:   It is the last index, that is, one less than the number 
> of the
> + *   OPPs
> + * @power_ops:   Pointer to devfreq_cooling_power, a more precised model.
>   * @res_util:Resource utilization scaling factor for the power.
>   *   It is multiplied by 100 to minimize the error. It is used
>   *   for estimation of the power budget instead of using
> - *   'utilization' (which is 'busy_time / 'total_time').
> - *   The 'res_util' range is from 100 to (power_table[state] * 100)
> - *   for the corresponding 'state'.
> + *   'utilization' (which is 'busy_time' / 'total_time').
> + *   The 'res_util' range is from 100 to power * 100 for the
> + *   corresponding 'state'.
>   * @capped_state:index to cooling state with in dynamic power budget
>   * @req_max_freq:PM QoS request for limiting the maximum frequency
>   *   of the devfreq device.
> @@ -58,9 +55,8 @@ struct devfreq_cooling_device {
>   struct thermal_cooling_device *cdev;
>   struct devfreq *devfreq;
>   unsigned long cooling_state;
> - u32 *power_table;
>   u32 *freq_table;
> - size_t freq_table_size;
> + size_t max_state;
>   struct devfreq_cooling_power *power_ops;
>   u32 res_util;
>   int capped_state;
> @@ -74,7 +70,7 @@ static int devfreq_cooling_get_max_state(struct 
> thermal_cooling_device *cdev,
>  {
>   struct devfreq_cooling_device *dfc = cdev->devdata;
>  
> - *state = dfc->freq_table_size - 1;
> + *state = dfc->max_state;
>  
>   return 0;
>  }
> @@ -96,16 +92,22 @@ static int devfreq_cooling_set_cur_state(struct 
> thermal_cooling_device *cdev,
>   struct devfreq *df = dfc->devfreq;
>   struct device *dev = df->dev.parent;
>   unsigned long freq;
> + int perf_idx;
>  
>   if (state == dfc->cooling_state)
>   return 0;
>  
>   dev_dbg(dev, "Setting cooling state %lu\n", state);
>  
> - if (state >= dfc->freq_table_size)
> + if (state > dfc->max_state)
>   return -EINVAL;
>  
> - freq = dfc->freq_table[state];
> + if (dfc->em) {
> + perf_idx = dfc->max_state - state;
> + freq = dfc->em->table[perf_idx].frequency * 1000;
> + } else {
> + freq = dfc->freq_table[state];
> + }
>  
>   dev_pm_qos_update_request(&dfc->req_max_freq,
> DIV_ROUND_UP(freq, HZ_PER_KHZ));
> @@ -116,24 +118,24 @@ static int devfreq_cooling_set_cur_state(struct 
> thermal_cooling_device *cdev,
>  }
>  
>  /**
> - * freq_get_state() - get the cooling state corresponding to a frequency
> + * get_perf_idx() - get the performance index corresponding to a frequency
>   * @dfc: Pointer to devfreq cooling device
> - * @freq:frequency in Hz
> + * @freq:frequency in kHz
>   *
> - * Return: the cooling state associated with the @freq, or
> - * THERMAL_CSTATE_INVALID if it wasn't found.
> + * Return: the performance index associated with the @freq, or
> + * -EINVAL if it wasn't found.
>   */
> -static unsigned long
> -freq_get_state(struct devfreq_cooling_device *dfc, unsigned long freq)
> +static int get_perf_idx(struct devfreq_cooling_device *dfc, unsigned long 
> freq)
>  {
> + struct em_perf_domain *em = dfc->em;
>   int i;
>  
> - for (i = 0; i < dfc->freq_table_size; i++) {
> -  

[PATCH v6 1/8] dt-bindings: display: simple: fix alphabetical order for EDT compatibles

[Oleksij Rempel]

Reorder it alphabetically and remove one double entry.

Signed-off-by: Oleksij Rempel 
---
 .../bindings/display/panel/panel-simple.yaml | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index edb53ab0d9eb..428b03342fea 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -106,26 +106,24 @@ properties:
 # Emerging Display Technology Corp. 3.5" QVGA TFT LCD panel
   - edt,et035012dm6
 # Emerging Display Technology Corp. 480x272 TFT Display with 
capacitive touch
+  - edt,et057090dhu
+# Emerging Display Technology Corp. WVGA TFT Display with capacitive 
touch
   - edt,etm043080dh6gp
 # Emerging Display Technology Corp. 480x272 TFT Display
   - edt,etm0430g0dh6
 # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel
-  - edt,et057090dhu
-# Emerging Display Technology Corp. WVGA TFT Display with capacitive 
touch
-  - edt,etm070080dh6
-# Emerging Display Technology Corp. WVGA TFT Display with capacitive 
touch
-  - edt,etm0700g0dh6
-# Emerging Display Technology Corp. WVGA TFT Display with capacitive 
touch
-# Same as ETM0700G0DH6 but with inverted pixel clock.
   - edt,etm070080bdh6
 # Emerging Display Technology Corp. WVGA TFT Display with capacitive 
touch
 # Same display as the ETM0700G0BDH6, but with changed hardware for the
 # backlight and the touch interface.
+  - edt,etm070080dh6
+# Emerging Display Technology Corp. WVGA TFT Display with capacitive 
touch
   - edt,etm070080edh6
 # Emerging Display Technology Corp. WVGA TFT Display with capacitive 
touch
 # Same timings as the ETM0700G0DH6, but with resistive touch.
-  - edt,etm070080dh6
-# Evervision Electronics Co. Ltd. VGG804821 5.0" WVGA TFT LCD Panel
+  - edt,etm0700g0dh6
+# Emerging Display Technology Corp. WVGA TFT Display with capacitive 
touch
+# Same as ETM0700G0DH6 but with inverted pixel clock.
   - evervision,vgg804821
 # Foxlink Group 5" WVGA TFT LCD panel
   - foxlink,fl500wvr00-a0t
-- 
2.29.2

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

[PATCH drm/hisilicon v2 2/3] drm/irq: Add the new api to install irq

[Tian Tao]

Add new api devm_drm_irq_install() to register interrupts,
no need to call drm_irq_uninstall() when the drm module is removed.

Signed-off-by: Tian Tao 
---
 drivers/gpu/drm/drm_irq.c | 32 
 include/drm/drm_irq.h |  2 +-
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 09d6e9e..803af4b 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -214,6 +214,38 @@ int drm_irq_uninstall(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_irq_uninstall);
 
+static void devm_drm_irq_uninstall(void *data)
+{
+   drm_irq_uninstall(data);
+}
+
+/**
+ * devm_drm_irq_install - install IRQ handler
+ * @dev: DRM device
+ * @irq: IRQ number to install the handler for
+ *
+ * devm_drm_irq_install is a  help function of drm_irq_install.
+ *
+ * if the driver uses devm_drm_irq_install, there is no need
+ * to call drm_irq_uninstall when the drm module get unloaded,
+ * as this will done automagically.
+ *
+ * Returns:
+ * Zero on success or a negative error code on failure.
+ */
+int devm_drm_irq_install(struct drm_device *dev, int irq)
+{
+   int ret;
+
+   ret = drm_irq_install(dev, irq);
+   if (ret)
+   return ret;
+
+   return devm_add_action_or_reset(dev->dev,
+   devm_drm_irq_uninstall, dev);
+}
+EXPORT_SYMBOL(devm_drm_irq_install);
+
 #if IS_ENABLED(CONFIG_DRM_LEGACY)
 int drm_legacy_irq_control(struct drm_device *dev, void *data,
   struct drm_file *file_priv)
diff --git a/include/drm/drm_irq.h b/include/drm/drm_irq.h
index d77f6e6..631b22f 100644
--- a/include/drm/drm_irq.h
+++ b/include/drm/drm_irq.h
@@ -28,5 +28,5 @@ struct drm_device;
 
 int drm_irq_install(struct drm_device *dev, int irq);
 int drm_irq_uninstall(struct drm_device *dev);
-
+int devm_drm_irq_install(struct drm_device *dev, int irq);
 #endif
-- 
2.7.4

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

Re: [PATCH v2 2/5] thermal: devfreq_cooling: get a copy of device status

[Ionela Voinescu]

On Wednesday 18 Nov 2020 at 12:03:55 (+), Lukasz Luba wrote:
> Devfreq cooling needs to now the correct status of the device in order
> to operate. Do not rely on Devfreq last_status which might be a stale data
> and get more up-to-date values of the load.
> 
> Devfreq framework can change the device status in the background. To
> mitigate this situation make a copy of the status structure and use it
> for internal calculations.
> 
> In addition this patch adds normalization function, which also makes sure
> that whatever data comes from the device, it is in a sane range.
> 
> Signed-off-by: Lukasz Luba 
> ---
>  drivers/thermal/devfreq_cooling.c | 52 +--
>  1 file changed, 43 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/thermal/devfreq_cooling.c 
> b/drivers/thermal/devfreq_cooling.c
> index 659c0143c9f0..925523694462 100644
> --- a/drivers/thermal/devfreq_cooling.c
> +++ b/drivers/thermal/devfreq_cooling.c
> @@ -227,20 +227,46 @@ static inline unsigned long get_total_power(struct 
> devfreq_cooling_device *dfc,
>  voltage);
>  }
>  
> +static void _normalize_load(struct devfreq_dev_status *status)
> +{
> + /* Make some space if needed */
> + if (status->busy_time > 0x) {
> + status->busy_time >>= 10;
> + status->total_time >>= 10;
> + }
> +
> + if (status->busy_time > status->total_time)
> + status->busy_time = status->total_time;
> +
> + status->busy_time *= 100;
> + status->busy_time /= status->total_time ? : 1;
> +
> + /* Avoid division by 0 */
> + status->busy_time = status->busy_time ? : 1;
> + status->total_time = 100;
> +}
>  
>  static int devfreq_cooling_get_requested_power(struct thermal_cooling_device 
> *cdev,
>  u32 *power)
>  {
>   struct devfreq_cooling_device *dfc = cdev->devdata;
>   struct devfreq *df = dfc->devfreq;
> - struct devfreq_dev_status *status = &df->last_status;
> + struct devfreq_dev_status status;
>   unsigned long state;
> - unsigned long freq = status->current_frequency;
> + unsigned long freq;
>   unsigned long voltage;
>   u32 dyn_power = 0;
>   u32 static_power = 0;
>   int res;
>  
> + mutex_lock(&df->lock);
> + res = df->profile->get_dev_status(df->dev.parent, &status);
> + mutex_unlock(&df->lock);
> + if (res)
> + return res;
> +
> + freq = status.current_frequency;
> +
>   state = freq_get_state(dfc, freq);
>   if (state == THERMAL_CSTATE_INVALID) {
>   res = -EAGAIN;
> @@ -268,16 +294,18 @@ static int devfreq_cooling_get_requested_power(struct 
> thermal_cooling_device *cd
>   } else {
>   dyn_power = dfc->power_table[state];
>  
> + _normalize_load(&status);
> +
>   /* Scale dynamic power for utilization */
> - dyn_power *= status->busy_time;
> - dyn_power /= status->total_time;
> + dyn_power *= status.busy_time;
> + dyn_power /= status.total_time;
>   /* Get static power */
>   static_power = get_static_power(dfc, freq);
>  
>   *power = dyn_power + static_power;
>   }
>  
> - trace_thermal_power_devfreq_get_power(cdev, status, freq, *power);
> + trace_thermal_power_devfreq_get_power(cdev, &status, freq, *power);
>  
>   return 0;
>  fail:
> @@ -309,14 +337,20 @@ static int devfreq_cooling_power2state(struct 
> thermal_cooling_device *cdev,
>  {
>   struct devfreq_cooling_device *dfc = cdev->devdata;
>   struct devfreq *df = dfc->devfreq;
> - struct devfreq_dev_status *status = &df->last_status;
> - unsigned long freq = status->current_frequency;
> + struct devfreq_dev_status status;
>   unsigned long busy_time;
> + unsigned long freq;
>   s32 dyn_power;
>   u32 static_power;
>   s32 est_power;
>   int i;
>  
> + mutex_lock(&df->lock);
> + status = df->last_status;
> + mutex_unlock(&df->lock);
> +
> + freq = status.current_frequency;
> +
>   if (dfc->power_ops->get_real_power) {
>   /* Scale for resource utilization */
>   est_power = power * dfc->res_util;
> @@ -328,8 +362,8 @@ static int devfreq_cooling_power2state(struct 
> thermal_cooling_device *cdev,
>   dyn_power = dyn_power > 0 ? dyn_power : 0;
>  
>   /* Scale dynamic power for utilization */
> - busy_time = status->busy_time ?: 1;
> - est_power = (dyn_power * status->total_time) / busy_time;
> + busy_time = status.busy_time ?: 1;
> + est_power = (dyn_power * status.total_time) / busy_time;
>   }
>  
>   /*
> -- 
> 2.17.1
> 

Reviewed-by: Ionela Voinescu 

Thanks,
Ionela.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.

[PATCH] drm: Fix drm.h uapi header for Windows

[James Park]

This will allow Mesa to port code to Windows more easily.

Hide BSD header and drm_handle_t behind _WIN32 check.

Change __volatile__ to volatile, which is standard.

Signed-off-by: James Park 
---
 include/uapi/drm/drm.h | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 808b48a..53dc3c9 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -48,10 +48,9 @@ typedef unsigned int drm_handle_t;
 #include 
 typedef unsigned int drm_handle_t;
 
-#else /* One of the BSDs */
+#else
 
 #include 
-#include 
 #include 
 typedef int8_t   __s8;
 typedef uint8_t  __u8;
@@ -62,10 +61,16 @@ typedef uint32_t __u32;
 typedef int64_t  __s64;
 typedef uint64_t __u64;
 typedef size_t   __kernel_size_t;
+
+#ifndef _WIN32 /* One of the BSDs */
+
+#include 
 typedef unsigned long drm_handle_t;
 
 #endif
 
+#endif
+
 #if defined(__cplusplus)
 extern "C" {
 #endif
@@ -128,7 +133,7 @@ struct drm_tex_region {
  * other data stored in the same cache line.
  */
 struct drm_hw_lock {
-   __volatile__ unsigned int lock; /**< lock variable */
+   volatile unsigned int lock; /**< lock variable */
char padding[60];   /**< Pad to cache line */
 };
 
-- 
2.7.4

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

[PATCH v2 3/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPR channel binding

[Liu Ying]

This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Channel.

Signed-off-by: Liu Ying 
---
Note that this depends on the 'two cell binding' clock patch set which has
already landed in Shawn's i.MX clk/imx git branch.  Otherwise, imx8-lpcg.h
won't be found.

v1->v2:
* Use new dt binding way to add clocks in the example.

 .../bindings/display/imx/fsl,imx8qxp-dprc.yaml | 87 ++
 1 file changed, 87 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml

diff --git 
a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml 
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
new file mode 100644
index ..91e9472
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dprc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Prefetch Resolve Channel
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The i.MX8qm/qxp Display Prefetch Resolve Channel(DPRC) is an engine which
+  fetches display data before the display pipeline needs the data to drive
+  pixels in the active display region.  This data is transformed, or resolved,
+  from a variety of tiled buffer formats into linear format, if needed.
+  The DPR works with a double bank memory structure.  This memory structure is
+  implemented in the Resolve Tile Memory(RTRAM) and the banks are referred to
+  as A and B.  Each bank is either 4 or 8 lines high depending on the source
+  frame buffer format.
+
+properties:
+  compatible:
+oneOf:
+  - const: fsl,imx8qxp-dpr-channel
+  - const: fsl,imx8qm-dpr-channel
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: apb clock
+  - description: b clock
+  - description: rtram clock
+
+  clock-names:
+items:
+  - const: apb
+  - const: b
+  - const: rtram
+
+  fsl,sc-resource:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: The SCU resource ID associated with this DPRC instance.
+
+  fsl,prgs:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description: |
+  List of phandle which points to Prefetch Resolve Gaskets(PRGs)
+  associated with this DPRC instance.
+
+  power-domains:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - fsl,sc-resource
+  - fsl,prgs
+  - power-domains
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+dpr-channel@5610 {
+compatible = "fsl,imx8qxp-dpr-channel";
+reg = <0x5610 0x1>;
+interrupts = ;
+clocks = <&dc0_dpr1_lpcg IMX_LPCG_CLK_4>,
+ <&dc0_dpr1_lpcg IMX_LPCG_CLK_5>,
+ <&dc0_rtram1_lpcg IMX_LPCG_CLK_0>;
+clock-names = "apb", "b", "rtram";
+fsl,sc-resource = ;
+fsl,prgs = <&dc0_prg4>, <&dc0_prg5>;
+power-domains = <&pd IMX_SC_R_DC_0>;
+};
-- 
2.7.4

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

[PATCH v2 6/6] MAINTAINERS: add maintainer for i.MX8qxp DPU DRM driver

[Liu Ying]

Add myself as the maintainer of the i.MX8qxp DPU DRM driver.

Signed-off-by: Liu Ying 
---
v1->v2:
* No change.

 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 970d9ce..dee4586 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5834,6 +5834,15 @@ F:   Documentation/devicetree/bindings/display/imx/
 F: drivers/gpu/drm/imx/
 F: drivers/gpu/ipu-v3/
 
+DRM DRIVERS FOR FREESCALE i.MX8QXP
+M: Liu Ying 
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
+F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml
+F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
+F: drivers/gpu/drm/imx/dpu/
+
 DRM DRIVERS FOR GMA500 (Poulsbo, Moorestown and derivative chipsets)
 M: Patrik Jakobsson 
 L: dri-devel@lists.freedesktop.org
-- 
2.7.4

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

[PATCH v2 0/6] drm/imx: Introduce i.MX8qm/qxp DPU DRM

[Liu Ying]

Hi,


This patch set introduces i.MX8qm/qxp Display Processing Unit(DPU) DRM support.

DPU is comprised of a blit engine for 2D graphics, a display controller
and a command sequencer.  Outside of DPU, optional prefetch engines can
fetch data from memory prior to some DPU fetchunits of blit engine and
display controller.  The pre-fetchers support linear formats and Vivante
GPU tile formats.

Reference manual can be found at:
https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM


This patch set adds kernel modesetting support for the display controller part.
It supports two CRTCs per display controller, several planes, prefetch
engines and some properties of CRTC and plane.  Currently, the registers of
the controller is accessed without command sequencer involved, instead just by
using CPU.  DRM connectors would be created from the DPU KMS driver.


If people want to try this series with i.MX8qxp, clock patches can be found at:
https://www.spinics.net/lists/arm-kernel/msg859763.html

and, power domain patches have already landed in Shawn's
i.MX for-next git branch.

This version drops the device tree patches because we'll use new dt binding
way to support i.MX8qm/qxp clocks.  It depends on the below series to do basic
conversions for the platforms which has not landed yet:
https://www.spinics.net/lists/linux-mmc/msg61965.html


I will send other patch sets to add downstream bridges(embedded in i.MX8qxp)
to support LVDS displays.

A brief look at the pipe:
prefetch eng -> DPU -> pixel combiner -> pixel link -> pixel to DPI(pxl2dpi) ->
LVDS display bridge(LDB)

Patch 1 ~ 3 add dt-bindings for DPU and prefetch engines.
Patch 4 is a minor improvement of a macro to suppress warning as the KMS driver
uses it.
Patch 5 introduces the DPU DRM support.
Patch 6 updates MAINTAINERS.

Welcome comments, thanks.

v1->v2:
* Test this patch set also with i.MX8qm LVDS displays.
* Drop the device tree patches because we'll use new dt binding way to
  support i.MX8qm/qxp clocks.  This depends on a not-yet-landed patch set
  to do basic conversions for the platforms.
* Fix dt binding yamllint warnings.
* Require bypass0 and bypass1 clocks for both i.MX8qxp and i.MX8qm in DPU's
  dt binding documentation.
* Use new dt binding way to add clocks in the dt binding examples.
* Address several comments from Laurentiu on the DPU DRM patch.

Liu Ying (6):
  dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding
  dt-bindings: display: imx: Add i.MX8qxp/qm PRG binding
  dt-bindings: display: imx: Add i.MX8qxp/qm DPR channel binding
  drm/atomic: Avoid unused-but-set-variable warning on
for_each_old_plane_in_state
  drm/imx: Introduce i.MX8qm/qxp DPU DRM
  MAINTAINERS: add maintainer for i.MX8qxp DPU DRM driver

 .../bindings/display/imx/fsl,imx8qxp-dprc.yaml |  87 ++
 .../bindings/display/imx/fsl,imx8qxp-dpu.yaml  | 416 +
 .../bindings/display/imx/fsl,imx8qxp-prg.yaml  |  60 ++
 MAINTAINERS|   9 +
 drivers/gpu/drm/imx/Kconfig|   1 +
 drivers/gpu/drm/imx/Makefile   |   1 +
 drivers/gpu/drm/imx/dpu/Kconfig|  10 +
 drivers/gpu/drm/imx/dpu/Makefile   |  10 +
 drivers/gpu/drm/imx/dpu/dpu-constframe.c   | 170 
 drivers/gpu/drm/imx/dpu/dpu-core.c | 881 
 drivers/gpu/drm/imx/dpu/dpu-crtc.c | 926 +
 drivers/gpu/drm/imx/dpu/dpu-crtc.h |  62 ++
 drivers/gpu/drm/imx/dpu/dpu-disengcfg.c| 114 +++
 drivers/gpu/drm/imx/dpu/dpu-dprc.c | 721 
 drivers/gpu/drm/imx/dpu/dpu-dprc.h |  40 +
 drivers/gpu/drm/imx/dpu/dpu-drv.c  | 297 +++
 drivers/gpu/drm/imx/dpu/dpu-drv.h  |  28 +
 drivers/gpu/drm/imx/dpu/dpu-extdst.c   | 296 +++
 drivers/gpu/drm/imx/dpu/dpu-fetchdecode.c  | 291 +++
 drivers/gpu/drm/imx/dpu/dpu-fetcheco.c | 221 +
 drivers/gpu/drm/imx/dpu/dpu-fetchlayer.c   | 151 
 drivers/gpu/drm/imx/dpu/dpu-fetchunit.c| 609 ++
 drivers/gpu/drm/imx/dpu/dpu-fetchunit.h| 191 +
 drivers/gpu/drm/imx/dpu/dpu-fetchwarp.c| 247 ++
 drivers/gpu/drm/imx/dpu/dpu-framegen.c | 392 +
 drivers/gpu/drm/imx/dpu/dpu-gammacor.c | 220 +
 drivers/gpu/drm/imx/dpu/dpu-hscaler.c  | 272 ++
 drivers/gpu/drm/imx/dpu/dpu-kms.c  | 543 
 drivers/gpu/drm/imx/dpu/dpu-kms.h  |  23 +
 drivers/gpu/drm/imx/dpu/dpu-layerblend.c   | 345 
 drivers/gpu/drm/imx/dpu/dpu-plane.c| 703 
 drivers/gpu/drm/imx/dpu/dpu-plane.h|  56 ++
 drivers/gpu/drm/imx/dpu/dpu-prg.c  | 433 ++
 drivers/gpu/drm/imx/dpu/dpu-prg.h  |  45 +
 drivers/gpu/drm/imx/dpu/dpu-prv.h