Re: [git pull] drm fixes for v5.7-rc7

[pr-tracker-bot]

The pull request you sent on Sat, 23 May 2020 06:38:11 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-05-23

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a24deb9d68b423f3e5e190b9836d192ee3e0ff9d

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration

[bugzilla-daemon]

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

--- Comment #15 from Cyrax (ev...@hotmail.com) ---
Created attachment 289241
  --> https://bugzilla.kernel.org/attachment.cgi?id=289241=edit
dump of struct dcn_bw_internal_vars

-- 
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 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration

[bugzilla-daemon]

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

--- Comment #14 from Cyrax (ev...@hotmail.com) ---
Created attachment 289239
  --> https://bugzilla.kernel.org/attachment.cgi?id=289239=edit
backtrace created by executing bt -f command in crash utility

-- 
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 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration

[bugzilla-daemon]

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

--- Comment #13 from Cyrax (ev...@hotmail.com) ---
Created attachment 289237
  --> https://bugzilla.kernel.org/attachment.cgi?id=289237=edit
kernel log dumped from crash dump by using crash utility

-- 
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 0/4] mm/gup, drm/i915: refactor gup_fast, convert to pin_user_pages()

[John Hubbard]

On 2020-05-22 04:40, Souptick Joarder wrote:
...

3) Make it easy for an upcoming patch from Souptick, which aims to
convert __get_user_pages_fast() to use a gup_flags argument, instead
of a bool writeable arg.  Also, if this series looks good, we can
ask Souptick to change the name as well, to whatever the consensus
is. My initial recommendation is: get_user_pages_fast_only(), to
match the new pin_user_pages_only().


Shall I hold my changes till 5.8-rc1 , when this series will appear upstream ?


I don't really see any problem with your posting something that is based on
the latest linux-next (which has my changes now). Should be fine. And in
fact it would be nice to get that done in this round, so that the pin* and
get* APIs look the same.


thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/msm/a6xx: don't try to set GPU frequency when GMU is suspended

[Jordan Crouse]

On Mon, May 18, 2020 at 11:07:33PM -0400, Jonathan Marek wrote:
> This fixes changing the frequency in sysfs while suspended, for example
> when doing something like this:
> 
> cat devfreq/3d0.gpu/max_freq > devfreq/3d0.gpu/min_freq

A patch landed to fix this [1] but it crossed paths in the night with the
a640/a650 support. Can you respin this to move the pm_runtime_get_if_in_use()
check in _a6xx_gmu_set_freq() to the higher level function and then we should
be covered.

Thanks,
Jordan

[1] https://patchwork.freedesktop.org/patch/364089/?series=76829=3

> Signed-off-by: Jonathan Marek 
> ---
>  drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index aec54cde8534..9498803dcad9 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -151,13 +151,20 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned 
> long freq)
>   break;
>  
>   gmu->current_perf_index = perf_index;
> + gmu->freq = gmu->gpu_freqs[perf_index];
> +
> + /*
> +  * devfreq may try to change frequency target even when suspended
> +  * this can happen when changing frequency through sysfs
> +  * don't try to set freq when suspended, it will be set on resume
> +  */
> + if (!pm_runtime_active(gmu->dev))
> + return;
>  
>   if (gmu->legacy)
>   __a6xx_gmu_set_freq(gmu, perf_index);
>   else
>   a6xx_hfi_set_freq(gmu, perf_index);
> -
> - gmu->freq = gmu->gpu_freqs[perf_index];
>  }
>  
>  unsigned long a6xx_gmu_get_freq(struct msm_gpu *gpu)
> -- 
> 2.26.1
> 

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 0/3] drm/msm: Cleanups ahead of per-instance pagetables

[Jordan Crouse]

These are three cleanup and reorganization patches that were originally
part of one of my many per-instance pagetable stacks [1] [2] but make life
better in general and can stand on their own. Send them now to get them
out of my other stack and make that processs ever so easier.

[1] https://patchwork.kernel.org/patch/11355255/
[2] https://patchwork.kernel.org/patch/11355259/

Jordan Crouse (3):
  drm/msm: Attach the IOMMU device during initialization
  drm/msm: Refactor address space initialization
  drm/msm: Update the MMU helper function APIs

 drivers/gpu/drm/msm/adreno/a2xx_gpu.c| 16 
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c|  1 +
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c|  1 +
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c|  1 +
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c|  1 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  | 23 ---
 drivers/gpu/drm/msm/adreno/adreno_gpu.h  |  8 
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 18 +++--
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 18 -
 drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c |  4 --
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 18 -
 drivers/gpu/drm/msm/msm_drv.h|  8 +---
 drivers/gpu/drm/msm/msm_gem_vma.c| 36 +++--
 drivers/gpu/drm/msm/msm_gpu.c| 49 +---
 drivers/gpu/drm/msm/msm_gpu.h|  4 +-
 drivers/gpu/drm/msm/msm_gpummu.c | 10 +
 drivers/gpu/drm/msm/msm_iommu.c  | 15 ++--
 drivers/gpu/drm/msm/msm_mmu.h|  5 +--
 18 files changed, 95 insertions(+), 141 deletions(-)

-- 
2.17.1

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

[PATCH v1 2/3] drm/msm: Refactor address space initialization

[Jordan Crouse]

Refactor how address space initialization works. Instead of having the
address space function create the MMU object (and thus require separate but
equal functions for gpummu and iommu) use a single function and pass the
MMU struct in. Make the generic code cleaner by using target specific
functions to create the address space so a2xx can do its own thing in its
own space.  For all the other targets use a generic helper to initialize
IOMMU but leave the door open for newer targets to use customization
if they need it.

Reviewed-by: Rob Clark 
Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a2xx_gpu.c| 16 
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c|  1 +
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c|  1 +
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c|  1 +
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c|  1 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  | 23 ---
 drivers/gpu/drm/msm/adreno/adreno_gpu.h  |  8 
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 10 ++---
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 14 ---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c |  4 --
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 11 -
 drivers/gpu/drm/msm/msm_drv.h|  8 +---
 drivers/gpu/drm/msm/msm_gem_vma.c| 51 +++-
 drivers/gpu/drm/msm/msm_gpu.c| 40 +--
 drivers/gpu/drm/msm/msm_gpu.h|  4 +-
 drivers/gpu/drm/msm/msm_iommu.c  |  3 ++
 16 files changed, 82 insertions(+), 114 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
index 1f83bc18d500..60f6472a3e58 100644
--- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
@@ -401,6 +401,21 @@ static struct msm_gpu_state *a2xx_gpu_state_get(struct 
msm_gpu *gpu)
return state;
 }
 
+static struct msm_gem_address_space *
+a2xx_create_address_space(struct msm_gpu *gpu, struct platform_device *pdev)
+{
+   struct msm_mmu *mmu = msm_gpummu_new(>dev, gpu);
+   struct msm_gem_address_space *aspace;
+
+   aspace = msm_gem_address_space_create(mmu, "gpu", SZ_16M,
+   SZ_16M + 0xfff * SZ_64K);
+
+   if (IS_ERR(aspace) && !IS_ERR(mmu))
+   mmu->funcs->destroy(mmu);
+
+   return aspace;
+}
+
 /* Register offset defines for A2XX - copy of A3XX */
 static const unsigned int a2xx_register_offsets[REG_ADRENO_REGISTER_MAX] = {
REG_ADRENO_DEFINE(REG_ADRENO_CP_RB_BASE, REG_AXXX_CP_RB_BASE),
@@ -429,6 +444,7 @@ static const struct adreno_gpu_funcs funcs = {
 #endif
.gpu_state_get = a2xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
+   .create_address_space = a2xx_create_address_space,
},
 };
 
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index b67f88872726..0a5ea9f56cb8 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -441,6 +441,7 @@ static const struct adreno_gpu_funcs funcs = {
 #endif
.gpu_state_get = a3xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
+   .create_address_space = adreno_iommu_create_address_space,
},
 };
 
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 9e244982974e..b9b26b2bf9c5 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -583,6 +583,7 @@ static const struct adreno_gpu_funcs funcs = {
 #endif
.gpu_state_get = a4xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
+   .create_address_space = adreno_iommu_create_address_space,
},
.get_timestamp = a4xx_get_timestamp,
 };
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 662d02289533..d95970a73fb4 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1445,6 +1445,7 @@ static const struct adreno_gpu_funcs funcs = {
.gpu_busy = a5xx_gpu_busy,
.gpu_state_get = a5xx_gpu_state_get,
.gpu_state_put = a5xx_gpu_state_put,
+   .create_address_space = adreno_iommu_create_address_space,
},
.get_timestamp = a5xx_get_timestamp,
 };
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 6f335ae179c8..a1589e040c57 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -893,6 +893,7 @@ static const struct adreno_gpu_funcs funcs = {
 #if defined(CONFIG_DRM_MSM_GPU_STATE)
.gpu_state_get = a6xx_gpu_state_get,
.gpu_state_put = a6xx_gpu_state_put,
+   .create_address_space = adreno_iommu_create_address_space,
 #endif
},
.get_timestamp = a6xx_get_timestamp,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 

[PATCH v1 1/3] drm/msm: Attach the IOMMU device during initialization

[Jordan Crouse]

Everywhere an IOMMU object is created by msm_gpu_create_address_space
the IOMMU device is attached immediately after. Instead of carrying around
the infrastructure to do the attach from the device specific code do it
directly in the msm_iommu_init() function. This gets it out of the way for
more aggressive cleanups that follow.

Reviewed-by: Rob Clark 
Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  |  8 
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c |  4 
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c |  7 ---
 drivers/gpu/drm/msm/msm_gem_vma.c| 23 +++
 drivers/gpu/drm/msm/msm_gpu.c| 11 +--
 drivers/gpu/drm/msm/msm_gpummu.c |  6 --
 drivers/gpu/drm/msm/msm_iommu.c  |  8 +++-
 drivers/gpu/drm/msm/msm_mmu.h|  1 -
 8 files changed, 27 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 10c33cf7a5d7..c5150c67a3b8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -794,7 +794,6 @@ static int _dpu_kms_mmu_init(struct dpu_kms *dpu_kms)
 {
struct iommu_domain *domain;
struct msm_gem_address_space *aspace;
-   int ret;
 
domain = iommu_domain_alloc(_bus_type);
if (!domain)
@@ -810,13 +809,6 @@ static int _dpu_kms_mmu_init(struct dpu_kms *dpu_kms)
return PTR_ERR(aspace);
}
 
-   ret = aspace->mmu->funcs->attach(aspace->mmu);
-   if (ret) {
-   DPU_ERROR("failed to attach iommu %d\n", ret);
-   msm_gem_address_space_put(aspace);
-   return ret;
-   }
-
dpu_kms->base.aspace = aspace;
return 0;
 }
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index dda05436f716..9dba37c6344f 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -518,10 +518,6 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
}
 
kms->aspace = aspace;
-
-   ret = aspace->mmu->funcs->attach(aspace->mmu);
-   if (ret)
-   goto fail;
} else {
DRM_DEV_INFO(dev->dev, "no iommu, fallback to phys "
"contig buffers for scanout\n");
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 46c1c4707292..eba8ff480296 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -636,13 +636,6 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
}
 
