[PATCH] drm: gem: add an option for supporting the dma-coherent hardware.
The single map_noncoherent member of struct drm_gem_dma_object may not
sufficient for describing the backing memory of the GEM buffer object.
Especially on dma-coherent systems, the backing memory is both cached
coherent for multi-core CPUs and dma-coherent for peripheral device.
Say architectures like X86-64, LoongArch64, Loongson Mips64, etc.
Whether a peripheral device is dma-coherent or not can be
implementation-dependent. The single map_noncoherent option is not enough
to reflect real hardware anymore. For example, the Loongson LS3A4000 CPU
and LS2K2000/LS2K1000 SoC, peripheral device of such hardware platform
allways snoop CPU's cache. Doing the allocation with dma_alloc_coherent
function is preferred. The return buffer is cached, it should not using
the default write-combine mapping. While with the current implement, there
no way to tell the drm core to reflect this.
This patch adds cached and coherent members to struct drm_gem_dma_object.
which allow driver implements to inform the core. Introducing new mappings
while keeping the original default behavior unchanged.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/drm_fb_dma_helper.c | 11 +--
drivers/gpu/drm/drm_fbdev_dma.c | 2 +-
drivers/gpu/drm/drm_gem_dma_helper.c | 20
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 5 -
drivers/gpu/drm/rcar-du/Kconfig | 2 --
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 4 +++-
include/drm/drm_gem_dma_helper.h | 7 +--
7 files changed, 34 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_dma_helper.c
b/drivers/gpu/drm/drm_fb_dma_helper.c
index 3b535ad1b07c..93ff05041192 100644
--- a/drivers/gpu/drm/drm_fb_dma_helper.c
+++ b/drivers/gpu/drm/drm_fb_dma_helper.c
@@ -106,16 +106,15 @@ dma_addr_t drm_fb_dma_get_gem_addr(struct drm_framebuffer
*fb,
EXPORT_SYMBOL_GPL(drm_fb_dma_get_gem_addr);
/**
- * drm_fb_dma_sync_non_coherent - Sync GEM object to non-coherent backing
- * memory
+ * drm_fb_dma_sync_non_coherent - Sync GEM object to cached backing memory
* @drm: DRM device
* @old_state: Old plane state
* @state: New plane state
*
* This function can be used by drivers that use damage clips and have
- * DMA GEM objects backed by non-coherent memory. Calling this function
- * in a plane's .atomic_update ensures that all the data in the backing
- * memory have been written to RAM.
+ * DMA GEM objects backed by cached memory. Calling this function in a
+ * plane's .atomic_update ensures that all the data in the backing memory
+ * have been written to RAM.
*/
void drm_fb_dma_sync_non_coherent(struct drm_device *drm,
struct drm_plane_state *old_state,
@@ -131,7 +130,7 @@ void drm_fb_dma_sync_non_coherent(struct drm_device *drm,
for (i = 0; i < finfo->num_planes; i++) {
dma_obj = drm_fb_dma_get_gem_obj(state->fb, i);
- if (!dma_obj->map_noncoherent)
+ if (dma_obj->cached && dma_obj->coherent)
continue;
daddr = drm_fb_dma_get_gem_addr(state->fb, state, i);
diff --git a/drivers/gpu/drm/drm_fbdev_dma.c b/drivers/gpu/drm/drm_fbdev_dma.c
index d86773fa8ab0..49fe9b284cc8 100644
--- a/drivers/gpu/drm/drm_fbdev_dma.c
+++ b/drivers/gpu/drm/drm_fbdev_dma.c
@@ -131,7 +131,7 @@ static int drm_fbdev_dma_helper_fb_probe(struct
drm_fb_helper *fb_helper,
/* screen */
info->flags |= FBINFO_VIRTFB; /* system memory */
- if (dma_obj->map_noncoherent)
+ if (dma_obj->cached)
info->flags |= FBINFO_READS_FAST; /* signal caching */
info->screen_size = sizes->surface_height * fb->pitches[0];
info->screen_buffer = map.vaddr;
diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c
b/drivers/gpu/drm/drm_gem_dma_helper.c
index 870b90b78bc4..dec1d512bdf1 100644
--- a/drivers/gpu/drm/drm_gem_dma_helper.c
+++ b/drivers/gpu/drm/drm_gem_dma_helper.c
@@ -93,7 +93,11 @@ __drm_gem_dma_create(struct drm_device *drm, size_t size,
bool private)
drm_gem_private_object_init(drm, gem_obj, size);
/* Always use writecombine for dma-buf mappings */
- dma_obj->map_noncoherent = false;
+ /* FIXME: This is not always true, on some dma coherent system,
+* cached mappings should be preferred over writecombine
+*/
+ dma_obj->cached = false;
+ dma_obj->coherent = false;
} else {
ret = drm_gem_object_init(drm, gem_obj, size);
}
@@ -143,7 +147,11 @@ struct drm_gem_dma_object *drm_gem_dma_create(struct
drm_device *drm,
if (IS_ERR(dma_obj))
return dma_obj;
- if (dma_obj->map_noncoherent) {
+ if (dma_obj->cached && dma_obj->coherent) {
+ dma_obj->vaddr = dma_alloc_coherent(drm->dev, size,
+ _obj->dma_addr,
+
RE: [PATCH v17 1/1] drm/i915: Allow user to set cache at BO creation
> -Original Message-
> From: Andi Shyti
> Sent: Wednesday, June 7, 2023 1:11 PM
> To: Zhang, Carl
> Cc: Andi Shyti ; Joonas Lahtinen
> ; Tvrtko Ursulin
> ; Yang, Fei ; Chris
> Wilson ; Roper, Matthew D
> ; Justen, Jordan L ;
> Gu, Lihao ; Intel GFX ;
> DRI Devel
> Subject: Re: [PATCH v17 1/1] drm/i915: Allow user to set cache at BO creation
>
> Hi Carl,
>
> On Wed, Jun 07, 2023 at 03:40:20AM +, Zhang, Carl wrote:
> > Media driver reverted previous patches, and file a new PR
> > https://github.com/intel/media-driver/pull/1680
> > will hold this PR until the uapi changes appear in drm_next.
>
> That's great, thanks a lot for the quick actions here.
>
> Before pushing I am going to replace the Media part in the commit log with
> the following sentence:
>
> "
> The media driver supprt has bin submitted in this merge request:
> https://github.com/intel/media-driver/pull/1680
> "
>
> > besides this, ask a dumb question.
> > How we retrieve the pat_index from a shared resource though dma_buf fd?
> > maybe we need to know whether it could be CPU cached if we want map it.
> > Of course, looks there are no real usage to access it though CPU.
> > Just use it directly without any pat related options ?
>
> I am not understanding. Do you want to ask the PAT table to the driver? Are
> you referring to the CPU PAT index?
>
> In any case, if I understood correctly, you don't necessarily always need to
> set the PAT options and the cache options will fall into the default values.
>
> Please let me know if I haven't answered the question.
>
If mesa create a resource , then use DRM_IOCTL_PRIME_HANDLE_TO_FD convert it to
a dma fd.
Then share it to media, media use DRM_IOCTL_PRIME_FD_TO_HANDLE convert it to a
gem bo.
But media does not know the PAT index , because mesa create it and set it.
So, if media want to call DRM_IOCTL_I915_GEM_MMAP_OFFSET, media does not know
whether it could be WB.
> Andi
>
> > Thanks
> > Carl
> >
> > > -Original Message-
> > > From: Andi Shyti
> > > Sent: Tuesday, June 6, 2023 7:15 PM
> > > To: Joonas Lahtinen
> > > Cc: Andi Shyti ; Tvrtko Ursulin
> > > ; Yang, Fei ;
> > > Chris Wilson ; Roper, Matthew D
> > > ; Justen, Jordan L
> > > ; Zhang, Carl ; Gu,
> > > Lihao ; Intel GFX
> > > ; DRI Devel > > de...@lists.freedesktop.org>
> > > Subject: Re: [PATCH v17 1/1] drm/i915: Allow user to set cache at BO
> > > creation
> > >
> > > > > > > To comply with the design that buffer objects shall have
> > > > > > > immutable cache setting through out their life cycle, {set,
> > > > > > > get}_caching ioctl's are no longer supported from MTL onward.
> > > > > > > With that change caching policy can only be set at object
> > > > > > > creation time. The current code applies a default (platform
> > > > > > > dependent)
> > > cache setting for all objects.
> > > > > > > However this is not optimal for performance tuning. The
> > > > > > > patch extends the existing gem_create uAPI to let user set
> > > > > > > PAT index for the object at creation time.
> > > > > > > The new extension is platform independent, so UMD's can
> > > > > > > switch to using this extension for older platforms as well,
> > > > > > > while {set, get}_caching are still supported on these legacy
> > > > > > > paltforms for
> > > compatibility reason.
> > > > > > > However, since PAT index was not clearly defined for
> > > > > > > platforms prior to
> > > > > > > GEN12 (TGL), so we are limiting this externsion to GEN12+
> > > > > > > platforms only. See ext_set_pat() in for the implementation
> > > > > > > details.
> > > > > > >
> > > > > > > Note: The documentation related to the PAT/MOCS tables is
> > > > > > > currently available for Tiger Lake here:
> > > > > > > https://www.intel.com/content/www/us/en/docs/graphics-for-li
> > > > > > > nux/ developer-reference/1-0/tiger-lake.html
> > > > > > >
> > > > > > > BSpec: 45101
> > > > > > >
> > > > > > > Mesa support has been submitted in this merge request:
> > > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22
> > > > > > > 878
> > > > > > >
> > > > > > > The media driver is supported by the following commits:
> > > > > > > https://github.com/intel/media-
> > > driver/commit/92c00a857433ebb34ec
> > > > > > > 575e9834f473c6fcb6341
> > > > > > > https://github.com/intel/media-driver/commit/fd375cf2c5e1f6b
> > > > > > > f6b4
> > > > > > > 3258ff797b3134aadc9fd
> > > > > > > https://github.com/intel/media-
> > > driver/commit/08dd244b22484770a33
> > > > > > > 464c2c8ae85430e548000
> > > >
> > > > Andi, let's still get these corrected before merging once the
> > > > media-driver revert is completed.
> > >
> > > Sure!
> > >
> > > At least this doesn't need a new version to be respinned.
> > >
> > > Please, Carl, link the new pull request and I will update the commit log.
> > >
> > > Andi
Re: [PATCH v17 1/1] drm/i915: Allow user to set cache at BO creation
Hi Carl,
On Wed, Jun 07, 2023 at 03:40:20AM +, Zhang, Carl wrote:
> Media driver reverted previous patches, and file a new PR
> https://github.com/intel/media-driver/pull/1680
> will hold this PR until the uapi changes appear in drm_next.
That's great, thanks a lot for the quick actions here.
Before pushing I am going to replace the Media part in the commit
log with the following sentence:
"
The media driver supprt has bin submitted in this merge request:
https://github.com/intel/media-driver/pull/1680
"
> besides this, ask a dumb question.
> How we retrieve the pat_index from a shared resource though dma_buf fd?
> maybe we need to know whether it could be CPU cached if we want map it.
> Of course, looks there are no real usage to access it though CPU.
> Just use it directly without any pat related options ?
I am not understanding. Do you want to ask the PAT table to the
driver? Are you referring to the CPU PAT index?
In any case, if I understood correctly, you don't necessarily
always need to set the PAT options and the cache options will
fall into the default values.
Please let me know if I haven't answered the question.
Andi
> Thanks
> Carl
>
> > -Original Message-
> > From: Andi Shyti
> > Sent: Tuesday, June 6, 2023 7:15 PM
> > To: Joonas Lahtinen
> > Cc: Andi Shyti ; Tvrtko Ursulin
> > ; Yang, Fei ; Chris
> > Wilson ; Roper, Matthew D
> > ; Justen, Jordan L ;
> > Zhang, Carl ; Gu, Lihao ; Intel
> > GFX ; DRI Devel > de...@lists.freedesktop.org>
> > Subject: Re: [PATCH v17 1/1] drm/i915: Allow user to set cache at BO
> > creation
> >
> > > > > > To comply with the design that buffer objects shall have
> > > > > > immutable cache setting through out their life cycle, {set,
> > > > > > get}_caching ioctl's are no longer supported from MTL onward.
> > > > > > With that change caching policy can only be set at object
> > > > > > creation time. The current code applies a default (platform
> > > > > > dependent)
> > cache setting for all objects.
> > > > > > However this is not optimal for performance tuning. The patch
> > > > > > extends the existing gem_create uAPI to let user set PAT index
> > > > > > for the object at creation time.
> > > > > > The new extension is platform independent, so UMD's can switch
> > > > > > to using this extension for older platforms as well, while {set,
> > > > > > get}_caching are still supported on these legacy paltforms for
> > compatibility reason.
> > > > > > However, since PAT index was not clearly defined for platforms
> > > > > > prior to
> > > > > > GEN12 (TGL), so we are limiting this externsion to GEN12+
> > > > > > platforms only. See ext_set_pat() in for the implementation details.
> > > > > >
> > > > > > Note: The documentation related to the PAT/MOCS tables is
> > > > > > currently available for Tiger Lake here:
> > > > > > https://www.intel.com/content/www/us/en/docs/graphics-for-linux/
> > > > > > developer-reference/1-0/tiger-lake.html
> > > > > >
> > > > > > BSpec: 45101
> > > > > >
> > > > > > Mesa support has been submitted in this merge request:
> > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22878
> > > > > >
> > > > > > The media driver is supported by the following commits:
> > > > > > https://github.com/intel/media-
> > driver/commit/92c00a857433ebb34ec
> > > > > > 575e9834f473c6fcb6341
> > > > > > https://github.com/intel/media-driver/commit/fd375cf2c5e1f6bf6b4
> > > > > > 3258ff797b3134aadc9fd
> > > > > > https://github.com/intel/media-
> > driver/commit/08dd244b22484770a33
> > > > > > 464c2c8ae85430e548000
> > >
> > > Andi, let's still get these corrected before merging once the
> > > media-driver revert is completed.
> >
> > Sure!
> >
> > At least this doesn't need a new version to be respinned.
> >
> > Please, Carl, link the new pull request and I will update the commit log.
> >
> > Andi
Re: [PATCH] drm: xlnx: zynqmp_dpsub: Add missing check for dma_set_mask
Hello Jiasheng,
Thank you for the patch.
On Wed, Jun 07, 2023 at 10:05:29AM +0800, Jiasheng Jiang wrote:
> Add check for dma_set_mask() and return the error if it fails.
>
> Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort
> Subsystem")
> Signed-off-by: Jiasheng Jiang
> ---
> drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> index bab862484d42..068413be6527 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> @@ -227,7 +227,9 @@ static int zynqmp_dpsub_probe(struct platform_device
> *pdev)
> dpsub->dev = >dev;
> platform_set_drvdata(pdev, dpsub);
>
> - dma_set_mask(dpsub->dev, DMA_BIT_MASK(ZYNQMP_DISP_MAX_DMA_BIT));
> + ret = dma_set_mask(dpsub->dev, DMA_BIT_MASK(ZYNQMP_DISP_MAX_DMA_BIT));
> + if (ret)
> + return ret;
This seems reasonable.
Reviewed-by: Laurent Pinchart
Tomi, would you be able to quickly test this ?
>
> /* Try the reserved memory. Proceed if there's none. */
> of_reserved_mem_device_init(>dev);
--
Regards,
Laurent Pinchart
Re: [PATCH drm-next v4 03/14] drm: manager to keep track of GPUs VA mappings
Hi Danilo,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 33a86170888b7e4aa0cea94ebb9c67180139cea9]
url:
https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-execution-context-for-GEM-buffers-v4/20230607-063442
base: 33a86170888b7e4aa0cea94ebb9c67180139cea9
patch link:https://lore.kernel.org/r/20230606223130.6132-4-dakr%40redhat.com
patch subject: [PATCH drm-next v4 03/14] drm: manager to keep track of GPUs VA
mappings
config: alpha-allyesconfig
(https://download.01.org/0day-ci/archive/20230607/202306071203.gn8jrmlz-...@intel.com/config)
compiler: alpha-linux-gcc (GCC) 12.3.0
reproduce (this is a W=1 build):
mkdir -p ~/bin
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 33a86170888b7e4aa0cea94ebb9c67180139cea9
b4 shazam
https://lore.kernel.org/r/20230606223130.6132-4-d...@redhat.com
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.3.0 ~/bin/make.cross
W=1 O=build_dir ARCH=alpha olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.3.0 ~/bin/make.cross
W=1 O=build_dir ARCH=alpha SHELL=/bin/bash drivers/gpu/drm/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202306071203.gn8jrmlz-...@intel.com/
All warnings (new ones prefixed by >>):
drivers/gpu/drm/drm_gpuva_mgr.c: In function '__drm_gpuva_sm_map':
>> drivers/gpu/drm/drm_gpuva_mgr.c:1032:32: warning: variable 'prev' set but
>> not used [-Wunused-but-set-variable]
1032 | struct drm_gpuva *va, *prev = NULL;
|^~~~
vim +/prev +1032 drivers/gpu/drm/drm_gpuva_mgr.c
1024
1025 static int
1026 __drm_gpuva_sm_map(struct drm_gpuva_manager *mgr,
1027 const struct drm_gpuva_fn_ops *ops, void *priv,
1028 u64 req_addr, u64 req_range,
1029 struct drm_gem_object *req_obj, u64 req_offset)
1030 {
1031 DRM_GPUVA_ITER(it, mgr, req_addr);
> 1032 struct drm_gpuva *va, *prev = NULL;
1033 u64 req_end = req_addr + req_range;
1034 int ret;
1035
1036 if (unlikely(!drm_gpuva_in_mm_range(mgr, req_addr, req_range)))
1037 return -EINVAL;
1038
1039 if (unlikely(drm_gpuva_in_kernel_node(mgr, req_addr,
req_range)))
1040 return -EINVAL;
1041
1042 drm_gpuva_iter_for_each_range(va, it, req_end) {
1043 struct drm_gem_object *obj = va->gem.obj;
1044 u64 offset = va->gem.offset;
1045 u64 addr = va->va.addr;
1046 u64 range = va->va.range;
1047 u64 end = addr + range;
1048 bool merge = !!va->gem.obj;
1049
1050 if (addr == req_addr) {
1051 merge &= obj == req_obj &&
1052 offset == req_offset;
1053
1054 if (end == req_end) {
1055 ret = op_unmap_cb(ops, , priv, va,
merge);
1056 if (ret)
1057 return ret;
1058 break;
1059 }
1060
1061 if (end < req_end) {
1062 ret = op_unmap_cb(ops, , priv, va,
merge);
1063 if (ret)
1064 return ret;
1065 goto next;
1066 }
1067
1068 if (end > req_end) {
1069 struct drm_gpuva_op_map n = {
1070 .va.addr = req_end,
1071 .va.range = range - req_range,
1072 .gem.obj = obj,
1073 .gem.offset = offset +
req_range,
1074 };
1075 struct drm_gpuva_op_unmap u = {
1076 .va = va,
1077 .keep = merge,
1078 };
1079
1080 ret = op_remap_cb(ops, , priv, NULL,
, );
1081 if (ret)
1082 return ret;
1083 break;
1084 }
1085 } else if (addr < req_addr) {
1086 u64 ls_range = req_addr -
Re: [PATCH net-next v6 3/6] net: bcmasp: Add support for ASP2.0 Ethernet controller
On Tue, 6 Jun 2023 21:22:45 -0700 Justin Chen wrote: > >> Through filters that can be programmed by the Host cpu or co-processor. > > > > How are the filter programmed by the host (in terms of user API)? > > You are stumbling upon my next objective here. This patch set does not > support this because it wasn't clear how to do it. The plan was to get > the base driver merged first then introduce a way to specify an offload > channel. Alright. > If you must know, I introduced a rxnfc flow_spec ring cookie to specify > an offload filter. Not sure if this is the right way to do it or not, > but figured this would be a future discussion. We clean leave it for later indeed, but in case you're wondering - that's unlikely to fly. My preference will be to expose the accelerator port as a switch port, with a netdev and forward using TC flower etc. With the netdev in place you'll have a place to report stats and all the necessary diagnostics, which otherwise get crammed into random places. I believe Florian asked about this in the past, I hope I'm being consistent with my answer here :P
[GIT PULL] exynos-drm-fixes
Hi Dave and Daniel, Just two fixups to Exynos vidi and g2d drivers. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 9561de3a55bed6bdd44a12820ba81ec416e705a7: Linux 6.4-rc5 (2023-06-04 14:04:27 -0400) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-fixes-for-v6.4-rc6 for you to fetch changes up to 48bfd02569f5db49cc033f259e66d57aa6efc9a3: drm/exynos: fix race condition UAF in exynos_g2d_exec_ioctl (2023-06-07 13:03:16 +0900) Two fixups - Fix wrong return in Exynos vidi driver. - Fix use-after-free issue to Exynos g2d driver. Inki Dae (1): drm/exynos: vidi: fix a wrong error return Min Li (1): drm/exynos: fix race condition UAF in exynos_g2d_exec_ioctl drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 -- 2 files changed, 1 insertion(+), 3 deletions(-)
Re: [PATCH v9 0/8] drm: Remove usage of deprecated DRM_* macros
On Tue, Jun 06, 2023 at 11:47:50PM +0530, Siddh Raman Pant wrote: > On Tue, 06 Jun 2023 23:19:28 +0530, Laurent Pinchart wrote: > > The idea would be to include the drm_print_deprecated.h header in > > drivers that still use the deprecated macros. > > Yeah, what I meant was in a "first pass" kind of sense. > > > > Not every file can be seen at a case-by-case basis or by coccinelle > > > as far as I understand its usage. Consider the following: > > > > > > DRM_INFO is used on line 210 of amd/amdgpu/amdgpu_acpi.c, but the > > > file does not even include drm_print.h directly. It includes the > > > amdgpu.h header, which includes the amdgpu_ring.h header, which > > > finally has the "#include " line. > > > > > > If a simple find and replace has to be done, then that can be added > > > at the end of the series. > > > > Maybe a simple grep for the deprecated macros would be enough to > > identify all the files that still use them ? > > Hmm, so the drm_print_deprecated.h should be included individually on > all the files, regardless of whether they include drm_print.h directly > or not? > > Actually that makes sense, so further inclusion of top-level header > would not automatically include the deprecated macros. That's the idea, yes. It would also clearly flag drivers that need to be converted to the new macros. > Since this needs some thought, I will be sending v10 without this. > This change can be sent later separately, as it will anyways be a > huge patch, and 10 is already a big enough revision number. Sounds good to me. -- Regards, Laurent Pinchart
Re: [PATCH net-next v6 3/6] net: bcmasp: Add support for ASP2.0 Ethernet controller
On 6/6/2023 8:45 PM, Jakub Kicinski wrote: On Tue, 6 Jun 2023 19:33:13 -0700 Justin Chen wrote: Not netdevs per se, but packets can be redirected to an offload co-processor. How is the redirecting configured? Through filters that can be programmed by the Host cpu or co-processor. How are the filter programmed by the host (in terms of user API)? You are stumbling upon my next objective here. This patch set does not support this because it wasn't clear how to do it. The plan was to get the base driver merged first then introduce a way to specify an offload channel. If you must know, I introduced a rxnfc flow_spec ring cookie to specify an offload filter. Not sure if this is the right way to do it or not, but figured this would be a future discussion. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Lima] [PATCH] drm/lima: fix sched context destroy
Reviewed-by: Qiang Yu
Applied to drm-misc-fixes.
On Wed, Jun 7, 2023 at 9:18 AM Vasily Khoruzhick wrote:
>
> On Tue, Jun 6, 2023 at 7:33 AM Erico Nunes wrote:
> >
> > The drm sched entity must be flushed before finishing, to account for
> > jobs potentially still in flight at that time.
> > Lima did not do this flush until now, so switch the destroy call to the
> > drm_sched_entity_destroy() wrapper which will take care of that.
> >
> > This fixes a regression on lima which started since the rework in
> > commit 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini")
> > where some specific types of applications may hang indefinitely.
> >
> > Fixes: 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini")
> > Signed-off-by: Erico Nunes
>
> Reviewed-by: Vasily Khoruzhick
>
> > ---
> > drivers/gpu/drm/lima/lima_sched.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/lima/lima_sched.c
> > b/drivers/gpu/drm/lima/lima_sched.c
> > index ff003403fbbc..ffd91a5ee299 100644
> > --- a/drivers/gpu/drm/lima/lima_sched.c
> > +++ b/drivers/gpu/drm/lima/lima_sched.c
> > @@ -165,7 +165,7 @@ int lima_sched_context_init(struct lima_sched_pipe
> > *pipe,
> > void lima_sched_context_fini(struct lima_sched_pipe *pipe,
> > struct lima_sched_context *context)
> > {
> > - drm_sched_entity_fini(>base);
> > + drm_sched_entity_destroy(>base);
> > }
> >
> > struct dma_fence *lima_sched_context_queue_task(struct lima_sched_task
> > *task)
> > --
> > 2.40.1
> >
Re: [PATCH v9 8/8] drm: Remove usage of deprecated DRM_DEBUG_KMS
Hi Jani,
On Wed, Jun 07, 2023 at 12:39:44AM +0300, Jani Nikula wrote:
> On Tue, 06 Jun 2023, Laurent Pinchart wrote:
> > On Tue, Jun 06, 2023 at 04:15:22PM +0530, Siddh Raman Pant wrote:
> >> drm_print.h says DRM_DEBUG_KMS is deprecated in favor of
> >> drm_dbg_kms().
> >> ---
> >> drivers/gpu/drm/drm_client_modeset.c | 112 +++
> >> drivers/gpu/drm/drm_color_mgmt.c | 4 +-
> >> drivers/gpu/drm/drm_connector.c | 21 ++---
> >> drivers/gpu/drm/drm_crtc.c | 36 -
> >> drivers/gpu/drm/drm_crtc_helper.c| 54 ++---
> >> drivers/gpu/drm/drm_debugfs_crc.c| 5 +-
> >> drivers/gpu/drm/drm_displayid.c | 4 +-
> >> drivers/gpu/drm/drm_edid.c | 17 ++--
> >> drivers/gpu/drm/drm_lease.c | 2 +-
> >> drivers/gpu/drm/drm_mipi_dbi.c | 7 +-
> >> drivers/gpu/drm/drm_modes.c | 10 +--
> >> drivers/gpu/drm/drm_plane.c | 32
> >> drivers/gpu/drm/drm_probe_helper.c | 39 +-
> >> drivers/gpu/drm/drm_rect.c | 4 +-
> >> drivers/gpu/drm/drm_sysfs.c | 8 +-
> >> 15 files changed, 187 insertions(+), 168 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_client_modeset.c
> >> b/drivers/gpu/drm/drm_client_modeset.c
> >> index e2403b8c6347..4e08ae688b83 100644
> >> --- a/drivers/gpu/drm/drm_client_modeset.c
> >> +++ b/drivers/gpu/drm/drm_client_modeset.c
> >> @@ -242,8 +242,9 @@ static void drm_client_connectors_enabled(struct
> >> drm_connector **connectors,
> >>for (i = 0; i < connector_count; i++) {
> >>connector = connectors[i];
> >>enabled[i] = drm_connector_enabled(connector, true);
> >> - DRM_DEBUG_KMS("connector %d enabled? %s\n", connector->base.id,
> >> -connector->display_info.non_desktop ? "non
> >> desktop" : str_yes_no(enabled[i]));
> >> + drm_dbg_kms(connector->dev, "connector %d enabled? %s\n",
> >> + connector->base.id,
> >> + connector->display_info.non_desktop ? "non desktop"
> >> : str_yes_no(enabled[i]));
> >>
> >>any_enabled |= enabled[i];
> >>}
> >> @@ -303,7 +304,7 @@ static bool drm_client_target_cloned(struct drm_device
> >> *dev,
> >>}
> >>
> >>if (can_clone) {
> >> - DRM_DEBUG_KMS("can clone using command line\n");
> >> + drm_dbg_kms(dev, "can clone using command line\n");
> >>return true;
> >>}
> >>
> >> @@ -328,7 +329,7 @@ static bool drm_client_target_cloned(struct drm_device
> >> *dev,
> >>}
> >>
> >>if (can_clone) {
> >> - DRM_DEBUG_KMS("can clone using 1024x768\n");
> >> + drm_dbg_kms(dev, "can clone using 1024x768\n");
> >>return true;
> >>}
> >>drm_info(dev, "kms: can't enable cloning when we probably wanted
> >> to.\n");
> >> @@ -352,8 +353,9 @@ static int drm_client_get_tile_offsets(struct
> >> drm_connector **connectors,
> >>continue;
> >>
> >>if (!modes[i] && (h_idx || v_idx)) {
> >> - DRM_DEBUG_KMS("no modes for connector tiled %d %d\n", i,
> >> -connector->base.id);
> >> + drm_dbg_kms(connector->dev,
> >> + "no modes for connector tiled %d %d\n",
> >> + i, connector->base.id);
> >>continue;
> >>}
> >>if (connector->tile_h_loc < h_idx)
> >> @@ -364,7 +366,8 @@ static int drm_client_get_tile_offsets(struct
> >> drm_connector **connectors,
> >>}
> >>offsets[idx].x = hoffset;
> >>offsets[idx].y = voffset;
> >> - DRM_DEBUG_KMS("returned %d %d for %d %d\n", hoffset, voffset, h_idx,
> >> v_idx);
> >> + drm_dbg_kms(NULL, "returned %d %d for %d %d\n",
> >> + hoffset, voffset, h_idx, v_idx);
> >>return 0;
> >> }
> >>
> >> @@ -421,14 +424,16 @@ static bool drm_client_target_preferred(struct
> >> drm_connector **connectors,
> >>drm_client_get_tile_offsets(connectors,
> >> connector_count, modes, offsets, i,
> >>connector->tile_h_loc,
> >> connector->tile_v_loc);
> >>}
> >> - DRM_DEBUG_KMS("looking for cmdline mode on connector %d\n",
> >> -connector->base.id);
> >> + drm_dbg_kms(connector->dev,
> >> + "looking for cmdline mode on connector %d\n",
> >> + connector->base.id);
> >>
> >>/* got for command line mode first */
> >>modes[i] = drm_connector_pick_cmdline_mode(connector);
> >>if (!modes[i]) {
> >> - DRM_DEBUG_KMS("looking for preferred mode on connector
> >> %d %d\n",
> >> -connector->base.id, connector->tile_group
> >> ? connector->tile_group->id : 0);
> >> + drm_dbg_kms(connector->dev,
>
Re: [PATCH net-next v6 3/6] net: bcmasp: Add support for ASP2.0 Ethernet controller
On Tue, 6 Jun 2023 19:33:13 -0700 Justin Chen wrote: > >> Not netdevs per se, but packets can be redirected to an offload > >> co-processor. > > > > How is the redirecting configured? > > Through filters that can be programmed by the Host cpu or co-processor. How are the filter programmed by the host (in terms of user API)?
RE: [PATCH v17 1/1] drm/i915: Allow user to set cache at BO creation
Media driver reverted previous patches, and file a new PR
https://github.com/intel/media-driver/pull/1680
will hold this PR until the uapi changes appear in drm_next.
besides this, ask a dumb question.
How we retrieve the pat_index from a shared resource though dma_buf fd?
maybe we need to know whether it could be CPU cached if we want map it.
Of course, looks there are no real usage to access it though CPU.
Just use it directly without any pat related options ?
Thanks
Carl
> -Original Message-
> From: Andi Shyti
> Sent: Tuesday, June 6, 2023 7:15 PM
> To: Joonas Lahtinen
> Cc: Andi Shyti ; Tvrtko Ursulin
> ; Yang, Fei ; Chris
> Wilson ; Roper, Matthew D
> ; Justen, Jordan L ;
> Zhang, Carl ; Gu, Lihao ; Intel
> GFX ; DRI Devel de...@lists.freedesktop.org>
> Subject: Re: [PATCH v17 1/1] drm/i915: Allow user to set cache at BO creation
>
> > > > > To comply with the design that buffer objects shall have
> > > > > immutable cache setting through out their life cycle, {set,
> > > > > get}_caching ioctl's are no longer supported from MTL onward.
> > > > > With that change caching policy can only be set at object
> > > > > creation time. The current code applies a default (platform dependent)
> cache setting for all objects.
> > > > > However this is not optimal for performance tuning. The patch
> > > > > extends the existing gem_create uAPI to let user set PAT index
> > > > > for the object at creation time.
> > > > > The new extension is platform independent, so UMD's can switch
> > > > > to using this extension for older platforms as well, while {set,
> > > > > get}_caching are still supported on these legacy paltforms for
> compatibility reason.
> > > > > However, since PAT index was not clearly defined for platforms
> > > > > prior to
> > > > > GEN12 (TGL), so we are limiting this externsion to GEN12+
> > > > > platforms only. See ext_set_pat() in for the implementation details.
> > > > >
> > > > > Note: The documentation related to the PAT/MOCS tables is
> > > > > currently available for Tiger Lake here:
> > > > > https://www.intel.com/content/www/us/en/docs/graphics-for-linux/
> > > > > developer-reference/1-0/tiger-lake.html
> > > > >
> > > > > BSpec: 45101
> > > > >
> > > > > Mesa support has been submitted in this merge request:
> > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22878
> > > > >
> > > > > The media driver is supported by the following commits:
> > > > > https://github.com/intel/media-
> driver/commit/92c00a857433ebb34ec
> > > > > 575e9834f473c6fcb6341
> > > > > https://github.com/intel/media-driver/commit/fd375cf2c5e1f6bf6b4
> > > > > 3258ff797b3134aadc9fd
> > > > > https://github.com/intel/media-
> driver/commit/08dd244b22484770a33
> > > > > 464c2c8ae85430e548000
> >
> > Andi, let's still get these corrected before merging once the
> > media-driver revert is completed.
>
> Sure!
>
> At least this doesn't need a new version to be respinned.
>
> Please, Carl, link the new pull request and I will update the commit log.
>
> Andi
linux-next: build warning after merge of the amdgpu tree
Hi all,
After merging the amdgpu tree, today's linux-next build (htmldocs)
produced this warning:
drivers/gpu/drm/amd/display/dc/dc.h:900: warning: Function parameter or member
'enable_legacy_fast_update' not described in 'dc_debug_options'
Introduced by commit
4164998e0a9c ("drm/amd/display: Refactor fast update to use new HWSS build
sequence")
--
Cheers,
Stephen Rothwell
pgphsNaHQXmyi.pgp
Description: OpenPGP digital signature
Re: [PATCH net-next v6 3/6] net: bcmasp: Add support for ASP2.0 Ethernet controller
On 6/6/2023 6:54 PM, Jakub Kicinski wrote: On Tue, 6 Jun 2023 18:35:51 -0700 Justin Chen wrote: Also - can you describe how you can have multiple netdevs for the same MAC? Not netdevs per se, but packets can be redirected to an offload co-processor. How is the redirecting configured? Through filters that can be programmed by the Host cpu or co-processor. Could you split this patch into basic netdev datapath, and then as separate patches support for ethtool configuration features, each with its own patch? This will make it easier for area experts to review. The base patch can probably include these: + .get_drvinfo= bcmasp_get_drvinfo, + .get_link = ethtool_op_get_link, + .get_link_ksettings = phy_ethtool_get_link_ksettings, + .set_link_ksettings = phy_ethtool_set_link_ksettings, + .get_msglevel = bcmasp_get_msglevel, + .set_msglevel = bcmasp_set_msglevel, WoL can be a separate patch: + .get_wol= bcmasp_get_wol, + .set_wol= bcmasp_set_wol, Stats a separate patch: + .get_strings= bcmasp_get_strings, + .get_ethtool_stats = bcmasp_get_ethtool_stats, + .get_sset_count = bcmasp_get_sset_count, + .nway_reset = phy_ethtool_nway_reset, Flow steering separate: + .get_rxnfc = bcmasp_get_rxnfc, + .set_rxnfc = bcmasp_set_rxnfc, EEE separate: + .set_eee= bcmasp_set_eee, + .get_eee= bcmasp_get_eee, Will do. smime.p7s Description: S/MIME Cryptographic Signature
[PATCH] drm: xlnx: zynqmp_dpsub: Add missing check for dma_set_mask
Add check for dma_set_mask() and return the error if it fails.
Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort
Subsystem")
Signed-off-by: Jiasheng Jiang
---
drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
index bab862484d42..068413be6527 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
@@ -227,7 +227,9 @@ static int zynqmp_dpsub_probe(struct platform_device *pdev)
dpsub->dev = >dev;
platform_set_drvdata(pdev, dpsub);
- dma_set_mask(dpsub->dev, DMA_BIT_MASK(ZYNQMP_DISP_MAX_DMA_BIT));
+ ret = dma_set_mask(dpsub->dev, DMA_BIT_MASK(ZYNQMP_DISP_MAX_DMA_BIT));
+ if (ret)
+ return ret;
/* Try the reserved memory. Proceed if there's none. */
of_reserved_mem_device_init(>dev);
--
2.25.1
Re: [PATCH net-next v6 3/6] net: bcmasp: Add support for ASP2.0 Ethernet controller
On Tue, 6 Jun 2023 18:35:51 -0700 Justin Chen wrote: > > Also - can you describe how you can have multiple netdevs for > > the same MAC? > > Not netdevs per se, but packets can be redirected to an offload > co-processor. How is the redirecting configured? Could you split this patch into basic netdev datapath, and then as separate patches support for ethtool configuration features, each with its own patch? This will make it easier for area experts to review. The base patch can probably include these: + .get_drvinfo= bcmasp_get_drvinfo, + .get_link = ethtool_op_get_link, + .get_link_ksettings = phy_ethtool_get_link_ksettings, + .set_link_ksettings = phy_ethtool_set_link_ksettings, + .get_msglevel = bcmasp_get_msglevel, + .set_msglevel = bcmasp_set_msglevel, WoL can be a separate patch: + .get_wol= bcmasp_get_wol, + .set_wol= bcmasp_set_wol, Stats a separate patch: + .get_strings= bcmasp_get_strings, + .get_ethtool_stats = bcmasp_get_ethtool_stats, + .get_sset_count = bcmasp_get_sset_count, + .nway_reset = phy_ethtool_nway_reset, Flow steering separate: + .get_rxnfc = bcmasp_get_rxnfc, + .set_rxnfc = bcmasp_set_rxnfc, EEE separate: + .set_eee= bcmasp_set_eee, + .get_eee= bcmasp_get_eee,
Re: [PATCH net-next v6 3/6] net: bcmasp: Add support for ASP2.0 Ethernet controller
On 6/6/2023 5:16 PM, Jakub Kicinski wrote:
On Tue, 6 Jun 2023 15:58:21 -0700 Justin Chen wrote:
On 6/2/23 11:58 PM, Jakub Kicinski wrote:
On Thu, 1 Jun 2023 15:12:28 -0700 Justin Chen wrote:
+ /* general stats */
+ STAT_NETDEV(rx_packets),
+ STAT_NETDEV(tx_packets),
+ STAT_NETDEV(rx_bytes),
+ STAT_NETDEV(tx_bytes),
+ STAT_NETDEV(rx_errors),
+ STAT_NETDEV(tx_errors),
+ STAT_NETDEV(rx_dropped),
+ STAT_NETDEV(tx_dropped),
+ STAT_NETDEV(multicast),
please don't report standard interface stats in ethtool -S
These are not netdev statistics but MAC block counters. Guess it is not
clear with the naming here, will fix this. We have a use case where the
MAC traffic may be redirected from the associated net dev, so the
counters may not be the same.
You seem to be dumping straight from the stats member of struct
net_device:
+ if (s->type == BCMASP_STAT_NETDEV)
+ p = (char *)>stats;
No?
Woops I got it mixed up. Yes these stats are redundant. What I was
describing is
+ STAT_BCMASP_MIB_RX("rx_pkts", mib.rx.pkt),
and equivalent.
Also - can you describe how you can have multiple netdevs for
the same MAC?
Not netdevs per se, but packets can be redirected to an offload
co-processor.
smime.p7s
Description: S/MIME Cryptographic Signature
[PATCH v2] drm/bridge: ti-sn65dsi86: Avoid possible buffer overflow
Smatch error:buffer overflow 'ti_sn_bridge_refclk_lut' 5 <= 5.
Fixes: cea86c5bb442 ("drm/bridge: ti-sn65dsi86: Implement the pwm_chip")
Signed-off-by: Su Hui
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 7a748785c545..bb88406495e9 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -305,7 +305,7 @@ static void ti_sn_bridge_set_refclk_freq(struct
ti_sn65dsi86 *pdata)
* The PWM refclk is based on the value written to SN_DPPLL_SRC_REG,
* regardless of its actual sourcing.
*/
- pdata->pwm_refclk_freq = ti_sn_bridge_refclk_lut[i];
+ pdata->pwm_refclk_freq = ti_sn_bridge_refclk_lut[i < refclk_lut_size ?
i : 1];
}
static void ti_sn65dsi86_enable_comms(struct ti_sn65dsi86 *pdata)
--
2.30.2
Re: [Lima] [PATCH] drm/lima: fix sched context destroy
On Tue, Jun 6, 2023 at 7:33 AM Erico Nunes wrote:
>
> The drm sched entity must be flushed before finishing, to account for
> jobs potentially still in flight at that time.
> Lima did not do this flush until now, so switch the destroy call to the
> drm_sched_entity_destroy() wrapper which will take care of that.
>
> This fixes a regression on lima which started since the rework in
> commit 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini")
> where some specific types of applications may hang indefinitely.
>
> Fixes: 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini")
> Signed-off-by: Erico Nunes
Reviewed-by: Vasily Khoruzhick
> ---
> drivers/gpu/drm/lima/lima_sched.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_sched.c
> b/drivers/gpu/drm/lima/lima_sched.c
> index ff003403fbbc..ffd91a5ee299 100644
> --- a/drivers/gpu/drm/lima/lima_sched.c
> +++ b/drivers/gpu/drm/lima/lima_sched.c
> @@ -165,7 +165,7 @@ int lima_sched_context_init(struct lima_sched_pipe *pipe,
> void lima_sched_context_fini(struct lima_sched_pipe *pipe,
> struct lima_sched_context *context)
> {
> - drm_sched_entity_fini(>base);
> + drm_sched_entity_destroy(>base);
> }
>
> struct dma_fence *lima_sched_context_queue_task(struct lima_sched_task *task)
> --
> 2.40.1
>
Re: [PATCH] drm/bridge: ti-sn65dsi86: Avoid possible buffer overflow
Hi,
On 2023/6/6 23:28, Doug Anderson wrote:
Hi,
On Tue, Jun 6, 2023 at 12:56 AM Su Hui wrote:
Smatch error:buffer overflow 'ti_sn_bridge_refclk_lut' 5 <= 5.
Fixes: cea86c5bb442 ("drm/bridge: ti-sn65dsi86: Implement the pwm_chip")
Signed-off-by: Su Hui
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 7a748785c545..952aae4221e7 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -305,7 +305,8 @@ static void ti_sn_bridge_set_refclk_freq(struct
ti_sn65dsi86 *pdata)
* The PWM refclk is based on the value written to SN_DPPLL_SRC_REG,
* regardless of its actual sourcing.
*/
- pdata->pwm_refclk_freq = ti_sn_bridge_refclk_lut[i];
+ if (i < refclk_lut_size)
+ pdata->pwm_refclk_freq = ti_sn_bridge_refclk_lut[i];
I don't think this is quite the right fix. I don't think we can just
skip assigning "pdata->pwm_refclk_freq". In general I think we're in
pretty bad shape if we ever fail to match a refclk from the table and
I'm not quite sure how the bridge chip could work at all in this case.
Probably that at least deserves a warning message in the logs. There's
no place to return an error though, so I guess the warning is the best
we can do and then we can do our best to do something reasonable.
In this case, I think "reasonable" might be that if the for loop exits
and "i == refclk_lut_size" that we should set "i" to 1. According to
the datasheet [1] setting a value of 5 (which the existing code does)
is the same as setting a value of 1 (the default) and if it's 1 then
we'll be able to look this up in the table.
I think you are right, set i to 1 if i >= refclk_lut_size. I will resend
this patch soon.
Thanks for your reply!
Su Hui
[1] https://www.ti.com/lit/gpn/sn65dsi86
-Doug
Re: [Freedreno] [RFC PATCH v2 10/13] drm/msm/dpu: add list of supported formats to the DPU caps
On 6/6/2023 4:21 PM, Dmitry Baryshkov wrote: On 07/06/2023 02:14, Abhinav Kumar wrote: On 6/6/2023 3:59 PM, Dmitry Baryshkov wrote: On 07/06/2023 01:57, Abhinav Kumar wrote: On 6/6/2023 3:50 PM, Dmitry Baryshkov wrote: On 07/06/2023 01:47, Abhinav Kumar wrote: On 6/6/2023 2:52 PM, Dmitry Baryshkov wrote: On 07/06/2023 00:47, Abhinav Kumar wrote: On 6/6/2023 2:29 PM, Dmitry Baryshkov wrote: On 07/06/2023 00:14, Abhinav Kumar wrote: On 5/24/2023 6:47 PM, Dmitry Baryshkov wrote: On Thu, 25 May 2023 at 02:16, Abhinav Kumar wrote: On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote: As we are going to add virtual planes, add the list of supported formats to the hw catalog entry. It will be used to setup universal planes, with later selecting a pipe depending on whether the YUV format is used for the framebuffer. If your usage of format_list is going to be internal to dpu_plane.c, I can think of another idea for this change. This essentially translates to if (num_vig >= 1) If we can just have a small helper to detect that from the catalog can we use that instead of adding formats to the dpu caps? I'd prefer to be explicit here. The list of supported formats might vary between generations, might it not? Also we don't have a case of the devices not having VIG planes. Even the qcm2290 (which doesn't have CSC) lists YUV as supported. the list of formats is tied to the sspps the dpu generation has and the capabilities of those sspps. qcm2290 is really an interesting case. It has one vig sspp but no csc block for that vig sspp, hence it cannot support non-RGB formats. I have confirmed that downstream is incorrect to populate yuv formats for qcm2290. I still think that having atleast one vig sspp with csc sub-blk is the right condition to check if we want to decide if the dpu for that chipset supports yuv formats. Extra csc-blk check to handle qcm2290. Having a small helper in dpu_plane.c is good enough for that because with virtual planes, you only need to know "if such a plane exists and not which plane" and a full catalog change isnt needed IMO This goes down to the question: is the list of YUV and non-YUV formats static or not? Do all DPU devices support the same set of YUV and non-YUV formats? If it is static, we might as well drop dpu_sspp_sub_blks::format_list. I would say yes based on the below reference: https://git.codelinaro.org/clo/la/platform/vendor/opensource/display-drivers/-/blob/clo/main/msm/sde/sde_hw_catalog.c#L3858 We always add the same set of YUV formats for all Vig SSPPs irrespective of the chipsets. Well, as your example pointed out, few lines below it starts adding formats to the list, so the format list is not static and depends on the generation. No, the DPU revision checks are there to add P010 UBWC formats on top of the Vig formats. At the moment, the latest downstream code (code which is not on CLO hence I cannot share) has dropped all that and just checks if P010 UBWC is supported for the Vig SSPP and adds all those. So its still tied to the feature bit whether P010 UBWC is supported in the Vig SSPP and not at the chipset level. So, what is the difference? This means that depending on some conditions either we can support P010 UBWC or we can not. So the list of all suppored formats is not static. The difference is SSPP level vs chipset level. This patch was made with chipset level in mind and had to expand the format list for each chipset. What I am suggesting is its a SSPP level decision. Please note its not just P010 UBWC but P010 UBWC FOR Vig SSPP. So expanding each chipset's format list is not needed when the decision can be made just on the basis of the SSPP's feature flag OR the presence of the csc blk. Maybe I misunderstand something. Is P010 UBWC format supported on VIG SSPPs on all generations? The code that you have pointed me suggests that is is not. No, your understanding is correct that P010 UBWC format is supported only on Vig SSPPs of certain generations. But my point is that, its still a SSPP level decision. So even if we add P010 UBWC formats later to the list of supported formats, what we will do is add that feature bit alone in the Vig SSPP's feature mask of that chipset and based on that all the P010 UBWC formats for the virtual planes. But if we follow your approach, we will add another array called plane_formats_p010_ubwc and add that to each chipset which will support it. sspp->sblk->formats_list is constant, so we will have to add another formats array anyway. Not to each chipset. Yes you will have one new array for P010 UBWC formats which you will use to do the plane_init() if any of the Vig SSPPs have the feature bit set. As opposed to adding the format_list to each chipset like you are doing now. Its just a decision of whether you want to expand the catalog to have this for each chipset OR not when you can easily make that
Re: [PATCH net-next v6 3/6] net: bcmasp: Add support for ASP2.0 Ethernet controller
On Tue, 6 Jun 2023 15:58:21 -0700 Justin Chen wrote: > On 6/2/23 11:58 PM, Jakub Kicinski wrote: > > On Thu, 1 Jun 2023 15:12:28 -0700 Justin Chen wrote: > >> + /* general stats */ > >> + STAT_NETDEV(rx_packets), > >> + STAT_NETDEV(tx_packets), > >> + STAT_NETDEV(rx_bytes), > >> + STAT_NETDEV(tx_bytes), > >> + STAT_NETDEV(rx_errors), > >> + STAT_NETDEV(tx_errors), > >> + STAT_NETDEV(rx_dropped), > >> + STAT_NETDEV(tx_dropped), > >> + STAT_NETDEV(multicast), > > > > please don't report standard interface stats in ethtool -S > > > > These are not netdev statistics but MAC block counters. Guess it is not > clear with the naming here, will fix this. We have a use case where the > MAC traffic may be redirected from the associated net dev, so the > counters may not be the same. You seem to be dumping straight from the stats member of struct net_device: + if (s->type == BCMASP_STAT_NETDEV) + p = (char *)>stats; No? Also - can you describe how you can have multiple netdevs for the same MAC?
Re: [PATCH] drm/i915/guc: Force a reset on internal GuC error
On 6/5/2023 1:54 PM, john.c.harri...@intel.com wrote:
From: John Harrison
If GuC hits an internal error (and survives long enough to report it
to the KMD), it is basically toast and will stop until a GT reset and
subsequent GuC reload is performed. Previously, the KMD just printed
an error message and then waited for the heartbeat to eventually kick
in and trigger a reset (assuming the heartbeat had not been disabled).
Instead, force the reset immediately to guarantee that it happens and
to eliminate the very long heartbeat delay. The captured error state
is also more likely to be useful if captured at the time of the error
rather than many seconds later.
Note that it is not possible to trigger a reset from with the G2H
handler itself. The reset prepare process involves flushing
outstanding G2H contents. So a deadlock could result. Instead, the G2H
handler queues a worker thread to do the reset asynchronously.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 26 +++
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 9
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +-
3 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 2eb891b270aec..c35cf10f52b56 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -159,6 +159,13 @@ static void gen11_disable_guc_interrupts(struct intel_guc
*guc)
gen11_reset_guc_interrupts(guc);
}
+static void guc_dead_worker_func(struct work_struct *w)
+{
+ struct intel_guc *guc = container_of(w, struct intel_guc,
dead_guc_worker);
+
+ intel_gt_handle_error(guc_to_gt(guc), ALL_ENGINES, I915_ERROR_CAPTURE, "dead
GuC");
+}
+
void intel_guc_init_early(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
@@ -171,6 +178,8 @@ void intel_guc_init_early(struct intel_guc *guc)
intel_guc_slpc_init_early(>slpc);
intel_guc_rc_init_early(guc);
+ INIT_WORK(>dead_guc_worker, guc_dead_worker_func);
+
mutex_init(>send_mutex);
spin_lock_init(>irq_lock);
if (GRAPHICS_VER(i915) >= 11) {
@@ -585,6 +594,20 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32
*request, u32 len,
return ret;
}
+int intel_guc_crash_process_msg(struct intel_guc *guc, u32 action)
+{
+ if (action == INTEL_GUC_ACTION_NOTIFY_CRASH_DUMP_POSTED)
+ guc_err(guc, "Crash dump notification\n");
+ else if (action == INTEL_GUC_ACTION_NOTIFY_EXCEPTION)
+ guc_err(guc, "Exception notification\n");
+ else
+ guc_err(guc, "Unknown crash notification\n");
+
+ queue_work(system_unbound_wq, >dead_guc_worker);
Do we need to flush the worker on suspend/unload?
+
+ return 0;
+}
+
int intel_guc_to_host_process_recv_msg(struct intel_guc *guc,
const u32 *payload, u32 len)
{
@@ -601,6 +624,9 @@ int intel_guc_to_host_process_recv_msg(struct intel_guc
*guc,
if (msg & INTEL_GUC_RECV_MSG_EXCEPTION)
guc_err(guc, "Received early exception notification!\n");
+ if (msg & (INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED | INTEL_GUC_RECV_MSG_EXCEPTION))
+ queue_work(system_unbound_wq, >dead_guc_worker);
I'm a bit worried about queuing this for a failure during the init flow.
If we have a systemic issue (e.g. bad memory) we could end up trying and
failing to reset & reload multiple times, until the wedge code manages
to set the wedge on init flag.
Daniele
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 8dc291ff00935..0b54eec95fc00 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -266,6 +266,14 @@ struct intel_guc {
unsigned long last_stat_jiffies;
} timestamp;
+ /**
+* @dead_guc_worker: Asynchronous worker thread for forcing a GuC reset.
+* Specifically used when the G2H handler wants to issue a reset. Resets
+* require flushing the G2H queue. So, the G2H processing itself must
not
+* trigger a reset directly. Instead, go via this worker.
+*/
+ struct work_struct dead_guc_worker;
+
#ifdef CONFIG_DRM_I915_SELFTEST
/**
* @number_guc_id_stolen: The number of guc_ids that have been stolen
@@ -476,6 +484,7 @@ int intel_guc_engine_failure_process_msg(struct intel_guc
*guc,
const u32 *msg, u32 len);
int intel_guc_error_capture_process_msg(struct intel_guc *guc,
const u32 *msg, u32 len);
+int intel_guc_crash_process_msg(struct intel_guc *guc, u32 action);
struct intel_engine_cs *
intel_guc_lookup_engine(struct intel_guc *guc, u8 guc_class, u8 instance);
diff --git
Re: [PATCH drm-next v4 04/14] drm: debugfs: provide infrastructure to dump a DRM GPU VA space
Hi Danilo,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 33a86170888b7e4aa0cea94ebb9c67180139cea9]
url:
https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-execution-context-for-GEM-buffers-v4/20230607-063442
base: 33a86170888b7e4aa0cea94ebb9c67180139cea9
patch link:https://lore.kernel.org/r/20230606223130.6132-5-dakr%40redhat.com
patch subject: [PATCH drm-next v4 04/14] drm: debugfs: provide infrastructure
to dump a DRM GPU VA space
config: m68k-allyesconfig
(https://download.01.org/0day-ci/archive/20230607/202306070751.26wx3ive-...@intel.com/config)
compiler: m68k-linux-gcc (GCC) 12.3.0
reproduce (this is a W=1 build):
mkdir -p ~/bin
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 33a86170888b7e4aa0cea94ebb9c67180139cea9
b4 shazam
https://lore.kernel.org/r/20230606223130.6132-5-d...@redhat.com
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.3.0 ~/bin/make.cross
W=1 O=build_dir ARCH=m68k olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.3.0 ~/bin/make.cross
W=1 O=build_dir ARCH=m68k SHELL=/bin/bash drivers/gpu/drm/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202306070751.26wx3ive-...@intel.com/
All warnings (new ones prefixed by >>):
drivers/gpu/drm/drm_debugfs.c: In function 'drm_debugfs_gpuva_info':
>> drivers/gpu/drm/drm_debugfs.c:213:28: warning: cast from pointer to integer
>> of different size [-Wpointer-to-int-cast]
213 |(u64)va->gem.obj, va->gem.offset);
|^
vim +213 drivers/gpu/drm/drm_debugfs.c
178
179 /**
180 * drm_debugfs_gpuva_info - dump the given DRM GPU VA space
181 * @m: pointer to the _file to write
182 * @mgr: the _gpuva_manager representing the GPU VA space
183 *
184 * Dumps the GPU VA mappings of a given DRM GPU VA manager.
185 *
186 * For each DRM GPU VA space drivers should call this function from
their
187 * _info_list's show callback.
188 *
189 * Returns: 0 on success, -ENODEV if the is not initialized
190 */
191 int drm_debugfs_gpuva_info(struct seq_file *m,
192 struct drm_gpuva_manager *mgr)
193 {
194 DRM_GPUVA_ITER(it, mgr, 0);
195 struct drm_gpuva *va, *kva = >kernel_alloc_node;
196
197 if (!mgr->name)
198 return -ENODEV;
199
200 seq_printf(m, "DRM GPU VA space (%s) [0x%016llx;0x%016llx]\n",
201 mgr->name, mgr->mm_start, mgr->mm_start +
mgr->mm_range);
202 seq_printf(m, "Kernel reserved node [0x%016llx;0x%016llx]\n",
203 kva->va.addr, kva->va.addr + kva->va.range);
204 seq_puts(m, "\n");
205 seq_puts(m, " VAs | start | range |
end| object | object offset\n");
206 seq_puts(m,
"-\n");
207 drm_gpuva_iter_for_each(va, it) {
208 if (unlikely(va == >kernel_alloc_node))
209 continue;
210
211 seq_printf(m, " | 0x%016llx | 0x%016llx | 0x%016llx
| 0x%016llx | 0x%016llx\n",
212 va->va.addr, va->va.range, va->va.addr +
va->va.range,
> 213 (u64)va->gem.obj, va->gem.offset);
214 }
215
216 return 0;
217 }
218 EXPORT_SYMBOL(drm_debugfs_gpuva_info);
219
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [Freedreno] [RFC PATCH v2 10/13] drm/msm/dpu: add list of supported formats to the DPU caps
On 07/06/2023 02:14, Abhinav Kumar wrote:
On 6/6/2023 3:59 PM, Dmitry Baryshkov wrote:
On 07/06/2023 01:57, Abhinav Kumar wrote:
On 6/6/2023 3:50 PM, Dmitry Baryshkov wrote:
On 07/06/2023 01:47, Abhinav Kumar wrote:
On 6/6/2023 2:52 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:47, Abhinav Kumar wrote:
On 6/6/2023 2:29 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:14, Abhinav Kumar wrote:
On 5/24/2023 6:47 PM, Dmitry Baryshkov wrote:
On Thu, 25 May 2023 at 02:16, Abhinav Kumar
wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
As we are going to add virtual planes, add the list of
supported formats
to the hw catalog entry. It will be used to setup universal
planes, with
later selecting a pipe depending on whether the YUV format
is used for
the framebuffer.
If your usage of format_list is going to be internal to
dpu_plane.c, I
can think of another idea for this change.
This essentially translates to if (num_vig >= 1)
If we can just have a small helper to detect that from the
catalog can
we use that instead of adding formats to the dpu caps?
I'd prefer to be explicit here. The list of supported formats
might
vary between generations, might it not? Also we don't have a
case of
the devices not having VIG planes. Even the qcm2290 (which
doesn't
have CSC) lists YUV as supported.
the list of formats is tied to the sspps the dpu generation has
and the capabilities of those sspps.
qcm2290 is really an interesting case. It has one vig sspp but
no csc block for that vig sspp, hence it cannot support non-RGB
formats.
I have confirmed that downstream is incorrect to populate yuv
formats for qcm2290.
I still think that having atleast one vig sspp with csc sub-blk
is the right condition to check if we want to decide if the dpu
for that chipset supports yuv formats. Extra csc-blk check to
handle qcm2290.
Having a small helper in dpu_plane.c is good enough for that
because with virtual planes, you only need to know "if such a
plane exists and not which plane" and a full catalog change
isnt needed IMO
This goes down to the question: is the list of YUV and non-YUV
formats static or not? Do all DPU devices support the same set
of YUV and non-YUV formats? If it is static, we might as well
drop dpu_sspp_sub_blks::format_list.
I would say yes based on the below reference:
https://git.codelinaro.org/clo/la/platform/vendor/opensource/display-drivers/-/blob/clo/main/msm/sde/sde_hw_catalog.c#L3858
We always add the same set of YUV formats for all Vig SSPPs
irrespective of the chipsets.
Well, as your example pointed out, few lines below it starts
adding formats to the list, so the format list is not static and
depends on the generation.
No, the DPU revision checks are there to add P010 UBWC formats on
top of the Vig formats.
At the moment, the latest downstream code (code which is not on CLO
hence I cannot share) has dropped all that and just checks if P010
UBWC is supported for the Vig SSPP and adds all those.
So its still tied to the feature bit whether P010 UBWC is supported
in the Vig SSPP and not at the chipset level.
So, what is the difference? This means that depending on some
conditions either we can support P010 UBWC or we can not. So the
list of all suppored formats is not static.
The difference is SSPP level vs chipset level. This patch was made
with chipset level in mind and had to expand the format list for each
chipset.
What I am suggesting is its a SSPP level decision. Please note its
not just P010 UBWC but P010 UBWC FOR Vig SSPP.
So expanding each chipset's format list is not needed when the
decision can be made just on the basis of the SSPP's feature flag OR
the presence of the csc blk.
Maybe I misunderstand something. Is P010 UBWC format supported on VIG
SSPPs on all generations? The code that you have pointed me suggests
that is is not.
No, your understanding is correct that P010 UBWC format is supported
only on Vig SSPPs of certain generations.
But my point is that, its still a SSPP level decision.
So even if we add P010 UBWC formats later to the list of supported
formats, what we will do is add that feature bit alone in the Vig SSPP's
feature mask of that chipset and based on that all the P010 UBWC formats
for the virtual planes.
But if we follow your approach, we will add another array called
plane_formats_p010_ubwc and add that to each chipset which will support it.
sspp->sblk->formats_list is constant, so we will have to add another
formats array anyway.
The only difference in idea is that, based on the SSPP's feature set of
that chipset we can still determine that Vs adding it to each chipset.
Note to myself: consider
dpu_mdss_cfg::{dma_formats,cursor_formats,vig_formats}. Either
migrate dpu_sspp_sub_blks::format_list users to these fields or
drop them.
Yes, I agree. There is no need to have format list in the sub_blk
as for one type of SSPP, it supports the
Re: [Freedreno] [RFC PATCH v2 10/13] drm/msm/dpu: add list of supported formats to the DPU caps
On 6/6/2023 3:59 PM, Dmitry Baryshkov wrote:
On 07/06/2023 01:57, Abhinav Kumar wrote:
On 6/6/2023 3:50 PM, Dmitry Baryshkov wrote:
On 07/06/2023 01:47, Abhinav Kumar wrote:
On 6/6/2023 2:52 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:47, Abhinav Kumar wrote:
On 6/6/2023 2:29 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:14, Abhinav Kumar wrote:
On 5/24/2023 6:47 PM, Dmitry Baryshkov wrote:
On Thu, 25 May 2023 at 02:16, Abhinav Kumar
wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
As we are going to add virtual planes, add the list of
supported formats
to the hw catalog entry. It will be used to setup universal
planes, with
later selecting a pipe depending on whether the YUV format is
used for
the framebuffer.
If your usage of format_list is going to be internal to
dpu_plane.c, I
can think of another idea for this change.
This essentially translates to if (num_vig >= 1)
If we can just have a small helper to detect that from the
catalog can
we use that instead of adding formats to the dpu caps?
I'd prefer to be explicit here. The list of supported formats
might
vary between generations, might it not? Also we don't have a
case of
the devices not having VIG planes. Even the qcm2290 (which doesn't
have CSC) lists YUV as supported.
the list of formats is tied to the sspps the dpu generation has
and the capabilities of those sspps.
qcm2290 is really an interesting case. It has one vig sspp but
no csc block for that vig sspp, hence it cannot support non-RGB
formats.
I have confirmed that downstream is incorrect to populate yuv
formats for qcm2290.
I still think that having atleast one vig sspp with csc sub-blk
is the right condition to check if we want to decide if the dpu
for that chipset supports yuv formats. Extra csc-blk check to
handle qcm2290.
Having a small helper in dpu_plane.c is good enough for that
because with virtual planes, you only need to know "if such a
plane exists and not which plane" and a full catalog change isnt
needed IMO
This goes down to the question: is the list of YUV and non-YUV
formats static or not? Do all DPU devices support the same set of
YUV and non-YUV formats? If it is static, we might as well drop
dpu_sspp_sub_blks::format_list.
I would say yes based on the below reference:
https://git.codelinaro.org/clo/la/platform/vendor/opensource/display-drivers/-/blob/clo/main/msm/sde/sde_hw_catalog.c#L3858
We always add the same set of YUV formats for all Vig SSPPs
irrespective of the chipsets.
Well, as your example pointed out, few lines below it starts adding
formats to the list, so the format list is not static and depends
on the generation.
No, the DPU revision checks are there to add P010 UBWC formats on
top of the Vig formats.
At the moment, the latest downstream code (code which is not on CLO
hence I cannot share) has dropped all that and just checks if P010
UBWC is supported for the Vig SSPP and adds all those.
So its still tied to the feature bit whether P010 UBWC is supported
in the Vig SSPP and not at the chipset level.
So, what is the difference? This means that depending on some
conditions either we can support P010 UBWC or we can not. So the list
of all suppored formats is not static.
The difference is SSPP level vs chipset level. This patch was made
with chipset level in mind and had to expand the format list for each
chipset.
What I am suggesting is its a SSPP level decision. Please note its not
just P010 UBWC but P010 UBWC FOR Vig SSPP.
So expanding each chipset's format list is not needed when the
decision can be made just on the basis of the SSPP's feature flag OR
the presence of the csc blk.
Maybe I misunderstand something. Is P010 UBWC format supported on VIG
SSPPs on all generations? The code that you have pointed me suggests
that is is not.
No, your understanding is correct that P010 UBWC format is supported
only on Vig SSPPs of certain generations.
But my point is that, its still a SSPP level decision.
So even if we add P010 UBWC formats later to the list of supported
formats, what we will do is add that feature bit alone in the Vig SSPP's
feature mask of that chipset and based on that all the P010 UBWC formats
for the virtual planes.
But if we follow your approach, we will add another array called
plane_formats_p010_ubwc and add that to each chipset which will support it.
The only difference in idea is that, based on the SSPP's feature set of
that chipset we can still determine that Vs adding it to each chipset.
Note to myself: consider
dpu_mdss_cfg::{dma_formats,cursor_formats,vig_formats}. Either
migrate dpu_sspp_sub_blks::format_list users to these fields or
drop them.
Yes, I agree. There is no need to have format list in the sub_blk
as for one type of SSPP, it supports the same format across DPU
generations.
Note: I think at some point we should have a closer look at the
list
of supported formats and
Re: [Freedreno] [RFC PATCH v2 10/13] drm/msm/dpu: add list of supported formats to the DPU caps
On 07/06/2023 01:57, Abhinav Kumar wrote:
On 6/6/2023 3:50 PM, Dmitry Baryshkov wrote:
On 07/06/2023 01:47, Abhinav Kumar wrote:
On 6/6/2023 2:52 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:47, Abhinav Kumar wrote:
On 6/6/2023 2:29 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:14, Abhinav Kumar wrote:
On 5/24/2023 6:47 PM, Dmitry Baryshkov wrote:
On Thu, 25 May 2023 at 02:16, Abhinav Kumar
wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
As we are going to add virtual planes, add the list of
supported formats
to the hw catalog entry. It will be used to setup universal
planes, with
later selecting a pipe depending on whether the YUV format is
used for
the framebuffer.
If your usage of format_list is going to be internal to
dpu_plane.c, I
can think of another idea for this change.
This essentially translates to if (num_vig >= 1)
If we can just have a small helper to detect that from the
catalog can
we use that instead of adding formats to the dpu caps?
I'd prefer to be explicit here. The list of supported formats might
vary between generations, might it not? Also we don't have a
case of
the devices not having VIG planes. Even the qcm2290 (which doesn't
have CSC) lists YUV as supported.
the list of formats is tied to the sspps the dpu generation has
and the capabilities of those sspps.
qcm2290 is really an interesting case. It has one vig sspp but no
csc block for that vig sspp, hence it cannot support non-RGB
formats.
I have confirmed that downstream is incorrect to populate yuv
formats for qcm2290.
I still think that having atleast one vig sspp with csc sub-blk
is the right condition to check if we want to decide if the dpu
for that chipset supports yuv formats. Extra csc-blk check to
handle qcm2290.
Having a small helper in dpu_plane.c is good enough for that
because with virtual planes, you only need to know "if such a
plane exists and not which plane" and a full catalog change isnt
needed IMO
This goes down to the question: is the list of YUV and non-YUV
formats static or not? Do all DPU devices support the same set of
YUV and non-YUV formats? If it is static, we might as well drop
dpu_sspp_sub_blks::format_list.
I would say yes based on the below reference:
https://git.codelinaro.org/clo/la/platform/vendor/opensource/display-drivers/-/blob/clo/main/msm/sde/sde_hw_catalog.c#L3858
We always add the same set of YUV formats for all Vig SSPPs
irrespective of the chipsets.
Well, as your example pointed out, few lines below it starts adding
formats to the list, so the format list is not static and depends on
the generation.
No, the DPU revision checks are there to add P010 UBWC formats on top
of the Vig formats.
At the moment, the latest downstream code (code which is not on CLO
hence I cannot share) has dropped all that and just checks if P010
UBWC is supported for the Vig SSPP and adds all those.
So its still tied to the feature bit whether P010 UBWC is supported
in the Vig SSPP and not at the chipset level.
So, what is the difference? This means that depending on some
conditions either we can support P010 UBWC or we can not. So the list
of all suppored formats is not static.
The difference is SSPP level vs chipset level. This patch was made with
chipset level in mind and had to expand the format list for each chipset.
What I am suggesting is its a SSPP level decision. Please note its not
just P010 UBWC but P010 UBWC FOR Vig SSPP.
So expanding each chipset's format list is not needed when the decision
can be made just on the basis of the SSPP's feature flag OR the presence
of the csc blk.
Maybe I misunderstand something. Is P010 UBWC format supported on VIG
SSPPs on all generations? The code that you have pointed me suggests
that is is not.
Note to myself: consider
dpu_mdss_cfg::{dma_formats,cursor_formats,vig_formats}. Either
migrate dpu_sspp_sub_blks::format_list users to these fields or
drop them.
Yes, I agree. There is no need to have format list in the sub_blk
as for one type of SSPP, it supports the same format across DPU
generations.
Note: I think at some point we should have a closer look at the
list
of supported formats and crosscheck that we do not have either
unsupported formats being listed, or missing formats which are not
listed as supported.
--
With best wishes
Dmitry
Re: [PATCH net-next v6 3/6] net: bcmasp: Add support for ASP2.0 Ethernet controller
On 6/2/23 11:58 PM, Jakub Kicinski wrote:
On Thu, 1 Jun 2023 15:12:28 -0700 Justin Chen wrote:
+ /* general stats */
+ STAT_NETDEV(rx_packets),
+ STAT_NETDEV(tx_packets),
+ STAT_NETDEV(rx_bytes),
+ STAT_NETDEV(tx_bytes),
+ STAT_NETDEV(rx_errors),
+ STAT_NETDEV(tx_errors),
+ STAT_NETDEV(rx_dropped),
+ STAT_NETDEV(tx_dropped),
+ STAT_NETDEV(multicast),
please don't report standard interface stats in ethtool -S
These are not netdev statistics but MAC block counters. Guess it is not
clear with the naming here, will fix this. We have a use case where the
MAC traffic may be redirected from the associated net dev, so the
counters may not be the same.
+ /* UniMAC RSV counters */
+ STAT_BCMASP_MIB_RX("rx_64_octets", mib.rx.pkt_cnt.cnt_64),
+ STAT_BCMASP_MIB_RX("rx_65_127_oct", mib.rx.pkt_cnt.cnt_127),
+ STAT_BCMASP_MIB_RX("rx_128_255_oct", mib.rx.pkt_cnt.cnt_255),
+ STAT_BCMASP_MIB_RX("rx_256_511_oct", mib.rx.pkt_cnt.cnt_511),
+ STAT_BCMASP_MIB_RX("rx_512_1023_oct", mib.rx.pkt_cnt.cnt_1023),
+ STAT_BCMASP_MIB_RX("rx_1024_1518_oct", mib.rx.pkt_cnt.cnt_1518),
+ STAT_BCMASP_MIB_RX("rx_vlan_1519_1522_oct", mib.rx.pkt_cnt.cnt_mgv),
+ STAT_BCMASP_MIB_RX("rx_1522_2047_oct", mib.rx.pkt_cnt.cnt_2047),
+ STAT_BCMASP_MIB_RX("rx_2048_4095_oct", mib.rx.pkt_cnt.cnt_4095),
+ STAT_BCMASP_MIB_RX("rx_4096_9216_oct", mib.rx.pkt_cnt.cnt_9216),
these should also be removed, and you should implement @get_rmon_stats.
+ STAT_BCMASP_MIB_RX("rx_pkts", mib.rx.pkt),
+ STAT_BCMASP_MIB_RX("rx_bytes", mib.rx.bytes),
+ STAT_BCMASP_MIB_RX("rx_multicast", mib.rx.mca),
+ STAT_BCMASP_MIB_RX("rx_broadcast", mib.rx.bca),
+ STAT_BCMASP_MIB_RX("rx_fcs", mib.rx.fcs),
there's a FCS error statistic in the standard stats, no need to
duplicate
Same comment as above
+ STAT_BCMASP_MIB_RX("rx_control", mib.rx.cf),
+ STAT_BCMASP_MIB_RX("rx_pause", mib.rx.pf),
@get_pause_stats
+ STAT_BCMASP_MIB_RX("rx_unknown", mib.rx.uo),
+ STAT_BCMASP_MIB_RX("rx_align", mib.rx.aln),
+ STAT_BCMASP_MIB_RX("rx_outrange", mib.rx.flr),
+ STAT_BCMASP_MIB_RX("rx_code", mib.rx.cde),
+ STAT_BCMASP_MIB_RX("rx_carrier", mib.rx.fcr),
+ STAT_BCMASP_MIB_RX("rx_oversize", mib.rx.ovr),
+ STAT_BCMASP_MIB_RX("rx_jabber", mib.rx.jbr),
these look like candidates from standard stats, too.
Please read thru:
https://docs.kernel.org/next/networking/statistics.html
Looks like the way we are doing stats are a bit outdated. Thanks for
pointing it out. I got a bit of refactoring to do.
+ STAT_BCMASP_MIB_RX("rx_mtu_err", mib.rx.mtue),
+ STAT_BCMASP_MIB_RX("rx_good_pkts", mib.rx.pok),
+ STAT_BCMASP_MIB_RX("rx_unicast", mib.rx.uc),
+ STAT_BCMASP_MIB_RX("rx_ppp", mib.rx.ppp),
+ STAT_BCMASP_MIB_RX("rx_crc", mib.rx.rcrc),
hm, what's the difference between rx_crc and rx_fcs ?
This looks like some debug feature that really has nothing to do with
verifying crcs. I will remove it.
Apologies, probably should have done my due diligence with each stats
instead of blindly including everything.
Thanks,
Justin
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Freedreno] [RFC PATCH v2 10/13] drm/msm/dpu: add list of supported formats to the DPU caps
On 6/6/2023 3:50 PM, Dmitry Baryshkov wrote:
On 07/06/2023 01:47, Abhinav Kumar wrote:
On 6/6/2023 2:52 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:47, Abhinav Kumar wrote:
On 6/6/2023 2:29 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:14, Abhinav Kumar wrote:
On 5/24/2023 6:47 PM, Dmitry Baryshkov wrote:
On Thu, 25 May 2023 at 02:16, Abhinav Kumar
wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
As we are going to add virtual planes, add the list of
supported formats
to the hw catalog entry. It will be used to setup universal
planes, with
later selecting a pipe depending on whether the YUV format is
used for
the framebuffer.
If your usage of format_list is going to be internal to
dpu_plane.c, I
can think of another idea for this change.
This essentially translates to if (num_vig >= 1)
If we can just have a small helper to detect that from the
catalog can
we use that instead of adding formats to the dpu caps?
I'd prefer to be explicit here. The list of supported formats might
vary between generations, might it not? Also we don't have a case of
the devices not having VIG planes. Even the qcm2290 (which doesn't
have CSC) lists YUV as supported.
the list of formats is tied to the sspps the dpu generation has
and the capabilities of those sspps.
qcm2290 is really an interesting case. It has one vig sspp but no
csc block for that vig sspp, hence it cannot support non-RGB formats.
I have confirmed that downstream is incorrect to populate yuv
formats for qcm2290.
I still think that having atleast one vig sspp with csc sub-blk is
the right condition to check if we want to decide if the dpu for
that chipset supports yuv formats. Extra csc-blk check to handle
qcm2290.
Having a small helper in dpu_plane.c is good enough for that
because with virtual planes, you only need to know "if such a
plane exists and not which plane" and a full catalog change isnt
needed IMO
This goes down to the question: is the list of YUV and non-YUV
formats static or not? Do all DPU devices support the same set of
YUV and non-YUV formats? If it is static, we might as well drop
dpu_sspp_sub_blks::format_list.
I would say yes based on the below reference:
https://git.codelinaro.org/clo/la/platform/vendor/opensource/display-drivers/-/blob/clo/main/msm/sde/sde_hw_catalog.c#L3858
We always add the same set of YUV formats for all Vig SSPPs
irrespective of the chipsets.
Well, as your example pointed out, few lines below it starts adding
formats to the list, so the format list is not static and depends on
the generation.
No, the DPU revision checks are there to add P010 UBWC formats on top
of the Vig formats.
At the moment, the latest downstream code (code which is not on CLO
hence I cannot share) has dropped all that and just checks if P010
UBWC is supported for the Vig SSPP and adds all those.
So its still tied to the feature bit whether P010 UBWC is supported in
the Vig SSPP and not at the chipset level.
So, what is the difference? This means that depending on some conditions
either we can support P010 UBWC or we can not. So the list of all
suppored formats is not static.
The difference is SSPP level vs chipset level. This patch was made with
chipset level in mind and had to expand the format list for each chipset.
What I am suggesting is its a SSPP level decision. Please note its not
just P010 UBWC but P010 UBWC FOR Vig SSPP.
So expanding each chipset's format list is not needed when the decision
can be made just on the basis of the SSPP's feature flag OR the presence
of the csc blk.
Note to myself: consider
dpu_mdss_cfg::{dma_formats,cursor_formats,vig_formats}. Either
migrate dpu_sspp_sub_blks::format_list users to these fields or
drop them.
Yes, I agree. There is no need to have format list in the sub_blk as
for one type of SSPP, it supports the same format across DPU
generations.
Note: I think at some point we should have a closer look at the list
of supported formats and crosscheck that we do not have either
unsupported formats being listed, or missing formats which are not
listed as supported.
Re: [RFC PATCH v2 10/13] drm/msm/dpu: add list of supported formats to the DPU caps
On 07/06/2023 01:47, Abhinav Kumar wrote:
On 6/6/2023 2:52 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:47, Abhinav Kumar wrote:
On 6/6/2023 2:29 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:14, Abhinav Kumar wrote:
On 5/24/2023 6:47 PM, Dmitry Baryshkov wrote:
On Thu, 25 May 2023 at 02:16, Abhinav Kumar
wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
As we are going to add virtual planes, add the list of supported
formats
to the hw catalog entry. It will be used to setup universal
planes, with
later selecting a pipe depending on whether the YUV format is
used for
the framebuffer.
If your usage of format_list is going to be internal to
dpu_plane.c, I
can think of another idea for this change.
This essentially translates to if (num_vig >= 1)
If we can just have a small helper to detect that from the
catalog can
we use that instead of adding formats to the dpu caps?
I'd prefer to be explicit here. The list of supported formats might
vary between generations, might it not? Also we don't have a case of
the devices not having VIG planes. Even the qcm2290 (which doesn't
have CSC) lists YUV as supported.
the list of formats is tied to the sspps the dpu generation has and
the capabilities of those sspps.
qcm2290 is really an interesting case. It has one vig sspp but no
csc block for that vig sspp, hence it cannot support non-RGB formats.
I have confirmed that downstream is incorrect to populate yuv
formats for qcm2290.
I still think that having atleast one vig sspp with csc sub-blk is
the right condition to check if we want to decide if the dpu for
that chipset supports yuv formats. Extra csc-blk check to handle
qcm2290.
Having a small helper in dpu_plane.c is good enough for that
because with virtual planes, you only need to know "if such a plane
exists and not which plane" and a full catalog change isnt needed IMO
This goes down to the question: is the list of YUV and non-YUV
formats static or not? Do all DPU devices support the same set of
YUV and non-YUV formats? If it is static, we might as well drop
dpu_sspp_sub_blks::format_list.
I would say yes based on the below reference:
https://git.codelinaro.org/clo/la/platform/vendor/opensource/display-drivers/-/blob/clo/main/msm/sde/sde_hw_catalog.c#L3858
We always add the same set of YUV formats for all Vig SSPPs
irrespective of the chipsets.
Well, as your example pointed out, few lines below it starts adding
formats to the list, so the format list is not static and depends on
the generation.
No, the DPU revision checks are there to add P010 UBWC formats on top of
the Vig formats.
At the moment, the latest downstream code (code which is not on CLO
hence I cannot share) has dropped all that and just checks if P010 UBWC
is supported for the Vig SSPP and adds all those.
So its still tied to the feature bit whether P010 UBWC is supported in
the Vig SSPP and not at the chipset level.
So, what is the difference? This means that depending on some conditions
either we can support P010 UBWC or we can not. So the list of all
suppored formats is not static.
Note to myself: consider
dpu_mdss_cfg::{dma_formats,cursor_formats,vig_formats}. Either
migrate dpu_sspp_sub_blks::format_list users to these fields or drop
them.
Yes, I agree. There is no need to have format list in the sub_blk as
for one type of SSPP, it supports the same format across DPU
generations.
Note: I think at some point we should have a closer look at the list
of supported formats and crosscheck that we do not have either
unsupported formats being listed, or missing formats which are not
listed as supported.
--
With best wishes
Dmitry
Re: [RFC PATCH v2 10/13] drm/msm/dpu: add list of supported formats to the DPU caps
On 6/6/2023 2:52 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:47, Abhinav Kumar wrote:
On 6/6/2023 2:29 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:14, Abhinav Kumar wrote:
On 5/24/2023 6:47 PM, Dmitry Baryshkov wrote:
On Thu, 25 May 2023 at 02:16, Abhinav Kumar
wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
As we are going to add virtual planes, add the list of supported
formats
to the hw catalog entry. It will be used to setup universal
planes, with
later selecting a pipe depending on whether the YUV format is
used for
the framebuffer.
If your usage of format_list is going to be internal to
dpu_plane.c, I
can think of another idea for this change.
This essentially translates to if (num_vig >= 1)
If we can just have a small helper to detect that from the catalog
can
we use that instead of adding formats to the dpu caps?
I'd prefer to be explicit here. The list of supported formats might
vary between generations, might it not? Also we don't have a case of
the devices not having VIG planes. Even the qcm2290 (which doesn't
have CSC) lists YUV as supported.
the list of formats is tied to the sspps the dpu generation has and
the capabilities of those sspps.
qcm2290 is really an interesting case. It has one vig sspp but no
csc block for that vig sspp, hence it cannot support non-RGB formats.
I have confirmed that downstream is incorrect to populate yuv
formats for qcm2290.
I still think that having atleast one vig sspp with csc sub-blk is
the right condition to check if we want to decide if the dpu for
that chipset supports yuv formats. Extra csc-blk check to handle
qcm2290.
Having a small helper in dpu_plane.c is good enough for that because
with virtual planes, you only need to know "if such a plane exists
and not which plane" and a full catalog change isnt needed IMO
This goes down to the question: is the list of YUV and non-YUV
formats static or not? Do all DPU devices support the same set of YUV
and non-YUV formats? If it is static, we might as well drop
dpu_sspp_sub_blks::format_list.
I would say yes based on the below reference:
https://git.codelinaro.org/clo/la/platform/vendor/opensource/display-drivers/-/blob/clo/main/msm/sde/sde_hw_catalog.c#L3858
We always add the same set of YUV formats for all Vig SSPPs
irrespective of the chipsets.
Well, as your example pointed out, few lines below it starts adding
formats to the list, so the format list is not static and depends on the
generation.
No, the DPU revision checks are there to add P010 UBWC formats on top of
the Vig formats.
At the moment, the latest downstream code (code which is not on CLO
hence I cannot share) has dropped all that and just checks if P010 UBWC
is supported for the Vig SSPP and adds all those.
So its still tied to the feature bit whether P010 UBWC is supported in
the Vig SSPP and not at the chipset level.
Note to myself: consider
dpu_mdss_cfg::{dma_formats,cursor_formats,vig_formats}. Either
migrate dpu_sspp_sub_blks::format_list users to these fields or drop
them.
Yes, I agree. There is no need to have format list in the sub_blk as
for one type of SSPP, it supports the same format across DPU generations.
Note: I think at some point we should have a closer look at the list
of supported formats and crosscheck that we do not have either
unsupported formats being listed, or missing formats which are not
listed as supported.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 26
+++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 +++
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 212d546b6c5d..2d6944a9679a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -315,6 +315,8 @@ static const struct dpu_caps msm8998_dpu_caps
= {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps qcm2290_dpu_caps = {
@@ -324,6 +326,8 @@ static const struct dpu_caps qcm2290_dpu_caps
= {
.has_idle_pc = true,
.max_linewidth = 2160,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sdm845_dpu_caps = {
@@ -339,6 +343,8 @@ static const struct dpu_caps sdm845_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sc7180_dpu_caps = {
@@ -350,6 +356,8
Re: [PATCH 1/9] dt-bindings: display: Add yamls for JH7110 display subsystem
On Wed, Jun 07, 2023 at 12:22:33AM +0200, Heiko Stübner wrote: > Am Dienstag, 6. Juni 2023, 20:41:17 CEST schrieb Shengyu Qu: > > > On Fri, Jun 02, 2023 at 03:40:35PM +0800, Keith Zhao wrote: > > >> Add bindings for JH7110 display subsystem which > > >> has a display controller verisilicon dc8200 > > >> and an HDMI interface. > > >> +description: > > >> + The StarFive SoC uses the HDMI signal transmiter based on innosilicon > > >> IP > > > Is innosilicon the same thing as verisilicon? Also > > > s/transmiter/transmitter/, both here and in the title. > > > > I think that is not the same, I remember Rockchip has used a HDMI > > transmitter from > > > > Innosilicon, and there is a existing driver for that in mainline. > > Yep, I think Innosilicon is the company you turn to when you want to save > a bit of money ;-) . In the bigger SoCs Rockchip most of the time uses > Designware hdmi blocks and looking at the history only the rk3036 ever > used an Innosilicon block. > > Looking at the history, 2016 really was a long time ago :-D. > > > So Keith, if that's true, I think it is better to seperate the HDMI > > stuff and reuse existing driver. > > I'm not so sure about that - at least from a cursory glance :-) . > > The registers do look slightly different and I don't know how much > the IP changed between the rk3036-version and the jh7110 version. > > At the very least, I know my rk3036 board isn't booting right now, so > I can't really provide help for generalizing the rockchip-driver. > > At the very least both the binding and driver could drop the "starfive-hdmi" > and actually use the Innosilicon in the naming somewhere, so that it's > clear for future developers :-) Seeing "based on" always makes me a little bit nervous to be honest when it comes to using a compatible from the IP. Is it the IP? What version is it? etc. Perhaps "starfive,jh7110-hdmi" & falling back to some sort of "innosilicon,hdmi" would be more future/IP-silliness proof. Driver can always be generic & bind against "innosilicon,hdmi" until that becomes impossible. Cheers, Conor. signature.asc Description: PGP signature
[PATCH drm-next v4 14/14] drm/nouveau: debugfs: implement DRM GPU VA debugfs
Provide the driver indirection iterating over all DRM GPU VA spaces to
enable the common 'gpuvas' debugfs file for dumping DRM GPU VA spaces.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 99d022a91afc..053f703f2f68 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -203,6 +203,44 @@ nouveau_debugfs_pstate_open(struct inode *inode, struct
file *file)
return single_open(file, nouveau_debugfs_pstate_get, inode->i_private);
}
+static void
+nouveau_debugfs_gpuva_regions(struct seq_file *m, struct nouveau_uvmm *uvmm)
+{
+ MA_STATE(mas, >region_mt, 0, 0);
+ struct nouveau_uvma_region *reg;
+
+ seq_puts (m, " VA regions | start | range |
end\n");
+ seq_puts (m,
"\n");
+ mas_for_each(, reg, ULONG_MAX)
+ seq_printf(m, " | 0x%016llx | 0x%016llx |
0x%016llx\n",
+ reg->va.addr, reg->va.range, reg->va.addr +
reg->va.range);
+}
+
+static int
+nouveau_debugfs_gpuva(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = (struct drm_info_node *) m->private;
+ struct nouveau_drm *drm = nouveau_drm(node->minor->dev);
+ struct nouveau_cli *cli;
+
+ mutex_lock(>clients_lock);
+ list_for_each_entry(cli, >clients, head) {
+ struct nouveau_uvmm *uvmm = nouveau_cli_uvmm(cli);
+
+ if (!uvmm)
+ continue;
+
+ nouveau_uvmm_lock(uvmm);
+ drm_debugfs_gpuva_info(m, >umgr);
+ seq_puts(m, "\n");
+ nouveau_debugfs_gpuva_regions(m, uvmm);
+ nouveau_uvmm_unlock(uvmm);
+ }
+ mutex_unlock(>clients_lock);
+
+ return 0;
+}
+
static const struct file_operations nouveau_pstate_fops = {
.owner = THIS_MODULE,
.open = nouveau_debugfs_pstate_open,
@@ -214,6 +252,7 @@ static const struct file_operations nouveau_pstate_fops = {
static struct drm_info_list nouveau_debugfs_list[] = {
{ "vbios.rom", nouveau_debugfs_vbios_image, 0, NULL },
{ "strap_peek", nouveau_debugfs_strap_peek, 0, NULL },
+ DRM_DEBUGFS_GPUVA_INFO(nouveau_debugfs_gpuva, NULL),
};
#define NOUVEAU_DEBUGFS_ENTRIES ARRAY_SIZE(nouveau_debugfs_list)
--
2.40.1
[PATCH drm-next v4 13/14] drm/nouveau: implement new VM_BIND uAPI
This commit provides the implementation for the new uapi motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU virtual address (VA) space via the new
DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the portion of VA
space managed by the kernel and userspace, respectively.
2) Allocate and free a VA space region as well as bind and unbind memory
to the GPUs VA space via the new DRM_IOCTL_NOUVEAU_VM_BIND ioctl.
UMDs can request the named operations to be processed either
synchronously or asynchronously. It supports DRM syncobjs
(incl. timelines) as synchronization mechanism. The management of the
GPU VA mappings is implemented with the DRM GPU VA manager.
3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl. The
execution happens asynchronously. It supports DRM syncobj (incl.
timelines) as synchronization mechanism. DRM GEM object locking is
handled with drm_exec.
Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC, use the DRM
GPU scheduler for the asynchronous paths.
Signed-off-by: Danilo Krummrich
---
Documentation/gpu/driver-uapi.rst |3 +
drivers/gpu/drm/nouveau/Kbuild |3 +
drivers/gpu/drm/nouveau/Kconfig |2 +
drivers/gpu/drm/nouveau/nouveau_abi16.c | 24 +
drivers/gpu/drm/nouveau/nouveau_abi16.h |1 +
drivers/gpu/drm/nouveau/nouveau_bo.c| 147 +-
drivers/gpu/drm/nouveau/nouveau_bo.h|2 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 27 +-
drivers/gpu/drm/nouveau/nouveau_drv.h | 59 +-
drivers/gpu/drm/nouveau/nouveau_exec.c | 418 +
drivers/gpu/drm/nouveau/nouveau_exec.h | 54 +
drivers/gpu/drm/nouveau/nouveau_gem.c | 25 +-
drivers/gpu/drm/nouveau/nouveau_mem.h |5 +
drivers/gpu/drm/nouveau/nouveau_prime.c |2 +-
drivers/gpu/drm/nouveau/nouveau_sched.c | 461 ++
drivers/gpu/drm/nouveau/nouveau_sched.h | 123 ++
drivers/gpu/drm/nouveau/nouveau_uvmm.c | 1898 +++
drivers/gpu/drm/nouveau/nouveau_uvmm.h | 107 ++
18 files changed, 3296 insertions(+), 65 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/nouveau_exec.c
create mode 100644 drivers/gpu/drm/nouveau/nouveau_exec.h
create mode 100644 drivers/gpu/drm/nouveau/nouveau_sched.c
create mode 100644 drivers/gpu/drm/nouveau/nouveau_sched.h
create mode 100644 drivers/gpu/drm/nouveau/nouveau_uvmm.c
create mode 100644 drivers/gpu/drm/nouveau/nouveau_uvmm.h
diff --git a/Documentation/gpu/driver-uapi.rst
b/Documentation/gpu/driver-uapi.rst
index 9c7ca6e33a68..c08bcbb95fb3 100644
--- a/Documentation/gpu/driver-uapi.rst
+++ b/Documentation/gpu/driver-uapi.rst
@@ -13,4 +13,7 @@ drm/nouveau uAPI
VM_BIND / EXEC uAPI
---
+.. kernel-doc:: drivers/gpu/drm/nouveau/nouveau_exec.c
+:doc: Overview
+
.. kernel-doc:: include/uapi/drm/nouveau_drm.h
diff --git a/drivers/gpu/drm/nouveau/Kbuild b/drivers/gpu/drm/nouveau/Kbuild
index 5e5617006da5..cf6b3a80c0c8 100644
--- a/drivers/gpu/drm/nouveau/Kbuild
+++ b/drivers/gpu/drm/nouveau/Kbuild
@@ -47,6 +47,9 @@ nouveau-y += nouveau_prime.o
nouveau-y += nouveau_sgdma.o
nouveau-y += nouveau_ttm.o
nouveau-y += nouveau_vmm.o
+nouveau-y += nouveau_exec.o
+nouveau-y += nouveau_sched.o
+nouveau-y += nouveau_uvmm.o
# DRM - modesetting
nouveau-$(CONFIG_DRM_NOUVEAU_BACKLIGHT) += nouveau_backlight.o
diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig
index a70bd65e1400..c52e8096cca4 100644
--- a/drivers/gpu/drm/nouveau/Kconfig
+++ b/drivers/gpu/drm/nouveau/Kconfig
@@ -10,6 +10,8 @@ config DRM_NOUVEAU
select DRM_KMS_HELPER
select DRM_TTM
select DRM_TTM_HELPER
+ select DRM_EXEC
+ select DRM_SCHED
select I2C
select I2C_ALGOBIT
select BACKLIGHT_CLASS_DEVICE if DRM_NOUVEAU_BACKLIGHT
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 82dab51d8aeb..a112f28681d3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -35,6 +35,7 @@
#include "nouveau_chan.h"
#include "nouveau_abi16.h"
#include "nouveau_vmm.h"
+#include "nouveau_sched.h"
static struct nouveau_abi16 *
nouveau_abi16(struct drm_file *file_priv)
@@ -125,6 +126,17 @@ nouveau_abi16_chan_fini(struct nouveau_abi16 *abi16,
{
struct nouveau_abi16_ntfy *ntfy, *temp;
+ /* When a client exits without waiting for it's queued up jobs to
+* finish it might happen that we fault the channel. This is due to
+* drm_file_free() calling drm_gem_release() before the postclose()
+* callback. Hence, we can't tear down this scheduler entity before
+* uvmm mappings are unmapped. Currently, we can't detect this case.
+*
+* However, this should be rare and harmless, since the channel isn't
+* needed anymore.
+*/
+ nouveau_sched_entity_fini(>sched_entity);
+
/* wait for all activity to
[PATCH drm-next v4 12/14] drm/nouveau: nvkm/vmm: implement raw ops to manage uvmm
The new VM_BIND UAPI uses the DRM GPU VA manager to manage the VA space.
Hence, we a need a way to manipulate the MMUs page tables without going
through the internal range allocator implemented by nvkm/vmm.
This patch adds a raw interface for nvkm/vmm to pass the resposibility
for managing the address space and the corresponding map/unmap/sparse
operations to the upper layers.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 26 ++-
drivers/gpu/drm/nouveau/include/nvif/vmm.h| 19 +-
.../gpu/drm/nouveau/include/nvkm/subdev/mmu.h | 20 +-
drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_vmm.c | 4 +-
drivers/gpu/drm/nouveau/nvif/vmm.c| 100 +++-
.../gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c| 213 --
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 197
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 25 ++
.../drm/nouveau/nvkm/subdev/mmu/vmmgf100.c| 16 +-
.../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c| 16 +-
.../gpu/drm/nouveau/nvkm/subdev/mmu/vmmnv50.c | 27 ++-
12 files changed, 566 insertions(+), 99 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
index 9c7ff56831c5..a5a182b3c28d 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
@@ -3,7 +3,10 @@
struct nvif_vmm_v0 {
__u8 version;
__u8 page_nr;
- __u8 managed;
+#define NVIF_VMM_V0_TYPE_UNMANAGED 0x00
+#define NVIF_VMM_V0_TYPE_MANAGED 0x01
+#define NVIF_VMM_V0_TYPE_RAW 0x02
+ __u8 type;
__u8 pad03[5];
__u64 addr;
__u64 size;
@@ -17,6 +20,7 @@ struct nvif_vmm_v0 {
#define NVIF_VMM_V0_UNMAP 0x04
#define NVIF_VMM_V0_PFNMAP 0x05
#define NVIF_VMM_V0_PFNCLR 0x06
+#define NVIF_VMM_V0_RAW0x07
#define NVIF_VMM_V0_MTHD(i) ((i) +
0x80)
struct nvif_vmm_page_v0 {
@@ -66,6 +70,26 @@ struct nvif_vmm_unmap_v0 {
__u64 addr;
};
+struct nvif_vmm_raw_v0 {
+ __u8 version;
+#define NVIF_VMM_RAW_V0_GET0x0
+#define NVIF_VMM_RAW_V0_PUT0x1
+#define NVIF_VMM_RAW_V0_MAP0x2
+#define NVIF_VMM_RAW_V0_UNMAP 0x3
+#define NVIF_VMM_RAW_V0_SPARSE 0x4
+ __u8 op;
+ __u8 sparse;
+ __u8 ref;
+ __u8 shift;
+ __u32 argc;
+ __u8 pad01[7];
+ __u64 addr;
+ __u64 size;
+ __u64 offset;
+ __u64 memory;
+ __u64 argv;
+};
+
struct nvif_vmm_pfnmap_v0 {
__u8 version;
__u8 page;
diff --git a/drivers/gpu/drm/nouveau/include/nvif/vmm.h
b/drivers/gpu/drm/nouveau/include/nvif/vmm.h
index a2ee92201ace..0ecedd0ee0a5 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/vmm.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/vmm.h
@@ -4,6 +4,12 @@
struct nvif_mem;
struct nvif_mmu;
+enum nvif_vmm_type {
+ UNMANAGED,
+ MANAGED,
+ RAW,
+};
+
enum nvif_vmm_get {
ADDR,
PTES,
@@ -30,8 +36,9 @@ struct nvif_vmm {
int page_nr;
};
-int nvif_vmm_ctor(struct nvif_mmu *, const char *name, s32 oclass, bool
managed,
- u64 addr, u64 size, void *argv, u32 argc, struct nvif_vmm *);
+int nvif_vmm_ctor(struct nvif_mmu *, const char *name, s32 oclass,
+ enum nvif_vmm_type, u64 addr, u64 size, void *argv, u32 argc,
+ struct nvif_vmm *);
void nvif_vmm_dtor(struct nvif_vmm *);
int nvif_vmm_get(struct nvif_vmm *, enum nvif_vmm_get, bool sparse,
u8 page, u8 align, u64 size, struct nvif_vma *);
@@ -39,4 +46,12 @@ void nvif_vmm_put(struct nvif_vmm *, struct nvif_vma *);
int nvif_vmm_map(struct nvif_vmm *, u64 addr, u64 size, void *argv, u32 argc,
struct nvif_mem *, u64 offset);
int nvif_vmm_unmap(struct nvif_vmm *, u64);
+
+int nvif_vmm_raw_get(struct nvif_vmm *vmm, u64 addr, u64 size, u8 shift);
+int nvif_vmm_raw_put(struct nvif_vmm *vmm, u64 addr, u64 size, u8 shift);
+int nvif_vmm_raw_map(struct nvif_vmm *vmm, u64 addr, u64 size, u8 shift,
+void *argv, u32 argc, struct nvif_mem *mem, u64 offset);
+int nvif_vmm_raw_unmap(struct nvif_vmm *vmm, u64 addr, u64 size,
+ u8 shift, bool sparse);
+int nvif_vmm_raw_sparse(struct nvif_vmm *vmm, u64 addr, u64 size, bool ref);
#endif
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
index 70e7887ef4b4..2fd2f2433fc7 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
@@ -17,6 +17,7 @@
[PATCH drm-next v4 11/14] drm/nouveau: chan: provide nouveau_channel_kill()
The new VM_BIND UAPI implementation introduced in subsequent commits
will allow asynchronous jobs processing push buffers and emitting fences.
If a job times out, we need a way to recover from this situation. For
now, simply kill the channel to unblock all hung up jobs and signal
userspace that the device is dead on the next EXEC or VM_BIND ioctl.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_chan.c | 14 +++---
drivers/gpu/drm/nouveau/nouveau_chan.h | 1 +
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index f47c0363683c..a975f8b0e0e5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -40,6 +40,14 @@ MODULE_PARM_DESC(vram_pushbuf, "Create DMA push buffers in
VRAM");
int nouveau_vram_pushbuf;
module_param_named(vram_pushbuf, nouveau_vram_pushbuf, int, 0400);
+void
+nouveau_channel_kill(struct nouveau_channel *chan)
+{
+ atomic_set(>killed, 1);
+ if (chan->fence)
+ nouveau_fence_context_kill(chan->fence, -ENODEV);
+}
+
static int
nouveau_channel_killed(struct nvif_event *event, void *repv, u32 repc)
{
@@ -47,9 +55,9 @@ nouveau_channel_killed(struct nvif_event *event, void *repv,
u32 repc)
struct nouveau_cli *cli = (void *)chan->user.client;
NV_PRINTK(warn, cli, "channel %d killed!\n", chan->chid);
- atomic_set(>killed, 1);
- if (chan->fence)
- nouveau_fence_context_kill(chan->fence, -ENODEV);
+
+ if (unlikely(!atomic_read(>killed)))
+ nouveau_channel_kill(chan);
return NVIF_EVENT_DROP;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.h
b/drivers/gpu/drm/nouveau/nouveau_chan.h
index e06a8ffed31a..e483f4a254da 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.h
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.h
@@ -65,6 +65,7 @@ int nouveau_channel_new(struct nouveau_drm *, struct
nvif_device *, bool priv,
u32 vram, u32 gart, struct nouveau_channel **);
void nouveau_channel_del(struct nouveau_channel **);
int nouveau_channel_idle(struct nouveau_channel *);
+void nouveau_channel_kill(struct nouveau_channel *);
extern int nouveau_vram_pushbuf;
--
2.40.1
[PATCH drm-next v4 10/14] drm/nouveau: fence: fail to emit when fence context is killed
The new VM_BIND UAPI implementation introduced in subsequent commits
will allow asynchronous jobs processing push buffers and emitting
fences.
If a fence context is killed, e.g. due to a channel fault, jobs which
are already queued for execution might still emit new fences. In such a
case a job would hang forever.
To fix that, fail to emit a new fence on a killed fence context with
-ENODEV to unblock the job.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 7 +++
drivers/gpu/drm/nouveau/nouveau_fence.h | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index e946408f945b..77c739a55b19 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -96,6 +96,7 @@ nouveau_fence_context_kill(struct nouveau_fence_chan *fctx,
int error)
if (nouveau_fence_signal(fence))
nvif_event_block(>event);
}
+ fctx->killed = 1;
spin_unlock_irqrestore(>lock, flags);
}
@@ -229,6 +230,12 @@ nouveau_fence_emit(struct nouveau_fence *fence, struct
nouveau_channel *chan)
dma_fence_get(>base);
spin_lock_irq(>lock);
+ if (unlikely(fctx->killed)) {
+ spin_unlock_irq(>lock);
+ dma_fence_put(>base);
+ return -ENODEV;
+ }
+
if (nouveau_fence_update(chan, fctx))
nvif_event_block(>event);
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.h
b/drivers/gpu/drm/nouveau/nouveau_fence.h
index 7c73c7c9834a..2c72d96ef17d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.h
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.h
@@ -44,7 +44,7 @@ struct nouveau_fence_chan {
char name[32];
struct nvif_event event;
- int notify_ref, dead;
+ int notify_ref, dead, killed;
};
struct nouveau_fence_priv {
--
2.40.1
[PATCH drm-next v4 09/14] drm/nouveau: fence: separate fence alloc and emit
The new (VM_BIND) UAPI exports DMA fences through DRM syncobjs. Hence,
in order to emit fences within DMA fence signalling critical sections
(e.g. as typically done in the DRM GPU schedulers run_job() callback) we
need to separate fence allocation and fence emitting.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 9 -
drivers/gpu/drm/nouveau/nouveau_bo.c| 52 +++--
drivers/gpu/drm/nouveau/nouveau_chan.c | 6 ++-
drivers/gpu/drm/nouveau/nouveau_dmem.c | 9 +++--
drivers/gpu/drm/nouveau/nouveau_fence.c | 16 +++-
drivers/gpu/drm/nouveau/nouveau_fence.h | 3 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 5 ++-
7 files changed, 59 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index a6f2e681bde9..a34924523133 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -1122,11 +1122,18 @@ nv04_page_flip_emit(struct nouveau_channel *chan,
PUSH_NVSQ(push, NV_SW, NV_SW_PAGE_FLIP, 0x);
PUSH_KICK(push);
- ret = nouveau_fence_new(chan, false, pfence);
+ ret = nouveau_fence_new(pfence);
if (ret)
goto fail;
+ ret = nouveau_fence_emit(*pfence, chan);
+ if (ret)
+ goto fail_fence_unref;
+
return 0;
+
+fail_fence_unref:
+ nouveau_fence_unref(pfence);
fail:
spin_lock_irqsave(>event_lock, flags);
list_del(>head);
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 057bc995f19b..e9cbbf594e6f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -820,29 +820,39 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int
evict,
mutex_lock(>mutex);
else
mutex_lock_nested(>mutex, SINGLE_DEPTH_NESTING);
+
ret = nouveau_fence_sync(nouveau_bo(bo), chan, true,
ctx->interruptible);
- if (ret == 0) {
- ret = drm->ttm.move(chan, bo, bo->resource, new_reg);
- if (ret == 0) {
- ret = nouveau_fence_new(chan, false, );
- if (ret == 0) {
- /* TODO: figure out a better solution here
-*
-* wait on the fence here explicitly as going
through
-* ttm_bo_move_accel_cleanup somehow doesn't
seem to do it.
-*
-* Without this the operation can timeout and
we'll fallback to a
-* software copy, which might take several
minutes to finish.
-*/
- nouveau_fence_wait(fence, false, false);
- ret = ttm_bo_move_accel_cleanup(bo,
- >base,
- evict, false,
- new_reg);
- nouveau_fence_unref();
- }
- }
+ if (ret)
+ goto out_unlock;
+
+ ret = drm->ttm.move(chan, bo, bo->resource, new_reg);
+ if (ret)
+ goto out_unlock;
+
+ ret = nouveau_fence_new();
+ if (ret)
+ goto out_unlock;
+
+ ret = nouveau_fence_emit(fence, chan);
+ if (ret) {
+ nouveau_fence_unref();
+ goto out_unlock;
}
+
+ /* TODO: figure out a better solution here
+*
+* wait on the fence here explicitly as going through
+* ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
+*
+* Without this the operation can timeout and we'll fallback to a
+* software copy, which might take several minutes to finish.
+*/
+ nouveau_fence_wait(fence, false, false);
+ ret = ttm_bo_move_accel_cleanup(bo, >base, evict, false,
+ new_reg);
+ nouveau_fence_unref();
+
+out_unlock:
mutex_unlock(>mutex);
return ret;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index 1068abe41024..f47c0363683c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -62,9 +62,11 @@ nouveau_channel_idle(struct nouveau_channel *chan)
struct nouveau_fence *fence = NULL;
int ret;
- ret = nouveau_fence_new(chan, false, );
+ ret = nouveau_fence_new();
if (!ret) {
- ret = nouveau_fence_wait(fence, false, false);
+ ret = nouveau_fence_emit(fence, chan);
+ if (!ret)
+
[PATCH drm-next v4 08/14] drm/nouveau: move usercopy helpers to nouveau_drv.h
Move the usercopy helpers to a common driver header file to make it
usable for the new API added in subsequent commits.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 26 ++
drivers/gpu/drm/nouveau/nouveau_gem.c | 26 --
2 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 81350e685b50..20a7f31b9082 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -130,6 +130,32 @@ nouveau_cli(struct drm_file *fpriv)
return fpriv ? fpriv->driver_priv : NULL;
}
+static inline void
+u_free(void *addr)
+{
+ kvfree(addr);
+}
+
+static inline void *
+u_memcpya(uint64_t user, unsigned nmemb, unsigned size)
+{
+ void *mem;
+ void __user *userptr = (void __force __user *)(uintptr_t)user;
+
+ size *= nmemb;
+
+ mem = kvmalloc(size, GFP_KERNEL);
+ if (!mem)
+ return ERR_PTR(-ENOMEM);
+
+ if (copy_from_user(mem, userptr, size)) {
+ u_free(mem);
+ return ERR_PTR(-EFAULT);
+ }
+
+ return mem;
+}
+
#include
#include
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 45ca4eb98f54..a48f42aaeab9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -613,32 +613,6 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
return 0;
}
-static inline void
-u_free(void *addr)
-{
- kvfree(addr);
-}
-
-static inline void *
-u_memcpya(uint64_t user, unsigned nmemb, unsigned size)
-{
- void *mem;
- void __user *userptr = (void __force __user *)(uintptr_t)user;
-
- size *= nmemb;
-
- mem = kvmalloc(size, GFP_KERNEL);
- if (!mem)
- return ERR_PTR(-ENOMEM);
-
- if (copy_from_user(mem, userptr, size)) {
- u_free(mem);
- return ERR_PTR(-EFAULT);
- }
-
- return mem;
-}
-
static int
nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
struct drm_nouveau_gem_pushbuf *req,
--
2.40.1
[PATCH drm-next v4 07/14] drm/nouveau: bo: initialize GEM GPU VA interface
Initialize the GEM's DRM GPU VA manager interface in preparation for the (u)vmm implementation, provided by subsequent commits, to make use of it. Signed-off-by: Danilo Krummrich --- drivers/gpu/drm/nouveau/nouveau_bo.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 7724fe63067d..057bc995f19b 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -215,11 +215,14 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int *align, u32 domain, nvbo = kzalloc(sizeof(struct nouveau_bo), GFP_KERNEL); if (!nvbo) return ERR_PTR(-ENOMEM); + INIT_LIST_HEAD(>head); INIT_LIST_HEAD(>entry); INIT_LIST_HEAD(>vma_list); nvbo->bo.bdev = >ttm.bdev; + drm_gem_gpuva_init(>bo.base); + /* This is confusing, and doesn't actually mean we want an uncached * mapping, but is what NOUVEAU_GEM_DOMAIN_COHERENT gets translated * into in nouveau_gem_new(). -- 2.40.1
[PATCH drm-next v4 06/14] drm/nouveau: get vmm via nouveau_cli_vmm()
Provide a getter function for the client's current vmm context. Since
we'll add a new (u)vmm context for UMD bindings in subsequent commits,
this will keep the code clean.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_drv.h | 9 +
drivers/gpu/drm/nouveau/nouveau_gem.c | 6 +++---
4 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index c2ec91cc845d..7724fe63067d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -204,7 +204,7 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int
*align, u32 domain,
struct nouveau_drm *drm = cli->drm;
struct nouveau_bo *nvbo;
struct nvif_mmu *mmu = >mmu;
- struct nvif_vmm *vmm = cli->svm.cli ? >svm.vmm : >vmm.vmm;
+ struct nvif_vmm *vmm = _cli_vmm(cli)->vmm;
int i, pi = -1;
if (!*size) {
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index e648ecd0c1a0..1068abe41024 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -148,7 +148,7 @@ nouveau_channel_prep(struct nouveau_drm *drm, struct
nvif_device *device,
chan->device = device;
chan->drm = drm;
- chan->vmm = cli->svm.cli ? >svm : >vmm;
+ chan->vmm = nouveau_cli_vmm(cli);
atomic_set(>killed, 0);
/* allocate memory for dma push buffer */
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index b5de312a523f..81350e685b50 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -112,6 +112,15 @@ struct nouveau_cli_work {
struct dma_fence_cb cb;
};
+static inline struct nouveau_vmm *
+nouveau_cli_vmm(struct nouveau_cli *cli)
+{
+ if (cli->svm.cli)
+ return >svm;
+
+ return >vmm;
+}
+
void nouveau_cli_work_queue(struct nouveau_cli *, struct dma_fence *,
struct nouveau_cli_work *);
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index ab9062e50977..45ca4eb98f54 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -103,7 +103,7 @@ nouveau_gem_object_open(struct drm_gem_object *gem, struct
drm_file *file_priv)
struct nouveau_bo *nvbo = nouveau_gem_object(gem);
struct nouveau_drm *drm = nouveau_bdev(nvbo->bo.bdev);
struct device *dev = drm->dev->dev;
- struct nouveau_vmm *vmm = cli->svm.cli ? >svm : >vmm;
+ struct nouveau_vmm *vmm = nouveau_cli_vmm(cli);
struct nouveau_vma *vma;
int ret;
@@ -180,7 +180,7 @@ nouveau_gem_object_close(struct drm_gem_object *gem, struct
drm_file *file_priv)
struct nouveau_bo *nvbo = nouveau_gem_object(gem);
struct nouveau_drm *drm = nouveau_bdev(nvbo->bo.bdev);
struct device *dev = drm->dev->dev;
- struct nouveau_vmm *vmm = cli->svm.cli ? >svm : & cli->vmm;
+ struct nouveau_vmm *vmm = nouveau_cli_vmm(cli);
struct nouveau_vma *vma;
int ret;
@@ -269,7 +269,7 @@ nouveau_gem_info(struct drm_file *file_priv, struct
drm_gem_object *gem,
{
struct nouveau_cli *cli = nouveau_cli(file_priv);
struct nouveau_bo *nvbo = nouveau_gem_object(gem);
- struct nouveau_vmm *vmm = cli->svm.cli ? >svm : >vmm;
+ struct nouveau_vmm *vmm = nouveau_cli_vmm(cli);
struct nouveau_vma *vma;
if (is_power_of_2(nvbo->valid_domains))
--
2.40.1
[PATCH drm-next v4 03/14] drm: manager to keep track of GPUs VA mappings
Add infrastructure to keep track of GPU virtual address (VA) mappings with a decicated VA space manager implementation. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1) Provide infrastructure to track GPU VA allocations and mappings, making use of the maple_tree. 2) Generically connect GPU VA mappings to their backing buffers, in particular DRM GEM objects. 3) Provide a common implementation to perform more complex mapping operations on the GPU VA space. In particular splitting and merging of GPU VA mappings, e.g. for intersecting mapping requests or partial unmap requests. Suggested-by: Dave Airlie Signed-off-by: Danilo Krummrich --- Documentation/gpu/drm-mm.rst| 31 + drivers/gpu/drm/Makefile|1 + drivers/gpu/drm/drm_gem.c |3 + drivers/gpu/drm/drm_gpuva_mgr.c | 1687 +++ include/drm/drm_drv.h |6 + include/drm/drm_gem.h | 75 ++ include/drm/drm_gpuva_mgr.h | 681 + 7 files changed, 2484 insertions(+) create mode 100644 drivers/gpu/drm/drm_gpuva_mgr.c create mode 100644 include/drm/drm_gpuva_mgr.h diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index a52e6f4117d6..c9f120cfe730 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -466,6 +466,37 @@ DRM MM Range Allocator Function References .. kernel-doc:: drivers/gpu/drm/drm_mm.c :export: +DRM GPU VA Manager +== + +Overview + + +.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c + :doc: Overview + +Split and Merge +--- + +.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c + :doc: Split and Merge + +Locking +--- + +.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c + :doc: Locking + + +DRM GPU VA Manager Function References +-- + +.. kernel-doc:: include/drm/drm_gpuva_mgr.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c + :export: + DRM Buddy Allocator === diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 9c6446eb3c83..8eeed446a078 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -45,6 +45,7 @@ drm-y := \ drm_vblank.o \ drm_vblank_work.o \ drm_vma_manager.o \ + drm_gpuva_mgr.o \ drm_writeback.o drm-$(CONFIG_DRM_LEGACY) += \ drm_agpsupport.o \ diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 1a5a2cd0d4ec..cd878ebddbd0 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -164,6 +164,9 @@ void drm_gem_private_object_init(struct drm_device *dev, if (!obj->resv) obj->resv = >_resv; + if (drm_core_check_feature(dev, DRIVER_GEM_GPUVA)) + drm_gem_gpuva_init(obj); + drm_vma_node_reset(>vma_node); INIT_LIST_HEAD(>lru_node); } diff --git a/drivers/gpu/drm/drm_gpuva_mgr.c b/drivers/gpu/drm/drm_gpuva_mgr.c new file mode 100644 index ..dd8dd7fef14b --- /dev/null +++ b/drivers/gpu/drm/drm_gpuva_mgr.c @@ -0,0 +1,1687 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2022 Red Hat. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + * + * Authors: + * Danilo Krummrich + * + */ + +#include +#include + +/** + * DOC: Overview + * + * The DRM GPU VA Manager, represented by struct drm_gpuva_manager keeps track + * of a GPU's virtual address (VA) space and manages the corresponding virtual + * mappings represented by _gpuva objects. It also keeps track of the + * mapping's backing _gem_object buffers. + * + * _gem_object buffers maintain a list (and a corresponding list lock) of + * _gpuva objects representing
[PATCH drm-next v4 05/14] drm/nouveau: new VM_BIND uapi interfaces
This commit provides the interfaces for the new UAPI motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU virtual address (VA) space via the new
DRM_IOCTL_NOUVEAU_VM_INIT ioctl. UMDs can provide a kernel reserved
VA area.
2) Bind and unbind GPU VA space mappings via the new
DRM_IOCTL_NOUVEAU_VM_BIND ioctl.
3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl.
Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC support
asynchronous processing with DRM syncobjs as synchronization mechanism.
The default DRM_IOCTL_NOUVEAU_VM_BIND is synchronous processing,
DRM_IOCTL_NOUVEAU_EXEC supports asynchronous processing only.
Co-authored-by: Dave Airlie
Signed-off-by: Danilo Krummrich
---
Documentation/gpu/driver-uapi.rst | 8 ++
include/uapi/drm/nouveau_drm.h| 209 ++
2 files changed, 217 insertions(+)
diff --git a/Documentation/gpu/driver-uapi.rst
b/Documentation/gpu/driver-uapi.rst
index 4411e6919a3d..9c7ca6e33a68 100644
--- a/Documentation/gpu/driver-uapi.rst
+++ b/Documentation/gpu/driver-uapi.rst
@@ -6,3 +6,11 @@ drm/i915 uAPI
=
.. kernel-doc:: include/uapi/drm/i915_drm.h
+
+drm/nouveau uAPI
+
+
+VM_BIND / EXEC uAPI
+---
+
+.. kernel-doc:: include/uapi/drm/nouveau_drm.h
diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
index 853a327433d3..4d3a70529637 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -126,6 +126,209 @@ struct drm_nouveau_gem_cpu_fini {
__u32 handle;
};
+/**
+ * struct drm_nouveau_sync - sync object
+ *
+ * This structure serves as synchronization mechanism for (potentially)
+ * asynchronous operations such as EXEC or VM_BIND.
+ */
+struct drm_nouveau_sync {
+ /**
+* @flags: the flags for a sync object
+*
+* The first 8 bits are used to determine the type of the sync object.
+*/
+ __u32 flags;
+#define DRM_NOUVEAU_SYNC_SYNCOBJ 0x0
+#define DRM_NOUVEAU_SYNC_TIMELINE_SYNCOBJ 0x1
+#define DRM_NOUVEAU_SYNC_TYPE_MASK 0xf
+ /**
+* @handle: the handle of the sync object
+*/
+ __u32 handle;
+ /**
+* @timeline_value:
+*
+* The timeline point of the sync object in case the syncobj is of
+* type DRM_NOUVEAU_SYNC_TIMELINE_SYNCOBJ.
+*/
+ __u64 timeline_value;
+};
+
+/**
+ * struct drm_nouveau_vm_init - GPU VA space init structure
+ *
+ * Used to initialize the GPU's VA space for a user client, telling the kernel
+ * which portion of the VA space is managed by the UMD and kernel respectively.
+ */
+struct drm_nouveau_vm_init {
+ /**
+* @unmanaged_addr: start address of the kernel managed VA space region
+*/
+ __u64 unmanaged_addr;
+ /**
+* @unmanaged_size: size of the kernel managed VA space region in bytes
+*/
+ __u64 unmanaged_size;
+};
+
+/**
+ * struct drm_nouveau_vm_bind_op - VM_BIND operation
+ *
+ * This structure represents a single VM_BIND operation. UMDs should pass
+ * an array of this structure via struct drm_nouveau_vm_bind's _ptr field.
+ */
+struct drm_nouveau_vm_bind_op {
+ /**
+* @op: the operation type
+*/
+ __u32 op;
+/**
+ * @DRM_NOUVEAU_VM_BIND_OP_MAP:
+ *
+ * Map a GEM object to the GPU's VA space. Optionally, the
+ * _NOUVEAU_VM_BIND_SPARSE flag can be passed to instruct the kernel to
+ * create sparse mappings for the given range.
+ */
+#define DRM_NOUVEAU_VM_BIND_OP_MAP 0x0
+/**
+ * @DRM_NOUVEAU_VM_BIND_OP_UNMAP:
+ *
+ * Unmap an existing mapping in the GPU's VA space. If the region the mapping
+ * is located in is a sparse region, new sparse mappings are created where the
+ * unmapped (memory backed) mapping was mapped previously. To remove a sparse
+ * region the _NOUVEAU_VM_BIND_SPARSE must be set.
+ */
+#define DRM_NOUVEAU_VM_BIND_OP_UNMAP 0x1
+ /**
+* @flags: the flags for a _nouveau_vm_bind_op
+*/
+ __u32 flags;
+/**
+ * @DRM_NOUVEAU_VM_BIND_SPARSE:
+ *
+ * Indicates that an allocated VA space region should be sparse.
+ */
+#define DRM_NOUVEAU_VM_BIND_SPARSE (1 << 8)
+ /**
+* @handle: the handle of the DRM GEM object to map
+*/
+ __u32 handle;
+ /**
+* @pad: 32 bit padding, should be 0
+*/
+ __u32 pad;
+ /**
+* @addr:
+*
+* the address the VA space region or (memory backed) mapping should be
mapped to
+*/
+ __u64 addr;
+ /**
+* @bo_offset: the offset within the BO backing the mapping
+*/
+ __u64 bo_offset;
+ /**
+* @range: the size of the requested mapping in bytes
+*/
+ __u64 range;
+};
+
+/**
+ * struct drm_nouveau_vm_bind - structure for DRM_IOCTL_NOUVEAU_VM_BIND
+ */
+struct drm_nouveau_vm_bind {
+ /**
+* @op_count: the number of _nouveau_vm_bind_op
+
[PATCH drm-next v4 04/14] drm: debugfs: provide infrastructure to dump a DRM GPU VA space
This commit adds a function to dump a DRM GPU VA space and a macro for
drivers to register the struct drm_info_list 'gpuvas' entry.
Most likely, most drivers might maintain one DRM GPU VA space per struct
drm_file, but there might also be drivers not having a fixed relation
between DRM GPU VA spaces and a DRM core infrastructure, hence we need the
indirection via the driver iterating it's maintained DRM GPU VA spaces.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/drm_debugfs.c | 41 +++
include/drm/drm_debugfs.h | 25 +
2 files changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 4855230ba2c6..82180fb1c200 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -175,6 +176,46 @@ static const struct file_operations drm_debugfs_fops = {
.release = single_release,
};
+/**
+ * drm_debugfs_gpuva_info - dump the given DRM GPU VA space
+ * @m: pointer to the _file to write
+ * @mgr: the _gpuva_manager representing the GPU VA space
+ *
+ * Dumps the GPU VA mappings of a given DRM GPU VA manager.
+ *
+ * For each DRM GPU VA space drivers should call this function from their
+ * _info_list's show callback.
+ *
+ * Returns: 0 on success, -ENODEV if the is not initialized
+ */
+int drm_debugfs_gpuva_info(struct seq_file *m,
+ struct drm_gpuva_manager *mgr)
+{
+ DRM_GPUVA_ITER(it, mgr, 0);
+ struct drm_gpuva *va, *kva = >kernel_alloc_node;
+
+ if (!mgr->name)
+ return -ENODEV;
+
+ seq_printf(m, "DRM GPU VA space (%s) [0x%016llx;0x%016llx]\n",
+ mgr->name, mgr->mm_start, mgr->mm_start + mgr->mm_range);
+ seq_printf(m, "Kernel reserved node [0x%016llx;0x%016llx]\n",
+ kva->va.addr, kva->va.addr + kva->va.range);
+ seq_puts(m, "\n");
+ seq_puts(m, " VAs | start | range | end
| object | object offset\n");
+ seq_puts(m,
"-\n");
+ drm_gpuva_iter_for_each(va, it) {
+ if (unlikely(va == >kernel_alloc_node))
+ continue;
+
+ seq_printf(m, " | 0x%016llx | 0x%016llx | 0x%016llx |
0x%016llx | 0x%016llx\n",
+ va->va.addr, va->va.range, va->va.addr +
va->va.range,
+ (u64)va->gem.obj, va->gem.offset);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_debugfs_gpuva_info);
/**
* drm_debugfs_create_files - Initialize a given set of debugfs files for DRM
diff --git a/include/drm/drm_debugfs.h b/include/drm/drm_debugfs.h
index 7616f457ce70..cb2c1956a214 100644
--- a/include/drm/drm_debugfs.h
+++ b/include/drm/drm_debugfs.h
@@ -34,6 +34,22 @@
#include
#include
+
+#include
+
+/**
+ * DRM_DEBUGFS_GPUVA_INFO - _info_list entry to dump a GPU VA space
+ * @show: the _info_list's show callback
+ * @data: driver private data
+ *
+ * Drivers should use this macro to define a _info_list entry to provide a
+ * debugfs file for dumping the GPU VA space regions and mappings.
+ *
+ * For each DRM GPU VA space drivers should call drm_debugfs_gpuva_info() from
+ * their @show callback.
+ */
+#define DRM_DEBUGFS_GPUVA_INFO(show, data) {"gpuvas", show, DRIVER_GEM_GPUVA,
data}
+
/**
* struct drm_info_list - debugfs info list entry
*
@@ -134,6 +150,9 @@ void drm_debugfs_add_file(struct drm_device *dev, const
char *name,
void drm_debugfs_add_files(struct drm_device *dev,
const struct drm_debugfs_info *files, int count);
+
+int drm_debugfs_gpuva_info(struct seq_file *m,
+ struct drm_gpuva_manager *mgr);
#else
static inline void drm_debugfs_create_files(const struct drm_info_list *files,
int count, struct dentry *root,
@@ -155,6 +174,12 @@ static inline void drm_debugfs_add_files(struct drm_device
*dev,
const struct drm_debugfs_info *files,
int count)
{}
+
+static inline int drm_debugfs_gpuva_info(struct seq_file *m,
+struct drm_gpuva_manager *mgr)
+{
+ return 0;
+}
#endif
#endif /* _DRM_DEBUGFS_H_ */
--
2.40.1
[PATCH drm-next v4 02/14] maple_tree: split up MA_STATE() macro
Split up the MA_STATE() macro such that components using the maple tree
can easily inherit from struct ma_state and build custom tree walk
macros to hide their internals from users.
Example:
struct sample_iterator {
struct ma_state mas;
struct sample_mgr *mgr;
};
\#define SAMPLE_ITERATOR(name, __mgr, start)\
struct sample_iterator name = { \
.mas = MA_STATE_INIT(&(__mgr)->mt, start, 0), \
.mgr = __mgr, \
}
\#define sample_iter_for_each_range(it__, entry__, end__) \
mas_for_each(&(it__).mas, entry__, end__)
--
struct sample *sample;
SAMPLE_ITERATOR(si, min);
sample_iter_for_each_range(, sample, max) {
frob(mgr, sample);
}
Signed-off-by: Danilo Krummrich
---
include/linux/maple_tree.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/linux/maple_tree.h b/include/linux/maple_tree.h
index 1fadb5f5978b..87d55334f1c2 100644
--- a/include/linux/maple_tree.h
+++ b/include/linux/maple_tree.h
@@ -423,8 +423,8 @@ struct ma_wr_state {
#define MA_ERROR(err) \
((struct maple_enode *)(((unsigned long)err << 2) | 2UL))
-#define MA_STATE(name, mt, first, end) \
- struct ma_state name = {\
+#define MA_STATE_INIT(mt, first, end) \
+ { \
.tree = mt, \
.index = first, \
.last = end,\
@@ -435,6 +435,9 @@ struct ma_wr_state {
.mas_flags = 0, \
}
+#define MA_STATE(name, mt, first, end) \
+ struct ma_state name = MA_STATE_INIT(mt, first, end)
+
#define MA_WR_STATE(name, ma_state, wr_entry) \
struct ma_wr_state name = { \
.mas = ma_state,\
--
2.40.1
[PATCH drm-next v4 01/14] drm: execution context for GEM buffers v4
From: Christian König
This adds the infrastructure for an execution context for GEM buffers
which is similar to the existing TTMs execbuf util and intended to replace
it in the long term.
The basic functionality is that we abstracts the necessary loop to lock
many different GEM buffers with automated deadlock and duplicate handling.
v2: drop xarray and use dynamic resized array instead, the locking
overhead is unecessary and measurable.
v3: drop duplicate tracking, radeon is really the only one needing that.
v4: fixes issues pointed out by Danilo, some typos in comments and a
helper for lock arrays of GEM objects.
Signed-off-by: Christian König
---
Documentation/gpu/drm-mm.rst | 12 ++
drivers/gpu/drm/Kconfig | 6 +
drivers/gpu/drm/Makefile | 2 +
drivers/gpu/drm/drm_exec.c | 278 +++
include/drm/drm_exec.h | 119 +++
5 files changed, 417 insertions(+)
create mode 100644 drivers/gpu/drm/drm_exec.c
create mode 100644 include/drm/drm_exec.h
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index a79fd3549ff8..a52e6f4117d6 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -493,6 +493,18 @@ DRM Sync Objects
.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
:export:
+DRM Execution context
+=
+
+.. kernel-doc:: drivers/gpu/drm/drm_exec.c
+ :doc: Overview
+
+.. kernel-doc:: include/drm/drm_exec.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_exec.c
+ :export:
+
GPU Scheduler
=
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index ba3fb04bb691..2dc81eb062eb 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -201,6 +201,12 @@ config DRM_TTM
GPU memory types. Will be enabled automatically if a device driver
uses it.
+config DRM_EXEC
+ tristate
+ depends on DRM
+ help
+ Execution context for command submissions
+
config DRM_BUDDY
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a33257d2bc7f..9c6446eb3c83 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -78,6 +78,8 @@ obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) +=
drm_panel_orientation_quirks.o
#
# Memory-management helpers
#
+#
+obj-$(CONFIG_DRM_EXEC) += drm_exec.o
obj-$(CONFIG_DRM_BUDDY) += drm_buddy.o
diff --git a/drivers/gpu/drm/drm_exec.c b/drivers/gpu/drm/drm_exec.c
new file mode 100644
index ..18071bff20f4
--- /dev/null
+++ b/drivers/gpu/drm/drm_exec.c
@@ -0,0 +1,278 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+
+#include
+#include
+#include
+
+/**
+ * DOC: Overview
+ *
+ * This component mainly abstracts the retry loop necessary for locking
+ * multiple GEM objects while preparing hardware operations (e.g. command
+ * submissions, page table updates etc..).
+ *
+ * If a contention is detected while locking a GEM object the cleanup procedure
+ * unlocks all previously locked GEM objects and locks the contended one first
+ * before locking any further objects.
+ *
+ * After an object is locked fences slots can optionally be reserved on the
+ * dma_resv object inside the GEM object.
+ *
+ * A typical usage pattern should look like this::
+ *
+ * struct drm_gem_object *obj;
+ * struct drm_exec exec;
+ * unsigned long index;
+ * int ret;
+ *
+ * drm_exec_init(, true);
+ * drm_exec_while_not_all_locked() {
+ * ret = drm_exec_prepare_obj(, boA, 1);
+ * drm_exec_continue_on_contention();
+ * if (ret)
+ * goto error;
+ *
+ * ret = drm_exec_prepare_obj(, boB, 1);
+ * drm_exec_continue_on_contention();
+ * if (ret)
+ * goto error;
+ * }
+ *
+ * drm_exec_for_each_locked_object(, index, obj) {
+ * dma_resv_add_fence(obj->resv, fence, DMA_RESV_USAGE_READ);
+ * ...
+ * }
+ * drm_exec_fini();
+ *
+ * See struct dma_exec for more details.
+ */
+
+/* Dummy value used to initially enter the retry loop */
+#define DRM_EXEC_DUMMY (void*)~0
+
+/* Unlock all objects and drop references */
+static void drm_exec_unlock_all(struct drm_exec *exec)
+{
+ struct drm_gem_object *obj;
+ unsigned long index;
+
+ drm_exec_for_each_locked_object(exec, index, obj) {
+ dma_resv_unlock(obj->resv);
+ drm_gem_object_put(obj);
+ }
+
+ drm_gem_object_put(exec->prelocked);
+ exec->prelocked = NULL;
+}
+
+/**
+ * drm_exec_init - initialize a drm_exec object
+ * @exec: the drm_exec object to initialize
+ * @interruptible: if locks should be acquired interruptible
+ *
+ * Initialize the object and make sure that we can track locked objects.
+ */
+void drm_exec_init(struct drm_exec *exec, bool interruptible)
+{
+ exec->interruptible = interruptible;
+ exec->objects =
[PATCH drm-next v4 00/14] [RFC] DRM GPUVA Manager & Nouveau VM_BIND UAPI
Furthermore, with the DRM GPUVA manager it provides a new DRM core feature to keep track of GPU virtual address (VA) mappings in a more generic way. The DRM GPUVA manager is indented to help drivers implement userspace-manageable GPU VA spaces in reference to the Vulkan API. In order to achieve this goal it serves the following purposes in this context. 1) Provide infrastructure to track GPU VA allocations and mappings, making use of the maple_tree. 2) Generically connect GPU VA mappings to their backing buffers, in particular DRM GEM objects. 3) Provide a common implementation to perform more complex mapping operations on the GPU VA space. In particular splitting and merging of GPU VA mappings, e.g. for intersecting mapping requests or partial unmap requests. The new VM_BIND Nouveau UAPI build on top of the DRM GPUVA manager, itself providing the following new interfaces. 1) Initialize a GPU VA space via the new DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the portion of VA space managed by the kernel and userspace, respectively. 2) Allocate and free a VA space region as well as bind and unbind memory to the GPUs VA space via the new DRM_IOCTL_NOUVEAU_VM_BIND ioctl. 3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl. Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC, make use of the DRM scheduler to queue jobs and support asynchronous processing with DRM syncobjs as synchronization mechanism. By default DRM_IOCTL_NOUVEAU_VM_BIND does synchronous processing, DRM_IOCTL_NOUVEAU_EXEC supports asynchronous processing only. The new VM_BIND UAPI for Nouveau makes also use of drm_exec (execution context for GEM buffers) by Christian König. Since the patch implementing drm_exec was not yet merged into drm-next it is part of this series, as well as a small fix for this patch, which was found while testing this series. This patch series is also available at [1]. There is a Mesa NVK merge request by Dave Airlie [2] implementing the corresponding userspace parts for this series. The Vulkan CTS test suite passes the sparse binding and sparse residency test cases for the new UAPI together with Dave's Mesa work. There are also some test cases in the igt-gpu-tools project [3] for the new UAPI and hence the DRM GPU VA manager. However, most of them are testing the DRM GPU VA manager's logic through Nouveau's new UAPI and should be considered just as helper for implementation. However, I absolutely intend to change those test cases to proper kunit test cases for the DRM GPUVA manager, once and if we agree on it's usefulness and design. [1] https://gitlab.freedesktop.org/nouvelles/kernel/-/tree/new-uapi-drm-next / https://gitlab.freedesktop.org/nouvelles/kernel/-/merge_requests/1 [2] https://gitlab.freedesktop.org/nouveau/mesa/-/merge_requests/150/ [3] https://gitlab.freedesktop.org/dakr/igt-gpu-tools/-/tree/wip_nouveau_vm_bind Changes in V2: == Nouveau: - Reworked the Nouveau VM_BIND UAPI to avoid memory allocations in fence signalling critical sections. Updates to the VA space are split up in three separate stages, where only the 2. stage executes in a fence signalling critical section: 1. update the VA space, allocate new structures and page tables 2. (un-)map the requested memory bindings 3. free structures and page tables - Separated generic job scheduler code from specific job implementations. - Separated the EXEC and VM_BIND implementation of the UAPI. - Reworked the locking parts of the nvkm/vmm RAW interface, such that (un-)map operations can be executed in fence signalling critical sections. GPUVA Manager: - made drm_gpuva_regions optional for users of the GPUVA manager - allow NULL GEMs for drm_gpuva entries - swichted from drm_mm to maple_tree for track drm_gpuva / drm_gpuva_region entries - provide callbacks for users to allocate custom drm_gpuva_op structures to allow inheritance - added user bits to drm_gpuva_flags - added a prefetch operation type in order to support generating prefetch operations in the same way other operations generated - hand the responsibility for mutual exclusion for a GEM's drm_gpuva list to the user; simplified corresponding (un-)link functions Maple Tree: - I added two maple tree patches to the series, one to support custom tree walk macros and one to hand the locking responsibility to the user of the GPUVA manager without pre-defined lockdep checks. Changes in V3: == Nouveau: - Reworked the Nouveau VM_BIND UAPI to do the job cleanup (including page table cleanup) within a workqueue rather than the job_free() callback of the scheduler itself. A job_free() callback can stall the execution (run() callback) of the next job in the queue. Since the page table cleanup
Re: [PATCH 1/9] dt-bindings: display: Add yamls for JH7110 display subsystem
Am Dienstag, 6. Juni 2023, 20:41:17 CEST schrieb Shengyu Qu: > Hi Conor, > > > Hey Keith, > > > > On Fri, Jun 02, 2023 at 03:40:35PM +0800, Keith Zhao wrote: > >> Add bindings for JH7110 display subsystem which > >> has a display controller verisilicon dc8200 > >> and an HDMI interface. > >> > >> Signed-off-by: Keith Zhao > >> --- > >> .../display/verisilicon/starfive-hdmi.yaml| 93 +++ > >> .../display/verisilicon/verisilicon-dc.yaml | 110 ++ > >> .../display/verisilicon/verisilicon-drm.yaml | 42 +++ > >> .../devicetree/bindings/vendor-prefixes.yaml | 2 + > >> MAINTAINERS | 7 ++ > >> 5 files changed, 254 insertions(+) > >> create mode 100644 > >> Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml > >> create mode 100644 > >> Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml > >> create mode 100644 > >> Documentation/devicetree/bindings/display/verisilicon/verisilicon-drm.yaml > >> > >> diff --git > >> a/Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml > >> b/Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml > >> new file mode 100644 > >> index ..c30b7954a355 > >> --- /dev/null > >> +++ > >> b/Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml > >> @@ -0,0 +1,93 @@ > >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > >> +%YAML 1.2 > >> +--- > >> +$id: http://devicetree.org/schemas/display/verisilicon/starfive-hdmi.yaml# > >> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >> + > >> +title: StarFive HDMI transmiter > >> + > >> +description: > >> + The StarFive SoC uses the HDMI signal transmiter based on innosilicon IP > > Is innosilicon the same thing as verisilicon? Also > > s/transmiter/transmitter/, both here and in the title. > > I think that is not the same, I remember Rockchip has used a HDMI > transmitter from > > Innosilicon, and there is a existing driver for that in mainline. Yep, I think Innosilicon is the company you turn to when you want to save a bit of money ;-) . In the bigger SoCs Rockchip most of the time uses Designware hdmi blocks and looking at the history only the rk3036 ever used an Innosilicon block. Looking at the history, 2016 really was a long time ago :-D. > So Keith, if that's true, I think it is better to seperate the HDMI > stuff and reuse existing driver. I'm not so sure about that - at least from a cursory glance :-) . The registers do look slightly different and I don't know how much the IP changed between the rk3036-version and the jh7110 version. At the very least, I know my rk3036 board isn't booting right now, so I can't really provide help for generalizing the rockchip-driver. At the very least both the binding and driver could drop the "starfive-hdmi" and actually use the Innosilicon in the naming somewhere, so that it's clear for future developers :-) Heiko > >> + to generate HDMI signal from its input and transmit the signal to the > >> screen. > >> + > >> +maintainers: > >> + - Keith Zhao > >> + - ShengYang Chen > >> + > >> +properties: > >> + compatible: > >> +const: starfive,hdmi > > Is this going to work on every SoC that StarFive has ever & will ever > > make? Please use soc-based compatibles ;) > > > >> + > >> + reg: > >> +minItems: 1 > >> + > >> + interrupts: > >> +items: > >> + - description: The HDMI hot plug detection interrupt. > >> + > >> + clocks: > >> +items: > >> + - description: System clock of HDMI module. > >> + - description: Mclk clock of HDMI audio. > >> + - description: Bclk clock of HDMI audio. > >> + - description: Pixel clock generated by HDMI module. > >> + > >> + clock-names: > >> +items: > >> + - const: sysclk > >> + - const: mclk > >> + - const: bclk > >> + - const: pclk > >> + > >> + resets: > >> +items: > >> + - description: Reset for HDMI module. > >> + > >> + reset-names: > >> +items: > >> + - const: hdmi_tx > > You only have one item here, you don't need the "items: - const:", > > "const:" alone will do. > > > > > >> diff --git > >> a/Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml > >> > >> b/Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml > >> new file mode 100644 > >> index ..1322502c4cde > >> --- /dev/null > >> +++ > >> b/Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml > >> @@ -0,0 +1,110 @@ > >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > >> +%YAML 1.2 > >> +--- > >> +$id: > >> http://devicetree.org/schemas/display/verisilicon/verisilicon-dc.yaml# > >> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >> + > >> +title: StarFive display controller > >> + > >> +description: > >> + The StarFive SoC uses the display controller based on Verisilicon
Re: [RFC PATCH v2 10/13] drm/msm/dpu: add list of supported formats to the DPU caps
On 07/06/2023 00:47, Abhinav Kumar wrote:
On 6/6/2023 2:29 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:14, Abhinav Kumar wrote:
On 5/24/2023 6:47 PM, Dmitry Baryshkov wrote:
On Thu, 25 May 2023 at 02:16, Abhinav Kumar
wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
As we are going to add virtual planes, add the list of supported
formats
to the hw catalog entry. It will be used to setup universal
planes, with
later selecting a pipe depending on whether the YUV format is used
for
the framebuffer.
If your usage of format_list is going to be internal to dpu_plane.c, I
can think of another idea for this change.
This essentially translates to if (num_vig >= 1)
If we can just have a small helper to detect that from the catalog can
we use that instead of adding formats to the dpu caps?
I'd prefer to be explicit here. The list of supported formats might
vary between generations, might it not? Also we don't have a case of
the devices not having VIG planes. Even the qcm2290 (which doesn't
have CSC) lists YUV as supported.
the list of formats is tied to the sspps the dpu generation has and
the capabilities of those sspps.
qcm2290 is really an interesting case. It has one vig sspp but no csc
block for that vig sspp, hence it cannot support non-RGB formats.
I have confirmed that downstream is incorrect to populate yuv formats
for qcm2290.
I still think that having atleast one vig sspp with csc sub-blk is
the right condition to check if we want to decide if the dpu for that
chipset supports yuv formats. Extra csc-blk check to handle qcm2290.
Having a small helper in dpu_plane.c is good enough for that because
with virtual planes, you only need to know "if such a plane exists
and not which plane" and a full catalog change isnt needed IMO
This goes down to the question: is the list of YUV and non-YUV formats
static or not? Do all DPU devices support the same set of YUV and
non-YUV formats? If it is static, we might as well drop
dpu_sspp_sub_blks::format_list.
I would say yes based on the below reference:
https://git.codelinaro.org/clo/la/platform/vendor/opensource/display-drivers/-/blob/clo/main/msm/sde/sde_hw_catalog.c#L3858
We always add the same set of YUV formats for all Vig SSPPs irrespective
of the chipsets.
Well, as your example pointed out, few lines below it starts adding
formats to the list, so the format list is not static and depends on the
generation.
Note to myself: consider
dpu_mdss_cfg::{dma_formats,cursor_formats,vig_formats}. Either migrate
dpu_sspp_sub_blks::format_list users to these fields or drop them.
Yes, I agree. There is no need to have format list in the sub_blk as for
one type of SSPP, it supports the same format across DPU generations.
Note: I think at some point we should have a closer look at the list
of supported formats and crosscheck that we do not have either
unsupported formats being listed, or missing formats which are not
listed as supported.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 26
+++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 +++
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 212d546b6c5d..2d6944a9679a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -315,6 +315,8 @@ static const struct dpu_caps msm8998_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps qcm2290_dpu_caps = {
@@ -324,6 +326,8 @@ static const struct dpu_caps qcm2290_dpu_caps = {
.has_idle_pc = true,
.max_linewidth = 2160,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sdm845_dpu_caps = {
@@ -339,6 +343,8 @@ static const struct dpu_caps sdm845_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sc7180_dpu_caps = {
@@ -350,6 +356,8 @@ static const struct dpu_caps sc7180_dpu_caps = {
.has_idle_pc = true,
.max_linewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sm6115_dpu_caps = {
@@ -361,6 +369,8 @@ static const struct dpu_caps sm6115_dpu_caps = {
.has_idle_pc = true,
.max_linewidth = 2160,
Re: [PATCH v17] drm/msm/dpu: add DSC blocks to the catalog of MSM8998
Hi Dmitry
On 6/6/2023 1:21 PM, Dmitry Baryshkov wrote:
On 06/06/2023 23:11, Kuogee Hsieh wrote:
From: Abhinav Kumar
Some platforms have DSC blocks which have not been declared in the
catalog.
Complete DSC 1.1 support for all platforms by adding the missing
blocks to
MSM8998.
'Some platforms' doesn't make sense if we are talking about a single
poor msm8998.
If you dont mind, can you please fix this while applying? Thanks for
consideration.
Changes in v9:
-- add MSM8998 and SC8180x to commit title
Changes in v10:
-- fix grammar at commit text
Changes in v12:
-- fix "titil" with "title" at changes in v9
Changes in v14:
-- "dsc" tp "DSC" at commit title
Changes in v15:
-- fix merge conflicts at dpu_5_1_sc8180x.h
Changes in v16
-- fix cherry-pick error by deleting both redundant .dsc and .dsc_count
assignment from dpu_5_1_sc8180x.h
Changes in v17
-- remove sc8180x from both commit title and text
-- remove Reviewed-by
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index 3c732a0..7d0d0e7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -126,6 +126,11 @@ static const struct dpu_pingpong_cfg msm8998_pp[]
= {
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
};
+static const struct dpu_dsc_cfg msm8998_dsc[] = {
+ DSC_BLK("dsc_0", DSC_0, 0x8, 0),
+ DSC_BLK("dsc_1", DSC_1, 0x80400, 0),
+};
+
static const struct dpu_dspp_cfg msm8998_dspp[] = {
DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_SC7180_MASK,
_dspp_sblk),
@@ -199,6 +204,8 @@ const struct dpu_mdss_cfg dpu_msm8998_cfg = {
.dspp = msm8998_dspp,
.pingpong_count = ARRAY_SIZE(msm8998_pp),
.pingpong = msm8998_pp,
+ .dsc_count = ARRAY_SIZE(msm8998_dsc),
+ .dsc = msm8998_dsc,
.intf_count = ARRAY_SIZE(msm8998_intf),
.intf = msm8998_intf,
.vbif_count = ARRAY_SIZE(msm8998_vbif),
Re: [RFC PATCH v2 10/13] drm/msm/dpu: add list of supported formats to the DPU caps
On 6/6/2023 2:29 PM, Dmitry Baryshkov wrote:
On 07/06/2023 00:14, Abhinav Kumar wrote:
On 5/24/2023 6:47 PM, Dmitry Baryshkov wrote:
On Thu, 25 May 2023 at 02:16, Abhinav Kumar
wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
As we are going to add virtual planes, add the list of supported
formats
to the hw catalog entry. It will be used to setup universal planes,
with
later selecting a pipe depending on whether the YUV format is used for
the framebuffer.
If your usage of format_list is going to be internal to dpu_plane.c, I
can think of another idea for this change.
This essentially translates to if (num_vig >= 1)
If we can just have a small helper to detect that from the catalog can
we use that instead of adding formats to the dpu caps?
I'd prefer to be explicit here. The list of supported formats might
vary between generations, might it not? Also we don't have a case of
the devices not having VIG planes. Even the qcm2290 (which doesn't
have CSC) lists YUV as supported.
the list of formats is tied to the sspps the dpu generation has and
the capabilities of those sspps.
qcm2290 is really an interesting case. It has one vig sspp but no csc
block for that vig sspp, hence it cannot support non-RGB formats.
I have confirmed that downstream is incorrect to populate yuv formats
for qcm2290.
I still think that having atleast one vig sspp with csc sub-blk is the
right condition to check if we want to decide if the dpu for that
chipset supports yuv formats. Extra csc-blk check to handle qcm2290.
Having a small helper in dpu_plane.c is good enough for that because
with virtual planes, you only need to know "if such a plane exists and
not which plane" and a full catalog change isnt needed IMO
This goes down to the question: is the list of YUV and non-YUV formats
static or not? Do all DPU devices support the same set of YUV and
non-YUV formats? If it is static, we might as well drop
dpu_sspp_sub_blks::format_list.
I would say yes based on the below reference:
https://git.codelinaro.org/clo/la/platform/vendor/opensource/display-drivers/-/blob/clo/main/msm/sde/sde_hw_catalog.c#L3858
We always add the same set of YUV formats for all Vig SSPPs irrespective
of the chipsets.
Note to myself: consider
dpu_mdss_cfg::{dma_formats,cursor_formats,vig_formats}. Either migrate
dpu_sspp_sub_blks::format_list users to these fields or drop them.
Yes, I agree. There is no need to have format list in the sub_blk as for
one type of SSPP, it supports the same format across DPU generations.
Note: I think at some point we should have a closer look at the list
of supported formats and crosscheck that we do not have either
unsupported formats being listed, or missing formats which are not
listed as supported.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 26
+++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 +++
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 212d546b6c5d..2d6944a9679a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -315,6 +315,8 @@ static const struct dpu_caps msm8998_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps qcm2290_dpu_caps = {
@@ -324,6 +326,8 @@ static const struct dpu_caps qcm2290_dpu_caps = {
.has_idle_pc = true,
.max_linewidth = 2160,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sdm845_dpu_caps = {
@@ -339,6 +343,8 @@ static const struct dpu_caps sdm845_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sc7180_dpu_caps = {
@@ -350,6 +356,8 @@ static const struct dpu_caps sc7180_dpu_caps = {
.has_idle_pc = true,
.max_linewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sm6115_dpu_caps = {
@@ -361,6 +369,8 @@ static const struct dpu_caps sm6115_dpu_caps = {
.has_idle_pc = true,
.max_linewidth = 2160,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sm8150_dpu_caps = {
@@
Re: [PATCH v9 8/8] drm: Remove usage of deprecated DRM_DEBUG_KMS
On Tue, 06 Jun 2023, Laurent Pinchart wrote:
> Hi Siddh,
>
> Thank you for the patch.
>
> On Tue, Jun 06, 2023 at 04:15:22PM +0530, Siddh Raman Pant wrote:
>> drm_print.h says DRM_DEBUG_KMS is deprecated in favor of
>> drm_dbg_kms().
>> ---
>> drivers/gpu/drm/drm_client_modeset.c | 112 +++
>> drivers/gpu/drm/drm_color_mgmt.c | 4 +-
>> drivers/gpu/drm/drm_connector.c | 21 ++---
>> drivers/gpu/drm/drm_crtc.c | 36 -
>> drivers/gpu/drm/drm_crtc_helper.c| 54 ++---
>> drivers/gpu/drm/drm_debugfs_crc.c| 5 +-
>> drivers/gpu/drm/drm_displayid.c | 4 +-
>> drivers/gpu/drm/drm_edid.c | 17 ++--
>> drivers/gpu/drm/drm_lease.c | 2 +-
>> drivers/gpu/drm/drm_mipi_dbi.c | 7 +-
>> drivers/gpu/drm/drm_modes.c | 10 +--
>> drivers/gpu/drm/drm_plane.c | 32
>> drivers/gpu/drm/drm_probe_helper.c | 39 +-
>> drivers/gpu/drm/drm_rect.c | 4 +-
>> drivers/gpu/drm/drm_sysfs.c | 8 +-
>> 15 files changed, 187 insertions(+), 168 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_client_modeset.c
>> b/drivers/gpu/drm/drm_client_modeset.c
>> index e2403b8c6347..4e08ae688b83 100644
>> --- a/drivers/gpu/drm/drm_client_modeset.c
>> +++ b/drivers/gpu/drm/drm_client_modeset.c
>> @@ -242,8 +242,9 @@ static void drm_client_connectors_enabled(struct
>> drm_connector **connectors,
>> for (i = 0; i < connector_count; i++) {
>> connector = connectors[i];
>> enabled[i] = drm_connector_enabled(connector, true);
>> -DRM_DEBUG_KMS("connector %d enabled? %s\n", connector->base.id,
>> - connector->display_info.non_desktop ? "non
>> desktop" : str_yes_no(enabled[i]));
>> +drm_dbg_kms(connector->dev, "connector %d enabled? %s\n",
>> +connector->base.id,
>> +connector->display_info.non_desktop ? "non desktop"
>> : str_yes_no(enabled[i]));
>>
>> any_enabled |= enabled[i];
>> }
>> @@ -303,7 +304,7 @@ static bool drm_client_target_cloned(struct drm_device
>> *dev,
>> }
>>
>> if (can_clone) {
>> -DRM_DEBUG_KMS("can clone using command line\n");
>> +drm_dbg_kms(dev, "can clone using command line\n");
>> return true;
>> }
>>
>> @@ -328,7 +329,7 @@ static bool drm_client_target_cloned(struct drm_device
>> *dev,
>> }
>>
>> if (can_clone) {
>> -DRM_DEBUG_KMS("can clone using 1024x768\n");
>> +drm_dbg_kms(dev, "can clone using 1024x768\n");
>> return true;
>> }
>> drm_info(dev, "kms: can't enable cloning when we probably wanted
>> to.\n");
>> @@ -352,8 +353,9 @@ static int drm_client_get_tile_offsets(struct
>> drm_connector **connectors,
>> continue;
>>
>> if (!modes[i] && (h_idx || v_idx)) {
>> -DRM_DEBUG_KMS("no modes for connector tiled %d %d\n", i,
>> - connector->base.id);
>> +drm_dbg_kms(connector->dev,
>> +"no modes for connector tiled %d %d\n",
>> +i, connector->base.id);
>> continue;
>> }
>> if (connector->tile_h_loc < h_idx)
>> @@ -364,7 +366,8 @@ static int drm_client_get_tile_offsets(struct
>> drm_connector **connectors,
>> }
>> offsets[idx].x = hoffset;
>> offsets[idx].y = voffset;
>> -DRM_DEBUG_KMS("returned %d %d for %d %d\n", hoffset, voffset, h_idx,
>> v_idx);
>> +drm_dbg_kms(NULL, "returned %d %d for %d %d\n",
>> +hoffset, voffset, h_idx, v_idx);
>> return 0;
>> }
>>
>> @@ -421,14 +424,16 @@ static bool drm_client_target_preferred(struct
>> drm_connector **connectors,
>> drm_client_get_tile_offsets(connectors,
>> connector_count, modes, offsets, i,
>> connector->tile_h_loc,
>> connector->tile_v_loc);
>> }
>> -DRM_DEBUG_KMS("looking for cmdline mode on connector %d\n",
>> - connector->base.id);
>> +drm_dbg_kms(connector->dev,
>> +"looking for cmdline mode on connector %d\n",
>> +connector->base.id);
>>
>> /* got for command line mode first */
>> modes[i] = drm_connector_pick_cmdline_mode(connector);
>> if (!modes[i]) {
>> -DRM_DEBUG_KMS("looking for preferred mode on connector
>> %d %d\n",
>> - connector->base.id, connector->tile_group
>> ? connector->tile_group->id : 0);
>> +drm_dbg_kms(connector->dev,
>> +"looking for preferred mode on connector %d
>> %d\n",
>> +
Re: [RFC PATCH v2 10/13] drm/msm/dpu: add list of supported formats to the DPU caps
On 07/06/2023 00:14, Abhinav Kumar wrote:
On 5/24/2023 6:47 PM, Dmitry Baryshkov wrote:
On Thu, 25 May 2023 at 02:16, Abhinav Kumar
wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
As we are going to add virtual planes, add the list of supported
formats
to the hw catalog entry. It will be used to setup universal planes,
with
later selecting a pipe depending on whether the YUV format is used for
the framebuffer.
If your usage of format_list is going to be internal to dpu_plane.c, I
can think of another idea for this change.
This essentially translates to if (num_vig >= 1)
If we can just have a small helper to detect that from the catalog can
we use that instead of adding formats to the dpu caps?
I'd prefer to be explicit here. The list of supported formats might
vary between generations, might it not? Also we don't have a case of
the devices not having VIG planes. Even the qcm2290 (which doesn't
have CSC) lists YUV as supported.
the list of formats is tied to the sspps the dpu generation has and the
capabilities of those sspps.
qcm2290 is really an interesting case. It has one vig sspp but no csc
block for that vig sspp, hence it cannot support non-RGB formats.
I have confirmed that downstream is incorrect to populate yuv formats
for qcm2290.
I still think that having atleast one vig sspp with csc sub-blk is the
right condition to check if we want to decide if the dpu for that
chipset supports yuv formats. Extra csc-blk check to handle qcm2290.
Having a small helper in dpu_plane.c is good enough for that because
with virtual planes, you only need to know "if such a plane exists and
not which plane" and a full catalog change isnt needed IMO
This goes down to the question: is the list of YUV and non-YUV formats
static or not? Do all DPU devices support the same set of YUV and
non-YUV formats? If it is static, we might as well drop
dpu_sspp_sub_blks::format_list.
Note to myself: consider
dpu_mdss_cfg::{dma_formats,cursor_formats,vig_formats}. Either migrate
dpu_sspp_sub_blks::format_list users to these fields or drop them.
Note: I think at some point we should have a closer look at the list
of supported formats and crosscheck that we do not have either
unsupported formats being listed, or missing formats which are not
listed as supported.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 26
+++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 +++
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 212d546b6c5d..2d6944a9679a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -315,6 +315,8 @@ static const struct dpu_caps msm8998_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps qcm2290_dpu_caps = {
@@ -324,6 +326,8 @@ static const struct dpu_caps qcm2290_dpu_caps = {
.has_idle_pc = true,
.max_linewidth = 2160,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sdm845_dpu_caps = {
@@ -339,6 +343,8 @@ static const struct dpu_caps sdm845_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sc7180_dpu_caps = {
@@ -350,6 +356,8 @@ static const struct dpu_caps sc7180_dpu_caps = {
.has_idle_pc = true,
.max_linewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sm6115_dpu_caps = {
@@ -361,6 +369,8 @@ static const struct dpu_caps sm6115_dpu_caps = {
.has_idle_pc = true,
.max_linewidth = 2160,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sm8150_dpu_caps = {
@@ -376,6 +386,8 @@ static const struct dpu_caps sm8150_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sc8180x_dpu_caps = {
@@ -391,6 +403,8 @@ static const struct dpu_caps sc8180x_dpu_caps = {
.pixel_ram_size =
[PATCH] drm/i915/quirk: Add quirk for devices that cannot be dimmed
Cybernet T10C cannot be dimmed without the backlight strobing. Create a
new quirk to lock the minimum brightness to the highest supported value.
This aligns the device with its behavior on Windows, which will not
lower the brightness below maximum.
Signed-off-by: Allen Ballway
---
.../gpu/drm/i915/display/intel_backlight.c| 6 +
drivers/gpu/drm/i915/display/intel_quirks.c | 27 +++
drivers/gpu/drm/i915/display/intel_quirks.h | 1 +
3 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
b/drivers/gpu/drm/i915/display/intel_backlight.c
index 2e8f17c045222..863a33245a3d7 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -1192,6 +1192,11 @@ static u32 get_backlight_min_vbt(struct intel_connector
*connector)
drm_WARN_ON(>drm, panel->backlight.pwm_level_max == 0);
+ if (intel_has_quirk(i915, QUIRK_NO_DIM)) {
+ /* Cannot dim backlight, set minimum to hightest value */
+ return panel->backlight.pwm_level_max - 1;
+ }
+
/*
* XXX: If the vbt value is 255, it makes min equal to max, which leads
* to problems. There are such machines out there. Either our
@@ -1206,6 +1211,7 @@ static u32 get_backlight_min_vbt(struct intel_connector
*connector)
connector->panel.vbt.backlight.min_brightness, min);
}
+
/* vbt value is a coefficient in range [0..255] */
return scale(min, 0, 255, 0, panel->backlight.pwm_level_max);
}
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
b/drivers/gpu/drm/i915/display/intel_quirks.c
index a280448df771a..910c95840a539 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.c
+++ b/drivers/gpu/drm/i915/display/intel_quirks.c
@@ -65,6 +65,12 @@ static void quirk_no_pps_backlight_power_hook(struct
drm_i915_private *i915)
drm_info(>drm, "Applying no pps backlight power quirk\n");
}
+static void quirk_no_dim(struct drm_i915_private *i915)
+{
+ intel_set_quirk(i915, QUIRK_NO_DIM);
+ drm_info(>drm, "Applying no dim quirk\n");
+}
+
struct intel_quirk {
int device;
int subsystem_vendor;
@@ -90,6 +96,12 @@ static int intel_dmi_no_pps_backlight(const struct
dmi_system_id *id)
return 1;
}
+static int intel_dmi_no_dim(const struct dmi_system_id *id)
+{
+ DRM_INFO("No dimming allowed on %s\n", id->ident);
+ return 1;
+}
+
static const struct intel_dmi_quirk intel_dmi_quirks[] = {
{
.dmi_id_list = &(const struct dmi_system_id[]) {
@@ -136,6 +148,20 @@ static const struct intel_dmi_quirk intel_dmi_quirks[] = {
},
.hook = quirk_no_pps_backlight_power_hook,
},
+ {
+ .dmi_id_list = &(const struct dmi_system_id[]) {
+ {
+ .callback = intel_dmi_no_dim,
+ .ident = "Cybernet T10C Tablet",
+ .matches = {DMI_EXACT_MATCH(DMI_BOARD_VENDOR,
+ "Cybernet
Manufacturing Inc."),
+ DMI_EXACT_MATCH(DMI_BOARD_NAME,
"T10C Tablet"),
+ },
+ },
+ { }
+ },
+ .hook = quirk_no_dim,
+ },
};
static struct intel_quirk intel_quirks[] = {
@@ -218,6 +244,7 @@ void intel_init_quirks(struct drm_i915_private *i915)
q->subsystem_device == PCI_ANY_ID))
q->hook(i915);
}
+
for (i = 0; i < ARRAY_SIZE(intel_dmi_quirks); i++) {
if (dmi_check_system(*intel_dmi_quirks[i].dmi_id_list) != 0)
intel_dmi_quirks[i].hook(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.h
b/drivers/gpu/drm/i915/display/intel_quirks.h
index 10a4d163149fd..b41c7bbf0a5e3 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.h
+++ b/drivers/gpu/drm/i915/display/intel_quirks.h
@@ -17,6 +17,7 @@ enum intel_quirk_id {
QUIRK_INVERT_BRIGHTNESS,
QUIRK_LVDS_SSC_DISABLE,
QUIRK_NO_PPS_BACKLIGHT_POWER_HOOK,
+ QUIRK_NO_DIM,
};
void intel_init_quirks(struct drm_i915_private *i915);
--
2.41.0.162.gfafddb0af9-goog
Re: [Freedreno] [PATCH] drm/msm/dpu: re-introduce dpu core revision to the catalog
On 6/6/2023 2:08 PM, Dmitry Baryshkov wrote: On 07/06/2023 00:01, Dmitry Baryshkov wrote: On 06/06/2023 22:28, Abhinav Kumar wrote: On 6/6/2023 12:09 PM, Dmitry Baryshkov wrote: On 06/06/2023 20:51, Abhinav Kumar wrote: On 6/6/2023 4:14 AM, Dmitry Baryshkov wrote: On Tue, 6 Jun 2023 at 05:35, Abhinav Kumar wrote: On 6/5/2023 6:03 PM, Dmitry Baryshkov wrote: On 06/06/2023 03:55, Abhinav Kumar wrote: On 6/3/2023 7:21 PM, Dmitry Baryshkov wrote: On 31/05/2023 21:25, Abhinav Kumar wrote: On 5/31/2023 3:07 AM, Dmitry Baryshkov wrote: On 31/05/2023 06:05, Abhinav Kumar wrote: On 5/30/2023 7:53 PM, Dmitry Baryshkov wrote: On Wed, 31 May 2023 at 03:54, Abhinav Kumar wrote: With [1] dpu core revision was dropped in favor of using the compatible string from the device tree to select the dpu catalog being used in the device. This approach works well however also necessitates adding catalog entries for small register level details as dpu capabilities and/or features bloating the catalog unnecessarily. Examples include but are not limited to data_compress, interrupt register set, widebus etc. Introduce the dpu core revision back as an entry to the catalog so that we can just use dpu revision checks and enable those bits which should be enabled unconditionally and not controlled by a catalog and also simplify the changes to do something like: if (dpu_core_revision > x && dpu_core_revision < x) enable the bit; Also, add some of the useful macros back to be able to use dpu core revision effectively. [1]: https://patchwork.freedesktop.org/patch/530891/?series=113910=4 Signed-off-by: Abhinav Kumar --- .../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 1 + .../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 1 + .../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 1 + .../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 1 + .../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 1 + .../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 1 + .../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 1 + .../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 1 + .../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 1 + .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 31 ++- 14 files changed, 43 insertions(+), 1 deletion(-) [skipped catalog changes] diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h index 677048cc3b7d..cc4aa75a1219 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h @@ -19,6 +19,33 @@ */ #define MAX_BLOCKS 12 +#define DPU_HW_VER(MAJOR, MINOR, STEP)\ + unsigned int)MAJOR & 0xF) << 28) |\ + ((MINOR & 0xFFF) << 16) |\ + (STEP & 0x)) + +#define DPU_HW_MAJOR(rev)((rev) >> 28) +#define DPU_HW_MINOR(rev)(((rev) >> 16) & 0xFFF) +#define DPU_HW_STEP(rev)((rev) & 0x) +#define DPU_HW_MAJOR_MINOR(rev)((rev) >> 16) + +#define IS_DPU_MAJOR_MINOR_SAME(rev1, rev2) \ +(DPU_HW_MAJOR_MINOR((rev1)) == DPU_HW_MAJOR_MINOR((rev2))) + +#define DPU_HW_VER_300 DPU_HW_VER(3, 0, 0) /* 8998 v1.0 */ +#define DPU_HW_VER_400 DPU_HW_VER(4, 0, 0) /* sdm845 v1.0 */ +#define DPU_HW_VER_500 DPU_HW_VER(5, 0, 0) /* sm8150 v1.0 */ +#define DPU_HW_VER_510 DPU_HW_VER(5, 1, 1) /* sc8180 */ +#define DPU_HW_VER_600 DPU_HW_VER(6, 0, 0) /* sm8250 */ +#define DPU_HW_VER_620 DPU_HW_VER(6, 2, 0) /* sc7180 v1.0 */ +#define DPU_HW_VER_630 DPU_HW_VER(6, 3, 0) /* sm6115|sm4250 */ +#define DPU_HW_VER_650 DPU_HW_VER(6, 5, 0) /* qcm2290|sm4125 */ +#define DPU_HW_VER_700 DPU_HW_VER(7, 0, 0) /* sm8350 */ +#define DPU_HW_VER_720 DPU_HW_VER(7, 2, 0) /* sc7280 */ +#define DPU_HW_VER_800 DPU_HW_VER(8, 0, 0) /* sc8280xp */ +#define DPU_HW_VER_810 DPU_HW_VER(8, 1, 0) /* sm8450 */ +#define DPU_HW_VER_900 DPU_HW_VER(9, 0, 0) /* sm8550 */ Instead of having defines for all SoCs (which can quickly become unmanageable) and can cause merge conflicts, I'd suggest inlining all the defines into respective catalog files. Sure, that can be done. Also, I'm not sure that the "step" should be a part of the catalog. I know that this follows the hardware revision. However, please correct me if I'm wrong, different step levels are used for revisions of the same SoC. The original code that was reading the hw revision from the hardware register, listed both 5.0.0 and 5.0.1 for sm8150. This is one of the things i noticed while making this change. Before the catalog rework, we used to handle even steps as we used to read that from the register and match it with the mdss_cfg handler. But after the rework, we dont handle steps anymore. Yes, you are right that different step levels are
Re: [RFC PATCH v2 10/13] drm/msm/dpu: add list of supported formats to the DPU caps
On 5/24/2023 6:47 PM, Dmitry Baryshkov wrote:
On Thu, 25 May 2023 at 02:16, Abhinav Kumar wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
As we are going to add virtual planes, add the list of supported formats
to the hw catalog entry. It will be used to setup universal planes, with
later selecting a pipe depending on whether the YUV format is used for
the framebuffer.
If your usage of format_list is going to be internal to dpu_plane.c, I
can think of another idea for this change.
This essentially translates to if (num_vig >= 1)
If we can just have a small helper to detect that from the catalog can
we use that instead of adding formats to the dpu caps?
I'd prefer to be explicit here. The list of supported formats might
vary between generations, might it not? Also we don't have a case of
the devices not having VIG planes. Even the qcm2290 (which doesn't
have CSC) lists YUV as supported.
the list of formats is tied to the sspps the dpu generation has and the
capabilities of those sspps.
qcm2290 is really an interesting case. It has one vig sspp but no csc
block for that vig sspp, hence it cannot support non-RGB formats.
I have confirmed that downstream is incorrect to populate yuv formats
for qcm2290.
I still think that having atleast one vig sspp with csc sub-blk is the
right condition to check if we want to decide if the dpu for that
chipset supports yuv formats. Extra csc-blk check to handle qcm2290.
Having a small helper in dpu_plane.c is good enough for that because
with virtual planes, you only need to know "if such a plane exists and
not which plane" and a full catalog change isnt needed IMO
Note: I think at some point we should have a closer look at the list
of supported formats and crosscheck that we do not have either
unsupported formats being listed, or missing formats which are not
listed as supported.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 26 +++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 4 +++
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 212d546b6c5d..2d6944a9679a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -315,6 +315,8 @@ static const struct dpu_caps msm8998_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps qcm2290_dpu_caps = {
@@ -324,6 +326,8 @@ static const struct dpu_caps qcm2290_dpu_caps = {
.has_idle_pc = true,
.max_linewidth = 2160,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sdm845_dpu_caps = {
@@ -339,6 +343,8 @@ static const struct dpu_caps sdm845_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sc7180_dpu_caps = {
@@ -350,6 +356,8 @@ static const struct dpu_caps sc7180_dpu_caps = {
.has_idle_pc = true,
.max_linewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sm6115_dpu_caps = {
@@ -361,6 +369,8 @@ static const struct dpu_caps sm6115_dpu_caps = {
.has_idle_pc = true,
.max_linewidth = 2160,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sm8150_dpu_caps = {
@@ -376,6 +386,8 @@ static const struct dpu_caps sm8150_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sc8180x_dpu_caps = {
@@ -391,6 +403,8 @@ static const struct dpu_caps sc8180x_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_hdeci_exp = MAX_HORZ_DECIMATION,
.max_vdeci_exp = MAX_VERT_DECIMATION,
+ .format_list = plane_formats_yuv,
+ .num_formats = ARRAY_SIZE(plane_formats_yuv),
};
static const struct dpu_caps sc8280xp_dpu_caps = {
@@ -404,6 +418,8 @@ static const struct dpu_caps sc8280xp_dpu_caps = {
.has_3d_merge = true,
.max_linewidth = 5120,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+
Re: [Freedreno] [PATCH] drm/msm/dpu: re-introduce dpu core revision to the catalog
On 07/06/2023 00:01, Dmitry Baryshkov wrote: On 06/06/2023 22:28, Abhinav Kumar wrote: On 6/6/2023 12:09 PM, Dmitry Baryshkov wrote: On 06/06/2023 20:51, Abhinav Kumar wrote: On 6/6/2023 4:14 AM, Dmitry Baryshkov wrote: On Tue, 6 Jun 2023 at 05:35, Abhinav Kumar wrote: On 6/5/2023 6:03 PM, Dmitry Baryshkov wrote: On 06/06/2023 03:55, Abhinav Kumar wrote: On 6/3/2023 7:21 PM, Dmitry Baryshkov wrote: On 31/05/2023 21:25, Abhinav Kumar wrote: On 5/31/2023 3:07 AM, Dmitry Baryshkov wrote: On 31/05/2023 06:05, Abhinav Kumar wrote: On 5/30/2023 7:53 PM, Dmitry Baryshkov wrote: On Wed, 31 May 2023 at 03:54, Abhinav Kumar wrote: With [1] dpu core revision was dropped in favor of using the compatible string from the device tree to select the dpu catalog being used in the device. This approach works well however also necessitates adding catalog entries for small register level details as dpu capabilities and/or features bloating the catalog unnecessarily. Examples include but are not limited to data_compress, interrupt register set, widebus etc. Introduce the dpu core revision back as an entry to the catalog so that we can just use dpu revision checks and enable those bits which should be enabled unconditionally and not controlled by a catalog and also simplify the changes to do something like: if (dpu_core_revision > x && dpu_core_revision < x) enable the bit; Also, add some of the useful macros back to be able to use dpu core revision effectively. [1]: https://patchwork.freedesktop.org/patch/530891/?series=113910=4 Signed-off-by: Abhinav Kumar --- .../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 1 + .../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 1 + .../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 1 + .../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 1 + .../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 1 + .../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 1 + .../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 1 + .../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 1 + .../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 1 + .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 31 ++- 14 files changed, 43 insertions(+), 1 deletion(-) [skipped catalog changes] diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h index 677048cc3b7d..cc4aa75a1219 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h @@ -19,6 +19,33 @@ */ #define MAX_BLOCKS 12 +#define DPU_HW_VER(MAJOR, MINOR, STEP)\ + unsigned int)MAJOR & 0xF) << 28) |\ + ((MINOR & 0xFFF) << 16) |\ + (STEP & 0x)) + +#define DPU_HW_MAJOR(rev)((rev) >> 28) +#define DPU_HW_MINOR(rev)(((rev) >> 16) & 0xFFF) +#define DPU_HW_STEP(rev)((rev) & 0x) +#define DPU_HW_MAJOR_MINOR(rev)((rev) >> 16) + +#define IS_DPU_MAJOR_MINOR_SAME(rev1, rev2) \ +(DPU_HW_MAJOR_MINOR((rev1)) == DPU_HW_MAJOR_MINOR((rev2))) + +#define DPU_HW_VER_300 DPU_HW_VER(3, 0, 0) /* 8998 v1.0 */ +#define DPU_HW_VER_400 DPU_HW_VER(4, 0, 0) /* sdm845 v1.0 */ +#define DPU_HW_VER_500 DPU_HW_VER(5, 0, 0) /* sm8150 v1.0 */ +#define DPU_HW_VER_510 DPU_HW_VER(5, 1, 1) /* sc8180 */ +#define DPU_HW_VER_600 DPU_HW_VER(6, 0, 0) /* sm8250 */ +#define DPU_HW_VER_620 DPU_HW_VER(6, 2, 0) /* sc7180 v1.0 */ +#define DPU_HW_VER_630 DPU_HW_VER(6, 3, 0) /* sm6115|sm4250 */ +#define DPU_HW_VER_650 DPU_HW_VER(6, 5, 0) /* qcm2290|sm4125 */ +#define DPU_HW_VER_700 DPU_HW_VER(7, 0, 0) /* sm8350 */ +#define DPU_HW_VER_720 DPU_HW_VER(7, 2, 0) /* sc7280 */ +#define DPU_HW_VER_800 DPU_HW_VER(8, 0, 0) /* sc8280xp */ +#define DPU_HW_VER_810 DPU_HW_VER(8, 1, 0) /* sm8450 */ +#define DPU_HW_VER_900 DPU_HW_VER(9, 0, 0) /* sm8550 */ Instead of having defines for all SoCs (which can quickly become unmanageable) and can cause merge conflicts, I'd suggest inlining all the defines into respective catalog files. Sure, that can be done. Also, I'm not sure that the "step" should be a part of the catalog. I know that this follows the hardware revision. However, please correct me if I'm wrong, different step levels are used for revisions of the same SoC. The original code that was reading the hw revision from the hardware register, listed both 5.0.0 and 5.0.1 for sm8150. This is one of the things i noticed while making this change. Before the catalog rework, we used to handle even steps as we used to read that from the register and match it with the mdss_cfg handler. But after the rework, we dont handle steps anymore. Yes, you are right that different step levels are used for the revisions of the same SOC and so with
Re: [Freedreno] [PATCH] drm/msm/dpu: re-introduce dpu core revision to the catalog
On 06/06/2023 22:28, Abhinav Kumar wrote: On 6/6/2023 12:09 PM, Dmitry Baryshkov wrote: On 06/06/2023 20:51, Abhinav Kumar wrote: On 6/6/2023 4:14 AM, Dmitry Baryshkov wrote: On Tue, 6 Jun 2023 at 05:35, Abhinav Kumar wrote: On 6/5/2023 6:03 PM, Dmitry Baryshkov wrote: On 06/06/2023 03:55, Abhinav Kumar wrote: On 6/3/2023 7:21 PM, Dmitry Baryshkov wrote: On 31/05/2023 21:25, Abhinav Kumar wrote: On 5/31/2023 3:07 AM, Dmitry Baryshkov wrote: On 31/05/2023 06:05, Abhinav Kumar wrote: On 5/30/2023 7:53 PM, Dmitry Baryshkov wrote: On Wed, 31 May 2023 at 03:54, Abhinav Kumar wrote: With [1] dpu core revision was dropped in favor of using the compatible string from the device tree to select the dpu catalog being used in the device. This approach works well however also necessitates adding catalog entries for small register level details as dpu capabilities and/or features bloating the catalog unnecessarily. Examples include but are not limited to data_compress, interrupt register set, widebus etc. Introduce the dpu core revision back as an entry to the catalog so that we can just use dpu revision checks and enable those bits which should be enabled unconditionally and not controlled by a catalog and also simplify the changes to do something like: if (dpu_core_revision > x && dpu_core_revision < x) enable the bit; Also, add some of the useful macros back to be able to use dpu core revision effectively. [1]: https://patchwork.freedesktop.org/patch/530891/?series=113910=4 Signed-off-by: Abhinav Kumar --- .../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 1 + .../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 1 + .../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 1 + .../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 1 + .../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 1 + .../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 1 + .../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 1 + .../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 1 + .../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 1 + .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 31 ++- 14 files changed, 43 insertions(+), 1 deletion(-) [skipped catalog changes] diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h index 677048cc3b7d..cc4aa75a1219 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h @@ -19,6 +19,33 @@ */ #define MAX_BLOCKS 12 +#define DPU_HW_VER(MAJOR, MINOR, STEP)\ + unsigned int)MAJOR & 0xF) << 28) |\ + ((MINOR & 0xFFF) << 16) |\ + (STEP & 0x)) + +#define DPU_HW_MAJOR(rev)((rev) >> 28) +#define DPU_HW_MINOR(rev)(((rev) >> 16) & 0xFFF) +#define DPU_HW_STEP(rev)((rev) & 0x) +#define DPU_HW_MAJOR_MINOR(rev)((rev) >> 16) + +#define IS_DPU_MAJOR_MINOR_SAME(rev1, rev2) \ +(DPU_HW_MAJOR_MINOR((rev1)) == DPU_HW_MAJOR_MINOR((rev2))) + +#define DPU_HW_VER_300 DPU_HW_VER(3, 0, 0) /* 8998 v1.0 */ +#define DPU_HW_VER_400 DPU_HW_VER(4, 0, 0) /* sdm845 v1.0 */ +#define DPU_HW_VER_500 DPU_HW_VER(5, 0, 0) /* sm8150 v1.0 */ +#define DPU_HW_VER_510 DPU_HW_VER(5, 1, 1) /* sc8180 */ +#define DPU_HW_VER_600 DPU_HW_VER(6, 0, 0) /* sm8250 */ +#define DPU_HW_VER_620 DPU_HW_VER(6, 2, 0) /* sc7180 v1.0 */ +#define DPU_HW_VER_630 DPU_HW_VER(6, 3, 0) /* sm6115|sm4250 */ +#define DPU_HW_VER_650 DPU_HW_VER(6, 5, 0) /* qcm2290|sm4125 */ +#define DPU_HW_VER_700 DPU_HW_VER(7, 0, 0) /* sm8350 */ +#define DPU_HW_VER_720 DPU_HW_VER(7, 2, 0) /* sc7280 */ +#define DPU_HW_VER_800 DPU_HW_VER(8, 0, 0) /* sc8280xp */ +#define DPU_HW_VER_810 DPU_HW_VER(8, 1, 0) /* sm8450 */ +#define DPU_HW_VER_900 DPU_HW_VER(9, 0, 0) /* sm8550 */ Instead of having defines for all SoCs (which can quickly become unmanageable) and can cause merge conflicts, I'd suggest inlining all the defines into respective catalog files. Sure, that can be done. Also, I'm not sure that the "step" should be a part of the catalog. I know that this follows the hardware revision. However, please correct me if I'm wrong, different step levels are used for revisions of the same SoC. The original code that was reading the hw revision from the hardware register, listed both 5.0.0 and 5.0.1 for sm8150. This is one of the things i noticed while making this change. Before the catalog rework, we used to handle even steps as we used to read that from the register and match it with the mdss_cfg handler. But after the rework, we dont handle steps anymore. Yes, you are right that different step levels are used for the revisions of the same SOC and so with that, i dont expect or atleast am not aware of
Re: [PATCH v2] drm/i915: Fix a VMA UAF for multi-gt platform
Hi Nirmoy,
On Tue, Jun 06, 2023 at 10:27:55PM +0200, Nirmoy Das wrote:
> Ensure correct handling of closed VMAs on multi-gt platforms to prevent
> Use-After-Free. Currently, when GT0 goes idle, closed VMAs that are
> exclusively added to GT0's closed_vma link (gt->closed_vma) and
> subsequently freed by i915_vma_parked(), which assumes the entire GPU is
> idle. However, on platforms with multiple GTs, such as MTL, GT1 may
> remain active while GT0 is idle. This causes GT0 to mistakenly consider
> the closed VMAs in its closed_vma list as unnecessary, potentially
> leading to Use-After-Free issues if a job for GT1 attempts to access a
> freed VMA.
>
> Although we do take a wakeref for GT0 but it happens later, after
> evaluating VMAs. To mitigate this, it is necessary to hold a GT0 wakeref
> early.
>
> v2: Use gt id to detect multi-tile(Andi)
> Fix the incorrect error path.
>
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Tvrtko Ursulin
> Cc: Thomas Hellström
> Cc: Chris Wilson
> Cc: Andi Shyti
> Cc: Andrzej Hajda
> Cc: Sushma Venkatesh Reddy
> Tested-by: Andi Shyti
> Signed-off-by: Nirmoy Das
I wonder if we need any Fixes tag here, maybe this:
Fixes: d93939730347 ("drm/i915: Remove the vma refcount")
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 3aeede6aee4d..c2a67435acfa 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2683,6 +2683,7 @@ static int
> eb_select_engine(struct i915_execbuffer *eb)
> {
> struct intel_context *ce, *child;
> + struct intel_gt *gt;
> unsigned int idx;
> int err;
>
> @@ -2706,10 +2707,16 @@ eb_select_engine(struct i915_execbuffer *eb)
> }
> }
> eb->num_batches = ce->parallel.number_children + 1;
> + gt = ce->engine->gt;
>
> for_each_child(ce, child)
> intel_context_get(child);
> intel_gt_pm_get(ce->engine->gt);
> + /* Keep GT0 active on MTL so that i915_vma_parked() doesn't
> + * free VMAs while execbuf ioctl is validating VMAs.
> + */
> + if (gt->info.id)
> + intel_gt_pm_get(to_gt(gt->i915));
>
> if (!test_bit(CONTEXT_ALLOC_BIT, >flags)) {
> err = intel_context_alloc_state(ce);
> @@ -2748,6 +2755,9 @@ eb_select_engine(struct i915_execbuffer *eb)
> return err;
>
> err:
> + if (gt->info.id)
> + intel_gt_pm_put(to_gt(gt->i915));
> +
> intel_gt_pm_put(ce->engine->gt);
> for_each_child(ce, child)
> intel_context_put(child);
> @@ -2761,6 +2771,8 @@ eb_put_engine(struct i915_execbuffer *eb)
> struct intel_context *child;
>
> i915_vm_put(eb->context->vm);
> + if (eb->gt->info.id)
> + intel_gt_pm_put(to_gt(eb->gt->i915));
> intel_gt_pm_put(eb->gt);
I would add a comment up here, just not to scare people when they
see this.
Reviewed-by: Andi Shyti
Andi
> for_each_child(eb->context, child)
> intel_context_put(child);
> --
> 2.39.0
Re: [PATCH v5 00/13] Enable Colorspace connector property in amdgpu
Thanks Harry. Looks good. Reviewed-by: Joshua Ashton - Joshie ✨ On 6/6/23 21:25, Harry Wentland wrote: This patchset is based on Joshua's previous patchset [1], as well as my previous patchset [2]. It is - enabling support for the colorspace property in amdgpu, as well as - allowing drivers to specify the supported set of colorspaces, and Colorspace, Infoframes, and YCbCr matrix --- Even though the initial intent of the colorspace property was to set the colorspace field in the respective HDMI AVI and DP SDP infoframes that is not sufficient in all scenarios. For DP the colorspace information also affects the MSA (main stream attribute) packet. For YUV output the colorspace affects the RGB-to-YCbCr conversion matrix. The colorspace field of the infopackets also depends on the encoding used, which is something that is decided by the driver and not known to userspace. For these reasons a driver will need to be able to select the supported colorspaces at property creation. Note: There seems to be an understanding that the colorspace property should ONLY modify the infoframe. While this is current behavior and sufficient in some cases it is nowhere specified that this should be the only use of this property. As outlined above this limitation is not going to work in all cases. This patchset does not affect current behavior for the drivers that implement this property: i915 and vc4. In the future we might want to give userspace control over the encoding format on the wire, in particular to avoid use of YUV420 when image fidelity is important. This work would likely go hand in hand with a min_bpc property and wouldn't conflict with the work done in this patchset. I would expect this future work to tag along with a drm_crtc or drm_connector's Color Pipeline, similar to the one propsed for drm_plane [3]. Colorspace on crtc or connector? There have been suggestions of programming 'colorspace' on the drm_crtc but I don't think the crtc is the right place for this property. The drm_plane and drm_crtc will be used to offload color processing that would normally be done via the GFX or other pipelines. The drm_connector controls the signalling with the display and ensures the wire format is appropriate for the encoding by programming the RGB-to-YCbCr matrix. [1] https://patchwork.freedesktop.org/series/113632/ [2] https://patchwork.freedesktop.org/series/111865/ [3] https://lists.freedesktop.org/archives/dri-devel/2023-May/403173.html v2: - Tested with DP and HDMI analyzers - Confirmed driver will fallback to lower bpc when needed - Dropped hunk to set HDMI AVI infoframe as it was a no-op - Fixed BT.2020 YCbCr colorimetry (JoshuaAshton) - Simplify initialization of supported colorspaces (Jani) - Fix kerneldoc (kernel test robot) v3: - Added documentation for colorspaces (Pekka, Joshua) - Split 'Allow drivers to pass list of supported colorspaces' patch to pull out code to create common colorspace array and keep it separate from change to create only supported colorspaces v4: - Don't "deprecate" existing enum values - Fixes based on review comments throughout - Dropped Josh's RBs v5: - Add documentation that drivers are free to pick appropriate RGB or YCC variant Cc: Pekka Paalanen Cc: Sebastian Wick Cc: vitaly.pros...@amd.com Cc: Uma Shankar Cc: Ville Syrjälä Cc: Joshua Ashton Cc: Jani Nikula Cc: Michel Dänzer Cc: Simon Ser Cc: Melissa Wen Cc: dri-devel@lists.freedesktop.org Cc: amd-...@lists.freedesktop.org Harry Wentland (10): drm/connector: Convert DRM_MODE_COLORIMETRY to enum drm/connector: Pull out common create_colorspace_property code drm/connector: Use common colorspace_names array drm/connector: Print connector colorspace in state debugfs drm/connector: Allow drivers to pass list of supported colorspaces drm/amd/display: Always pass connector_state to stream validation drm/amd/display: Register Colorspace property for DP and HDMI drm/amd/display: Signal mode_changed if colorspace changed drm/amd/display: Send correct DP colorspace infopacket drm/amd/display: Add debugfs for testing output colorspace Joshua Ashton (3): drm/connector: Add enum documentation to drm_colorspace drm/amd/display: Always set crtcinfo from create_stream_for_sink drm/amd/display: Refactor avi_info_frame colorimetry determination .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 84 ++--- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 57 ++ .../gpu/drm/amd/display/dc/core/dc_resource.c | 28 +-- drivers/gpu/drm/drm_atomic.c | 1 + drivers/gpu/drm/drm_connector.c | 176 +++--- .../gpu/drm/i915/display/intel_connector.c| 4 +- drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +- include/drm/display/drm_dp.h | 2 +- include/drm/drm_connector.h | 129 ++--- 9 files changed,
Re: [Freedreno] [RFC PATCH v2 04/13] drm/msm/dpu: remove unused fields from dpu_encoder_virt
On 6/6/2023 1:29 PM, Dmitry Baryshkov wrote:
On 06/06/2023 23:25, Abhinav Kumar wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
Remove historical fields intfs_swapped and topology fields from struct
dpu_encoder_virt and also remove even more historical docs.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 28729c77364f..4ee708264f3b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -130,18 +130,12 @@ enum dpu_enc_rc_states {
* pingpong blocks can be different than num_phys_encs.
* @hw_dsc: Handle to the DSC blocks used for the display.
* @dsc_mask: Bitmask of used DSC blocks.
- * @intfs_swapped: Whether or not the phys_enc interfaces have
been swapped
- * for partial update right-only cases, such as pingpong
- * split where virtual pingpong does not generate IRQs
* @crtc: Pointer to the currently assigned crtc. Normally you
* would use crtc->state->encoder_mask to determine the
* link between encoder/crtc. However in this case we need
* to track crtc in the disable() hook which is called
* _after_ encoder_mask is cleared.
* @connector: If a mode is set, cached pointer to the
active connector
- * @crtc_kickoff_cb: Callback into CRTC that will flush & start
- * all CTL paths
- * @crtc_kickoff_cb_data: Opaque user data given to crtc_kickoff_cb
no concerns with the above 3
* @enc_lock: Lock around physical encoder
* create/destroy/enable/disable
* @frame_busy_mask: Bitmask tracking which phys_enc we are
still
@@ -160,7 +154,6 @@ enum dpu_enc_rc_states {
* @delayed_off_work: delayed worker to schedule disabling of
* clks and resources after IDLE_TIMEOUT time.
* @vsync_event_work: worker to handle vsync event for
autorefresh
- * @topology: topology of the display
As we are still going to go ahead with encoder based allocation for
now, we should keep this topology and start using it for DP DSC's
1:1:1 topology.
It is currently unused, so it can be dropped. Your patchset would have
to reintroduce it.
Ok same old argument which I tend to always lose. We will add it back
with DP DSC.
And I'm still not happy about the encoder-based allocation. You
persuaded me that it is irrelevant for the wide planes. So I'd split it
and post the allocation patchset after the virtual-wide is fully
reviewed (when would come that blissful moment, btw?).
Post the allocation with a compelling feature for us to be convinced.
The moment is happening as we speak :)
* @idle_timeout: idle timeout duration in milliseconds
* @wide_bus_en: wide bus is enabled on this interface
* @dsc: drm_dsc_config pointer, for DSC-enabled encoders
@@ -180,8 +173,6 @@ struct dpu_encoder_virt {
unsigned int dsc_mask;
- bool intfs_swapped;
-
struct drm_crtc *crtc;
struct drm_connector *connector;
@@ -201,7 +192,6 @@ struct dpu_encoder_virt {
enum dpu_enc_rc_states rc_state;
struct delayed_work delayed_off_work;
struct kthread_work vsync_event_work;
- struct msm_display_topology topology;
u32 idle_timeout;
Re: [Freedreno] [RFC PATCH v2 04/13] drm/msm/dpu: remove unused fields from dpu_encoder_virt
On 06/06/2023 23:25, Abhinav Kumar wrote:
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
Remove historical fields intfs_swapped and topology fields from struct
dpu_encoder_virt and also remove even more historical docs.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 28729c77364f..4ee708264f3b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -130,18 +130,12 @@ enum dpu_enc_rc_states {
* pingpong blocks can be different than num_phys_encs.
* @hw_dsc: Handle to the DSC blocks used for the display.
* @dsc_mask: Bitmask of used DSC blocks.
- * @intfs_swapped: Whether or not the phys_enc interfaces have
been swapped
- * for partial update right-only cases, such as pingpong
- * split where virtual pingpong does not generate IRQs
* @crtc: Pointer to the currently assigned crtc. Normally you
* would use crtc->state->encoder_mask to determine the
* link between encoder/crtc. However in this case we need
* to track crtc in the disable() hook which is called
* _after_ encoder_mask is cleared.
* @connector: If a mode is set, cached pointer to the active
connector
- * @crtc_kickoff_cb: Callback into CRTC that will flush & start
- * all CTL paths
- * @crtc_kickoff_cb_data: Opaque user data given to crtc_kickoff_cb
no concerns with the above 3
* @enc_lock: Lock around physical encoder
* create/destroy/enable/disable
* @frame_busy_mask: Bitmask tracking which phys_enc we are
still
@@ -160,7 +154,6 @@ enum dpu_enc_rc_states {
* @delayed_off_work: delayed worker to schedule disabling of
* clks and resources after IDLE_TIMEOUT time.
* @vsync_event_work: worker to handle vsync event for
autorefresh
- * @topology: topology of the display
As we are still going to go ahead with encoder based allocation for now,
we should keep this topology and start using it for DP DSC's 1:1:1
topology.
It is currently unused, so it can be dropped. Your patchset would have
to reintroduce it.
And I'm still not happy about the encoder-based allocation. You
persuaded me that it is irrelevant for the wide planes. So I'd split it
and post the allocation patchset after the virtual-wide is fully
reviewed (when would come that blissful moment, btw?).
* @idle_timeout: idle timeout duration in milliseconds
* @wide_bus_en: wide bus is enabled on this interface
* @dsc: drm_dsc_config pointer, for DSC-enabled encoders
@@ -180,8 +173,6 @@ struct dpu_encoder_virt {
unsigned int dsc_mask;
- bool intfs_swapped;
-
struct drm_crtc *crtc;
struct drm_connector *connector;
@@ -201,7 +192,6 @@ struct dpu_encoder_virt {
enum dpu_enc_rc_states rc_state;
struct delayed_work delayed_off_work;
struct kthread_work vsync_event_work;
- struct msm_display_topology topology;
u32 idle_timeout;
--
With best wishes
Dmitry
[PATCH v2] drm/i915: Fix a VMA UAF for multi-gt platform
Ensure correct handling of closed VMAs on multi-gt platforms to prevent
Use-After-Free. Currently, when GT0 goes idle, closed VMAs that are
exclusively added to GT0's closed_vma link (gt->closed_vma) and
subsequently freed by i915_vma_parked(), which assumes the entire GPU is
idle. However, on platforms with multiple GTs, such as MTL, GT1 may
remain active while GT0 is idle. This causes GT0 to mistakenly consider
the closed VMAs in its closed_vma list as unnecessary, potentially
leading to Use-After-Free issues if a job for GT1 attempts to access a
freed VMA.
Although we do take a wakeref for GT0 but it happens later, after
evaluating VMAs. To mitigate this, it is necessary to hold a GT0 wakeref
early.
v2: Use gt id to detect multi-tile(Andi)
Fix the incorrect error path.
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Thomas Hellström
Cc: Chris Wilson
Cc: Andi Shyti
Cc: Andrzej Hajda
Cc: Sushma Venkatesh Reddy
Tested-by: Andi Shyti
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 3aeede6aee4d..c2a67435acfa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2683,6 +2683,7 @@ static int
eb_select_engine(struct i915_execbuffer *eb)
{
struct intel_context *ce, *child;
+ struct intel_gt *gt;
unsigned int idx;
int err;
@@ -2706,10 +2707,16 @@ eb_select_engine(struct i915_execbuffer *eb)
}
}
eb->num_batches = ce->parallel.number_children + 1;
+ gt = ce->engine->gt;
for_each_child(ce, child)
intel_context_get(child);
intel_gt_pm_get(ce->engine->gt);
+ /* Keep GT0 active on MTL so that i915_vma_parked() doesn't
+* free VMAs while execbuf ioctl is validating VMAs.
+*/
+ if (gt->info.id)
+ intel_gt_pm_get(to_gt(gt->i915));
if (!test_bit(CONTEXT_ALLOC_BIT, >flags)) {
err = intel_context_alloc_state(ce);
@@ -2748,6 +2755,9 @@ eb_select_engine(struct i915_execbuffer *eb)
return err;
err:
+ if (gt->info.id)
+ intel_gt_pm_put(to_gt(gt->i915));
+
intel_gt_pm_put(ce->engine->gt);
for_each_child(ce, child)
intel_context_put(child);
@@ -2761,6 +2771,8 @@ eb_put_engine(struct i915_execbuffer *eb)
struct intel_context *child;
i915_vm_put(eb->context->vm);
+ if (eb->gt->info.id)
+ intel_gt_pm_put(to_gt(eb->gt->i915));
intel_gt_pm_put(eb->gt);
for_each_child(eb->context, child)
intel_context_put(child);
--
2.39.0
Re: [Freedreno] [RFC PATCH v2 09/13] drm/msm/dpu: move pstate->pipe initialization to dpu_plane_atomic_check
On 5/24/2023 6:40 PM, Dmitry Baryshkov wrote: On Thu, 25 May 2023 at 02:04, Abhinav Kumar wrote: On 5/24/2023 3:46 PM, Abhinav Kumar wrote: On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote: In preparation to virtualized planes support, move pstate->pipe initialization from dpu_plane_reset() to dpu_plane_atomic_check(). In case of virtual planes the plane's pipe will not be known up to the point of atomic_check() callback. Signed-off-by: Dmitry Baryshkov --- Will legacy paths be broken with this? So lets say there is no atomic_check we will not have a valid sspp anymore. I think it should still work, even if goes through the modeset crtc, it should still call drm_atomic_commit() internally which should have the call to atomic_check, once you confirm this , i can ack this particular change. Can you please describe the scenario you have in mind? If I got you correctly, you were asking about the non-commit IOCTLs. Because of the atomic helpers being used (e.g. drm_atomic_helper_set_config()), they will also result in a call to drm_atomic_commit(), which invokes drm_atomic_check_only(). Yes, that was pretty much the scenario I was referring to, thanks for confirming.
[PATCH v5 13/13] drm/amd/display: Refactor avi_info_frame colorimetry determination
From: Joshua Ashton
Replace the messy two if-else chains here that were
on the same value with a switch on the enum.
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: Simon Ser
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Reviewed-by: Harry Wentland
---
.../gpu/drm/amd/display/dc/core/dc_resource.c | 28 +++
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index c72540d37aef..2f3d9a698486 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -3035,23 +3035,29 @@ static void set_avi_info_frame(
hdmi_info.bits.S0_S1 = scan_type;
/* C0, C1 : Colorimetry */
- if (color_space == COLOR_SPACE_YCBCR709 ||
- color_space == COLOR_SPACE_YCBCR709_LIMITED)
+ switch (color_space) {
+ case COLOR_SPACE_YCBCR709:
+ case COLOR_SPACE_YCBCR709_LIMITED:
hdmi_info.bits.C0_C1 = COLORIMETRY_ITU709;
- else if (color_space == COLOR_SPACE_YCBCR601 ||
- color_space == COLOR_SPACE_YCBCR601_LIMITED)
+ break;
+ case COLOR_SPACE_YCBCR601:
+ case COLOR_SPACE_YCBCR601_LIMITED:
hdmi_info.bits.C0_C1 = COLORIMETRY_ITU601;
- else {
- hdmi_info.bits.C0_C1 = COLORIMETRY_NO_DATA;
- }
- if (color_space == COLOR_SPACE_2020_RGB_FULLRANGE ||
- color_space == COLOR_SPACE_2020_RGB_LIMITEDRANGE ||
- color_space == COLOR_SPACE_2020_YCBCR) {
+ break;
+ case COLOR_SPACE_2020_RGB_FULLRANGE:
+ case COLOR_SPACE_2020_RGB_LIMITEDRANGE:
+ case COLOR_SPACE_2020_YCBCR:
hdmi_info.bits.EC0_EC2 = COLORIMETRYEX_BT2020RGBYCBCR;
hdmi_info.bits.C0_C1 = COLORIMETRY_EXTENDED;
- } else if (color_space == COLOR_SPACE_ADOBERGB) {
+ break;
+ case COLOR_SPACE_ADOBERGB:
hdmi_info.bits.EC0_EC2 = COLORIMETRYEX_ADOBERGB;
hdmi_info.bits.C0_C1 = COLORIMETRY_EXTENDED;
+ break;
+ case COLOR_SPACE_SRGB:
+ default:
+ hdmi_info.bits.C0_C1 = COLORIMETRY_NO_DATA;
+ break;
}
if (pixel_encoding && color_space == COLOR_SPACE_2020_YCBCR &&
--
2.41.0
[PATCH v5 12/13] drm/amd/display: Add debugfs for testing output colorspace
In order to IGT test colorspace we'll want to print
the currently enabled colorspace on a stream. We add
a new debugfs to do so, using the same scheme as
current bpc reporting.
This might also come in handy when debugging display
issues.
v4:
- Fix function doc comment
- Fix sRGB debug print
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: Simon Ser
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 57 +++
1 file changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 82234397dd44..caf13b2e8cb6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -906,6 +906,61 @@ static int amdgpu_current_bpc_show(struct seq_file *m,
void *data)
}
DEFINE_SHOW_ATTRIBUTE(amdgpu_current_bpc);
+/*
+ * Returns the current colorspace for the crtc.
+ * Example usage: cat /sys/kernel/debug/dri/0/crtc-0/amdgpu_current_colorspace
+ */
+static int amdgpu_current_colorspace_show(struct seq_file *m, void *data)
+{
+ struct drm_crtc *crtc = m->private;
+ struct drm_device *dev = crtc->dev;
+ struct dm_crtc_state *dm_crtc_state = NULL;
+ int res = -ENODEV;
+
+ mutex_lock(>mode_config.mutex);
+ drm_modeset_lock(>mutex, NULL);
+ if (crtc->state == NULL)
+ goto unlock;
+
+ dm_crtc_state = to_dm_crtc_state(crtc->state);
+ if (dm_crtc_state->stream == NULL)
+ goto unlock;
+
+ switch (dm_crtc_state->stream->output_color_space) {
+ case COLOR_SPACE_SRGB:
+ seq_printf(m, "sRGB");
+ break;
+ case COLOR_SPACE_YCBCR601:
+ case COLOR_SPACE_YCBCR601_LIMITED:
+ seq_printf(m, "BT601_YCC");
+ break;
+ case COLOR_SPACE_YCBCR709:
+ case COLOR_SPACE_YCBCR709_LIMITED:
+ seq_printf(m, "BT709_YCC");
+ break;
+ case COLOR_SPACE_ADOBERGB:
+ seq_printf(m, "opRGB");
+ break;
+ case COLOR_SPACE_2020_RGB_FULLRANGE:
+ seq_printf(m, "BT2020_RGB");
+ break;
+ case COLOR_SPACE_2020_YCBCR:
+ seq_printf(m, "BT2020_YCC");
+ break;
+ default:
+ goto unlock;
+ }
+ res = 0;
+
+unlock:
+ drm_modeset_unlock(>mutex);
+ mutex_unlock(>mode_config.mutex);
+
+ return res;
+}
+DEFINE_SHOW_ATTRIBUTE(amdgpu_current_colorspace);
+
+
/*
* Example usage:
* Disable dsc passthrough, i.e.,: have dsc decoding at converver, not
external RX
@@ -3139,6 +3194,8 @@ void crtc_debugfs_init(struct drm_crtc *crtc)
#endif
debugfs_create_file("amdgpu_current_bpc", 0644, crtc->debugfs_entry,
crtc, _current_bpc_fops);
+ debugfs_create_file("amdgpu_current_colorspace", 0644,
crtc->debugfs_entry,
+ crtc, _current_colorspace_fops);
}
/*
--
2.41.0
[PATCH v5 11/13] drm/amd/display: Always set crtcinfo from create_stream_for_sink
From: Joshua Ashton Given that we always pass dm_state into here now, this won't ever trigger anymore. This is needed for we will always fail mode validation with invalid clocks or link bandwidth errors. Signed-off-by: Joshua Ashton Signed-off-by: Harry Wentland Cc: Pekka Paalanen Cc: Sebastian Wick Cc: vitaly.pros...@amd.com Cc: Joshua Ashton Cc: Simon Ser Cc: Melissa Wen Cc: dri-devel@lists.freedesktop.org Cc: amd-...@lists.freedesktop.org Reviewed-By: Harry Wentland --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 060a975f9885..e17c8afce2f4 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -6054,7 +6054,7 @@ create_stream_for_sink(struct amdgpu_dm_connector *aconnector, if (recalculate_timing) drm_mode_set_crtcinfo(_mode, 0); - else if (!dm_state) + else drm_mode_set_crtcinfo(, 0); /* -- 2.41.0
[PATCH v5 10/13] drm/amd/display: Send correct DP colorspace infopacket
Look at connector->colorimetry to determine output colorspace.
We don't want to impact current SDR behavior, so
DRM_MODE_COLORIMETRY_DEFAULT preserves current behavior.
Also add support to explicitly set BT601 and BT709.
v4:
- Roll support for BT709 and BT601 into this patch
- Add default case to avoid warnings for unhandled
enum values
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: Simon Ser
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 48 ---
1 file changed, 31 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 793ea29b4cfe..060a975f9885 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5338,21 +5338,44 @@ get_aspect_ratio(const struct drm_display_mode *mode_in)
}
static enum dc_color_space
-get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
+get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
+ const struct drm_connector_state *connector_state)
{
enum dc_color_space color_space = COLOR_SPACE_SRGB;
- switch (dc_crtc_timing->pixel_encoding) {
- case PIXEL_ENCODING_YCBCR422:
- case PIXEL_ENCODING_YCBCR444:
- case PIXEL_ENCODING_YCBCR420:
- {
+ switch (connector_state->colorspace) {
+ case DRM_MODE_COLORIMETRY_BT601_YCC:
+ if (dc_crtc_timing->flags.Y_ONLY)
+ color_space = COLOR_SPACE_YCBCR601_LIMITED;
+ else
+ color_space = COLOR_SPACE_YCBCR601;
+ break;
+ case DRM_MODE_COLORIMETRY_BT709_YCC:
+ if (dc_crtc_timing->flags.Y_ONLY)
+ color_space = COLOR_SPACE_YCBCR709_LIMITED;
+ else
+ color_space = COLOR_SPACE_YCBCR709;
+ break;
+ case DRM_MODE_COLORIMETRY_OPRGB:
+ color_space = COLOR_SPACE_ADOBERGB;
+ break;
+ case DRM_MODE_COLORIMETRY_BT2020_RGB:
+ case DRM_MODE_COLORIMETRY_BT2020_YCC:
+ if (dc_crtc_timing->pixel_encoding == PIXEL_ENCODING_RGB)
+ color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
+ else
+ color_space = COLOR_SPACE_2020_YCBCR;
+ break;
+ case DRM_MODE_COLORIMETRY_DEFAULT: // ITU601
+ default:
+ if (dc_crtc_timing->pixel_encoding == PIXEL_ENCODING_RGB) {
+ color_space = COLOR_SPACE_SRGB;
/*
* 27030khz is the separation point between HDTV and SDTV
* according to HDMI spec, we use YCbCr709 and YCbCr601
* respectively
*/
- if (dc_crtc_timing->pix_clk_100hz > 270300) {
+ } else if (dc_crtc_timing->pix_clk_100hz > 270300) {
if (dc_crtc_timing->flags.Y_ONLY)
color_space =
COLOR_SPACE_YCBCR709_LIMITED;
@@ -5365,15 +5388,6 @@ get_output_color_space(const struct dc_crtc_timing
*dc_crtc_timing)
else
color_space = COLOR_SPACE_YCBCR601;
}
-
- }
- break;
- case PIXEL_ENCODING_RGB:
- color_space = COLOR_SPACE_SRGB;
- break;
-
- default:
- WARN_ON(1);
break;
}
@@ -5512,7 +5526,7 @@ static void fill_stream_properties_from_drm_display_mode(
}
}
- stream->output_color_space = get_output_color_space(timing_out);
+ stream->output_color_space = get_output_color_space(timing_out,
connector_state);
}
static void fill_audio_info(struct audio_info *audio_info,
--
2.41.0
[PATCH v5 06/13] drm/connector: Allow drivers to pass list of supported colorspaces
Drivers might not support all colorspaces defined in
dp_colorspaces and hdmi_colorspaces. This results in
undefined behavior when userspace is setting an
unsupported colorspace.
Allow drivers to pass the list of supported colorspaces
when creating the colorspace property.
v2:
- Use 0 to indicate support for all colorspaces (Jani)
- Print drm_dbg_kms message when drivers pass 0
to signal that drivers should specify supported
colorspaecs explicity (Jani)
v3:
- Move changes to create a common colorspace_names array
to separate patch
Signed-off-by: Harry Wentland
Reviewed-by: Sebastian Wick
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: Jani Nikula
Cc: Simon Ser
Cc: Ville Syrjälä
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/drm_connector.c| 14 ++
drivers/gpu/drm/i915/display/intel_connector.c | 4 ++--
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
include/drm/drm_connector.h| 7 +--
4 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 69480385eaf3..b63b3e3168a1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2045,9 +2045,12 @@ static int drm_mode_create_colorspace_property(struct
drm_connector *connector,
* Returns:
* Zero on success, negative errno on failure.
*/
-int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
+int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector,
+u32 supported_colorspaces)
{
- return drm_mode_create_colorspace_property(connector, hdmi_colorspaces);
+ u32 colorspaces = supported_colorspaces & hdmi_colorspaces;
+
+ return drm_mode_create_colorspace_property(connector, colorspaces);
}
EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
@@ -2061,9 +2064,12 @@ EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
* Returns:
* Zero on success, negative errno on failure.
*/
-int drm_mode_create_dp_colorspace_property(struct drm_connector *connector)
+int drm_mode_create_dp_colorspace_property(struct drm_connector *connector,
+ u32 supported_colorspaces)
{
- return drm_mode_create_colorspace_property(connector, dp_colorspaces);
+ u32 colorspaces = supported_colorspaces & dp_colorspaces;
+
+ return drm_mode_create_colorspace_property(connector, colorspaces);
}
EXPORT_SYMBOL(drm_mode_create_dp_colorspace_property);
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
b/drivers/gpu/drm/i915/display/intel_connector.c
index 6205ddd3ded0..e8b4a352a7a6 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -283,14 +283,14 @@ intel_attach_aspect_ratio_property(struct drm_connector
*connector)
void
intel_attach_hdmi_colorspace_property(struct drm_connector *connector)
{
- if (!drm_mode_create_hdmi_colorspace_property(connector))
+ if (!drm_mode_create_hdmi_colorspace_property(connector, 0))
drm_connector_attach_colorspace_property(connector);
}
void
intel_attach_dp_colorspace_property(struct drm_connector *connector)
{
- if (!drm_mode_create_dp_colorspace_property(connector))
+ if (!drm_mode_create_dp_colorspace_property(connector, 0))
drm_connector_attach_colorspace_property(connector);
}
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 55744216392b..eee53e841701 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -618,7 +618,7 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
if (ret)
return ret;
- ret = drm_mode_create_hdmi_colorspace_property(connector);
+ ret = drm_mode_create_hdmi_colorspace_property(connector, 0);
if (ret)
return ret;
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 9d9e4d6f0449..f799cbd755a3 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
@@ -1904,8 +1905,10 @@ int
drm_connector_attach_hdr_output_metadata_property(struct drm_connector *conn
bool drm_connector_atomic_hdr_metadata_equal(struct drm_connector_state
*old_state,
struct drm_connector_state
*new_state);
int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
-int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector);
-int drm_mode_create_dp_colorspace_property(struct drm_connector *connector);
+int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector,
+
[PATCH v5 09/13] drm/amd/display: Signal mode_changed if colorspace changed
We need to signal mode_changed to make sure we update the output
colorspace.
v2: No need to call drm_hdmi_avi_infoframe_colorimetry as DC does its
own infoframe packing.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Joshua Ashton
Cc: Simon Ser
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Reviewed-by: Leo Li
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index bdda136235af..793ea29b4cfe 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6699,6 +6699,14 @@ amdgpu_dm_connector_atomic_check(struct drm_connector
*conn,
if (!crtc)
return 0;
+ if (new_con_state->colorspace != old_con_state->colorspace) {
+ new_crtc_state = drm_atomic_get_crtc_state(state, crtc);
+ if (IS_ERR(new_crtc_state))
+ return PTR_ERR(new_crtc_state);
+
+ new_crtc_state->mode_changed = true;
+ }
+
if (!drm_connector_atomic_hdr_metadata_equal(old_con_state,
new_con_state)) {
struct dc_info_packet hdr_infopacket;
@@ -6721,7 +6729,7 @@ amdgpu_dm_connector_atomic_check(struct drm_connector
*conn,
* set is permissible, however. So only force a
* modeset if we're entering or exiting HDR.
*/
- new_crtc_state->mode_changed =
+ new_crtc_state->mode_changed = new_crtc_state->mode_changed ||
!old_con_state->hdr_output_metadata ||
!new_con_state->hdr_output_metadata;
}
--
2.41.0
[PATCH v5 05/13] drm/connector: Print connector colorspace in state debugfs
v3: Fix kerneldocs (kernel test robot)
v4: Avoid returning NULL from drm_get_colorspace_name
Signed-off-by: Harry Wentland
Reviewed-by: Sebastian Wick
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: Jani Nikula
Cc: Simon Ser
Cc: Ville Syrjälä
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/drm_atomic.c| 1 +
drivers/gpu/drm/drm_connector.c | 15 +++
include/drm/drm_connector.h | 1 +
3 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c0dc5858a723..d6d04c4ccfc0 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1071,6 +1071,7 @@ static void drm_atomic_connector_print_state(struct
drm_printer *p,
drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name :
"(null)");
drm_printf(p, "\tself_refresh_aware=%d\n", state->self_refresh_aware);
drm_printf(p, "\tmax_requested_bpc=%d\n", state->max_requested_bpc);
+ drm_printf(p, "\tcolorspace=%s\n",
drm_get_colorspace_name(state->colorspace));
if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
if (state->writeback_job && state->writeback_job->fb)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 8d24a5da4076..69480385eaf3 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1048,6 +1048,21 @@ static const char * const colorspace_names[] = {
[DRM_MODE_COLORIMETRY_BT601_YCC] = "BT601_YCC",
};
+/**
+ * drm_get_colorspace_name - return a string for color encoding
+ * @colorspace: color space to compute name of
+ *
+ * In contrast to the other drm_get_*_name functions this one here returns a
+ * const pointer and hence is threadsafe.
+ */
+const char *drm_get_colorspace_name(enum drm_colorspace colorspace)
+{
+ if (colorspace < ARRAY_SIZE(colorspace_names) &&
colorspace_names[colorspace])
+ return colorspace_names[colorspace];
+ else
+ return "(null)";
+}
+
static const u32 hdmi_colorspaces =
BIT(DRM_MODE_COLORIMETRY_SMPTE_170M_YCC) |
BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fad38cdf4f79..9d9e4d6f0449 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1988,6 +1988,7 @@ void drm_connector_list_iter_end(struct
drm_connector_list_iter *iter);
bool drm_connector_has_possible_encoder(struct drm_connector *connector,
struct drm_encoder *encoder);
+const char *drm_get_colorspace_name(enum drm_colorspace colorspace);
/**
* drm_for_each_connector_iter - connector_list iterator macro
--
2.41.0
[PATCH v5 08/13] drm/amd/display: Register Colorspace property for DP and HDMI
We want compositors to be able to set the output
colorspace on DP and HDMI outputs, based on the
caps reported from the receiver via EDID.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: Simon Ser
Cc: Ville Syrjälä
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 27868dbb09f6..bdda136235af 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7246,6 +7246,12 @@ static int amdgpu_dm_connector_get_modes(struct
drm_connector *connector)
return amdgpu_dm_connector->num_modes;
}
+static const u32 supported_colorspaces =
+ BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
+ BIT(DRM_MODE_COLORIMETRY_OPRGB) |
+ BIT(DRM_MODE_COLORIMETRY_BT2020_RGB) |
+ BIT(DRM_MODE_COLORIMETRY_BT2020_YCC);
+
void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
struct amdgpu_dm_connector *aconnector,
int connector_type,
@@ -7326,6 +7332,15 @@ void amdgpu_dm_connector_init_helper(struct
amdgpu_display_manager *dm,
adev->mode_info.abm_level_property, 0);
}
+ if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
+ if
(!drm_mode_create_hdmi_colorspace_property(>base,
supported_colorspaces))
+
drm_connector_attach_colorspace_property(>base);
+ } else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
+ connector_type == DRM_MODE_CONNECTOR_eDP) {
+ if (!drm_mode_create_dp_colorspace_property(>base,
supported_colorspaces))
+
drm_connector_attach_colorspace_property(>base);
+ }
+
if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
connector_type == DRM_MODE_CONNECTOR_eDP) {
--
2.41.0
[PATCH v5 07/13] drm/amd/display: Always pass connector_state to stream validation
We need the connector_state for colorspace and scaling information
and can get it from connector->state.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: Simon Ser
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 90de0d37f1d2..27868dbb09f6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5954,15 +5954,14 @@ create_stream_for_sink(struct amdgpu_dm_connector
*aconnector,
{
struct drm_display_mode *preferred_mode = NULL;
struct drm_connector *drm_connector;
- const struct drm_connector_state *con_state =
- dm_state ? _state->base : NULL;
+ const struct drm_connector_state *con_state = _state->base;
struct dc_stream_state *stream = NULL;
struct drm_display_mode mode;
struct drm_display_mode saved_mode;
struct drm_display_mode *freesync_mode = NULL;
bool native_mode_found = false;
bool recalculate_timing = false;
- bool scale = dm_state ? (dm_state->scaling != RMX_OFF) : false;
+ bool scale = dm_state->scaling != RMX_OFF;
int mode_refresh;
int preferred_refresh = 0;
enum color_transfer_func tf = TRANSFER_FUNC_UNKNOWN;
@@ -6604,7 +6603,9 @@ enum drm_mode_status
amdgpu_dm_connector_mode_valid(struct drm_connector *connec
goto fail;
}
- stream = create_validate_stream_for_sink(aconnector, mode, NULL, NULL);
+ stream = create_validate_stream_for_sink(aconnector, mode,
+
to_dm_connector_state(connector->state),
+NULL);
if (stream) {
dc_stream_release(stream);
result = MODE_OK;
--
2.41.0
[PATCH v5 04/13] drm/connector: Use common colorspace_names array
We an use bitfields to track the support ones for HDMI
and DP. This allows us to print colorspaces in a consistent
manner without needing to know whether we're dealing with
DP or HDMI.
v4:
- Rename _MAX to _COUNT and leave comment to indicate
it's not a valid value
- Fix misplaced function doc
Signed-off-by: Harry Wentland
Reviewed-by: Sebastian Wick
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: Jani Nikula
Cc: Simon Ser
Cc: Ville Syrjälä
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/drm_connector.c | 125 ++--
include/drm/drm_connector.h | 2 +
2 files changed, 74 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 9c087d6f5691..8d24a5da4076 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1016,64 +1016,70 @@ static const struct drm_prop_enum_list
drm_dp_subconnector_enum_list[] = {
DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
drm_dp_subconnector_enum_list)
-static const struct drm_prop_enum_list hdmi_colorspaces[] = {
+
+static const char * const colorspace_names[] = {
/* For Default case, driver will set the colorspace */
- { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ [DRM_MODE_COLORIMETRY_DEFAULT] = "Default",
/* Standard Definition Colorimetry based on CEA 861 */
- { DRM_MODE_COLORIMETRY_SMPTE_170M_YCC, "SMPTE_170M_YCC" },
- { DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
+ [DRM_MODE_COLORIMETRY_SMPTE_170M_YCC] = "SMPTE_170M_YCC",
+ [DRM_MODE_COLORIMETRY_BT709_YCC] = "BT709_YCC",
/* Standard Definition Colorimetry based on IEC 61966-2-4 */
- { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
+ [DRM_MODE_COLORIMETRY_XVYCC_601] = "XVYCC_601",
/* High Definition Colorimetry based on IEC 61966-2-4 */
- { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
+ [DRM_MODE_COLORIMETRY_XVYCC_709] = "XVYCC_709",
/* Colorimetry based on IEC 61966-2-1/Amendment 1 */
- { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
+ [DRM_MODE_COLORIMETRY_SYCC_601] = "SYCC_601",
/* Colorimetry based on IEC 61966-2-5 [33] */
- { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
+ [DRM_MODE_COLORIMETRY_OPYCC_601] = "opYCC_601",
/* Colorimetry based on IEC 61966-2-5 */
- { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
+ [DRM_MODE_COLORIMETRY_OPRGB] = "opRGB",
/* Colorimetry based on ITU-R BT.2020 */
- { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
+ [DRM_MODE_COLORIMETRY_BT2020_CYCC] = "BT2020_CYCC",
/* Colorimetry based on ITU-R BT.2020 */
- { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
+ [DRM_MODE_COLORIMETRY_BT2020_RGB] = "BT2020_RGB",
/* Colorimetry based on ITU-R BT.2020 */
- { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
+ [DRM_MODE_COLORIMETRY_BT2020_YCC] = "BT2020_YCC",
/* Added as part of Additional Colorimetry Extension in 861.G */
- { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
- { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
+ [DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65] = "DCI-P3_RGB_D65",
+ [DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER] = "DCI-P3_RGB_Theater",
+ [DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED] = "RGB_WIDE_FIXED",
+ /* Colorimetry based on scRGB (IEC 61966-2-2) */
+ [DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT] = "RGB_WIDE_FLOAT",
+ [DRM_MODE_COLORIMETRY_BT601_YCC] = "BT601_YCC",
};
+static const u32 hdmi_colorspaces =
+ BIT(DRM_MODE_COLORIMETRY_SMPTE_170M_YCC) |
+ BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
+ BIT(DRM_MODE_COLORIMETRY_XVYCC_601) |
+ BIT(DRM_MODE_COLORIMETRY_XVYCC_709) |
+ BIT(DRM_MODE_COLORIMETRY_SYCC_601) |
+ BIT(DRM_MODE_COLORIMETRY_OPYCC_601) |
+ BIT(DRM_MODE_COLORIMETRY_OPRGB) |
+ BIT(DRM_MODE_COLORIMETRY_BT2020_CYCC) |
+ BIT(DRM_MODE_COLORIMETRY_BT2020_RGB) |
+ BIT(DRM_MODE_COLORIMETRY_BT2020_YCC) |
+ BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
+ BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
+
/*
* As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel
Encoding/Colorimetry
* Format Table 2-120
*/
-static const struct drm_prop_enum_list dp_colorspaces[] = {
- /* For Default case, driver will set the colorspace */
- { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
- { DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED, "RGB_Wide_Gamut_Fixed_Point" },
- /* Colorimetry based on scRGB (IEC 61966-2-2) */
- { DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT, "RGB_Wide_Gamut_Floating_Point"
},
- /* Colorimetry based on IEC 61966-2-5 */
- { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
- /* Colorimetry based on SMPTE RP 431-2 */
-
[PATCH v5 02/13] drm/connector: Add enum documentation to drm_colorspace
From: Joshua Ashton
To match the other enums, and add more information about these values.
v2:
- Specify where an enum entry comes from
- Clarify DEFAULT and NO_DATA behavior
- BT.2020 CYCC is "constant luminance"
- correct type for BT.601
v4:
- drop DP/HDMI clarifications that might create
more questions than answers
v5:
- Add note on YCC and RGB variants
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Reviewed-by: Harry Wentland
Reviewed-by: Sebastian Wick
Acked-by: Pekka Paalanen
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: Simon Ser
Cc: Ville Syrjälä
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
include/drm/drm_connector.h | 70 +++--
1 file changed, 68 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 77401e425341..907f40851e80 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -363,13 +363,79 @@ enum drm_privacy_screen_status {
PRIVACY_SCREEN_ENABLED_LOCKED,
};
-/*
- * This is a consolidated colorimetry list supported by HDMI and
+/**
+ * enum drm_colorspace - color space
+ *
+ * This enum is a consolidated colorimetry list supported by HDMI and
* DP protocol standard. The respective connectors will register
* a property with the subset of this list (supported by that
* respective protocol). Userspace will set the colorspace through
* a colorspace property which will be created and exposed to
* userspace.
+ *
+ * DP definitions come from the DP v2.0 spec
+ * HDMI definitions come from the CTA-861-H spec
+ *
+ * A note on YCC and RGB variants:
+ *
+ * Since userspace is not aware of the encoding on the wire
+ * (RGB or YCbCr), drivers are free to pick the appropriate
+ * variant, regardless of what userspace selects. E.g., if
+ * BT2020_RGB is selected by userspace a driver will pick
+ * BT2020_YCC if the encoding on the wire is YUV444 or YUV420.
+ *
+ * @DRM_MODE_COLORIMETRY_DEFAULT:
+ * Driver specific behavior.
+ * @DRM_MODE_COLORIMETRY_NO_DATA:
+ * Driver specific behavior.
+ * @DRM_MODE_COLORIMETRY_SMPTE_170M_YCC:
+ * (HDMI)
+ * SMPTE ST 170M colorimetry format
+ * @DRM_MODE_COLORIMETRY_BT709_YCC:
+ * (HDMI, DP)
+ * ITU-R BT.709 colorimetry format
+ * @DRM_MODE_COLORIMETRY_XVYCC_601:
+ * (HDMI, DP)
+ * xvYCC601 colorimetry format
+ * @DRM_MODE_COLORIMETRY_XVYCC_709:
+ * (HDMI, DP)
+ * xvYCC709 colorimetry format
+ * @DRM_MODE_COLORIMETRY_SYCC_601:
+ * (HDMI, DP)
+ * sYCC601 colorimetry format
+ * @DRM_MODE_COLORIMETRY_OPYCC_601:
+ * (HDMI, DP)
+ * opYCC601 colorimetry format
+ * @DRM_MODE_COLORIMETRY_OPRGB:
+ * (HDMI, DP)
+ * opRGB colorimetry format
+ * @DRM_MODE_COLORIMETRY_BT2020_CYCC:
+ * (HDMI, DP)
+ * ITU-R BT.2020 Y'c C'bc C'rc (constant luminance) colorimetry format
+ * @DRM_MODE_COLORIMETRY_BT2020_RGB:
+ * (HDMI, DP)
+ * ITU-R BT.2020 R' G' B' colorimetry format
+ * @DRM_MODE_COLORIMETRY_BT2020_YCC:
+ * (HDMI, DP)
+ * ITU-R BT.2020 Y' C'b C'r colorimetry format
+ * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
+ * (HDMI)
+ * SMPTE ST 2113 P3D65 colorimetry format
+ * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER:
+ * (HDMI)
+ * SMPTE ST 2113 P3DCI colorimetry format
+ * @DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED:
+ * (DP)
+ * RGB wide gamut fixed point colorimetry format
+ * @DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT:
+ * (DP)
+ * RGB wide gamut floating point
+ * (scRGB (IEC 61966-2-2)) colorimetry format
+ * @DRM_MODE_COLORIMETRY_BT601_YCC:
+ * (DP)
+ * ITU-R BT.601 colorimetry format
+ * The DP spec does not say whether this is the 525 or the 625
+ * line version.
*/
enum drm_colorspace {
/* For Default case, driver will set the colorspace */
--
2.41.0
[PATCH v5 03/13] drm/connector: Pull out common create_colorspace_property code
Signed-off-by: Harry Wentland
Reviewed-by: Sebastian Wick
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: Jani Nikula
Cc: Simon Ser
Cc: Ville Syrjälä
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/drm_connector.c | 54 -
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 547356e00341..9c087d6f5691 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1975,33 +1975,44 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
* drm_mode_create_dp_colorspace_property() is used for DP connector.
*/
-/**
- * drm_mode_create_hdmi_colorspace_property - create hdmi colorspace property
- * @connector: connector to create the Colorspace property on.
- *
- * Called by a driver the first time it's needed, must be attached to desired
- * HDMI connectors.
- *
- * Returns:
- * Zero on success, negative errno on failure.
- */
-int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
+static int drm_mode_create_colorspace_property(struct drm_connector *connector,
+ const struct drm_prop_enum_list
*colorspaces,
+ int size)
{
struct drm_device *dev = connector->dev;
if (connector->colorspace_property)
return 0;
+ if (!colorspaces)
+ return 0;
+
connector->colorspace_property =
drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "Colorspace",
-hdmi_colorspaces,
-ARRAY_SIZE(hdmi_colorspaces));
+ colorspaces,
+ size);
if (!connector->colorspace_property)
return -ENOMEM;
return 0;
}
+/**
+ * drm_mode_create_hdmi_colorspace_property - create hdmi colorspace property
+ * @connector: connector to create the Colorspace property on.
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * HDMI connectors.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
+{
+ return drm_mode_create_colorspace_property(connector,
+ hdmi_colorspaces,
+
ARRAY_SIZE(hdmi_colorspaces));
+}
EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
/**
@@ -2016,20 +2027,9 @@ EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
*/
int drm_mode_create_dp_colorspace_property(struct drm_connector *connector)
{
- struct drm_device *dev = connector->dev;
-
- if (connector->colorspace_property)
- return 0;
-
- connector->colorspace_property =
- drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "Colorspace",
-dp_colorspaces,
-ARRAY_SIZE(dp_colorspaces));
-
- if (!connector->colorspace_property)
- return -ENOMEM;
-
- return 0;
+ return drm_mode_create_colorspace_property(connector,
+ dp_colorspaces,
+ ARRAY_SIZE(dp_colorspaces));
}
EXPORT_SYMBOL(drm_mode_create_dp_colorspace_property);
--
2.41.0
[PATCH v5 01/13] drm/connector: Convert DRM_MODE_COLORIMETRY to enum
This allows us to use strongly typed arguments.
v2:
- Bring NO_DATA back
- Provide explicit enum values
v3:
- Drop unnecessary '&' from kerneldoc (emersion)
v4:
- Fix Normal Colorimetry comment
Signed-off-by: Harry Wentland
Reviewed-by: Simon Ser
Reviewed-by: Sebastian Wick
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: Simon Ser
Cc: Ville Syrjälä
Cc: Melissa Wen
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Reviewed-by: Pekka Paalanen
---
include/drm/display/drm_dp.h | 2 +-
include/drm/drm_connector.h | 49 ++--
2 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index f1be179c5f1f..7f858352cb43 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -1626,7 +1626,7 @@ enum dp_pixelformat {
*
* This enum is used to indicate DP VSC SDP Colorimetry formats.
* It is based on DP 1.4 spec [Table 2-117: VSC SDP Payload for DB16 through
- * DB18] and a name of enum member follows DRM_MODE_COLORIMETRY definition.
+ * DB18] and a name of enum member follows enum drm_colorimetry definition.
*
* @DP_COLORIMETRY_DEFAULT: sRGB (IEC 61966-2-1) or
* ITU-R BT.601 colorimetry format
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 565cf9d3c550..77401e425341 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -371,29 +371,30 @@ enum drm_privacy_screen_status {
* a colorspace property which will be created and exposed to
* userspace.
*/
-
-/* For Default case, driver will set the colorspace */
-#define DRM_MODE_COLORIMETRY_DEFAULT 0
-/* CEA 861 Normal Colorimetry options */
-#define DRM_MODE_COLORIMETRY_NO_DATA 0
-#define DRM_MODE_COLORIMETRY_SMPTE_170M_YCC1
-#define DRM_MODE_COLORIMETRY_BT709_YCC 2
-/* CEA 861 Extended Colorimetry Options */
-#define DRM_MODE_COLORIMETRY_XVYCC_601 3
-#define DRM_MODE_COLORIMETRY_XVYCC_709 4
-#define DRM_MODE_COLORIMETRY_SYCC_601 5
-#define DRM_MODE_COLORIMETRY_OPYCC_601 6
-#define DRM_MODE_COLORIMETRY_OPRGB 7
-#define DRM_MODE_COLORIMETRY_BT2020_CYCC 8
-#define DRM_MODE_COLORIMETRY_BT2020_RGB9
-#define DRM_MODE_COLORIMETRY_BT2020_YCC10
-/* Additional Colorimetry extension added as part of CTA 861.G */
-#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D6511
-#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER12
-/* Additional Colorimetry Options added for DP 1.4a VSC Colorimetry Format */
-#define DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED13
-#define DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT14
-#define DRM_MODE_COLORIMETRY_BT601_YCC 15
+enum drm_colorspace {
+ /* For Default case, driver will set the colorspace */
+ DRM_MODE_COLORIMETRY_DEFAULT= 0,
+ /* CEA 861 Normal Colorimetry options */
+ DRM_MODE_COLORIMETRY_NO_DATA= 0,
+ DRM_MODE_COLORIMETRY_SMPTE_170M_YCC = 1,
+ DRM_MODE_COLORIMETRY_BT709_YCC = 2,
+ /* CEA 861 Extended Colorimetry Options */
+ DRM_MODE_COLORIMETRY_XVYCC_601 = 3,
+ DRM_MODE_COLORIMETRY_XVYCC_709 = 4,
+ DRM_MODE_COLORIMETRY_SYCC_601 = 5,
+ DRM_MODE_COLORIMETRY_OPYCC_601 = 6,
+ DRM_MODE_COLORIMETRY_OPRGB = 7,
+ DRM_MODE_COLORIMETRY_BT2020_CYCC= 8,
+ DRM_MODE_COLORIMETRY_BT2020_RGB = 9,
+ DRM_MODE_COLORIMETRY_BT2020_YCC = 10,
+ /* Additional Colorimetry extension added as part of CTA 861.G */
+ DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65 = 11,
+ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER = 12,
+ /* Additional Colorimetry Options added for DP 1.4a VSC Colorimetry
Format */
+ DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED = 13,
+ DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT = 14,
+ DRM_MODE_COLORIMETRY_BT601_YCC = 15,
+};
/**
* enum drm_bus_flags - bus_flags info for _display_info
@@ -828,7 +829,7 @@ struct drm_connector_state {
* colorspace change on Sink. This is most commonly used to switch
* to wider color gamuts like BT2020.
*/
- u32 colorspace;
+ enum drm_colorspace colorspace;
/**
* @writeback_job: Writeback job for writeback connectors
--
2.41.0
[PATCH v5 00/13] Enable Colorspace connector property in amdgpu
This patchset is based on Joshua's previous patchset [1], as well as my previous patchset [2]. It is - enabling support for the colorspace property in amdgpu, as well as - allowing drivers to specify the supported set of colorspaces, and Colorspace, Infoframes, and YCbCr matrix --- Even though the initial intent of the colorspace property was to set the colorspace field in the respective HDMI AVI and DP SDP infoframes that is not sufficient in all scenarios. For DP the colorspace information also affects the MSA (main stream attribute) packet. For YUV output the colorspace affects the RGB-to-YCbCr conversion matrix. The colorspace field of the infopackets also depends on the encoding used, which is something that is decided by the driver and not known to userspace. For these reasons a driver will need to be able to select the supported colorspaces at property creation. Note: There seems to be an understanding that the colorspace property should ONLY modify the infoframe. While this is current behavior and sufficient in some cases it is nowhere specified that this should be the only use of this property. As outlined above this limitation is not going to work in all cases. This patchset does not affect current behavior for the drivers that implement this property: i915 and vc4. In the future we might want to give userspace control over the encoding format on the wire, in particular to avoid use of YUV420 when image fidelity is important. This work would likely go hand in hand with a min_bpc property and wouldn't conflict with the work done in this patchset. I would expect this future work to tag along with a drm_crtc or drm_connector's Color Pipeline, similar to the one propsed for drm_plane [3]. Colorspace on crtc or connector? There have been suggestions of programming 'colorspace' on the drm_crtc but I don't think the crtc is the right place for this property. The drm_plane and drm_crtc will be used to offload color processing that would normally be done via the GFX or other pipelines. The drm_connector controls the signalling with the display and ensures the wire format is appropriate for the encoding by programming the RGB-to-YCbCr matrix. [1] https://patchwork.freedesktop.org/series/113632/ [2] https://patchwork.freedesktop.org/series/111865/ [3] https://lists.freedesktop.org/archives/dri-devel/2023-May/403173.html v2: - Tested with DP and HDMI analyzers - Confirmed driver will fallback to lower bpc when needed - Dropped hunk to set HDMI AVI infoframe as it was a no-op - Fixed BT.2020 YCbCr colorimetry (JoshuaAshton) - Simplify initialization of supported colorspaces (Jani) - Fix kerneldoc (kernel test robot) v3: - Added documentation for colorspaces (Pekka, Joshua) - Split 'Allow drivers to pass list of supported colorspaces' patch to pull out code to create common colorspace array and keep it separate from change to create only supported colorspaces v4: - Don't "deprecate" existing enum values - Fixes based on review comments throughout - Dropped Josh's RBs v5: - Add documentation that drivers are free to pick appropriate RGB or YCC variant Cc: Pekka Paalanen Cc: Sebastian Wick Cc: vitaly.pros...@amd.com Cc: Uma Shankar Cc: Ville Syrjälä Cc: Joshua Ashton Cc: Jani Nikula Cc: Michel Dänzer Cc: Simon Ser Cc: Melissa Wen Cc: dri-devel@lists.freedesktop.org Cc: amd-...@lists.freedesktop.org Harry Wentland (10): drm/connector: Convert DRM_MODE_COLORIMETRY to enum drm/connector: Pull out common create_colorspace_property code drm/connector: Use common colorspace_names array drm/connector: Print connector colorspace in state debugfs drm/connector: Allow drivers to pass list of supported colorspaces drm/amd/display: Always pass connector_state to stream validation drm/amd/display: Register Colorspace property for DP and HDMI drm/amd/display: Signal mode_changed if colorspace changed drm/amd/display: Send correct DP colorspace infopacket drm/amd/display: Add debugfs for testing output colorspace Joshua Ashton (3): drm/connector: Add enum documentation to drm_colorspace drm/amd/display: Always set crtcinfo from create_stream_for_sink drm/amd/display: Refactor avi_info_frame colorimetry determination .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 84 ++--- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 57 ++ .../gpu/drm/amd/display/dc/core/dc_resource.c | 28 +-- drivers/gpu/drm/drm_atomic.c | 1 + drivers/gpu/drm/drm_connector.c | 176 +++--- .../gpu/drm/i915/display/intel_connector.c| 4 +- drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +- include/drm/display/drm_dp.h | 2 +- include/drm/drm_connector.h | 129 ++--- 9 files changed, 349 insertions(+), 134 deletions(-) -- 2.41.0
Re: [Freedreno] [RFC PATCH v2 04/13] drm/msm/dpu: remove unused fields from dpu_encoder_virt
On 3/20/2023 6:18 PM, Dmitry Baryshkov wrote:
Remove historical fields intfs_swapped and topology fields from struct
dpu_encoder_virt and also remove even more historical docs.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 28729c77364f..4ee708264f3b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -130,18 +130,12 @@ enum dpu_enc_rc_states {
*pingpong blocks can be different than num_phys_encs.
* @hw_dsc: Handle to the DSC blocks used for the display.
* @dsc_mask: Bitmask of used DSC blocks.
- * @intfs_swapped: Whether or not the phys_enc interfaces have been swapped
- * for partial update right-only cases, such as pingpong
- * split where virtual pingpong does not generate IRQs
* @crtc: Pointer to the currently assigned crtc. Normally you
*would use crtc->state->encoder_mask to determine the
*link between encoder/crtc. However in this case we need
*to track crtc in the disable() hook which is called
*_after_ encoder_mask is cleared.
* @connector:If a mode is set, cached pointer to the active
connector
- * @crtc_kickoff_cb: Callback into CRTC that will flush & start
- * all CTL paths
- * @crtc_kickoff_cb_data: Opaque user data given to crtc_kickoff_cb
no concerns with the above 3
* @enc_lock: Lock around physical encoder
*create/destroy/enable/disable
* @frame_busy_mask: Bitmask tracking which phys_enc we are still
@@ -160,7 +154,6 @@ enum dpu_enc_rc_states {
* @delayed_off_work: delayed worker to schedule disabling of
*clks and resources after IDLE_TIMEOUT time.
* @vsync_event_work: worker to handle vsync event for autorefresh
- * @topology: topology of the display
As we are still going to go ahead with encoder based allocation for now,
we should keep this topology and start using it for DP DSC's 1:1:1 topology.
* @idle_timeout: idle timeout duration in milliseconds
* @wide_bus_en: wide bus is enabled on this interface
* @dsc: drm_dsc_config pointer, for DSC-enabled encoders
@@ -180,8 +173,6 @@ struct dpu_encoder_virt {
unsigned int dsc_mask;
- bool intfs_swapped;
-
struct drm_crtc *crtc;
struct drm_connector *connector;
@@ -201,7 +192,6 @@ struct dpu_encoder_virt {
enum dpu_enc_rc_states rc_state;
struct delayed_work delayed_off_work;
struct kthread_work vsync_event_work;
- struct msm_display_topology topology;
u32 idle_timeout;
Re: [PATCH] drm/msm/dpu: tidy up some error checking
On 2023-06-06 11:33:03, Dan Carpenter wrote:
> The "vsync_hz" variable is unsigned int so it can't be less
> than zero. The dpu_kms_get_clk_rate() function used to return a u64
> but I previously changed it to return an unsigned long and zero on
> error so it matches clk_get_rate().
>
> Change the "vsync_hz" type to unsigned long as well and change the
> error checking to check for zero instead of negatives. This change
> does not affect runtime at all. It's just a clean up.
>
> Signed-off-by: Dan Carpenter
Suggested-by: Marijn Suijten
Reviewed-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> index d8ed85a238af..6aecaba14e7e 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> @@ -324,7 +324,7 @@ static void dpu_encoder_phys_cmd_tearcheck_config(
> struct dpu_hw_tear_check tc_cfg = { 0 };
> struct drm_display_mode *mode;
> bool tc_enable = true;
> - u32 vsync_hz;
> + unsigned long vsync_hz;
> struct dpu_kms *dpu_kms;
>
> if (phys_enc->has_intf_te) {
> @@ -359,8 +359,8 @@ static void dpu_encoder_phys_cmd_tearcheck_config(
>* frequency divided by the no. of rows (lines) in the LCDpanel.
>*/
> vsync_hz = dpu_kms_get_clk_rate(dpu_kms, "vsync");
> - if (vsync_hz <= 0) {
> - DPU_DEBUG_CMDENC(cmd_enc, "invalid - vsync_hz %u\n",
> + if (!vsync_hz) {
> + DPU_DEBUG_CMDENC(cmd_enc, "invalid - vsync_hz %lu\n",
>vsync_hz);
Nit: no need to print the value here, you know it's zero. Could be
clarified to just "no vsync clock".
- Marijn
> return;
> }
> @@ -381,7 +381,7 @@ static void dpu_encoder_phys_cmd_tearcheck_config(
> tc_cfg.rd_ptr_irq = mode->vdisplay + 1;
>
> DPU_DEBUG_CMDENC(cmd_enc,
> - "tc vsync_clk_speed_hz %u vtotal %u vrefresh %u\n",
> + "tc vsync_clk_speed_hz %lu vtotal %u vrefresh %u\n",
> vsync_hz, mode->vtotal, drm_mode_vrefresh(mode));
> DPU_DEBUG_CMDENC(cmd_enc,
> "tc enable %u start_pos %u rd_ptr_irq %u\n",
> --
> 2.39.2
>
Re: [PATCH v17] drm/msm/dpu: add DSC blocks to the catalog of MSM8998
On 06/06/2023 23:11, Kuogee Hsieh wrote:
From: Abhinav Kumar
Some platforms have DSC blocks which have not been declared in the catalog.
Complete DSC 1.1 support for all platforms by adding the missing blocks to
MSM8998.
'Some platforms' doesn't make sense if we are talking about a single
poor msm8998.
Changes in v9:
-- add MSM8998 and SC8180x to commit title
Changes in v10:
-- fix grammar at commit text
Changes in v12:
-- fix "titil" with "title" at changes in v9
Changes in v14:
-- "dsc" tp "DSC" at commit title
Changes in v15:
-- fix merge conflicts at dpu_5_1_sc8180x.h
Changes in v16
-- fix cherry-pick error by deleting both redundant .dsc and .dsc_count
assignment from dpu_5_1_sc8180x.h
Changes in v17
-- remove sc8180x from both commit title and text
-- remove Reviewed-by
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index 3c732a0..7d0d0e7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -126,6 +126,11 @@ static const struct dpu_pingpong_cfg msm8998_pp[] = {
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
};
+static const struct dpu_dsc_cfg msm8998_dsc[] = {
+ DSC_BLK("dsc_0", DSC_0, 0x8, 0),
+ DSC_BLK("dsc_1", DSC_1, 0x80400, 0),
+};
+
static const struct dpu_dspp_cfg msm8998_dspp[] = {
DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_SC7180_MASK,
_dspp_sblk),
@@ -199,6 +204,8 @@ const struct dpu_mdss_cfg dpu_msm8998_cfg = {
.dspp = msm8998_dspp,
.pingpong_count = ARRAY_SIZE(msm8998_pp),
.pingpong = msm8998_pp,
+ .dsc_count = ARRAY_SIZE(msm8998_dsc),
+ .dsc = msm8998_dsc,
.intf_count = ARRAY_SIZE(msm8998_intf),
.intf = msm8998_intf,
.vbif_count = ARRAY_SIZE(msm8998_vbif),
--
With best wishes
Dmitry
Re: [PATCH v17] drm/msm/dpu: add DSC blocks to the catalog of MSM8998
On 2023-06-06 13:11:12, Kuogee Hsieh wrote:
> From: Abhinav Kumar
>
> Some platforms have DSC blocks which have not been declared in the catalog.
Nit: just one platform now, but please don't send a v18 for that :)
> Complete DSC 1.1 support for all platforms by adding the missing blocks to
> MSM8998.
>
> Changes in v9:
> -- add MSM8998 and SC8180x to commit title
>
> Changes in v10:
> -- fix grammar at commit text
>
> Changes in v12:
> -- fix "titil" with "title" at changes in v9
>
> Changes in v14:
> -- "dsc" tp "DSC" at commit title
>
> Changes in v15:
> -- fix merge conflicts at dpu_5_1_sc8180x.h
>
> Changes in v16
> -- fix cherry-pick error by deleting both redundant .dsc and .dsc_count
>assignment from dpu_5_1_sc8180x.h
>
> Changes in v17
> -- remove sc8180x from both commit title and text
> -- remove Reviewed-by
This is the reason I find these changelogs-above-the-cut so silly in the
DRM subsystem: it is now longer than both the patch description *and
contents*, and absolutely *useless* to future readers of this patch in
git history.
Not something you have to (or can) address Kuogee, but I'll keep sending
my submissions with the changelog *below* the cut (or in the cover
letter) until someone complains.
>
> Signed-off-by: Abhinav Kumar
Reviewed-by: Marijn Suijten
- Marijn
> ---
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> index 3c732a0..7d0d0e7 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> @@ -126,6 +126,11 @@ static const struct dpu_pingpong_cfg msm8998_pp[] = {
> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
> };
>
> +static const struct dpu_dsc_cfg msm8998_dsc[] = {
> + DSC_BLK("dsc_0", DSC_0, 0x8, 0),
> + DSC_BLK("dsc_1", DSC_1, 0x80400, 0),
> +};
> +
> static const struct dpu_dspp_cfg msm8998_dspp[] = {
> DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_SC7180_MASK,
>_dspp_sblk),
> @@ -199,6 +204,8 @@ const struct dpu_mdss_cfg dpu_msm8998_cfg = {
> .dspp = msm8998_dspp,
> .pingpong_count = ARRAY_SIZE(msm8998_pp),
> .pingpong = msm8998_pp,
> + .dsc_count = ARRAY_SIZE(msm8998_dsc),
> + .dsc = msm8998_dsc,
> .intf_count = ARRAY_SIZE(msm8998_intf),
> .intf = msm8998_intf,
> .vbif_count = ARRAY_SIZE(msm8998_vbif),
> --
> 2.7.4
>
Re: [PATCH] drm/msm/dpu: tidy up some error checking
On 6/6/2023 1:33 AM, Dan Carpenter wrote: The "vsync_hz" variable is unsigned int so it can't be less than zero. The dpu_kms_get_clk_rate() function used to return a u64 but I previously changed it to return an unsigned long and zero on error so it matches clk_get_rate(). Change the "vsync_hz" type to unsigned long as well and change the error checking to check for zero instead of negatives. This change does not affect runtime at all. It's just a clean up. Signed-off-by: Dan Carpenter --- Reviewed-by: Abhinav Kumar
Re: [PATCH] drm/i915: Fix a VMA UAF for multi-gt platform
Hi Nirmoy, > > MTL is a > > weird multi-gt platform and, indeed, you can't shut down GT0 > > without affecting GT1. > > > > For now it's OK, though, as to test it. > > Looking forward to that. I did test it extensively and ChromeOS team as > well. great job, Nirmoy! I haven't been able to reproduce the issue. This is a great news! Tested-by: Andi Shyti Andi
[PATCH v17] drm/msm/dpu: add DSC blocks to the catalog of MSM8998
From: Abhinav Kumar
Some platforms have DSC blocks which have not been declared in the catalog.
Complete DSC 1.1 support for all platforms by adding the missing blocks to
MSM8998.
Changes in v9:
-- add MSM8998 and SC8180x to commit title
Changes in v10:
-- fix grammar at commit text
Changes in v12:
-- fix "titil" with "title" at changes in v9
Changes in v14:
-- "dsc" tp "DSC" at commit title
Changes in v15:
-- fix merge conflicts at dpu_5_1_sc8180x.h
Changes in v16
-- fix cherry-pick error by deleting both redundant .dsc and .dsc_count
assignment from dpu_5_1_sc8180x.h
Changes in v17
-- remove sc8180x from both commit title and text
-- remove Reviewed-by
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index 3c732a0..7d0d0e7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -126,6 +126,11 @@ static const struct dpu_pingpong_cfg msm8998_pp[] = {
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
};
+static const struct dpu_dsc_cfg msm8998_dsc[] = {
+ DSC_BLK("dsc_0", DSC_0, 0x8, 0),
+ DSC_BLK("dsc_1", DSC_1, 0x80400, 0),
+};
+
static const struct dpu_dspp_cfg msm8998_dspp[] = {
DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_SC7180_MASK,
_dspp_sblk),
@@ -199,6 +204,8 @@ const struct dpu_mdss_cfg dpu_msm8998_cfg = {
.dspp = msm8998_dspp,
.pingpong_count = ARRAY_SIZE(msm8998_pp),
.pingpong = msm8998_pp,
+ .dsc_count = ARRAY_SIZE(msm8998_dsc),
+ .dsc = msm8998_dsc,
.intf_count = ARRAY_SIZE(msm8998_intf),
.intf = msm8998_intf,
.vbif_count = ARRAY_SIZE(msm8998_vbif),
--
2.7.4
Re: [PATCH 06/36] drm/amd/display: add CRTC driver-specific property for gamma TF
On 6/6/23 12:57, Melissa Wen wrote:
> On 06/06, Sebastian Wick wrote:
>> On Tue, Jun 6, 2023 at 6:19 PM Joshua Ashton wrote:
>>>
>>>
>>>
>>> On 6/1/23 20:17, Harry Wentland wrote:
On 5/23/23 18:14, Melissa Wen wrote:
> Hook up driver-specific atomic operations for managing AMD color
> properties and create AMD driver-specific color management properties
> and attach them according to HW capabilities defined by `struct
> dc_color_caps`. Add enumerated transfer function property to DRM CRTC
> gamma to convert to wire encoding with or without a user gamma LUT.
> Enumerated TFs are not supported yet by the DRM color pipeline,
> therefore, create a DRM enum list with the predefined TFs supported by
> the AMD display driver.
>
> Co-developed-by: Joshua Ashton
> Signed-off-by: Joshua Ashton
> Signed-off-by: Melissa Wen
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 36 ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 8 +++
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 22 ++
> .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 72 ++-
> 4 files changed, 137 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 389396eac222..88af075e6c18 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -1247,6 +1247,38 @@ amdgpu_display_user_framebuffer_create(struct
> drm_device *dev,
> return _fb->base;
> }
>
> +static const struct drm_prop_enum_list drm_transfer_function_enum_list[]
> = {
> +{ DRM_TRANSFER_FUNCTION_DEFAULT, "Default" },
> +{ DRM_TRANSFER_FUNCTION_SRGB, "sRGB" },
> +{ DRM_TRANSFER_FUNCTION_BT709, "BT.709" },
> +{ DRM_TRANSFER_FUNCTION_PQ, "PQ (Perceptual Quantizer)" },
> +{ DRM_TRANSFER_FUNCTION_LINEAR, "Linear" },
> +{ DRM_TRANSFER_FUNCTION_UNITY, "Unity" },
> +{ DRM_TRANSFER_FUNCTION_HLG, "HLG (Hybrid Log Gamma)" },
> +{ DRM_TRANSFER_FUNCTION_GAMMA22, "Gamma 2.2" },
> +{ DRM_TRANSFER_FUNCTION_GAMMA24, "Gamma 2.4" },
> +{ DRM_TRANSFER_FUNCTION_GAMMA26, "Gamma 2.6" },
> +};
Let's not use the DRM_/drm_ prefix here. It might clash later when
we introduce DRM_ core interfaces for enumerated transfer functions.
We'll want to specify whether something is an EOTF or an inverse EOTF,
or possibly an OETF. Of course that wouldn't apply to "Linear" or
"Unity" (I'm assuming the two are the same?).
EOTF = electro-optical transfer function
This is the transfer function to go from the encoded value to an
optical (linear) value.
Inverse EOTF = simply the inverse of the EOTF
This is usually intended to go from an optical/linear space (which
might have been used for blending) back to the encoded values.
OETF = opto-electronic transfer function
This is usually used for converting optical signals into encoded
values. Usually that's done on the camera side but I think HLG might
define the OETF instead of the EOTF. A bit fuzzy on that. If you're
unclear about HLG I recommend we don't include it yet.
It would also be good to document a bit more what each of the TFs
mean, but I'm fine if that comes later with a "driver-agnostic"
API. The key thing to clarify is whether we have an EOTF or inv_EOTF,
i.e. whether we use the TF to go from encoded to optical or vice
versa.
>>>
>>> Whether we use the inverse or not is just determined per-block though.
>>>
>>> I think we should definitely document it per-block very explicitly
>>> (whether it is EOTF or inv EOTF) but I don't think we need to touch the
>>> enums here.
>>
>> Either the drm prefix has to be removed or the enum variant names have
>> to be explicitly be the EOTF, OETF, inverse EOTF or inverse OETF.
>
> I'm okay on using `AMD_` prefix instead of `DRM_` for this
> driver-specific implementation. I think the position of each block in
> the pipeline already describe the conversion type, since we only
> implemented one conversion type per-block. So, I agree we can keep it
> simple as Joshua suggested (don't extend enum, just document blocks -
> should it be a kernel doc?).
>
I would still prefer if we can make the enum be explicit about whether
an EOTF or inv_EOTF is intended. In theory many of these blocks in HW
could support either.
Harry
> Melissa
>
>>
>>> - Joshie ✨
>>>
I know DC is sloppy and doesn't define those but it will still use
them as either EOTF or inv_EOTF, based on which block they're being
programmed, if I'm not mistaken.
> +
> +#ifdef AMD_PRIVATE_COLOR
> +static int
> +amdgpu_display_create_color_properties(struct amdgpu_device *adev)
> +{
Re: [PATCH v16] drm/msm/dpu: add DSC blocks to the catalog of MSM8998 and SC8180X
On 6/6/2023 11:57 AM, Marijn Suijten wrote:
On 2023-06-06 11:31:39, Kuogee Hsieh wrote:
From: Abhinav Kumar
Some platforms have DSC blocks which have not been declared in the catalog.
Complete DSC 1.1 support for all platforms by adding the missing blocks to
MSM8998 and SC8180X.
Still a NACK, as pointed out in v15 both the title and this commit
description point to SC8180X but that catalog entry is not touched at
all anymore after rebasing on top of f5abecfe339e4 ("drm/msm/dpu: enable
DSPP and DSC on sc8180x").
- Marijn
Yeah we should fix the commit text and the title. Apologies for that.
Changes in v9:
-- add MSM8998 and SC8180x to commit title
Changes in v10:
-- fix grammar at commit text
Changes in v12:
-- fix "titil" with "title" at changes in v9
Changes in v14:
-- "dsc" tp "DSC" at commit title
Changes in v15:
-- fix merge conflicts at dpu_5_1_sc8180x.h
Changes in v16
-- fix cherry-pick error by deleting both redundant .dsc and .dsc_count
assignment from dpu_5_1_sc8180x.h
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index 3c732a0..7d0d0e7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -126,6 +126,11 @@ static const struct dpu_pingpong_cfg msm8998_pp[] = {
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
};
+static const struct dpu_dsc_cfg msm8998_dsc[] = {
+ DSC_BLK("dsc_0", DSC_0, 0x8, 0),
+ DSC_BLK("dsc_1", DSC_1, 0x80400, 0),
+};
+
static const struct dpu_dspp_cfg msm8998_dspp[] = {
DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_SC7180_MASK,
_dspp_sblk),
@@ -199,6 +204,8 @@ const struct dpu_mdss_cfg dpu_msm8998_cfg = {
.dspp = msm8998_dspp,
.pingpong_count = ARRAY_SIZE(msm8998_pp),
.pingpong = msm8998_pp,
+ .dsc_count = ARRAY_SIZE(msm8998_dsc),
+ .dsc = msm8998_dsc,
.intf_count = ARRAY_SIZE(msm8998_intf),
.intf = msm8998_intf,
.vbif_count = ARRAY_SIZE(msm8998_vbif),
--
2.7.4
Re: [Intel-gfx] [PATCH v2 1/2] vgaarb: various coding style and comments fix
Match the subject line style:
$ git log --oneline drivers/pci/vgaarb.c
f321c35feaee PCI/VGA: Replace full MIT license text with SPDX identifier
d5109fe4d1ec PCI/VGA: Use unsigned format string to print lock counts
4e6c91847a7f PCI/VGA: Log bridge control messages when adding devices
dc593fd48abb PCI/VGA: Remove empty vga_arb_device_card_gone()
...
Subject line should be a summary of the commit log, not just "various
style fixes". This one needs to say something about
vga_str_to_iostate().
On Mon, Jun 05, 2023 at 04:58:30AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> To keep consistent with vga_iostate_to_str() function, the third argument
> of vga_str_to_iostate() function should be 'unsigned int *'.
>
> Signed-off-by: Sui Jingfeng
> ---
> drivers/pci/vgaarb.c | 29 +++--
> include/linux/vgaarb.h | 8 +++-
> 2 files changed, 18 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
> index 5a696078b382..e40e6e5e5f03 100644
> --- a/drivers/pci/vgaarb.c
> +++ b/drivers/pci/vgaarb.c
> @@ -61,7 +61,6 @@ static bool vga_arbiter_used;
> static DEFINE_SPINLOCK(vga_lock);
> static DECLARE_WAIT_QUEUE_HEAD(vga_wait_queue);
>
> -
> static const char *vga_iostate_to_str(unsigned int iostate)
> {
> /* Ignore VGA_RSRC_IO and VGA_RSRC_MEM */
> @@ -77,10 +76,12 @@ static const char *vga_iostate_to_str(unsigned int
> iostate)
> return "none";
> }
>
> -static int vga_str_to_iostate(char *buf, int str_size, int *io_state)
> +static int vga_str_to_iostate(char *buf, int str_size, unsigned int
> *io_state)
> {
> - /* we could in theory hand out locks on IO and mem
> - * separately to userspace but it can cause deadlocks */
> + /*
> + * we could in theory hand out locks on IO and mem
> + * separately to userspace but it can cause deadlocks
> + */
Omit all the comment formatting changes. They are distractions from the
vga_str_to_iostate() parameter change.
I think this patch should be the single line change to the
vga_str_to_iostate() prototype so it matches the callers.
If you want to do the other comment formatting changes, they're fine,
but they should be all together in a separate patch that clearly
doesn't change the generated code.
Bjorn
Re: [PATCH v3 1/2] dt-bindings: soc: imx93-media-blk-ctrl: Add PDFC subnode to schema and example
On Mon, Jun 05, 2023 at 02:22:16PM +0800, Liu Ying wrote:
> i.MX93 SoC mediamix blk-ctrl contains one DISPLAY_MUX register which
> configures parallel display format by using the "PARALLEL_DISP_FORMAT"
> field. Document the Parallel Display Format Configuration(PDFC) subnode
> and add the subnode to example.
The previous issues seem to be resolved & what you've got here looks
fine to me. Perhaps Krzysztof will disagree!
Reviewed-by: Conor Dooley
Cheers,
Conor.
>
> Signed-off-by: Liu Ying
> ---
> v2->v3:
> * Newly introduced to replace the standalone dt-binding in v1 and v2. (Rob)
>
> .../soc/imx/fsl,imx93-media-blk-ctrl.yaml | 68 +++
> 1 file changed, 68 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml
> b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml
> index b3554e7f9e76..3f550c30d93d 100644
> --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml
> +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml
> @@ -24,6 +24,12 @@ properties:
>reg:
> maxItems: 1
>
> + '#address-cells':
> +const: 1
> +
> + '#size-cells':
> +const: 1
> +
>'#power-domain-cells':
> const: 1
>
> @@ -46,9 +52,43 @@ properties:
>- const: csi
>- const: dsi
>
> + bridge@60:
> +type: object
> +additionalProperties: false
> +
> +properties:
> + compatible:
> +const: nxp,imx93-pdfc
> +
> + reg:
> +maxItems: 1
> +
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: Input port node to receive pixel data.
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: Output port node to downstream pixel data receivers.
> +
> +required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - ports
> +
> required:
>- compatible
>- reg
> + - '#address-cells'
> + - '#size-cells'
>- power-domains
>- clocks
>- clock-names
> @@ -76,5 +116,33 @@ examples:
> < IMX93_CLK_MIPI_DSI_GATE>;
> clock-names = "apb", "axi", "nic", "disp", "cam",
> "pxp", "lcdif", "isi", "csi", "dsi";
> + #address-cells = <1>;
> + #size-cells = <1>;
>#power-domain-cells = <1>;
> +
> + bridge@60 {
> +compatible = "nxp,imx93-pdfc";
> +reg = <0x60 0x4>;
> +
> +ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> +reg = <0>;
> +
> +pdfc_from_lcdif: endpoint {
> + remote-endpoint = <_to_pdfc>;
> +};
> + };
> +
> + port@1 {
> +reg = <1>;
> +
> +pdfc_to_panel: endpoint {
> + remote-endpoint = <_from_pdfc>;
> +};
> + };
> +};
> + };
> };
> --
> 2.37.1
>
signature.asc
Description: PGP signature
Re: [Freedreno] [PATCH] drm/msm/dpu: re-introduce dpu core revision to the catalog
On 6/6/2023 12:09 PM, Dmitry Baryshkov wrote: On 06/06/2023 20:51, Abhinav Kumar wrote: On 6/6/2023 4:14 AM, Dmitry Baryshkov wrote: On Tue, 6 Jun 2023 at 05:35, Abhinav Kumar wrote: On 6/5/2023 6:03 PM, Dmitry Baryshkov wrote: On 06/06/2023 03:55, Abhinav Kumar wrote: On 6/3/2023 7:21 PM, Dmitry Baryshkov wrote: On 31/05/2023 21:25, Abhinav Kumar wrote: On 5/31/2023 3:07 AM, Dmitry Baryshkov wrote: On 31/05/2023 06:05, Abhinav Kumar wrote: On 5/30/2023 7:53 PM, Dmitry Baryshkov wrote: On Wed, 31 May 2023 at 03:54, Abhinav Kumar wrote: With [1] dpu core revision was dropped in favor of using the compatible string from the device tree to select the dpu catalog being used in the device. This approach works well however also necessitates adding catalog entries for small register level details as dpu capabilities and/or features bloating the catalog unnecessarily. Examples include but are not limited to data_compress, interrupt register set, widebus etc. Introduce the dpu core revision back as an entry to the catalog so that we can just use dpu revision checks and enable those bits which should be enabled unconditionally and not controlled by a catalog and also simplify the changes to do something like: if (dpu_core_revision > x && dpu_core_revision < x) enable the bit; Also, add some of the useful macros back to be able to use dpu core revision effectively. [1]: https://patchwork.freedesktop.org/patch/530891/?series=113910=4 Signed-off-by: Abhinav Kumar --- .../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 1 + .../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 1 + .../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 1 + .../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 1 + .../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 1 + .../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 1 + .../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 1 + .../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 1 + .../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 1 + .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 31 ++- 14 files changed, 43 insertions(+), 1 deletion(-) [skipped catalog changes] diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h index 677048cc3b7d..cc4aa75a1219 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h @@ -19,6 +19,33 @@ */ #define MAX_BLOCKS 12 +#define DPU_HW_VER(MAJOR, MINOR, STEP)\ + unsigned int)MAJOR & 0xF) << 28) |\ + ((MINOR & 0xFFF) << 16) |\ + (STEP & 0x)) + +#define DPU_HW_MAJOR(rev)((rev) >> 28) +#define DPU_HW_MINOR(rev)(((rev) >> 16) & 0xFFF) +#define DPU_HW_STEP(rev)((rev) & 0x) +#define DPU_HW_MAJOR_MINOR(rev)((rev) >> 16) + +#define IS_DPU_MAJOR_MINOR_SAME(rev1, rev2) \ +(DPU_HW_MAJOR_MINOR((rev1)) == DPU_HW_MAJOR_MINOR((rev2))) + +#define DPU_HW_VER_300 DPU_HW_VER(3, 0, 0) /* 8998 v1.0 */ +#define DPU_HW_VER_400 DPU_HW_VER(4, 0, 0) /* sdm845 v1.0 */ +#define DPU_HW_VER_500 DPU_HW_VER(5, 0, 0) /* sm8150 v1.0 */ +#define DPU_HW_VER_510 DPU_HW_VER(5, 1, 1) /* sc8180 */ +#define DPU_HW_VER_600 DPU_HW_VER(6, 0, 0) /* sm8250 */ +#define DPU_HW_VER_620 DPU_HW_VER(6, 2, 0) /* sc7180 v1.0 */ +#define DPU_HW_VER_630 DPU_HW_VER(6, 3, 0) /* sm6115|sm4250 */ +#define DPU_HW_VER_650 DPU_HW_VER(6, 5, 0) /* qcm2290|sm4125 */ +#define DPU_HW_VER_700 DPU_HW_VER(7, 0, 0) /* sm8350 */ +#define DPU_HW_VER_720 DPU_HW_VER(7, 2, 0) /* sc7280 */ +#define DPU_HW_VER_800 DPU_HW_VER(8, 0, 0) /* sc8280xp */ +#define DPU_HW_VER_810 DPU_HW_VER(8, 1, 0) /* sm8450 */ +#define DPU_HW_VER_900 DPU_HW_VER(9, 0, 0) /* sm8550 */ Instead of having defines for all SoCs (which can quickly become unmanageable) and can cause merge conflicts, I'd suggest inlining all the defines into respective catalog files. Sure, that can be done. Also, I'm not sure that the "step" should be a part of the catalog. I know that this follows the hardware revision. However, please correct me if I'm wrong, different step levels are used for revisions of the same SoC. The original code that was reading the hw revision from the hardware register, listed both 5.0.0 and 5.0.1 for sm8150. This is one of the things i noticed while making this change. Before the catalog rework, we used to handle even steps as we used to read that from the register and match it with the mdss_cfg handler. But after the rework, we dont handle steps anymore. Yes, you are right that different step levels are used for the revisions of the same SOC and so with that, i dont expect or atleast am not aware of DPU differences between steps but I am not able
Re: [PATCH] drm/amdgpu: display/Kconfig: replace leading spaces with tab
Thanks a lot. On 2023/6/7 03:15, Alex Deucher wrote: Applied. Thanks! Alex On Tue, Jun 6, 2023 at 9:33 AM Sui Jingfeng wrote: This patch replace the leading spaces with tab, make them keep aligned with the rest of the config options. No functional change. Signed-off-by: Sui Jingfeng --- drivers/gpu/drm/amd/display/Kconfig | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/amd/display/Kconfig b/drivers/gpu/drm/amd/display/Kconfig index 2d8e55e29637..04ccfc70d583 100644 --- a/drivers/gpu/drm/amd/display/Kconfig +++ b/drivers/gpu/drm/amd/display/Kconfig @@ -42,16 +42,13 @@ config DEBUG_KERNEL_DC Choose this option if you want to hit kdgb_break in assert. config DRM_AMD_SECURE_DISPLAY -bool "Enable secure display support" -depends on DEBUG_FS -depends on DRM_AMD_DC_FP -help -Choose this option if you want to -support secure display - -This option enables the calculation -of crc of specific region via debugfs. -Cooperate with specific DMCU FW. + bool "Enable secure display support" + depends on DEBUG_FS + depends on DRM_AMD_DC_FP + help + Choose this option if you want to support secure display + This option enables the calculation of crc of specific region via + debugfs. Cooperate with specific DMCU FW. endmenu -- 2.25.1 -- Jingfeng
Re: [PATCH] drm/amdgpu: display/Kconfig: replace leading spaces with tab
Applied. Thanks! Alex On Tue, Jun 6, 2023 at 9:33 AM Sui Jingfeng wrote: > > This patch replace the leading spaces with tab, make them keep aligned with > the rest of the config options. No functional change. > > Signed-off-by: Sui Jingfeng > --- > drivers/gpu/drm/amd/display/Kconfig | 17 +++-- > 1 file changed, 7 insertions(+), 10 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/Kconfig > b/drivers/gpu/drm/amd/display/Kconfig > index 2d8e55e29637..04ccfc70d583 100644 > --- a/drivers/gpu/drm/amd/display/Kconfig > +++ b/drivers/gpu/drm/amd/display/Kconfig > @@ -42,16 +42,13 @@ config DEBUG_KERNEL_DC > Choose this option if you want to hit kdgb_break in assert. > > config DRM_AMD_SECURE_DISPLAY > -bool "Enable secure display support" > -depends on DEBUG_FS > -depends on DRM_AMD_DC_FP > -help > -Choose this option if you want to > -support secure display > - > -This option enables the calculation > -of crc of specific region via debugfs. > -Cooperate with specific DMCU FW. > + bool "Enable secure display support" > + depends on DEBUG_FS > + depends on DRM_AMD_DC_FP > + help > + Choose this option if you want to support secure display > > + This option enables the calculation of crc of specific region via > + debugfs. Cooperate with specific DMCU FW. > > endmenu > -- > 2.25.1 >
Re: [PATCH v4 1/4] Input: ads7846 - Convert to use software nodes
On Sun, Jun 4, 2023 at 5:44 PM Christophe JAILLET wrote: > > + /* Asserts RESET */ > > + gpiod_set_value(md->reset, 1); > > Hi, > > should this also be done in the probe if mipid_detect() fails? It's a nice bonus but surely not urgent or necessary. > If yes, please also look at [1], that I've just sent, which introduces > an error handling path in the probe. Looks good to me. Reviewed-by: Linus Walleij Yours, Linus Walleij
[linux-next:master] BUILD REGRESSION 6db29e14f4fb7bce9eb5290288e71b05c2b0d118
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 6db29e14f4fb7bce9eb5290288e71b05c2b0d118 Add linux-next specific
files for 20230606
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202305132244.dwzbucud-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202306021936.okttcmat-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202306061802.duh27kmq-...@intel.com
Error/Warning: (recently discovered and may have been fixed)
ERROR: modpost: "lynx_pcs_create_mdiodev"
[drivers/net/ethernet/altera/altera_tse.ko] undefined!
ERROR: modpost: "lynx_pcs_destroy"
[drivers/net/ethernet/stmicro/stmmac/stmmac.ko] undefined!
arm-linux-gnueabi-ld: altera_tse_main.c:(.text+0x1808): undefined reference to
`lynx_pcs_destroy'
drivers/bus/fsl-mc/fsl-mc-allocator.c:108:12: warning: variable 'mc_bus_dev' is
uninitialized when used here [-Wuninitialized]
drivers/net/ethernet/altera/altera_tse_main.c:1419: undefined reference to
`lynx_pcs_create_mdiodev'
drivers/net/ethernet/altera/altera_tse_main.c:1473: undefined reference to
`lynx_pcs_destroy'
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c:669: undefined reference to
`lynx_pcs_destroy'
include/drm/drm_print.h:456:39: error: format '%ld' expects argument of type
'long int', but argument 4 has type 'size_t' {aka 'unsigned int'}
[-Werror=format=]
ld.lld: error: undefined symbol: lynx_pcs_create_mdiodev
ld.lld: error: undefined symbol: lynx_pcs_destroy
m68k-linux-ld: drivers/net/ethernet/altera/altera_tse_main.c:1451: undefined
reference to `lynx_pcs_destroy'
microblaze-linux-ld: drivers/net/ethernet/altera/altera_tse_main.c:1451:
undefined reference to `lynx_pcs_destroy'
mips64-linux-ld: drivers/net/ethernet/altera/altera_tse_main.c:1451: undefined
reference to `lynx_pcs_destroy'
net/netfilter/ipvs/ip_vs_proto.o: warning: objtool: .init.text: unexpected end
of section
nios2-linux-ld: drivers/net/ethernet/altera/altera_tse_main.c:1451: undefined
reference to `lynx_pcs_destroy'
powerpc-linux-ld: drivers/net/ethernet/altera/altera_tse_main.c:1451: undefined
reference to `lynx_pcs_destroy'
riscv32-linux-ld: altera_tse_main.c:(.text+0x2024): undefined reference to
`lynx_pcs_destroy'
Unverified Error/Warning (likely false positive, please contact us if
interested):
Warning: MAINTAINERS references a file that doesn't exist:
Documentation/devicetree/bindings/usb/starfive,jh7110-usb.yaml
drivers/net/ethernet/emulex/benet/be_main.c:2460 be_rx_compl_process_gro()
error: buffer overflow '((skb_end_pointer(skb)))->frags' 17 <= u16max
drivers/usb/cdns3/cdns3-starfive.c:23: warning: expecting prototype for
cdns3(). Prototype was for USB_STRAP_HOST() instead
fs/btrfs/volumes.c:6407 btrfs_map_block() error: we previously assumed
'mirror_num_ret' could be null (see line 6245)
fs/smb/client/cifsfs.c:982 cifs_smb3_do_mount() warn: possible memory leak of
'cifs_sb'
fs/smb/client/cifssmb.c:4089 CIFSFindFirst() warn: missing error code? 'rc'
fs/smb/client/cifssmb.c:4216 CIFSFindNext() warn: missing error code? 'rc'
fs/smb/client/connect.c:2725 cifs_match_super() error: 'tlink' dereferencing
possible ERR_PTR()
fs/smb/client/connect.c:2924 generic_ip_connect() error: we previously assumed
'socket' could be null (see line 2912)
kernel/events/uprobes.c:478 uprobe_write_opcode() warn: passing zero to
'PTR_ERR'
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
|-- alpha-allyesconfig
| `--
drivers-usb-cdns3-cdns3-starfive.c:warning:expecting-prototype-for-cdns3().-Prototype-was-for-USB_STRAP_HOST()-instead
|-- arc-allyesconfig
| `--
drivers-usb-cdns3-cdns3-starfive.c:warning:expecting-prototype-for-cdns3().-Prototype-was-for-USB_STRAP_HOST()-instead
|-- arm-allmodconfig
| `--
drivers-usb-cdns3-cdns3-starfive.c:warning:expecting-prototype-for-cdns3().-Prototype-was-for-USB_STRAP_HOST()-instead
|-- arm-allyesconfig
| `--
drivers-usb-cdns3-cdns3-starfive.c:warning:expecting-prototype-for-cdns3().-Prototype-was-for-USB_STRAP_HOST()-instead
|-- arm-randconfig-r022-20230606
| `--
arm-linux-gnueabi-ld:altera_tse_main.c:(.text):undefined-reference-to-lynx_pcs_destroy
|-- arm64-allyesconfig
| `--
drivers-usb-cdns3-cdns3-starfive.c:warning:expecting-prototype-for-cdns3().-Prototype-was-for-USB_STRAP_HOST()-instead
|-- arm64-buildonly-randconfig-r003-20230606
| `--
ERROR:lynx_pcs_create_mdiodev-drivers-net-ethernet-altera-altera_tse.ko-undefined
|-- arm64-randconfig-s043-20230606
| `-- mm-kfence-core.c:sparse:sparse:cast-to-restricted-__le64
|-- i386-allyesconfig
| `--
include-drm-drm_print.h:error:format-ld-expects-argument-of-type-long-int-but-argument-has-type-size_t-aka-unsigned-int
|-- i386-randconfig-i005-20230606
| `--
include-drm-drm_print.h:error:format-ld-expects-argument-of-type-long-int-but-argument-has-type-size_t-aka-unsigned-int
|-- i386-randconfig-m021-20230606
| |--
fs-smb-client-cifsfs.c-cifs_smb3_do_mount()-warn:possible-memory-leak
[PATCH] drm/amdgpu: add error reporting code
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 29
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 52564b93f7eb..d33b78aa3e58 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -951,7 +951,7 @@ static bool dc_construct(struct dc *dc,
goto fail;
}
-dc_ctx = dc->ctx;
+ dc_ctx = dc->ctx;
/* Resource should construct all asic specific resources.
* This should be the only place where we need to parse the asic id
@@ -990,16 +990,21 @@ static bool dc_construct(struct dc *dc,
}
dc->res_pool = dc_create_resource_pool(dc, init_params,
dc_ctx->dce_version);
- if (!dc->res_pool)
+ if (!dc->res_pool) {
+ dm_error("%s: failed to create resource pool\n", __func__);
goto fail;
+ }
/* set i2c speed if not done by the respective dcnxxx__resource.c */
if (dc->caps.i2c_speed_in_khz_hdcp == 0)
dc->caps.i2c_speed_in_khz_hdcp = dc->caps.i2c_speed_in_khz;
dc->clk_mgr = dc_clk_mgr_create(dc->ctx, dc->res_pool->pp_smu,
dc->res_pool->dccg);
- if (!dc->clk_mgr)
+ if (!dc->clk_mgr) {
+ dm_error("%s: failed to create clk manager\n", __func__);
goto fail;
+ }
+
#ifdef CONFIG_DRM_AMD_DC_FP
dc->clk_mgr->force_smu_not_present = init_params->force_smu_not_present;
@@ -1022,14 +1027,18 @@ static bool dc_construct(struct dc *dc,
goto fail;
}
- if (!create_links(dc, init_params->num_virtual_links))
+ if (!create_links(dc, init_params->num_virtual_links)) {
+ dm_error("%s: failed to create links\n", __func__);
goto fail;
+ }
/* Create additional DIG link encoder objects if fewer than the platform
* supports were created during link construction.
*/
- if (!create_link_encoders(dc))
+ if (!create_link_encoders(dc)) {
+ dm_error("%s: failed to create link encoders\n", __func__);
goto fail;
+ }
dc_resource_state_construct(dc, dc->current_state);
@@ -1314,11 +1323,15 @@ struct dc *dc_create(const struct dc_init_data
*init_params)
return NULL;
if (init_params->dce_environment == DCE_ENV_VIRTUAL_HW) {
- if (!dc_construct_ctx(dc, init_params))
+ if (!dc_construct_ctx(dc, init_params)) {
+ DC_LOG_ERROR("%s: dc construct failed\n", __func__);
goto destruct_dc;
+ }
} else {
- if (!dc_construct(dc, init_params))
+ if (!dc_construct(dc, init_params)) {
+ DC_LOG_ERROR("%s: dc construct failed\n", __func__);
goto destruct_dc;
+ }
full_pipe_count = dc->res_pool->pipe_count;
if (dc->res_pool->underlay_pipe_index != NO_UNDERLAY_PIPE)
@@ -1349,8 +1362,6 @@ struct dc *dc_create(const struct dc_init_data
*init_params)
DC_LOG_DC("Display Core initialized\n");
-
-
return dc;
destruct_dc:
--
2.25.1
Re: [Freedreno] [PATCH] drm/msm/dpu: re-introduce dpu core revision to the catalog
On 06/06/2023 20:51, Abhinav Kumar wrote: On 6/6/2023 4:14 AM, Dmitry Baryshkov wrote: On Tue, 6 Jun 2023 at 05:35, Abhinav Kumar wrote: On 6/5/2023 6:03 PM, Dmitry Baryshkov wrote: On 06/06/2023 03:55, Abhinav Kumar wrote: On 6/3/2023 7:21 PM, Dmitry Baryshkov wrote: On 31/05/2023 21:25, Abhinav Kumar wrote: On 5/31/2023 3:07 AM, Dmitry Baryshkov wrote: On 31/05/2023 06:05, Abhinav Kumar wrote: On 5/30/2023 7:53 PM, Dmitry Baryshkov wrote: On Wed, 31 May 2023 at 03:54, Abhinav Kumar wrote: With [1] dpu core revision was dropped in favor of using the compatible string from the device tree to select the dpu catalog being used in the device. This approach works well however also necessitates adding catalog entries for small register level details as dpu capabilities and/or features bloating the catalog unnecessarily. Examples include but are not limited to data_compress, interrupt register set, widebus etc. Introduce the dpu core revision back as an entry to the catalog so that we can just use dpu revision checks and enable those bits which should be enabled unconditionally and not controlled by a catalog and also simplify the changes to do something like: if (dpu_core_revision > x && dpu_core_revision < x) enable the bit; Also, add some of the useful macros back to be able to use dpu core revision effectively. [1]: https://patchwork.freedesktop.org/patch/530891/?series=113910=4 Signed-off-by: Abhinav Kumar --- .../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 1 + .../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 1 + .../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 1 + .../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h | 1 + .../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 1 + .../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 1 + .../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 1 + .../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 1 + .../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 1 + .../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 1 + .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 31 ++- 14 files changed, 43 insertions(+), 1 deletion(-) [skipped catalog changes] diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h index 677048cc3b7d..cc4aa75a1219 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h @@ -19,6 +19,33 @@ */ #define MAX_BLOCKS 12 +#define DPU_HW_VER(MAJOR, MINOR, STEP)\ + unsigned int)MAJOR & 0xF) << 28) |\ + ((MINOR & 0xFFF) << 16) |\ + (STEP & 0x)) + +#define DPU_HW_MAJOR(rev)((rev) >> 28) +#define DPU_HW_MINOR(rev)(((rev) >> 16) & 0xFFF) +#define DPU_HW_STEP(rev)((rev) & 0x) +#define DPU_HW_MAJOR_MINOR(rev)((rev) >> 16) + +#define IS_DPU_MAJOR_MINOR_SAME(rev1, rev2) \ +(DPU_HW_MAJOR_MINOR((rev1)) == DPU_HW_MAJOR_MINOR((rev2))) + +#define DPU_HW_VER_300 DPU_HW_VER(3, 0, 0) /* 8998 v1.0 */ +#define DPU_HW_VER_400 DPU_HW_VER(4, 0, 0) /* sdm845 v1.0 */ +#define DPU_HW_VER_500 DPU_HW_VER(5, 0, 0) /* sm8150 v1.0 */ +#define DPU_HW_VER_510 DPU_HW_VER(5, 1, 1) /* sc8180 */ +#define DPU_HW_VER_600 DPU_HW_VER(6, 0, 0) /* sm8250 */ +#define DPU_HW_VER_620 DPU_HW_VER(6, 2, 0) /* sc7180 v1.0 */ +#define DPU_HW_VER_630 DPU_HW_VER(6, 3, 0) /* sm6115|sm4250 */ +#define DPU_HW_VER_650 DPU_HW_VER(6, 5, 0) /* qcm2290|sm4125 */ +#define DPU_HW_VER_700 DPU_HW_VER(7, 0, 0) /* sm8350 */ +#define DPU_HW_VER_720 DPU_HW_VER(7, 2, 0) /* sc7280 */ +#define DPU_HW_VER_800 DPU_HW_VER(8, 0, 0) /* sc8280xp */ +#define DPU_HW_VER_810 DPU_HW_VER(8, 1, 0) /* sm8450 */ +#define DPU_HW_VER_900 DPU_HW_VER(9, 0, 0) /* sm8550 */ Instead of having defines for all SoCs (which can quickly become unmanageable) and can cause merge conflicts, I'd suggest inlining all the defines into respective catalog files. Sure, that can be done. Also, I'm not sure that the "step" should be a part of the catalog. I know that this follows the hardware revision. However, please correct me if I'm wrong, different step levels are used for revisions of the same SoC. The original code that was reading the hw revision from the hardware register, listed both 5.0.0 and 5.0.1 for sm8150. This is one of the things i noticed while making this change. Before the catalog rework, we used to handle even steps as we used to read that from the register and match it with the mdss_cfg handler. But after the rework, we dont handle steps anymore. Yes, you are right that different step levels are used for the revisions of the same SOC and so with that, i dont expect or atleast am not aware of DPU differences between steps but I am not able to rule it out. So are you suggesting we drop step
[PATCH] drm/nouveau: fix codeing style
drivers/gpu/drm/nouveau/dispnv04/crtc.c:453: warning: This comment starts with
'/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
* Sets up registers for the given mode/adjusted_mode pair.
drivers/gpu/drm/nouveau/dispnv04/crtc.c:629: warning: This comment starts with
'/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
* Sets up registers for the given mode/adjusted_mode pair.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index a6f2e681bde9..2a9400ba4b92 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -413,8 +413,8 @@ nv_crtc_mode_set_vga(struct drm_crtc *crtc, struct
drm_display_mode *mode)
regp->CRTC[NV_CIO_CRE_ILACE__INDEX] = 0xff; /* interlace off */
/*
- * Graphics Display Controller
- */
+* Graphics Display Controller
+*/
regp->Graphics[NV_VIO_GX_SR_INDEX] = 0x00;
regp->Graphics[NV_VIO_GX_SREN_INDEX] = 0x00;
regp->Graphics[NV_VIO_GX_CCOMP_INDEX] = 0x00;
@@ -449,7 +449,7 @@ nv_crtc_mode_set_vga(struct drm_crtc *crtc, struct
drm_display_mode *mode)
regp->Attribute[NV_CIO_AR_CSEL_INDEX] = 0x00;
}
-/**
+/*
* Sets up registers for the given mode/adjusted_mode pair.
*
* The clocks, CRTCs and outputs attached to this CRTC must be off.
@@ -625,7 +625,7 @@ nv_crtc_swap_fbs(struct drm_crtc *crtc, struct
drm_framebuffer *old_fb)
return ret;
}
-/**
+/*
* Sets up registers for the given mode/adjusted_mode pair.
*
* The clocks, CRTCs and outputs attached to this CRTC must be off.
@@ -1263,9 +1263,9 @@ static const struct drm_crtc_helper_funcs
nv04_crtc_helper_funcs = {
};
static const uint32_t modeset_formats[] = {
-DRM_FORMAT_XRGB,
-DRM_FORMAT_RGB565,
-DRM_FORMAT_XRGB1555,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB1555,
};
static const struct drm_plane_funcs nv04_primary_plane_funcs = {
--
2.25.1
Re: [PATCH v16] drm/msm/dpu: add DSC blocks to the catalog of MSM8998 and SC8180X
On 06/06/2023 21:31, Kuogee Hsieh wrote:
From: Abhinav Kumar
Some platforms have DSC blocks which have not been declared in the catalog.
Complete DSC 1.1 support for all platforms by adding the missing blocks to
MSM8998 and SC8180X.
Changes in v9:
-- add MSM8998 and SC8180x to commit title
Changes in v10:
-- fix grammar at commit text
Changes in v12:
-- fix "titil" with "title" at changes in v9
Changes in v14:
-- "dsc" tp "DSC" at commit title
Changes in v15:
-- fix merge conflicts at dpu_5_1_sc8180x.h
Changes in v16
-- fix cherry-pick error by deleting both redundant .dsc and .dsc_count
assignment from dpu_5_1_sc8180x.h
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
The patch was changed significantly. Thus the review-by's do not apply
anymore. Please take care to drop reviewed-by and acked-by tags when you
change the patch was changed in a sensible manner. Otherwise it would be
impossible to understand if the patch was really reviewed or not.
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index 3c732a0..7d0d0e7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -126,6 +126,11 @@ static const struct dpu_pingpong_cfg msm8998_pp[] = {
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 15)),
};
+static const struct dpu_dsc_cfg msm8998_dsc[] = {
+ DSC_BLK("dsc_0", DSC_0, 0x8, 0),
+ DSC_BLK("dsc_1", DSC_1, 0x80400, 0),
+};
+
static const struct dpu_dspp_cfg msm8998_dspp[] = {
DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_SC7180_MASK,
_dspp_sblk),
@@ -199,6 +204,8 @@ const struct dpu_mdss_cfg dpu_msm8998_cfg = {
.dspp = msm8998_dspp,
.pingpong_count = ARRAY_SIZE(msm8998_pp),
.pingpong = msm8998_pp,
+ .dsc_count = ARRAY_SIZE(msm8998_dsc),
+ .dsc = msm8998_dsc,
.intf_count = ARRAY_SIZE(msm8998_intf),
.intf = msm8998_intf,
.vbif_count = ARRAY_SIZE(msm8998_vbif),
--
With best wishes
Dmitry
Re: [PATCH v7 7/7] drm/etnaviv: add support for the dma coherent device
On Wed, Jun 07, 2023 at 02:43:27AM +0800, Sui Jingfeng wrote: > On 2023/6/7 00:56, Bjorn Helgaas wrote: > > On Sat, Jun 03, 2023 at 06:59:43PM +0800, Sui Jingfeng wrote: > > > From: Sui Jingfeng > > > > > > Loongson CPUs maintain cache coherency by hardware, which means that the > > > data in the CPU cache is identical to the data in main system memory. As > > > for the peripheral device, most of Loongson chips chose to define the > > > peripherals as DMA coherent by default, device drivers do not need to > > > maintain the coherency between a processor and an I/O device manually. > > ... > > I guess the only way to discover this coherency attribute is via the > > DT "vivante,gc" property? Seems a little weird but I'm really not a > > DT person. > > I'm not sure it is *only*, but it is very convenient to achieve such a thing > with DT. I don't know if this is a property of the PCI device, or a property of the system as a whole. I asked because PCI devices should be self-describing (the Device/Vendor ID should be enough to identify the correct driver, and the driver should know how to learn anything else it needs to know about the device from PCI config space) and should not require extra DT properties. But if this is a CPU or system property, you probably have to use a firmware interface like DT or ACPI. > > > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c > > > @@ -8,6 +8,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > > It looks like this #include might not be needed? > > No, the dev_is_dma_coherent() function is declared and defined in > dma-map-ops.h. if remove it, gcc will complain: > > drivers/gpu/drm/etnaviv/etnaviv_drv.c: In function > ‘etnaviv_is_dma_coherent’: > drivers/gpu/drm/etnaviv/etnaviv_drv.c:56:14: error: implicit declaration of > function ‘dev_is_dma_coherent’; did you mean ‘etnaviv_is_dma_coherent’? > [-Werror=implicit-function-declaration] > 56 | coherent = dev_is_dma_coherent(dev); > | ^~~ Of course, but that warning is for etnaviv_drv.c, not for etnaviv_gpu.c. So etnaviv_drv.c needs to include dma-map-ops.h, but I don't think etnaviv_gpu.c does. I removed this #include from etnaviv_gpu.c and it still built without errors. > > You're only adding a > > new reference to priv->dma_coherent, which looks like it was added to > > etnaviv_drv.h.
