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

[Sam Ravnborg]

Hi Lyude.

> > > *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(&vblank->count), diff,
> > > +   pipe, (unsigned long long)atomic64_read(&vblank->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

I wnet ahead and applied this patch (after fixing a too long line),
and then I updated the logging functions as suggested above.
I applied the patch to drm-misc-next.

Patches with updated logging coming.

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

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&action=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&action=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&action=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&rev=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(&pdev->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(&platform_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(&pdev->dev, "failed to attach iommu: 
%d\n",
-   ret);
-   goto fail;
-   }
} else {
DRM_DEV_INFO(&pdev->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(&aspace->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(&aspace->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(&aspace->mm, start >> PAGE_SHIFT, size >> PAGE_SHIFT);
 
kref_init(&aspace->kref);
 
@@ -166,6 +175,12 @@ msm_gem_address_space_create_a2xx(struct device *dev, 
struct msm_gpu *gpu,
spin_lock_init(&aspace->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)

[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 = &drm_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   = &rcar_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 &drm_driver.gem_prime_import_sg_table
> > - * callback. The DRM_GEM_CMA_VMAP_DRIVER_OPS() macro provides a shortcut 
> > to set
> > + * callback. The &DRM_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   = &tidss_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   = &hx8357d_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 = &drm_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 = &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 = &drm_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 = &zx_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(&vblank->count), diff,
> > + pipe, (unsigned long long)atomic64_read(&vblank->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 = &ade_fops,
> -   .gem_free_object_unlocked = drm_gem_cma_free_object,
> -   .gem_vm_ops = &drm_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 = &drm_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 = &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 = &si_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 = &si_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 &drm_driver.gem_prime_import_sg_table
> - * callback. The DRM_GEM_CMA_VMAP_DRIVER_OPS() macro provides a shortcut to 
> set
> + * callback. The &DRM_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   = &tidss_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   = &hx8357d_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  

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 = &si_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 = &si_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, &job->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(&pfdev->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(&mem->bo);
+   drm_gem_object_put_unlocked(&mem->bo->tbo.base);
mutex_destroy(&mem->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(&bo->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(&adev->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(&adev->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(&adev->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 = &hdcp_work[link_index].display;
struct mod_hdcp_link *link = &hdcp_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(&mem->bo);
+   drm_gem_object_put_unlocked(&mem->bo->tbo.base);
mutex_destroy(&mem->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(&bo->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(&adev->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(&adev->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(&adev->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 = &drm_gem_cma_vm_ops,
-   .dumb_create = drm_gem_cma_dumb_create,
+   DRM_GEM_CMA_DRIVER_OPS,
.fops = &sti_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 = &drm_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   = &shmob_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 = &drm_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 = &drm_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 = &ade_fops,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = &drm_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 &drm_driver.gem_prime_import_sg_table
- * callback. The DRM_GEM_CMA_VMAP_DRIVER_OPS() macro provides a shortcut to set
+ * callback. The &DRM_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   = &tidss_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   = &hx8357d_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   = &ili9225_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   = &ili9341_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_

[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 = &drm_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 = &zx_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   = &ingenic_drm_fops,
-
-   .dumb_create= drm_gem_cma_dumb_create,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = &drm_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 = &drm_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   = &rcar_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 = &drm_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 = &drm_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 = &drm_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   = &imx_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 = &drm_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   = &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 = &arcpgu_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 = &drm_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 = &drm_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 = &drv_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 = &drm_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 = &drm_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   = &fsl_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 = &drm_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 = &komeda_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 = &drm_gem_cma_vm_ops,
+   /* CMA Ops */
+   __DRM_GEM_CMA_DRIVER_OPS(meson_dumb_create),
 
/* Misc */
.fops   = &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 = &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 = &drm_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 = &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, &job->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(&pfdev->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 &xen_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&action=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 these

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 = &dsi->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.html&data=02%7C01%7Cchristian.koenig%40amd.com%7C7dd54e944eff4d17178008d7fdee62d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637257072615411745&sdata=fQHnbXZpsgiMjHOr%2By0Uq12jpCYEYbdX5K26iNkwyeM%3D&reserved=0
[2] 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKSPP%2Flinux%2Fissues%2F21&data=02%7C01%7Cchristian.koenig%40amd.com%7C7dd54e944eff4d17178008d7fdee62d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637257072615411745&sdata=gg20YupmqsaW%2Bg3VyJL%2BkjE3kFwnWF1RD1D2QP04OLk%3D&reserved=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