kms->aspace = aspace;
-
-   ret = aspace->mmu->funcs->attach(aspace->mmu);
-   if (ret) {
-   DRM_DEV_ERROR(>dev, "failed to attach iommu: 
%d\n",
-   ret);
-   goto fail;
-   }
} else {
DRM_DEV_INFO(>dev,
 "no iommu, fallback to phys contig buffers for 
scanout\n");
diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c 
b/drivers/gpu/drm/msm/msm_gem_vma.c
index 407b7ab82818..72fc1980fff6 100644
--- a/drivers/gpu/drm/msm/msm_gem_vma.c
+++ b/drivers/gpu/drm/msm/msm_gem_vma.c
@@ -133,8 +133,8 @@ msm_gem_address_space_create(struct device *dev, struct 
iommu_domain *domain,
const char *name)
 {
struct msm_gem_address_space *aspace;
-   u64 size = domain->geometry.aperture_end -
-   domain->geometry.aperture_start;
+   u64 start = domain->geometry.aperture_start;
+   u64 size = domain->geometry.aperture_end - start;
 
aspace = kzalloc(sizeof(*aspace), GFP_KERNEL);
if (!aspace)
@@ -143,9 +143,18 @@ msm_gem_address_space_create(struct device *dev, struct 
iommu_domain *domain,
spin_lock_init(>lock);
aspace->name = name;
aspace->mmu = msm_iommu_new(dev, domain);
+   if (IS_ERR(aspace->mmu)) {
+   int ret = PTR_ERR(aspace->mmu);
 
-   drm_mm_init(>mm, (domain->geometry.aperture_start >> 
PAGE_SHIFT),
-   size >> PAGE_SHIFT);
+   kfree(aspace);
+   return ERR_PTR(ret);
+   }
+
+   /*
+* Attaching the IOMMU device changes the aperture values so use the
+* cached values instead
+*/
+   drm_mm_init(>mm, start >> PAGE_SHIFT, size >> PAGE_SHIFT);
 
kref_init(>kref);
 
@@ -166,6 +175,12 @@ msm_gem_address_space_create_a2xx(struct device *dev, 
struct msm_gpu *gpu,
spin_lock_init(>lock);
aspace->name = name;
aspace->mmu = msm_gpummu_new(dev, gpu);
+   if (IS_ERR(aspace->mmu)) {
+   int ret = PTR_ERR(aspace->mmu);
+
+   kfree(aspace);
+   return ERR_PTR(ret);
+   }
 
drm_mm_init(>mm, (va_start >> 

[PATCH v1 3/3] drm/msm: Update the MMU helper function APIs

[Jordan Crouse]

Instead of using a bare unsigned type for the length value for map/unmap
functions pass in a size_t to more correctly match up with the underlying
APIs.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/msm_gpummu.c | 4 ++--
 drivers/gpu/drm/msm/msm_iommu.c  | 4 ++--
 drivers/gpu/drm/msm/msm_mmu.h| 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gpummu.c b/drivers/gpu/drm/msm/msm_gpummu.c
index 0ad0f848560a..310a31b05faa 100644
--- a/drivers/gpu/drm/msm/msm_gpummu.c
+++ b/drivers/gpu/drm/msm/msm_gpummu.c
@@ -26,7 +26,7 @@ static void msm_gpummu_detach(struct msm_mmu *mmu)
 }
 
 static int msm_gpummu_map(struct msm_mmu *mmu, uint64_t iova,
-   struct sg_table *sgt, unsigned len, int prot)
+   struct sg_table *sgt, size_t len, int prot)
 {
struct msm_gpummu *gpummu = to_msm_gpummu(mmu);
unsigned idx = (iova - GPUMMU_VA_START) / GPUMMU_PAGE_SIZE;
@@ -54,7 +54,7 @@ static int msm_gpummu_map(struct msm_mmu *mmu, uint64_t iova,
return 0;
 }
 
-static int msm_gpummu_unmap(struct msm_mmu *mmu, uint64_t iova, unsigned len)
+static int msm_gpummu_unmap(struct msm_mmu *mmu, uint64_t iova, size_t len)
 {
struct msm_gpummu *gpummu = to_msm_gpummu(mmu);
unsigned idx = (iova - GPUMMU_VA_START) / GPUMMU_PAGE_SIZE;
diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index 627e1187d8aa..f8d5a294e1be 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -38,7 +38,7 @@ static void msm_iommu_detach(struct msm_mmu *mmu)
 }
 
 static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
-   struct sg_table *sgt, unsigned len, int prot)
+   struct sg_table *sgt, size_t len, int prot)
 {
struct msm_iommu *iommu = to_msm_iommu(mmu);
size_t ret;
@@ -49,7 +49,7 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
return (ret == len) ? 0 : -EINVAL;
 }
 
-static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t iova, unsigned len)
+static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t iova, size_t len)
 {
struct msm_iommu *iommu = to_msm_iommu(mmu);
 
diff --git a/drivers/gpu/drm/msm/msm_mmu.h b/drivers/gpu/drm/msm/msm_mmu.h
index bae9e8e67ec1..3a534ee59bf6 100644
--- a/drivers/gpu/drm/msm/msm_mmu.h
+++ b/drivers/gpu/drm/msm/msm_mmu.h
@@ -12,8 +12,8 @@
 struct msm_mmu_funcs {
void (*detach)(struct msm_mmu *mmu);
int (*map)(struct msm_mmu *mmu, uint64_t iova, struct sg_table *sgt,
-   unsigned len, int prot);
-   int (*unmap)(struct msm_mmu *mmu, uint64_t iova, unsigned len);
+   size_t len, int prot);
+   int (*unmap)(struct msm_mmu *mmu, uint64_t iova, size_t len);
void (*destroy)(struct msm_mmu *mmu);
 };
 
-- 
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 204611] amdgpu error scheduling IBs when waking from sleep

[bugzilla-daemon]

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

aeon.descrip...@gmail.com changed:

   What|Removed |Added

 CC||aeon.descrip...@gmail.com

--- Comment #8 from aeon.descrip...@gmail.com ---
Issue also present on Lenovo e585 -> "AMD Ryzen 7 2700U with Radeon Vega Mobile
Gfx"

I can provide debugging information upon request, availability permitting. 
Omitted for now, as substantially similar to Vic Luo.  I'm not just posting
this as a 'me too', I'll try to make availability to help out in whatever ways
I can.

-- 
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

[git pull] drm fixes for v5.7-rc7

[Dave Airlie]

Hi Linus,

Things seemed to have quieten down, though no i915 pull (I even gave
them an extra 12 hours in case they were late). The amdgpu floating
point fix is probably the largest, but it just moves some code around
to it doesn't do fpu stuff outside the fpu boundaries. Otherwise it's
just a couple of vmwgfx fixes (maintainer change) and two etnaviv
fixes.

Dave.

drm-fixes-2020-05-23:
drm fixes for v5.7-rc7

vmwgfx:
- change maintainers
- fix redundant assignment
- fix parameter name
- fix return value

etnaviv:
- memory leak fix when userspace passes a invalid softpin address
- off-by-one crashing the kernel in the perfmon domain iteration when
  the GPU core has both 2D and 3D capabilities

amdgpu:
- DP fix
- Floating point fix
- Fix cursor stutter issue
The following changes since commit b9bbe6ed63b2b9f2c9ee5cbd0f2c946a2723f4ce:

  Linux 5.7-rc6 (2020-05-17 16:48:37 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-05-23

for you to fetch changes up to 7d9ff5eed4146bf026c69e766ff630bc0bd555bb:

  Merge tag 'amd-drm-fixes-5.7-2020-05-21' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-05-22
10:30:51 +1000)


drm fixes for v5.7-rc7

vmwgfx:
- change maintainers
- fix redundant assignment
- fix parameter name
- fix return value

etnaviv:
- memory leak fix when userspace passes a invalid softpin address
- off-by-one crashing the kernel in the perfmon domain iteration when
  the GPU core has both 2D and 3D capabilities

amdgpu:
- DP fix
- Floating point fix
- Fix cursor stutter issue


Christian Gmeiner (1):
  drm/etnaviv: fix perfmon domain interation

Colin Ian King (1):
  drm/vmwgfx: remove redundant assignment to variable ret

Dan Carpenter (1):
  drm/etnaviv: Fix a leak in submit_pin_objects()

Dave Airlie (3):
  Merge branch 'vmwgfx-fixes-5.7' of
git://people.freedesktop.org/~sroland/linux into drm-fixes
  Merge branch 'etnaviv/fixes' of
https://git.pengutronix.de/git/lst/linux into drm-fixes
  Merge tag 'amd-drm-fixes-5.7-2020-05-21' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Guixiong Wei (1):
  drm/vmwgfx: Fix parameter name in vmw_bo_init

Jan Schmidt (1):
  drm/edid: Add Oculus Rift S to non-desktop list

Jason Yan (1):
  drm/vmwgfx: Return true in function vmw_fence_obj_signaled()

Nicholas Kazlauskas (1):
  drm/amd/display: Defer cursor lock until after VUPDATE

Rodrigo Siqueira (1):
  drm/amd/display: Remove dml_common_def file

Roland Scheidegger (1):
  drm/vmwgfx: update MAINTAINERS entry

Vladimir Stempen (1):
  drm/amd/display: DP training to set properly SCRAMBLING_DISABLE

 MAINTAINERS|  4 +-
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   | 27 +
 .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c  | 69 +-
 .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.h  |  5 ++
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_init.c  |  1 +
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_init.c  |  1 +
 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c  |  1 +
 drivers/gpu/drm/amd/display/dc/dml/Makefile|  2 -
 .../display/dc/dml/dcn20/display_rq_dlg_calc_20.h  |  1 -
 .../dc/dml/dcn20/display_rq_dlg_calc_20v2.h|  1 -
 .../display/dc/dml/dcn21/display_rq_dlg_calc_21.h  |  2 +-
 .../gpu/drm/amd/display/dc/dml/display_mode_lib.h  |  6 +-
 .../gpu/drm/amd/display/dc/dml/display_mode_vba.h  |  2 -
 .../amd/display/dc/dml/display_rq_dlg_helpers.h|  1 -
 .../amd/display/dc/dml/dml1_display_rq_dlg_calc.h  |  2 -
 .../gpu/drm/amd/display/dc/dml/dml_common_defs.c   | 43 --
 .../gpu/drm/amd/display/dc/dml/dml_common_defs.h   | 37 
 .../gpu/drm/amd/display/dc/dml/dml_inline_defs.h   | 15 -
 drivers/gpu/drm/amd/display/dc/inc/hw_sequencer.h  |  5 ++
 drivers/gpu/drm/drm_edid.c |  3 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c   |  4 +-
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c|  2 +-
 25 files changed, 137 insertions(+), 103 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/display/dc/dml/dml_common_defs.c
 delete mode 100644 drivers/gpu/drm/amd/display/dc/dml/dml_common_defs.h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: rcar-du: Fix build error

[Laurent Pinchart]

Hi Daniel,

Thank you for the patch.

On Mon, May 18, 2020 at 10:16:46PM +0200, Daniel Gomez wrote:
> Select DRM_KMS_HELPER dependency.
> 
> Build error when DRM_KMS_HELPER is not selected:
> 
> drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xd48): undefined reference to 
> `drm_atomic_helper_bridge_duplicate_state'
> drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xd50): undefined reference to 
> `drm_atomic_helper_bridge_destroy_state'
> drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xd70): undefined reference to 
> `drm_atomic_helper_bridge_reset'
> drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xdc8): undefined reference to 
> `drm_atomic_helper_connector_reset'
> drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xde0): undefined reference to 
> `drm_helper_probe_single_connector_modes'
> drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xe08): undefined reference to 
> `drm_atomic_helper_connector_duplicate_state'
> drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xe10): undefined reference to 
> `drm_atomic_helper_connector_destroy_state'
> 
> Signed-off-by: Daniel Gomez 

Reviewed-by: Laurent Pinchart 

and taken in my tree for v5.9. If you think it should get in v5.8 as a
fix, I can do so as well, could you then provide a Fixes: tag ?

> ---
>  drivers/gpu/drm/rcar-du/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> index 0919f1f159a4..f65d1489dc50 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -31,6 +31,7 @@ config DRM_RCAR_DW_HDMI
>  config DRM_RCAR_LVDS
>   tristate "R-Car DU LVDS Encoder Support"
>   depends on DRM && DRM_BRIDGE && OF
> + select DRM_KMS_HELPER
>   select DRM_PANEL
>   select OF_FLATTREE
>   select OF_OVERLAY

-- 
Regards,

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

Re: [PATCH 15/21] drm/rcar-du: Use GEM CMA object functions

[Laurent Pinchart]

Hi Thomas,

Thank you for the patch.

On Fri, May 22, 2020 at 03:52:40PM +0200, Thomas Zimmermann wrote:
> The rcar-du driver uses the default implementation for CMA functions;
> except for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro
> now sets these defaults and .dumb_create in struct drm_driver. All
> remaining operations are provided by CMA GEM object functions.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 3e67cf70f0402..3728038cec1d1 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -476,16 +476,7 @@ DEFINE_DRM_GEM_CMA_FOPS(rcar_du_fops);
>  
>  static struct drm_driver rcar_du_driver = {
>   .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> - .gem_vm_ops = _gem_cma_vm_ops,
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> - .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> - .dumb_create= rcar_du_dumb_create,
> + __DRM_GEM_CMA_DRIVER_OPS(rcar_du_dumb_create),

Your __DRM_GEM_CMA_DRIVER_OPS is defined as

#define __DRM_GEM_CMA_DRIVER_OPS(__dumb_create) \
.gem_create_object  = drm_cma_gem_create_object_default_funcs, \
.dumb_create= (__dumb_create), \
.prime_handle_to_fd = drm_gem_prime_handle_to_fd, \
.prime_fd_to_handle = drm_gem_prime_fd_to_handle, \
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table_vmap, \
.gem_prime_mmap = drm_gem_prime_mmap

The patch thus introduces several changes:

- drm_gem_cma_prime_import_sg_table_vmap() is used instead of
  drm_gem_cma_prime_import_sg_table() combined with .gem_prime_vmap()
  and .gem_prime_vunmap(). I believe that's fine, but splitting that
  change in a separate commit, or at the very least explaining it in
  details in the commit message, would make review easier.

- .gem_create_object() is now set. That seems to be OK, but I'm not sure
  to grasp all the implications. This should also be explained in the
  commit message, and ideally split to a separate patch.

- drm_gem_cma_prime_mmap() is replaced with drm_gem_prime_mmap(). Same
  comments :-)

This patch hides way too many changes in what is documented as just
innocent refactoring. It seems other drivers are affected too.

>   .fops   = _du_fops,
>   .name   = "rcar-du",
>   .desc   = "Renesas R-Car Display Unit",

-- 
Regards,

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

Re: [PATCH 01/21] drm/cma-helper: Rework DRM_GEM_CMA_VMAP_DRIVER_OPS macro

[Laurent Pinchart]

Hello,

On Fri, May 22, 2020 at 07:48:35PM +0200, Sam Ravnborg wrote:
> On Fri, May 22, 2020 at 03:52:26PM +0200, Thomas Zimmermann wrote:
> > Rename the macro to DRM_GEM_CMA_DRIVER_OPS to align with SHMEM
> > helpers.
>
> This part is fine, I like that the naming is somehow consistent.
> 
> > An internal version is provided for drivers that override
> > the default .dumb_create callback. Adapt drivers to the changes.
> I loathe anything named __foo or __FOO. This __ signals to me
> that the author was clueless in naming - or some sort.
> I know that __ is used in some lib headers - but thats not the case
> here.
> 
> But I love that we have a variant that takes a create function.
> So we do not have to escape from the nice macro.
> The macro is another way to tell me as rewiewer that this
> drivers uses all the default helpers for this.
> 
> 
> So critizising the name I better suggest something that
> I personally like better:
> 
> DRM_GEM_CMA_DRIVER_OPS_CREATE()
> 
> It would look like this:
>   /* GEM Operations */
> - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> - .dumb_create= drm_sun4i_gem_dumb_create,
> + DRM_GEM_CMA_DRIVER_OPS_CREATE(drm_sun4i_gem_dumb_create),

I agree with Sam here. With this change,

Reviewed-by: Laurent Pinchart 

> Please fix zte/zx_drm_drv.c which also uses DRM_GEM_CMA_VMAP_DRIVER_OPS.
> 
> The naming is a bikeshedding topic that we may not agree on, soo..
> 
> With zte fixed the patch is:
> Reviewed-by: Sam Ravnborg 
> 
> > Signed-off-by: Thomas Zimmermann 
> > ---
> >  drivers/gpu/drm/drm_gem_cma_helper.c |  2 +-
> >  drivers/gpu/drm/sun4i/sun4i_drv.c|  3 +--
> >  drivers/gpu/drm/tidss/tidss_drv.c|  2 +-
> >  drivers/gpu/drm/tiny/hx8357d.c   |  2 +-
> >  drivers/gpu/drm/tiny/ili9225.c   |  2 +-
> >  drivers/gpu/drm/tiny/ili9341.c   |  2 +-
> >  drivers/gpu/drm/tiny/ili9486.c   |  2 +-
> >  drivers/gpu/drm/tiny/mi0283qt.c  |  2 +-
> >  drivers/gpu/drm/tiny/repaper.c   |  2 +-
> >  drivers/gpu/drm/tiny/st7586.c|  2 +-
> >  drivers/gpu/drm/tiny/st7735r.c   |  2 +-
> >  include/drm/drm_gem_cma_helper.h | 24 
> >  12 files changed, 31 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
> > b/drivers/gpu/drm/drm_gem_cma_helper.c
> > index 12e98fb28229d..6fa4d2f2e3987 100644
> > --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> > @@ -620,7 +620,7 @@ EXPORT_SYMBOL(drm_cma_gem_create_object_default_funcs);
> >   * address set. This address is released when the object is freed.
> >   *
> >   * This function can be used as the _driver.gem_prime_import_sg_table
> > - * callback. The DRM_GEM_CMA_VMAP_DRIVER_OPS() macro provides a shortcut 
> > to set
> > + * callback. The _GEM_CMA_DRIVER_OPS macro provides a shortcut to set
> >   * the necessary DRM driver operations.
> >   *
> >   * Returns:
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> > b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > index 328272ff77d84..012855fd89c24 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > @@ -52,8 +52,7 @@ static struct drm_driver sun4i_drv_driver = {
> > .minor  = 0,
> >  
> > /* GEM Operations */
> > -   DRM_GEM_CMA_VMAP_DRIVER_OPS,
> > -   .dumb_create= drm_sun4i_gem_dumb_create,
> > +   __DRM_GEM_CMA_DRIVER_OPS(drm_sun4i_gem_dumb_create),
> >  };
> >  
> >  static int sun4i_drv_bind(struct device *dev)
> > diff --git a/drivers/gpu/drm/tidss/tidss_drv.c 
> > b/drivers/gpu/drm/tidss/tidss_drv.c
> > index 99edc66ebdef2..1753cdc74ebda 100644
> > --- a/drivers/gpu/drm/tidss/tidss_drv.c
> > +++ b/drivers/gpu/drm/tidss/tidss_drv.c
> > @@ -112,7 +112,7 @@ static struct drm_driver tidss_driver = {
> > .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> > .fops   = _fops,
> > .release= tidss_release,
> > -   DRM_GEM_CMA_VMAP_DRIVER_OPS,
> > +   DRM_GEM_CMA_DRIVER_OPS,
> > .name   = "tidss",
> > .desc   = "TI Keystone DSS",
> > .date   = "20180215",
> > diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c
> > index b4bc358a3269a..592da71d7ca70 100644
> > --- a/drivers/gpu/drm/tiny/hx8357d.c
> > +++ b/drivers/gpu/drm/tiny/hx8357d.c
> > @@ -196,7 +196,7 @@ DEFINE_DRM_GEM_CMA_FOPS(hx8357d_fops);
> >  static struct drm_driver hx8357d_driver = {
> > .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> > .fops   = _fops,
> > -   DRM_GEM_CMA_VMAP_DRIVER_OPS,
> > +   DRM_GEM_CMA_DRIVER_OPS,
> > .debugfs_init   = mipi_dbi_debugfs_init,
> > .name   = "hx8357d",
> > .desc   = "HX8357D",
> > diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c
> > index d1a5ab6747d5c..368ff6c8a1efb 100644
> > --- 

Re: [PATCH 05/21] drm/atmel-hlcdc: Use GEM CMA object functions

[Sam Ravnborg]

Hi Thomas.

On Fri, May 22, 2020 at 03:52:30PM +0200, Thomas Zimmermann wrote:
> The atmel-hlcdc driver uses the default implementation for CMA functions. The
> DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
> All remaining operations are provided by CMA GEM object functions.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 112aa5066ceed..871293d1aeeba 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -821,16 +821,7 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
>   .irq_preinstall = atmel_hlcdc_dc_irq_uninstall,
>   .irq_postinstall = atmel_hlcdc_dc_irq_postinstall,
>   .irq_uninstall = atmel_hlcdc_dc_irq_uninstall,
> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> - .gem_vm_ops = _gem_cma_vm_ops,
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> - .gem_prime_vunmap = drm_gem_cma_prime_vunmap,

> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
When using DRM_GEM_CMA_DRIVER_OPS gem_prime_mmap is set to
drm_gem_prime_mmap.
Why is this the same as drm_gem_cma_prime_mmap?

Maybe this is all obvious when you know all the CMA stuff,
but this puzzeled me.

Sam


> - .dumb_create = drm_gem_cma_dumb_create,
> + DRM_GEM_CMA_DRIVER_OPS,
>   .fops = ,
>   .name = "atmel-hlcdc",
>   .desc = "Atmel HLCD Controller DRM",
> -- 
> 2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 21/21] drm/zte: Use GEM CMA object functions

[Sam Ravnborg]

Hi Thomas.

On Fri, May 22, 2020 at 03:52:46PM +0200, Thomas Zimmermann wrote:
> The zte driver uses the default implementation for CMA functions. The
> DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
> All remaining operations are provided by CMA GEM object functions.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/zte/zx_drm_drv.c | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c 
> b/drivers/gpu/drm/zte/zx_drm_drv.c
> index 1141c1ed1ed04..42c59eae0ea03 100644
> --- a/drivers/gpu/drm/zte/zx_drm_drv.c
> +++ b/drivers/gpu/drm/zte/zx_drm_drv.c
> @@ -36,16 +36,7 @@ DEFINE_DRM_GEM_CMA_FOPS(zx_drm_fops);
>  
>  static struct drm_driver zx_drm_driver = {
>   .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> - .gem_vm_ops = _gem_cma_vm_ops,
> - .dumb_create = drm_gem_cma_dumb_create,
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> - .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> + DRM_GEM_CMA_VMAP_DRIVER_OPS,
s/_VMAP// as pointed out by Emil.

Sam

>   .fops = _drm_fops,
>   .name = "zx-vou",
>   .desc = "ZTE VOU Controller DRM",
> -- 
> 2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] linux/bits.h: adjust GENMASK_INPUT_CHECK() check

[Emil Velikov]

Hi Rikard,


On 2020/05/19, Rikard Falkeborn wrote:
> + Andrew et al who recieved mail from the build robot this morning about
> the same issue.
> 
> On Tue, May 19, 2020 at 10:14:52PM +0100, Emil Velikov wrote:
> > Recently the GENMASK_INPUT_CHECK() was added, aiming to catch cases
> > where there GENMASK arguments are flipped.
> > 
> > Although it seems to be triggering -Wtype-limits in the following cases:
> > 
> >unsigned foo = (10 + x);
> >unsigned bar = GENMASK(foo, 0);
> > 
> >const unsigned foo = (10 + x);
> >unsigned bar = GENMASK(foo, 0);
> > 
> > Here are the warnings, from my GCC 9.2 box.
> > 
> > warning: comparison of unsigned expression < 0 is always false 
> > [-Wtype-limits]
> >__builtin_constant_p((l) > (h)), (l) > (h), 0)))
> > ^
> > warning: comparison of unsigned expression < 0 is always false 
> > [-Wtype-limits]
> >__builtin_constant_p((l) > (h)), (l) > (h), 0)))
> > ^
> > 
> > This results in people disabling the warning all together or promoting
> > foo to signed. Either of which being a sub par option IMHO.
> > 
> > Add a trivial "+ 1" to each h and l in the constant expression.
> > 
> > v2: drop accidental !
> > 
> > Fixes: 295bcca84916 ("linux/bits.h: add compile time sanity check of
> > GENMASK inputs")
> > Cc: Rikard Falkeborn 
> > Cc: Linus Torvalds 
> > Cc: Chris Wilson 
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Emil Velikov 
> > Reported-by: kbuild test robot 
> > Reported-by: kbuild test robot 
> > ---
> >  include/linux/bits.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/include/linux/bits.h b/include/linux/bits.h
> > index 4671fbf28842..02a42866d198 100644
> > --- a/include/linux/bits.h
> > +++ b/include/linux/bits.h
> > @@ -23,7 +23,7 @@
> >  #include 
> >  #define GENMASK_INPUT_CHECK(h, l) \
> > (BUILD_BUG_ON_ZERO(__builtin_choose_expr( \
> > -   __builtin_constant_p((l) > (h)), (l) > (h), 0)))
> > +   __builtin_constant_p((l + 1) > (h + 1)), (l + 1) > (h + 1), 0)))
> 
> You need parentheses around l and h here.
> 
Sure will do.

> I think I would have prefered a cast to int here instead but I'm fine
> with either (I don't think pragmas for disabling the warning can be used
> since the check is added to the mask). Either way, I think we need a
> comment on why this is done.

How about:

Add trivial "+ 1" when to the h/l arguments. Without this GCC will
complain when comparing unsigned vs 0. Depending on the GCC version,
that can happen within __builtin_constant_p and/or the BUILD_BUG_ON_ZERO
macro.


> 
> >  #else
> >  /*
> >   * BUILD_BUG_ON_ZERO is not available in h files included from asm files,
> > -- 
> > 2.25.1
> > 
> 
> I can't reproduce this with gcc 10 and kernelci.org does not show the
> warning (but those builds seem to be gcc 8 only, so maybe this is a gcc
> 9 thing only). A bit strange this shows up now, it's been in Linus's
> tree for six weeks and in next for even longer, but oh well.
> 
I would imagine that people either use "interesting" workarounds like
this [1], or outright disable -Wtype-limits - grep for Wtype-limits.

I'm glad that GCC 10 is saner, although it's far from being the minimum
required for building the kernel :-\


Let me know if the above comment works for you and I'll send out the
next revision.


Thanks
Emil

[1]
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=2803aa743fd38f66acca555ae6e5fc677bb71251
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/21] drm/cma-helper: Rework DRM_GEM_CMA_VMAP_DRIVER_OPS macro

[Sam Ravnborg]

Hi Emil.

> > Please fix zte/zx_drm_drv.c which also uses DRM_GEM_CMA_VMAP_DRIVER_OPS.
> >
> Isn't DRM_GEM_CMA_VMAP_DRIVER_OPS introduced to zte with the last
> patch in the series?

You are right, I just applied all patches and throw them after my
build script and zte failed.

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

Re: [PATCH 00/21] drm: Convert most CMA-based drivers to GEM object functions

[Emil Velikov]

Hi Thomas,

On Fri, 22 May 2020 at 14:53, Thomas Zimmermann  wrote:

>  32 files changed, 52 insertions(+), 226 deletions(-)
>
We need more diffstat like this. With this series the .gem_print_info
is no longer set.
Feel free to follow-up and nuke it, alongside the glue in drm_gem.c.

There's a small comment in the kirin patch - with that resolved the series is:
Acked-by: Emil Velikov 

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

Re: [PATCH] drm/vblank: Fix -Wformat compile warnings on some arches

[Lyude Paul]

On Thu, 2020-05-21 at 23:09 +0200, Sam Ravnborg wrote:
> On Thu, May 21, 2020 at 04:46:47PM -0400, Lyude Paul wrote:
> > On some architectures like ppc64le and aarch64, compiling with
> > -Wformat=1 will throw the following warnings:
> > 
> >   In file included from drivers/gpu/drm/drm_vblank.c:33:
> >   drivers/gpu/drm/drm_vblank.c: In function 'drm_update_vblank_count':
> >   drivers/gpu/drm/drm_vblank.c:273:16: warning: format '%llu' expects
> >   argument of type 'long long unsigned int', but argument 4 has type
> >   'long int' [-Wformat=]
> > DRM_DEBUG_VBL("updating vblank count on crtc %u:"
> >   ^~~
> >   ./include/drm/drm_print.h:407:22: note: in definition of macro
> >   'DRM_DEBUG_VBL'
> > drm_dbg(DRM_UT_VBL, fmt, ##__VA_ARGS__)
> > ^~~
> >   drivers/gpu/drm/drm_vblank.c:274:22: note: format string is defined here
> >" current=%llu, diff=%u, hw=%u hw_last=%u\n",
> >  ~~~^
> >  %lu
> > 
> > So, fix that with a typecast.
> > 
> > Signed-off-by: Lyude Paul 
> > Co-developed-by: Dave Airlie 
> > ---
> >  drivers/gpu/drm/drm_vblank.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > index acb3c3f65b579..1a96db2dd16fa 100644
> > --- a/drivers/gpu/drm/drm_vblank.c
> > +++ b/drivers/gpu/drm/drm_vblank.c
> > @@ -342,7 +342,7 @@ static void drm_update_vblank_count(struct drm_device
> > *dev, unsigned int pipe,
> >  
> > DRM_DEBUG_VBL("updating vblank count on crtc %u:"
> >   " current=%llu, diff=%u, hw=%u hw_last=%u\n",
> > - pipe, atomic64_read(>count), diff,
> > + pipe, (unsigned long long)atomic64_read(>count),
> > diff,
> >   cur_vblank, vblank->last);
> 
> While touching this you could consider introducing drm_dbg_vbl().
> An maybe as a follow-up patch replace all logging in this file with the drm_*
> variants.

ok - no promises when I can actually get to this though, I've got a lot on my
plate ATM
> 
>   Sam
> 
> >  
> > if (diff == 0) {
> > -- 
> > 2.26.2
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH 01/21] drm/cma-helper: Rework DRM_GEM_CMA_VMAP_DRIVER_OPS macro

[Emil Velikov]

On Fri, 22 May 2020 at 18:48, Sam Ravnborg  wrote:
>
> Hi Thomas.
>
> On Fri, May 22, 2020 at 03:52:26PM +0200, Thomas Zimmermann wrote:
> > Rename the macro to DRM_GEM_CMA_DRIVER_OPS to align with SHMEM
> > helpers.
> This part is fine, I like that the naming is somehow consistent.
>
> > An internal version is provided for drivers that override
> > the default .dumb_create callback. Adapt drivers to the changes.
> I loathe anything named __foo or __FOO. This __ signals to me
> that the author was clueless in naming - or some sort.
> I know that __ is used in some lib headers - but thats not the case
> here.
>
> But I love that we have a variant that takes a create function.
> So we do not have to escape from the nice macro.
> The macro is another way to tell me as rewiewer that this
> drivers uses all the default helpers for this.
>
Fwiw I share the sentiment, although I fear we're a little late. __
prefixed functions are widely common in core drm and it's helpers.

>
> So critizising the name I better suggest something that
> I personally like better:
>
> DRM_GEM_CMA_DRIVER_OPS_CREATE()
>
> It would look like this:
> /* GEM Operations */
> -   DRM_GEM_CMA_VMAP_DRIVER_OPS,
> -   .dumb_create= drm_sun4i_gem_dumb_create,
> +   DRM_GEM_CMA_DRIVER_OPS_CREATE(drm_sun4i_gem_dumb_create),
>
>
>
> Please fix zte/zx_drm_drv.c which also uses DRM_GEM_CMA_VMAP_DRIVER_OPS.
>
Isn't DRM_GEM_CMA_VMAP_DRIVER_OPS introduced to zte with the last
patch in the series?

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

Re: [PATCH 07/21] drm/hisilicon/kirin: Use GEM CMA object functions

[Emil Velikov]

Hi Thomas,

On Fri, 22 May 2020 at 14:53, Thomas Zimmermann  wrote:
>
> The kirin driver uses the default implementation for CMA functions; except
> for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro now sets
> these defaults and .dumb_create in struct drm_driver. All remaining
> operations are provided by CMA GEM object functions.
>
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> index c339e632522a9..b1ffd7d43e562 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> @@ -921,17 +921,7 @@ DEFINE_DRM_GEM_CMA_FOPS(ade_fops);
>  static struct drm_driver ade_driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .fops = _fops,
> -   .gem_free_object_unlocked = drm_gem_cma_free_object,
> -   .gem_vm_ops = _gem_cma_vm_ops,
> -   .dumb_create = drm_gem_cma_dumb_create_internal,

This doesn't seem right. The _internal documentation explicitly says
that this should _not_ be used as .dumb_create. Instead drivers should
use it to implement their callback.

Since it yields the same result as drm_gem_cma_dumb_create we can use
the default macro below.

Weather to the .dumb_create in separate patch, or squash it here -
I'll leave to you.
In case of the latter, please mentioned it in the commit message.

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

Re: [PATCH 05/21] drm/atmel-hlcdc: Use GEM CMA object functions

[Sam Ravnborg]

Hi Thomas.

On Fri, May 22, 2020 at 03:52:30PM +0200, Thomas Zimmermann wrote:
> The atmel-hlcdc driver uses the default implementation for CMA functions. The
> DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
> All remaining operations are provided by CMA GEM object functions.

A nice side-effect of introducing the defualt implementation
of CMA functions is that this driver is now migrated over to use
drm_gem_object_funcs, which is why we can replace all these
helpers with a simple macro that defined only 6 helpers.

With an improved changelog:
Reviewed-by: Sam Ravnborg 

And as I said in the other mail, this is really nice.
It is now much more obvious that this drivers uses
all the default helpers for CMA.

And I can drop one item from my TODO list on top of that.

Sam

> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 112aa5066ceed..871293d1aeeba 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -821,16 +821,7 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
>   .irq_preinstall = atmel_hlcdc_dc_irq_uninstall,
>   .irq_postinstall = atmel_hlcdc_dc_irq_postinstall,
>   .irq_uninstall = atmel_hlcdc_dc_irq_uninstall,
> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> - .gem_vm_ops = _gem_cma_vm_ops,
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> - .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> - .dumb_create = drm_gem_cma_dumb_create,
> + DRM_GEM_CMA_DRIVER_OPS,
>   .fops = ,
>   .name = "atmel-hlcdc",
>   .desc = "Atmel HLCD Controller DRM",
> -- 
> 2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/[radeon|amdgpu]: Replace one-element array and use struct_size() helper

[Alex Deucher]

On Fri, May 22, 2020 at 1:39 PM Gustavo A. R. Silva
 wrote:
>
> The current codebase makes use of one-element arrays in the following
> form:
>
> struct something {
> int length;
> u8 data[1];
> };
>
> struct something *instance;
>
> instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
> instance->length = size;
> memcpy(instance->data, source, size);
>
> but the preferred mechanism to declare variable-length types such as
> these ones is a flexible array member[1][2], introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> By making use of the mechanism above, we will get a compiler warning
> in case the flexible array does not occur last in the structure, which
> will help us prevent some kind of undefined behavior bugs from being
> inadvertently introduced[3] to the codebase from now on. So, replace
> the one-element array with a flexible-array member.
>
> Also, make use of the new struct_size() helper to properly calculate the
> size of struct SISLANDS_SMC_SWSTATE.
>
> This issue was found with the help of Coccinelle and, audited and fixed
> _manually_.
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [2] https://github.com/KSPP/linux/issues/21
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
>
> Signed-off-by: Gustavo A. R. Silva 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/si_dpm.c   | 5 ++---
>  drivers/gpu/drm/amd/amdgpu/sislands_smc.h | 2 +-
>  drivers/gpu/drm/radeon/si_dpm.c   | 5 ++---
>  3 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.c 
> b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
> index c00ba4b23c9a6..0fc56c5bac080 100644
> --- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
> @@ -5715,10 +5715,9 @@ static int si_upload_sw_state(struct amdgpu_device 
> *adev,
> int ret;
> u32 address = si_pi->state_table_start +
> offsetof(SISLANDS_SMC_STATETABLE, driverState);
> -   u32 state_size = sizeof(SISLANDS_SMC_SWSTATE) +
> -   ((new_state->performance_level_count - 1) *
> -sizeof(SISLANDS_SMC_HW_PERFORMANCE_LEVEL));
> SISLANDS_SMC_SWSTATE *smc_state = _pi->smc_statetable.driverState;
> +   size_t state_size = struct_size(smc_state, levels,
> +   new_state->performance_level_count);
>
> memset(smc_state, 0, state_size);
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/sislands_smc.h 
> b/drivers/gpu/drm/amd/amdgpu/sislands_smc.h
> index d2930eceaf3c8..a089dbf8f7a93 100644
> --- a/drivers/gpu/drm/amd/amdgpu/sislands_smc.h
> +++ b/drivers/gpu/drm/amd/amdgpu/sislands_smc.h
> @@ -186,7 +186,7 @@ struct SISLANDS_SMC_SWSTATE
>  uint8_t levelCount;
>  uint8_t padding2;
>  uint8_t padding3;
> -SISLANDS_SMC_HW_PERFORMANCE_LEVEL   levels[1];
> +SISLANDS_SMC_HW_PERFORMANCE_LEVEL   levels[];
>  };
>
>  typedef struct SISLANDS_SMC_SWSTATE SISLANDS_SMC_SWSTATE;
> diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
> index a167e1c36d243..bab01ca864c63 100644
> --- a/drivers/gpu/drm/radeon/si_dpm.c
> +++ b/drivers/gpu/drm/radeon/si_dpm.c
> @@ -5253,10 +5253,9 @@ static int si_upload_sw_state(struct radeon_device 
> *rdev,
> int ret;
> u32 address = si_pi->state_table_start +
> offsetof(SISLANDS_SMC_STATETABLE, driverState);
> -   u32 state_size = sizeof(SISLANDS_SMC_SWSTATE) +
> -   ((new_state->performance_level_count - 1) *
> -sizeof(SISLANDS_SMC_HW_PERFORMANCE_LEVEL));
> SISLANDS_SMC_SWSTATE *smc_state = _pi->smc_statetable.driverState;
> +   size_t state_size = struct_size(smc_state, levels,
> +   new_state->performance_level_count);
>
> memset(smc_state, 0, state_size);
>
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/radeon/dpm: Replace one-element array and use struct_size() helper

[Alex Deucher]

On Fri, May 22, 2020 at 1:29 PM Gustavo A. R. Silva
 wrote:
>
> The current codebase makes use of one-element arrays in the following
> form:
>
> struct something {
> int length;
> u8 data[1];
> };
>
> struct something *instance;
>
> instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
> instance->length = size;
> memcpy(instance->data, source, size);
>
> but the preferred mechanism to declare variable-length types such as
> these ones is a flexible array member[1][2], introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> By making use of the mechanism above, we will get a compiler warning
> in case the flexible array does not occur last in the structure, which
> will help us prevent some kind of undefined behavior bugs from being
> inadvertently introduced[3] to the codebase from now on. So, replace
> the one-element array with a flexible-array member.
>
> Also, make use of the new struct_size() helper to properly calculate the
> size of struct NISLANDS_SMC_SWSTATE.
>
> This issue was found with the help of Coccinelle and, audited and fixed
> _manually_.
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [2] https://github.com/KSPP/linux/issues/21
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
>
> Reviewed-by: Christian König 
> Signed-off-by: Gustavo A. R. Silva 

Applied.  Thanks!

Alex

> ---
> Changes in v2:
>  - Use type size_t instead of u16 for state_size variable.
>
>  drivers/gpu/drm/amd/amdgpu/si_dpm.h | 2 +-
>  drivers/gpu/drm/radeon/ni_dpm.c | 7 ---
>  2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.h 
> b/drivers/gpu/drm/amd/amdgpu/si_dpm.h
> index 6b7d292b919f3..bc0be6818e218 100644
> --- a/drivers/gpu/drm/amd/amdgpu/si_dpm.h
> +++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.h
> @@ -781,7 +781,7 @@ struct NISLANDS_SMC_SWSTATE
>  uint8_t levelCount;
>  uint8_t padding2;
>  uint8_t padding3;
> -NISLANDS_SMC_HW_PERFORMANCE_LEVEL   levels[1];
> +NISLANDS_SMC_HW_PERFORMANCE_LEVEL   levels[];
>  };
>
>  typedef struct NISLANDS_SMC_SWSTATE NISLANDS_SMC_SWSTATE;
> diff --git a/drivers/gpu/drm/radeon/ni_dpm.c b/drivers/gpu/drm/radeon/ni_dpm.c
> index b57c37ddd164c..abb6345bfae32 100644
> --- a/drivers/gpu/drm/radeon/ni_dpm.c
> +++ b/drivers/gpu/drm/radeon/ni_dpm.c
> @@ -2685,11 +2685,12 @@ static int ni_upload_sw_state(struct radeon_device 
> *rdev,
> struct rv7xx_power_info *pi = rv770_get_pi(rdev);
> u16 address = pi->state_table_start +
> offsetof(NISLANDS_SMC_STATETABLE, driverState);
> -   u16 state_size = sizeof(NISLANDS_SMC_SWSTATE) +
> -   ((NISLANDS_MAX_SMC_PERFORMANCE_LEVELS_PER_SWSTATE - 1) * 
> sizeof(NISLANDS_SMC_HW_PERFORMANCE_LEVEL));
> +   NISLANDS_SMC_SWSTATE *smc_state;
> +   size_t state_size = struct_size(smc_state, levels,
> +   NISLANDS_MAX_SMC_PERFORMANCE_LEVELS_PER_SWSTATE);
> int ret;
> -   NISLANDS_SMC_SWSTATE *smc_state = kzalloc(state_size, GFP_KERNEL);
>
> +   smc_state = kzalloc(state_size, GFP_KERNEL);
> if (smc_state == NULL)
> return -ENOMEM;
>
> --
> 2.26.2
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu/smu10: Replace one-element array and use struct_size() helper

[Alex Deucher]

On Fri, May 22, 2020 at 1:46 PM Gustavo A. R. Silva
 wrote:
>
> On Wed, May 20, 2020 at 09:42:27AM +0200, Christian König wrote:
> > >
> > > Signed-off-by: Gustavo A. R. Silva 
> >
> > Acked-by: Christian König 
> >
> > May I suggest that we add a section how to correctly do this to
> > Documentation/process/coding-style.rst or similar document?
> >
>
> That's already on my list. :)
>
> > I've seen a bunch of different approaches and some even doesn't work with
> > some gcc versions and result in a broken binary.
> >
>
> Do you have an example of that one that doesn't work with some GCC
> versions? It'd be interesting to take a look...

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/radeon/radeon_atombios.c?id=a7ee824a6255e347ea76e2f00827e81bbe01004e

Alex

>
> Thanks
> --
> Gustavo
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/21] drm/cma-helper: Rework DRM_GEM_CMA_VMAP_DRIVER_OPS macro

[Sam Ravnborg]

Hi Thomas.

On Fri, May 22, 2020 at 03:52:26PM +0200, Thomas Zimmermann wrote:
> Rename the macro to DRM_GEM_CMA_DRIVER_OPS to align with SHMEM
> helpers.
This part is fine, I like that the naming is somehow consistent.

> An internal version is provided for drivers that override
> the default .dumb_create callback. Adapt drivers to the changes.
I loathe anything named __foo or __FOO. This __ signals to me
that the author was clueless in naming - or some sort.
I know that __ is used in some lib headers - but thats not the case
here.

But I love that we have a variant that takes a create function.
So we do not have to escape from the nice macro.
The macro is another way to tell me as rewiewer that this
drivers uses all the default helpers for this.


So critizising the name I better suggest something that
I personally like better:

DRM_GEM_CMA_DRIVER_OPS_CREATE()

It would look like this:
/* GEM Operations */
-   DRM_GEM_CMA_VMAP_DRIVER_OPS,
-   .dumb_create= drm_sun4i_gem_dumb_create,
+   DRM_GEM_CMA_DRIVER_OPS_CREATE(drm_sun4i_gem_dumb_create),



Please fix zte/zx_drm_drv.c which also uses DRM_GEM_CMA_VMAP_DRIVER_OPS.


The naming is a bikeshedding topic that we may not agree on, soo..

With zte fixed the patch is:
Reviewed-by: Sam Ravnborg 

Sam


> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/drm_gem_cma_helper.c |  2 +-
>  drivers/gpu/drm/sun4i/sun4i_drv.c|  3 +--
>  drivers/gpu/drm/tidss/tidss_drv.c|  2 +-
>  drivers/gpu/drm/tiny/hx8357d.c   |  2 +-
>  drivers/gpu/drm/tiny/ili9225.c   |  2 +-
>  drivers/gpu/drm/tiny/ili9341.c   |  2 +-
>  drivers/gpu/drm/tiny/ili9486.c   |  2 +-
>  drivers/gpu/drm/tiny/mi0283qt.c  |  2 +-
>  drivers/gpu/drm/tiny/repaper.c   |  2 +-
>  drivers/gpu/drm/tiny/st7586.c|  2 +-
>  drivers/gpu/drm/tiny/st7735r.c   |  2 +-
>  include/drm/drm_gem_cma_helper.h | 24 
>  12 files changed, 31 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 12e98fb28229d..6fa4d2f2e3987 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -620,7 +620,7 @@ EXPORT_SYMBOL(drm_cma_gem_create_object_default_funcs);
>   * address set. This address is released when the object is freed.
>   *
>   * This function can be used as the _driver.gem_prime_import_sg_table
> - * callback. The DRM_GEM_CMA_VMAP_DRIVER_OPS() macro provides a shortcut to 
> set
> + * callback. The _GEM_CMA_DRIVER_OPS macro provides a shortcut to set
>   * the necessary DRM driver operations.
>   *
>   * Returns:
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 328272ff77d84..012855fd89c24 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -52,8 +52,7 @@ static struct drm_driver sun4i_drv_driver = {
>   .minor  = 0,
>  
>   /* GEM Operations */
> - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> - .dumb_create= drm_sun4i_gem_dumb_create,
> + __DRM_GEM_CMA_DRIVER_OPS(drm_sun4i_gem_dumb_create),
>  };
>  
>  static int sun4i_drv_bind(struct device *dev)
> diff --git a/drivers/gpu/drm/tidss/tidss_drv.c 
> b/drivers/gpu/drm/tidss/tidss_drv.c
> index 99edc66ebdef2..1753cdc74ebda 100644
> --- a/drivers/gpu/drm/tidss/tidss_drv.c
> +++ b/drivers/gpu/drm/tidss/tidss_drv.c
> @@ -112,7 +112,7 @@ static struct drm_driver tidss_driver = {
>   .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
>   .fops   = _fops,
>   .release= tidss_release,
> - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> + DRM_GEM_CMA_DRIVER_OPS,
>   .name   = "tidss",
>   .desc   = "TI Keystone DSS",
>   .date   = "20180215",
> diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c
> index b4bc358a3269a..592da71d7ca70 100644
> --- a/drivers/gpu/drm/tiny/hx8357d.c
> +++ b/drivers/gpu/drm/tiny/hx8357d.c
> @@ -196,7 +196,7 @@ DEFINE_DRM_GEM_CMA_FOPS(hx8357d_fops);
>  static struct drm_driver hx8357d_driver = {
>   .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
>   .fops   = _fops,
> - DRM_GEM_CMA_VMAP_DRIVER_OPS,
> + DRM_GEM_CMA_DRIVER_OPS,
>   .debugfs_init   = mipi_dbi_debugfs_init,
>   .name   = "hx8357d",
>   .desc   = "HX8357D",
> diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c
> index d1a5ab6747d5c..368ff6c8a1efb 100644
> --- a/drivers/gpu/drm/tiny/ili9225.c
> +++ b/drivers/gpu/drm/tiny/ili9225.c
> @@ -346,7 +346,7 @@ DEFINE_DRM_GEM_CMA_FOPS(ili9225_fops);
>  static struct drm_driver ili9225_driver = {
>   .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
>   .fops   = _fops,
> - 

Re: [PATCH] drm/amdgpu/smu10: Replace one-element array and use struct_size() helper

[Gustavo A. R. Silva]

On Wed, May 20, 2020 at 09:42:27AM +0200, Christian König wrote:
> > 
> > Signed-off-by: Gustavo A. R. Silva 
> 
> Acked-by: Christian König 
> 
> May I suggest that we add a section how to correctly do this to
> Documentation/process/coding-style.rst or similar document?
> 

That's already on my list. :)

> I've seen a bunch of different approaches and some even doesn't work with
> some gcc versions and result in a broken binary.
> 

Do you have an example of that one that doesn't work with some GCC
versions? It'd be interesting to take a look...

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

[PATCH] drm/[radeon|amdgpu]: Replace one-element array and use struct_size() helper

[Gustavo A. R. Silva]

The current codebase makes use of one-element arrays in the following
form:

struct something {
int length;
u8 data[1];
};

struct something *instance;

instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
instance->length = size;
memcpy(instance->data, source, size);

but the preferred mechanism to declare variable-length types such as
these ones is a flexible array member[1][2], introduced in C99:

struct foo {
int stuff;
struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on. So, replace
the one-element array with a flexible-array member.

Also, make use of the new struct_size() helper to properly calculate the
size of struct SISLANDS_SMC_SWSTATE.

This issue was found with the help of Coccinelle and, audited and fixed
_manually_.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/amd/amdgpu/si_dpm.c   | 5 ++---
 drivers/gpu/drm/amd/amdgpu/sislands_smc.h | 2 +-
 drivers/gpu/drm/radeon/si_dpm.c   | 5 ++---
 3 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.c 
b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
index c00ba4b23c9a6..0fc56c5bac080 100644
--- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
@@ -5715,10 +5715,9 @@ static int si_upload_sw_state(struct amdgpu_device *adev,
int ret;
u32 address = si_pi->state_table_start +
offsetof(SISLANDS_SMC_STATETABLE, driverState);
-   u32 state_size = sizeof(SISLANDS_SMC_SWSTATE) +
-   ((new_state->performance_level_count - 1) *
-sizeof(SISLANDS_SMC_HW_PERFORMANCE_LEVEL));
SISLANDS_SMC_SWSTATE *smc_state = _pi->smc_statetable.driverState;
+   size_t state_size = struct_size(smc_state, levels,
+   new_state->performance_level_count);
 
memset(smc_state, 0, state_size);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/sislands_smc.h 
b/drivers/gpu/drm/amd/amdgpu/sislands_smc.h
index d2930eceaf3c8..a089dbf8f7a93 100644
--- a/drivers/gpu/drm/amd/amdgpu/sislands_smc.h
+++ b/drivers/gpu/drm/amd/amdgpu/sislands_smc.h
@@ -186,7 +186,7 @@ struct SISLANDS_SMC_SWSTATE
 uint8_t levelCount;
 uint8_t padding2;
 uint8_t padding3;
-SISLANDS_SMC_HW_PERFORMANCE_LEVEL   levels[1];
+SISLANDS_SMC_HW_PERFORMANCE_LEVEL   levels[];
 };
 
 typedef struct SISLANDS_SMC_SWSTATE SISLANDS_SMC_SWSTATE;
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index a167e1c36d243..bab01ca864c63 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -5253,10 +5253,9 @@ static int si_upload_sw_state(struct radeon_device *rdev,
int ret;
u32 address = si_pi->state_table_start +
offsetof(SISLANDS_SMC_STATETABLE, driverState);
-   u32 state_size = sizeof(SISLANDS_SMC_SWSTATE) +
-   ((new_state->performance_level_count - 1) *
-sizeof(SISLANDS_SMC_HW_PERFORMANCE_LEVEL));
SISLANDS_SMC_SWSTATE *smc_state = _pi->smc_statetable.driverState;
+   size_t state_size = struct_size(smc_state, levels,
+   new_state->performance_level_count);
 
memset(smc_state, 0, state_size);
 
-- 
2.26.2

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

[PATCH v2] drm/radeon/dpm: Replace one-element array and use struct_size() helper

[Gustavo A. R. Silva]

The current codebase makes use of one-element arrays in the following
form:

struct something {
int length;
u8 data[1];
};

struct something *instance;

instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
instance->length = size;
memcpy(instance->data, source, size);

but the preferred mechanism to declare variable-length types such as
these ones is a flexible array member[1][2], introduced in C99:

struct foo {
int stuff;
struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on. So, replace
the one-element array with a flexible-array member.

Also, make use of the new struct_size() helper to properly calculate the
size of struct NISLANDS_SMC_SWSTATE.

This issue was found with the help of Coccinelle and, audited and fixed
_manually_.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Reviewed-by: Christian König 
Signed-off-by: Gustavo A. R. Silva 
---
Changes in v2:
 - Use type size_t instead of u16 for state_size variable.

 drivers/gpu/drm/amd/amdgpu/si_dpm.h | 2 +-
 drivers/gpu/drm/radeon/ni_dpm.c | 7 ---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.h 
b/drivers/gpu/drm/amd/amdgpu/si_dpm.h
index 6b7d292b919f3..bc0be6818e218 100644
--- a/drivers/gpu/drm/amd/amdgpu/si_dpm.h
+++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.h
@@ -781,7 +781,7 @@ struct NISLANDS_SMC_SWSTATE
 uint8_t levelCount;
 uint8_t padding2;
 uint8_t padding3;
-NISLANDS_SMC_HW_PERFORMANCE_LEVEL   levels[1];
+NISLANDS_SMC_HW_PERFORMANCE_LEVEL   levels[];
 };
 
 typedef struct NISLANDS_SMC_SWSTATE NISLANDS_SMC_SWSTATE;
diff --git a/drivers/gpu/drm/radeon/ni_dpm.c b/drivers/gpu/drm/radeon/ni_dpm.c
index b57c37ddd164c..abb6345bfae32 100644
--- a/drivers/gpu/drm/radeon/ni_dpm.c
+++ b/drivers/gpu/drm/radeon/ni_dpm.c
@@ -2685,11 +2685,12 @@ static int ni_upload_sw_state(struct radeon_device 
*rdev,
struct rv7xx_power_info *pi = rv770_get_pi(rdev);
u16 address = pi->state_table_start +
offsetof(NISLANDS_SMC_STATETABLE, driverState);
-   u16 state_size = sizeof(NISLANDS_SMC_SWSTATE) +
-   ((NISLANDS_MAX_SMC_PERFORMANCE_LEVELS_PER_SWSTATE - 1) * 
sizeof(NISLANDS_SMC_HW_PERFORMANCE_LEVEL));
+   NISLANDS_SMC_SWSTATE *smc_state;
+   size_t state_size = struct_size(smc_state, levels,
+   NISLANDS_MAX_SMC_PERFORMANCE_LEVELS_PER_SWSTATE);
int ret;
-   NISLANDS_SMC_SWSTATE *smc_state = kzalloc(state_size, GFP_KERNEL);
 
+   smc_state = kzalloc(state_size, GFP_KERNEL);
if (smc_state == NULL)
return -ENOMEM;
 
-- 
2.26.2

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

Re: [PATCH] drm/radeon/dpm: Replace one-element array and use struct_size() helper

[Gustavo A. R. Silva]

On Fri, May 22, 2020 at 09:00:09AM +0200, Christian König wrote:
> > +++ b/drivers/gpu/drm/radeon/ni_dpm.c
> > @@ -2685,11 +2685,12 @@ static int ni_upload_sw_state(struct radeon_device 
> > *rdev,
> > struct rv7xx_power_info *pi = rv770_get_pi(rdev);
> > u16 address = pi->state_table_start +
> > offsetof(NISLANDS_SMC_STATETABLE, driverState);
> > -   u16 state_size = sizeof(NISLANDS_SMC_SWSTATE) +
> > -   ((NISLANDS_MAX_SMC_PERFORMANCE_LEVELS_PER_SWSTATE - 1) * 
> > sizeof(NISLANDS_SMC_HW_PERFORMANCE_LEVEL));
> > +   NISLANDS_SMC_SWSTATE *smc_state;
> > +   u16 state_size = struct_size(smc_state, levels,
> > +   NISLANDS_MAX_SMC_PERFORMANCE_LEVELS_PER_SWSTATE);
> 
> Probably better to use size_t instead of u16 here. With that fixed feel free
> to stick my rb on the patch.
> 

Sure thing. I'll send v2, shortly.

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

Re: [PATCH v4 3/8] spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4

[Mark Brown]

On Fri, May 22, 2020 at 11:59:25PM +0800, dillon min wrote:

> but, after spi-core create a dummy tx_buf or rx_buf, then i can't get
> the correct spi_3wire direction.
> actually, this dummy tx_buf is useless for SPI_3WIRE. it's has meaning
> for SPI_SIMPLE_RX mode,
> simulate SPI_FULL_DUMPLEX

Oh, that's annoying.  I think the fix here is in the core, it should
ignore MUST_TX and MUST_RX in 3WIRE mode since they clearly make no
sense there.


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

Re: [GIT PULL v2] mediatek drm next for 5.8

[Matthias Brugger]

On 20/05/2020 07:46, Dave Airlie wrote:
> On Wed, 20 May 2020 at 15:44, Dave Airlie  wrote:
>>
>> On Mon, 18 May 2020 at 10:06, Chun-Kuang Hu  wrote:
>>>
>>> Hi, Dave & Daniel:
>>>
>>> This include dpi pin mode swap, config mipi_tx current and impedance,
>>> and some fixup. I drop drm_bridge patches in this version.
>>>
>>> The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
>>>   Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
>>> are available in the Git repository at:
>>>   https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git
>>> tags/mediatek-drm-next-5.8
>>> for you to fetch changes up to 007d274a017bb4e2ef7b922c2f54f40cf2073664:
>>
>> Did you edit this by hand or pass it through some mailserver that
>> chewed it up, I had to reconstruct this pull from the above bits, I've
>> no idea why it's so messed up in the first place.
> 
> and why does it contain an unexplained backmerge?
> 
>  Merge tag 'v5.7-next-drm-stable' of
> ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux
> into mediatek-drm-next
> 
> Please don't ever backmerge fixes into next pull, without a long
> explaination or if you really need it ask us first,

It's not fixes. I suppose my tagging strategy helps to create confusion. The tag
is v5.7-*next*, which relates to v5.8 (next version after v5.7). Maybe not the
best way to do it.

We had to merge a series that changed the drivers/gpu/drm, drivers/soc and
drivers/clk.
So I took the series through my branch and Chun-Kuang merged a stable tag in his
branch so that he can take commits on top of this changes.

Maybe the explanation comes too late, but I just wanted to clarify.

Regards,
Matthias

> 
> Please resend this again cleaned up.
> 
> Dave.
> 
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/panfrost: Fix inbalance of devfreq record_busy/idle()

[Steven Price]

The calls to panfrost_devfreq_record_busy() and
panfrost_devfreq_record_idle() must be balanced to ensure that the
devfreq utilisation is correctly reported. But there are two cases where
this doesn't work correctly.

In panfrost_job_hw_submit() if pm_runtime_get_sync() fails or the
WARN_ON() fires then no call to panfrost_devfreq_record_busy() is made,
but when the job times out the corresponding _record_idle() call is
still made in panfrost_job_timedout(). Move the call up to ensure that
it always happens.

Secondly panfrost_job_timedout() only makes a single call to
panfrost_devfreq_record_idle() even if it is cleaning up multiple jobs.
Move the call inside the loop to ensure that the number of
_record_idle() calls matches the number of _record_busy() calls.

Fixes: 9e62b885f715 ("drm/panfrost: Simplify devfreq utilisation tracking")
Signed-off-by: Steven Price 
---
 drivers/gpu/drm/panfrost/panfrost_job.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c 
b/drivers/gpu/drm/panfrost/panfrost_job.c
index b2f09c038d35..ac87ef675e8a 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -145,6 +145,8 @@ static void panfrost_job_hw_submit(struct panfrost_job 
*job, int js)
u64 jc_head = job->jc;
int ret;
 
+   panfrost_devfreq_record_busy(pfdev);
+
ret = pm_runtime_get_sync(pfdev->dev);
if (ret < 0)
return;
@@ -155,7 +157,6 @@ static void panfrost_job_hw_submit(struct panfrost_job 
*job, int js)
}
 
cfg = panfrost_mmu_as_get(pfdev, >file_priv->mmu);
-   panfrost_devfreq_record_busy(pfdev);
 
job_write(pfdev, JS_HEAD_NEXT_LO(js), jc_head & 0x);
job_write(pfdev, JS_HEAD_NEXT_HI(js), jc_head >> 32);
@@ -410,12 +411,12 @@ static void panfrost_job_timedout(struct drm_sched_job 
*sched_job)
for (i = 0; i < NUM_JOB_SLOTS; i++) {
if (pfdev->jobs[i]) {
pm_runtime_put_noidle(pfdev->dev);
+   panfrost_devfreq_record_idle(pfdev);
pfdev->jobs[i] = NULL;
}
}
spin_unlock_irqrestore(>js->job_lock, flags);
 
-   panfrost_devfreq_record_idle(pfdev);
panfrost_device_reset(pfdev);
 
for (i = 0; i < NUM_JOB_SLOTS; i++)
-- 
2.20.1

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

[PATCH AUTOSEL 5.4 14/32] drm/amd/powerplay: perform PG ungate prior to CG ungate

[Sasha Levin]

From: Evan Quan 

[ Upstream commit f4fcfa4282c1a1bf51475ebb0ffda623eebf1191 ]

Since gfxoff should be disabled first before trying to access those
GC registers.

Signed-off-by: Evan Quan 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 6 +++---
 drivers/gpu/drm/amd/powerplay/amdgpu_smu.c| 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c 
b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
index 8bb5fbef7de0..9eb3a0dcd1f2 100644
--- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
@@ -320,12 +320,12 @@ static void pp_dpm_en_umd_pstate(struct pp_hwmgr  *hwmgr,
if (*level & profile_mode_mask) {
hwmgr->saved_dpm_level = hwmgr->dpm_level;
hwmgr->en_umd_pstate = true;
-   amdgpu_device_ip_set_clockgating_state(hwmgr->adev,
-   AMD_IP_BLOCK_TYPE_GFX,
-   AMD_CG_STATE_UNGATE);
amdgpu_device_ip_set_powergating_state(hwmgr->adev,
AMD_IP_BLOCK_TYPE_GFX,
AMD_PG_STATE_UNGATE);
+   amdgpu_device_ip_set_clockgating_state(hwmgr->adev,
+   AMD_IP_BLOCK_TYPE_GFX,
+   AMD_CG_STATE_UNGATE);
}
} else {
/* exit umd pstate, restore level, enable gfx cg*/
diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c 
b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
index a066e929..b51a124e505a 100644
--- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
@@ -1541,12 +1541,12 @@ static int smu_enable_umd_pstate(void *handle,
if (*level & profile_mode_mask) {
smu_dpm_ctx->saved_dpm_level = smu_dpm_ctx->dpm_level;
smu_dpm_ctx->enable_umd_pstate = true;
-   amdgpu_device_ip_set_clockgating_state(smu->adev,
-  
AMD_IP_BLOCK_TYPE_GFX,
-  
AMD_CG_STATE_UNGATE);
amdgpu_device_ip_set_powergating_state(smu->adev,
   
AMD_IP_BLOCK_TYPE_GFX,
   
AMD_PG_STATE_UNGATE);
+   amdgpu_device_ip_set_clockgating_state(smu->adev,
+  
AMD_IP_BLOCK_TYPE_GFX,
+  
AMD_CG_STATE_UNGATE);
}
} else {
/* exit umd pstate, restore level, enable gfx cg*/
-- 
2.25.1

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

[PATCH AUTOSEL 5.6 35/41] drm/meson: pm resume add return errno branch

[Sasha Levin]

From: Bernard Zhao 

[ Upstream commit c54a8f1f329197d83d941ad84c4aa38bf282cbbd ]

pm_resump api did not handle drm_mode_config_helper_resume error.
This change add handle to return drm_mode_config_helper_resume`s
error number. This code logic is aligned with api pm_suspend.
After this change, the code maybe a bit readable.

Signed-off-by: Bernard Zhao 
Signed-off-by: Neil Armstrong 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20200428131747.2099-1-bern...@vivo.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/meson/meson_drv.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_drv.c 
b/drivers/gpu/drm/meson/meson_drv.c
index b5f5eb7b4bb9..8c2e1b47e81a 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -412,9 +412,7 @@ static int __maybe_unused meson_drv_pm_resume(struct device 
*dev)
if (priv->afbcd.ops)
priv->afbcd.ops->init(priv);
 
-   drm_mode_config_helper_resume(priv->drm);
-
-   return 0;
+   return drm_mode_config_helper_resume(priv->drm);
 }
 
 static int compare_of(struct device *dev, void *data)
-- 
2.25.1

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

[PATCH AUTOSEL 5.4 15/32] drm/amdgpu: Use GEM obj reference for KFD BOs

[Sasha Levin]

From: Felix Kuehling 

[ Upstream commit 39b3128d7ffd44e400e581e6f49e88cb42bef9a1 ]

Releasing the AMDGPU BO ref directly leads to problems when BOs were
exported as DMA bufs. Releasing the GEM reference makes sure that the
AMDGPU/TTM BO is not freed too early.

Also take a GEM reference when importing BOs from DMABufs to keep
references to imported BOs balances properly.

Signed-off-by: Felix Kuehling 
Tested-by: Alex Sierra 
Acked-by: Christian König 
Reviewed-by: Alex Sierra 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 6d021ecc8d59..edb561baf8b9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1288,7 +1288,7 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
}
 
/* Free the BO*/
-   amdgpu_bo_unref(>bo);
+   drm_gem_object_put_unlocked(>bo->tbo.base);
mutex_destroy(>lock);
kfree(mem);
 
@@ -1630,7 +1630,8 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct kgd_dev *kgd,
AMDGPU_VM_PAGE_READABLE | AMDGPU_VM_PAGE_WRITEABLE |
AMDGPU_VM_PAGE_EXECUTABLE | AMDGPU_VM_MTYPE_NC;
 
-   (*mem)->bo = amdgpu_bo_ref(bo);
+   drm_gem_object_get(>tbo.base);
+   (*mem)->bo = bo;
(*mem)->va = va;
(*mem)->domain = (bo->preferred_domains & AMDGPU_GEM_DOMAIN_VRAM) ?
AMDGPU_GEM_DOMAIN_VRAM : AMDGPU_GEM_DOMAIN_GTT;
-- 
2.25.1

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

[PATCH AUTOSEL 5.4 13/32] drm/amdgpu: drop unnecessary cancel_delayed_work_sync on PG ungate

[Sasha Levin]

From: Evan Quan 

[ Upstream commit 1fe48ec08d9f2e26d893a6c05bd6c99a3490f9ef ]

As this is already properly handled in amdgpu_gfx_off_ctrl(). In fact,
this unnecessary cancel_delayed_work_sync may leave a small time window
for race condition and is dangerous.

Signed-off-by: Evan Quan 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c |  6 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  | 12 +++-
 2 files changed, 4 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 14417cebe38b..6f118292e40f 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -4290,11 +4290,7 @@ static int gfx_v10_0_set_powergating_state(void *handle,
switch (adev->asic_type) {
case CHIP_NAVI10:
case CHIP_NAVI14:
-   if (!enable) {
-   amdgpu_gfx_off_ctrl(adev, false);
-   cancel_delayed_work_sync(>gfx.gfx_off_delay_work);
-   } else
-   amdgpu_gfx_off_ctrl(adev, true);
+   amdgpu_gfx_off_ctrl(adev, enable);
break;
default:
break;
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index c34ddaa65324..6004fdacc866 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -4839,10 +4839,9 @@ static int gfx_v9_0_set_powergating_state(void *handle,
switch (adev->asic_type) {
case CHIP_RAVEN:
case CHIP_RENOIR:
-   if (!enable) {
+   if (!enable)
amdgpu_gfx_off_ctrl(adev, false);
-   cancel_delayed_work_sync(>gfx.gfx_off_delay_work);
-   }
+
if (adev->pg_flags & AMD_PG_SUPPORT_RLC_SMU_HS) {
gfx_v9_0_enable_sck_slow_down_on_power_up(adev, true);
gfx_v9_0_enable_sck_slow_down_on_power_down(adev, true);
@@ -4868,12 +4867,7 @@ static int gfx_v9_0_set_powergating_state(void *handle,
amdgpu_gfx_off_ctrl(adev, true);
break;
case CHIP_VEGA12:
-   if (!enable) {
-   amdgpu_gfx_off_ctrl(adev, false);
-   cancel_delayed_work_sync(>gfx.gfx_off_delay_work);
-   } else {
-   amdgpu_gfx_off_ctrl(adev, true);
-   }
+   amdgpu_gfx_off_ctrl(adev, enable);
break;
default:
break;
-- 
2.25.1

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

[PATCH AUTOSEL 5.6 26/41] drm/amd/amdgpu: Update update_config() logic

[Sasha Levin]

From: "Leo (Hanghong) Ma" 

[ Upstream commit 650e723cecf2738dee828564396f3239829aba83 ]

[Why]
For MST case: when update_config is called to disable a stream,
this clears the settings for all the streams on that link.
We should only clear the settings for the stream that was disabled.

[How]
Clear the settings after the call to remove display is called.

Reviewed-by: Harry Wentland 
Reviewed-by: Bhawanpreet Lakha 
Signed-off-by: Leo (Hanghong) Ma 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c
index 3abeff7722e3..e80371542622 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c
@@ -316,15 +316,15 @@ static void update_config(void *handle, struct 
cp_psp_stream_config *config)
struct mod_hdcp_display *display = _work[link_index].display;
struct mod_hdcp_link *link = _work[link_index].link;
 
-   memset(display, 0, sizeof(*display));
-   memset(link, 0, sizeof(*link));
-
-   display->index = aconnector->base.index;
-
if (config->dpms_off) {
hdcp_remove_display(hdcp_work, link_index, aconnector);
return;
}
+
+   memset(display, 0, sizeof(*display));
+   memset(link, 0, sizeof(*link));
+
+   display->index = aconnector->base.index;
display->state = MOD_HDCP_DISPLAY_ACTIVE;
 
if (aconnector->dc_sink != NULL)
-- 
2.25.1

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

[PATCH AUTOSEL 5.6 19/41] drm/amdgpu: Use GEM obj reference for KFD BOs

[Sasha Levin]

From: Felix Kuehling 

[ Upstream commit 39b3128d7ffd44e400e581e6f49e88cb42bef9a1 ]

Releasing the AMDGPU BO ref directly leads to problems when BOs were
exported as DMA bufs. Releasing the GEM reference makes sure that the
AMDGPU/TTM BO is not freed too early.

Also take a GEM reference when importing BOs from DMABufs to keep
references to imported BOs balances properly.

Signed-off-by: Felix Kuehling 
Tested-by: Alex Sierra 
Acked-by: Christian König 
Reviewed-by: Alex Sierra 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index fa8ac9d19a7a..6326c1792270 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1304,7 +1304,7 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
}
 
/* Free the BO*/
-   amdgpu_bo_unref(>bo);
+   drm_gem_object_put_unlocked(>bo->tbo.base);
mutex_destroy(>lock);
kfree(mem);
 
@@ -1647,7 +1647,8 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct kgd_dev *kgd,
 ALLOC_MEM_FLAGS_VRAM : ALLOC_MEM_FLAGS_GTT) |
ALLOC_MEM_FLAGS_WRITABLE | ALLOC_MEM_FLAGS_EXECUTABLE;
 
-   (*mem)->bo = amdgpu_bo_ref(bo);
+   drm_gem_object_get(>tbo.base);
+   (*mem)->bo = bo;
(*mem)->va = va;
(*mem)->domain = (bo->preferred_domains & AMDGPU_GEM_DOMAIN_VRAM) ?
AMDGPU_GEM_DOMAIN_VRAM : AMDGPU_GEM_DOMAIN_GTT;
-- 
2.25.1

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

[PATCH AUTOSEL 5.6 18/41] drm/amd/powerplay: perform PG ungate prior to CG ungate

[Sasha Levin]

From: Evan Quan 

[ Upstream commit f4fcfa4282c1a1bf51475ebb0ffda623eebf1191 ]

Since gfxoff should be disabled first before trying to access those
GC registers.

Signed-off-by: Evan Quan 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 6 +++---
 drivers/gpu/drm/amd/powerplay/amdgpu_smu.c| 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c 
b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
index e4e5a53b2b4e..8e2acb4df860 100644
--- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
@@ -319,12 +319,12 @@ static void pp_dpm_en_umd_pstate(struct pp_hwmgr  *hwmgr,
if (*level & profile_mode_mask) {
hwmgr->saved_dpm_level = hwmgr->dpm_level;
hwmgr->en_umd_pstate = true;
-   amdgpu_device_ip_set_clockgating_state(hwmgr->adev,
-   AMD_IP_BLOCK_TYPE_GFX,
-   AMD_CG_STATE_UNGATE);
amdgpu_device_ip_set_powergating_state(hwmgr->adev,
AMD_IP_BLOCK_TYPE_GFX,
AMD_PG_STATE_UNGATE);
+   amdgpu_device_ip_set_clockgating_state(hwmgr->adev,
+   AMD_IP_BLOCK_TYPE_GFX,
+   AMD_CG_STATE_UNGATE);
}
} else {
/* exit umd pstate, restore level, enable gfx cg*/
diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c 
b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
index 96e81c7bc266..e2565967db07 100644
--- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
@@ -1675,12 +1675,12 @@ static int smu_enable_umd_pstate(void *handle,
if (*level & profile_mode_mask) {
smu_dpm_ctx->saved_dpm_level = smu_dpm_ctx->dpm_level;
smu_dpm_ctx->enable_umd_pstate = true;
-   amdgpu_device_ip_set_clockgating_state(smu->adev,
-  
AMD_IP_BLOCK_TYPE_GFX,
-  
AMD_CG_STATE_UNGATE);
amdgpu_device_ip_set_powergating_state(smu->adev,
   
AMD_IP_BLOCK_TYPE_GFX,
   
AMD_PG_STATE_UNGATE);
+   amdgpu_device_ip_set_clockgating_state(smu->adev,
+  
AMD_IP_BLOCK_TYPE_GFX,
+  
AMD_CG_STATE_UNGATE);
}
} else {
/* exit umd pstate, restore level, enable gfx cg*/
-- 
2.25.1

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

[PATCH AUTOSEL 5.6 17/41] drm/amdgpu: drop unnecessary cancel_delayed_work_sync on PG ungate

[Sasha Levin]

From: Evan Quan 

[ Upstream commit 1fe48ec08d9f2e26d893a6c05bd6c99a3490f9ef ]

As this is already properly handled in amdgpu_gfx_off_ctrl(). In fact,
this unnecessary cancel_delayed_work_sync may leave a small time window
for race condition and is dangerous.

Signed-off-by: Evan Quan 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c |  6 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  | 12 +++-
 2 files changed, 4 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 02702597ddeb..012df3d574bf 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -4241,11 +4241,7 @@ static int gfx_v10_0_set_powergating_state(void *handle,
switch (adev->asic_type) {
case CHIP_NAVI10:
case CHIP_NAVI14:
-   if (!enable) {
-   amdgpu_gfx_off_ctrl(adev, false);
-   cancel_delayed_work_sync(>gfx.gfx_off_delay_work);
-   } else
-   amdgpu_gfx_off_ctrl(adev, true);
+   amdgpu_gfx_off_ctrl(adev, enable);
break;
default:
break;
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 906648fca9ef..914dbd901b98 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -4734,10 +4734,9 @@ static int gfx_v9_0_set_powergating_state(void *handle,
switch (adev->asic_type) {
case CHIP_RAVEN:
case CHIP_RENOIR:
-   if (!enable) {
+   if (!enable)
amdgpu_gfx_off_ctrl(adev, false);
-   cancel_delayed_work_sync(>gfx.gfx_off_delay_work);
-   }
+
if (adev->pg_flags & AMD_PG_SUPPORT_RLC_SMU_HS) {
gfx_v9_0_enable_sck_slow_down_on_power_up(adev, true);
gfx_v9_0_enable_sck_slow_down_on_power_down(adev, true);
@@ -4761,12 +4760,7 @@ static int gfx_v9_0_set_powergating_state(void *handle,
amdgpu_gfx_off_ctrl(adev, true);
break;
case CHIP_VEGA12:
-   if (!enable) {
-   amdgpu_gfx_off_ctrl(adev, false);
-   cancel_delayed_work_sync(>gfx.gfx_off_delay_work);
-   } else {
-   amdgpu_gfx_off_ctrl(adev, true);
-   }
+   amdgpu_gfx_off_ctrl(adev, enable);
break;
default:
break;
-- 
2.25.1

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

Re: [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM

[Alex Deucher]

On Fri, May 22, 2020 at 6:41 AM Christian König
 wrote:
>
> Am 20.05.20 um 18:18 schrieb Alex Deucher:
> > On Wed, May 20, 2020 at 10:43 AM Christian König
> >  wrote:
> >> Am 13.05.20 um 13:03 schrieb Christian König:
> >>> Unfortunately AGP is still to widely used as we could just drop support 
> >>> for using its GART.
> >>>
> >>> Not using the AGP GART also doesn't mean a loss in functionality since 
> >>> drivers will just fallback to the driver specific PCI GART.
> >>>
> >>> For now just deprecate the code and don't enable the AGP GART in TTM even 
> >>> when general AGP support is available.
> >> So I've used an ancient system (32bit) to setup a test box for this.
> >>
> >>
> >> The first GPU I could test is an RV280 (Radeon 9200 PRO) which is easily
> >> 15 years old.
> >>
> >> What happens in AGP mode is that glxgears shows artifacts during
> >> rendering on this system.
> >>
> >> In PCI mode those rendering artifacts are gone and glxgears seems to
> >> draw everything correctly now.
> >>
> >> Performance is obviously not comparable, cause in AGP we don't render
> >> all triangles correctly.
> >>
> >>
> >> The second GPU I could test is an RV630 PRO (Radeon HD 2600 PRO AGP)
> >> which is more than 10 years old.
> >>
> >> As far as I can tell this one works in both AGP and PCIe mode perfectly
> >> fine.
> >>
> >> Since this is only a 32bit system I couldn't really test any OpenGL game
> >> that well.
> >>
> >> But for glxgears switching from AGP to PCIe mode seems to result in a
> >> roughly 5% performance drop.
> >>
> >> The surprising reason for this is not the better TLB performance, but
> >> the lack of USWC support for the PCIe GART in radeon.
> >>
> >>
> >> So if anybody wants to get his hands dirty and squeeze a bit more
> >> performance out of the old hardware, porting USWC from amdgpu to radeon
> >> shouldn't be to much of a problem.
> > We do support USWC on radeon, although I think we had separate flags
> > for cached and WC.  That said we had a lot of problems with WC on 32
> > bit (see radeon_bo_create()).  The other problem is that, at least on
> > the really old radeons, the PCI gart didn't support snooped and
> > unsnooped.  It was always snooped.  It wasn't until pcie that the gart
> > hw got support for both.  For AGP, the expectation was that AGP
> > provided the uncached memory.
>
> Oh, indeed. I didn't remembered that.
>
> Interesting is that in this case I have no idea where the performance
> difference is coming from.
>
> >
> >>
> >> Summing it up I'm still leaning towards disabling AGP completely by
> >> default for radeon and deprecate it in TTM as well.
> >>
> >> Thoughts? Especially Alex what do you think.
> > Works for me.
>
> I will take that as an rb and commit at least the first patch.

Yeah, Reviewed-by: Alex Deucher 

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

[PATCH 18/21] drm/sti: Use GEM CMA object functions

[Thomas Zimmermann]

The sti driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
All remaining operations are provided by CMA GEM object functions.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/sti/sti_drv.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 3f9db3e3f3978..381804126e70d 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -132,19 +132,9 @@ DEFINE_DRM_GEM_CMA_FOPS(sti_driver_fops);
 
 static struct drm_driver sti_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
-   .dumb_create = drm_gem_cma_dumb_create,
+   DRM_GEM_CMA_DRIVER_OPS,
.fops = _driver_fops,
 
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
-
.debugfs_init = sti_drm_dbg_init,
 
.name = DRIVER_NAME,
-- 
2.26.2

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

[PATCH 16/21] drm/shmobile: Use GEM CMA object functions

[Thomas Zimmermann]

The shmobile driver uses the default implementation for CMA functions.
The DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct
drm_driver. All remaining operations are provided by CMA GEM object
functions.

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

diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c 
b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
index ae9d6b8d3ca87..26a15c214bd3f 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
@@ -131,16 +131,7 @@ DEFINE_DRM_GEM_CMA_FOPS(shmob_drm_fops);
 static struct drm_driver shmob_drm_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET,
.irq_handler= shmob_drm_irq,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
-   .dumb_create= drm_gem_cma_dumb_create,
+   DRM_GEM_CMA_DRIVER_OPS,
.fops   = _drm_fops,
.name   = "shmob-drm",
.desc   = "Renesas SH Mobile DRM",
-- 
2.26.2

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

[PATCH 12/21] drm/mcde: Use GEM CMA object functions

[Thomas Zimmermann]

The mcde driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
All remaining operations are provided by CMA GEM object functions.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/mcde/mcde_drv.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c
index 84f3e2dbd77bd..d300be5ee463d 100644
--- a/drivers/gpu/drm/mcde/mcde_drv.c
+++ b/drivers/gpu/drm/mcde/mcde_drv.c
@@ -228,17 +228,7 @@ static struct drm_driver mcde_drm_driver = {
.major = 1,
.minor = 0,
.patchlevel = 0,
-   .dumb_create = drm_gem_cma_dumb_create,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
-
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
+   DRM_GEM_CMA_DRIVER_OPS,
 };
 
 static int mcde_drm_bind(struct device *dev)
-- 
2.26.2

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

[PATCH 20/21] drm/tv200: Use GEM CMA object functions

[Thomas Zimmermann]

The tve200 driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
All remaining operations are provided by CMA GEM object functions.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/tve200/tve200_drv.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/tve200/tve200_drv.c 
b/drivers/gpu/drm/tve200/tve200_drv.c
index 00ba9e5ce1307..c3aa39bd38ecd 100644
--- a/drivers/gpu/drm/tve200/tve200_drv.c
+++ b/drivers/gpu/drm/tve200/tve200_drv.c
@@ -147,17 +147,7 @@ static struct drm_driver tve200_drm_driver = {
.major = 1,
.minor = 0,
.patchlevel = 0,
-   .dumb_create = drm_gem_cma_dumb_create,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
-
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
+   DRM_GEM_CMA_DRIVER_OPS,
 };
 
 static int tve200_probe(struct platform_device *pdev)
-- 
2.26.2

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

[PATCH 07/21] drm/hisilicon/kirin: Use GEM CMA object functions

[Thomas Zimmermann]

The kirin driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro now sets
these defaults and .dumb_create in struct drm_driver. All remaining
operations are provided by CMA GEM object functions.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index c339e632522a9..b1ffd7d43e562 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -921,17 +921,7 @@ DEFINE_DRM_GEM_CMA_FOPS(ade_fops);
 static struct drm_driver ade_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.fops = _fops,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
-   .dumb_create = drm_gem_cma_dumb_create_internal,
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
-
+   __DRM_GEM_CMA_DRIVER_OPS(drm_gem_cma_dumb_create_internal),
.name = "kirin",
.desc = "Hisilicon Kirin620 SoC DRM Driver",
.date = "20150718",
-- 
2.26.2

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

[PATCH 01/21] drm/cma-helper: Rework DRM_GEM_CMA_VMAP_DRIVER_OPS macro

[Thomas Zimmermann]

Rename the macro to DRM_GEM_CMA_DRIVER_OPS to align with SHMEM
helpers. An internal version is provided for drivers that override
the default .dumb_create callback. Adapt drivers to the changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem_cma_helper.c |  2 +-
 drivers/gpu/drm/sun4i/sun4i_drv.c|  3 +--
 drivers/gpu/drm/tidss/tidss_drv.c|  2 +-
 drivers/gpu/drm/tiny/hx8357d.c   |  2 +-
 drivers/gpu/drm/tiny/ili9225.c   |  2 +-
 drivers/gpu/drm/tiny/ili9341.c   |  2 +-
 drivers/gpu/drm/tiny/ili9486.c   |  2 +-
 drivers/gpu/drm/tiny/mi0283qt.c  |  2 +-
 drivers/gpu/drm/tiny/repaper.c   |  2 +-
 drivers/gpu/drm/tiny/st7586.c|  2 +-
 drivers/gpu/drm/tiny/st7735r.c   |  2 +-
 include/drm/drm_gem_cma_helper.h | 24 
 12 files changed, 31 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 12e98fb28229d..6fa4d2f2e3987 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -620,7 +620,7 @@ EXPORT_SYMBOL(drm_cma_gem_create_object_default_funcs);
  * address set. This address is released when the object is freed.
  *
  * This function can be used as the _driver.gem_prime_import_sg_table
- * callback. The DRM_GEM_CMA_VMAP_DRIVER_OPS() macro provides a shortcut to set
+ * callback. The _GEM_CMA_DRIVER_OPS macro provides a shortcut to set
  * the necessary DRM driver operations.
  *
  * Returns:
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 328272ff77d84..012855fd89c24 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -52,8 +52,7 @@ static struct drm_driver sun4i_drv_driver = {
.minor  = 0,
 
/* GEM Operations */
-   DRM_GEM_CMA_VMAP_DRIVER_OPS,
-   .dumb_create= drm_sun4i_gem_dumb_create,
+   __DRM_GEM_CMA_DRIVER_OPS(drm_sun4i_gem_dumb_create),
 };
 
 static int sun4i_drv_bind(struct device *dev)
diff --git a/drivers/gpu/drm/tidss/tidss_drv.c 
b/drivers/gpu/drm/tidss/tidss_drv.c
index 99edc66ebdef2..1753cdc74ebda 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.c
+++ b/drivers/gpu/drm/tidss/tidss_drv.c
@@ -112,7 +112,7 @@ static struct drm_driver tidss_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.fops   = _fops,
.release= tidss_release,
-   DRM_GEM_CMA_VMAP_DRIVER_OPS,
+   DRM_GEM_CMA_DRIVER_OPS,
.name   = "tidss",
.desc   = "TI Keystone DSS",
.date   = "20180215",
diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c
index b4bc358a3269a..592da71d7ca70 100644
--- a/drivers/gpu/drm/tiny/hx8357d.c
+++ b/drivers/gpu/drm/tiny/hx8357d.c
@@ -196,7 +196,7 @@ DEFINE_DRM_GEM_CMA_FOPS(hx8357d_fops);
 static struct drm_driver hx8357d_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.fops   = _fops,
-   DRM_GEM_CMA_VMAP_DRIVER_OPS,
+   DRM_GEM_CMA_DRIVER_OPS,
.debugfs_init   = mipi_dbi_debugfs_init,
.name   = "hx8357d",
.desc   = "HX8357D",
diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c
index d1a5ab6747d5c..368ff6c8a1efb 100644
--- a/drivers/gpu/drm/tiny/ili9225.c
+++ b/drivers/gpu/drm/tiny/ili9225.c
@@ -346,7 +346,7 @@ DEFINE_DRM_GEM_CMA_FOPS(ili9225_fops);
 static struct drm_driver ili9225_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.fops   = _fops,
-   DRM_GEM_CMA_VMAP_DRIVER_OPS,
+   DRM_GEM_CMA_DRIVER_OPS,
.name   = "ili9225",
.desc   = "Ilitek ILI9225",
.date   = "20171106",
diff --git a/drivers/gpu/drm/tiny/ili9341.c b/drivers/gpu/drm/tiny/ili9341.c
index bb819f45a5d3b..e1b9043ef7a0a 100644
--- a/drivers/gpu/drm/tiny/ili9341.c
+++ b/drivers/gpu/drm/tiny/ili9341.c
@@ -152,7 +152,7 @@ DEFINE_DRM_GEM_CMA_FOPS(ili9341_fops);
 static struct drm_driver ili9341_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.fops   = _fops,
-   DRM_GEM_CMA_VMAP_DRIVER_OPS,
+   DRM_GEM_CMA_DRIVER_OPS,
.debugfs_init   = mipi_dbi_debugfs_init,
.name   = "ili9341",
.desc   = "Ilitek ILI9341",
diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
index 2702ea557d297..90a17f40fdf0c 100644
--- a/drivers/gpu/drm/tiny/ili9486.c
+++ b/drivers/gpu/drm/tiny/ili9486.c
@@ -165,7 +165,7 @@ DEFINE_DRM_GEM_CMA_FOPS(ili9486_fops);
 static struct drm_driver ili9486_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,

[PATCH 21/21] drm/zte: Use GEM CMA object functions

[Thomas Zimmermann]

The zte driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
All remaining operations are provided by CMA GEM object functions.

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

diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c
index 1141c1ed1ed04..42c59eae0ea03 100644
--- a/drivers/gpu/drm/zte/zx_drm_drv.c
+++ b/drivers/gpu/drm/zte/zx_drm_drv.c
@@ -36,16 +36,7 @@ DEFINE_DRM_GEM_CMA_FOPS(zx_drm_fops);
 
 static struct drm_driver zx_drm_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
-   .dumb_create = drm_gem_cma_dumb_create,
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
+   DRM_GEM_CMA_VMAP_DRIVER_OPS,
.fops = _drm_fops,
.name = "zx-vou",
.desc = "ZTE VOU Controller DRM",
-- 
2.26.2

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

[PATCH 09/21] drm/ingenic: Use GEM CMA object functions

[Thomas Zimmermann]

The ingenic driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
All remaining operations are provided by CMA GEM object functions.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index eff57a1f70fb0..1c1cee367b752 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -519,18 +519,7 @@ static struct drm_driver ingenic_drm_driver_data = {
.patchlevel = 0,
 
.fops   = _drm_fops,
-
-   .dumb_create= drm_gem_cma_dumb_create,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
-
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
+   DRM_GEM_CMA_DRIVER_OPS,
 
.irq_handler= ingenic_drm_irq_handler,
 };
-- 
2.26.2

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

[PATCH 15/21] drm/rcar-du: Use GEM CMA object functions

[Thomas Zimmermann]

The rcar-du driver uses the default implementation for CMA functions;
except for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro
now sets these defaults and .dumb_create in struct drm_driver. All
remaining operations are provided by CMA GEM object functions.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 3e67cf70f0402..3728038cec1d1 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -476,16 +476,7 @@ DEFINE_DRM_GEM_CMA_FOPS(rcar_du_fops);
 
 static struct drm_driver rcar_du_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
-   .dumb_create= rcar_du_dumb_create,
+   __DRM_GEM_CMA_DRIVER_OPS(rcar_du_dumb_create),
.fops   = _du_fops,
.name   = "rcar-du",
.desc   = "Renesas R-Car Display Unit",
-- 
2.26.2

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

[PATCH 11/21] drm/malidp: Use GEM CMA object functions

[Thomas Zimmermann]

The malidp driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro now sets
these defaults and .dumb_create in struct drm_driver. All remaining
operations are provided by CMA GEM object functions.

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

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index def8c9ffafcaf..92e0bca6aa2f4 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -563,16 +563,7 @@ static void malidp_debugfs_init(struct drm_minor *minor)
 
 static struct drm_driver malidp_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
-   .dumb_create = malidp_dumb_create,
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
+   __DRM_GEM_CMA_DRIVER_OPS(malidp_dumb_create),
 #ifdef CONFIG_DEBUG_FS
.debugfs_init = malidp_debugfs_init,
 #endif
-- 
2.26.2

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

[PATCH 19/21] drm/tilcdc: Use GEM CMA object functions

[Thomas Zimmermann]

The tilcdc driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
All remaining operations are provided by CMA GEM object functions.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index a5e9ee4c7fbf4..0d74a64432633 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -496,18 +496,7 @@ DEFINE_DRM_GEM_CMA_FOPS(fops);
 static struct drm_driver tilcdc_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.irq_handler= tilcdc_irq,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_print_info = drm_gem_cma_print_info,
-   .gem_vm_ops = _gem_cma_vm_ops,
-   .dumb_create= drm_gem_cma_dumb_create,
-
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
+   DRM_GEM_CMA_DRIVER_OPS,
 #ifdef CONFIG_DEBUG_FS
.debugfs_init   = tilcdc_debugfs_init,
 #endif
-- 
2.26.2

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

[PATCH 08/21] drm/imx: Use GEM CMA object functions

[Thomas Zimmermann]

The imx driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
All remaining operations are provided by CMA GEM object functions.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/imx/imx-drm-core.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 2e38f1a5cf8da..36037b2e65647 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -146,17 +146,7 @@ static const struct drm_ioctl_desc imx_drm_ioctls[] = {
 
 static struct drm_driver imx_drm_driver = {
.driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
-   .dumb_create= drm_gem_cma_dumb_create,
-
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
+   DRM_GEM_CMA_DRIVER_OPS,
.ioctls = imx_drm_ioctls,
.num_ioctls = ARRAY_SIZE(imx_drm_ioctls),
.fops   = _drm_driver_fops,
-- 
2.26.2

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

[PATCH 14/21] drm/mxsfb: Use GEM CMA object functions

[Thomas Zimmermann]

The mxsfb driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
All remaining operations are provided by CMA GEM object functions.

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

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 497cf443a9afa..47c7dce03da4a 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -356,16 +356,7 @@ static struct drm_driver mxsfb_driver = {
.irq_handler= mxsfb_irq_handler,
.irq_preinstall = mxsfb_irq_preinstall,
.irq_uninstall  = mxsfb_irq_preinstall,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
-   .dumb_create= drm_gem_cma_dumb_create,
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
+   DRM_GEM_CMA_DRIVER_OPS,
.fops   = ,
.name   = "mxsfb-drm",
.desc   = "MXSFB Controller DRM",
-- 
2.26.2

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

[PATCH 02/21] drm/arc: Use GEM CMA object functions

[Thomas Zimmermann]

The arc driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
All remaining operations are provided by CMA GEM object functions.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/arc/arcpgu_drv.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index c05d001163e0e..f164818ec477a 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -154,17 +154,7 @@ static struct drm_driver arcpgu_drm_driver = {
.minor = 0,
.patchlevel = 0,
.fops = _drm_ops,
-   .dumb_create = drm_gem_cma_dumb_create,
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_print_info = drm_gem_cma_print_info,
-   .gem_vm_ops = _gem_cma_vm_ops,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
+   DRM_GEM_CMA_DRIVER_OPS,
 #ifdef CONFIG_DEBUG_FS
.debugfs_init = arcpgu_debugfs_init,
 #endif
-- 
2.26.2

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

[PATCH 03/21] drm/arm: Use GEM CMA object functions

[Thomas Zimmermann]

The arm driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
All remaining operations are provided by CMA GEM object functions.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/arm/hdlcd_drv.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index 194419f47c5e5..c83b81a3a582a 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -240,17 +240,7 @@ static struct drm_driver hdlcd_driver = {
.irq_preinstall = hdlcd_irq_preinstall,
.irq_postinstall = hdlcd_irq_postinstall,
.irq_uninstall = hdlcd_irq_uninstall,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_print_info = drm_gem_cma_print_info,
-   .gem_vm_ops = _gem_cma_vm_ops,
-   .dumb_create = drm_gem_cma_dumb_create,
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
+   DRM_GEM_CMA_DRIVER_OPS,
 #ifdef CONFIG_DEBUG_FS
.debugfs_init = hdlcd_debugfs_init,
 #endif
-- 
2.26.2

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

[PATCH 17/21] drm/stm: Use GEM CMA object functions

[Thomas Zimmermann]

The stm driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro now sets
these defaults and .dumb_create in struct drm_driver. All remaining
operations are provided by CMA GEM object functions.

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

diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index 0f85dd86cafa7..d6238c71fabf6 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -62,16 +62,7 @@ static struct drm_driver drv_driver = {
.minor = 0,
.patchlevel = 0,
.fops = _driver_fops,
-   .dumb_create = stm_gem_cma_dumb_create,
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
+   __DRM_GEM_CMA_DRIVER_OPS(stm_gem_cma_dumb_create),
 };
 
 static int drv_load(struct drm_device *ddev)
-- 
2.26.2

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

[PATCH 06/21] drm/fsl-dcu: Use GEM CMA object functions

[Thomas Zimmermann]

The fsl-dcu driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
All remaining operations are provided by CMA GEM object functions.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index f15d2e7967a3e..abbc1ddbf27f0 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -141,16 +141,7 @@ static struct drm_driver fsl_dcu_drm_driver = {
.irq_handler= fsl_dcu_drm_irq,
.irq_preinstall = fsl_dcu_irq_uninstall,
.irq_uninstall  = fsl_dcu_irq_uninstall,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
-   .dumb_create= drm_gem_cma_dumb_create,
+   DRM_GEM_CMA_DRIVER_OPS,
.fops   = _dcu_drm_fops,
.name   = "fsl-dcu-drm",
.desc   = "Freescale DCU DRM",
-- 
2.26.2

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

[PATCH 00/21] drm: Convert most CMA-based drivers to GEM object functions

[Thomas Zimmermann]

Most of the CMA-based drivers use the default implementation for the
callbacks in struct drm_driver. With this patch, these interfaces are
initialized with a common helper macro and GEM object functions replace
several deprecated interfaces.

The first patch updates the existing macro to similar naming as with
SHMEM and adds a helper for drivers that override the default implementation
for .dumb_create(). The remaining patches convert the drivers. The aspeed
driver already uses GEM object functions and only changes to the initializer
macro.

I don't have much of the hardware, so compile-tested on aarch64, arm and
x86-64 only.

Thomas Zimmermann (21):
  drm/cma-helper: Rework DRM_GEM_CMA_VMAP_DRIVER_OPS macro
  drm/arc: Use GEM CMA object functions
  drm/arm: Use GEM CMA object functions
  drm/aspeed: Set driver CMA functions with DRM_GEM_CMA_DRIVER_OPS
  drm/atmel-hlcdc: Use GEM CMA object functions
  drm/fsl-dcu: Use GEM CMA object functions
  drm/hisilicon/kirin: Use GEM CMA object functions
  drm/imx: Use GEM CMA object functions
  drm/ingenic: Use GEM CMA object functions
  drm/komeda: Use GEM CMA object functions
  drm/malidp: Use GEM CMA object functions
  drm/mcde: Use GEM CMA object functions
  drm/meson: Use GEM CMA object functions
  drm/mxsfb: Use GEM CMA object functions
  drm/rcar-du: Use GEM CMA object functions
  drm/shmobile: Use GEM CMA object functions
  drm/stm: Use GEM CMA object functions
  drm/sti: Use GEM CMA object functions
  drm/tilcdc: Use GEM CMA object functions
  drm/tv200: Use GEM CMA object functions
  drm/zte: Use GEM CMA object functions

 drivers/gpu/drm/arc/arcpgu_drv.c  | 12 +-
 .../gpu/drm/arm/display/komeda/komeda_kms.c   | 11 +
 drivers/gpu/drm/arm/hdlcd_drv.c   | 12 +-
 drivers/gpu/drm/arm/malidp_drv.c  | 11 +
 drivers/gpu/drm/aspeed/aspeed_gfx_drv.c   |  7 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c  | 11 +
 drivers/gpu/drm/drm_gem_cma_helper.c  |  2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 11 +
 .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c   | 12 +-
 drivers/gpu/drm/imx/imx-drm-core.c| 12 +-
 drivers/gpu/drm/ingenic/ingenic-drm.c | 13 +-
 drivers/gpu/drm/mcde/mcde_drv.c   | 12 +-
 drivers/gpu/drm/meson/meson_drv.c | 15 ++--
 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 11 +
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 11 +
 drivers/gpu/drm/shmobile/shmob_drm_drv.c  | 11 +
 drivers/gpu/drm/sti/sti_drv.c | 12 +-
 drivers/gpu/drm/stm/drv.c | 11 +
 drivers/gpu/drm/sun4i/sun4i_drv.c |  3 +--
 drivers/gpu/drm/tidss/tidss_drv.c |  2 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c   | 13 +-
 drivers/gpu/drm/tiny/hx8357d.c|  2 +-
 drivers/gpu/drm/tiny/ili9225.c|  2 +-
 drivers/gpu/drm/tiny/ili9341.c|  2 +-
 drivers/gpu/drm/tiny/ili9486.c|  2 +-
 drivers/gpu/drm/tiny/mi0283qt.c   |  2 +-
 drivers/gpu/drm/tiny/repaper.c|  2 +-
 drivers/gpu/drm/tiny/st7586.c |  2 +-
 drivers/gpu/drm/tiny/st7735r.c|  2 +-
 drivers/gpu/drm/tve200/tve200_drv.c   | 12 +-
 drivers/gpu/drm/zte/zx_drm_drv.c  | 11 +
 include/drm/drm_gem_cma_helper.h  | 24 +++
 32 files changed, 52 insertions(+), 226 deletions(-)

--
2.26.2

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

[PATCH 10/21] drm/komeda: Use GEM CMA object functions

[Thomas Zimmermann]

The komeda driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro now sets
these defaults and .dumb_create in struct drm_driver. All remaining
operations are provided by CMA GEM object functions.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 6b85d5f4caa85..bdfbcbc416260 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -61,16 +61,7 @@ static irqreturn_t komeda_kms_irq_handler(int irq, void 
*data)
 static struct drm_driver komeda_kms_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.lastclose  = drm_fb_helper_lastclose,
-   .gem_free_object_unlocked   = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
-   .dumb_create= komeda_gem_cma_dumb_create,
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table  = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
+   __DRM_GEM_CMA_DRIVER_OPS(komeda_gem_cma_dumb_create),
.fops = _cma_fops,
.name = "komeda",
.desc = "Arm Komeda Display Processor driver",
-- 
2.26.2

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

[PATCH 13/21] drm/meson: Use GEM CMA object functions

[Thomas Zimmermann]

The meson driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro now sets
these defaults and .dumb_create in struct drm_driver. All remaining
operations are provided by CMA GEM object functions.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/meson/meson_drv.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_drv.c 
b/drivers/gpu/drm/meson/meson_drv.c
index 4c5aafcec7991..2fe88f2b2fb55 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -96,19 +96,8 @@ static struct drm_driver meson_driver = {
/* IRQ */
.irq_handler= meson_irq,
 
-   /* PRIME Ops */
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
-
-   /* GEM Ops */
-   .dumb_create= meson_dumb_create,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
+   /* CMA Ops */
+   __DRM_GEM_CMA_DRIVER_OPS(meson_dumb_create),
 
/* Misc */
.fops   = ,
-- 
2.26.2

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

[PATCH 04/21] drm/aspeed: Set driver CMA functions with DRM_GEM_CMA_DRIVER_OPS

[Thomas Zimmermann]

DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver
to their defaults. No functional changes are made.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c 
b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
index 6b27242b9ee3c..1167ff78e24a3 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
@@ -188,12 +188,7 @@ DEFINE_DRM_GEM_CMA_FOPS(fops);
 
 static struct drm_driver aspeed_gfx_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
-   .gem_create_object  = drm_cma_gem_create_object_default_funcs,
-   .dumb_create= drm_gem_cma_dumb_create,
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_mmap = drm_gem_prime_mmap,
+   DRM_GEM_CMA_DRIVER_OPS,
.fops = ,
.name = "aspeed-gfx-drm",
.desc = "ASPEED GFX DRM",
-- 
2.26.2

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

[PATCH 05/21] drm/atmel-hlcdc: Use GEM CMA object functions

[Thomas Zimmermann]

The atmel-hlcdc driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
All remaining operations are provided by CMA GEM object functions.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 112aa5066ceed..871293d1aeeba 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -821,16 +821,7 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
.irq_preinstall = atmel_hlcdc_dc_irq_uninstall,
.irq_postinstall = atmel_hlcdc_dc_irq_postinstall,
.irq_uninstall = atmel_hlcdc_dc_irq_uninstall,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
-   .dumb_create = drm_gem_cma_dumb_create,
+   DRM_GEM_CMA_DRIVER_OPS,
.fops = ,
.name = "atmel-hlcdc",
.desc = "Atmel HLCD Controller DRM",
-- 
2.26.2

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

Re: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe

[Mark Brown]

On Thu, May 21, 2020 at 07:30:04PM +0800, Shengjiu Wang wrote:
> On Wed, May 20, 2020 at 8:38 PM Mark Brown  wrote:

> > Other drivers having problems means those drivers should be fixed, not
> > that we should copy the problems.  In the case of the PXA driver that's
> > very old code which predates deferred probe by I'd guess a decade.

> Thanks.

> For the FE-BE case, do you have any suggestion for how fix it?

> With DMA1->ASRC->DMA2->ESAI case, the DMA1->ASRC->DMA2
> is in FE,  ESAI is in BE.  When ESAI drvier probe,  DMA3 channel is
> created with ESAI's "dma:tx" (DMA3 channel
> is not used in this FE-BE case).When FE-BE startup, DMA2
> channel is created, it needs the ESAI's "dma:tx", so the warning
> comes out.

Not really TBH, this seems like another one of those csaes where DPCM is
creaking at the seams :/


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/panfrost: fix runtime pm imbalance on error

[Steven Price]

On 21/05/2020 08:00, dinghao@zju.edu.cn wrote:

Hi Steve,

There are two bailing out points in panfrost_job_hw_submit(): one is
the error path beginning from pm_runtime_get_sync(), the other one is
the error path beginning from WARN_ON() in the if statement. The pm
imbalance fixed in this patch is between these two paths. I think the
caller of panfrost_job_hw_submit() cannot distinguish this imbalance
outside this function.


My point is the caller expects panfrost_job_hw_submit() to increase the 
PM reference count. Since panfrost_job_hw_submit() cannot return an 
error (it's void return) we cannot signal to the caller that the 
reference hasn't been taken.



panfrost_job_timedout() calls pm_runtime_put_noidle() for every job it
finds, but all jobs are added to the pfdev->jobs just before calling
panfrost_job_hw_submit(). Therefore I think the imbalance still exists.


My point's exactly that - the "jobs are added to pfdev->jobs just before 
calling panfrost_job_hw_submit()". Since we don't have a way for 
panfrost_job_hw_submit() to fail it must unconditionally take any 
references that will then be freed later on.



But I'm not very sure if we should add pm_runtime_put on the error path
after pm_runtime_get_sync(), or remove pm_runtime_put one the error path
after WARN_ON().


The pm_runtime_put after the WARN_ON() is a bug. Sorry this is probably 
what confused you - clearly the WARN_ON() situation is never meant to 
happen in the first place, so hopefully this isn't actually possible.


Feel free to send a patch removing it! ;)


As for the problem about panfrost_devfreq_record_busy(), this may be a
new bug and requires independent patch to fix it.


Indeed, I'll post a proper patch for that later - I just spotted it 
while looking at the code.


Thanks,

Steve


Regards,
Dinghao



On 20/05/2020 12:05, Dinghao Liu wrote:

pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.

Signed-off-by: Dinghao Liu 


Actually I think we have the opposite problem. To be honest we don't
handle this situation very well. By the time panfrost_job_hw_submit() is
called the job has already been added to the pfdev->jobs array, so it's
considered submitted even if it never actually lands on the hardware. So
in the case of this function bailing out early we will then (eventually)
hit a timeout and trigger a GPU reset.

panfrost_job_timedout() iterates through the pfdev->jobs array and calls
pm_runtime_put_noidle() for each job it finds. So there's no inbalance
here that I can see.

Have you actually observed the situation where pm_runtime_get_sync()
returns a failure?

HOWEVER, it appears that by bailing out early the call to
panfrost_devfreq_record_busy() is never made, which as far as I can see
means that there may be an extra call to panfrost_devfreq_record_idle()
when the jobs have timed out. Which could underflow the counter.

But equally looking at panfrost_job_timedout(), we only call
panfrost_devfreq_record_idle() *once* even though multiple jobs might be
processed.

There's a completely untested patch below which in theory should fix that...

Steve

8<---
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 7914b1570841..f9519afca29d 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -145,6 +145,8 @@ static void panfrost_job_hw_submit(struct
panfrost_job *job, int js)
u64 jc_head = job->jc;
int ret;

+   panfrost_devfreq_record_busy(pfdev);
+
ret = pm_runtime_get_sync(pfdev->dev);
if (ret < 0)
return;
@@ -155,7 +157,6 @@ static void panfrost_job_hw_submit(struct
panfrost_job *job, int js)
}

cfg = panfrost_mmu_as_get(pfdev, >file_priv->mmu);
-   panfrost_devfreq_record_busy(pfdev);

job_write(pfdev, JS_HEAD_NEXT_LO(js), jc_head & 0x);
job_write(pfdev, JS_HEAD_NEXT_HI(js), jc_head >> 32);
@@ -410,12 +411,12 @@ static void panfrost_job_timedout(struct
drm_sched_job *sched_job)
for (i = 0; i < NUM_JOB_SLOTS; i++) {
if (pfdev->jobs[i]) {
pm_runtime_put_noidle(pfdev->dev);
+   panfrost_devfreq_record_idle(pfdev);
pfdev->jobs[i] = NULL;
}
}
spin_unlock_irqrestore(>js->job_lock, flags);

-   panfrost_devfreq_record_idle(pfdev);
panfrost_device_reset(pfdev);

for (i = 0; i < NUM_JOB_SLOTS; i++)


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

Re: [PATCH] drm/tegra: hub: Do not enable orphaned window group

[Thierry Reding]

On Tue, May 19, 2020 at 02:03:01AM -0700, Nicolin Chen wrote:
> Though the unconditional enable/disable code is not a final solution,
> we don't want to run into a NULL pointer situation when window group
> doesn't link to its DC parent if the DC is disabled in Device Tree.
> 
> So this patch simply adds a check to make sure that window group has
> a valid parent before running into tegra_windowgroup_enable/disable.
> 
> Signed-off-by: Nicolin Chen 
> ---
>  drivers/gpu/drm/tegra/hub.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)

Applied, thanks.

Thierry


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

[PATCH v5 39/38] drm: xen: fix common struct sg_table related issues

[Marek Szyprowski]

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_map_sg().

struct sg_table is a common structure used for describing a non-contiguous
memory buffer, used commonly in the DRM and graphics subsystems. It
consists of a scatterlist with memory pages and DMA addresses (sgl entry),
as well as the number of scatterlist entries: CPU pages (orig_nents entry)
and DMA mapped pages (nents entry).

It turned out that it was a common mistake to misuse nents and orig_nents
entries, calling DMA-mapping functions with a wrong number of entries or
ignoring the number of mapped entries returned by the dma_map_sg()
function.

Fix the code to refer to proper nents or orig_nents entries. This driver
reports the number of the pages in the imported scatterlist, so it should
refer to sg_table->orig_nents entry.

Signed-off-by: Marek Szyprowski 
Acked-by: Oleksandr Andrushchenko 
---
For more information, see '[PATCH v5 00/38] DRM: fix struct sg_table nents
vs. orig_nents misuse' thread:
https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprow...@samsung.com/T/

This patch has been resurrected on Oleksandr Andrushchenko request. The
patch was a part of v2 patchset, but then I've dropped it as it only
fixes the debug output, thus I didn't consider it so critical.
---
 drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c 
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index f0b85e0..ba4bdc5 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -215,7 +215,7 @@ struct drm_gem_object *
return ERR_PTR(ret);
 
DRM_DEBUG("Imported buffer of size %zu with nents %u\n",
- size, sgt->nents);
+ size, sgt->orig_nents);
 
return _obj->base;
 }
-- 
1.9.1

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

[Bug 206475] amdgpu under load drop signal to monitor until hard reset

[bugzilla-daemon]

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

andrewammerl...@riseup.net (andrewammerl...@riseup.net) changed:

   What|Removed |Added

 CC||andrewammerl...@riseup.net

--- Comment #10 from andrewammerl...@riseup.net (andrewammerl...@riseup.net) ---
Created attachment 289235
  --> https://bugzilla.kernel.org/attachment.cgi?id=289235=edit
syslog

I think I ran into this issue as well. It has happened twice. Both times it
happened 10 to 20 minutes *after* playing minecraft. Both times I was in a full
screen video meeting. Everything works, except the screen goes black, I could
finish the meeting, but without seeing anything. 

Only the monitors connected to my RX 590 go black, the one connected to the
iGPU just freezes, and after a while the cursor becomes usable again on that
monitor, though all applications remain frozen, and switching to tty does not
work. REISUB'ing the machine makes it boot on the iGPU. It needs to be
completely switched on and off to boot from the amdgpu.

It looks like it does a graphics reset (why though?):
15554.332021] amdgpu :01:00.0: GPU reset begin!

And from that point onwards everyting goes wrong:
[15554.332296] amdgpu: [powerplay] 
[15554.332296]  last message was failed ret is 65535
[15554.332297] amdgpu: [powerplay] 
[15554.332297]  failed to send message 261 ret is 65535 
[15554.332297] amdgpu: [powerplay] 
[15554.332297]  last message was failed ret is 65535

This is kernel 5.6.14
xorg-1.20.8
mesa-20.1.0_rc3
xf86-video-amdgpu-19.1.0

Full log is attached.

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

Re: [PATCH v4 3/8] spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4

[Mark Brown]

On Mon, May 18, 2020 at 07:09:20PM +0800, dillon.min...@gmail.com wrote:

> 2, use stm32 spi's "In full-duplex (BIDIMODE=0 and RXONLY=0)", as tx_buf is
> null, we must add dummy data sent out before read data.
> so, add stm32f4_spi_tx_dummy() to handle this situation.

There are flags SPI_CONTROLLER_MUST_TX and SPI_CONTROLLER_MUST_RX flags
that the driver can set if it needs to, no need to open code this in the
driver.


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

RE: [EXTERNAL] Re: [RFC PATCH 0/4] DirectX on Linux

[Steve Pronovost]

[resending as plain text, sorry about that]

Thanks Daniel, more below.

From: Daniel Vetter  
Sent: Wednesday, May 20, 2020 12:41 AM
To: Steve Pronovost 
Cc: Dave Airlie ; Sasha Levin 
; mailto:linux-hyp...@vger.kernel.org; Stephen 
Hemminger ; Ursulin, Tvrtko 
; Greg Kroah-Hartman 
; Haiyang Zhang 
; LKML ; 
dri-devel ; Chris Wilson 
; Linux Fbdev development list 
; Iouri Tarassov 
; Deucher, Alexander 
; KY Srinivasan ; 
Wei Liu ; Hawking Zhang 

Subject: Re: [EXTERNAL] Re: [RFC PATCH 0/4] DirectX on Linux

Hi Steve,

Sounds all good, some more comments and details below.

On Wed, May 20, 2020 at 5:47 AM Steve Pronovost  
wrote:
Hey guys,

Thanks for the discussion. I may not be able to immediately answer all of your 
questions, but I'll do my best .

drivers/hyperv sounds like it could be a better location. We weren't too sure 
where to put this, we though /drivers/gpu would be appropriate given this deal 
with GPUs, but I get your point... this is a vGPU driver that really only works 
when being run under Hyper-V, so drivers/hyperv is likely more appropriate.

I think "it's a virtual gpu" is the wrong sales pitch, as is "only runs on 
$platform". We have lots of drm drivers in drivers/gpu that fit that bill. The 
better pitch I think is "it's a not a gpu, it's a dx12 protocol pipe" and "we 
actually do not want to integrate with the linux gpu ecosystem and primitives, 
we want to integrate with dx12 ecosystem and primitives to make the seamless 
rdp/rail/vail stuff work nicely". Below some more thoughts on the technical 
said.

[spronovo] Agreed. As I mentioned in another reply, that protocol isn’t tied to 
DX… but the point you are making is still valid. This is really a projection of 
the Windows native abstraction of a GPU that windows user mode driver (dx, gl, 
cl, vulkan, cuda, etc…) are familiar with and use to communicate with the GPU… 
This effectively enable porting of these user mode driver to Linux inside of 
WSL and allow them to share the GPU with the host. Our goal is to offer 
CL/EGL/GLX/CUDA/… API support for applications running inside of WSL and 
integrate their output on the Windows desktop through the Wayland compositor we 
are building. The fact that we are using layer to implement some of these APIs 
(to reduce our partners work among other thing) is just an implementation 
details that most application shouldn’t have to worry about… “it just works” . 
From that perspective we’re fine moving the driver under a different node than 
/driver/gpu .

In term of presentation, I need to clarify a few things. We announced today 
that we're also adding support for Linux GUI applications. The way this will 
work is roughly as follow. We're writing a Wayland compositor that will 
essentially bridge over RDP-RAIL (RAIL=Remote Application Integrated Locally). 
We're starting from a Weston base. Weston already has an RDP Backend, but 
that's for a full desktop remoting scheme. Weston draws a desktop and remote it 
over RDP... and then you can peek at that desktop using an rdp client on the 
Windows side. RAIL works differently. In that case our wayland compositor no 
longer paint a desktop... instead it simply forward individual visual / 
wl_surface over the RDP RAIL channel such that these visual can be displayed on 
the Windows desktop. The RDP client create proxy window for each of these top 
level visual and their content is filled with the data coming over the RDP 
channel. All pixels are owned by the RDP server/WSL... so these windows looks 
different than native window are they are painted and themed by WSL. The proxy 
window on the host gather input and inject back over RDP... This is essentially 
how application remoting works on windows and this is all publicly documented 
as part of the various RDP protocol specification. As a matter of fact, for the 
RDP server on the Weston side we are looking at continue to leverage FreeRDP 
(and provide fixes/enhancement as needed to the public project). Further, we're 
looking at further improvement down this path to avoid having to copy the 
content over the RAIL channel and instead just share/swap buffer between the 
guest and the host. We have extension to the RDP protocol, called VAIL 
(Virtualized Application Integrated Locally) which does that today. Today this 
is only use in Windows on Windows for very specific scenario. We're looking at 
extending the public RDP protocol with 

RE: [EXTERNAL] Re: [RFC PATCH 0/4] DirectX on Linux

[Steve Pronovost]

>Echoing what others said, you're not making a DRM driver. The driver should 
>live outside of the DRM code.

Agreed, please see my earlier reply. We'll be moving the driver to 
drivers/hyperv node or something similar. Apology for the confusion here.

> I have one question about the driver API: on Windows, DirectX versions are 
> loosly tied to Windows releases. So I guess you can change the kernel 
> interface among DirectX versions?
> If so, how would this work on Linux in the long term? If there ever is a 
> DirectX 13 or 14 with incompatible kernel interfaces, how would you plan to 
> update the Linux driver?

You should think of the communication over the VM Bus for the vGPU projection 
as a strongly versioned interface. We will be keeping compatibility with older 
version of that interface as it evolves over time so we can continue to run 
older guest (we already do). This protocol isn't actually tied to the DX API. 
It is a generic abstraction for the GPU that can be used for any APIs (for 
example the NVIDIA CUDA driver that we announced is going over the same 
protocol to access the GPU). 

New version of user mode DX can either take advantage or sometime require new 
services from this kernel abstraction. This mean that pulling a new version of 
user mode DX can mean having to also pull a new version of this vGPU kernel 
driver. For WSL, these essentially ships together. The kernel driver ships as 
part of our WSL2 Linux Kernel integration. User mode DX bits ships with 
Windows. 

-Original Message-
From: Thomas Zimmermann  
Sent: Wednesday, May 20, 2020 12:11 AM
To: Sasha Levin ; alexander.deuc...@amd.com; 
ch...@chris-wilson.co.uk; ville.syrj...@linux.intel.com; hawking.zh...@amd.com; 
tvrtko.ursu...@intel.com
Cc: linux-ker...@vger.kernel.org; linux-hyp...@vger.kernel.org; KY Srinivasan 
; Haiyang Zhang ; Stephen Hemminger 
; wei@kernel.org; Steve Pronovost 
; Iouri Tarassov ; 
dri-devel@lists.freedesktop.org; linux-fb...@vger.kernel.org; 
gre...@linuxfoundation.org
Subject: [EXTERNAL] Re: [RFC PATCH 0/4] DirectX on Linux

Hi

Am 19.05.20 um 18:32 schrieb Sasha Levin:
> There is a blog post that goes into more detail about the bigger 
> picture, and walks through all the required pieces to make this work. 
> It is available here:
> https://devblogs.microsoft.com/directx/directx-heart-linux . The rest 
> of this cover letter will focus on the Linux Kernel bits.

That's quite a surprise. Thanks for your efforts to contribute.

> 
> Overview
> 
> 
> This is the first draft of the Microsoft Virtual GPU (vGPU) driver. 
> The driver exposes a paravirtualized GPU to user mode applications 
> running in a virtual machine on a Windows host. This enables hardware 
> acceleration in environment such as WSL (Windows Subsystem for Linux) 
> where the Linux virtual machine is able to share the GPU with the 
> Windows host.
> 
> The projection is accomplished by exposing the WDDM (Windows Display 
> Driver Model) interface as a set of IOCTL. This allows APIs and user 
> mode driver written against the WDDM GPU abstraction on Windows to be 
> ported to run within a Linux environment. This enables the port of the
> D3D12 and DirectML APIs as well as their associated user mode driver 
> to Linux. This also enables third party APIs, such as the popular 
> NVIDIA Cuda compute API, to be hardware accelerated within a WSL environment.
> 
> Only the rendering/compute aspect of the GPU are projected to the 
> virtual machine, no display functionality is exposed. Further, at this 
> time there are no presentation integration. So although the D3D12 API 
> can be use to render graphics offscreen, there is no path (yet) for 
> pixel to flow from the Linux environment back onto the Windows host 
> desktop. This GPU stack is effectively side-by-side with the native 
> Linux graphics stack.
> 
> The driver creates the /dev/dxg device, which can be opened by user 
> mode application and handles their ioctls. The IOCTL interface to the 
> driver is defined in dxgkmthk.h (Dxgkrnl Graphics Port Driver ioctl 
> definitions). The interface matches the D3DKMT interface on Windows.
> Ioctls are implemented in ioctl.c.

Echoing what others said, you're not making a DRM driver. The driver should 
live outside of the DRM code.

I have one question about the driver API: on Windows, DirectX versions are 
loosly tied to Windows releases. So I guess you can change the kernel interface 
among DirectX versions?

If so, how would this work on Linux in the long term? If there ever is a 
DirectX 13 or 14 with incompatible kernel interfaces, how would you plan to 
update the Linux driver?

Best regards
Thomas

> 
> When a VM starts, hyper-v on the host adds virtual GPU devices to the 
> VM via the hyper-v driver. The host offers several VM bus channels to 
> the
> VM: the global channel and one channel per virtual GPU, assigned to 
> the VM.
> 
> The driver registers with the hyper-v driver (hv_driver) for the 
> arrival of 

RE: [EXTERNAL] Re: [RFC PATCH 0/4] DirectX on Linux

[Steve Pronovost]

Thanks Daniel, more below.

From: Daniel Vetter 
Sent: Wednesday, May 20, 2020 12:41 AM
To: Steve Pronovost 
Cc: Dave Airlie ; Sasha Levin ; 
linux-hyp...@vger.kernel.org; Stephen Hemminger ; 
Ursulin, Tvrtko ; Greg Kroah-Hartman 
; Haiyang Zhang ; LKML 
; dri-devel ; 
Chris Wilson ; Linux Fbdev development list 
; Iouri Tarassov ; Deucher, 
Alexander ; KY Srinivasan ; Wei 
Liu ; Hawking Zhang 
Subject: Re: [EXTERNAL] Re: [RFC PATCH 0/4] DirectX on Linux

Hi Steve,

Sounds all good, some more comments and details below.

On Wed, May 20, 2020 at 5:47 AM Steve Pronovost 
mailto:spron...@microsoft.com>> wrote:
Hey guys,

Thanks for the discussion. I may not be able to immediately answer all of your 
questions, but I'll do my best .

drivers/hyperv sounds like it could be a better location. We weren't too sure 
where to put this, we though /drivers/gpu would be appropriate given this deal 
with GPUs, but I get your point... this is a vGPU driver that really only works 
when being run under Hyper-V, so drivers/hyperv is likely more appropriate.

I think "it's a virtual gpu" is the wrong sales pitch, as is "only runs on 
$platform". We have lots of drm drivers in drivers/gpu that fit that bill. The 
better pitch I think is "it's a not a gpu, it's a dx12 protocol pipe" and "we 
actually do not want to integrate with the linux gpu ecosystem and primitives, 
we want to integrate with dx12 ecosystem and primitives to make the seamless 
rdp/rail/vail stuff work nicely". Below some more thoughts on the technical 
said.

[spronovo] Agreed. As I mentioned in another reply, that protocol isn’t tied to 
DX… but the point you are making is still valid. This is really a projection of 
the Windows native abstraction of a GPU that windows user mode driver (dx, gl, 
cl, vulkan, cuda, etc…) are familiar with and use to communicate with the GPU… 
This effectively enable porting of these user mode driver to Linux inside of 
WSL and allow them to share the GPU with the host. Our goal is to offer 
CL/EGL/GLX/CUDA/… API support for applications running inside of WSL and 
integrate their output on the Windows desktop through the Wayland compositor we 
are building. The fact that we are using layer to implement some of these APIs 
(to reduce our partners work among other thing) is just an implementation 
details that most application shouldn’t have to worry about… “it just works” . 
From that perspective we’re fine moving the driver under a different node than 
/driver/gpu .

In term of presentation, I need to clarify a few things. We announced today 
that we're also adding support for Linux GUI applications. The way this will 
work is roughly as follow. We're writing a Wayland compositor that will 
essentially bridge over RDP-RAIL (RAIL=Remote Application Integrated Locally). 
We're starting from a Weston base. Weston already has an RDP Backend, but 
that's for a full desktop remoting scheme. Weston draws a desktop and remote it 
over RDP... and then you can peek at that desktop using an rdp client on the 
Windows side. RAIL works differently. In that case our wayland compositor no 
longer paint a desktop... instead it simply forward individual visual / 
wl_surface over the RDP RAIL channel such that these visual can be displayed on 
the Windows desktop. The RDP client create proxy window for each of these top 
level visual and their content is filled with the data coming over the RDP 
channel. All pixels are owned by the RDP server/WSL... so these windows looks 
different than native window are they are painted and themed by WSL. The proxy 
window on the host gather input and inject back over RDP... This is essentially 
how application remoting works on windows and this is all publicly documented 
as part of the various RDP protocol specification. As a matter of fact, for the 
RDP server on the Weston side we are looking at continue to leverage FreeRDP 
(and provide fixes/enhancement as needed to the public project). Further, we're 
looking at further improvement down this path to avoid having to copy the 
content over the RAIL channel and instead just share/swap buffer between the 
guest and the host. We have extension to the RDP protocol, called VAIL 
(Virtualized Application Integrated Locally) which does that today. Today this 
is only use in Windows on Windows for very specific scenario. We're looking at 
extending the public RDP protocol with these VAIL extension to make this an 
official Microsoft supported protocol which would allow us to target this in 
WSL. We have finished designing this part in details. Our goal would be to 
leverage something along the line of wl_drm, dma-buf, dma-fence, etc... This 
compositor and all our contribution to FreeRDP will be fully open source, 
including our design doc. We're not quite sure yet whether this will be offered 
as a separate project entirely distinct from it's Weston root... or if we'll 
propose an extension to Weston to operate in this mode. We would like to build 
it such 

Re: [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM

[Michel Dänzer]

On 2020-05-22 12:40 p.m., Christian König wrote:
> Am 20.05.20 um 18:25 schrieb Michel Dänzer:
>> On 2020-05-20 4:43 p.m., Christian König wrote:
>>> Am 13.05.20 um 13:03 schrieb Christian König:
 Unfortunately AGP is still to widely used as we could just drop
 support for using its GART.

 Not using the AGP GART also doesn't mean a loss in functionality since
 drivers will just fallback to the driver specific PCI GART.

 For now just deprecate the code and don't enable the AGP GART in TTM
 even when general AGP support is available.
>>> So I've used an ancient system (32bit) to setup a test box for this.
>>>
>>>
>>> The first GPU I could test is an RV280 (Radeon 9200 PRO) which is easily
>>> 15 years old.
>>>
>>> What happens in AGP mode is that glxgears shows artifacts during
>>> rendering on this system.
>>>
>>> In PCI mode those rendering artifacts are gone and glxgears seems to
>>> draw everything correctly now.
>>>
>>> Performance is obviously not comparable, cause in AGP we don't render
>>> all triangles correctly.
>>>
>>>
>>> The second GPU I could test is an RV630 PRO (Radeon HD 2600 PRO AGP)
>>> which is more than 10 years old.
>>>
>>> As far as I can tell this one works in both AGP and PCIe mode perfectly
>>> fine.
>>>
>>> Since this is only a 32bit system I couldn't really test any OpenGL game
>>> that well.
>>>
>>> But for glxgears switching from AGP to PCIe mode seems to result in a
>>> roughly 5% performance drop.
>>>
>>> The surprising reason for this is not the better TLB performance, but
>>> the lack of USWC support for the PCIe GART in radeon.
>> I suspect the main reason it's only 5% is that PCIe GART page tables are
>> stored in VRAM, so they don't need to be fetched across the PCIe link
>> (and presumably it has more than one TLB entry as well). The difference
>> is much bigger with native AGP ASICs with PCI GART.
> 
> Do you have some hardware you could give that a try on?

As I mentioned before, I tested this many times on my AGP PowerBooks
back in the day. The result was always a similar, big hit with PCI GART
vs AGP (even just 1x). I haven't seen any reason to believe this has
changed.


> While I agree that it means a performance regression, this is a rather
> high motivation to go ahead with at least the first patch.

I totally agree with the benefits, I just want everyone to be honest and
clear about the performance hit with native AGP Radeons, which already
have very weak performance by today's standards even with AGP.


-- 
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

Re: [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM

[Christian König]

Am 20.05.20 um 18:18 schrieb Alex Deucher:

On Wed, May 20, 2020 at 10:43 AM Christian König
 wrote:

Am 13.05.20 um 13:03 schrieb Christian König:

Unfortunately AGP is still to widely used as we could just drop support for 
using its GART.

Not using the AGP GART also doesn't mean a loss in functionality since drivers 
will just fallback to the driver specific PCI GART.

For now just deprecate the code and don't enable the AGP GART in TTM even when 
general AGP support is available.

So I've used an ancient system (32bit) to setup a test box for this.


The first GPU I could test is an RV280 (Radeon 9200 PRO) which is easily
15 years old.

What happens in AGP mode is that glxgears shows artifacts during
rendering on this system.

In PCI mode those rendering artifacts are gone and glxgears seems to
draw everything correctly now.

Performance is obviously not comparable, cause in AGP we don't render
all triangles correctly.


The second GPU I could test is an RV630 PRO (Radeon HD 2600 PRO AGP)
which is more than 10 years old.

As far as I can tell this one works in both AGP and PCIe mode perfectly
fine.

Since this is only a 32bit system I couldn't really test any OpenGL game
that well.

But for glxgears switching from AGP to PCIe mode seems to result in a
roughly 5% performance drop.

The surprising reason for this is not the better TLB performance, but
the lack of USWC support for the PCIe GART in radeon.


So if anybody wants to get his hands dirty and squeeze a bit more
performance out of the old hardware, porting USWC from amdgpu to radeon
shouldn't be to much of a problem.

We do support USWC on radeon, although I think we had separate flags
for cached and WC.  That said we had a lot of problems with WC on 32
bit (see radeon_bo_create()).  The other problem is that, at least on
the really old radeons, the PCI gart didn't support snooped and
unsnooped.  It was always snooped.  It wasn't until pcie that the gart
hw got support for both.  For AGP, the expectation was that AGP
provided the uncached memory.


Oh, indeed. I didn't remembered that.

Interesting is that in this case I have no idea where the performance 
difference is coming from.






Summing it up I'm still leaning towards disabling AGP completely by
default for radeon and deprecate it in TTM as well.

Thoughts? Especially Alex what do you think.

Works for me.


I will take that as an rb and commit at least the first patch.

Thanks,
Christian.



Alex


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

Re: [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM

[Christian König]

Am 20.05.20 um 18:25 schrieb Michel Dänzer:

On 2020-05-20 4:43 p.m., Christian König wrote:

Am 13.05.20 um 13:03 schrieb Christian König:

Unfortunately AGP is still to widely used as we could just drop
support for using its GART.

Not using the AGP GART also doesn't mean a loss in functionality since
drivers will just fallback to the driver specific PCI GART.

For now just deprecate the code and don't enable the AGP GART in TTM
even when general AGP support is available.

So I've used an ancient system (32bit) to setup a test box for this.


The first GPU I could test is an RV280 (Radeon 9200 PRO) which is easily
15 years old.

What happens in AGP mode is that glxgears shows artifacts during
rendering on this system.

In PCI mode those rendering artifacts are gone and glxgears seems to
draw everything correctly now.

Performance is obviously not comparable, cause in AGP we don't render
all triangles correctly.


The second GPU I could test is an RV630 PRO (Radeon HD 2600 PRO AGP)
which is more than 10 years old.

As far as I can tell this one works in both AGP and PCIe mode perfectly
fine.

Since this is only a 32bit system I couldn't really test any OpenGL game
that well.

But for glxgears switching from AGP to PCIe mode seems to result in a
roughly 5% performance drop.

The surprising reason for this is not the better TLB performance, but
the lack of USWC support for the PCIe GART in radeon.

I suspect the main reason it's only 5% is that PCIe GART page tables are
stored in VRAM, so they don't need to be fetched across the PCIe link
(and presumably it has more than one TLB entry as well). The difference
is much bigger with native AGP ASICs with PCI GART.


Do you have some hardware you could give that a try on?

I mean the first card I put into the system obviously only worked 
correctly with AGP disabled.


While I agree that it means a performance regression, this is a rather 
high motivation to go ahead with at least the first patch.


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

[PATCH] drm/mediatek: dsi: fix scrolling of panel with small hfp or hbp

[Jitao Shi]

If panel has too small hfp or hbp, horizontal_frontporch_byte or
horizontal_backporch_byte may become very small value or negative
value. This patch adjusts their values so that they are greater
than minimum value and keep total of them unchanged.

Signed-off-by: Jitao Shi 
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 0ede69830a9d..aebaafd90ceb 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -148,6 +148,9 @@
(type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
(type == MIPI_DSI_DCS_READ))
 
+#define MIN_HFP_BYTE   0x02
+#define MIN_HBP_BYTE   0x02
+
 struct mtk_phy_timing {
u32 lpx;
u32 da_hs_prepare;
@@ -450,6 +453,7 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
u32 horizontal_sync_active_byte;
u32 horizontal_backporch_byte;
u32 horizontal_frontporch_byte;
+   s32 signed_hfp_byte, signed_hbp_byte;
u32 dsi_tmp_buf_bpp, data_phy_cycles;
struct mtk_phy_timing *timing = >phy_timing;
 
@@ -519,6 +523,20 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
}
}
 
+   signed_hfp_byte = (s32)horizontal_frontporch_byte;
+   signed_hbp_byte = (s32)horizontal_backporch_byte;
+
+   if (signed_hfp_byte + signed_hbp_byte < MIN_HFP_BYTE + MIN_HBP_BYTE) {
+   DRM_WARN("Calculated hfp_byte and hbp_byte are too small, "
+"panel may not work properly.\n");
+   } else if (signed_hfp_byte < MIN_HFP_BYTE) {
+   horizontal_frontporch_byte = MIN_HFP_BYTE;
+   horizontal_backporch_byte -= MIN_HFP_BYTE - signed_hfp_byte;
+   } else if (signed_hbp_byte < MIN_HBP_BYTE) {
+   horizontal_frontporch_byte -= MIN_HBP_BYTE - signed_hbp_byte;
+   horizontal_backporch_byte = MIN_HBP_BYTE;
+   }
+
writel(horizontal_sync_active_byte, dsi->regs + DSI_HSA_WC);
writel(horizontal_backporch_byte, dsi->regs + DSI_HBP_WC);
writel(horizontal_frontporch_byte, dsi->regs + DSI_HFP_WC);
-- 
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Pekka Paalanen]

On Wed, 20 May 2020 16:19:00 +0200
Daniel Vetter  wrote:

> On Wed, May 20, 2020 at 3:20 PM Simon Ser  wrote:
> >
> > On Wednesday, May 20, 2020 2:55 PM, Daniel Vetter  wrote:
> >  
> > > Maybe we should add an explicit note that there's no guarantee about the
> > > new chardev minor this new device will get, it could both inherit the
> > > existing one (you can't open the old one anymore anyway) or get a new one?
> > >
> > > Or does userspace want a guarantee, i.e. as long as there's still a handle
> > > open kernel guarantees to not recycle the chardev minor (which is what we
> > > currently do). In that case better to add that to your list of guarantees
> > > above.  
> >
> > The are race conditions to consider too, e.g.
> >
> > - Compositor sends /dev/dri/card0 to a client
> > - card0 goes away
> > - Another device takes card0
> > - Client receives /dev/dri/card0 and then starts using it, but it's the
> >   wrong device  
> 
> Oh reminds me, what should we do about open() - that one will fail,
> the chardev is going away after all, not failing kinda doesn't make
> sense. And more tricky, about creating new leases?
> 
> I think reasonable semantics here would be that both of these "create
> a new open drm fd" operations can fail as soon as the device is
> unplugged. Userspace needs to be able to deal with that.

Hi,

yeah, we can make mmap read/write end result undefined, recycle char
minors like pids, and let new open()s and new leases fail. Pretty much
everything Daniel and Simon said make sense to me.

I'll spin a v2, but maybe next week.

What about the drm_ioctl() issue Andrey pointed out?


Thanks,
pq


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

Re: [PATCH] drm: rcar-du: Fix build error

[Kieran Bingham]

Hi Daniel,

On 18/05/2020 21:16, Daniel Gomez wrote:
> Select DRM_KMS_HELPER dependency.
> 
> Build error when DRM_KMS_HELPER is not selected:
> 
> drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xd48): undefined reference to 
> `drm_atomic_helper_bridge_duplicate_state'
> drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xd50): undefined reference to 
> `drm_atomic_helper_bridge_destroy_state'
> drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xd70): undefined reference to 
> `drm_atomic_helper_bridge_reset'
> drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xdc8): undefined reference to 
> `drm_atomic_helper_connector_reset'
> drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xde0): undefined reference to 
> `drm_helper_probe_single_connector_modes'
> drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xe08): undefined reference to 
> `drm_atomic_helper_connector_duplicate_state'
> drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xe10): undefined reference to 
> `drm_atomic_helper_connector_destroy_state'
> 

Looking at the files in rcar_du that utilise drm_atomic_helpers...

git grep -l drm_atomic_helper_ drivers/gpu/drm/rcar-du/
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c
 drivers/gpu/drm/rcar-du/rcar_du_kms.c
 drivers/gpu/drm/rcar-du/rcar_du_plane.c
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c
 drivers/gpu/drm/rcar-du/rcar_du_writeback.c
 drivers/gpu/drm/rcar-du/rcar_lvds.c

of those, these are configurable:

 rcar_du_vsp.c  # DRM_RCAR_VSP
 rcar_du_writeback.c# DRM_RCAR_WRITEBACK
 rcar_lvds.c# DRM_RCAR_LVDS

But VSP and WRITEBACK are already implicitly dependant upon DRM_RCAR_DU
because they get built into the DU module.

So indeed, only the RCAR_LVDS is a separate module, using those helpers,
so I think a select is a reasonable fix.

I would also ask whether DRM_RCAR_LVDS should depend upon DRM_RCAR_DU
though as well.

There is no linkage requirement, as it's a standalone bridge driver from
what I can see, but I don't think it serves much purpose without the DU?

Anyway, even if it's just for compile testing maybe, the select here
should be fine.

Reviewed-by: Kieran Bingham 

> Signed-off-by: Daniel Gomez 
> ---
>  drivers/gpu/drm/rcar-du/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> index 0919f1f159a4..f65d1489dc50 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -31,6 +31,7 @@ config DRM_RCAR_DW_HDMI
>  config DRM_RCAR_LVDS
>   tristate "R-Car DU LVDS Encoder Support"
>   depends on DRM && DRM_BRIDGE && OF
> + select DRM_KMS_HELPER
>   select DRM_PANEL
>   select OF_FLATTREE
>   select OF_OVERLAY
> 

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

Re: [PATCH] drm/radeon/dpm: Replace one-element array and use struct_size() helper

[Christian König]

Am 22.05.20 um 03:25 schrieb Gustavo A. R. Silva:

The current codebase makes use of one-element arrays in the following
form:

struct something {
 int length;
 u8 data[1];
};

struct something *instance;

instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
instance->length = size;
memcpy(instance->data, source, size);

but the preferred mechanism to declare variable-length types such as
these ones is a flexible array member[1][2], introduced in C99:

struct foo {
 int stuff;
 struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on. So, replace
the one-element array with a flexible-array member.

Also, make use of the new struct_size() helper to properly calculate the
size of struct NISLANDS_SMC_SWSTATE.

This issue was found with the help of Coccinelle and, audited and fixed
_manually_.

[1] 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2FZero-Length.htmldata=02%7C01%7Cchristian.koenig%40amd.com%7C7dd54e944eff4d17178008d7fdee62d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637257072615411745sdata=fQHnbXZpsgiMjHOr%2By0Uq12jpCYEYbdX5K26iNkwyeM%3Dreserved=0
[2] 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKSPP%2Flinux%2Fissues%2F21data=02%7C01%7Cchristian.koenig%40amd.com%7C7dd54e944eff4d17178008d7fdee62d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637257072615411745sdata=gg20YupmqsaW%2Bg3VyJL%2BkjE3kFwnWF1RD1D2QP04OLk%3Dreserved=0
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva 
---
  drivers/gpu/drm/amd/amdgpu/si_dpm.h | 2 +-
  drivers/gpu/drm/radeon/ni_dpm.c | 7 ---
  2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.h 
b/drivers/gpu/drm/amd/amdgpu/si_dpm.h
index 6b7d292b919f3..bc0be6818e218 100644
--- a/drivers/gpu/drm/amd/amdgpu/si_dpm.h
+++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.h
@@ -781,7 +781,7 @@ struct NISLANDS_SMC_SWSTATE
  uint8_t levelCount;
  uint8_t padding2;
  uint8_t padding3;
-NISLANDS_SMC_HW_PERFORMANCE_LEVEL   levels[1];
+NISLANDS_SMC_HW_PERFORMANCE_LEVEL   levels[];
  };
  
  typedef struct NISLANDS_SMC_SWSTATE NISLANDS_SMC_SWSTATE;

diff --git a/drivers/gpu/drm/radeon/ni_dpm.c b/drivers/gpu/drm/radeon/ni_dpm.c
index b57c37ddd164c..7d81dde509dc9 100644
--- a/drivers/gpu/drm/radeon/ni_dpm.c
+++ b/drivers/gpu/drm/radeon/ni_dpm.c
@@ -2685,11 +2685,12 @@ static int ni_upload_sw_state(struct radeon_device 
*rdev,
struct rv7xx_power_info *pi = rv770_get_pi(rdev);
u16 address = pi->state_table_start +
offsetof(NISLANDS_SMC_STATETABLE, driverState);
-   u16 state_size = sizeof(NISLANDS_SMC_SWSTATE) +
-   ((NISLANDS_MAX_SMC_PERFORMANCE_LEVELS_PER_SWSTATE - 1) * 
sizeof(NISLANDS_SMC_HW_PERFORMANCE_LEVEL));
+   NISLANDS_SMC_SWSTATE *smc_state;
+   u16 state_size = struct_size(smc_state, levels,
+   NISLANDS_MAX_SMC_PERFORMANCE_LEVELS_PER_SWSTATE);


Probably better to use size_t instead of u16 here. With that fixed feel 
free to stick my rb on the patch.


Regards,
Christian.


int ret;
-   NISLANDS_SMC_SWSTATE *smc_state = kzalloc(state_size, GFP_KERNEL);
  
+	smc_state = kzalloc(state_size, GFP_KERNEL);

if (smc_state == NULL)
return -ENOMEM;
  


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

Re: [RFC PATCH 0/8] Qualcomm Cloud AI 100 driver

[Jeffrey Hugo]

On 5/20/2020 2:34 AM, Daniel Vetter wrote:

On Wed, May 20, 2020 at 7:15 AM Greg Kroah-Hartman
 wrote:


On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:

On Tue, May 19, 2020 at 07:41:20PM +0200, Greg Kroah-Hartman wrote:

On Tue, May 19, 2020 at 08:57:38AM -0600, Jeffrey Hugo wrote:

On 5/18/2020 11:08 PM, Dave Airlie wrote:

On Fri, 15 May 2020 at 00:12, Jeffrey Hugo  wrote:


Introduction:
Qualcomm Cloud AI 100 is a PCIe adapter card which contains a dedicated
SoC ASIC for the purpose of efficently running Deep Learning inference
workloads in a data center environment.

The offical press release can be found at -
https://www.qualcomm.com/news/releases/2019/04/09/qualcomm-brings-power-efficient-artificial-intelligence-inference

The offical product website is -
https://www.qualcomm.com/products/datacenter-artificial-intelligence

At the time of the offical press release, numerious technology news sites
also covered the product.  Doing a search of your favorite site is likely
to find their coverage of it.

It is our goal to have the kernel driver for the product fully upstream.
The purpose of this RFC is to start that process.  We are still doing
development (see below), and thus not quite looking to gain acceptance quite
yet, but now that we have a working driver we beleive we are at the stage
where meaningful conversation with the community can occur.



Hi Jeffery,

Just wondering what the userspace/testing plans for this driver.

This introduces a new user facing API for a device without pointers to
users or tests for that API.


We have daily internal testing, although I don't expect you to take my word
for that.

I would like to get one of these devices into the hands of Linaro, so that
it can be put into KernelCI.  Similar to other Qualcomm products. I'm trying
to convince the powers that be to make this happen.

Regarding what the community could do on its own, everything but the Linux
driver is considered proprietary - that includes the on device firmware and
the entire userspace stack.  This is a decision above my pay grade.


Ok, that's a decision you are going to have to push upward on, as we
really can't take this without a working, open, userspace.


Uh wut.

So the merge criteria for drivers/accel (atm still drivers/misc but I
thought that was interim until more drivers showed up) isn't actually
"totally-not-a-gpu accel driver without open source userspace".

Instead it's "totally-not-a-gpu accel driver without open source
userspace" _and_ you have to be best buddies with Greg. Or at least
not be on the naughty company list. Since for habanalabs all you
wanted is a few test cases to exercise the ioctls. Not the entire
userspace.


Also, to be fair, I have changed my mind after seeing the mess of
complexity that these "ioctls for everyone!" type of pass-through
these kinds of drivers are creating.  You were right, we need open
userspace code in order to be able to properly evaluate and figure out
what they are doing is right or not and be able to maintain things over
time correctly.

So I was wrong, and you were right, my apologies for my previous
stubbornness.


Awesome and don't worry, I'm pretty sure we've all been stubborn
occasionally :-)

 From a drivers/gpu pov I think still not quite there since we also
want to see the compiler for these programmable accelerator thingies.
But just having a fairly good consensus that "userspace library with
all the runtime stuff excluding compiler must be open" is a huge step
forward. Next step may be that we (kernel overall, drivers/gpu will
still ask for the full thing) have ISA docs for these programmable
things, so that we can also evaluate that aspect and gauge how many
security issues there might be. Plus have a fighting chance to fix up
the security leaks when (post smeltdown I don't really want to
consider this an if) someone finds a hole in the hw security wall. At
least in drivers/gpu we historically have a ton of drivers with
command checkers to validate what userspace wants to run on the
accelerator thingie. Both in cases where the hw was accidentally too
strict, and not strict enough.


I think this provides a pretty clear guidance on what you/the community 
are looking for, both now and possibly in the future.


Thank you.

From my perspective, it would be really nice if there was something 
like Mesa that was a/the standard for these sorts of accelerators.  Its 
somewhat the wild west, and we've struggled with it.


I don't work on the compiler end of things, but based on what I've seen 
in my project, I think the vendors are going to be highly resistant to 
opening that up.  There is more than just the raw instruction set that 
goes on in the device, and its viewed as "secret sauce" even though I 
agree with your previous statements on that viewpoint.

--
Jeffrey Hugo
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH 2/3] drm/etnaviv: Don't ignore errors on getting clocks

[Lubomir Rintel]

On Thu, May 14, 2020 at 09:53:08AM +0100, Russell King - ARM Linux admin wrote:
> On Thu, May 14, 2020 at 10:40:58AM +0200, Lucas Stach wrote:
> > Am Donnerstag, den 14.05.2020, 09:27 +0100 schrieb Russell King - ARM Linux 
> > admin:
> > > On Thu, May 14, 2020 at 10:18:02AM +0200, Lucas Stach wrote:
> > > > Am Mittwoch, den 13.05.2020, 23:41 -0300 schrieb Fabio Estevam:
> > > > > On Wed, May 13, 2020 at 2:09 PM Fabio Estevam  
> > > > > wrote:
> > > > > 
> > > > > > The binding doc 
> > > > > > Documentation/devicetree/bindings/gpu/vivante,gc.yaml
> > > > > > says that only the 'reg' clock could be optional, the others are
> > > > > > required.
> > > > > 
> > > > > arch/arm/boot/dts/dove.dtsi only uses the 'core' clock.
> > > > > arch/arm/boot/dts/stm32mp157.dtsi uses 'bus' and 'core'
> > > > > 
> > > > > Maybe the binding needs to be updated and it seems that using
> > > > > devm_clk_get_optional() like you propose is safe.
> > > > 
> > > > The binding is correct as-is. We want to require those clocks to be
> > > > present, but the dove DT was added before the binding was finalized, so
> > > > the driver still treats the clocks as optional to not break
> > > > compatibility with old DTs. Maybe this warrants a comment in the
> > > > code...
> > > 
> > > The binding doc in mainline says:
> > > 
> > >   clocks:
> > > items:
> > >   - description: AXI/master interface clock
> > >   - description: GPU core clock
> > >   - description: Shader clock (only required if GPU has feature 
> > > PIPE_3D)
> > >   - description: AHB/slave interface clock (only required if GPU can 
> > > gate slave interface independently)
> > > minItems: 1
> > > maxItems: 4
> > > 
> > >   clock-names:
> > > items:
> > >   enum: [ bus, core, shader, reg ]
> > > minItems: 1
> > > maxItems: 4
> > > 
> > > which looks correct to me - and means that Dove is compliant with that.
> > 
> > The YAML binding actually did loose something in translation here,
> > which I didn't notice. Previously all those clocks were listed under
> > "Required properties", with the exceptions listed in parenthesis. So
> > the Dove GPU, which is a combined 2D/3D core should have axi, core and
> > shader clocks specified.
> 
> That may be your desire, but that is impossible without knowing that
> (a) it has the clocks
> (b) what those clocks are connected to
> 
> I guess we could "make something up" but as DT is supposed to describe
> hardware, I don't see how we can satisfy that and your requirement.
> 
> The only thing that is known from the documentation is that there is
> one clock for the GPU on Dove.

Yes. This means that in fact "core" is the only required clock for all
implementations of vivante,gc and the common binding needs to be updated
to reflect that. I'll follow with a patch that does that, unless there
are strong objections.

If there are implementations that require different clock inputs, then they
need to use additional compatible string for the particular flavor and the
binding should have conditionals for them. Something like this:

  if:
properties:
  compatible:
contains:
  const: fsl,imx6sx-gpu
  then:
properties:
  clocks:
minItems: 4

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

[Bug Report] drivers/video/fbdev/da8xx-fb.c: undefined behavior when left shifting

[Changming Liu]

Hi Bartlomiej,
Greetings, it's me again, I sent you a bug report yesterday, I hope that find 
you well.

This time I found that in /drivers/video/fbdev/da8xx-fb.c
function lcd_cfg_vertical_sync, there might be an undefined result by left 
shifting.

More specifically, in function lcd_cfg_vertical_sync, line 437. back_porch is a 
signed integer 
which might come from user space. And it's logic AND with string literal 0xff. 
The result is then left shifted by 24 bits.

The problem is, since the logic AND produce a signed integer and the result of 
left shifting this signed integer
(whose lowest 8 bits not cleared) by 24 bits is undefined when its 8th bit is 
1. Similar patterns can be found in line 410 as well.

I wonder if this bug is worth fixing? This can help me understand linux and UB 
a lot.

Looking forward to you valuable response.

Best regards,
Changming Liu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/panfrost: fix runtime pm imbalance on error

[Dinghao Liu]

pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.

Signed-off-by: Dinghao Liu 
---
 drivers/gpu/drm/panfrost/panfrost_job.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c 
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 7914b1570841..5719e356c969 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -146,8 +146,10 @@ static void panfrost_job_hw_submit(struct panfrost_job 
*job, int js)
int ret;
 
ret = pm_runtime_get_sync(pfdev->dev);
-   if (ret < 0)
+   if (ret < 0) {
+   pm_runtime_put_sync_autosuspend(pfdev->dev);
return;
+   }
 
if (WARN_ON(job_read(pfdev, JS_COMMAND_NEXT(js {
pm_runtime_put_sync_autosuspend(pfdev->dev);
-- 
2.17.1

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

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

[Al Viro]

On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny 
> > 
> > The kunmap_atomic clean up failed to remove one set of pagefault/preempt
> > enables when vaddr is not in the fixmap.
> > 
> > Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate code")
> > Signed-off-by: Ira Weiny 
> 
> microblazeel works with this patch, as do the nosmp sparc32 boot tests,
> but sparc32 boot tests with SMP enabled still fail with lots of messages
> such as:

BTW, what's your setup for sparc32 boot tests?  IOW, how do you manage to
shrink the damn thing enough to have the loader cope with it?  I hadn't
been able to do that for the current mainline ;-/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau/debugfs: fix runtime pm imbalance on error

[Dinghao Liu]

pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.

Signed-off-by: Dinghao Liu 
---
 drivers/gpu/drm/nouveau/nouveau_debugfs.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c 
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 15a3d40edf02..db3711436577 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -181,8 +181,11 @@ nouveau_debugfs_pstate_set(struct file *file, const char 
__user *ubuf,
}
 
ret = pm_runtime_get_sync(drm->dev);
-   if (ret < 0 && ret != -EACCES)
+   if (ret < 0 && ret != -EACCES) {
+   pm_runtime_put_autosuspend(drm->dev);
return ret;
+   }
+
ret = nvif_mthd(ctrl, NVIF_CONTROL_PSTATE_USER, , sizeof(args));
pm_runtime_put_autosuspend(drm->dev);
if (ret < 0)
-- 
2.17.1

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

[PATCH v2 1/1] drm: check for NULL pointer in drm_gem_object_put

[Nirmoy Das]

drm_gem_fb_destroy() calls drm_gem_object_put() with NULL obj causing:

[   11.584209] BUG: kernel NULL pointer dereference, address: 
[   11.584213] #PF: supervisor write access in kernel mode
[   11.584215] #PF: error_code(0x0002) - not-present page
[   11.584216] PGD 0 P4D 0
[   11.584220] Oops: 0002 [#1] SMP NOPTI
[   11.584223] CPU: 7 PID: 1571 Comm: gnome-shell Tainted: GE 
5.7.0-rc1-1-default+ #27
[   11.584225] Hardware name: Micro-Star International Co., Ltd. MS-7A31/X370 
XPOWER GAMING TITANIUM (MS-7A31), BIOS 1.MR 12/03/2019
[   11.584237] RIP: 0010:drm_gem_fb_destroy+0x28/0x70 [drm_kms_helper]

[   11.584256] Call Trace:
[   11.584279]  drm_mode_rmfb+0x189/0x1c0 [drm]
[   11.584299]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
[   11.584314]  drm_ioctl_kernel+0xaa/0xf0 [drm]
[   11.584329]  drm_ioctl+0x1ff/0x3b0 [drm]
[   11.584347]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
[   11.584421]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[   11.584427]  ksys_ioctl+0x87/0xc0
[   11.584430]  __x64_sys_ioctl+0x16/0x20
[   11.584434]  do_syscall_64+0x5f/0x240
[   11.584438]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   11.584440] RIP: 0033:0x7f0ef80f7227

Fixes: b5d250744cccfb400 ("drm/gem: fold drm_gem_object_put_unlocked and 
__drm_gem_object_put()")

Signed-off-by: Nirmoy Das 
---
 include/drm/drm_gem.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 52173abdf500..a13510346a9b 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -372,6 +372,9 @@ static inline void drm_gem_object_get(struct drm_gem_object 
*obj)
 static inline void
 drm_gem_object_put(struct drm_gem_object *obj)
 {
+   if (!obj)
+   return;
+
kref_put(>refcount, drm_gem_object_free);
 }
 
-- 
2.26.2

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

Re: [RFC PATCH 0/4] DirectX on Linux

[Jan Engelhardt]

On Tuesday 2020-05-19 22:36, Sasha Levin wrote:
>
>> - Why DX12 on linux? Looking at this feels like classic divide and
>
> There is a single usecase for this: WSL2 developer who wants to run
> machine learning on his GPU. The developer is working on his laptop,
> which is running Windows and that laptop has a single GPU that Windows
> is using.

It does not feel right conceptually. If the target is a Windows API
(DX12/ML), why bother with Linux environments? Make it a Windows executable,
thereby skipping the WSL translation layer and passthrough.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe

[Shengjiu Wang]

On Wed, May 20, 2020 at 8:38 PM Mark Brown  wrote:
>
> On Wed, May 20, 2020 at 07:22:19PM +0800, Shengjiu Wang wrote:
>
> > I see some driver also request dma channel in open() or hw_params().
> > how can they avoid the defer probe issue?
> > for example：
> > sound/arm/pxa2xx-pcm-lib.c
> > sound/soc/sprd/sprd-pcm-dma.c
>
> Other drivers having problems means those drivers should be fixed, not
> that we should copy the problems.  In the case of the PXA driver that's
> very old code which predates deferred probe by I'd guess a decade.

Thanks.

For the FE-BE case, do you have any suggestion for how fix it?

With DMA1->ASRC->DMA2->ESAI case, the DMA1->ASRC->DMA2
is in FE,  ESAI is in BE.  When ESAI drvier probe,  DMA3 channel is
created with ESAI's "dma:tx" (DMA3 channel
is not used in this FE-BE case).When FE-BE startup, DMA2
channel is created, it needs the ESAI's "dma:tx", so the warning
comes out.

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

Re: [RFC PATCH 0/8] Qualcomm Cloud AI 100 driver

[Jeffrey Hugo]

On 5/20/2020 9:59 AM, Greg Kroah-Hartman wrote:

On Wed, May 20, 2020 at 08:48:13AM -0600, Jeffrey Hugo wrote:

On 5/20/2020 2:34 AM, Daniel Vetter wrote:

On Wed, May 20, 2020 at 7:15 AM Greg Kroah-Hartman
 wrote:


On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:

On Tue, May 19, 2020 at 07:41:20PM +0200, Greg Kroah-Hartman wrote:

On Tue, May 19, 2020 at 08:57:38AM -0600, Jeffrey Hugo wrote:

On 5/18/2020 11:08 PM, Dave Airlie wrote:

On Fri, 15 May 2020 at 00:12, Jeffrey Hugo  wrote:


Introduction:
Qualcomm Cloud AI 100 is a PCIe adapter card which contains a dedicated
SoC ASIC for the purpose of efficently running Deep Learning inference
workloads in a data center environment.

The offical press release can be found at -
https://www.qualcomm.com/news/releases/2019/04/09/qualcomm-brings-power-efficient-artificial-intelligence-inference

The offical product website is -
https://www.qualcomm.com/products/datacenter-artificial-intelligence

At the time of the offical press release, numerious technology news sites
also covered the product.  Doing a search of your favorite site is likely
to find their coverage of it.

It is our goal to have the kernel driver for the product fully upstream.
The purpose of this RFC is to start that process.  We are still doing
development (see below), and thus not quite looking to gain acceptance quite
yet, but now that we have a working driver we beleive we are at the stage
where meaningful conversation with the community can occur.



Hi Jeffery,

Just wondering what the userspace/testing plans for this driver.

This introduces a new user facing API for a device without pointers to
users or tests for that API.


We have daily internal testing, although I don't expect you to take my word
for that.

I would like to get one of these devices into the hands of Linaro, so that
it can be put into KernelCI.  Similar to other Qualcomm products. I'm trying
to convince the powers that be to make this happen.

Regarding what the community could do on its own, everything but the Linux
driver is considered proprietary - that includes the on device firmware and
the entire userspace stack.  This is a decision above my pay grade.


Ok, that's a decision you are going to have to push upward on, as we
really can't take this without a working, open, userspace.


Uh wut.

So the merge criteria for drivers/accel (atm still drivers/misc but I
thought that was interim until more drivers showed up) isn't actually
"totally-not-a-gpu accel driver without open source userspace".

Instead it's "totally-not-a-gpu accel driver without open source
userspace" _and_ you have to be best buddies with Greg. Or at least
not be on the naughty company list. Since for habanalabs all you
wanted is a few test cases to exercise the ioctls. Not the entire
userspace.


Also, to be fair, I have changed my mind after seeing the mess of
complexity that these "ioctls for everyone!" type of pass-through
these kinds of drivers are creating.  You were right, we need open
userspace code in order to be able to properly evaluate and figure out
what they are doing is right or not and be able to maintain things over
time correctly.

So I was wrong, and you were right, my apologies for my previous
stubbornness.


Awesome and don't worry, I'm pretty sure we've all been stubborn
occasionally :-)

  From a drivers/gpu pov I think still not quite there since we also
want to see the compiler for these programmable accelerator thingies.
But just having a fairly good consensus that "userspace library with
all the runtime stuff excluding compiler must be open" is a huge step
forward. Next step may be that we (kernel overall, drivers/gpu will
still ask for the full thing) have ISA docs for these programmable
things, so that we can also evaluate that aspect and gauge how many
security issues there might be. Plus have a fighting chance to fix up
the security leaks when (post smeltdown I don't really want to
consider this an if) someone finds a hole in the hw security wall. At
least in drivers/gpu we historically have a ton of drivers with
command checkers to validate what userspace wants to run on the
accelerator thingie. Both in cases where the hw was accidentally too
strict, and not strict enough.


I think this provides a pretty clear guidance on what you/the community are
looking for, both now and possibly in the future.

Thank you.

 From my perspective, it would be really nice if there was something like
Mesa that was a/the standard for these sorts of accelerators.  Its somewhat
the wild west, and we've struggled with it.


Put a first cut at such a thing out there and see how it goes!  Nothing
is preventing you from starting such a project, and it would be most
welcome as you have seen.


I wish.  I'll float the idea, but don't hold your breath.

--
Jeffrey Hugo
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
___

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

[Guenter Roeck]

On 5/21/20 10:42 AM, Ira Weiny wrote:
> On Thu, May 21, 2020 at 09:05:41AM -0700, Guenter Roeck wrote:
>> On 5/19/20 10:13 PM, Ira Weiny wrote:
>>> On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote:
 On Tue, May 19, 2020 at 11:40:32AM -0700, Ira Weiny wrote:
> On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
>> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.we...@intel.com wrote:
>>> From: Ira Weiny 
>>>
>>> The kunmap_atomic clean up failed to remove one set of pagefault/preempt
>>> enables when vaddr is not in the fixmap.
>>>
>>> Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate code")
>>> Signed-off-by: Ira Weiny 
>>
>> microblazeel works with this patch,
>
> Awesome...  Andrew in my rush yesterday I should have put a reported by 
> on the
> patch for Guenter as well.
>
> Sorry about that Guenter,

 No worries.

> Ira
>
>> as do the nosmp sparc32 boot tests,
>> but sparc32 boot tests with SMP enabled still fail with lots of messages
>> such as:
>>
>> BUG: Bad page state in process swapper/0  pfn:006a1
>> page:f0933420 refcount:0 mapcount:1 mapping:(ptrval) index:0x1
>> flags: 0x0()
>> raw:  0100 0122  0001   
>> 
>> page dumped because: nonzero mapcount
>> Modules linked in:
>> CPU: 0 PID: 1 Comm: swapper/0 Tainted: GB 
>> 5.7.0-rc6-next-20200518-2-gb178d2d56f29 #1
>> [f00e7ab8 :
>> bad_page+0xa8/0x108 ]
>> [f00e8b54 :
>> free_pcppages_bulk+0x154/0x52c ]
>> [f00ea024 :
>> free_unref_page+0x54/0x6c ]
>> [f00ed864 :
>> free_reserved_area+0x58/0xec ]
>> [f0527104 :
>> kernel_init+0x14/0x110 ]
>> [f000b77c :
>> ret_from_kernel_thread+0xc/0x38 ]
>> [ :
>> 0x0 ]
>>
>> Code path leading to that message is different but always the same
>> from free_unref_page().
>>>
>>> Actually it occurs to me that the patch consolidating kmap_prot is odd for
>>> sparc 32 bit...
>>>
>>> Its a long shot but could you try reverting this patch?
>>>
>>> 4ea7d2419e3f kmap: consolidate kmap_prot definitions
>>>
>>
>> That is not easy to revert, unfortunately, due to several follow-up patches.
> 
> I have gotten your sparc tests to run and they all pass...
> 
> 08:10:34 > ../linux-build-test/rootfs/sparc/run-qemu-sparc.sh 
> Build reference: v5.7-rc4-17-g852b6f2edc0f
> 

That doesn't look like it is linux-next, which I guess means that something
else in linux-next breaks it. What is your qemu version ?

Thanks,
Guenter

> Building sparc32:SPARCClassic:nosmp:scsi:hd ... running . passed
> Building sparc32:SPARCbook:nosmp:scsi:cd ... running . passed
> Building sparc32:LX:nosmp:noapc:scsi:hd ... running . passed
> Building sparc32:SS-4:nosmp:initrd ... running . passed
> Building sparc32:SS-5:nosmp:scsi:hd ... running . passed
> Building sparc32:SS-10:nosmp:scsi:cd ... running . passed
> Building sparc32:SS-20:nosmp:scsi:hd ... running . passed
> Building sparc32:SS-600MP:nosmp:scsi:hd ... running . passed
> Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running . passed
> Building sparc32:SS-4:smp:scsi:hd ... running . passed
> Building sparc32:SS-5:smp:scsi:cd ... running . passed
> Building sparc32:SS-10:smp:scsi:hd ... running . passed
> Building sparc32:SS-20:smp:scsi:hd ... running . passed
> Building sparc32:SS-600MP:smp:scsi:hd ... running . passed
> Building sparc32:Voyager:smp:noapc:scsi:hd ... running . passed
> 
> Is there another test I need to run?
> 
> Ira
> 
> 
>>
>> Guenter
>>
>>> Alternately I will need to figure out how to run the sparc on qemu here...
>>>
>>> Thanks very much for all the testing though!  :-D
>>>
>>> Ira
>>>
>>
>> Still testing ppc images.
>>

 ppc image tests are passing with this patch.

 Guenter
>>

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

[PATCH] drm/nouveau: fix runtime pm imbalance on error

[Dinghao Liu]

pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.

Signed-off-by: Dinghao Liu 
---
 drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index f5ece1f94973..6697f960dd89 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -76,8 +76,10 @@ nouveau_gem_object_open(struct drm_gem_object *gem, struct 
drm_file *file_priv)
return ret;
 
ret = pm_runtime_get_sync(dev);
-   if (ret < 0 && ret != -EACCES)
+   if (ret < 0 && ret != -EACCES) {
+   pm_runtime_put_autosuspend(dev);
goto out;
+   }
 
ret = nouveau_vma_new(nvbo, vmm, );
pm_runtime_mark_last_busy(dev);
-- 
2.17.1

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

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

[Guenter Roeck]

On 5/21/20 5:46 PM, Al Viro wrote:
> On Thu, May 21, 2020 at 11:46:12PM +0100, Al Viro wrote:
>> On Thu, May 21, 2020 at 03:20:46PM -0700, Guenter Roeck wrote:
>>> On 5/21/20 10:27 AM, Al Viro wrote:
 On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.we...@intel.com wrote:
>> From: Ira Weiny 
>>
>> The kunmap_atomic clean up failed to remove one set of pagefault/preempt
>> enables when vaddr is not in the fixmap.
>>
>> Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate code")
>> Signed-off-by: Ira Weiny 
>
> microblazeel works with this patch, as do the nosmp sparc32 boot tests,
> but sparc32 boot tests with SMP enabled still fail with lots of messages
> such as:

 BTW, what's your setup for sparc32 boot tests?  IOW, how do you manage to
 shrink the damn thing enough to have the loader cope with it?  I hadn't
 been able to do that for the current mainline ;-/

>>>
>>> defconfig seems to work just fine, even after enabling various debug
>>> and file system options.
>>
>> The hell?  How do you manage to get the kernel in?  sparc32_defconfig
>> ends up with 5316876 bytes unpacked...
> 
> Incidentally, trying to load it via -kernel/-initrd leads to
> Configuration device id QEMU version 1 machine id 64
> Probing SBus slot 0 offset 0
> Probing SBus slot 1 offset 0
> Probing SBus slot 2 offset 0
> Probing SBus slot 3 offset 0
> Probing SBus slot 15 offset 0
> Invalid FCode start byte
> CPUs: 1 x TI,TMS390Z55
> UUID: ----
> Welcome to OpenBIOS v1.1 built on Dec 27 2018 19:17
>   Type 'help' for detailed information
> [sparc] Kernel already loaded
> switching to new context:
> PROMLIB: obio_ranges 1
> PROMLIB: Sun Boot Prom Version 3 Revision 2
> Linux version 5.7.0-rc1-2-gcf51e129b968 (al@duke) (gcc version 6.3.0 
> 20170516 (Debian 6.3.0-18), GNU ld (GNU Binutils for Debian) 2.28) #32 Thu 
> May 21 18:36:07 EDT 2020
> printk: bootconsole [earlyprom0] enabled
> ARCH: SUN4M
> TYPE: Sun4m SparcStation10/20
> Ethernet address: 52:54:00:12:34:56
> 303MB HIGHMEM available.
> OF stdout device is: /obio/zs@0,10:a
> PROM: Built device tree with 30051 bytes of memory.
> Booting Linux...
> Power off control detected.
> Kernel panic - not syncing: Failed to allocate memory for percpu areas.
> CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0-rc1-2-gcf51e129b968 #32
> [f04f92a8 : 
> setup_per_cpu_areas+0x58/0x90 ] 
> [f04edbf4 : 
> start_kernel+0xc0/0x4a0 ] 
> [f04ed43c : 
> continue_boot+0x324/0x334 ] 
> [ : 
> 0x0 ] 
> 
> Press Stop-A (L1-A) from sun keyboard or send break
> twice on console to return to the boot prom
> ---[ end Kernel panic - not syncing: Failed to allocate memory for percpu 
> areas. ]---
> 
> Giving guest more RAM doesn't change the outcome (well, the number HIGHMEM 
> line is
> obviously higher, but that's it).
> 
> So which sparc32 kernel have you booted with defconfig and how have you done
> that?
> 

Mainline, with:

qemu-system-sparc -M SS-4 -kernel arch/sparc/boot/zImage -no-reboot \
-snapshot -drive file=rootfs.ext2,format=raw,if=scsi \
-append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0"
-nographic -monitor none

The machine doesn't really matter, though. The root file system is built
with buildroot.

Note that I carry two reverts in my qemu images.

Revert "tcx: switch to load_image_mr() and remove prom_addr hack"
Revert "cg3: switch to load_image_mr() and remove prom-addr hack"

I have been carrying those since ~2017. I didn't check recently
if they are still needed.

If sparc32 is no longer supported in the upstream kernel,
would it possibly make sense remove its support ?

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

Re: [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM

[Rui Salvaterra]

Hi, Christian,

On Wed, 20 May 2020 at 16:00, Christian König
 wrote:
>
> So I've used an ancient system (32bit) to setup a test box for this.
>
>
> The first GPU I could test is an RV280 (Radeon 9200 PRO) which is easily
> 15 years old.

Oh, I have one of those in box somewhere, but no AGP machine to
install it (yet).

> What happens in AGP mode is that glxgears shows artifacts during
> rendering on this system.
>
> In PCI mode those rendering artifacts are gone and glxgears seems to
> draw everything correctly now.
>
> Performance is obviously not comparable, cause in AGP we don't render
> all triangles correctly.

I agree, correctness before performance, always.

> The second GPU I could test is an RV630 PRO (Radeon HD 2600 PRO AGP)
> which is more than 10 years old.
>
> As far as I can tell this one works in both AGP and PCIe mode perfectly
> fine.
>
> Since this is only a 32bit system I couldn't really test any OpenGL game
> that well.

I usually test with my distro's (Debian or Ubuntu, in my case) games.
For example, I used Nexuiz when wiring up the shader cache on r300g.

> But for glxgears switching from AGP to PCIe mode seems to result in a
> roughly 5% performance drop.
>
> The surprising reason for this is not the better TLB performance, but
> the lack of USWC support for the PCIe GART in radeon.
>
> So if anybody wants to get his hands dirty and squeeze a bit more
> performance out of the old hardware, porting USWC from amdgpu to radeon
> shouldn't be to much of a problem.

Well, FWIW, I would argue that a regression in performance, if
avoidable, should be avoided. I have not nearly enough knowledge of
the driver to do it myself, but I'll glady test any patches, on both
x86-64 (Radeon Xpress 1250) and ppc32 (Mobility Radeon 9550).

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

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

[Al Viro]

On Thu, May 21, 2020 at 11:46:12PM +0100, Al Viro wrote:
> On Thu, May 21, 2020 at 03:20:46PM -0700, Guenter Roeck wrote:
> > On 5/21/20 10:27 AM, Al Viro wrote:
> > > On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> > >> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.we...@intel.com wrote:
> > >>> From: Ira Weiny 
> > >>>
> > >>> The kunmap_atomic clean up failed to remove one set of pagefault/preempt
> > >>> enables when vaddr is not in the fixmap.
> > >>>
> > >>> Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate code")
> > >>> Signed-off-by: Ira Weiny 
> > >>
> > >> microblazeel works with this patch, as do the nosmp sparc32 boot tests,
> > >> but sparc32 boot tests with SMP enabled still fail with lots of messages
> > >> such as:
> > > 
> > > BTW, what's your setup for sparc32 boot tests?  IOW, how do you manage to
> > > shrink the damn thing enough to have the loader cope with it?  I hadn't
> > > been able to do that for the current mainline ;-/
> > > 
> > 
> > defconfig seems to work just fine, even after enabling various debug
> > and file system options.
> 
> The hell?  How do you manage to get the kernel in?  sparc32_defconfig
> ends up with 5316876 bytes unpacked...

Incidentally, trying to load it via -kernel/-initrd leads to
Configuration device id QEMU version 1 machine id 64
Probing SBus slot 0 offset 0
Probing SBus slot 1 offset 0
Probing SBus slot 2 offset 0
Probing SBus slot 3 offset 0
Probing SBus slot 15 offset 0
Invalid FCode start byte
CPUs: 1 x TI,TMS390Z55
UUID: ----
Welcome to OpenBIOS v1.1 built on Dec 27 2018 19:17
  Type 'help' for detailed information
[sparc] Kernel already loaded
switching to new context:
PROMLIB: obio_ranges 1
PROMLIB: Sun Boot Prom Version 3 Revision 2
Linux version 5.7.0-rc1-2-gcf51e129b968 (al@duke) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18), GNU ld (GNU Binutils for Debian) 2.28) #32 Thu May 
21 18:36:07 EDT 2020
printk: bootconsole [earlyprom0] enabled
ARCH: SUN4M
TYPE: Sun4m SparcStation10/20
Ethernet address: 52:54:00:12:34:56
303MB HIGHMEM available.
OF stdout device is: /obio/zs@0,10:a
PROM: Built device tree with 30051 bytes of memory.
Booting Linux...
Power off control detected.
Kernel panic - not syncing: Failed to allocate memory for percpu areas.
CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0-rc1-2-gcf51e129b968 #32
[f04f92a8 : 
setup_per_cpu_areas+0x58/0x90 ] 
[f04edbf4 : 
start_kernel+0xc0/0x4a0 ] 
[f04ed43c : 
continue_boot+0x324/0x334 ] 
[ : 
0x0 ] 

Press Stop-A (L1-A) from sun keyboard or send break
twice on console to return to the boot prom
---[ end Kernel panic - not syncing: Failed to allocate memory for percpu 
areas. ]---

Giving guest more RAM doesn't change the outcome (well, the number HIGHMEM line 
is
obviously higher, but that's it).

So which sparc32 kernel have you booted with defconfig and how have you done
that?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

[Al Viro]

On Fri, May 22, 2020 at 02:29:50AM +0100, Al Viro wrote:
> On Thu, May 21, 2020 at 06:11:08PM -0700, Guenter Roeck wrote:
> 
> > Mainline, with:
> > 
> > qemu-system-sparc -M SS-4 -kernel arch/sparc/boot/zImage -no-reboot \
> > -snapshot -drive file=rootfs.ext2,format=raw,if=scsi \
> > -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0"
> > -nographic -monitor none
> > 
> > The machine doesn't really matter, though.
> 
> It does, unfortunately - try that with SS-10 and watch what happens ;-/

Ugh...  It's actually something in -m handling: -m 256 passes, -m 512
leads to that panic.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] add generic DT binding for RTS/CTS

[Erwan Le Ray]

Add support of generic DT binding for annoucing RTS/CTS lines. The initial
binding 'st,hw-flow-control' is not needed anymore since generic binding
is available, but is kept for backward compatibility.

Erwan Le Ray (2):
  dt-bindings: serial: add generic DT binding for announcing RTS/CTS
lines
  serial: stm32: Use generic DT binding for announcing RTS/CTS lines

 Documentation/devicetree/bindings/serial/st,stm32-uart.yaml | 4 +++-
 drivers/tty/serial/stm32-usart.c| 5 +++--
 2 files changed, 6 insertions(+), 3 deletions(-)

-- 
2.17.1

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

Re: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe

[Shengjiu Wang]

Hi

On Tue, May 19, 2020 at 6:04 PM Lucas Stach  wrote:
>
> Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu Wang:
> > There are two requirements that we need to move the request
> > of dma channel from probe to open.
>
> How do you handle -EPROBE_DEFER return code from the channel request if
> you don't do it in probe?

I use the dma_request_slave_channel or dma_request_channel instead
of dmaengine_pcm_request_chan_of. so there should be not -EPROBE_DEFER
return code.

>
> > - When dma device binds with power-domains, the power will
> > be enabled when we request dma channel. If the request of dma
> > channel happen on probe, then the power-domains will be always
> > enabled after kernel boot up,  which is not good for power
> > saving,  so we need to move the request of dma channel to .open();
>
> This is certainly something which could be fixed in the dmaengine
> driver.

Dma driver always call the pm_runtime_get_sync in
device_alloc_chan_resources, the device_alloc_chan_resources is
called when channel is requested. so power is enabled on channel
request.

>
> > - With FE-BE case, if the dma channel is requested in probe,
> > then there will be below issue, which is caused by that the
> > dma channel will be requested duplicately
>
> Why is this requested a second time? Is this just some missing cleanup
> on a deferred probe path?

Not relate with deferred probe.  With DMA1->ASRC->DMA2->ESAI case,
the DMA1->ASRC->DMA2 is in FE,  ESAI is in BE.  When ESAI drvier
probe,  DMA3 channel is created with ESAI's "dma:tx" (DMA3 channel
is not used in this FE-BE case).When FE-BE startup, DMA2
channel is created, it needs the ESAI's "dma:tx", so below warning
comes out.

>
> Regards,
> Lucas
>
> > [  638.906268] sysfs: cannot create duplicate filename 
> > '/devices/soc0/soc/200.bus/200.spba-bus/2024000.esai/dma:tx'
> > [  638.919061] CPU: 1 PID: 673 Comm: aplay Not tainted 
> > 5.7.0-rc1-12956-gfc64b2585593 #287
> > [  638.927113] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> > [  638.933690] [] (unwind_backtrace) from [] 
> > (show_stack+0x10/0x14)
> > [  638.941464] [] (show_stack) from [] 
> > (dump_stack+0xe4/0x118)
> > [  638.948808] [] (dump_stack) from [] 
> > (sysfs_warn_dup+0x50/0x64)
> > [  638.956406] [] (sysfs_warn_dup) from [] 
> > (sysfs_do_create_link_sd+0xc8/0xd4)
> > [  638.965134] [] (sysfs_do_create_link_sd) from [] 
> > (dma_request_chan+0xb0/0x210)
> > [  638.974120] [] (dma_request_chan) from [] 
> > (dma_request_slave_channel+0x8/0x14)
> > [  638.983111] [] (dma_request_slave_channel) from [] 
> > (fsl_asrc_dma_hw_params+0x1e0/0x438)
> > [  638.992881] [] (fsl_asrc_dma_hw_params) from [] 
> > (soc_pcm_hw_params+0x4a0/0x6a8)
> > [  639.001952] [] (soc_pcm_hw_params) from [] 
> > (dpcm_fe_dai_hw_params+0x70/0xe4)
> > [  639.010765] [] (dpcm_fe_dai_hw_params) from [] 
> > (snd_pcm_hw_params+0x158/0x418)
> > [  639.019750] [] (snd_pcm_hw_params) from [] 
> > (snd_pcm_ioctl+0x734/0x183c)
> > [  639.028129] [] (snd_pcm_ioctl) from [] 
> > (ksys_ioctl+0x2ac/0xb98)
> > [  639.035812] [] (ksys_ioctl) from [] 
> > (ret_fast_syscall+0x0/0x28)
> > [  639.043490] Exception stack(0xec529fa8 to 0xec529ff0)
> > [  639.048565] 9fa0:   bee84650 01321870 0004 c25c4111 
> > bee84650 0002000f
> > [  639.056766] 9fc0: bee84650 01321870 01321820 0036 1f40  
> > 0002c2f8 0003
> > [  639.064964] 9fe0: b6f483fc bee8451c b6ee2655 b6e1dcf8
> > [  639.070339] fsl-esai-dai 2024000.esai: Cannot create DMA dma:tx symlink
> >
> > Signed-off-by: Shengjiu Wang 
> > ---
> >  sound/soc/fsl/imx-pcm-dma.c | 173 +---
> >  1 file changed, 159 insertions(+), 14 deletions(-)
> >
> > diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c
> > index 04a9bc749016..dae53b384df4 100644
> > --- a/sound/soc/fsl/imx-pcm-dma.c
> > +++ b/sound/soc/fsl/imx-pcm-dma.c
> > @@ -11,6 +11,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include 
> >  #include 
> > @@ -29,24 +30,168 @@ static bool filter(struct dma_chan *chan, void *param)
> >   return true;
> >  }
> >
> > -static const struct snd_dmaengine_pcm_config imx_dmaengine_pcm_config = {
> > - .prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config,
> > - .compat_filter_fn = filter,
> > -};
> > +static int imx_pcm_hw_params(struct snd_soc_component *component,
> > +  struct snd_pcm_substream *substream,
> > +  struct snd_pcm_hw_params *params)
> > +{
> > + struct snd_pcm_runtime *runtime = substream->runtime;
> > + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> > + struct snd_soc_dai *cpu_dai = asoc_rtd_to_cpu(rtd, 0);
> > + struct snd_dmaengine_dai_dma_data *dma_data;
> > + struct dma_slave_config config;
> > + struct dma_chan *chan;
> > + int ret = 0;
> >
> > -int imx_pcm_dma_init(struct platform_device *pdev, size_t size)
> > +