Re: [Intel-gfx] [PATCH] drm/i915: Kick rcu harder to free objects
On Thu, Sep 08, 2022 at 09:34:04PM +0200, Das, Nirmoy wrote: > > On 9/8/2022 5:11 PM, Ville Syrjälä wrote: > > On Thu, Sep 08, 2022 at 04:32:56PM +0200, Das, Nirmoy wrote: > >> Hi Ville, > >> > >> > >> I fixed a similar issue in DII but I couldn't reproduce it in drm > >> > >> http://intel-gfx-pw.fi.intel.com/patch/228850/?series=15910&rev=2. > >> > >> I wonder if that fixes the problem you are facing then I can send that > >> to drm. > > CI can tell you. It has been complaining about this for ages > > > Could you please share a url/failed test name. I must be searching the > wrong hw/test(https://intel-gfx-ci.01.org/tree/drm-tip/fi-ivb-3770.html). https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12102/fi-pnv-d510/igt@i915_selftest@l...@requests.html gen3 hits it nearly 100% of the time in the live selftests. IIRC it also looked like shard-snb has also hit it more sporadically in some tests. There's also at least one bug about it https://gitlab.freedesktop.org/drm/intel/-/issues/4528 which I guess is why ci is able to ignore this, and that then has enabled all the humans to ignore it as well. -- Ville Syrjälä Intel
[Intel-gfx] [PATCH v3 01/37] drm/i915: fix kernel-doc trivial warnings on i915/*.[ch] files
There are several trivial warnings there, due to trivial things: - lack of function name at the kerneldoc markup; - renamed functions; - wrong parameter syntax. Fix such warnings: drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'active' not described in '__i915_active_fence_init' drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'fence' not described in '__i915_active_fence_init' drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'fn' not described in '__i915_active_fence_init' drivers/gpu/drm/i915/i915_active.h:89: warning: Function parameter or member 'active' not described in 'i915_active_fence_set' drivers/gpu/drm/i915/i915_active.h:89: warning: Function parameter or member 'rq' not described in 'i915_active_fence_set' drivers/gpu/drm/i915/i915_active.h:102: warning: Function parameter or member 'active' not described in 'i915_active_fence_get' drivers/gpu/drm/i915/i915_active.h:122: warning: Function parameter or member 'active' not described in 'i915_active_fence_isset' drivers/gpu/drm/i915/i915_gem.c:443: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Reads data from the object referenced by handle. drivers/gpu/drm/i915/i915_gem.c:532: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * This is the fast pwrite path, where we copy the data directly from the drivers/gpu/drm/i915/i915_gem.c:717: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Writes data to the object referenced by handle. drivers/gpu/drm/i915/i915_gem.c:802: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Called when user space has done writes to this buffer drivers/gpu/drm/i915/i915_pmu.h:22: warning: cannot understand function prototype: 'enum i915_pmu_tracked_events ' drivers/gpu/drm/i915/i915_pmu.h:33: warning: cannot understand function prototype: 'enum ' drivers/gpu/drm/i915/i915_pmu.h:42: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * How many different events we track in the global PMU mask. drivers/gpu/drm/i915/i915_request.h:177: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Request queue structure. drivers/gpu/drm/i915/i915_request.h:473: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Returns true if seq1 is later than seq2. drivers/gpu/drm/i915/i915_scatterlist.c:63: warning: Function parameter or member 'size' not described in 'i915_refct_sgt_init' drivers/gpu/drm/i915/i915_scatterlist.h:153: warning: Incorrect use of kernel-doc format: * release() - Free the memory of the struct i915_refct_sgt drivers/gpu/drm/i915/i915_scatterlist.h:157: warning: Function parameter or member 'release' not described in 'i915_refct_sgt_ops' drivers/gpu/drm/i915/i915_scatterlist.h:180: warning: Function parameter or member 'rsgt' not described in 'i915_refct_sgt_put' drivers/gpu/drm/i915/i915_scatterlist.h:191: warning: Function parameter or member 'rsgt' not described in 'i915_refct_sgt_get' drivers/gpu/drm/i915/i915_scatterlist.h:207: warning: Function parameter or member 'rsgt' not described in '__i915_refct_sgt_init' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'OP' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'COND' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'US' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'Wmin' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'Wmax' not described in '__wait_for' drivers/gpu/drm/i915/i915_vma_resource.h:88: warning: Incorrect use of kernel-doc format: * struct i915_vma_bindinfo - Information needed for async bind drivers/gpu/drm/i915/i915_vma_resource.h:123: warning: Function parameter or member 'bi' not described in 'i915_vma_resource' Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@ker
[Intel-gfx] [PATCH v3 06/37] drm/i915: intel_wakeref.h: fix some kernel-doc markups
Two documented functions don't match the kernel-doc comments, as reported by kernel-doc: drivers/gpu/drm/i915/intel_wakeref.h:117: warning: expecting prototype for intel_wakeref_get_if_in_use(). Prototype was for intel_wakeref_get_if_active() instead drivers/gpu/drm/i915/intel_wakeref.h:149: warning: expecting prototype for intel_wakeref_put_flags(). Prototype was for __intel_wakeref_put() instead Fix them. Additionally, improve title for intel_wakeref_get_if_active(). Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/intel_wakeref.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_wakeref.h b/drivers/gpu/drm/i915/intel_wakeref.h index 4f4c2e15e736..63e539c9b1f3 100644 --- a/drivers/gpu/drm/i915/intel_wakeref.h +++ b/drivers/gpu/drm/i915/intel_wakeref.h @@ -104,7 +104,7 @@ __intel_wakeref_get(struct intel_wakeref *wf) } /** - * intel_wakeref_get_if_in_use: Acquire the wakeref + * intel_wakeref_get_if_active: Acquire the wakeref if active * @wf: the wakeref * * Acquire a hold on the wakeref, but only if the wakeref is already @@ -130,7 +130,7 @@ intel_wakeref_might_get(struct intel_wakeref *wf) } /** - * intel_wakeref_put_flags: Release the wakeref + * __intel_wakeref_put: Release the wakeref * @wf: the wakeref * @flags: control flags * -- 2.37.3
[Intel-gfx] [PATCH v3 08/37] drm/i915: i915_gem_ttm_pm.c: fix kernel-doc markups
The documentation for the flags field is missing there. It sounds that some last-time change converted some bools into flags, but the kernel-doc change didn't follow it. Fix those warnings: drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:135: warning: Function parameter or member 'flags' not described in 'i915_ttm_backup_region' drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:135: warning: Excess function parameter 'allow_gpu' description in 'i915_ttm_backup_region' drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:135: warning: Excess function parameter 'backup_pinned' description in 'i915_ttm_backup_region' drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:199: warning: Function parameter or member 'flags' not described in 'i915_ttm_restore_region' drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:199: warning: Excess function parameter 'allow_gpu' description in 'i915_ttm_restore_region' Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c index 07e49f22f2de..03256ebbeb5f 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c @@ -128,8 +128,9 @@ void i915_ttm_recover_region(struct intel_memory_region *mr) /** * i915_ttm_backup_region - Back up all objects of a region to smem. * @mr: The memory region - * @allow_gpu: Whether to allow the gpu blitter for this backup. - * @backup_pinned: Backup also pinned objects. + * @flags: Bitmap field with the following flags: + * %I915_TTM_BACKUP_ALLOW_GPU: allow the gpu blitter for this backup; + * %I915_TTM_BACKUP_PINNED: backup also pinned objects. * * Loops over all objects of a region and either evicts them if they are * evictable or backs them up using a backup object if they are pinned. @@ -193,7 +194,8 @@ static int i915_ttm_restore(struct i915_gem_apply_to_region *apply, /** * i915_ttm_restore_region - Restore backed-up objects of a region from smem. * @mr: The memory region - * @allow_gpu: Whether to allow the gpu blitter to recover. + * @flags: Bitmap field with the following flags: + * %I915_TTM_BACKUP_ALLOW_GPU: allow the gpu blitter for this backup; * * Loops over all objects of a region and if they are backed-up, restores * them from smem. -- 2.37.3
[Intel-gfx] [PATCH v3 00/37] drm/i915: fix kernel-doc issues
There are several kernel-doc markups along the i915 driver that aren't part of the i915.rst file, nor are included on any other file under Documentation. Maybe due to that, there are several kernel-doc markups that report problems when checked with scripts/kernel-doc. More than that, some of them also have problems when actually integrated at the building system, as reported by Sphinx. Along the issues we have: - renamed symbols where the prototype doesn't match the kernel-doc name; - some markups doesn't have the symbol name on it; - typos when defining parameter; - some parameters are missing; - some ascii artwork aren't properly displayed after parsed by Sphinx; - some other tags produce bad results and warnings after parsed by html build; - some "/**" patterns exist on places that aren't kernel-doc markups. This series, against drm-tip, fix all the above issues and all all such files to i915.rst. This way, it will be easier to avoid other problems to be introduced. While here, I also added SPDX on two display files. Besides being the current way to indicate the license, it also makes easier to find all files with kernel-doc markups, as all it is needed is to search for "/**" at i915 files to know what of them have embedded documentation. PS.: my end goal here is to ensure that the TLB patch series I'm about to send will be properly documented. For that to happen, let's first fix all warnings when building the documentation ;-) --- v3: - Dropped patches with issues already fixed; - Addressed Rodrigo's comments. v2: - Added 3 already-existing patches form other PRs addressing some of the issues. The subjects were renamed, in order to describe what they're doing. - Fixed checkpatch warnings; - Added 4 additional patches at the end, documenting some structs at i915_gem_object_types.h and intel_gt_pm.h, plus adding intel-guc.c internal functions to the generated documentation. Mauro Carvalho Chehab (37): drm/i915: fix kernel-doc trivial warnings on i915/*.[ch] files drm/i915: display: fix kernel-doc markup warnings drm/i915: gt: fix some Kernel-doc issues drm/i915: gvt: fix kernel-doc trivial warnings drm/i915: gem: fix some Kernel-doc issues drm/i915: intel_wakeref.h: fix some kernel-doc markups drm/i915: i915_gem_ttm: fix a kernel-doc markup drm/i915: i915_gem_ttm_pm.c: fix kernel-doc markups drm/i915: gem: add kernel-doc description for some function parameters drm/i915: i915_gpu_error.c: document dump_flags drm/i915: document kernel-doc trivial issues drm/i915: intel_dp_link_training.c: fix kernel-doc markup drm/i915: intel_fb: fix a kernel-doc issue with Sphinx drm/i915: skl_scaler: fix return value kernel-doc markup drm/i915: intel_pm.c: fix some ascii artwork at kernel-doc drm/i915: i915_gem_region.h: fix i915_gem_apply_to_region_ops doc drm/i915: i915_gem_wait.c: fix a kernel-doc markup drm/i915: fix i915_gem_ttm_move.c DOC: markup drm/i915: stop using kernel-doc markups for something else drm/i915: dvo_ch7xxx.c: use SPDX header drm/i915: dvo_sil164.c: use SPDX header drm/i915: i915_vma_resource.c: fix some kernel-doc markups drm/i915: i915_gem.c fix a kernel-doc issue drm/i915: i915_scatterlist.h: fix some kernel-doc markups drm/i915: i915_deps: use a shorter title markup docs: gpu: i915.rst: display: add kernel-doc markups docs: gpu: i915.rst: gt: add more kernel-doc markups docs: gpu: i915.rst: GuC: add more kernel-doc markups docs: gpu: i915.rst: GVT: add more kernel-doc markups docs: gpu: i915.rst: PM: add more kernel-doc markups docs: gpu: i915.rst: GEM/TTM: add more kernel-doc markups docs: gpu: i915.rst: add the remaining kernel-doc markup files drm/i915 i915_gem_object_types.h: document struct i915_lut_handle drm/i915: document struct drm_i915_gem_object drm/i915: add descriptions for some RPM macros at intel_gt_pm.h drm/i915: add GuC functions to the documentation drm/i915: be consistent with kernel-doc function declaration Documentation/gpu/i915.rst| 283 +- drivers/gpu/drm/i915/display/dvo_ch7017.c | 26 +- drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 39 +-- drivers/gpu/drm/i915/display/dvo_sil164.c | 32 +- drivers/gpu/drm/i915/display/intel_atomic.c | 2 +- drivers/gpu/drm/i915/display/intel_audio.c| 4 +- drivers/gpu/drm/i915/display/intel_crtc.c | 4 +- .../drm/i915/display/intel_display_debugfs.c | 2 +- .../drm/i915/display/intel_display_power.c| 2 +- .../drm/i915/display/intel_display_types.h| 2 +- drivers/gpu/drm/i915/display/intel_dmc.c | 10 +- .../drm/i915/display/intel_dp_link_training.c | 2 + drivers/gpu/drm/i915/display/intel_dsb.c | 10 +- drivers/gpu/drm/i915/display/intel_dvo_dev.h | 6 +- drivers/gpu/drm/i915/display/intel_fb.c | 2 +- .../gpu/drm/i915/display/intel_lpe_audio.c| 8 +- drivers/gpu/drm/i915/display/intel_sdvo.c | 4 +- drivers/gpu/drm/i915/
[Intel-gfx] [PATCH v3 04/37] drm/i915: gvt: fix kernel-doc trivial warnings
Some functions seem to have been renamed without updating the kernel-doc
markup causing warnings. Also, struct intel_vgpu_dmabuf_obj is not
properly documented, but has a kerneld-doc markup.
Fix those warnings:
drivers/gpu/drm/i915/gvt/aperture_gm.c:308: warning: expecting
prototype for inte_gvt_free_vgpu_resource(). Prototype was for
intel_vgpu_free_resource() instead
drivers/gpu/drm/i915/gvt/aperture_gm.c:344: warning: expecting
prototype for intel_alloc_vgpu_resource(). Prototype was for
intel_vgpu_alloc_resource() instead
drivers/gpu/drm/i915/gvt/cfg_space.c:257: warning: expecting prototype
for intel_vgpu_emulate_cfg_read(). Prototype was for
intel_vgpu_emulate_cfg_write() instead
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or
member 'vgpu' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or
member 'info' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or
member 'dmabuf_id' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or
member 'kref' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or
member 'initref' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or
member 'list' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/handlers.c:3066: warning: expecting prototype
for intel_t_default_mmio_write(). Prototype was for
intel_vgpu_default_mmio_write() instead
drivers/gpu/drm/i915/gvt/mmio_context.c:560: warning: expecting
prototype for intel_gvt_switch_render_mmio(). Prototype was for
intel_gvt_switch_mmio() instead
drivers/gpu/drm/i915/gvt/page_track.c:131: warning: expecting prototype
for intel_vgpu_enable_page_track(). Prototype was for
intel_vgpu_disable_page_track() instead
drivers/gpu/drm/i915/gvt/vgpu.c:215: warning: expecting prototype for
intel_gvt_active_vgpu(). Prototype was for intel_gvt_activate_vgpu() instead
drivers/gpu/drm/i915/gvt/vgpu.c:230: warning: expecting prototype for
intel_gvt_deactive_vgpu(). Prototype was for intel_gvt_deactivate_vgpu() instead
drivers/gpu/drm/i915/gvt/vgpu.c:358: warning: expecting prototype for
intel_gvt_destroy_vgpu(). Prototype was for intel_gvt_destroy_idle_vgpu()
instead
Reviewed-by: Rodrigo Vivi
Acked-by: Zhenyu Wang
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/gvt/cfg_space.c | 2 +-
drivers/gpu/drm/i915/gvt/dmabuf.h | 2 +-
drivers/gpu/drm/i915/gvt/page_track.c | 2 +-
drivers/gpu/drm/i915/gvt/vgpu.c | 6 +++---
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/cfg_space.c
b/drivers/gpu/drm/i915/gvt/cfg_space.c
index eef3bba8a41b..bff63babacd5 100644
--- a/drivers/gpu/drm/i915/gvt/cfg_space.c
+++ b/drivers/gpu/drm/i915/gvt/cfg_space.c
@@ -244,7 +244,7 @@ static void emulate_pci_bar_write(struct intel_vgpu *vgpu,
unsigned int offset,
}
/**
- * intel_vgpu_emulate_cfg_read - emulate vGPU configuration space write
+ * intel_vgpu_emulate_cfg_write - emulate vGPU configuration space write
* @vgpu: target vgpu
* @offset: offset
* @p_data: write data ptr
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.h
b/drivers/gpu/drm/i915/gvt/dmabuf.h
index 5f8f03fb1d1b..3dcdb6570eda 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.h
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.h
@@ -48,7 +48,7 @@ struct intel_vgpu_fb_info {
struct intel_vgpu_dmabuf_obj *obj;
};
-/**
+/*
* struct intel_vgpu_dmabuf_obj- Intel vGPU device buffer object
*/
struct intel_vgpu_dmabuf_obj {
diff --git a/drivers/gpu/drm/i915/gvt/page_track.c
b/drivers/gpu/drm/i915/gvt/page_track.c
index 3375b51c75f1..df34e73cba41 100644
--- a/drivers/gpu/drm/i915/gvt/page_track.c
+++ b/drivers/gpu/drm/i915/gvt/page_track.c
@@ -120,7 +120,7 @@ int intel_vgpu_enable_page_track(struct intel_vgpu *vgpu,
unsigned long gfn)
}
/**
- * intel_vgpu_enable_page_track - cancel write-protection on guest page
+ * intel_vgpu_disable_page_track - cancel write-protection on guest page
* @vgpu: a vGPU
* @gfn: the gfn of guest page
*
diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index 46da19b3225d..8e71cda19995 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -205,7 +205,7 @@ static void intel_gvt_update_vgpu_types(struct intel_gvt
*gvt)
}
/**
- * intel_gvt_active_vgpu - activate a virtual GPU
+ * intel_gvt_activate_vgpu - activate a virtual GPU
* @vgpu: virtual GPU
*
* This function is called when user wants
[Intel-gfx] [PATCH v3 26/37] docs: gpu: i915.rst: display: add kernel-doc markups
There are several documented kAPI at the display side that aren't currently part of the docs. Add them, as this allows identifying issues with badly-formatted tags. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ Documentation/gpu/i915.rst | 50 ++ 1 file changed, 50 insertions(+) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 4e59db1cfb00..2ad7941a79f2 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -100,6 +100,56 @@ Display FIFO Underrun Reporting .. kernel-doc:: drivers/gpu/drm/i915/display/intel_fifo_underrun.c :internal: +Atomic Modeset Support +-- + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic.c + +Display Power Domain + + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display_power.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display_power_map.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display_power_well.c + +Misc display functions +-- + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_backlight.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_crtc.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_connector.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display_debugfs.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp_link_training.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpt.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fb.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fb_pin.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_gmbus.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_lvds.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_opregion.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_snps_phy.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_tc.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/skl_scaler.c + + Plane Configuration --- -- 2.37.3
[Intel-gfx] [PATCH v3 27/37] docs: gpu: i915.rst: gt: add more kernel-doc markups
There are several documented GT kAPI that aren't currently part of the docs. Add them, as this allows identifying issues with badly-formatted tags. Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ Documentation/gpu/i915.rst | 40 +- 1 file changed, 39 insertions(+), 1 deletion(-) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 2ad7941a79f2..b668f36fb0a3 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -149,7 +149,6 @@ Misc display functions .. kernel-doc:: drivers/gpu/drm/i915/display/skl_scaler.c - Plane Configuration --- @@ -308,6 +307,45 @@ Multicast/Replicated (MCR) Registers .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_mcr.c :internal: +GT engine +- + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_types.h + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_cs.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_pm.c + +Graphics Translation Tables +--- + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_ggtt.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gtt.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gtt.h + +Other GT functionality +-- + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_context.h + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gsc.h + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_migrate.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_mocs.h + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rc6.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_reset.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rps_types.h + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rps.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_sseu.c + Memory Management and Command Submission -- 2.37.3
[Intel-gfx] [PATCH v3 24/37] drm/i915: i915_scatterlist.h: fix some kernel-doc markups
Building docs currently produces this warning: Documentation/foo/i915:159: ./drivers/gpu/drm/i915/i915_scatterlist.h:73: WARNING: Inline strong start-string without end-string. That's because @foo evaluates into **foo**, and placing anything after it without spaces cause Sphinx to warn and do the wrong thing.. So, replace them by a different Sphinx-compatible tag. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/i915_scatterlist.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h b/drivers/gpu/drm/i915/i915_scatterlist.h index 79b70ae2e766..ac77f2668544 100644 --- a/drivers/gpu/drm/i915/i915_scatterlist.h +++ b/drivers/gpu/drm/i915/i915_scatterlist.h @@ -70,7 +70,7 @@ static inline struct scatterlist *sg_next(struct scatterlist *sg) * * Description: * If the entry is the last, return NULL; otherwise, step to the next - * element in the array (@sg@+1). If that's a chain pointer, follow it; + * element in the array (``sg@+1``). If that's a chain pointer, follow it; * otherwise just return the pointer to the current element. **/ static inline struct scatterlist *__sg_next(struct scatterlist *sg) -- 2.37.3
[Intel-gfx] [PATCH v3 30/37] docs: gpu: i915.rst: PM: add more kernel-doc markups
Both intel_runtime_pm.h and intel_pm.c contains kAPI for runtime PM. So, add them to the documentation. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ Documentation/gpu/i915.rst | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index da64ebdaa9e0..4ce04a457ccc 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -25,6 +25,10 @@ Runtime Power Management .. kernel-doc:: drivers/gpu/drm/i915/intel_uncore.c :internal: +.. kernel-doc:: drivers/gpu/drm/i915/intel_runtime_pm.h + +.. kernel-doc:: drivers/gpu/drm/i915/intel_pm.c + Interrupt Handling -- -- 2.37.3
[Intel-gfx] [PATCH v3 07/37] drm/i915: i915_gem_ttm: fix a kernel-doc markup
Two new fields were added to __i915_gem_ttm_object_init() without
their corresponding documentation.
Document them.
Fixes: 9b78b5dade2d ("drm/i915: add i915_gem_object_create_region_at()")
Reviewed-by: Nirmoy Das
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index f64a3deb12fc..f5fb06d74f13 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1148,7 +1148,9 @@ void i915_ttm_bo_destroy(struct ttm_buffer_object *bo)
* __i915_gem_ttm_object_init - Initialize a ttm-backed i915 gem object
* @mem: The initial memory region for the object.
* @obj: The gem object.
+ * @offset: The range start.
* @size: Object size in bytes.
+ * @page_size: The requested page size in bytes for this object.
* @flags: gem object flags.
*
* Return: 0 on success, negative error code on failure.
--
2.37.3
[Intel-gfx] [PATCH v3 12/37] drm/i915: intel_dp_link_training.c: fix kernel-doc markup
The return code table is not properly marked, causing warnings
and being badly parsed by Sphinx:
Documentation/gpu/i915:130:
./drivers/gpu/drm/i915/display/intel_dp_link_training.c:183: WARNING: Block
quote ends without a blank line; unexpected unindent.
Documentation/gpu/i915:130:
./drivers/gpu/drm/i915/display/intel_dp_link_training.c:186: WARNING:
Definition list ends without a blank line; unexpected unindent.
Use table markups to fix it.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index d213d8ad1ea5..27c3b9f39c8b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -177,12 +177,14 @@ static int intel_dp_init_lttpr(struct intel_dp *intel_dp,
const u8 dpcd[DP_RECEI
* transparent mode link training mode.
*
* Returns:
+ * =
* >0 if LTTPRs were detected and the non-transparent LT mode was set. The
* DPRX capabilities are read out.
*0 if no LTTPRs or more than 8 LTTPRs were detected or in case of a
* detection failure and the transparent LT mode was set. The DPRX
* capabilities are read out.
* <0 Reading out the DPRX capabilities failed.
+ * =
*/
int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp)
{
--
2.37.3
[Intel-gfx] [PATCH v3 17/37] drm/i915: i915_gem_wait.c: fix a kernel-doc markup
The return codes for i915_gem_wait_ioctl() have identation issues, and will be displayed on a very confusing way. Use lists to improve its output. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/gem/i915_gem_wait.c | 24 +--- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c b/drivers/gpu/drm/i915/gem/i915_gem_wait.c index 4a33ad2d122b..1fd5cff552ed 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c @@ -210,23 +210,25 @@ static unsigned long to_wait_timeout(s64 timeout_ns) * @data: ioctl data blob * @file: drm file pointer * - * Returns 0 if successful, else an error is returned with the remaining time in - * the timeout parameter. - * -ETIME: object is still busy after timeout - * -ERESTARTSYS: signal interrupted the wait - * -ENONENT: object doesn't exist - * Also possible, but rare: - * -EAGAIN: incomplete, restart syscall - * -ENOMEM: damn - * -ENODEV: Internal IRQ fail - * -E?: The add request failed - * * The wait ioctl with a timeout of 0 reimplements the busy ioctl. With any * non-zero timeout parameter the wait ioctl will wait for the given number of * nanoseconds on an object becoming unbusy. Since the wait itself does so * without holding struct_mutex the object may become re-busied before this * function completes. A similar but shorter * race condition exists in the busy * ioctl + * + * Returns: + * 0 if successful, else an error is returned with the remaining time in + * the timeout parameter. + * * -ETIME: object is still busy after timeout + * * -ERESTARTSYS: signal interrupted the wait + * * -ENONENT: object doesn't exist + * + * Also possible, but rare: + * * -EAGAIN: incomplete, restart syscall + * * -ENOMEM: damn + * * -ENODEV: Internal IRQ fail + * * -E?: The add request failed */ int i915_gem_wait_ioctl(struct drm_device *dev, void *data, struct drm_file *file) -- 2.37.3
[Intel-gfx] [PATCH v3 19/37] drm/i915: stop using kernel-doc markups for something else
There are some occurrences of "/**" that aren't actually part of
a kernel-doc markup. Replace them by "/*", in order to make easier
to identify what i915 files contain kernel-doc markups.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/display/dvo_ch7017.c | 26 +++
drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 6 +-
.../drm/i915/display/intel_display_types.h| 2 +-
drivers/gpu/drm/i915/display/intel_dvo_dev.h | 6 +-
drivers/gpu/drm/i915/display/intel_sdvo.c | 4 +-
drivers/gpu/drm/i915/display/intel_tv.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 69 +--
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 2 +-
drivers/gpu/drm/i915/gt/intel_gt_types.h | 12 ++--
drivers/gpu/drm/i915/gt/intel_reset_types.h | 4 +-
.../gpu/drm/i915/gt/intel_timeline_types.h| 6 +-
.../drm/i915/gt/shaders/clear_kernel/hsw.asm | 4 +-
.../drm/i915/gt/shaders/clear_kernel/ivb.asm | 4 +-
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 10 +--
drivers/gpu/drm/i915/i915_drm_client.h| 2 +-
drivers/gpu/drm/i915/i915_drv.h | 24 +++
drivers/gpu/drm/i915/i915_file_private.h | 8 +--
drivers/gpu/drm/i915/i915_gpu_error.h | 4 +-
drivers/gpu/drm/i915/i915_pmu.h | 32 -
drivers/gpu/drm/i915/intel_uncore.h | 4 +-
20 files changed, 115 insertions(+), 116 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/dvo_ch7017.c
b/drivers/gpu/drm/i915/display/dvo_ch7017.c
index 0589994dde11..581e29ab77e4 100644
--- a/drivers/gpu/drm/i915/display/dvo_ch7017.c
+++ b/drivers/gpu/drm/i915/display/dvo_ch7017.c
@@ -55,13 +55,13 @@
#define CH7017_TEST_PATTERN0x48
#define CH7017_POWER_MANAGEMENT0x49
-/** Enables the TV output path. */
+/* Enables the TV output path. */
#define CH7017_TV_EN (1 << 0)
#define CH7017_DAC0_POWER_DOWN (1 << 1)
#define CH7017_DAC1_POWER_DOWN (1 << 2)
#define CH7017_DAC2_POWER_DOWN (1 << 3)
#define CH7017_DAC3_POWER_DOWN (1 << 4)
-/** Powers down the TV out block, and DAC0-3 */
+/* Powers down the TV out block, and DAC0-3 */
#define CH7017_TV_POWER_DOWN_EN(1 << 5)
#define CH7017_VERSION_ID 0x4a
@@ -84,26 +84,26 @@
#define CH7017_UP_SCALER_HORIZONTAL_INC_1 0x5e
#define CH7017_HORIZONTAL_ACTIVE_PIXEL_INPUT 0x5f
-/**< Low bits of horizontal active pixel input */
+/* Low bits of horizontal active pixel input */
#define CH7017_ACTIVE_INPUT_LINE_OUTPUT0x60
-/** High bits of horizontal active pixel input */
+/* High bits of horizontal active pixel input */
#define CH7017_LVDS_HAP_INPUT_MASK (0x7 << 0)
-/** High bits of vertical active line output */
+/* High bits of vertical active line output */
#define CH7017_LVDS_VAL_HIGH_MASK (0x7 << 3)
#define CH7017_VERTICAL_ACTIVE_LINE_OUTPUT 0x61
-/**< Low bits of vertical active line output */
+/* Low bits of vertical active line output */
#define CH7017_HORIZONTAL_ACTIVE_PIXEL_OUTPUT 0x62
-/**< Low bits of horizontal active pixel output */
+/* Low bits of horizontal active pixel output */
#define CH7017_LVDS_POWER_DOWN 0x63
-/** High bits of horizontal active pixel output */
+/* High bits of horizontal active pixel output */
#define CH7017_LVDS_HAP_HIGH_MASK (0x7 << 0)
-/** Enables the LVDS power down state transition */
+/* Enables the LVDS power down state transition */
#define CH7017_LVDS_POWER_DOWN_EN (1 << 6)
-/** Enables the LVDS upscaler */
+/* Enables the LVDS upscaler */
#define CH7017_LVDS_UPSCALER_EN(1 << 7)
#define CH7017_LVDS_POWER_DOWN_DEFAULT_RESERVED 0x08
@@ -116,9 +116,9 @@
#define CH7017_LVDS_ENCODING_2 0x65
#define CH7017_LVDS_PLL_CONTROL0x66
-/** Enables the LVDS panel output path */
+/* Enables the LVDS panel output path */
#define CH7017_LVDS_PANEN (1 << 0)
-/** Enables the LVDS panel backlight */
+/* Enables the LVDS panel backlight */
#define CH7017_LVDS_BKLEN (1 << 3)
#define CH7017_POWER_SEQUENCING_T1 0x67
@@ -197,7 +197,7 @@ static bool ch7017_write(struct intel_dvo_device *dvo, u8
addr, u8 val)
return i2c_transfer(dvo->i2c_bus, &msg, 1) == 1;
}
-/** Probes for a CH7017 on the given bus and slave address. */
+/* Probes for a CH7017 on the given bus and slave address. */
static bool ch7017_init(struct intel_dvo_device *dvo,
struct i2c_adapter *adapter)
{
diff --git a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
index 54f58ba44b9f..1c1fe1f29675 100644
--- a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
+++ b/drivers/gpu/drm/i915/display/dvo_ch7xxx.
[Intel-gfx] [PATCH v3 13/37] drm/i915: intel_fb: fix a kernel-doc issue with Sphinx
We can't use %foo[] as this produces a bad markup. Use instead, the emphasis markup directly. Fix this issue: Documentation/gpu/i915:136: ./drivers/gpu/drm/i915/display/intel_fb.c:280: WARNING: Inline strong start-string without end-string. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/display/intel_fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_fb.c b/drivers/gpu/drm/i915/display/intel_fb.c index eefa33c555ac..ba413e38033d 100644 --- a/drivers/gpu/drm/i915/display/intel_fb.c +++ b/drivers/gpu/drm/i915/display/intel_fb.c @@ -276,7 +276,7 @@ lookup_format_info(const struct drm_format_info formats[], * @cmd: FB add command structure * * Returns: - * Returns the format information for @cmd->pixel_format specific to @cmd->modifier[0], + * Returns the format information for @cmd->pixel_format specific to ``cmd->modifier[0]``, * or %NULL if the modifier doesn't override the format. */ const struct drm_format_info * -- 2.37.3
[Intel-gfx] [PATCH v3 29/37] docs: gpu: i915.rst: GVT: add more kernel-doc markups
There are several documented GVT kAPI that aren't currently part of the docs. Add them, as this allows identifying issues with badly-formatted tags. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ Documentation/gpu/i915.rst | 41 ++ 1 file changed, 41 insertions(+) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 7f2daa1b4a8b..da64ebdaa9e0 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -58,6 +58,47 @@ Intel GVT-g Host Support(vGPU device model) .. kernel-doc:: drivers/gpu/drm/i915/intel_gvt.c :internal: +Other Intel GVT-g interfaces + + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/gvt.h + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/aperture_gm.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/cfg_space.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/debugfs.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/display.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/edid.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/fb_decoder.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/firmware.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/gtt.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/handlers.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/interrupt.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/kvmgt.c + +.. kernel-doc:: drivers/gpu/drm/i915/intel_gvt_mmio_table.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/mmio.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/mmio_context.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/opregion.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/page_track.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/scheduler.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/vgpu.c + Workarounds --- -- 2.37.3
[Intel-gfx] [PATCH v3 20/37] drm/i915: dvo_ch7xxx.c: use SPDX header
This file is licensed with MIT license. Change its license text to use SPDX. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 33 +-- 1 file changed, 6 insertions(+), 27 deletions(-) diff --git a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c index 1c1fe1f29675..b4d94a565fdb 100644 --- a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c +++ b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c @@ -1,30 +1,9 @@ -/** - -Copyright © 2006 Dave Airlie - -All Rights Reserved. - -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, sub license, 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 (including the -next paragraph) 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 NON-INFRINGEMENT. -IN NO EVENT SHALL THE AUTHOR 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. - -**/ +// SPDX-License-Identifier: MIT +/* + * Copyright © 2006 Dave Airlie + * + * All Rights Reserved. + */ #include "intel_display_types.h" #include "intel_dvo_dev.h" -- 2.37.3
[Intel-gfx] [PATCH v3 21/37] drm/i915: dvo_sil164.c: use SPDX header
This file is licensed with MIT license. Change its license text to use SPDX. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/display/dvo_sil164.c | 32 +-- 1 file changed, 6 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/i915/display/dvo_sil164.c b/drivers/gpu/drm/i915/display/dvo_sil164.c index 0dfa0a0209ff..12974f7c9dc1 100644 --- a/drivers/gpu/drm/i915/display/dvo_sil164.c +++ b/drivers/gpu/drm/i915/display/dvo_sil164.c @@ -1,30 +1,10 @@ -/** +// SPDX-License-Identifier: MIT -Copyright © 2006 Dave Airlie - -All Rights Reserved. - -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, sub license, 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 (including the -next paragraph) 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 NON-INFRINGEMENT. -IN NO EVENT SHALL THE AUTHOR 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. - -**/ +/* + * Copyright © 2006 Dave Airlie + * + * All Rights Reserved. + */ #include "intel_display_types.h" #include "intel_dvo_dev.h" -- 2.37.3
[Intel-gfx] [PATCH v3 34/37] drm/i915: document struct drm_i915_gem_object
This is a large struct used to describe gem objects. It is
currently partially documented. Finish its documentation, filling
the gaps from git logs.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
.../gpu/drm/i915/gem/i915_gem_object_types.h | 200 ++
1 file changed, 158 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 35746cf268ea..577f02b16b23 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -233,6 +233,9 @@ struct i915_gem_object_page_iter {
struct mutex lock; /* protects this cache */
};
+/**
+ * struct drm_i915_gem_object - describes an i915 GEM object
+ */
struct drm_i915_gem_object {
/*
* We might have reason to revisit the below since it wastes
@@ -241,12 +244,16 @@ struct drm_i915_gem_object {
* when accessing it.
*/
union {
+ /** @base: GEM base object */
struct drm_gem_object base;
+ /** @__do_not_access: TTM buffer object */
struct ttm_buffer_object __do_not_access;
};
+ /** @ops: pointer to GEM object ops */
const struct drm_i915_gem_object_ops *ops;
+ /** @vma: struct containing VMA list, tree and lock */
struct {
/**
* @vma.lock: protect the list/tree of vmas
@@ -280,10 +287,12 @@ struct drm_i915_gem_object {
*
* If this object is closed, we need to remove all of its VMA from
* the fast lookup index in associated contexts; @lut_list provides
-* this translation from object to context->handles_vma.
+* this translation from object to ``context->handles_vma``.
*/
struct list_head lut_list;
- spinlock_t lut_lock; /* guards lut_list */
+
+ /** @lut_lock: guards @lut_list */
+ spinlock_t lut_lock;
/**
* @obj_link: Link into @i915_gem_ww_ctx.obj_list
@@ -294,42 +303,88 @@ struct drm_i915_gem_object {
*/
struct list_head obj_link;
/**
-* @shared_resv_from: The object shares the resv from this vm.
+* @shares_resv_from: The object shares the resv from this vm.
*/
struct i915_address_space *shares_resv_from;
union {
+ /** @rcu: head used when freeing objects with RCU */
struct rcu_head rcu;
+ /** @freed: list of GEM freed objects */
struct llist_node freed;
};
/**
-* Whether the object is currently in the GGTT mmap.
+* @userfault_count: a value bigger than zero means that the object
+* was mmapped into userspace.
+*
+* Used when the object is currently in the GGTT mmap.
*/
unsigned int userfault_count;
+ /**
+* @userfault_link: list of all objects that were
+* mmapped into userspace.
+*
+* Used when the object is currently in the GGTT mmap.
+*/
struct list_head userfault_link;
+ /** @mmo: struct containing mmo offsets and lock */
struct {
- spinlock_t lock; /* Protects access to mmo offsets */
+ /** @mmo.lock: protects access to @mmo.offsets */
+ spinlock_t lock;
+ /** @mmo.offsets: rbtree list of mmo offsets */
struct rb_root offsets;
} mmo;
+ /* private: used on selftest only */
I915_SELFTEST_DECLARE(struct list_head st_link);
+ /* public: */
+ /**
+* @flags: object flags. Current flags are:
+*
+* %I915_BO_ALLOC_CONTIGUOUS:
+* Object requires to be allocated as a contiguous block
+* %I915_BO_ALLOC_VOLATILE:
+* Volatile objects are marked as %DONTNEED while pinned, therefore
+* once unpinned the backing store can be discarded.
+* This is limited to kernel internal objects.
+* %I915_BO_ALLOC_CPU_CLEAR:
+* Some internal device local-memory objects may have an option
+* to CPU clear the pages upon gathering the backing store.
+* Note that this might be before the blitter is usable, which
+* is the case for some internal GuC objects.
+* %I915_BO_ALLOC_USER:
+* Make sure the object is cleared before any user access.
+* %I915_BO_ALLOC_PM_VOLATILE:
+* Object is allowed to lose its contents on suspend / resume,
+* even if pinned
+* %I915_BO_ALLOC_PM_EARLY:
+* Object needs to be restored early using memcpy during resume
+* %I915_BO_ALL
[Intel-gfx] [PATCH v3 25/37] drm/i915: i915_deps: use a shorter title markup
The DOC: tag waits for a one-line short title for the doc section. Using multiple lines will produce a weird output. So, add a shorter description for the title, while keeping the current content below it. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/i915_deps.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_deps.c b/drivers/gpu/drm/i915/i915_deps.c index 297b8e4e42ee..df6af832e3f2 100644 --- a/drivers/gpu/drm/i915/i915_deps.c +++ b/drivers/gpu/drm/i915/i915_deps.c @@ -11,7 +11,9 @@ #include "i915_deps.h" /** - * DOC: Set of utilities to dynamically collect dependencies into a + * DOC: Utilities to collect dependencies for GT migration code + * + * Set of utilities to dynamically collect dependencies into a * structure which is fed into the GT migration code. * * Once we can do async unbinding, this is also needed to coalesce -- 2.37.3
[Intel-gfx] [PATCH v3 02/37] drm/i915: display: fix kernel-doc markup warnings
There are a couple of issues at i915 display kernel-doc markups: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2238: warning: Function parameter or member 'intel_connector' not described in 'intel_connector_debugfs_add' drivers/gpu/drm/i915/display/intel_display_debugfs.c:2238: warning: Excess function parameter 'connector' description in 'intel_connector_debugfs_add' drivers/gpu/drm/i915/display/intel_display_power.c:700: warning: expecting prototype for intel_display_power_put_async(). Prototype was for __intel_display_power_put_async() instead drivers/gpu/drm/i915/display/intel_tc.c:807: warning: Function parameter or member 'work' not described in 'intel_tc_port_disconnect_phy_work' drivers/gpu/drm/i915/display/intel_tc.c:807: warning: Excess function parameter 'dig_port' description in 'intel_tc_port_disconnect_phy_work' Those are due to wrong parameter of function name. Address them. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 +- drivers/gpu/drm/i915/display/intel_display_power.c | 2 +- drivers/gpu/drm/i915/display/intel_tc.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c b/drivers/gpu/drm/i915/display/intel_display_debugfs.c index 5dc364e9db49..e8433aa50905 100644 --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c @@ -2232,7 +2232,7 @@ DEFINE_SHOW_ATTRIBUTE(i915_current_bpc); /** * intel_connector_debugfs_add - add i915 specific connector debugfs files - * @connector: pointer to a registered drm_connector + * @intel_connector: pointer to a registered drm_connector * * Cleanup will be done by drm_connector_unregister() through a call to * drm_debugfs_connector_remove(). diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c b/drivers/gpu/drm/i915/display/intel_display_power.c index 1af1705d730d..b080d65d4461 100644 --- a/drivers/gpu/drm/i915/display/intel_display_power.c +++ b/drivers/gpu/drm/i915/display/intel_display_power.c @@ -686,7 +686,7 @@ intel_display_power_put_async_work(struct work_struct *work) } /** - * intel_display_power_put_async - release a power domain reference asynchronously + * __intel_display_power_put_async - release a power domain reference asynchronously * @i915: i915 device instance * @domain: power domain to reference * @wakeref: wakeref acquired for the reference that is being released diff --git a/drivers/gpu/drm/i915/display/intel_tc.c b/drivers/gpu/drm/i915/display/intel_tc.c index e5af955b5600..10cda362537e 100644 --- a/drivers/gpu/drm/i915/display/intel_tc.c +++ b/drivers/gpu/drm/i915/display/intel_tc.c @@ -797,7 +797,7 @@ void intel_tc_port_lock(struct intel_digital_port *dig_port) /** * intel_tc_port_disconnect_phy_work: disconnect TypeC PHY from display port - * @dig_port: digital port + * @work: workqueue struct * * Disconnect the given digital port from its TypeC PHY (handing back the * control of the PHY to the TypeC subsystem). This will happen in a delayed -- 2.37.3
[Intel-gfx] [PATCH v3 23/37] drm/i915: i915_gem.c fix a kernel-doc issue
Prevent this Sphinx warning: Documentation/foo/i915:728: ./drivers/gpu/drm/i915/i915_gem.c:447: WARNING: Inline emphasis start-string without end-string. By using @data to identify the data field, as expected by kernel-doc. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/i915_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index f68fa0732363..2b5b2be91a24 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -444,7 +444,7 @@ i915_gem_gtt_pread(struct drm_i915_gem_object *obj, * @data: ioctl data blob * @file: drm file pointer * - * On error, the contents of *data are undefined. + * On error, the contents of @data is undefined. */ int i915_gem_pread_ioctl(struct drm_device *dev, void *data, -- 2.37.3
[Intel-gfx] [PATCH v3 15/37] drm/i915: intel_pm.c: fix some ascii artwork at kernel-doc
Preserving ascii artwork on kernel-docs is tricky, as it needs
to respect both the Sphinx rules and be properly parsed by
kernel-doc script.
The Sphinx syntax require code-blocks, which is:
::
followed by a blank line and indented lines.
But kernel-doc only works fine if the first and the last line
are indented with the same amount of spaces.
Also, a "\" at the end means that the next line should be merged
with the first one.
Change the ascii artwork to be on code-blocks, starting all
lines at the same characters and not ending with a backslash.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/intel_pm.c | 33 ++---
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index eb9c54bbf51f..1f5e520a6728 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -683,18 +683,20 @@ static const struct intel_watermark_params i845_wm_info =
{
* FIFO is relatively small compared to the amount of data
* fetched.
*
- * The FIFO level vs. time graph might look something like:
+ * The FIFO level vs. time graph might look something like::
*
- * |\ |\
- * | \ | \
- * __---__---__ (- plane active, _ blanking)
- * -> time
+ * ^
+ * | |\ |\ ( )
+ * | | \ | \ ( )
+ * | __---__---__ (- plane active, _ blanking)
+ * +---> time
*
- * or perhaps like this:
+ * or perhaps like this::
*
- * |\|\ |\|\
- * ______ (- plane active, _ blanking)
- * -> time
+ * ^
+ * | |\|\ |\|\ ( )
+ * | ______ (- plane active, _ blanking)
+ * +---> time
*
* Returns:
* The watermark in bytes
@@ -730,13 +732,14 @@ static unsigned int intel_wm_method1(unsigned int
pixel_rate,
* FIFO is relatively large compared to the amount of data
* fetched.
*
- * The FIFO level vs. time graph might look something like:
+ * The FIFO level vs. time graph might look something like::
*
- *|\___ |\___
- *|\___ |\___
- *|\ |\
- * __ --__--__--__--__--__--__ (- plane active, _ blanking)
- * -> time
+ * ^
+ * | |\___ |\___( )
+ * | |\___ |\___( )
+ * | |\ |\ ( )
+ * | __ --__--__--__--__--__--__ (- plane active, _ blanking)
+ * +-> time
*
* Returns:
* The watermark in bytes
--
2.37.3
[Intel-gfx] [PATCH v3 33/37] drm/i915 i915_gem_object_types.h: document struct i915_lut_handle
commit d1b48c1e7184 ("drm/i915: Replace execbuf vma ht with an idr")
added a rbtree list to allow searching for obj/ctx.
Document it.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 9f6b14ec189a..35746cf268ea 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -21,9 +21,15 @@ struct drm_i915_gem_object;
struct intel_fronbuffer;
struct intel_memory_region;
-/*
- * struct i915_lut_handle tracks the fast lookups from handle to vma used
- * for execbuf. Although we use a radixtree for that mapping, in order to
+/**
+ * struct i915_lut_handle - tracks the fast lookups from handle to vma used
+ * for execbuf.
+ *
+ * @obj_link: link to the object associated with the @handle.
+ * @ctx: context associated with the @handle.
+ * @handle: a rbtree handle to lookup context for specific obj/vma.
+ *
+ * Although we use a radixtree for that mapping, in order to
* remove them as the object or context is closed, we need a secondary list
* and a translation entry (i915_lut_handle).
*/
--
2.37.3
[Intel-gfx] [PATCH v3 22/37] drm/i915: i915_vma_resource.c: fix some kernel-doc markups
Building docs currently produces two warnings: Documentation/foo/i915:71: ./drivers/gpu/drm/i915/i915_vma_resource.c:286: WARNING: Inline strong start-string without end-string. Documentation/foo/i915:71: ./drivers/gpu/drm/i915/i915_vma_resource.c:370: WARNING: Inline strong start-string without end-string. That's because @foo evaluates into **foo**, and placing anything after it without spaces cause Sphinx to warn and do the wrong thing.. So, replace them by a different Sphinx-compatible tag. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/i915_vma_resource.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_vma_resource.c b/drivers/gpu/drm/i915/i915_vma_resource.c index de1342dbfa12..e758e0530175 100644 --- a/drivers/gpu/drm/i915/i915_vma_resource.c +++ b/drivers/gpu/drm/i915/i915_vma_resource.c @@ -290,7 +290,7 @@ i915_vma_resource_color_adjust_range(struct i915_address_space *vm, * * The function needs to be called with the vm lock held. * - * Return: Zero on success, -ERESTARTSYS if interrupted and @intr==true + * Return: Zero on success, -ERESTARTSYS if interrupted and ``intr==true`` */ int i915_vma_resource_bind_dep_sync(struct i915_address_space *vm, u64 offset, @@ -374,7 +374,7 @@ void i915_vma_resource_bind_dep_sync_all(struct i915_address_space *vm) * this means that during heavy memory pressure, we will sync in this * function. * - * Return: Zero on success, -ERESTARTSYS if interrupted and @intr==true + * Return: Zero on success, -ERESTARTSYS if interrupted and ``intr==true`` */ int i915_vma_resource_bind_dep_await(struct i915_address_space *vm, struct i915_sw_fence *sw_fence, -- 2.37.3
[Intel-gfx] [PATCH v3 14/37] drm/i915: skl_scaler: fix return value kernel-doc markup
The way it is, it produces this warning: Documentation/gpu/i915:150: ./drivers/gpu/drm/i915/display/skl_scaler.c:213: WARNING: Block quote ends without a blank line; unexpected unindent. Use list markups to suppress the warning. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/display/skl_scaler.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c b/drivers/gpu/drm/i915/display/skl_scaler.c index 4092679be21e..59099f793d3e 100644 --- a/drivers/gpu/drm/i915/display/skl_scaler.c +++ b/drivers/gpu/drm/i915/display/skl_scaler.c @@ -208,9 +208,9 @@ int skl_update_scaler_crtc(struct intel_crtc_state *crtc_state) * @crtc_state: crtc's scaler state * @plane_state: atomic plane state to update * - * Return - * 0 - scaler_usage updated successfully - *error - requested scaling cannot be supported or other error condition + * Return: + * * 0 - scaler_usage updated successfully + * * error - requested scaling cannot be supported or other error condition */ int skl_update_scaler_plane(struct intel_crtc_state *crtc_state, struct intel_plane_state *plane_state) -- 2.37.3
[Intel-gfx] [PATCH v3 11/37] drm/i915: document kernel-doc trivial issues
Fix those kernel-doc warnings:
drivers/gpu/drm/i915/intel_region_ttm.c:199: warning: Function
parameter or member 'offset' not described in 'intel_region_ttm_resource_alloc'
drivers/gpu/drm/i915/i915_vma_resource.h:123: warning: Function
parameter or member 'wakeref' not described in 'i915_vma_resource'
drivers/gpu/drm/i915/i915_vma.c:1703: warning: Function parameter or
member 'vma' not described in 'i915_vma_destroy_locked'
drivers/gpu/drm/i915/i915_vma.c:751: warning: Function parameter or
member 'ww' not described in 'i915_vma_insert'
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:159: warning: Function
parameter or member 'gt' not described in 'intel_gt_fini_hwconfig'
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:146: warning: Function
parameter or member 'gt' not described in 'intel_gt_init_hwconfig'
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:113: warning: expecting
prototype for intel_guc_hwconfig_init(). Prototype was for guc_hwconfig_init()
instead
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:113: warning: Function
parameter or member 'gt' not described in 'guc_hwconfig_init'
drivers/gpu/drm/i915/gt/intel_engine_types.h:276: warning: Function
parameter or member 'preempt_hang' not described in 'intel_engine_execlists'
That are due undocumented parameters.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/gt/intel_engine_types.h| 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 5 -
drivers/gpu/drm/i915/i915_vma.c | 2 ++
drivers/gpu/drm/i915/i915_vma_resource.h| 1 +
drivers/gpu/drm/i915/intel_region_ttm.c | 3 ++-
5 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 633a7e5dba3b..7c5ad9071fe7 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -271,6 +271,7 @@ struct intel_engine_execlists {
*/
u8 csb_head;
+ /* private: Used only in selftests */
I915_SELFTEST_DECLARE(struct st_preempt_hang preempt_hang;)
};
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
index 4781fccc2687..76f7447302a6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
@@ -103,7 +103,8 @@ static bool has_table(struct drm_i915_private *i915)
}
/**
- * intel_guc_hwconfig_init - Initialize the HWConfig
+ * guc_hwconfig_init - Initialize the HWConfig
+ * @gt: GT structure
*
* Retrieve the HWConfig table from the GuC and save it locally.
* It can then be queried on demand by other users later on.
@@ -138,6 +139,7 @@ static int guc_hwconfig_init(struct intel_gt *gt)
/**
* intel_gt_init_hwconfig - Initialize the HWConfig if available
+ * @gt: GT structure
*
* Retrieve the HWConfig table if available on the current platform.
*/
@@ -151,6 +153,7 @@ int intel_gt_init_hwconfig(struct intel_gt *gt)
/**
* intel_gt_fini_hwconfig - Finalize the HWConfig
+ * @gt: GT structure
*
* Free up the memory allocation holding the table.
*/
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index f17c09ead7d7..946f26138381 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -731,6 +731,7 @@ bool i915_gem_valid_gtt_space(struct i915_vma *vma,
unsigned long color)
/**
* i915_vma_insert - finds a slot for the vma in its address space
* @vma: the vma
+ * @ww: An optional struct i915_gem_ww_ctx
* @size: requested size in bytes (can be larger than the VMA)
* @alignment: required alignment
* @flags: mask of PIN_* flags to use
@@ -1686,6 +1687,7 @@ static void release_references(struct i915_vma *vma,
struct intel_gt *gt,
/**
* i915_vma_destroy_locked - Remove all weak reference to the vma and put
* the initial reference.
+ * @vma: VMA to destroy
*
* This function should be called when it's decided the vma isn't needed
* anymore. The caller must assure that it doesn't race with another lookup
diff --git a/drivers/gpu/drm/i915/i915_vma_resource.h
b/drivers/gpu/drm/i915/i915_vma_resource.h
index e155f6f7af6f..02dd8bb89c0a 100644
--- a/drivers/gpu/drm/i915/i915_vma_resource.h
+++ b/drivers/gpu/drm/i915/i915_vma_resource.h
@@ -49,6 +49,7 @@ struct i915_page_sizes {
* @__subtree_last: Interval tree private member.
* @vm: non-refcounted pointer to the vm. This is for internal use only and
* this member is cleared after vm_resource unbind.
+ * @wakeref: wakeref used for runtime PM reference.
* @mr: The memory region of the object pointed to by the vma.
[Intel-gfx] [PATCH v3 32/37] docs: gpu: i915.rst: add the remaining kernel-doc markup files
There are other files with kernel-doc markups: $ git grep -l "/\*\*" $(git ls-files|grep drivers/gpu/drm/i915/) >kernel-doc-files $ for i in $(cat kernel-doc-files); do if [ "$(git grep $i Documentation/)" == "" ]; then echo "$i"; fi; done >aaa Add them to i915.rst as well. Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ Documentation/gpu/i915.rst | 85 +- 1 file changed, 83 insertions(+), 2 deletions(-) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 545fe630557a..7f5cd01ed398 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -13,6 +13,11 @@ Core Driver Infrastructure This section covers core driver infrastructure used by both the display and the GEM parts of the driver. +Core driver +--- + +.. kernel-doc:: drivers/gpu/drm/i915/i915_driver.c + Runtime Power Management @@ -29,6 +34,8 @@ Runtime Power Management .. kernel-doc:: drivers/gpu/drm/i915/intel_pm.c +.. kernel-doc:: drivers/gpu/drm/i915/intel_wakeref.h + Interrupt Handling -- @@ -44,8 +51,25 @@ Interrupt Handling .. kernel-doc:: drivers/gpu/drm/i915/i915_irq.c :functions: intel_runtime_pm_enable_interrupts -Intel GVT-g Guest Support(vGPU) +Memory Handling +--- + +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma_resource.h + +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma_resource.c + +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma.h + +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma.c + +.. kernel-doc:: drivers/gpu/drm/i915/i915_mm.c + +.. kernel-doc:: drivers/gpu/drm/i915/intel_memory_region.c + +.. kernel-doc:: drivers/gpu/drm/i915/i915_memcpy.c + +Intel GVT-g Guest Support (vGPU) + .. kernel-doc:: drivers/gpu/drm/i915/i915_vgpu.c :doc: Intel GVT-g guest support @@ -109,6 +133,55 @@ Workarounds .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_workarounds.c :doc: Hardware workarounds +Scatterlist handling + + +.. kernel-doc:: drivers/gpu/drm/i915/i915_scatterlist.h + +.. kernel-doc:: drivers/gpu/drm/i915/i915_scatterlist.c + +i915 request + + +.. kernel-doc:: drivers/gpu/drm/i915/i915_request.h + +.. kernel-doc:: drivers/gpu/drm/i915/i915_request.c + +Others +-- + +.. kernel-doc:: drivers/gpu/drm/i915/i915_ioc32.c + +.. kernel-doc:: drivers/gpu/drm/i915/i915_gpu_error.c + +.. kernel-doc:: drivers/gpu/drm/i915/i915_active.h + +.. kernel-doc:: drivers/gpu/drm/i915/i915_deps.c + +.. kernel-doc:: drivers/gpu/drm/i915/i915_deps.h + +.. kernel-doc:: drivers/gpu/drm/i915/intel_device_info.c + +.. kernel-doc:: drivers/gpu/drm/i915/i915_params.c + +.. kernel-doc:: drivers/gpu/drm/i915/i915_sw_fence_work.h + +.. kernel-doc:: drivers/gpu/drm/i915/i915_syncmap.c + +.. kernel-doc:: drivers/gpu/drm/i915/intel_pcode.c + +.. kernel-doc:: drivers/gpu/drm/i915/i915_reg_defs.h + +.. kernel-doc:: drivers/gpu/drm/i915/intel_wopcm.h + + +Protected Xe Path (PXP) +--- + +.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_irq.c + +.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_tee.c + Display Hardware Handling = @@ -615,6 +688,12 @@ Protected Objects Table Manager (TTM) --- +.. kernel-doc:: drivers/gpu/drm/i915/i915_ttm_buddy_manager.h + +.. kernel-doc:: drivers/gpu/drm/i915/i915_ttm_buddy_manager.c + +.. kernel-doc:: drivers/gpu/drm/i915/intel_region_ttm.c + .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm.c .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm.h @@ -624,6 +703,8 @@ Table Manager (TTM) Graphics Execution Manager (GEM) +.. kernel-doc:: drivers/gpu/drm/i915/i915_gem.c + .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_create.c .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_domain.c -- 2.37.3
[Intel-gfx] [PATCH v3 03/37] drm/i915: gt: fix some Kernel-doc issues
There are several trivial warnings there, due to trivial things: - lack of function name at the kerneldoc markup; - undocumented structs with kernel-doc markups; - wrong parameter syntax. Fix such warnings: drivers/gpu/drm/i915/gt/intel_context.h:107: warning: Function parameter or member 'ce' not described in 'intel_context_lock_pinned' drivers/gpu/drm/i915/gt/intel_context.h:122: warning: Function parameter or member 'ce' not described in 'intel_context_is_pinned' drivers/gpu/drm/i915/gt/intel_context.h:141: warning: Function parameter or member 'ce' not described in 'intel_context_unlock_pinned' drivers/gpu/drm/i915/gt/intel_gtt.h:510: warning: Function parameter or member 'vm' not described in 'i915_vm_resv_put' drivers/gpu/drm/i915/gt/intel_gtt.h:510: warning: Excess function parameter 'resv' description in 'i915_vm_resv_put' drivers/gpu/drm/i915/gt/intel_gtt.h:615: warning: Function parameter or member 'i915' not described in 'i915_ggtt_mark_pte_lost' drivers/gpu/drm/i915/gt/intel_gtt.h:615: warning: Function parameter or member 'val' not described in 'i915_ggtt_mark_pte_lost' drivers/gpu/drm/i915/gt/intel_rps.c:2343: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Tells the intel_ips driver that the i915 driver is now loaded, if drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:28: warning: Function parameter or member 'size' not described in '__guc_capture_bufstate' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:28: warning: Function parameter or member 'data' not described in '__guc_capture_bufstate' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:28: warning: Function parameter or member 'rd' not described in '__guc_capture_bufstate' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:28: warning: Function parameter or member 'wr' not described in '__guc_capture_bufstate' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:60: warning: Function parameter or member 'link' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:60: warning: Function parameter or member 'is_partial' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:60: warning: Function parameter or member 'eng_class' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:60: warning: Function parameter or member 'eng_inst' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:60: warning: Function parameter or member 'guc_id' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:60: warning: Function parameter or member 'lrca' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:60: warning: Function parameter or member 'reginfo' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:63: warning: wrong kernel-doc identifier on line: * struct guc_debug_capture_list_header / struct guc_debug_capture_list drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:81: warning: wrong kernel-doc identifier on line: * struct __guc_mmio_reg_descr / struct __guc_mmio_reg_descr_group drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:106: warning: wrong kernel-doc identifier on line: * struct guc_state_capture_header_t / struct guc_state_capture_t / drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:164: warning: Function parameter or member 'is_valid' not described in '__guc_capture_ads_cache' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:164: warning: Function parameter or member 'ptr' not described in '__guc_capture_ads_cache' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:164: warning: Function parameter or member 'size' not described in '__guc_capture_ads_cache' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:164: warning: Function parameter or member 'status' not described in '__guc_capture_ads_cache' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:217: warning: Function parameter or member 'ads_null_cache' not described in 'intel_guc_state_capture' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:217: warning: Function parameter or member 'max_mmio_per_node' not described in 'intel_guc_state_capture' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:401: warning: Function parameter or member 'marker' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:401: warning: Function parameter or member 'read_ptr' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:401: warning: Function parameter or member 'write_ptr' not described in 'guc_log_buffer_state
[Intel-gfx] [PATCH v3 05/37] drm/i915: gem: fix some Kernel-doc issues
There are several trivial issueson kernel-doc markups at gem:
drivers/gpu/drm/i915/gem/i915_gem_create.c:146: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/gem/i915_gem_create.c:217: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/gem/i915_gem_create.c:401: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/gem/i915_gem_domain.c:116: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/gem/i915_gem_domain.c:177: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/gem/i915_gem_domain.c:262: warning: expecting
prototype for Changes the cache(). Prototype was for
i915_gem_object_set_cache_level() instead
drivers/gpu/drm/i915/gem/i915_gem_domain.c:456: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/gem/i915_gem_domain.c:500: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/gem/i915_gem_object.h:110: warning: Function
parameter or member 'file' not described in 'i915_gem_object_lookup_rcu'
drivers/gpu/drm/i915/gem/i915_gem_object.h:110: warning: Excess
function parameter 'filp' description in 'i915_gem_object_lookup_rcu'
drivers/gpu/drm/i915/gem/i915_gem_region.h:35: warning: Function
parameter or member 'process_obj' not described in
'i915_gem_apply_to_region_ops'
drivers/gpu/drm/i915/gem/i915_gem_wait.c:130: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
Caused by:
- lack of function name at the kernel-doc markup;
- renamed parameters.
Address them.
Reviewed-by: Nirmoy Das
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/gem/i915_gem_create.c | 8 +---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 17 +++--
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 2 +-
4 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 33673fe7ee0a..8cb2eb092031 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -143,7 +143,8 @@ __i915_gem_object_create_user_ext(struct drm_i915_private
*i915, u64 size,
}
/**
- * Creates a new object using the same path as DRM_I915_GEM_CREATE_EXT
+ * __i915_gem_object_create_user - Creates a new object using the same path
+ * as DRM_I915_GEM_CREATE_EXT
* @i915: i915 private
* @size: size of the buffer, in bytes
* @placements: possible placement regions, in priority order
@@ -214,7 +215,7 @@ i915_gem_dumb_create(struct drm_file *file,
}
/**
- * Creates a new mm object and returns a handle to it.
+ * i915_gem_create_ioctl - Creates a new mm object and returns a handle to it.
* @dev: drm device pointer
* @data: ioctl data blob
* @file: drm file pointer
@@ -398,7 +399,8 @@ static const i915_user_extension_fn create_extensions[] = {
};
/**
- * Creates a new mm object and returns a handle to it.
+ * i915_gem_create_ext_ioctl - Creates a new mm object and returns a handle
+ * to it.
* @dev: drm device pointer
* @data: ioctl data blob
* @file: drm file pointer
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index d44a152ce680..fd4f10765208 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -113,7 +113,8 @@ void i915_gem_object_flush_if_display_locked(struct
drm_i915_gem_object *obj)
}
/**
- * Moves a single object to the WC read, and possibly write domain.
+ * i915_gem_object_set_to_wc_domain - Moves a single object to the WC read,
+ * and possibly write domain.
* @obj: object to act on
* @write: ask for write access or read only
*
@@ -174,7 +175,8 @@ i915_gem_object_set_to_wc_domain(struct drm_i915_gem_object
*obj, bool write)
}
/**
- * Moves a single object to the GTT read, and possibly write domain.
+ * i915_gem_object_set_to_gtt_domain - Moves a single object to the GTT read,
+ * and possibly write domain.
* @obj: object to act on
* @write: ask for write access or read only
*
@@ -
[Intel-gfx] [PATCH v3 16/37] drm/i915: i915_gem_region.h: fix i915_gem_apply_to_region_ops doc
The kernel-doc markup for i915_gem_apply_to_region_ops() has some
issues:
1. The field should be marked as @process_obj;
2. The callback parameters aren't document properly, as sphinx
will consider them to be placed at the wrong place.
Fix (1) and change the way the parameters are described, using
a list, in order for it to be properly parsed during documentation
build time.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/gem/i915_gem_region.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.h
b/drivers/gpu/drm/i915/gem/i915_gem_region.h
index 2dfcc41c0170..b0134bf4b1b7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.h
@@ -22,9 +22,11 @@ struct i915_gem_apply_to_region;
*/
struct i915_gem_apply_to_region_ops {
/**
-* process_obj - Process the current object
-* @apply: Embed this for private data.
-* @obj: The current object.
+* @process_obj: Callback function to process the current object
+* it requires two arguments:
+*
+* - @apply: Embed this for private data.
+* - @obj: The current object.
*
* Note that if this function is part of a ww transaction, and
* if returns -EDEADLK for one of the objects, it may be
--
2.37.3
[Intel-gfx] [PATCH v3 31/37] docs: gpu: i915.rst: GEM/TTM: add more kernel-doc markups
There are several documented GEM/TTM kAPI that aren't currently part of the docs. Add them, as this allows identifying issues with badly-formatted tags. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ Documentation/gpu/i915.rst | 38 ++ 1 file changed, 38 insertions(+) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 4ce04a457ccc..545fe630557a 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -612,6 +612,44 @@ Protected Objects .. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_types.h +Table Manager (TTM) +--- + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm.h + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c + +Graphics Execution Manager (GEM) + + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_create.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_domain.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_internal.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_lmem.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_mman.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_object.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_object.h + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_object_types.h + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_region.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_region.h + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_userptr.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_wait.c + Microcontrollers -- 2.37.3
[Intel-gfx] [PATCH v3 10/37] drm/i915: i915_gpu_error.c: document dump_flags
Kernel-doc dump_flags parameter is missing at i915_capture_error_state().
Document it.
Fixes: a6f0f9cf330a ("drm/i915/guc: Plumb GuC-capture into gpu_coredump")
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/i915_gpu_error.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9ea2fe34e7d3..c2350284f221 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -2148,7 +2148,8 @@ void i915_error_state_store(struct i915_gpu_coredump
*error)
* i915_capture_error_state - capture an error record for later analysis
* @gt: intel_gt which originated the hang
* @engine_mask: hung engines
- *
+ * @dump_flags: bitmap flags. When %CORE_DUMP_FLAG_IS_GUC_CAPTURE is used,
+ * dump engine record registers and execlists.
*
* Should be called when an error is detected (either a hang or an error
* interrupt) to capture error state from the time of the error. Fills
--
2.37.3
[Intel-gfx] [PATCH v3 37/37] drm/i915: be consistent with kernel-doc function declaration
Currently, 91% of kernel-doc function declarations don't have
parenthesis on it. Let's be consistent inside the driver by
removing the parenthesis from the other ones.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/display/intel_atomic.c| 2 +-
drivers/gpu/drm/i915/display/intel_audio.c | 4 ++--
drivers/gpu/drm/i915/display/intel_crtc.c | 4 ++--
drivers/gpu/drm/i915/display/intel_dmc.c | 10 +-
drivers/gpu/drm/i915/display/intel_dsb.c | 10 +-
drivers/gpu/drm/i915/display/intel_lpe_audio.c | 8
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 10 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 10 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 4 ++--
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c| 8
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 4 ++--
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +-
drivers/gpu/drm/i915/i915_cmd_parser.c | 8
drivers/gpu/drm/i915/i915_reg_defs.h | 12 ++--
drivers/gpu/drm/i915/intel_wopcm.c | 4 ++--
18 files changed, 53 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 18f0a5ae3bac..9b604a720ff0 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -373,7 +373,7 @@ static void intel_atomic_setup_scaler(struct
intel_crtc_scaler_state *scaler_sta
}
/**
- * intel_atomic_setup_scalers() - setup scalers for crtc per staged requests
+ * intel_atomic_setup_scalers - setup scalers for crtc per staged requests
* @dev_priv: i915 device
* @intel_crtc: intel crtc
* @crtc_state: incoming crtc_state to validate and setup scalers
diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
b/drivers/gpu/drm/i915/display/intel_audio.c
index aacbc6da84ef..667fe9a8ff8e 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -1385,7 +1385,7 @@ static void i915_audio_component_cleanup(struct
drm_i915_private *dev_priv)
}
/**
- * intel_audio_init() - Initialize the audio driver either using
+ * intel_audio_init - Initialize the audio driver either using
* component framework or using lpe audio bridge
* @dev_priv: the i915 drm device private data
*
@@ -1397,7 +1397,7 @@ void intel_audio_init(struct drm_i915_private *dev_priv)
}
/**
- * intel_audio_deinit() - deinitialize the audio driver
+ * intel_audio_deinit - deinitialize the audio driver
* @dev_priv: the i915 drm device private data
*
*/
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
b/drivers/gpu/drm/i915/display/intel_crtc.c
index 6792a9056f46..507d7aec7b1c 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -463,7 +463,7 @@ static int intel_mode_vblank_start(const struct
drm_display_mode *mode)
}
/**
- * intel_pipe_update_start() - start update of a set of display registers
+ * intel_pipe_update_start - start update of a set of display registers
* @new_crtc_state: the new crtc state
*
* Mark the start of an update to pipe registers that should be updated
@@ -617,7 +617,7 @@ static void dbg_vblank_evade(struct intel_crtc *crtc,
ktime_t end) {}
#endif
/**
- * intel_pipe_update_end() - end update of a set of display registers
+ * intel_pipe_update_end - end update of a set of display registers
* @new_crtc_state: the new crtc state
*
* Mark the end of an update started with intel_pipe_update_start(). This
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index e52ecc0738a6..2024884688f6 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -408,7 +408,7 @@ static void pipedmc_clock_gating_wa(struct drm_i915_private
*i915, bool enable)
}
/**
- * intel_dmc_load_program() - write the firmware from memory to register.
+ * intel_dmc_load_program - write the firmware from memory to register.
* @dev_priv: i915 drm device.
*
* DMC firmware is read from a .bin file and kept in internal memory one time.
@@ -876,7 +876,7 @@ static void dmc_load_work_fn(struct work_struct *work)
}
/**
- * intel_dmc_ucode_init() - initialize the firmware loading.
+ * intel_dmc_ucode_init - initialize the firmware loading.
* @dev_priv: i915 drm device.
*
* This function is called at the time of loading the display driver to read
@@ -973,7 +973,7 @@ void intel_dmc_ucode_init(struct drm_i915_private *dev_priv)
}
/**
- * int
[Intel-gfx] [PATCH v3 35/37] drm/i915: add descriptions for some RPM macros at intel_gt_pm.h
The intel_gt_pm.h file contains some convenient macros to be used
in GT code in order to get/put runtime PM references and for
checking them.
Add descriptions based on the ones at intel_wakeref.h and
intel_runtime_pm.c.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
Documentation/gpu/i915.rst| 2 ++
drivers/gpu/drm/i915/gt/intel_gt_pm.h | 51 +++
2 files changed, 53 insertions(+)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 7f5cd01ed398..59c532fe0332 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -446,6 +446,8 @@ Graphics Translation Tables
Other GT functionality
--
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_pm.h
+
.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_context.h
.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gsc.h
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index 6c9a46452364..7847e15d102e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -11,21 +11,57 @@
#include "intel_gt_types.h"
#include "intel_wakeref.h"
+/**
+ * intel_gt_pm_is_awake: Query whether the runtime PM is awake held
+ *
+ * @gt: pointer to the graphics engine
+ *
+ * Returns: true if a runtime pm reference is currently held and the GT is
+ * awake.
+ */
static inline bool intel_gt_pm_is_awake(const struct intel_gt *gt)
{
return intel_wakeref_is_active(>->wakeref);
}
+/**
+ * intel_gt_pm_get: grab a runtime PM reference ensuring that GT is powered up
+ * @gt: pointer to the graphics engine
+ *
+ * Any runtime pm reference obtained by this function must have a symmetric
+ * call to intel_gt_pm_put() to release the reference again.
+ *
+ * Note that this is allowed to fail, in which case the runtime-pm wakeref
+ * will be released and the acquisition unwound.
+ */
static inline void intel_gt_pm_get(struct intel_gt *gt)
{
intel_wakeref_get(>->wakeref);
}
+/**
+ * __intel_gt_pm_get: Acquire the runtime PM reference again
+ * @gt: pointer to the graphics engine which contains the wakeref
+ *
+ * Increment the PM reference counter, only valid if it is already held by
+ * the caller.
+ *
+ * See intel_gt_pm_get().
+ */
static inline void __intel_gt_pm_get(struct intel_gt *gt)
{
__intel_wakeref_get(>->wakeref);
}
+/**
+ * intel_gt_pm_get_if_awake: Acquire the runtime PM reference if active
+ * @gt: pointer to the graphics engine which contains the PM reference
+ *
+ * Acquire a hold on the PM reference, but only if the GT is already
+ * active.
+ *
+ * Returns: true if the wakeref was acquired, false otherwise.
+ */
static inline bool intel_gt_pm_get_if_awake(struct intel_gt *gt)
{
return intel_wakeref_get_if_active(>->wakeref);
@@ -36,6 +72,14 @@ static inline void intel_gt_pm_might_get(struct intel_gt *gt)
intel_wakeref_might_get(>->wakeref);
}
+/**
+ * intel_gt_pm_put: Release the runtime PM reference
+ * @gt: pointer to the graphics engine which contains the PM reference
+ *
+ * Release our hold on the runtime PM for GT.
+ *
+ * It might power down the GT right away if this is the last reference.
+ */
static inline void intel_gt_pm_put(struct intel_gt *gt)
{
intel_wakeref_put(>->wakeref);
@@ -51,6 +95,13 @@ static inline void intel_gt_pm_might_put(struct intel_gt *gt)
intel_wakeref_might_put(>->wakeref);
}
+/**
+ * with_intel_gt_pm - get a GT reference ensuring that GT is powered up,
+ * run some code and then put the reference away.
+ *
+ * @gt: pointer to the gt
+ * @tmp: pointer to a temporary wakeref.
+ */
#define with_intel_gt_pm(gt, tmp) \
for (tmp = 1, intel_gt_pm_get(gt); tmp; \
intel_gt_pm_put(gt), tmp = 0)
--
2.37.3
[Intel-gfx] [PATCH v3 09/37] drm/i915: gem: add kernel-doc description for some function parameters
There are some parameters missing at the kernel-doc markups on some gem files. Some of those are trivial enough to be added. Document them. Reviewed-by: Nirmoy Das Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 ++ drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 1 + drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 ++ 3 files changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c index 85482a04d158..35637e2f51f3 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c @@ -815,6 +815,8 @@ int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj, * in an unknown_state. This means that userspace must NEVER be allowed to touch * the pages, with either the GPU or CPU. * + * @obj: The object to check its state. + * * ONLY valid to be called after ensuring that all kernel fences have signalled * (in particular the fence for moving/clearing the object). */ diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.h b/drivers/gpu/drm/i915/gem/i915_gem_ttm.h index e4842b4296fc..64151f40098f 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.h +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.h @@ -30,6 +30,7 @@ void i915_ttm_bo_destroy(struct ttm_buffer_object *bo); /** * i915_ttm_to_gem - Convert a struct ttm_buffer_object to an embedding * struct drm_i915_gem_object. + * @bo: The ttm buffer object. * * Return: Pointer to the embedding struct ttm_buffer_object, or NULL * if the object was not an i915 ttm object. diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c index 9a7e50534b84..56217d324a9b 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c @@ -237,6 +237,7 @@ static struct dma_fence *i915_ttm_accel_move(struct ttm_buffer_object *bo, * @_src_iter: Storage space for the source kmap iterator. * @dst_iter: Pointer to the destination kmap iterator. * @src_iter: Pointer to the source kmap iterator. + * @num_pages: Number of pages to copy or to be cleared. * @clear: Whether to clear instead of copy. * @src_rsgt: Refcounted scatter-gather list of source memory. * @dst_rsgt: Refcounted scatter-gather list of destination memory. @@ -541,6 +542,7 @@ __i915_ttm_move(struct ttm_buffer_object *bo, * i915_ttm_move - The TTM move callback used by i915. * @bo: The buffer object. * @evict: Whether this is an eviction. + * @ctx: Pointer to a struct ttm_operation_ctx * @dst_mem: The destination ttm resource. * @hop: If we need multihop, what temporary memory type to move to. * -- 2.37.3
[Intel-gfx] [PATCH v3 36/37] drm/i915: add GuC functions to the documentation
Currently, functions inside GuC aren't presented as part of the GuC documentation. Add them. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ Documentation/gpu/i915.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 59c532fe0332..b71e9720a1ac 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -759,6 +759,9 @@ GuC .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.h +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.c + :internal: + .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c -- 2.37.3
[Intel-gfx] [PATCH v3 18/37] drm/i915: fix i915_gem_ttm_move.c DOC: markup
The doc markup should not end with ":", as it would generate a warning on Sphinx while generating the cross-reference tag. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c index 56217d324a9b..16dd4991d527 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c @@ -20,7 +20,7 @@ #include "gt/intel_migrate.h" /** - * DOC: Selftest failure modes for failsafe migration: + * DOC: Selftest failure modes for failsafe migration * * For fail_gpu_migration, the gpu blit scheduled is always a clear blit * rather than a copy blit, and then we force the failure paths as if -- 2.37.3
[Intel-gfx] [PATCH v3 28/37] docs: gpu: i915.rst: GuC: add more kernel-doc markups
There are several documented GuC kAPI that aren't currently part of the docs. Add them, as this allows identifying issues with badly-formatted tags. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ Documentation/gpu/i915.rst | 22 ++ 1 file changed, 22 insertions(+) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index b668f36fb0a3..7f2daa1b4a8b 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -593,6 +593,28 @@ GuC .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.h +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_log.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_uc.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c + GuC Firmware Layout ~~~ -- 2.37.3
[Intel-gfx] ✗ Fi.CI.IGT: failure for i915: CAGF and RC6 changes for MTL (rev3)
== Series Details == Series: i915: CAGF and RC6 changes for MTL (rev3) URL : https://patchwork.freedesktop.org/series/108156/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12102_full -> Patchwork_108156v3_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_108156v3_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_108156v3_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (9 -> 11) -- Additional (2): shard-rkl shard-tglu Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_108156v3_full: ### IGT changes ### Possible regressions * igt@i915_pm_rps@waitboost: - shard-tglb: [PASS][1] -> [FAIL][2] +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12102/shard-tglb6/igt@i915_pm_...@waitboost.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v3/shard-tglb1/igt@i915_pm_...@waitboost.html * igt@kms_atomic_transition@plane-all-transition-nonblocking-fencing@pipe-b-vga-1: - shard-snb: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12102/shard-snb2/igt@kms_atomic_transition@plane-all-transition-nonblocking-fenc...@pipe-b-vga-1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v3/shard-snb6/igt@kms_atomic_transition@plane-all-transition-nonblocking-fenc...@pipe-b-vga-1.html Known issues Here are the changes found in Patchwork_108156v3_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][5] -> [TIMEOUT][6] ([i915#3070]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12102/shard-iclb2/igt@gem_...@unwedge-stress.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v3/shard-iclb1/igt@gem_...@unwedge-stress.html - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#5784]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12102/shard-tglb7/igt@gem_...@unwedge-stress.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v3/shard-tglb2/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@parallel-out-fence: - shard-iclb: [PASS][9] -> [SKIP][10] ([i915#4525]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12102/shard-iclb1/igt@gem_exec_balan...@parallel-out-fence.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v3/shard-iclb8/igt@gem_exec_balan...@parallel-out-fence.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][11] ([i915#2846]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v3/shard-apl6/igt@gem_exec_f...@basic-deadline.html - shard-glk: [PASS][12] -> [FAIL][13] ([i915#2846]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12102/shard-glk8/igt@gem_exec_f...@basic-deadline.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v3/shard-glk8/igt@gem_exec_f...@basic-deadline.html * igt@gem_lmem_swapping@heavy-verify-random-ccs: - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v3/shard-apl4/igt@gem_lmem_swapp...@heavy-verify-random-ccs.html * igt@gen9_exec_parse@allowed-all: - shard-glk: [PASS][15] -> [DMESG-WARN][16] ([i915#5566] / [i915#716]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12102/shard-glk7/igt@gen9_exec_pa...@allowed-all.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v3/shard-glk3/igt@gen9_exec_pa...@allowed-all.html * igt@gen9_exec_parse@allowed-single: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#5566] / [i915#716]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12102/shard-apl8/igt@gen9_exec_pa...@allowed-single.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v3/shard-apl2/igt@gen9_exec_pa...@allowed-single.html * igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc: - shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3886]) +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v3/shard-apl4/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html * igt@kms_ccs@pipe-d-bad-pixel-format-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271]) +85 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v3/shard-apl6/igt@kms_ccs@pipe-d-bad-pixel-format-y_tiled_gen12_mc_ccs.html * igt@kms_chamelium@vga-frame-dump: - shard-a
Re: [Intel-gfx] [PATCH v3 01/15] vfio: Add helpers for unifying vfio_device life cycle
Hi, Kevin,
在 2022/9/9 18:22, Kevin Tian 写道:
The idea is to let vfio core manage the vfio_device life cycle instead
of duplicating the logic cross drivers. This is also a preparatory
step for adding struct device into vfio_device.
New pair of helpers together with a kref in vfio_device:
- vfio_alloc_device()
- vfio_put_device()
To be honest, this pair of functions make me confusing to understand their
behaviour from wording point of view:
- vfio_alloc_device(), Okay, it allocates the vfio device, no reference
count thing. but,
- vfio_put_device()
seems it will decrease reference count and then if it is zero, free it.
so they are not of one *pair* about wording.
How about
- vfio_alloc_device() / - vfio_free_device()
or
- vfio_get_device() / - vfio_put_device(), perhaps not match their behviour
in following code.
Thanks,
Ethan
Drivers can register @init/@release callbacks to manage any private
state wrapping the vfio_device.
However vfio-ccw doesn't fit this model due to a life cycle mess
that its private structure mixes both parent and mdev info hence must
be allocated/freed outside of the life cycle of vfio device.
Per prior discussions this won't be fixed in short term by IBM folks.
Instead of waiting for those modifications introduce another helper
vfio_init_device() so ccw can call it to initialize a pre-allocated
vfio_device.
Further implication of the ccw trick is that vfio_device cannot be
freed uniformly in vfio core. Instead, require *EVERY* driver to
implement @release and free vfio_device inside. Then ccw can choose
to delay the free at its own discretion.
Another trick down the road is that kvzalloc() is used to accommodate
the need of gvt which uses vzalloc() while all others use kzalloc().
So drivers should call a helper vfio_free_device() to free the
vfio_device instead of assuming that kfree() or vfree() is appliable.
Later once the ccw mess is fixed we can remove those tricks and
fully handle structure alloc/free in vfio core.
Existing vfio_{un}init_group_dev() will be deprecated after all
existing usages are converted to the new model.
Suggested-by: Jason Gunthorpe
Co-developed-by: Yi Liu
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Tony Krowiak
Reviewed-by: Jason Gunthorpe
Reviewed-by: Eric Auger
---
drivers/vfio/vfio_main.c | 92
include/linux/vfio.h | 25 ++-
2 files changed, 116 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 27d9186f35d5..adc1b697bb78 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -498,6 +498,98 @@ void vfio_uninit_group_dev(struct vfio_device *device)
}
EXPORT_SYMBOL_GPL(vfio_uninit_group_dev);
+/* Release helper called by vfio_put_device() */
+void vfio_device_release(struct kref *kref)
+{
+ struct vfio_device *device =
+ container_of(kref, struct vfio_device, kref);
+
+ vfio_uninit_group_dev(device);
+
+ /*
+* kvfree() cannot be done here due to a life cycle mess in
+* vfio-ccw. Before the ccw part is fixed all drivers are
+* required to support @release and call vfio_free_device()
+* from there.
+*/
+ device->ops->release(device);
+}
+EXPORT_SYMBOL_GPL(vfio_device_release);
+
+/*
+ * Alloc and initialize vfio_device so it can be registered to vfio
+ * core.
+ *
+ * Drivers should use the wrapper vfio_alloc_device() for allocation.
+ * @size is the size of the structure to be allocated, including any
+ * private data used by the driver.
+ *
+ * Driver may provide an @init callback to cover device private data.
+ *
+ * Use vfio_put_device() to release the structure after success return.
+ */
+struct vfio_device *_vfio_alloc_device(size_t size, struct device *dev,
+ const struct vfio_device_ops *ops)
+{
+ struct vfio_device *device;
+ int ret;
+
+ if (WARN_ON(size < sizeof(struct vfio_device)))
+ return ERR_PTR(-EINVAL);
+
+ device = kvzalloc(size, GFP_KERNEL);
+ if (!device)
+ return ERR_PTR(-ENOMEM);
+
+ ret = vfio_init_device(device, dev, ops);
+ if (ret)
+ goto out_free;
+ return device;
+
+out_free:
+ kvfree(device);
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(_vfio_alloc_device);
+
+/*
+ * Initialize a vfio_device so it can be registered to vfio core.
+ *
+ * Only vfio-ccw driver should call this interface.
+ */
+int vfio_init_device(struct vfio_device *device, struct device *dev,
+const struct vfio_device_ops *ops)
+{
+ int ret;
+
+ vfio_init_group_dev(device, dev, ops);
+
+ if (ops->init) {
+ ret = ops->init(device);
+ if (ret)
+ goto out_uninit;
+ }
+
+ kref_init(&device->kref);
+ return 0;
+
+out_uninit:
+ vfio_uninit_group_d
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Split intel_read_wm_latency() into per-platform versions
On Thu, 08 Sep 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> No reaon to have this humongous if ladder in intel_read_wm_latency().
*reason
> Just split it into nicer per-platforms functions.
>
> Also do the s/dev_priv/i915/ while touching all of this code.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 201 +---
> 1 file changed, 110 insertions(+), 91 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 210c1f78cc90..096c311ed29f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2905,97 +2905,107 @@ adjust_wm_latency(struct drm_i915_private *i915,
> wm[0] += 1;
> }
>
> -static void intel_read_wm_latency(struct drm_i915_private *dev_priv,
> - u16 wm[])
> +static void mtl_read_wm_latency(struct drm_i915_private *i915, u16 wm[])
Bikeshed, I'd make that u16 *wm, but the same thing I guess.
Reviewed-by: Jani Nikula
> {
> - struct intel_uncore *uncore = &dev_priv->uncore;
> - int max_level = ilk_wm_max_level(dev_priv);
> -
> - if (DISPLAY_VER(dev_priv) >= 14) {
> - u32 val;
> -
> - val = intel_uncore_read(uncore, MTL_LATENCY_LP0_LP1);
> - wm[0] = REG_FIELD_GET(MTL_LATENCY_LEVEL_EVEN_MASK, val);
> - wm[1] = REG_FIELD_GET(MTL_LATENCY_LEVEL_ODD_MASK, val);
> - val = intel_uncore_read(uncore, MTL_LATENCY_LP2_LP3);
> - wm[2] = REG_FIELD_GET(MTL_LATENCY_LEVEL_EVEN_MASK, val);
> - wm[3] = REG_FIELD_GET(MTL_LATENCY_LEVEL_ODD_MASK, val);
> - val = intel_uncore_read(uncore, MTL_LATENCY_LP4_LP5);
> - wm[4] = REG_FIELD_GET(MTL_LATENCY_LEVEL_EVEN_MASK, val);
> - wm[5] = REG_FIELD_GET(MTL_LATENCY_LEVEL_ODD_MASK, val);
> -
> - adjust_wm_latency(dev_priv, wm, max_level, 6);
> - } else if (DISPLAY_VER(dev_priv) >= 9) {
> - int read_latency = DISPLAY_VER(dev_priv) >= 12 ? 3 : 2;
> - int mult = IS_DG2(dev_priv) ? 2 : 1;
> - u32 val;
> - int ret;
> -
> - /* read the first set of memory latencies[0:3] */
> - val = 0; /* data0 to be programmed to 0 for first set */
> - ret = snb_pcode_read(&dev_priv->uncore,
> GEN9_PCODE_READ_MEM_LATENCY,
> - &val, NULL);
> -
> - if (ret) {
> - drm_err(&dev_priv->drm,
> - "SKL Mailbox read error = %d\n", ret);
> - return;
> - }
> -
> - wm[0] = (val & GEN9_MEM_LATENCY_LEVEL_MASK) * mult;
> - wm[1] = ((val >> GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT) &
> - GEN9_MEM_LATENCY_LEVEL_MASK) * mult;
> - wm[2] = ((val >> GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT) &
> - GEN9_MEM_LATENCY_LEVEL_MASK) * mult;
> - wm[3] = ((val >> GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT) &
> - GEN9_MEM_LATENCY_LEVEL_MASK) * mult;
> -
> - /* read the second set of memory latencies[4:7] */
> - val = 1; /* data0 to be programmed to 1 for second set */
> - ret = snb_pcode_read(&dev_priv->uncore,
> GEN9_PCODE_READ_MEM_LATENCY,
> - &val, NULL);
> - if (ret) {
> - drm_err(&dev_priv->drm,
> - "SKL Mailbox read error = %d\n", ret);
> - return;
> - }
> -
> - wm[4] = (val & GEN9_MEM_LATENCY_LEVEL_MASK) * mult;
> - wm[5] = ((val >> GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT) &
> - GEN9_MEM_LATENCY_LEVEL_MASK) * mult;
> - wm[6] = ((val >> GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT) &
> - GEN9_MEM_LATENCY_LEVEL_MASK) * mult;
> - wm[7] = ((val >> GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT) &
> - GEN9_MEM_LATENCY_LEVEL_MASK) * mult;
> -
> - adjust_wm_latency(dev_priv, wm, max_level, read_latency);
> - } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> - u64 sskpd = intel_uncore_read64(uncore, MCH_SSKPD);
> -
> - wm[0] = REG_FIELD_GET64(SSKPD_NEW_WM0_MASK_HSW, sskpd);
> - if (wm[0] == 0)
> - wm[0] = REG_FIELD_GET64(SSKPD_OLD_WM0_MASK_HSW, sskpd);
> - wm[1] = REG_FIELD_GET64(SSKPD_WM1_MASK_HSW, sskpd);
> - wm[2] = REG_FIELD_GET64(SSKPD_WM2_MASK_HSW, sskpd);
> - wm[3] = REG_FIELD_GET64(SSKPD_WM3_MASK_HSW, sskpd);
> - wm[4] = REG_FIELD_GET64(SSKPD_WM4_MASK_HSW, sskpd);
> - } else if (DISPLAY_VER(dev_priv) >= 6) {
> - u32 sskpd = intel_uncore_read(uncore, MCH_SSKPD);
> -
> - wm[0] = REG_FIELD_GET(SSKPD_WM0_MASK_SNB, sskpd);
> - wm[1] = REG_FIELD_GET(SSKPD_
Re: [Intel-gfx] [PATCH v3 01/15] vfio: Add helpers for unifying vfio_device life cycle
> From: Ethan Zhao
> Sent: Friday, September 9, 2022 4:24 PM
>
> Hi, Kevin,
>
> 在 2022/9/9 18:22, Kevin Tian 写道:
> > The idea is to let vfio core manage the vfio_device life cycle instead
> > of duplicating the logic cross drivers. This is also a preparatory
> > step for adding struct device into vfio_device.
> >
> > New pair of helpers together with a kref in vfio_device:
> >
> > - vfio_alloc_device()
> > - vfio_put_device()
>
> To be honest, this pair of functions make me confusing to understand their
>
> behaviour from wording point of view:
>
> - vfio_alloc_device(), Okay, it allocates the vfio device, no reference
> count thing. but,
I think it's quite common to have an alloc() helper initialize refcount, e.g.
vfio_group_alloc() both initialize its user refcount and also call
device_initialize() to gets kref initialized. Similar example in
ib_alloc_device(), etc.
> - vfio_put_device()
> seems it will decrease reference count and then if it is zero, free it.
> so they are not of one *pair* about wording.
>
> How about
>
> - vfio_alloc_device() / - vfio_free_device()
> or
> - vfio_get_device() / - vfio_put_device(), perhaps not match their behviour
> in following code.
>
>
>
> Thanks,
> Ethan
>
>
> >
> > Drivers can register @init/@release callbacks to manage any private
> > state wrapping the vfio_device.
> >
> > However vfio-ccw doesn't fit this model due to a life cycle mess
> > that its private structure mixes both parent and mdev info hence must
> > be allocated/freed outside of the life cycle of vfio device.
> >
> > Per prior discussions this won't be fixed in short term by IBM folks.
> >
> > Instead of waiting for those modifications introduce another helper
> > vfio_init_device() so ccw can call it to initialize a pre-allocated
> > vfio_device.
> >
> > Further implication of the ccw trick is that vfio_device cannot be
> > freed uniformly in vfio core. Instead, require *EVERY* driver to
> > implement @release and free vfio_device inside. Then ccw can choose
> > to delay the free at its own discretion.
> >
> > Another trick down the road is that kvzalloc() is used to accommodate
> > the need of gvt which uses vzalloc() while all others use kzalloc().
> > So drivers should call a helper vfio_free_device() to free the
> > vfio_device instead of assuming that kfree() or vfree() is appliable.
> >
> > Later once the ccw mess is fixed we can remove those tricks and
> > fully handle structure alloc/free in vfio core.
> >
> > Existing vfio_{un}init_group_dev() will be deprecated after all
> > existing usages are converted to the new model.
> >
> > Suggested-by: Jason Gunthorpe
> > Co-developed-by: Yi Liu
> > Signed-off-by: Yi Liu
> > Signed-off-by: Kevin Tian
> > Reviewed-by: Tony Krowiak
> > Reviewed-by: Jason Gunthorpe
> > Reviewed-by: Eric Auger
> > ---
> > drivers/vfio/vfio_main.c | 92
>
> > include/linux/vfio.h | 25 ++-
> > 2 files changed, 116 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> > index 27d9186f35d5..adc1b697bb78 100644
> > --- a/drivers/vfio/vfio_main.c
> > +++ b/drivers/vfio/vfio_main.c
> > @@ -498,6 +498,98 @@ void vfio_uninit_group_dev(struct vfio_device
> *device)
> > }
> > EXPORT_SYMBOL_GPL(vfio_uninit_group_dev);
> >
> > +/* Release helper called by vfio_put_device() */
> > +void vfio_device_release(struct kref *kref)
> > +{
> > + struct vfio_device *device =
> > + container_of(kref, struct vfio_device, kref);
> > +
> > + vfio_uninit_group_dev(device);
> > +
> > + /*
> > +* kvfree() cannot be done here due to a life cycle mess in
> > +* vfio-ccw. Before the ccw part is fixed all drivers are
> > +* required to support @release and call vfio_free_device()
> > +* from there.
> > +*/
> > + device->ops->release(device);
> > +}
> > +EXPORT_SYMBOL_GPL(vfio_device_release);
> > +
> > +/*
> > + * Alloc and initialize vfio_device so it can be registered to vfio
> > + * core.
> > + *
> > + * Drivers should use the wrapper vfio_alloc_device() for allocation.
> > + * @size is the size of the structure to be allocated, including any
> > + * private data used by the driver.
> > + *
> > + * Driver may provide an @init callback to cover device private data.
> > + *
> > + * Use vfio_put_device() to release the structure after success return.
> > + */
> > +struct vfio_device *_vfio_alloc_device(size_t size, struct device *dev,
> > + const struct vfio_device_ops *ops)
> > +{
> > + struct vfio_device *device;
> > + int ret;
> > +
> > + if (WARN_ON(size < sizeof(struct vfio_device)))
> > + return ERR_PTR(-EINVAL);
> > +
> > + device = kvzalloc(size, GFP_KERNEL);
> > + if (!device)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + ret = vfio_init_device(device, dev, ops);
> > + if (ret)
> > + goto out_free;
> > + return device;
> > +
> >
[Intel-gfx] [PULL] drm-misc-next
Hello Dave, Daniel, Another pull request for drm-misc-next, enjoy! ~Maarten drm-misc-next-2022-09-09: drm-misc-next for v6.1-rc1: UAPI Changes: - Hide unregistered connectors from GETCONNECTOR ioctl. - drm/virtio no longer advertises LINEAR modifier, as it doesn't work. - Cross-subsystem Changes: - Fix GPF in udmabuf failure path. Core Changes: - Rework TTM placement to use intersect/compatible functions. - Drop legacy DP-MST support. - More DP-MST related fixes, and move all state into atomic. - Make DRM_MIPI_DBI select DRM_KMS_HELPER. - Add audio_infoframe packing for DP. - Add logging when some atomic check functions fail. - Assorted documentation updates and fixes. Driver Changes: - Assorted cleanups and fixes in msm, lcdif, nouveau, virtio, panel/ilitek, bridge/icn6211, tve200, gma500, bridge/*, panfrost, via, bochs, qxl, sun4i. - Add add AUO B133UAN02.1, IVO M133NW4J-R3, Innolux N120ACA-EA1 eDP panels. - Improve DP-MST modeset state handling in amdgpu, nouveau, i915. - Drop DP-MST from radeon driver, it was broken and only user of legacy DP-MST. - Handle unplugging better in vc4. - Simplify drm cmdparser tests. - Add DP support to ti-sn65dsi86. - Add MT8195 DP support to mediatek. - Support RGB565, XRGB64, and ARGB64 formats in vkms. - Convert sun4i tv support to atomic. - Refactor vc4/vec TV Modesetting, and fix timings. - Use atomic helpers instead of simple display helpers in ssd130x. Maintainer changes: - Add Douglas Anderson as reviewer for panel-edp. The following changes since commit 8869fa666a9e6782c3c896c1fa57d65adca23249: drm/virtio: remove drm_plane_cleanup() destroy hook (2022-08-19 16:00:15 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2022-09-09 for you to fetch changes up to 5d832b6694e094b176627ed9918a1b21c56fb742: drm/dp_mst: Avoid deleting payloads for connectors staying enabled (2022-09-08 19:41:18 +0300) drm-misc-next for v6.1-rc1: UAPI Changes: - Hide unregistered connectors from GETCONNECTOR ioctl. - drm/virtio no longer advertises LINEAR modifier, as it doesn't work. - Cross-subsystem Changes: - Fix GPF in udmabuf failure path. Core Changes: - Rework TTM placement to use intersect/compatible functions. - Drop legacy DP-MST support. - More DP-MST related fixes, and move all state into atomic. - Make DRM_MIPI_DBI select DRM_KMS_HELPER. - Add audio_infoframe packing for DP. - Add logging when some atomic check functions fail. - Assorted documentation updates and fixes. Driver Changes: - Assorted cleanups and fixes in msm, lcdif, nouveau, virtio, panel/ilitek, bridge/icn6211, tve200, gma500, bridge/*, panfrost, via, bochs, qxl, sun4i. - Add add AUO B133UAN02.1, IVO M133NW4J-R3, Innolux N120ACA-EA1 eDP panels. - Improve DP-MST modeset state handling in amdgpu, nouveau, i915. - Drop DP-MST from radeon driver, it was broken and only user of legacy DP-MST. - Handle unplugging better in vc4. - Simplify drm cmdparser tests. - Add DP support to ti-sn65dsi86. - Add MT8195 DP support to mediatek. - Support RGB565, XRGB64, and ARGB64 formats in vkms. - Convert sun4i tv support to atomic. - Refactor vc4/vec TV Modesetting, and fix timings. - Use atomic helpers instead of simple display helpers in ssd130x. Maintainer changes: - Add Douglas Anderson as reviewer for panel-edp. Alisa Khabibrakhmanova (1): drm/via: Add new condition to via_dma_cleanup() Arunpravin Paneer Selvam (6): drm/ttm: Add new callbacks to ttm res mgr drm/ttm: Implement intersect/compatible functions drm/amdgpu: Implement intersect/compatible functions drm/i915: Implement intersect/compatible functions drm/nouveau: Implement intersect/compatible functions drm/ttm: Switch to using the new res callback Beniamin Sandu (1): drm/nouveau/hwmon: use simplified HWMON_CHANNEL_INFO macro Bo-Chen Chen (4): drm/mediatek: dp: Add multiple bridge types support drm/mediatek: dp: Add multiple smc commands support drm/mediatek: dp: Add multiple calibration data formats support drm/mediatek: dp: Determine device of next_bridge Chen-Yu Tsai (1): drm/panel-edp: Add Innolux N120ACA-EA1 panel entry Chia-I Wu (1): drm/virtio: set fb_modifiers_not_supported Chris Morgan (2): dt-bindings: Add byteswap order to chrontel ch7033 drm/bridge: chrontel-ch7033: Add byteswap order setting Danilo Krummrich (4): drm/vc4: hdmi: unlock mutex when device is unplugged drm/vc4: plane: protect device resources after removal drm/vc4: crtc: protect device resources after removal drm/vc4: hvs: protect drm_print_regset32() Douglas Anderson (2): MAINTAINERS: Add myself as a reviewer for panel-edp.c drm/panel-edp: Fix typo in kerneldoc comment (appers=>appears) Gerd Hoffmann (1): drm/bochs: fix bl
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Use REG_FIELD_GET() to extract skl+ wm latencies
On Thu, 08 Sep 2022, Ville Syrjala wrote: > From: Ville Syrjälä > > Replace the hand rolled stuff with REG_FIELD_GET() for reading > out the skl+ watermark latencies. > > Signed-off-by: Ville Syrjälä Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/i915/display/skl_watermark.c | 22 +++- > drivers/gpu/drm/i915/i915_reg.h | 8 +++ > 2 files changed, 12 insertions(+), 18 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c > b/drivers/gpu/drm/i915/display/skl_watermark.c > index 25ca92ae8958..cb297725d5b9 100644 > --- a/drivers/gpu/drm/i915/display/skl_watermark.c > +++ b/drivers/gpu/drm/i915/display/skl_watermark.c > @@ -3239,13 +3239,10 @@ static void skl_read_wm_latency(struct > drm_i915_private *i915, u16 wm[]) > return; > } > > - wm[0] = (val & GEN9_MEM_LATENCY_LEVEL_MASK) * mult; > - wm[1] = ((val >> GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT) & > - GEN9_MEM_LATENCY_LEVEL_MASK) * mult; > - wm[2] = ((val >> GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT) & > - GEN9_MEM_LATENCY_LEVEL_MASK) * mult; > - wm[3] = ((val >> GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT) & > - GEN9_MEM_LATENCY_LEVEL_MASK) * mult; > + wm[0] = REG_FIELD_GET(GEN9_MEM_LATENCY_LEVEL_0_4_MASK, val) * mult; > + wm[1] = REG_FIELD_GET(GEN9_MEM_LATENCY_LEVEL_1_5_MASK, val) * mult; > + wm[2] = REG_FIELD_GET(GEN9_MEM_LATENCY_LEVEL_2_6_MASK, val) * mult; > + wm[3] = REG_FIELD_GET(GEN9_MEM_LATENCY_LEVEL_3_7_MASK, val) * mult; > > /* read the second set of memory latencies[4:7] */ > val = 1; /* data0 to be programmed to 1 for second set */ > @@ -3255,13 +3252,10 @@ static void skl_read_wm_latency(struct > drm_i915_private *i915, u16 wm[]) > return; > } > > - wm[4] = (val & GEN9_MEM_LATENCY_LEVEL_MASK) * mult; > - wm[5] = ((val >> GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT) & > - GEN9_MEM_LATENCY_LEVEL_MASK) * mult; > - wm[6] = ((val >> GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT) & > - GEN9_MEM_LATENCY_LEVEL_MASK) * mult; > - wm[7] = ((val >> GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT) & > - GEN9_MEM_LATENCY_LEVEL_MASK) * mult; > + wm[4] = REG_FIELD_GET(GEN9_MEM_LATENCY_LEVEL_0_4_MASK, val) * mult; > + wm[5] = REG_FIELD_GET(GEN9_MEM_LATENCY_LEVEL_1_5_MASK, val) * mult; > + wm[6] = REG_FIELD_GET(GEN9_MEM_LATENCY_LEVEL_2_6_MASK, val) * mult; > + wm[7] = REG_FIELD_GET(GEN9_MEM_LATENCY_LEVEL_3_7_MASK, val) * mult; > > adjust_wm_latency(i915, wm, max_level, read_latency); > } > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index c413eec3373f..7289e2b7da2c 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -6551,10 +6551,10 @@ > #define GEN6_DECODE_RC6_VID(vids)(((vids) * 5) + 245) > #define BDW_PCODE_DISPLAY_FREQ_CHANGE_REQ 0x18 > #define GEN9_PCODE_READ_MEM_LATENCY0x6 > -#define GEN9_MEM_LATENCY_LEVEL_MASK 0xFF > -#define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT 8 > -#define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT 16 > -#define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT 24 > +#define GEN9_MEM_LATENCY_LEVEL_3_7_MASK REG_GENMASK(31, 24) > +#define GEN9_MEM_LATENCY_LEVEL_2_6_MASK REG_GENMASK(23, 16) > +#define GEN9_MEM_LATENCY_LEVEL_1_5_MASK REG_GENMASK(15, 8) > +#define GEN9_MEM_LATENCY_LEVEL_0_4_MASK REG_GENMASK(7, 0) > #define SKL_PCODE_LOAD_HDCP_KEYS 0x5 > #define SKL_PCODE_CDCLK_CONTROL0x7 > #define SKL_CDCLK_PREPARE_FOR_CHANGE 0x3 -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix a potential UAF at device unload
On 08/09/2022 21:07, Nirmoy Das wrote:
i915_gem_drain_freed_objects() might not be enough to
free all the objects and RCU delayed work might get
scheduled after the i915 device struct gets freed.
Call i915_gem_drain_workqueue() to catch all RCU delayed work.
Suggested-by: Chris Wilson
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0f49ec9d494a..e8a053eaaa89 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1254,7 +1254,7 @@ void i915_gem_init_early(struct drm_i915_private
*dev_priv)
void i915_gem_cleanup_early(struct drm_i915_private *dev_priv)
{
- i915_gem_drain_freed_objects(dev_priv);
+ i915_gem_drain_workqueue(dev_priv);
GEM_BUG_ON(!llist_empty(&dev_priv->mm.free_list));
GEM_BUG_ON(atomic_read(&dev_priv->mm.free_count));
drm_WARN_ON(&dev_priv->drm, dev_priv->mm.shrink_count);
Help me spot the place where RCU free worker schedules itself back to
free more objects - if I got the rationale here right?
Regards,
Tvrtko
Re: [Intel-gfx] [PATCH 2/2] drm/i915: remove excessive i915_gem_drain_freed_objects
On 08/09/2022 21:07, Nirmoy Das wrote: i915_gem_drain_workqueue() call i915_gem_drain_freed_objects() so no need to call that again. Signed-off-by: Nirmoy Das --- drivers/gpu/drm/i915/i915_gem.c | 2 -- drivers/gpu/drm/i915/selftests/mock_gem_device.c | 1 - 2 files changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index e8a053eaaa89..e16718d79533 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -1217,8 +1217,6 @@ void i915_gem_driver_remove(struct drm_i915_private *dev_priv) /* Flush any outstanding unpin_work. */ i915_gem_drain_workqueue(dev_priv); - - i915_gem_drain_freed_objects(dev_priv); } void i915_gem_driver_release(struct drm_i915_private *dev_priv) diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c b/drivers/gpu/drm/i915/selftests/mock_gem_device.c index f5904e659ef2..5d02346c43a2 100644 --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c @@ -67,7 +67,6 @@ static void mock_device_release(struct drm_device *dev) intel_gt_driver_remove(to_gt(i915)); i915_gem_drain_workqueue(i915); - i915_gem_drain_freed_objects(i915); mock_fini_ggtt(to_gt(i915)->ggtt); destroy_workqueue(i915->wq); Reviewed-by: Tvrtko Ursulin Regards, Tvrtko
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Define WD trancoder for i915
> From: Suraj Kandpal
>
> Adding WD Types, WD transcoder to enum list and WD Transcoder offsets.
> Adding i915 register definitions related to WD transcoder
>
> Signed-off-by: Suraj Kandpal
> ---
> drivers/gpu/drm/i915/display/intel_display.h | 6 +
> .../drm/i915/display/intel_display_types.h| 1 +
> drivers/gpu/drm/i915/i915_reg.h | 139 ++
> 3 files changed, 146 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index fa5371036239..4e9f22954a41 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -120,6 +120,8 @@ enum transcoder {
> TRANSCODER_DSI_1,
> TRANSCODER_DSI_A = TRANSCODER_DSI_0,/* legacy DSI */
> TRANSCODER_DSI_C = TRANSCODER_DSI_1,/* legacy DSI */
> + TRANSCODER_WD_0,
> + TRANSCODER_WD_1,
>
> I915_MAX_TRANSCODERS
> };
> @@ -141,6 +143,10 @@ static inline const char *transcoder_name(enum
> transcoder transcoder)
> return "DSI A";
> case TRANSCODER_DSI_C:
> return "DSI C";
> + case TRANSCODER_WD_0:
> + return "WD 0";
> + case TRANSCODER_WD_1:
> + return "WD 1";
> default:
> return "";
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 0da9b208d56e..0e94bd430bcb 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -79,6 +79,7 @@ enum intel_output_type {
> INTEL_OUTPUT_DSI = 9,
> INTEL_OUTPUT_DDI = 10,
> INTEL_OUTPUT_DP_MST = 11,
> + INTEL_OUTPUT_WD = 12,
> };
>
> enum hdmi_force_audio {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index bf5c39d9f953..e3fced4b9980
> 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2059,6 +2059,8 @@
> #define TRANSCODER_EDP_OFFSET 0x6f000
> #define TRANSCODER_DSI0_OFFSET 0x6b000
> #define TRANSCODER_DSI1_OFFSET 0x6b800
> +#define TRANSCODER_WD0_OFFSET0x6e000
> +#define TRANSCODER_WD1_OFFSET0x6e800
>
> #define HTOTAL(trans)_MMIO_TRANS2(trans, _HTOTAL_A)
> #define HBLANK(trans)_MMIO_TRANS2(trans, _HBLANK_A)
> @@ -3831,6 +3833,11 @@
> #define PIPE_DSI0_OFFSET 0x7b000
> #define PIPE_DSI1_OFFSET 0x7b800
>
> +/* WD 0 and 1 */
Can this be changed to
/* WD offset */
> +#define PIPE_WD0_OFFSET 0x7e000
> +#define PIPE_WD1_OFFSET 0x7d000
> +
> +
> #define PIPECONF(pipe) _MMIO_PIPE2(pipe, _PIPEACONF)
> #define PIPEDSL(pipe)_MMIO_PIPE2(pipe, _PIPEADSL)
> #define PIPEFRAME(pipe) _MMIO_PIPE2(pipe,
> _PIPEAFRAMEHIGH)
> @@ -4495,6 +4502,10 @@
> #define _PIPEDSI0CONF0x7b008
> #define _PIPEDSI1CONF0x7b808
>
> +/* WD 0 and 1 */
Can this be changed to
/* WD config regs */
> +#define _PIPEWD0CONF 0x7e008
> +#define _PIPEWD1CONF 0x7d008
> +
> /* Sprite A control */
> #define _DVSACNTR0x72180
> #define DVS_ENABLE REG_BIT(31)
> @@ -5720,6 +5731,7 @@
> #define GEN8_DE_MISC_IER _MMIO(0x4446c)
> #define GEN8_DE_MISC_GSE(1 << 27)
> #define GEN8_DE_EDP_PSR (1 << 19)
> +#define GEN8_DE_MISC_WD0(1 << 23)
>
> #define GEN8_PCU_ISR _MMIO(0x444e0)
> #define GEN8_PCU_IMR _MMIO(0x444e4)
> @@ -8714,6 +8726,133 @@ enum skl_power_gate {
> #define DSB_ENABLE (1 << 31)
> #define DSB_STATUS (1 << 0)
>
> +#define TGL_ROOT_DEVICE_ID 0x9A00
> +#define TGL_ROOT_DEVICE_MASK 0xFF00
> +#define TGL_ROOT_DEVICE_SKU_MASK 0xF
> +#define TGL_ROOT_DEVICE_SKU_ULX 0x2
> +#define TGL_ROOT_DEVICE_SKU_ULT 0x4
> +
> +/* Gen12 WD */
> +#define _MMIO_WD(tc, wd0, wd1) _MMIO_TRANS((tc) -
> TRANSCODER_WD_0, \
> + wd0, wd1)
> +
> +#define WD_TRANS_ENABLE (1 << 31)
> +#define WD_TRANS_DISABLE 0
> +#define WD_TRANS_ACTIVE (1 << 30)
> +
> +/* WD transcoder control */
> +#define _WD_TRANS_FUNC_CTL_0 0x6e400
> +#define _WD_TRANS_FUNC_CTL_1 0x6ec00
> +#define WD_TRANS_FUNC_CTL(tc)_MMIO_WD(tc,\
> + _WD_TRANS_FUNC_CTL_0,\
> + _WD_TRANS_FUNC_CTL_1)
> +
> +#define TRANS_WD_FUNC_ENABLE (1 << 31)
> +#define WD_TRIGGERED_CAP_MODE_ENABLE (1 << 30)
> +#define START_TRIGGER_FRAME (1 << 29)
> +#define STOP_TRIGGER_FRAME (1 << 28)
> +#define WD_CTL_POINTER_ETEH (0 << 18)
> +#define WD_CTL_POINTER_ETDH (1 << 18)
> +#define WD_CTL_POINTER_DTDH
Re: [Intel-gfx] [PATCH v2 2/3] drm/i915 : Changing intel_connector iterators
> From: Suraj Kandpal
>
> Changing intel_connector iterators as with writeback introduction not all
> drm_connector will be embedded within intel_connector.
>
> Signed-off-by: Suraj Kandpal
> ---
> drivers/gpu/drm/i915/display/intel_display.h | 7 ++---
> .../drm/i915/display/intel_display_types.h| 26 ++-
> .../drm/i915/display/intel_modeset_setup.c| 16 +---
> 3 files changed, 40 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index 4e9f22954a41..3b9987b5f304 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -52,6 +52,7 @@ struct intel_crtc_state; struct intel_digital_port; struct
> intel_dp; struct intel_encoder;
> +struct intel_connector;
> struct intel_initial_plane_config;
> struct intel_load_detect_pipe;
> struct intel_plane;
> @@ -469,16 +470,12 @@ enum hpd_pin {
> for_each_if(intel_encoder_can_psr(intel_encoder))
>
> #define for_each_intel_connector_iter(intel_connector, iter) \
> - while ((intel_connector =
> to_intel_connector(drm_connector_list_iter_next(iter
> + while ((intel_connector = intel_connector_list_iter_next(iter)))
>
> #define for_each_encoder_on_crtc(dev, __crtc, intel_encoder) \
> list_for_each_entry((intel_encoder), &(dev)-
> >mode_config.encoder_list, base.head) \
> for_each_if((intel_encoder)->base.crtc == (__crtc))
>
> -#define for_each_connector_on_encoder(dev, __encoder, intel_connector)
> \
> - list_for_each_entry((intel_connector), &(dev)-
> >mode_config.connector_list, base.head) \
> - for_each_if((intel_connector)->base.encoder == (__encoder))
> -
> #define for_each_old_intel_plane_in_state(__state, plane, old_plane_state,
> __i) \
> for ((__i) = 0; \
>(__i) < (__state)->base.dev->mode_config.num_total_plane && \
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 0e94bd430bcb..7a82b7acbaf2 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1497,12 +1497,14 @@ struct cxsr_latency { #define
> to_intel_atomic_state(x) container_of(x, struct intel_atomic_state, base)
> #define to_intel_crtc(x) container_of(x, struct intel_crtc, base) #define
> to_intel_crtc_state(x) container_of(x, struct intel_crtc_state, uapi) -#define
> to_intel_connector(x) container_of(x, struct intel_connector, base)
> +#define to_intel_wb_connector(x) container_of(x, struct
> +intel_wb_connector, base)
> #define to_intel_encoder(x) container_of(x, struct intel_encoder, base)
> #define to_intel_framebuffer(x) container_of(x, struct intel_framebuffer,
> base) #define to_intel_plane(x) container_of(x, struct intel_plane, base)
> #define to_intel_plane_state(x) container_of(x, struct intel_plane_state,
> uapi) #define intel_fb_obj(x) ((x) ? to_intel_bo((x)->obj[0]) : NULL)
> +#define to_intel_connector(x) (((x->connector_type ==
> DRM_MODE_CONNECTOR_WRITEBACK)) ? \
> + NULL : container_of(x, struct intel_connector,
> base))
>
> struct intel_hdmi {
> i915_reg_t hdmi_reg;
> @@ -2068,4 +2070,26 @@ to_intel_frontbuffer(struct drm_framebuffer *fb)
> return fb ? to_intel_framebuffer(fb)->frontbuffer : NULL; }
>
> +static inline struct intel_connector *
> +intel_connector_list_iter_next(struct drm_connector_list_iter *iter) {
> + struct drm_connector *connector;
> + bool flag = true;
> + /*
> + * Skipping connector that are Writeback connector as they will
> + * not be embedded in intel connector
> + */
Better to be more clear, "An intel_connector entity is not created for
writeback, hence decoupling"
With the above changes
Reviewed-by: Arun R Murthy
> + while (flag) {
> + connector = drm_connector_list_iter_next(iter);
> + if (connector && !to_intel_connector(connector))
> + continue;
> +
> + flag = false;
> +
> + if (connector)
> + return to_intel_connector(connector);
> +
> + }
> + return NULL;
> +}
> #endif /* __INTEL_DISPLAY_TYPES_H__ */ diff --git
> a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> index f0e04d3904c6..985dfa5f7aa1 100644
> --- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> +++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> @@ -204,12 +204,22 @@ static bool intel_crtc_has_encoders(struct
> intel_crtc *crtc)
>
> static struct intel_connector *intel_encoder_find_connector(struct
> intel_encoder *encoder) {
> - struct drm_device *dev = encoder->base.dev;
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> struct intel_connector *connector;
> + struct drm_co
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Define WD trancoder for i915
On Fri, 09 Sep 2022, "Murthy, Arun R" wrote:
>> From: Suraj Kandpal
>>
>> Adding WD Types, WD transcoder to enum list and WD Transcoder offsets.
>> Adding i915 register definitions related to WD transcoder
>>
>> Signed-off-by: Suraj Kandpal
>> ---
>> drivers/gpu/drm/i915/display/intel_display.h | 6 +
>> .../drm/i915/display/intel_display_types.h| 1 +
>> drivers/gpu/drm/i915/i915_reg.h | 139 ++
>> 3 files changed, 146 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
>> b/drivers/gpu/drm/i915/display/intel_display.h
>> index fa5371036239..4e9f22954a41 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.h
>> +++ b/drivers/gpu/drm/i915/display/intel_display.h
>> @@ -120,6 +120,8 @@ enum transcoder {
>> TRANSCODER_DSI_1,
>> TRANSCODER_DSI_A = TRANSCODER_DSI_0,/* legacy DSI */
>> TRANSCODER_DSI_C = TRANSCODER_DSI_1,/* legacy DSI */
>> +TRANSCODER_WD_0,
>> +TRANSCODER_WD_1,
>>
>> I915_MAX_TRANSCODERS
>> };
>> @@ -141,6 +143,10 @@ static inline const char *transcoder_name(enum
>> transcoder transcoder)
>> return "DSI A";
>> case TRANSCODER_DSI_C:
>> return "DSI C";
>> +case TRANSCODER_WD_0:
>> +return "WD 0";
>> +case TRANSCODER_WD_1:
>> +return "WD 1";
>> default:
>> return "";
>> }
>> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
>> b/drivers/gpu/drm/i915/display/intel_display_types.h
>> index 0da9b208d56e..0e94bd430bcb 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
>> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
>> @@ -79,6 +79,7 @@ enum intel_output_type {
>> INTEL_OUTPUT_DSI = 9,
>> INTEL_OUTPUT_DDI = 10,
>> INTEL_OUTPUT_DP_MST = 11,
>> +INTEL_OUTPUT_WD = 12,
>> };
>>
>> enum hdmi_force_audio {
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h index bf5c39d9f953..e3fced4b9980
>> 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -2059,6 +2059,8 @@
>> #define TRANSCODER_EDP_OFFSET 0x6f000
>> #define TRANSCODER_DSI0_OFFSET 0x6b000
>> #define TRANSCODER_DSI1_OFFSET 0x6b800
>> +#define TRANSCODER_WD0_OFFSET 0x6e000
>> +#define TRANSCODER_WD1_OFFSET 0x6e800
>>
>> #define HTOTAL(trans) _MMIO_TRANS2(trans, _HTOTAL_A)
>> #define HBLANK(trans) _MMIO_TRANS2(trans, _HBLANK_A)
>> @@ -3831,6 +3833,11 @@
>> #define PIPE_DSI0_OFFSET0x7b000
>> #define PIPE_DSI1_OFFSET0x7b800
>>
>> +/* WD 0 and 1 */
> Can this be changed to
> /* WD offset */
Nah, the comments should be removed altogether, they add zero
value. That's literally what the macro name says already.
BR,
Jani.
>
>> +#define PIPE_WD0_OFFSET 0x7e000
>> +#define PIPE_WD1_OFFSET 0x7d000
>> +
>> +
>> #define PIPECONF(pipe) _MMIO_PIPE2(pipe, _PIPEACONF)
>> #define PIPEDSL(pipe) _MMIO_PIPE2(pipe, _PIPEADSL)
>> #define PIPEFRAME(pipe) _MMIO_PIPE2(pipe,
>> _PIPEAFRAMEHIGH)
>> @@ -4495,6 +4502,10 @@
>> #define _PIPEDSI0CONF 0x7b008
>> #define _PIPEDSI1CONF 0x7b808
>>
>> +/* WD 0 and 1 */
> Can this be changed to
> /* WD config regs */
>
>> +#define _PIPEWD0CONF0x7e008
>> +#define _PIPEWD1CONF0x7d008
>> +
>> /* Sprite A control */
>> #define _DVSACNTR 0x72180
>> #define DVS_ENABLEREG_BIT(31)
>> @@ -5720,6 +5731,7 @@
>> #define GEN8_DE_MISC_IER _MMIO(0x4446c)
>> #define GEN8_DE_MISC_GSE (1 << 27)
>> #define GEN8_DE_EDP_PSR(1 << 19)
>> +#define GEN8_DE_MISC_WD0 (1 << 23)
>>
>> #define GEN8_PCU_ISR _MMIO(0x444e0)
>> #define GEN8_PCU_IMR _MMIO(0x444e4)
>> @@ -8714,6 +8726,133 @@ enum skl_power_gate {
>> #define DSB_ENABLE(1 << 31)
>> #define DSB_STATUS(1 << 0)
>>
>> +#define TGL_ROOT_DEVICE_ID 0x9A00
>> +#define TGL_ROOT_DEVICE_MASK0xFF00
>> +#define TGL_ROOT_DEVICE_SKU_MASK0xF
>> +#define TGL_ROOT_DEVICE_SKU_ULX 0x2
>> +#define TGL_ROOT_DEVICE_SKU_ULT 0x4
>> +
>> +/* Gen12 WD */
>> +#define _MMIO_WD(tc, wd0, wd1) _MMIO_TRANS((tc) -
>> TRANSCODER_WD_0, \
>> +wd0, wd1)
>> +
>> +#define WD_TRANS_ENABLE (1 << 31)
>> +#define WD_TRANS_DISABLE0
>> +#define WD_TRANS_ACTIVE (1 << 30)
>> +
>> +/* WD transcoder control */
>> +#define _WD_TRANS_FUNC_CTL_00x6e400
>> +#define _WD_TRANS_FUNC_CTL_10x6ec00
>> +#define WD_TRANS_FUNC_CTL(tc) _MMIO_WD(tc,\
>> +_WD_TRANS_FUNC_CTL_0,\
>> +_WD_TRANS_FUNC_CTL_1)
>> +
>> +#define TRANS_WD_
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Define WD trancoder for i915
> On Fri, 09 Sep 2022, "Murthy, Arun R" wrote:
> >> From: Suraj Kandpal
> >>
> >> Adding WD Types, WD transcoder to enum list and WD Transcoder
> offsets.
> >> Adding i915 register definitions related to WD transcoder
> >>
> >> Signed-off-by: Suraj Kandpal
> >> ---
> >> drivers/gpu/drm/i915/display/intel_display.h | 6 +
> >> .../drm/i915/display/intel_display_types.h| 1 +
> >> drivers/gpu/drm/i915/i915_reg.h | 139 ++
> >> 3 files changed, 146 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> >> b/drivers/gpu/drm/i915/display/intel_display.h
> >> index fa5371036239..4e9f22954a41 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_display.h
> >> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> >> @@ -120,6 +120,8 @@ enum transcoder {
> >>TRANSCODER_DSI_1,
> >>TRANSCODER_DSI_A = TRANSCODER_DSI_0,/* legacy DSI */
> >>TRANSCODER_DSI_C = TRANSCODER_DSI_1,/* legacy DSI */
> >> + TRANSCODER_WD_0,
> >> + TRANSCODER_WD_1,
> >>
> >>I915_MAX_TRANSCODERS
> >> };
> >> @@ -141,6 +143,10 @@ static inline const char *transcoder_name(enum
> >> transcoder transcoder)
> >>return "DSI A";
> >>case TRANSCODER_DSI_C:
> >>return "DSI C";
> >> + case TRANSCODER_WD_0:
> >> + return "WD 0";
> >> + case TRANSCODER_WD_1:
> >> + return "WD 1";
> >>default:
> >>return "";
> >>}
> >> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> >> b/drivers/gpu/drm/i915/display/intel_display_types.h
> >> index 0da9b208d56e..0e94bd430bcb 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> >> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> >> @@ -79,6 +79,7 @@ enum intel_output_type {
> >>INTEL_OUTPUT_DSI = 9,
> >>INTEL_OUTPUT_DDI = 10,
> >>INTEL_OUTPUT_DP_MST = 11,
> >> + INTEL_OUTPUT_WD = 12,
> >> };
> >>
> >> enum hdmi_force_audio {
> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >> b/drivers/gpu/drm/i915/i915_reg.h index bf5c39d9f953..e3fced4b9980
> >> 100644
> >> --- a/drivers/gpu/drm/i915/i915_reg.h
> >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> @@ -2059,6 +2059,8 @@
> >> #define TRANSCODER_EDP_OFFSET 0x6f000
> >> #define TRANSCODER_DSI0_OFFSET0x6b000
> >> #define TRANSCODER_DSI1_OFFSET0x6b800
> >> +#define TRANSCODER_WD0_OFFSET 0x6e000
> >> +#define TRANSCODER_WD1_OFFSET 0x6e800
> >>
> >> #define HTOTAL(trans) _MMIO_TRANS2(trans, _HTOTAL_A)
> >> #define HBLANK(trans) _MMIO_TRANS2(trans, _HBLANK_A)
> >> @@ -3831,6 +3833,11 @@
> >> #define PIPE_DSI0_OFFSET 0x7b000
> >> #define PIPE_DSI1_OFFSET 0x7b800
> >>
> >> +/* WD 0 and 1 */
> > Can this be changed to
> > /* WD offset */
>
> Nah, the comments should be removed altogether, they add zero value.
> That's literally what the macro name says already.
>
That should be best!
Please remove this.
Thanks and Regards,
Arun R Murthy
---
l Open Source Graphics Center
Re: [Intel-gfx] [PATCH v3 27/37] docs: gpu: i915.rst: gt: add more kernel-doc markups
On Fri, Sep 09, 2022 at 09:34:34AM +0200, Mauro Carvalho Chehab wrote: > There are several documented GT kAPI that aren't currently part > of the docs. Add them, as this allows identifying issues with > badly-formatted tags. > In i915's commits we usually add a version history here to indicate what changed from the previous submission, something like v2: re-organizing the blocks to group gtt stuff. that helps reviewers to know if their change requested was addressed or not. but anyways: Reviewed-by: Rodrigo Vivi > Signed-off-by: Mauro Carvalho Chehab > --- > > To avoid mailbombing on a large number of people, only mailing lists were C/C > on the cover. > See [PATCH v3 00/37] at: > https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ > > Documentation/gpu/i915.rst | 40 +- > 1 file changed, 39 insertions(+), 1 deletion(-) > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > index 2ad7941a79f2..b668f36fb0a3 100644 > --- a/Documentation/gpu/i915.rst > +++ b/Documentation/gpu/i915.rst > @@ -149,7 +149,6 @@ Misc display functions > > .. kernel-doc:: drivers/gpu/drm/i915/display/skl_scaler.c > > - > Plane Configuration > --- > > @@ -308,6 +307,45 @@ Multicast/Replicated (MCR) Registers > .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_mcr.c > :internal: > > +GT engine > +- > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_types.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_cs.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_pm.c > + > +Graphics Translation Tables > +--- > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_ggtt.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gtt.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gtt.h > + > +Other GT functionality > +-- > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_context.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gsc.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_migrate.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_mocs.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rc6.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_reset.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rps_types.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rps.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_sseu.c > + > Memory Management and Command Submission > > > -- > 2.37.3 >
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Split intel_read_wm_latency() into per-platform versions
On Fri, Sep 09, 2022 at 11:27:07AM +0300, Jani Nikula wrote:
> On Thu, 08 Sep 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > No reaon to have this humongous if ladder in intel_read_wm_latency().
>
> *reason
>
> > Just split it into nicer per-platforms functions.
> >
> > Also do the s/dev_priv/i915/ while touching all of this code.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 201 +---
> > 1 file changed, 110 insertions(+), 91 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 210c1f78cc90..096c311ed29f 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -2905,97 +2905,107 @@ adjust_wm_latency(struct drm_i915_private *i915,
> > wm[0] += 1;
> > }
> >
> > -static void intel_read_wm_latency(struct drm_i915_private *dev_priv,
> > - u16 wm[])
> > +static void mtl_read_wm_latency(struct drm_i915_private *i915, u16 wm[])
>
> Bikeshed, I'd make that u16 *wm, but the same thing I guess.
I'd prefer to know that it's an array rather than a pointer.
>
> Reviewed-by: Jani Nikula
Thanks.
>
>
> > {
> > - struct intel_uncore *uncore = &dev_priv->uncore;
> > - int max_level = ilk_wm_max_level(dev_priv);
> > -
> > - if (DISPLAY_VER(dev_priv) >= 14) {
> > - u32 val;
> > -
> > - val = intel_uncore_read(uncore, MTL_LATENCY_LP0_LP1);
> > - wm[0] = REG_FIELD_GET(MTL_LATENCY_LEVEL_EVEN_MASK, val);
> > - wm[1] = REG_FIELD_GET(MTL_LATENCY_LEVEL_ODD_MASK, val);
> > - val = intel_uncore_read(uncore, MTL_LATENCY_LP2_LP3);
> > - wm[2] = REG_FIELD_GET(MTL_LATENCY_LEVEL_EVEN_MASK, val);
> > - wm[3] = REG_FIELD_GET(MTL_LATENCY_LEVEL_ODD_MASK, val);
> > - val = intel_uncore_read(uncore, MTL_LATENCY_LP4_LP5);
> > - wm[4] = REG_FIELD_GET(MTL_LATENCY_LEVEL_EVEN_MASK, val);
> > - wm[5] = REG_FIELD_GET(MTL_LATENCY_LEVEL_ODD_MASK, val);
> > -
> > - adjust_wm_latency(dev_priv, wm, max_level, 6);
> > - } else if (DISPLAY_VER(dev_priv) >= 9) {
> > - int read_latency = DISPLAY_VER(dev_priv) >= 12 ? 3 : 2;
> > - int mult = IS_DG2(dev_priv) ? 2 : 1;
> > - u32 val;
> > - int ret;
> > -
> > - /* read the first set of memory latencies[0:3] */
> > - val = 0; /* data0 to be programmed to 0 for first set */
> > - ret = snb_pcode_read(&dev_priv->uncore,
> > GEN9_PCODE_READ_MEM_LATENCY,
> > -&val, NULL);
> > -
> > - if (ret) {
> > - drm_err(&dev_priv->drm,
> > - "SKL Mailbox read error = %d\n", ret);
> > - return;
> > - }
> > -
> > - wm[0] = (val & GEN9_MEM_LATENCY_LEVEL_MASK) * mult;
> > - wm[1] = ((val >> GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT) &
> > - GEN9_MEM_LATENCY_LEVEL_MASK) * mult;
> > - wm[2] = ((val >> GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT) &
> > - GEN9_MEM_LATENCY_LEVEL_MASK) * mult;
> > - wm[3] = ((val >> GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT) &
> > - GEN9_MEM_LATENCY_LEVEL_MASK) * mult;
> > -
> > - /* read the second set of memory latencies[4:7] */
> > - val = 1; /* data0 to be programmed to 1 for second set */
> > - ret = snb_pcode_read(&dev_priv->uncore,
> > GEN9_PCODE_READ_MEM_LATENCY,
> > -&val, NULL);
> > - if (ret) {
> > - drm_err(&dev_priv->drm,
> > - "SKL Mailbox read error = %d\n", ret);
> > - return;
> > - }
> > -
> > - wm[4] = (val & GEN9_MEM_LATENCY_LEVEL_MASK) * mult;
> > - wm[5] = ((val >> GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT) &
> > - GEN9_MEM_LATENCY_LEVEL_MASK) * mult;
> > - wm[6] = ((val >> GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT) &
> > - GEN9_MEM_LATENCY_LEVEL_MASK) * mult;
> > - wm[7] = ((val >> GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT) &
> > - GEN9_MEM_LATENCY_LEVEL_MASK) * mult;
> > -
> > - adjust_wm_latency(dev_priv, wm, max_level, read_latency);
> > - } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> > - u64 sskpd = intel_uncore_read64(uncore, MCH_SSKPD);
> > -
> > - wm[0] = REG_FIELD_GET64(SSKPD_NEW_WM0_MASK_HSW, sskpd);
> > - if (wm[0] == 0)
> > - wm[0] = REG_FIELD_GET64(SSKPD_OLD_WM0_MASK_HSW, sskpd);
> > - wm[1] = REG_FIELD_GET64(SSKPD_WM1_MASK_HSW, sskpd);
> > - wm[2] = REG_FIELD_GET64(SSKPD_WM2_MASK_HSW, sskpd);
> > - wm[3] = REG_FIELD_GET64(SSKPD_WM3_MASK_HSW, sskpd);
> > - wm[4] = REG_FIELD_GET64(SSKPD_WM4_MASK_HSW, sskpd);
>
Re: [Intel-gfx] [PATCH v3 32/37] docs: gpu: i915.rst: add the remaining kernel-doc markup files
On Fri, Sep 09, 2022 at 09:34:39AM +0200, Mauro Carvalho Chehab wrote: > There are other files with kernel-doc markups: > > $ git grep -l "/\*\*" $(git ls-files|grep drivers/gpu/drm/i915/) > >kernel-doc-files > $ for i in $(cat kernel-doc-files); do if [ "$(git grep $i > Documentation/)" == "" ]; then echo "$i"; fi; done >aaa > > Add them to i915.rst as well. > > Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Rodrigo Vivi > --- > > To avoid mailbombing on a large number of people, only mailing lists were C/C > on the cover. > See [PATCH v3 00/37] at: > https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ > > Documentation/gpu/i915.rst | 85 +- > 1 file changed, 83 insertions(+), 2 deletions(-) > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > index 545fe630557a..7f5cd01ed398 100644 > --- a/Documentation/gpu/i915.rst > +++ b/Documentation/gpu/i915.rst > @@ -13,6 +13,11 @@ Core Driver Infrastructure > This section covers core driver infrastructure used by both the display > and the GEM parts of the driver. > > +Core driver > +--- > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_driver.c > + > Runtime Power Management > > > @@ -29,6 +34,8 @@ Runtime Power Management > > .. kernel-doc:: drivers/gpu/drm/i915/intel_pm.c > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_wakeref.h > + > Interrupt Handling > -- > > @@ -44,8 +51,25 @@ Interrupt Handling > .. kernel-doc:: drivers/gpu/drm/i915/i915_irq.c > :functions: intel_runtime_pm_enable_interrupts > > -Intel GVT-g Guest Support(vGPU) > > +Memory Handling > +--- > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma_resource.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma_resource.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_mm.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/intel_memory_region.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_memcpy.c > + > +Intel GVT-g Guest Support (vGPU) > + > > .. kernel-doc:: drivers/gpu/drm/i915/i915_vgpu.c > :doc: Intel GVT-g guest support > @@ -109,6 +133,55 @@ Workarounds > .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_workarounds.c > :doc: Hardware workarounds > > +Scatterlist handling > + > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_scatterlist.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_scatterlist.c > + > +i915 request > + > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_request.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_request.c > + > +Others > +-- > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_ioc32.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_gpu_error.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_active.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_deps.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_deps.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/intel_device_info.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_params.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_sw_fence_work.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_syncmap.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/intel_pcode.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_reg_defs.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/intel_wopcm.h > + > + > +Protected Xe Path (PXP) > +--- > + > +.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_irq.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_tee.c > + > Display Hardware Handling > = > > @@ -615,6 +688,12 @@ Protected Objects > Table Manager (TTM) > --- > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_ttm_buddy_manager.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_ttm_buddy_manager.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/intel_region_ttm.c > + > .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm.h > @@ -624,6 +703,8 @@ Table Manager (TTM) > Graphics Execution Manager (GEM) > > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_gem.c > + > .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_create.c > > .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_domain.c > -- > 2.37.3 >
Re: [Intel-gfx] [PATCH v3 35/37] drm/i915: add descriptions for some RPM macros at intel_gt_pm.h
On Fri, Sep 09, 2022 at 09:34:42AM +0200, Mauro Carvalho Chehab wrote:
> The intel_gt_pm.h file contains some convenient macros to be used
> in GT code in order to get/put runtime PM references and for
> checking them.
>
> Add descriptions based on the ones at intel_wakeref.h and
> intel_runtime_pm.c.
>
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Rodrigo Vivi
> ---
>
> To avoid mailbombing on a large number of people, only mailing lists were C/C
> on the cover.
> See [PATCH v3 00/37] at:
> https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
>
> Documentation/gpu/i915.rst| 2 ++
> drivers/gpu/drm/i915/gt/intel_gt_pm.h | 51 +++
> 2 files changed, 53 insertions(+)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 7f5cd01ed398..59c532fe0332 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -446,6 +446,8 @@ Graphics Translation Tables
> Other GT functionality
> --
>
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_pm.h
> +
> .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_context.h
>
> .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gsc.h
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> index 6c9a46452364..7847e15d102e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> @@ -11,21 +11,57 @@
> #include "intel_gt_types.h"
> #include "intel_wakeref.h"
>
> +/**
> + * intel_gt_pm_is_awake: Query whether the runtime PM is awake held
> + *
> + * @gt: pointer to the graphics engine
> + *
> + * Returns: true if a runtime pm reference is currently held and the GT is
> + * awake.
> + */
> static inline bool intel_gt_pm_is_awake(const struct intel_gt *gt)
> {
> return intel_wakeref_is_active(>->wakeref);
> }
>
> +/**
> + * intel_gt_pm_get: grab a runtime PM reference ensuring that GT is powered
> up
> + * @gt: pointer to the graphics engine
> + *
> + * Any runtime pm reference obtained by this function must have a symmetric
> + * call to intel_gt_pm_put() to release the reference again.
> + *
> + * Note that this is allowed to fail, in which case the runtime-pm wakeref
> + * will be released and the acquisition unwound.
> + */
> static inline void intel_gt_pm_get(struct intel_gt *gt)
> {
> intel_wakeref_get(>->wakeref);
> }
>
> +/**
> + * __intel_gt_pm_get: Acquire the runtime PM reference again
> + * @gt: pointer to the graphics engine which contains the wakeref
> + *
> + * Increment the PM reference counter, only valid if it is already held by
> + * the caller.
> + *
> + * See intel_gt_pm_get().
> + */
> static inline void __intel_gt_pm_get(struct intel_gt *gt)
> {
> __intel_wakeref_get(>->wakeref);
> }
>
> +/**
> + * intel_gt_pm_get_if_awake: Acquire the runtime PM reference if active
> + * @gt: pointer to the graphics engine which contains the PM reference
> + *
> + * Acquire a hold on the PM reference, but only if the GT is already
> + * active.
> + *
> + * Returns: true if the wakeref was acquired, false otherwise.
> + */
> static inline bool intel_gt_pm_get_if_awake(struct intel_gt *gt)
> {
> return intel_wakeref_get_if_active(>->wakeref);
> @@ -36,6 +72,14 @@ static inline void intel_gt_pm_might_get(struct intel_gt
> *gt)
> intel_wakeref_might_get(>->wakeref);
> }
>
> +/**
> + * intel_gt_pm_put: Release the runtime PM reference
> + * @gt: pointer to the graphics engine which contains the PM reference
> + *
> + * Release our hold on the runtime PM for GT.
> + *
> + * It might power down the GT right away if this is the last reference.
> + */
> static inline void intel_gt_pm_put(struct intel_gt *gt)
> {
> intel_wakeref_put(>->wakeref);
> @@ -51,6 +95,13 @@ static inline void intel_gt_pm_might_put(struct intel_gt
> *gt)
> intel_wakeref_might_put(>->wakeref);
> }
>
> +/**
> + * with_intel_gt_pm - get a GT reference ensuring that GT is powered up,
> + * run some code and then put the reference away.
> + *
> + * @gt: pointer to the gt
> + * @tmp: pointer to a temporary wakeref.
> + */
> #define with_intel_gt_pm(gt, tmp) \
> for (tmp = 1, intel_gt_pm_get(gt); tmp; \
>intel_gt_pm_put(gt), tmp = 0)
> --
> 2.37.3
>
Re: [Intel-gfx] [PATCH v3 37/37] drm/i915: be consistent with kernel-doc function declaration
On Fri, Sep 09, 2022 at 09:34:44AM +0200, Mauro Carvalho Chehab wrote:
> Currently, 91% of kernel-doc function declarations don't have
> parenthesis on it. Let's be consistent inside the driver by
> removing the parenthesis from the other ones.
>
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Rodrigo Vivi
> ---
>
> To avoid mailbombing on a large number of people, only mailing lists were C/C
> on the cover.
> See [PATCH v3 00/37] at:
> https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
>
> drivers/gpu/drm/i915/display/intel_atomic.c| 2 +-
> drivers/gpu/drm/i915/display/intel_audio.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_crtc.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_dmc.c | 10 +-
> drivers/gpu/drm/i915/display/intel_dsb.c | 10 +-
> drivers/gpu/drm/i915/display/intel_lpe_audio.c | 8
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 10 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 10 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc.h | 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 4 ++--
> drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c| 8
> drivers/gpu/drm/i915/gt/uc/intel_huc.c | 4 ++--
> drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +-
> drivers/gpu/drm/i915/i915_cmd_parser.c | 8
> drivers/gpu/drm/i915/i915_reg_defs.h | 12 ++--
> drivers/gpu/drm/i915/intel_wopcm.c | 4 ++--
> 18 files changed, 53 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index 18f0a5ae3bac..9b604a720ff0 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -373,7 +373,7 @@ static void intel_atomic_setup_scaler(struct
> intel_crtc_scaler_state *scaler_sta
> }
>
> /**
> - * intel_atomic_setup_scalers() - setup scalers for crtc per staged requests
> + * intel_atomic_setup_scalers - setup scalers for crtc per staged requests
> * @dev_priv: i915 device
> * @intel_crtc: intel crtc
> * @crtc_state: incoming crtc_state to validate and setup scalers
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index aacbc6da84ef..667fe9a8ff8e 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -1385,7 +1385,7 @@ static void i915_audio_component_cleanup(struct
> drm_i915_private *dev_priv)
> }
>
> /**
> - * intel_audio_init() - Initialize the audio driver either using
> + * intel_audio_init - Initialize the audio driver either using
> * component framework or using lpe audio bridge
> * @dev_priv: the i915 drm device private data
> *
> @@ -1397,7 +1397,7 @@ void intel_audio_init(struct drm_i915_private *dev_priv)
> }
>
> /**
> - * intel_audio_deinit() - deinitialize the audio driver
> + * intel_audio_deinit - deinitialize the audio driver
> * @dev_priv: the i915 drm device private data
> *
> */
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 6792a9056f46..507d7aec7b1c 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -463,7 +463,7 @@ static int intel_mode_vblank_start(const struct
> drm_display_mode *mode)
> }
>
> /**
> - * intel_pipe_update_start() - start update of a set of display registers
> + * intel_pipe_update_start - start update of a set of display registers
> * @new_crtc_state: the new crtc state
> *
> * Mark the start of an update to pipe registers that should be updated
> @@ -617,7 +617,7 @@ static void dbg_vblank_evade(struct intel_crtc *crtc,
> ktime_t end) {}
> #endif
>
> /**
> - * intel_pipe_update_end() - end update of a set of display registers
> + * intel_pipe_update_end - end update of a set of display registers
> * @new_crtc_state: the new crtc state
> *
> * Mark the end of an update started with intel_pipe_update_start(). This
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index e52ecc0738a6..2024884688f6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -408,7 +408,7 @@ static void pipedmc_clock_gating_wa(struct
> drm_i915_private *i915, bool enable)
> }
>
> /**
> - * intel_dmc_load_program() - write the firmware from memory to register.
> + * intel_dmc_load_program - write the firmware from memory to register.
> * @dev_priv: i915 drm device.
> *
> * DMC firmware is read from a .bin file and kept in internal memory one
> time.
> @@ -876,7 +876,7 @@ static void dmc_load_work_fn(struct work_struct *work)
> }
>
> /**
>
Re: [Intel-gfx] [PATCH v4 06/15] mei: pxp: support matching with a gfx discrete card
> >
> > > -Original Message-
> > > From: Greg Kroah-Hartman
> > > Sent: Friday, September 09, 2022 09:16
> > > To: Ceraolo Spurio, Daniele
> > > Cc: intel-gfx@lists.freedesktop.org;
> > > dri-de...@lists.freedesktop.org; Winkler, Tomas
> > > ; Lubart, Vitaly ;
> > > Teres Alexis, Alan Previn
> > > Subject: Re: [PATCH v4 06/15] mei: pxp: support matching with a gfx
> > > discrete card
> > >
> > > On Thu, Sep 08, 2022 at 05:16:03PM -0700, Daniele Ceraolo Spurio wrote:
> > > > From: Tomas Winkler
> > > >
> > > > With on-boards graphics card, both i915 and MEI are in the same
> > > > device hierarchy with the same parent, while for discrete gfx card
> > > > the MEI is its child device.
> > > > Adjust the match function for that scenario by matching MEI parent
> > > > device with i915.
> > > >
> > > > V2:
> > > > 1. More detailed commit message
> > > > 2. Check for dev is not null before it is accessed.
> > > >
> > > > Signed-off-by: Tomas Winkler
> > > > Signed-off-by: Daniele Ceraolo Spurio
> > > >
> > > > Cc: Vitaly Lubart
> > > > Cc: Greg Kroah-Hartman
> > > > Reviewed-by: Alan Previn
> > > > ---
> > > > drivers/misc/mei/pxp/mei_pxp.c | 13 ++---
> > > > 1 file changed, 10 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/misc/mei/pxp/mei_pxp.c
> > > > b/drivers/misc/mei/pxp/mei_pxp.c index 17c5d201603f..afc047627800
> > > > 100644
> > > > --- a/drivers/misc/mei/pxp/mei_pxp.c
> > > > +++ b/drivers/misc/mei/pxp/mei_pxp.c
> > > > @@ -159,17 +159,24 @@ static int mei_pxp_component_match(struct
> > > device
> > > > *dev, int subcomponent, {
> > > > struct device *base = data;
> > > >
> > > > + if (!dev)
> > > > + return 0;
> > >
> > > How can that happen?
> > >
> > > > +
> > > > if (!dev->driver || strcmp(dev->driver->name, "i915") ||
> > >
> > > That's crazy to assume, but whatever :(
> > Explained here:
> > https://lore.kernel.org/all/20220418175932.1809770-2-
> wonchung@google.c
> > om/
>
> Still crazy :(
>
> >
> > >
> > > > subcomponent != I915_COMPONENT_PXP)
> > > > return 0;
> > > >
> > > > base = base->parent;
> > > > - if (!base)
> > > > + if (!base) /* mei device */
> > >
> > > Why does this mean that?
> > >
> > > Where is that documented?
> > >
> > > > return 0;
> > > >
> > > > - base = base->parent;
> > > > - dev = dev->parent;
> > > > + base = base->parent; /* pci device */
> > >
> > > Again, why is this the case?
> > >
> > > > + /* for dgfx */
> > > > + if (base && dev == base)
> > > > + return 1;
> > > >
> > > > + /* for pch */
> > > > + dev = dev->parent;
> > >
> > > You are digging through a random device tree and assuming that you
> "know"
> > > what the topology is going to be, that feels very very fragile and
> > > ripe for problems going forward.
> >
> > I don't think it is random.
>
> Today it is one specific way, but how do you know this always will be this
> way?
>
> > > How do you ensure that this really is they way the tree is for ALL
> systems?
> >
> > Yes we take the topology assumption in PCI hierarchy.
> > There is a case where both GFX and MEI are in PCH and you cannot stick
> additional PCI extender or anything else there.
> > And case where MEI is child on a standalone graphics card this is set
> > in software so topology is not going to change unless we rewrite
> everything. Be happy to hear your insights.
>
> This is ripe to break in the future if someone makes a differently structured
> device as there is nothing forcing the current layout to always be this way by
> hardware designers.
>
> The goal of the driver model is to NOT have these types of hard-coded
> topology assumptions because, supprise, assumptions like this have always
> come back to bite people in the end.
>
> This is your driver, so that's fine, but really this feels very very wrong
> and you
> will have a hard time guaranteeing that this will always be this way for the
> next 20+ years of hardware designs. So why not do it properly from the
> beginning and pass in the correct pointers to different places?
>
> There is a very good reason that the driver model/core does not make it easy
> to determine what type of device a 'struct device *' is, because you shouldn't
> have to rely on that type of thing ever. You are taking it one step further
> and
> just assuming that you know what the type is here, with no real way to
> ensure that this is the case.
>
> In short, this feels like a very bad design as it is very fragile.
I believe I understand your concern but I would need to invent another
addressing scheme to associate hw components that are already
addressable by let say PCI hierarchy. We've changed two subsystems for this
work
components and aux bus already. So let's have some fun in the future.
Thanks
Tomas
Re: [Intel-gfx] [PATCH v2 09/41] drm/connector: Add TV standard property
On Wed, Sep 07, 2022 at 09:52:09PM +0200, Mateusz Kwiatkowski wrote:
> W dniu 7.09.2022 o 14:10, Maxime Ripard pisze:
> > Hi,
> >
> > On Fri, Sep 02, 2022 at 12:00:33AM +0200, Mateusz Kwiatkowski wrote:
> >> W dniu 29.08.2022 o 15:11, Maxime Ripard pisze:
> >>> The TV mode property has been around for a while now to select and get the
> >>> current TV mode output on an analog TV connector.
> >>>
> >>> Despite that property name being generic, its content isn't and has been
> >>> driver-specific which makes it hard to build any generic behaviour on top
> >>> of it, both in kernel and user-space.
> >>>
> >>> Let's create a new bitmask tv norm property, that can contain any of the
> >>> analog TV standards currently supported by kernel drivers. Each driver can
> >>> then pass in a bitmask of the modes it supports.
> >>
> >> This is not a bitmask property anymore, you've just changed it to an enum.
> >> The commit message is now misleading.
> >>
> >>> +static const struct drm_prop_enum_list drm_tv_mode_enum_list[] = {
> >>> + { DRM_MODE_TV_MODE_NTSC_443, "NTSC-443" },
> >>> + { DRM_MODE_TV_MODE_NTSC_J, "NTSC-J" },
> >>> + { DRM_MODE_TV_MODE_NTSC_M, "NTSC-M" },
> >>> + { DRM_MODE_TV_MODE_PAL_60, "PAL-60" },
> >>> + { DRM_MODE_TV_MODE_PAL_B, "PAL-B" },
> >>> + { DRM_MODE_TV_MODE_PAL_D, "PAL-D" },
> >>> + { DRM_MODE_TV_MODE_PAL_G, "PAL-G" },
> >>> + { DRM_MODE_TV_MODE_PAL_H, "PAL-H" },
> >>> + { DRM_MODE_TV_MODE_PAL_I, "PAL-I" },
> >>> + { DRM_MODE_TV_MODE_PAL_M, "PAL-M" },
> >>> + { DRM_MODE_TV_MODE_PAL_N, "PAL-N" },
> >>> + { DRM_MODE_TV_MODE_PAL_NC, "PAL-Nc" },
> >>> + { DRM_MODE_TV_MODE_SECAM_60, "SECAM-60" },
> >>> + { DRM_MODE_TV_MODE_SECAM_B, "SECAM-B" },
> >>> + { DRM_MODE_TV_MODE_SECAM_D, "SECAM-D" },
> >>> + { DRM_MODE_TV_MODE_SECAM_G, "SECAM-G" },
> >>> + { DRM_MODE_TV_MODE_SECAM_K, "SECAM-K" },
> >>> + { DRM_MODE_TV_MODE_SECAM_K1, "SECAM-K1" },
> >>> + { DRM_MODE_TV_MODE_SECAM_L, "SECAM-L" },
> >>> +};
> >>
> >> I did not comment on it the last time, but this list looks a little bit
> >> random.
> >>
> >> Compared to the standards defined by V4L2, you also define SECAM-60 (a good
> >> thing to define, because why not), but don't define PAL-B1, PAL-D1, PAL-K,
> >> SECAM-H, SECAM-LC (whatever that is - probably just another name for
> >> SECAM-L,
> >> see my comment about PAL-Nc below), or NTSC-M-KR (a Korean variant of
> >> NTSC).
> >>
> >> Like I mentioned previously, I'm personally not a fan of including all
> >> those
> >> CCIR/ITU system variants, as they don't mean any difference to the output
> >> unless
> >> there is an RF modulator involved. But I get it that they have already
> >> been used
> >> and regressing probably wouldn't be a very good idea. But in that case
> >> keeping
> >> it consistent with the set of values used by V4L2 would be wise, I think.
> >
> > Ack. What would be the list of standards we'd absolutely need? NSTC-M,
> > NTSC-J, PAL-60, PAL-B, PAL-M, SECAM-60 and SECAM-B?
>
> The "essential list" IMO is NTSC, NTSC-J, NTSC-443, PAL, PAL-M, PAL-N and
> SECAM.
> Note that:
>
> - I intentionally propose "NTSC", "PAL" and "SECAM" without an ITU system
> designation. If we only consider composite signals, there's no difference
> between e.g. PAL-B, PAL-D and PAL-I, so it's better to label it as a generic
> mode, IMO.
>
> * PAL-M and PAL-N are different, because those unique color encodings were
> only ever used with Systems M and N, respectively.
>
> * NTSC-J is also different, because "System J" doesn't exist anywhere in ITU
> documents. Japan technically uses System M with a non-standard black
> level.
> But "NTSC-J" stuck as a universally recognized name for that variant.
>
> - I intentionally did not list PAL-60 or SECAM-60. TBH... PAL-60 is just
> regular PAL paired with 480i60 modeline. Most if not all displays that
> accept PAL-60 input will just label it as "PAL". If we are not introducing
> strict modeline validation, then maybe separating PAL and PAL-60 isn't
> really
> necessary? Same goes for SECAM vs. SECAM-60.
>
> ...and same goes for NTSC vs. NTSC-50 a.k.a NTSC-N, which is a very exotic
> mode, but known to exist at least in the Atari ST world, see also:
> https://en.wikipedia.org/wiki/NTSC#NTSC-N/NTSC50
>
> Combining PAL and PAL-60 into a single setting would complicate the vc4 driver
> a little bit, though, as the registers need to be set up differently for
> those.
>
> My feelings about the PAL-60 issue are not that strong, though. Merging PAL
> and PAL-60 in this context is just a loose suggestion, I won't even try to
> argue if you disagree.
Ack
> >>> +/**
> >>> + * drm_mode_create_tv_properties - create TV specific connector
> >>> properties
> >>> + * @dev: DRM device
> >>> + * @supported_tv_modes: Bitmask of TV modes supported (See
> >>> DRM_MODE_TV_MODE_*)
> >>> +
> >>> + * Called by a driver's TV initialization routine, this function creates
> >
Re: [Intel-gfx] Developing a new backlight driver for specific OLED screen
On Fri, Sep 09, 2022 at 11:35:28AM +0200, Aurélien wrote: >Hi, >I hope this mailing-mist is the right place for this question. + dri-devel mailing list that looks more appropriated. + Hans and Lyude who were recently working to standardize some of the backlight stuff. >I would like to develop a new driver in order to manage backlight for a >specific OLED display (Samsung one). For that propose I need to use the >dpcd aux read and write functions. >Since this driver is independent film the i915 driver I would like to >develop an indémependant driver. >So my question is: how can I use the i915 API (dpcd aux communications) >outside from the driver and register the backlight sys entries like the >i915 does (in order to have all the softwares which plays with the >backlight working without modifying them) ? I don't believe you want to use the i915 API, but move the common functions to the drm subsystem itself and then reuse as a drm device. >Many thanks for your answers >-- >Aurélien
Re: [Intel-gfx] [PATCH 6/8] drm/i915/debugfs: Add perf_limit_reasons in debugfs
On Wed, Sep 07, 2022 at 10:22:49PM -0700, Ashutosh Dixit wrote:
> From: Tilak Tangudu
>
> Add perf_limit_reasons in debugfs. The upper 16 perf_limit_reasons RW "log"
> bits are identical to the lower 16 RO "status" bits except that the "log"
> bits remain set until cleared, thereby ensuring the throttling occurrence
> is not missed. The clear fop clears the upper 16 "log" bits, the get fop
> gets all 32 "log" and "status" bits.
>
> v2: Expand commit message and clarify "log" and "status" bits in
> comment (Rodrigo)
>
> Cc: Rodrigo Vivi
> Signed-off-by: Ashutosh Dixit
> Signed-off-by: Tilak Tangudu
> ---
> drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 31 +++
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 2 files changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> index 108b9e76c32e..a009cf69103a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> @@ -655,6 +655,36 @@ static bool rps_eval(void *data)
>
> DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(rps_boost);
>
> +static int perf_limit_reasons_get(void *data, u64 *val)
> +{
> + struct intel_gt *gt = data;
> + intel_wakeref_t wakeref;
> +
> + with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> + *val = intel_uncore_read(gt->uncore, GT0_PERF_LIMIT_REASONS);
> +
> + return 0;
> +}
> +
> +static int perf_limit_reasons_clear(void *data, u64 val)
> +{
> + struct intel_gt *gt = data;
> + intel_wakeref_t wakeref;
> +
> + /*
> + * Clear the upper 16 "log" bits, the lower 16 "status" bits are
> + * read-only. The upper 16 "log" bits are identical to the lower 16
> + * "status" bits except that the "log" bits remain set until cleared.
> + */
> + with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> + intel_uncore_rmw(gt->uncore, GT0_PERF_LIMIT_REASONS,
> + GT0_PERF_LIMIT_REASONS_LOG_MASK, 0);
> +
> + return 0;
> +}
> +DEFINE_SIMPLE_ATTRIBUTE(perf_limit_reasons_fops, perf_limit_reasons_get,
> + perf_limit_reasons_clear, "%llu\n");
> +
> void intel_gt_pm_debugfs_register(struct intel_gt *gt, struct dentry *root)
> {
> static const struct intel_gt_debugfs_file files[] = {
> @@ -664,6 +694,7 @@ void intel_gt_pm_debugfs_register(struct intel_gt *gt,
> struct dentry *root)
> { "forcewake_user", &forcewake_user_fops, NULL},
> { "llc", &llc_fops, llc_eval },
> { "rps_boost", &rps_boost_fops, rps_eval },
> + { "perf_limit_reasons", &perf_limit_reasons_fops, NULL },
> };
>
> intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), gt);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 24009786f88b..9492f8f43b25 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1802,6 +1802,7 @@
> #define POWER_LIMIT_4_MASK REG_BIT(8)
> #define POWER_LIMIT_1_MASK REG_BIT(10)
> #define POWER_LIMIT_2_MASK REG_BIT(11)
> +#define GT0_PERF_LIMIT_REASONS_LOG_MASK REG_GENMASK(31, 16)
>
I'm kind of confused here because I saw the other bits in the patch 5.
but, anyway, thanks for improving the commit msg.
Reviewed-by: Rodrigo Vivi
> #define CHV_CLK_CTL1 _MMIO(0x101100)
> #define VLV_CLK_CTL2 _MMIO(0x101104)
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH 7/8] drm/i915/mtl: PERF_LIMIT_REASONS changes for MTL
On Wed, Sep 07, 2022 at 10:23:38PM -0700, Ashutosh Dixit wrote:
> PERF_LIMIT_REASONS register for MTL media gt is different now.
>
> v2: Avoid static inline for intel_gt_perf_limit_reasons_reg() (Jani)
>
> Cc: Jani Nikula
> Cc: Badal Nilawar
> Signed-off-by: Ashutosh Dixit
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c| 6 ++
> drivers/gpu/drm/i915/gt/intel_gt.h| 1 +
> drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 6 +++---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 5 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index 070068524a19..602d711d3c9e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -224,6 +224,12 @@ static void gen6_clear_engine_error_register(struct
> intel_engine_cs *engine)
> GEN6_RING_FAULT_REG_POSTING_READ(engine);
> }
>
> +i915_reg_t intel_gt_perf_limit_reasons_reg(struct intel_gt *gt)
> +{
> + return gt->type == GT_MEDIA ?
> + MTL_MEDIA_PERF_LIMIT_REASONS : GT0_PERF_LIMIT_REASONS;
> +}
> +
> void
> intel_gt_clear_error_registers(struct intel_gt *gt,
> intel_engine_mask_t engine_mask)
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
> b/drivers/gpu/drm/i915/gt/intel_gt.h
> index c9a359f35d0f..b6509d3e8804 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.h
> @@ -60,6 +60,7 @@ void intel_gt_driver_late_release_all(struct
> drm_i915_private *i915);
> int intel_gt_wait_for_idle(struct intel_gt *gt, long timeout);
>
> void intel_gt_check_and_clear_faults(struct intel_gt *gt);
> +i915_reg_t intel_gt_perf_limit_reasons_reg(struct intel_gt *gt);
> void intel_gt_clear_error_registers(struct intel_gt *gt,
> intel_engine_mask_t engine_mask);
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> index a009cf69103a..68310881a793 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> @@ -661,7 +661,7 @@ static int perf_limit_reasons_get(void *data, u64 *val)
> intel_wakeref_t wakeref;
>
> with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> - *val = intel_uncore_read(gt->uncore, GT0_PERF_LIMIT_REASONS);
> + *val = intel_uncore_read(gt->uncore,
> intel_gt_perf_limit_reasons_reg(gt));
>
> return 0;
> }
> @@ -677,7 +677,7 @@ static int perf_limit_reasons_clear(void *data, u64 val)
>* "status" bits except that the "log" bits remain set until cleared.
>*/
> with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> - intel_uncore_rmw(gt->uncore, GT0_PERF_LIMIT_REASONS,
> + intel_uncore_rmw(gt->uncore,
> intel_gt_perf_limit_reasons_reg(gt),
>GT0_PERF_LIMIT_REASONS_LOG_MASK, 0);
>
> return 0;
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> index e066cc33d9f2..54deae45d81f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> @@ -510,7 +510,7 @@ struct intel_gt_bool_throttle_attr {
> struct attribute attr;
> ssize_t (*show)(struct device *dev, struct device_attribute *attr,
> char *buf);
> - i915_reg_t reg32;
> + i915_reg_t (*reg32)(struct intel_gt *gt);
> u32 mask;
> };
>
> @@ -521,7 +521,7 @@ static ssize_t throttle_reason_bool_show(struct device
> *dev,
> struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
> struct intel_gt_bool_throttle_attr *t_attr =
> (struct intel_gt_bool_throttle_attr *) attr;
> - bool val = rps_read_mask_mmio(>->rps, t_attr->reg32, t_attr->mask);
> + bool val = rps_read_mask_mmio(>->rps, t_attr->reg32(gt),
> t_attr->mask);
>
> return sysfs_emit(buff, "%u\n", val);
> }
> @@ -530,7 +530,7 @@ static ssize_t throttle_reason_bool_show(struct device
> *dev,
> struct intel_gt_bool_throttle_attr attr_##sysfs_func__ = { \
> .attr = { .name = __stringify(sysfs_func__), .mode = 0444 }, \
> .show = throttle_reason_bool_show, \
> - .reg32 = GT0_PERF_LIMIT_REASONS, \
> + .reg32 = intel_gt_perf_limit_reasons_reg, \
> .mask = mask__, \
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 9492f8f43b25..10a89d869b00 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1803,6 +1803,7 @@
> #define POWER_LIMIT_1_MASK REG_BIT(10)
> #define POWER_LIMIT_2_MASK REG_BIT(11)
> #define GT0_PERF_LIMIT_REASONS_LOG_MASK REG_GENMASK(31, 16)
> +#define MTL_MEDIA_PERF_LIMIT_REAS
Re: [Intel-gfx] [PATCH 8/8] drm/i915/rps: Freq caps for MTL
On Wed, Sep 07, 2022 at 10:23:57PM -0700, Ashutosh Dixit wrote:
> For MTL, when reading from HW, RP0, RP1 (actuall RPe) and RPn freq use an
> entirely different set of registers with different fields, bitwidths and
> units.
>
> v2: Move MTL check into a separate function (Jani)
>
> Cc: Jani Nikula
> Cc: Badal Nilawar
> Signed-off-by: Ashutosh Dixit
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gt/intel_rps.c | 46 +++--
> drivers/gpu/drm/i915/i915_reg.h | 9 ++
> 2 files changed, 46 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
> b/drivers/gpu/drm/i915/gt/intel_rps.c
> index 6fadde4ee7bf..234c69e2ca03 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -1085,15 +1085,25 @@ static u32 intel_rps_read_state_cap(struct intel_rps
> *rps)
> return intel_uncore_read(uncore, GEN6_RP_STATE_CAP);
> }
>
> -/**
> - * gen6_rps_get_freq_caps - Get freq caps exposed by HW
> - * @rps: the intel_rps structure
> - * @caps: returned freq caps
> - *
> - * Returned "caps" frequencies should be converted to MHz using
> - * intel_gpu_freq()
> - */
> -void gen6_rps_get_freq_caps(struct intel_rps *rps, struct
> intel_rps_freq_caps *caps)
> +static void
> +mtl_get_freq_caps(struct intel_rps *rps, struct intel_rps_freq_caps *caps)
> +{
> + struct intel_uncore *uncore = rps_to_uncore(rps);
> + u32 rp_state_cap = rps_to_gt(rps)->type == GT_MEDIA ?
> + intel_uncore_read(uncore, MTL_MEDIAP_STATE_CAP)
> :
> + intel_uncore_read(uncore, MTL_RP_STATE_CAP);
> + u32 rpe = rps_to_gt(rps)->type == GT_MEDIA ?
> + intel_uncore_read(uncore, MTL_MPE_FREQUENCY) :
> + intel_uncore_read(uncore, MTL_GT_RPE_FREQUENCY);
> +
> + /* MTL values are in units of 16.67 MHz */
> + caps->rp0_freq = REG_FIELD_GET(MTL_RP0_CAP_MASK, rp_state_cap);
> + caps->min_freq = REG_FIELD_GET(MTL_RPN_CAP_MASK, rp_state_cap);
> + caps->rp1_freq = REG_FIELD_GET(MTL_RPE_MASK, rpe);
> +}
> +
> +static void
> +__gen6_rps_get_freq_caps(struct intel_rps *rps, struct intel_rps_freq_caps
> *caps)
> {
> struct drm_i915_private *i915 = rps_to_i915(rps);
> u32 rp_state_cap;
> @@ -1128,6 +1138,24 @@ void gen6_rps_get_freq_caps(struct intel_rps *rps,
> struct intel_rps_freq_caps *c
> }
> }
>
> +/**
> + * gen6_rps_get_freq_caps - Get freq caps exposed by HW
> + * @rps: the intel_rps structure
> + * @caps: returned freq caps
> + *
> + * Returned "caps" frequencies should be converted to MHz using
> + * intel_gpu_freq()
> + */
> +void gen6_rps_get_freq_caps(struct intel_rps *rps, struct
> intel_rps_freq_caps *caps)
> +{
> + struct drm_i915_private *i915 = rps_to_i915(rps);
> +
> + if (IS_METEORLAKE(i915))
> + return mtl_get_freq_caps(rps, caps);
> + else
> + return __gen6_rps_get_freq_caps(rps, caps);
> +}
> +
> static void gen6_rps_init(struct intel_rps *rps)
> {
> struct drm_i915_private *i915 = rps_to_i915(rps);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 10a89d869b00..f008367a3433 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1792,6 +1792,15 @@
> #define XEHPSDV_RP_STATE_CAP _MMIO(0x250014)
> #define PVC_RP_STATE_CAP _MMIO(0x281014)
>
> +#define MTL_RP_STATE_CAP _MMIO(0x138000)
> +#define MTL_MEDIAP_STATE_CAP _MMIO(0x138020)
> +#define MTL_RP0_CAP_MASK REG_GENMASK(8, 0)
> +#define MTL_RPN_CAP_MASK REG_GENMASK(24, 16)
> +
> +#define MTL_GT_RPE_FREQUENCY _MMIO(0x13800c)
> +#define MTL_MPE_FREQUENCY_MMIO(0x13802c)
> +#define MTL_RPE_MASK REG_GENMASK(8, 0)
> +
> #define GT0_PERF_LIMIT_REASONS _MMIO(0x1381a8)
> #define GT0_PERF_LIMIT_REASONS_MASK0xde3
> #define PROCHOT_MASK REG_BIT(0)
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH v4 06/15] mei: pxp: support matching with a gfx discrete card
On Fri, Sep 09, 2022 at 09:21:30AM +, Winkler, Tomas wrote:
> > >
> > > > -Original Message-
> > > > From: Greg Kroah-Hartman
> > > > Sent: Friday, September 09, 2022 09:16
> > > > To: Ceraolo Spurio, Daniele
> > > > Cc: intel-gfx@lists.freedesktop.org;
> > > > dri-de...@lists.freedesktop.org; Winkler, Tomas
> > > > ; Lubart, Vitaly ;
> > > > Teres Alexis, Alan Previn
> > > > Subject: Re: [PATCH v4 06/15] mei: pxp: support matching with a gfx
> > > > discrete card
> > > >
> > > > On Thu, Sep 08, 2022 at 05:16:03PM -0700, Daniele Ceraolo Spurio wrote:
> > > > > From: Tomas Winkler
> > > > >
> > > > > With on-boards graphics card, both i915 and MEI are in the same
> > > > > device hierarchy with the same parent, while for discrete gfx card
> > > > > the MEI is its child device.
> > > > > Adjust the match function for that scenario by matching MEI parent
> > > > > device with i915.
> > > > >
> > > > > V2:
> > > > > 1. More detailed commit message
> > > > > 2. Check for dev is not null before it is accessed.
> > > > >
> > > > > Signed-off-by: Tomas Winkler
> > > > > Signed-off-by: Daniele Ceraolo Spurio
> > > > >
> > > > > Cc: Vitaly Lubart
> > > > > Cc: Greg Kroah-Hartman
> > > > > Reviewed-by: Alan Previn
> > > > > ---
> > > > > drivers/misc/mei/pxp/mei_pxp.c | 13 ++---
> > > > > 1 file changed, 10 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/misc/mei/pxp/mei_pxp.c
> > > > > b/drivers/misc/mei/pxp/mei_pxp.c index 17c5d201603f..afc047627800
> > > > > 100644
> > > > > --- a/drivers/misc/mei/pxp/mei_pxp.c
> > > > > +++ b/drivers/misc/mei/pxp/mei_pxp.c
> > > > > @@ -159,17 +159,24 @@ static int mei_pxp_component_match(struct
> > > > device
> > > > > *dev, int subcomponent, {
> > > > > struct device *base = data;
> > > > >
> > > > > + if (!dev)
> > > > > + return 0;
> > > >
> > > > How can that happen?
> > > >
> > > > > +
> > > > > if (!dev->driver || strcmp(dev->driver->name, "i915") ||
> > > >
> > > > That's crazy to assume, but whatever :(
> > > Explained here:
> > > https://lore.kernel.org/all/20220418175932.1809770-2-
> > wonchung@google.c
> > > om/
> >
> > Still crazy :(
> >
> > >
> > > >
> > > > > subcomponent != I915_COMPONENT_PXP)
> > > > > return 0;
> > > > >
> > > > > base = base->parent;
> > > > > - if (!base)
> > > > > + if (!base) /* mei device */
> > > >
> > > > Why does this mean that?
> > > >
> > > > Where is that documented?
> > > >
> > > > > return 0;
> > > > >
> > > > > - base = base->parent;
> > > > > - dev = dev->parent;
> > > > > + base = base->parent; /* pci device */
> > > >
> > > > Again, why is this the case?
> > > >
> > > > > + /* for dgfx */
> > > > > + if (base && dev == base)
> > > > > + return 1;
> > > > >
> > > > > + /* for pch */
> > > > > + dev = dev->parent;
> > > >
> > > > You are digging through a random device tree and assuming that you
> > "know"
> > > > what the topology is going to be, that feels very very fragile and
> > > > ripe for problems going forward.
> > >
> > > I don't think it is random.
> >
> > Today it is one specific way, but how do you know this always will be this
> > way?
> >
> > > > How do you ensure that this really is they way the tree is for ALL
> > systems?
> > >
> > > Yes we take the topology assumption in PCI hierarchy.
> > > There is a case where both GFX and MEI are in PCH and you cannot stick
> > additional PCI extender or anything else there.
> > > And case where MEI is child on a standalone graphics card this is set
> > > in software so topology is not going to change unless we rewrite
> > everything. Be happy to hear your insights.
> >
> > This is ripe to break in the future if someone makes a differently
> > structured
> > device as there is nothing forcing the current layout to always be this way
> > by
> > hardware designers.
> >
> > The goal of the driver model is to NOT have these types of hard-coded
> > topology assumptions because, supprise, assumptions like this have always
> > come back to bite people in the end.
> >
> > This is your driver, so that's fine, but really this feels very very wrong
> > and you
> > will have a hard time guaranteeing that this will always be this way for the
> > next 20+ years of hardware designs. So why not do it properly from the
> > beginning and pass in the correct pointers to different places?
> >
> > There is a very good reason that the driver model/core does not make it easy
> > to determine what type of device a 'struct device *' is, because you
> > shouldn't
> > have to rely on that type of thing ever. You are taking it one step
> > further and
> > just assuming that you know what the type is here, with no real way to
> > ensure that this is the case.
> >
> > In short, this feels like a very bad design as it is very fragile.
>
> I believe I understand your concern but I would need to invent another
> ad
Re: [Intel-gfx] [PATCH v7 00/15] GSC support for XeHP SDV and DG2
Dave, do you have a preference how to deal with the mishap here, shall I do a force-push to drm-intel-gt-next to correctly record the Acked-by or revert and re-push? Or just leave it as is? Quoting Greg Kroah-Hartman (2022-09-01 18:09:09) > On Sat, Aug 06, 2022 at 03:26:21PM +0300, Tomas Winkler wrote: > > Add GSC support for XeHP SDV and DG2 platforms. > > > > The series includes changes for the mei driver: > > - add ability to use polling instead of interrupts > > - add ability to use extended timeouts > > - setup extended operational memory for GSC > > > > The series includes changes for the i915 driver: > > - allocate extended operational memory for GSC > > - GSC on XeHP SDV offsets and definitions > > > > This patch set should be merged via gfx tree as > > the auxiliary device belongs there. > > Greg, your ACK is required for the drives/misc/mei code base, > > please review the patches. > > With the exception that you all don't know what year it is: > > Acked-by: Greg Kroah-Hartman Daniele, why were the patches applied without this A-b? I'm just preparing the drm-intel-gt-next pull request and now it appears like we're pushing a lot of commits outside of drm without any Acks. Please reach out to the maintainers *before* pushing code for other subsystems. Unless you get an explicit ack to do so, do not push such code. Quoting from the committer guidelines[1] the first rule is: "Only push patches changing drivers/gpu/drm/i915." In those cases, please ping a maintainer and don't rush things. Regards, Joonas [1] https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-intel.html#high-level-guidelines
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: fix kernel-doc issues (rev3)
== Series Details == Series: drm/i915: fix kernel-doc issues (rev3) URL : https://patchwork.freedesktop.org/series/106224/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v9 1/8] overflow: Move and add few utility macros into overflow
On 8/26/22 1:47 AM, Kees Cook wrote:
On Wed, Aug 24, 2022 at 05:45:07PM +0900, Gwan-gyeong Mun wrote:
It moves overflows_type utility macro into overflow header from i915_utils
header. The overflows_type can be used to catch the truncaion (overflow)
between different data types. And it adds check_assign() macro which
performs an assigning source value into destination ptr along with an
overflow check. overflow_type macro has been improved to handle the signbit
by gcc's built-in overflow check function. And it adds overflows_ptr()
helper macro for checking the overflows between a value and a pointer
type/value.
v3: Add is_type_unsigned() macro (Mauro)
Modify overflows_type() macro to consider signed data types (Mauro)
Fix the problem that safe_conversion() macro always returns true
v4: Fix kernel-doc markups
v6: Move macro addition location so that it can be used by other than drm
subsystem (Jani, Mauro, Andi)
Change is_type_unsigned to is_unsigned_type to have the same name form
as is_signed_type macro
v8: Add check_assign() and remove safe_conversion() (Kees)
Fix overflows_type() to use gcc's built-in overflow function (Andrzej)
Add overflows_ptr() to allow overflow checking when assigning a value
into a pointer variable (G.G.)
v9: Fix overflows_type() to use __builtin_add_overflow() instead of
__builtin_add_overflow_p() (Andrzej)
Fix overflows_ptr() to use overflows_type() with the unsigned long type
(Andrzej)
Signed-off-by: Gwan-gyeong Mun
Cc: Thomas Hellström
Cc: Matthew Auld
Cc: Nirmoy Das
Cc: Jani Nikula
Cc: Andi Shyti
Cc: Andrzej Hajda
Cc: Mauro Carvalho Chehab
Cc: Kees Cook
Reviewed-by: Mauro Carvalho Chehab (v5)
---
drivers/gpu/drm/i915/i915_user_extensions.c | 3 +-
drivers/gpu/drm/i915/i915_utils.h | 5 +-
include/linux/overflow.h| 62 +
3 files changed, 64 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_user_extensions.c
b/drivers/gpu/drm/i915/i915_user_extensions.c
index c822d0aafd2d..6f6b5b910968 100644
--- a/drivers/gpu/drm/i915/i915_user_extensions.c
+++ b/drivers/gpu/drm/i915/i915_user_extensions.c
@@ -50,8 +50,7 @@ int i915_user_extensions(struct i915_user_extension __user
*ext,
if (err)
return err;
- if (get_user(next, &ext->next_extension) ||
- overflows_type(next, ext))
+ if (get_user(next, &ext->next_extension) || overflows_ptr(next))
return -EFAULT;
ext = u64_to_user_ptr(next);
I continue to dislike the layers of macros and specialization here.
This is just a fancy version of check_assign():
if (get_user(next, &ext->next_extension) || check_assign(next, &ext))
return -EFAULT;
However, the __builtin_*_overflow() family only wants to work on
integral types, so this needs to be slightly expanded:
uintptr_t kptr;
...
if (get_user(next, &ext->next_extension) || check_assign(next, &kptr))
return -EFAULT;
ext = (void * __user)kptr;
But, it does seem like the actual problem here is that u64_to_user_ptr()
is not performing the checking? It's used heavily in the drm code.
Is a check_assign_user_ptr() needed?
Hi Kees,
Yes, the reason that an additional overflow check is performed when
assigning a pointer type is that no overflow check is provided when
using u64_to_user_ptr())
I also agree with the explicit overflow check when assigning to pointer
type variables.
I'll add check_assign_user_ptr() to the new version of the patch and use it.
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index c10d68cdc3ca..eb0ded23fa9c 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_X86
#include
@@ -111,10 +112,6 @@ bool i915_error_injected(void);
#define range_overflows_end_t(type, start, size, max) \
range_overflows_end((type)(start), (type)(size), (type)(max))
-/* Note we don't consider signbits :| */
-#define overflows_type(x, T) \
- (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T))
-
#define ptr_mask_bits(ptr, n) ({ \
unsigned long __v = (unsigned long)(ptr); \
(typeof(ptr))(__v & -BIT(n)); \
diff --git a/include/linux/overflow.h b/include/linux/overflow.h
index f1221d11f8e5..6af9df1d67a1 100644
--- a/include/linux/overflow.h
+++ b/include/linux/overflow.h
@@ -52,6 +52,68 @@ static inline bool __must_check __must_check_overflow(bool
overflow)
return unlikely(overflow);
}
+/**
+ * overflows_type - helper for checking the overflows between data types or
+ * values
+ *
+ * @x: Source value or data type for overflow check
+ * @T: Destination va
Re: [Intel-gfx] [PATCH v9 1/8] overflow: Move and add few utility macros into overflow
On 8/26/22 10:44 PM, Andrzej Hajda wrote:
On 25.08.2022 18:47, Kees Cook wrote:
On Wed, Aug 24, 2022 at 05:45:07PM +0900, Gwan-gyeong Mun wrote:
It moves overflows_type utility macro into overflow header from
i915_utils
header. The overflows_type can be used to catch the truncaion (overflow)
between different data types. And it adds check_assign() macro which
performs an assigning source value into destination ptr along with an
overflow check. overflow_type macro has been improved to handle the
signbit
by gcc's built-in overflow check function. And it adds overflows_ptr()
helper macro for checking the overflows between a value and a pointer
type/value.
v3: Add is_type_unsigned() macro (Mauro)
Modify overflows_type() macro to consider signed data types (Mauro)
Fix the problem that safe_conversion() macro always returns true
v4: Fix kernel-doc markups
v6: Move macro addition location so that it can be used by other than
drm
subsystem (Jani, Mauro, Andi)
Change is_type_unsigned to is_unsigned_type to have the same
name form
as is_signed_type macro
v8: Add check_assign() and remove safe_conversion() (Kees)
Fix overflows_type() to use gcc's built-in overflow function
(Andrzej)
Add overflows_ptr() to allow overflow checking when assigning a
value
into a pointer variable (G.G.)
v9: Fix overflows_type() to use __builtin_add_overflow() instead of
__builtin_add_overflow_p() (Andrzej)
Fix overflows_ptr() to use overflows_type() with the unsigned
long type
(Andrzej)
Signed-off-by: Gwan-gyeong Mun
Cc: Thomas Hellström
Cc: Matthew Auld
Cc: Nirmoy Das
Cc: Jani Nikula
Cc: Andi Shyti
Cc: Andrzej Hajda
Cc: Mauro Carvalho Chehab
Cc: Kees Cook
Reviewed-by: Mauro Carvalho Chehab (v5)
---
drivers/gpu/drm/i915/i915_user_extensions.c | 3 +-
drivers/gpu/drm/i915/i915_utils.h | 5 +-
include/linux/overflow.h | 62 +
3 files changed, 64 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_user_extensions.c
b/drivers/gpu/drm/i915/i915_user_extensions.c
index c822d0aafd2d..6f6b5b910968 100644
--- a/drivers/gpu/drm/i915/i915_user_extensions.c
+++ b/drivers/gpu/drm/i915/i915_user_extensions.c
@@ -50,8 +50,7 @@ int i915_user_extensions(struct i915_user_extension
__user *ext,
if (err)
return err;
- if (get_user(next, &ext->next_extension) ||
- overflows_type(next, ext))
+ if (get_user(next, &ext->next_extension) ||
overflows_ptr(next))
return -EFAULT;
ext = u64_to_user_ptr(next);
I continue to dislike the layers of macros and specialization here.
This is just a fancy version of check_assign():
if (get_user(next, &ext->next_extension) || check_assign(next, &ext))
return -EFAULT;
However, the __builtin_*_overflow() family only wants to work on
integral types, so this needs to be slightly expanded:
uintptr_t kptr;
...
if (get_user(next, &ext->next_extension) || check_assign(next,
&kptr))
return -EFAULT;
ext = (void * __user)kptr;
But, it does seem like the actual problem here is that u64_to_user_ptr()
is not performing the checking? It's used heavily in the drm code.
Is a check_assign_user_ptr() needed?
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index c10d68cdc3ca..eb0ded23fa9c 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_X86
#include
@@ -111,10 +112,6 @@ bool i915_error_injected(void);
#define range_overflows_end_t(type, start, size, max) \
range_overflows_end((type)(start), (type)(size), (type)(max))
-/* Note we don't consider signbits :| */
-#define overflows_type(x, T) \
- (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T))
-
#define ptr_mask_bits(ptr, n) ({ \
unsigned long __v = (unsigned long)(ptr); \
(typeof(ptr))(__v & -BIT(n)); \
diff --git a/include/linux/overflow.h b/include/linux/overflow.h
index f1221d11f8e5..6af9df1d67a1 100644
--- a/include/linux/overflow.h
+++ b/include/linux/overflow.h
@@ -52,6 +52,68 @@ static inline bool __must_check
__must_check_overflow(bool overflow)
return unlikely(overflow);
}
+/**
+ * overflows_type - helper for checking the overflows between data
types or
+ * values
+ *
+ * @x: Source value or data type for overflow check
+ * @T: Destination value or data type for overflow check
+ *
+ * It compares the values or data type between the first and second
argument to
+ * check whether overflow can occur when assigning the first
argument to the
+ * variable of the second argument. Source and Destination can be
singned or
+ * unsigned data types. Source and Destination can be different data
types.
+ *
+ * Returns:
+ * True if overflow can occur, false othe
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: fix kernel-doc issues (rev3)
== Series Details ==
Series: drm/i915: fix kernel-doc issues (rev3)
URL : https://patchwork.freedesktop.org/series/106224/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12104 -> Patchwork_106224v3
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_106224v3 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_106224v3, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106224v3/index.html
Participating hosts (39 -> 38)
--
Additional (1): bat-dg2-9
Missing(2): fi-rkl-11600 fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106224v3:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@migrate:
- fi-bdw-gvtdvm: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12104/fi-bdw-gvtdvm/igt@i915_selftest@l...@migrate.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106224v3/fi-bdw-gvtdvm/igt@i915_selftest@l...@migrate.html
Known issues
Here are the changes found in Patchwork_106224v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gem:
- fi-blb-e6850: NOTRUN -> [DMESG-FAIL][3] ([i915#4528])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106224v3/fi-blb-e6850/igt@i915_selftest@l...@gem.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[PASS][4] -> [DMESG-FAIL][5] ([i915#4528])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12104/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106224v3/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@i915_selftest@live@ring_submission:
- fi-cfl-8109u: [PASS][6] -> [DMESG-WARN][7] ([i915#5904]) +30
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12104/fi-cfl-8109u/igt@i915_selftest@live@ring_submission.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106224v3/fi-cfl-8109u/igt@i915_selftest@live@ring_submission.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-cfl-8109u: [PASS][8] -> [DMESG-WARN][9] ([i915#5904] / [i915#62])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12104/fi-cfl-8109u/igt@i915_susp...@basic-s2idle-without-i915.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106224v3/fi-cfl-8109u/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u: [PASS][10] -> [DMESG-FAIL][11] ([i915#62]) +1 similar
issue
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12104/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106224v3/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
* igt@prime_vgem@basic-fence-flip:
- fi-cfl-8109u: [PASS][12] -> [DMESG-WARN][13] ([i915#62]) +10
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12104/fi-cfl-8109u/igt@prime_v...@basic-fence-flip.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106224v3/fi-cfl-8109u/igt@prime_v...@basic-fence-flip.html
* igt@runner@aborted:
- fi-bdw-gvtdvm: NOTRUN -> [FAIL][14] ([i915#4312])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106224v3/fi-bdw-gvtdvm/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [DMESG-FAIL][15] ([i915#4528]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12104/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106224v3/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@i915_selftest@live@reset:
- {bat-rpls-1}: [DMESG-FAIL][17] ([i915#4983]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12104/bat-rpls-1/igt@i915_selftest@l...@reset.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106224v3/bat-rpls-1/igt@i915_selftest@l...@reset.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][19] ([i915#6298]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12104/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106224v3/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
Warnings
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5:
Re: [Intel-gfx] [PATCH v9 2/8] util_macros: Add exact_type macro to catch type mis-match while compiling
On 8/26/22 2:19 AM, Kees Cook wrote:
On Wed, Aug 24, 2022 at 05:45:08PM +0900, Gwan-gyeong Mun wrote:
It adds exact_type and exactly_pgoff_t macro to catch type mis-match while
compiling. The existing typecheck() macro outputs build warnings, but the
newly added exact_type() macro uses the BUILD_BUG_ON() macro to generate
a build break when the types are different and can be used to detect
explicit build errors.
v6: Move macro addition location so that it can be used by other than drm
subsystem (Jani, Mauro, Andi)
Signed-off-by: Gwan-gyeong Mun
Cc: Thomas Hellström
Cc: Matthew Auld
Cc: Nirmoy Das
Cc: Jani Nikula
Cc: Andi Shyti
Cc: Mauro Carvalho Chehab
---
include/linux/util_macros.h | 25 +
1 file changed, 25 insertions(+)
diff --git a/include/linux/util_macros.h b/include/linux/util_macros.h
index 72299f261b25..b6624b275257 100644
--- a/include/linux/util_macros.h
+++ b/include/linux/util_macros.h
@@ -2,6 +2,9 @@
#ifndef _LINUX_HELPER_MACROS_H_
#define _LINUX_HELPER_MACROS_H_
+#include
+#include
+
#define __find_closest(x, a, as, op) \
({\
typeof(as) __fc_i, __fc_as = (as) - 1; \
@@ -38,4 +41,26 @@
*/
#define find_closest_descending(x, a, as) __find_closest(x, a, as, >=)
+/**
+ * exact_type - break compile if source type and destination value's type are
+ * not the same
+ * @T: Source type
+ * @n: Destination value
+ *
+ * It is a helper macro for a poor man's -Wconversion: only allow variables of
+ * an exact type. It determines whether the source type and destination value's
+ * type are the same while compiling, and it breaks compile if two types are
+ * not the same
+ */
+#define exact_type(T, n) \
+ BUILD_BUG_ON(!__builtin_constant_p(n) &&
!__builtin_types_compatible_p(T, typeof(n)))
Maybe use __same_type() here instead of open-coded
__builtin_types_compatible_p()? Also, IIUC, currently coding style
advise is to use _Static_assert when possible over BUILD_BUG_ON for
error message readability.
This macro has a trap-door for literals, yes?
i.e. exact_type(pgoff_t, 5) will pass?
yes, I will update in detail comments about trap-door that may occur
when using constant value.
I also note that this is very close to the really common (and open-coded)
test scattered around the kernel already (BUILD_BUG_ON(__same_type(a,
b))), so I think it's good to get a macro defined for it, though I'm not
sure about the trap door test. Regardless, I'd like to bikeshed the name
a bit; I think this should be named something a bit more clear about
what happens on failure. Perhaps: assert_type()? Or to capture the
trapdoor idea, assert_typable()?
#define assert_type(t1, t2) _Static_assert(__same_type(t1, t2))
#define assert_typable(t, n)_Static_assert(__builtin_constant_p(n) ||
__same_type(t, typeof(n))
The form of the assert_type() / assert_typable() macros you suggested
looks better to me, so I will add these macros to the header where
__same_type() is defined and will send a new version of the patch.
many thanks
+
+/**
+ * exactly_pgoff_t - helper to check if the type of a value is pgoff_t
+ * @n: value to compare pgoff_t type
+ *
+ * It breaks compile if the argument value's type is not pgoff_t type.
+ */
+#define exactly_pgoff_t(n) exact_type(pgoff_t, n)
Why specialize this? Just use assert_typable(pgoff_t, n) in the other
patches? It's almost the same amount to write. :)
[Intel-gfx] [PATCH v10 0/9] Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation
This patch series fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation, etc. We need to check that we avoid integer overflows when looking up a page, and so fix all the instances where we have mistakenly used a plain integer instead of a more suitable long. And there is an impedance mismatch between the scatterlist API using unsigned int and our memory/page accounting in unsigned long. That is we may try to create a scatterlist for a large object that overflows returning a small table into which we try to fit very many pages. As the object size is under the control of userspace, we have to be prudent and catch the conversion errors. To catch the implicit truncation as we switch from unsigned long into the scatterlist's unsigned int, we use improved overflows_type check and report E2BIG prior to the operation. This is already used in our create ioctls to indicate if the uABI request is simply too large for the backing store. And ttm place also has the same problem with scatterlist creation, and we fix the integer truncation problem with the way approached by scatterlist creation. And It corrects the error code to return -E2BIG when creating gem objects using ttm or shmem, if the size is too large in each case. In order to provide a common macro, it moves and adds a few utility macros into overflow/compiler_types header. It introduces assert_type() assert_typable() macros to catch type mismatch while compiling. And it also introduces check_assign() and check_assign_user_ptr() macros to perform an assigning source value into the destination pointer along with an overflow check. In order to implemente check_assign(), overflows_type() on top of updated check_add_overflow() macro, this series include the patch which came from Kees [1] (this patch is under reviewing from other patch mail). [1] https://lore.kernel.org/all/202208311040.C6CA8253@keescook/ v10: Add check_assign_user_ptr() macro and drop overflows_ptr() macro(Kees) Use assert_typable instead of exactly_pgoff_t() macro (Kees) Remove a redundant type checking for a pointer. (Andrzej) Add patch "compiler_types.h: Add assert_type to catch type mis-match while compiling" and drop patch "util_macros: Add exact_type macro to catch type mis-match while compiling" from patch series (G.G.) (adding of assert_type(t1, t2) and assert_typable(t, n) were suggested by Kees v9's comments) v9: Fix overflows_type() to use __builtin_add_overflow() instead of __builtin_add_overflow_p() (Andrzej) Fix overflows_ptr() to use overflows_type() with the unsigned long type (Andrzej) v8: Add check_assign() and remove safe_conversion() (Kees) Replace safe_conversion() with check_assign() (Kees) Fix overflows_type() to use gcc's built-in overflow function (Andrzej) Add overflows_ptr() to allow overflow checking when assigning a value into a pointer variable (G.G.) v7: Fix to use WARN_ON() macro where GEM_BUG_ON() macro was used. (Jani) v6: Move macro addition location so that it can be used by other than drm subsystem (Jani, Mauro, Andi) Fix to follow general use case for GEM_BUG_ON(). (Jani) v5: Fix an alignment to match open parenthesis Fix macros to be enclosed in parentheses for complex values Fix too long line warning v4: Fix build warnins that reported by kernel test robot. (kernel test robot ) Add kernel-doc markups to the kAPI functions and macros (Mauoro) v3: Modify overflows_type() macro to consider signed data types and add is_type_unsigned() macro (Mauro) Make not use the same macro name on a function. (Mauro) For kernel-doc, macros and functions are handled in the same namespace, the same macro name on a function prevents ever adding documentation for it. Not to change execution inside a macro. (Mauro) Fix the problem that safe_conversion() macro always returns true (G.G) Add safe_conversion_gem_bug_on() macro and remove temporal SAFE_CONVERSION() macro. (G.G.) Chris Wilson (3): drm/i915/gem: Typecheck page lookups drm/i915: Check for integer truncation on scatterlist creation drm/i915: Remove truncation warning for large objects Gwan-gyeong Mun (5): overflow: Move and add few utility macros into overflow compiler_types.h: Add assert_type to catch type mis-match while compiling drm/i915: Check for integer truncation on the configuration of ttm place drm/i915: Check if the size is too big while creating shmem file drm/i915: Use error code as -E2BIG when the size of gem ttm object is too large Kees Cook (1): overflow: Allow mixed type arguments drivers/gpu/drm/i915/gem/i915_gem_internal.c | 6 +- drivers/gpu/drm/i915/gem/i915_gem_object.c| 7 +- drivers/gpu/drm/i915/gem/i915_gem_object.h| 303 +++--- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 27 +- drivers/gpu/drm/i915/gem/i915_gem_phys.c | 4 + drivers/gpu/drm/i915/gem/i915_ge
[Intel-gfx] [PATCH v10 4/9] drm/i915/gem: Typecheck page lookups
From: Chris Wilson
We need to check that we avoid integer overflows when looking up a page,
and so fix all the instances where we have mistakenly used a plain
integer instead of a more suitable long. Be pedantic and add integer
typechecking to the lookup so that we can be sure that we are safe.
And it also uses pgoff_t as our page lookups must remain compatible with
the page cache, pgoff_t is currently exactly unsigned long.
v2: Move added i915_utils's macro into drm_util header (Jani N)
v3: Make not use the same macro name on a function. (Mauro)
For kernel-doc, macros and functions are handled in the same namespace,
the same macro name on a function prevents ever adding documentation
for it.
v4: Add kernel-doc markups to the kAPI functions and macros (Mauoro)
v5: Fix an alignment to match open parenthesis
v6: Rebase
v10: Use assert_typable instead of exactly_pgoff_t() macro. (Kees)
Signed-off-by: Chris Wilson
Signed-off-by: Gwan-gyeong Mun
Cc: Tvrtko Ursulin
Cc: Matthew Auld
Cc: Thomas Hellström
Cc: Kees Cook
Reviewed-by: Nirmoy Das (v2)
Reviewed-by: Mauro Carvalho Chehab (v3)
Reviewed-by: Andrzej Hajda (v5)
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 7 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h| 293 --
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 27 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 12 +-
.../drm/i915/gem/selftests/i915_gem_mman.c| 8 +-
.../drm/i915/gem/selftests/i915_gem_object.c | 8 +-
drivers/gpu/drm/i915/i915_gem.c | 18 +-
drivers/gpu/drm/i915/i915_utils.h | 1 +
drivers/gpu/drm/i915/i915_vma.c | 8 +-
10 files changed, 323 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 85482a04d158..22a8c10eccec 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -413,10 +413,11 @@ void __i915_gem_object_invalidate_frontbuffer(struct
drm_i915_gem_object *obj,
static void
i915_gem_object_read_from_page_kmap(struct drm_i915_gem_object *obj, u64
offset, void *dst, int size)
{
+ pgoff_t idx = offset >> PAGE_SHIFT;
void *src_map;
void *src_ptr;
- src_map = kmap_atomic(i915_gem_object_get_page(obj, offset >>
PAGE_SHIFT));
+ src_map = kmap_atomic(i915_gem_object_get_page(obj, idx));
src_ptr = src_map + offset_in_page(offset);
if (!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_READ))
@@ -429,9 +430,10 @@ i915_gem_object_read_from_page_kmap(struct
drm_i915_gem_object *obj, u64 offset,
static void
i915_gem_object_read_from_page_iomap(struct drm_i915_gem_object *obj, u64
offset, void *dst, int size)
{
+ pgoff_t idx = offset >> PAGE_SHIFT;
+ dma_addr_t dma = i915_gem_object_get_dma_address(obj, idx);
void __iomem *src_map;
void __iomem *src_ptr;
- dma_addr_t dma = i915_gem_object_get_dma_address(obj, offset >>
PAGE_SHIFT);
src_map = io_mapping_map_wc(&obj->mm.region->iomap,
dma - obj->mm.region->region.start,
@@ -460,6 +462,7 @@ i915_gem_object_read_from_page_iomap(struct
drm_i915_gem_object *obj, u64 offset
*/
int i915_gem_object_read_from_page(struct drm_i915_gem_object *obj, u64
offset, void *dst, int size)
{
+ GEM_BUG_ON(overflows_type(offset >> PAGE_SHIFT, pgoff_t));
GEM_BUG_ON(offset >= obj->base.size);
GEM_BUG_ON(offset_in_page(offset) > PAGE_SIZE - size);
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 7317d4102955..8dd2b84468c8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -27,8 +27,10 @@ enum intel_region_id;
* spot such a local variable, please consider fixing!
*
* Aside from our own locals (for which we have no excuse!):
- * - sg_table embeds unsigned int for num_pages
- * - get_user_pages*() mixed ints with longs
+ * - sg_table embeds unsigned int for nents
+ *
+ * We can check for invalidly typed locals with typecheck(), see for example
+ * i915_gem_object_get_sg().
*/
#define GEM_CHECK_SIZE_OVERFLOW(sz) \
GEM_WARN_ON((sz) >> PAGE_SHIFT > INT_MAX)
@@ -363,44 +365,289 @@ i915_gem_object_get_tile_row_size(const struct
drm_i915_gem_object *obj)
int i915_gem_object_set_tiling(struct drm_i915_gem_object *obj,
unsigned int tiling, unsigned int stride);
+/**
+ * __i915_gem_object_page_iter_get_sg - helper to find the target scatterlist
+ * pointer and the target page position using pgoff_t n input argument and
+ * i915_gem_object_page_iter
+ * @obj: i915 GEM buffer object
+ * @iter: i915 GEM buffer object page iterator
+ * @n: page offset
+ * @offset: searched physical offset,
[Intel-gfx] [PATCH v10 2/9] overflow: Move and add few utility macros into overflow
It moves overflows_type utility macro into overflow header from i915_utils
header. The overflows_type can be used to catch the truncaion (overflow)
between different data types. And it adds check_assign() macro which
performs an assigning source value into destination pointer along with an
overflow check. overflow_type macro has been improved to handle the
different data types between source and destination by check_add_overflow
macro. It also adds check_assign_user_ptr macro which performs an assigning
source value into destination pointer type variable along with an overflow
check. If an explicit overflow check is required while assigning,
check_assign_user_ptr() can be used to assign integers into pointers along
with an overflow check.
v3: Add is_type_unsigned() macro (Mauro)
Modify overflows_type() macro to consider signed data types (Mauro)
Fix the problem that safe_conversion() macro always returns true
v4: Fix kernel-doc markups
v6: Move macro addition location so that it can be used by other than drm
subsystem (Jani, Mauro, Andi)
Change is_type_unsigned to is_unsigned_type to have the same name form
as is_signed_type macro
v8: Add check_assign() and remove safe_conversion() (Kees)
Fix overflows_type() to use gcc's built-in overflow function (Andrzej)
Add overflows_ptr() to allow overflow checking when assigning a value
into a pointer variable (G.G.)
v9: Fix overflows_type() to use __builtin_add_overflow() instead of
__builtin_add_overflow_p() (Andrzej)
Fix overflows_ptr() to use overflows_type() with the unsigned long type
(Andrzej)
v10: Remove a redundant type checking for a pointer. (Andrzej)
Use updated check_add_overflow macro instead of __builtin_add_overflow
(G.G)
Add check_assign_user_ptr() macro and drop overflows_ptr() macro(Kees)
Signed-off-by: Gwan-gyeong Mun
Cc: Thomas Hellström
Cc: Matthew Auld
Cc: Nirmoy Das
Cc: Jani Nikula
Cc: Andi Shyti
Cc: Andrzej Hajda
Cc: Mauro Carvalho Chehab
Cc: Kees Cook
Reviewed-by: Mauro Carvalho Chehab (v5)
Reviewed-by: Andrzej Hajda (v9)
---
drivers/gpu/drm/i915/i915_user_extensions.c | 6 +-
drivers/gpu/drm/i915/i915_utils.h | 5 +-
include/linux/overflow.h| 64 +
3 files changed, 68 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_user_extensions.c
b/drivers/gpu/drm/i915/i915_user_extensions.c
index c822d0aafd2d..80ec8390b0d8 100644
--- a/drivers/gpu/drm/i915/i915_user_extensions.c
+++ b/drivers/gpu/drm/i915/i915_user_extensions.c
@@ -50,11 +50,11 @@ int i915_user_extensions(struct i915_user_extension __user
*ext,
if (err)
return err;
- if (get_user(next, &ext->next_extension) ||
- overflows_type(next, ext))
+ if (get_user(next, &ext->next_extension))
return -EFAULT;
- ext = u64_to_user_ptr(next);
+ if (check_assign_user_ptr(next, ext))
+ return -EFAULT;
}
return 0;
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index 6c14d13364bf..efd3d69b78f7 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_X86
#include
@@ -111,10 +112,6 @@ bool i915_error_injected(void);
#define range_overflows_end_t(type, start, size, max) \
range_overflows_end((type)(start), (type)(size), (type)(max))
-/* Note we don't consider signbits :| */
-#define overflows_type(x, T) \
- (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T))
-
#define ptr_mask_bits(ptr, n) ({ \
unsigned long __v = (unsigned long)(ptr); \
(typeof(ptr))(__v & -BIT(n)); \
diff --git a/include/linux/overflow.h b/include/linux/overflow.h
index 19dfdd74835e..9e8fc8f03e7a 100644
--- a/include/linux/overflow.h
+++ b/include/linux/overflow.h
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
/*
* We need to compute the minimum and maximum values representable in a given
@@ -127,6 +128,69 @@ static inline bool __must_check __must_check_overflow(bool
overflow)
(*_d >> _to_shift) != _a); \
}))
+/**
+ * check_assign - perform an assigning source value into destination pointer
+ *along with an overflow check.
+ *
+ * @value: source value
+ * @ptr: Destination pointer address
+ *
+ * Returns:
+ * If the value would overflow the destination, it returns true. If not return
+ * false. When overflow does not occur, the assigning into destination from
+ * value succeeds. It follows the return policy as other check_*_overflow()
+ * functions return non-zero as a failure.
+ */
+#define check_assign(value, ptr) __must_check_overflow(({ \
+ check_a
[Intel-gfx] [PATCH v10 1/9] overflow: Allow mixed type arguments
From: Kees Cook
When the check_[op]_overflow() helpers were introduced, all arguments were
required to be the same type to make the fallback macros simpler. However,
now that the fallback macros have been removed[1], it is fine to allow
mixed types, which makes using the helpers much more useful, as they
can be used to test for type-based overflows (e.g. adding two large ints
but storing into a u8), as would be handy in the drm core[2].
Remove the restriction, and add additional self-tests that exercise some
of the mixed-type overflow cases, and double-check for accidental macro
side-effects.
[1] https://git.kernel.org/linus/4eb6bd55cfb22ffc20652732340c4962f3ac9a91
[2]
https://lore.kernel.org/lkml/20220824084514.2261614-2-gwan-gyeong@intel.com
Cc: Rasmus Villemoes
Cc: Gwan-gyeong Mun
Cc: Andrzej Hajda
Cc: "Gustavo A. R. Silva"
Cc: Nick Desaulniers
Cc: linux-harden...@vger.kernel.org
Signed-off-by: Kees Cook
---
include/linux/overflow.h | 72
lib/overflow_kunit.c | 101 ---
2 files changed, 113 insertions(+), 60 deletions(-)
diff --git a/include/linux/overflow.h b/include/linux/overflow.h
index 0eb3b192f07a..19dfdd74835e 100644
--- a/include/linux/overflow.h
+++ b/include/linux/overflow.h
@@ -51,40 +51,50 @@ static inline bool __must_check __must_check_overflow(bool
overflow)
return unlikely(overflow);
}
-/*
- * For simplicity and code hygiene, the fallback code below insists on
- * a, b and *d having the same type (similar to the min() and max()
- * macros), whereas gcc's type-generic overflow checkers accept
- * different types. Hence we don't just make check_add_overflow an
- * alias for __builtin_add_overflow, but add type checks similar to
- * below.
+/** check_add_overflow() - Calculate addition with overflow checking
+ *
+ * @a: first addend
+ * @b: second addend
+ * @d: pointer to store sum
+ *
+ * Returns 0 on success.
+ *
+ * *@d holds the results of the attempted addition, but is not considered
+ * "safe for use" on a non-zero return value, which indicates that the
+ * sum has overflowed or been truncated.
*/
-#define check_add_overflow(a, b, d) __must_check_overflow(({ \
- typeof(a) __a = (a);\
- typeof(b) __b = (b);\
- typeof(d) __d = (d);\
- (void) (&__a == &__b); \
- (void) (&__a == __d); \
- __builtin_add_overflow(__a, __b, __d); \
-}))
+#define check_add_overflow(a, b, d)\
+ __must_check_overflow(__builtin_add_overflow(a, b, d))
-#define check_sub_overflow(a, b, d) __must_check_overflow(({ \
- typeof(a) __a = (a);\
- typeof(b) __b = (b);\
- typeof(d) __d = (d);\
- (void) (&__a == &__b); \
- (void) (&__a == __d); \
- __builtin_sub_overflow(__a, __b, __d); \
-}))
+/** check_sub_overflow() - Calculate subtraction with overflow checking
+ *
+ * @a: minuend; value to subtract from
+ * @b: subtrahend; value to subtract from @a
+ * @d: pointer to store difference
+ *
+ * Returns 0 on success.
+ *
+ * *@d holds the results of the attempted subtraction, but is not considered
+ * "safe for use" on a non-zero return value, which indicates that the
+ * difference has underflowed or been truncated.
+ */
+#define check_sub_overflow(a, b, d)\
+ __must_check_overflow(__builtin_sub_overflow(a, b, d))
-#define check_mul_overflow(a, b, d) __must_check_overflow(({ \
- typeof(a) __a = (a);\
- typeof(b) __b = (b);\
- typeof(d) __d = (d);\
- (void) (&__a == &__b); \
- (void) (&__a == __d); \
- __builtin_mul_overflow(__a, __b, __d); \
-}))
+/** check_mul_overflow() - Calculate multiplication with overflow checking
+ *
+ * @a: first factor
+ * @b: second factor
+ * @d: pointer to store product
+ *
+ * Returns 0 on success.
+ *
+ * *@d holds the results of the attempted multiplication, but is not
+ * considered "safe for use" on a non-zero return value, which indicates
+ * that the product has overflowed or been truncated.
+ */
+#define check_mul_overflow(a, b, d)\
+ __must_check_overflow(__builtin_mul_overflow(a, b, d))
/** check_shl_overflow() - Calculate a left-shifted value and check overflow
*
diff --git a/lib/overflow_kunit.c b/lib/overflow_kunit.c
index 7e3e43679b73..0d98c9bc75da 100644
--- a/lib/overflow_kunit.c
+++ b/lib/overflow_kunit.c
@@ -16,12 +16,15 @@
#include
#include
-#define DEFINE_TEST_ARRAY(t) \
- static const struct test_ ## t {\
- t a, b; \
- t sum, diff, prod; \
- bool s_of, d_of, p_of; \
- } t ## _tests[]
+#define DEFINE_TEST_ARRA
[Intel-gfx] [PATCH v10 3/9] compiler_types.h: Add assert_type to catch type mis-match while compiling
It adds assert_type and assert_typable macros to catch type mis-match while
compiling. The existing typecheck() macro outputs build warnings, but the
newly added assert_type() macro uses the _Static_assert() keyword (which is
introduced in C11) to generate a build break when the types are different
and can be used to detect explicit build errors.
Unlike the assert_type() macro, assert_typable() macro allows a constant
value as the second argument.
Suggested-by: Kees Cook
Signed-off-by: Gwan-gyeong Mun
Cc: Thomas Hellström
Cc: Matthew Auld
Cc: Nirmoy Das
Cc: Jani Nikula
Cc: Andi Shyti
Cc: Mauro Carvalho Chehab
Cc: Andrzej Hajda
Cc: Kees Cook
---
include/linux/compiler_types.h | 39 ++
1 file changed, 39 insertions(+)
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 4f2a819fd60a..19cc125918bb 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -294,6 +294,45 @@ struct ftrace_likely_data {
/* Are two types/vars the same type (ignoring qualifiers)? */
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
+/**
+ * assert_type - break compile if the first argument's data type and the second
+ * argument's data type are not the same
+ *
+ * @t1: data type or variable
+ * @t2: data type or variable
+ *
+ * The first and second arguments can be data types or variables or mixed (the
+ * first argument is the data type and the second argument is variable or vice
+ * versa). It determines whether the first argument's data type and the second
+ * argument's data type are the same while compiling, and it breaks compile if
+ * the two types are not the same.
+ * See also assert_typable().
+ */
+#define assert_type(t1, t2) _Static_assert(__same_type(t1, t2))
+
+/**
+ * assert_typable - break compile if the first argument's data type and the
+ * second argument's data type are not the same
+ *
+ * @t: data type or variable
+ * @n: data type or variable or constant value
+ *
+ * The first and second arguments can be data types or variables or mixed (the
+ * first argument is the data type and the second argument is variable or vice
+ * versa). Unlike the assert_type() macro, this macro allows a constant value
+ * as the second argument. And if the second argument is a constant value, it
+ * always passes. And it doesn't mean that the types are explicitly the same.
+ * When a constant value is used as the second argument, if you need an
+ * overflow check when assigning a constant value to a variable of the type of
+ * the first argument, you can use the overflows_type() macro. When a constant
+ * value is not used as a second argument, it determines whether the first
+ * argument's data type and the second argument's data type are the same while
+ * compiling, and it breaks compile if the two types are not the same.
+ * See also assert_type() and overflows_type().
+ */
+#define assert_typable(t, n) _Static_assert(__builtin_constant_p(n) || \
+ __same_type(t, typeof(n)))
+
/*
* __unqual_scalar_typeof(x) - Declare an unqualified scalar type, leaving
*non-scalar types unchanged.
--
2.37.1
[Intel-gfx] [PATCH v10 5/9] drm/i915: Check for integer truncation on scatterlist creation
From: Chris Wilson
There is an impedance mismatch between the scatterlist API using unsigned
int and our memory/page accounting in unsigned long. That is we may try
to create a scatterlist for a large object that overflows returning a
small table into which we try to fit very many pages. As the object size
is under control of userspace, we have to be prudent and catch the
conversion errors.
To catch the implicit truncation as we switch from unsigned long into the
scatterlist's unsigned int, we use overflows_type check and report
E2BIG prior to the operation. This is already used in our create ioctls to
indicate if the uABI request is simply too large for the backing store.
Failing that type check, we have a second check at sg_alloc_table time
to make sure the values we are passing into the scatterlist API are not
truncated.
It uses pgoff_t for locals that are dealing with page indices, in this
case, the page count is the limit of the page index.
And it uses safe_conversion() macro which performs a type conversion (cast)
of an integer value into a new variable, checking that the destination is
large enough to hold the source value.
v2: Move added i915_utils's macro into drm_util header (Jani N)
v5: Fix macros to be enclosed in parentheses for complex values
Fix too long line warning
v8: Replace safe_conversion() with check_assign() (Kees)
Signed-off-by: Chris Wilson
Signed-off-by: Gwan-gyeong Mun
Cc: Tvrtko Ursulin
Cc: Brian Welty
Cc: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Nirmoy Das
Reviewed-by: Mauro Carvalho Chehab
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 6 --
drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 ---
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 4
drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 5 -
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 4
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 5 -
drivers/gpu/drm/i915/gvt/dmabuf.c| 9 +
drivers/gpu/drm/i915/i915_scatterlist.h | 11 +++
8 files changed, 36 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index c698f95af15f..53fa27e1c950 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -37,10 +37,13 @@ static int i915_gem_object_get_pages_internal(struct
drm_i915_gem_object *obj)
struct sg_table *st;
struct scatterlist *sg;
unsigned int sg_page_sizes;
- unsigned int npages;
+ pgoff_t npages; /* restricted by sg_alloc_table */
int max_order;
gfp_t gfp;
+ if (check_assign(obj->base.size >> PAGE_SHIFT, &npages))
+ return -E2BIG;
+
max_order = MAX_ORDER;
#ifdef CONFIG_SWIOTLB
if (is_swiotlb_active(obj->base.dev->dev)) {
@@ -67,7 +70,6 @@ static int i915_gem_object_get_pages_internal(struct
drm_i915_gem_object *obj)
if (!st)
return -ENOMEM;
- npages = obj->base.size / PAGE_SIZE;
if (sg_alloc_table(st, npages, GFP_KERNEL)) {
kfree(st);
return -ENOMEM;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 8dd2b84468c8..a64fe73c05b5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -26,9 +26,6 @@ enum intel_region_id;
* this and catch if we ever need to fix it. In the meantime, if you do
* spot such a local variable, please consider fixing!
*
- * Aside from our own locals (for which we have no excuse!):
- * - sg_table embeds unsigned int for nents
- *
* We can check for invalidly typed locals with typecheck(), see for example
* i915_gem_object_get_sg().
*/
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
index 0d0e46dae559..88ba7266a3a5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
@@ -28,6 +28,10 @@ static int i915_gem_object_get_pages_phys(struct
drm_i915_gem_object *obj)
void *dst;
int i;
+ /* Contiguous chunk, with a single scatterlist element */
+ if (overflows_type(obj->base.size, sg->length))
+ return -E2BIG;
+
if (GEM_WARN_ON(i915_gem_object_needs_bit17_swizzle(obj)))
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index f42ca1179f37..339b0a9cf2d0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -193,13 +193,16 @@ static int shmem_get_pages(struct drm_i915_gem_object
*obj)
struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct intel_memory_region *mem = obj->mm.region;
struct address_space *mapping = obj->base.filp->f_mapping;
- const unsigned long p
[Intel-gfx] [PATCH v10 7/9] drm/i915: Check if the size is too big while creating shmem file
The __shmem_file_setup() function returns -EINVAL if size is greater than MAX_LFS_FILESIZE. To handle the same error as other code that returns -E2BIG when the size is too large, it add a code that returns -E2BIG when the size is larger than the size that can be handled. v4: If BITS_PER_LONG is 32, size > MAX_LFS_FILESIZE is always false, so it checks only when BITS_PER_LONG is 64. Signed-off-by: Gwan-gyeong Mun Cc: Chris Wilson Cc: Matthew Auld Cc: Thomas Hellström Reviewed-by: Nirmoy Das Reviewed-by: Mauro Carvalho Chehab Reported-by: kernel test robot Reviewed-by: Andrzej Hajda --- drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c index 339b0a9cf2d0..ca30060e34ab 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c @@ -541,6 +541,20 @@ static int __create_shmem(struct drm_i915_private *i915, drm_gem_private_object_init(&i915->drm, obj, size); + /* XXX: The __shmem_file_setup() function returns -EINVAL if size is +* greater than MAX_LFS_FILESIZE. +* To handle the same error as other code that returns -E2BIG when +* the size is too large, we add a code that returns -E2BIG when the +* size is larger than the size that can be handled. +* If BITS_PER_LONG is 32, size > MAX_LFS_FILESIZE is always false, +* so we only needs to check when BITS_PER_LONG is 64. +* If BITS_PER_LONG is 32, E2BIG checks are processed when +* i915_gem_object_size_2big() is called before init_object() callback +* is called. +*/ + if (BITS_PER_LONG == 64 && size > MAX_LFS_FILESIZE) + return -E2BIG; + if (i915->mm.gemfs) filp = shmem_file_setup_with_mnt(i915->mm.gemfs, "i915", size, flags); -- 2.37.1
[Intel-gfx] [PATCH v10 9/9] drm/i915: Remove truncation warning for large objects
From: Chris Wilson
Having addressed the issues surrounding incorrect types for local
variables and potential integer truncation in using the scatterlist API,
we have closed all the loop holes we had previously identified with
dangerously large object creation. As such, we can eliminate the warning
put in place to remind us to complete the review.
Signed-off-by: Chris Wilson
Signed-off-by: Gwan-gyeong Mun
Cc: Tvrtko Ursulin
Cc: Brian Welty
Cc: Matthew Auld
Cc: Thomas Hellström
Testcase: igt@gem_create@create-massive
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4991
Reviewed-by: Nirmoy Das
Reviewed-by: Mauro Carvalho Chehab
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index a64fe73c05b5..ad88ab88b828 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -20,25 +20,10 @@
enum intel_region_id;
-/*
- * XXX: There is a prevalence of the assumption that we fit the
- * object's page count inside a 32bit _signed_ variable. Let's document
- * this and catch if we ever need to fix it. In the meantime, if you do
- * spot such a local variable, please consider fixing!
- *
- * We can check for invalidly typed locals with typecheck(), see for example
- * i915_gem_object_get_sg().
- */
-#define GEM_CHECK_SIZE_OVERFLOW(sz) \
- GEM_WARN_ON((sz) >> PAGE_SHIFT > INT_MAX)
-
static inline bool i915_gem_object_size_2big(u64 size)
{
struct drm_i915_gem_object *obj;
- if (GEM_CHECK_SIZE_OVERFLOW(size))
- return true;
-
if (overflows_type(size, obj->base.size))
return true;
--
2.37.1
[Intel-gfx] [PATCH v10 6/9] drm/i915: Check for integer truncation on the configuration of ttm place
There is an impedance mismatch between the first/last valid page
frame number of ttm place in unsigned and our memory/page accounting in
unsigned long.
As the object size is under the control of userspace, we have to be prudent
and catch the conversion errors.
To catch the implicit truncation as we switch from unsigned long to
unsigned, we use overflows_type check and report E2BIG or overflow_type
prior to the operation.
v3: Not to change execution inside a macro. (Mauro)
Add safe_conversion_gem_bug_on() macro and remove temporal
SAFE_CONVERSION() macro.
v4: Fix unhandled GEM_BUG_ON() macro call from safe_conversion_gem_bug_on()
v6: Fix to follow general use case for GEM_BUG_ON(). (Jani)
v7: Fix to use WARN_ON() macro where GEM_BUG_ON() macro was used. (Jani)
v8: Replace safe_conversion() with check_assign() (Kees)
Signed-off-by: Gwan-gyeong Mun
Cc: Chris Wilson
Cc: Matthew Auld
Cc: Thomas Hellström
Cc: Jani Nikula
Reviewed-by: Nirmoy Das (v2)
Reviewed-by: Mauro Carvalho Chehab (v3)
Reported-by: kernel test robot
Reviewed-by: Andrzej Hajda (v5)
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 6 +++---
drivers/gpu/drm/i915/intel_region_ttm.c | 17 ++---
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 06a2e80a5702..6956d273fa5f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -140,14 +140,14 @@ i915_ttm_place_from_region(const struct
intel_memory_region *mr,
if (flags & I915_BO_ALLOC_CONTIGUOUS)
place->flags |= TTM_PL_FLAG_CONTIGUOUS;
if (offset != I915_BO_INVALID_OFFSET) {
- place->fpfn = offset >> PAGE_SHIFT;
- place->lpfn = place->fpfn + (size >> PAGE_SHIFT);
+ WARN_ON(check_assign(offset >> PAGE_SHIFT, &place->fpfn));
+ WARN_ON(check_assign(place->fpfn + (size >> PAGE_SHIFT),
&place->lpfn));
} else if (mr->io_size && mr->io_size < mr->total) {
if (flags & I915_BO_ALLOC_GPU_ONLY) {
place->flags |= TTM_PL_FLAG_TOPDOWN;
} else {
place->fpfn = 0;
- place->lpfn = mr->io_size >> PAGE_SHIFT;
+ WARN_ON(check_assign(mr->io_size >> PAGE_SHIFT,
&place->lpfn));
}
}
}
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 575d67bc6ffe..37a964b20b36 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -209,14 +209,23 @@ intel_region_ttm_resource_alloc(struct
intel_memory_region *mem,
if (flags & I915_BO_ALLOC_CONTIGUOUS)
place.flags |= TTM_PL_FLAG_CONTIGUOUS;
if (offset != I915_BO_INVALID_OFFSET) {
- place.fpfn = offset >> PAGE_SHIFT;
- place.lpfn = place.fpfn + (size >> PAGE_SHIFT);
+ if (WARN_ON(check_assign(offset >> PAGE_SHIFT, &place.fpfn))) {
+ ret = -E2BIG;
+ goto out;
+ }
+ if (WARN_ON(check_assign(place.fpfn + (size >> PAGE_SHIFT),
&place.lpfn))) {
+ ret = -E2BIG;
+ goto out;
+ }
} else if (mem->io_size && mem->io_size < mem->total) {
if (flags & I915_BO_ALLOC_GPU_ONLY) {
place.flags |= TTM_PL_FLAG_TOPDOWN;
} else {
place.fpfn = 0;
- place.lpfn = mem->io_size >> PAGE_SHIFT;
+ if (WARN_ON(check_assign(mem->io_size >> PAGE_SHIFT,
&place.lpfn))) {
+ ret = -E2BIG;
+ goto out;
+ }
}
}
@@ -224,6 +233,8 @@ intel_region_ttm_resource_alloc(struct intel_memory_region
*mem,
mock_bo.bdev = &mem->i915->bdev;
ret = man->func->alloc(man, &mock_bo, &place, &res);
+
+out:
if (ret == -ENOSPC)
ret = -ENXIO;
if (!ret)
--
2.37.1
[Intel-gfx] [PATCH v10 8/9] drm/i915: Use error code as -E2BIG when the size of gem ttm object is too large
The ttm_bo_init_reserved() functions returns -ENOSPC if the size is too big to add vma. The direct function that returns -ENOSPC is drm_mm_insert_node_in_range(). To handle the same error as other code returning -E2BIG when the size is too large, it converts return value to -E2BIG. Signed-off-by: Gwan-gyeong Mun Cc: Chris Wilson Cc: Matthew Auld Cc: Thomas Hellström Reviewed-by: Nirmoy Das Reviewed-by: Mauro Carvalho Chehab Reviewed-by: Andrzej Hajda --- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c index 6956d273fa5f..955635ae5982 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c @@ -1210,6 +1210,17 @@ int __i915_gem_ttm_object_init(struct intel_memory_region *mem, ret = ttm_bo_init_reserved(&i915->bdev, i915_gem_to_ttm(obj), bo_type, &i915_sys_placement, page_size >> PAGE_SHIFT, &ctx, NULL, NULL, i915_ttm_bo_destroy); + + /* +* XXX: The ttm_bo_init_reserved() functions returns -ENOSPC if the size +* is too big to add vma. The direct function that returns -ENOSPC is +* drm_mm_insert_node_in_range(). To handle the same error as other code +* that returns -E2BIG when the size is too large, it converts -ENOSPC to +* -E2BIG. +*/ + if (size >> PAGE_SHIFT > INT_MAX && ret == -ENOSPC) + ret = -E2BIG; + if (ret) return i915_ttm_err_to_gem(ret); -- 2.37.1
[Intel-gfx] [PULL] drm-intel-gt-next
Hi Dave & Daniel, Here goes second drm-intel-gt-next PR towards 6.1. As the top item we're now aligning the GuC/HuC firmware versioning to meet the expectations recorded under firmware-usage-guidelines.rst. A revert of a previous (incorrect) userspace register removal for DG2 and addition of new DG2 workaround. Reject suspend on DG2 on low system memory condition. Fix for Gitlab #6639 h264 hardware video decoding regression, GuC SLPC improvements, PXP fix, ATS-M thread tuning settings and tiny bit of Meteorlake enabling, Regards, Joonas PS. Still not the top of drm-intel-gt-next as need your comments on fixing(?) the Acked-by's on the MEI/GSC patches. *** drm-intel-gt-next-2022-09-09: UAPI Changes: - Revert "drm/i915/dg2: Add preemption changes for Wa_14015141709" The intent of Wa_14015141709 was to inform us that userspace can no longer control object-level preemption as it has on past platforms (i.e., by twiddling register bit CS_CHICKEN1[0]). The description of the workaround in the spec wasn't terribly well-written, and when we requested clarification from the hardware teams we were told that on the kernel side we should also probably stop setting FF_SLICE_CS_CHICKEN1[14], which is the register bit that directs the hardware to honor the settings in per-context register CS_CHICKEN1. It turns out that this guidance about FF_SLICE_CS_CHICKEN1[14] was a mistake; even though CS_CHICKEN1[0] is non-operational and useless to userspace, there are other bits in the register that do still work and might need to be adjusted by userspace in the future (e.g., to implement other workarounds that show up). If we don't set FF_SLICE_CS_CHICKEN1[14] in i915, then those future workarounds would not take effect. Even more details at: https://lists.freedesktop.org/archives/intel-gfx/2022-September/305478.html Driver Changes: - Align GuC/HuC firmware versioning scheme to kernel practices (John) - Fix #6639: h264 hardware video decoding broken in 5.19 on Intel(R) Celeron(R) N3060 (Nirmoy) - Meteorlake (MTL) enabling (Matt R) - GuC SLPC improvements (Vinay, Rodrigo) - Add thread execution tuning setting for ATS-M (Matt R) - Don't start PXP without mei_pxp bind (Juston) - Remove leftover verbose debug logging from GuC error capture (John) - Abort suspend on low system memory conditions (Nirmoy, Matt A, Chris) - Add DG2 Wa_16014892111 (Matt R) - Rename ggtt_view as gtt_view (Niranjana) - Consider HAS_FLAT_CCS() in needs_ccs_pages (Matt A) - Don't try to disable host RPS when this was never enabled. (Rodrigo) - Clear stalled GuC CT request after a reset (Daniele) - Remove runtime info printing from GuC time stamp logging (Jani) - Skip Bit12 fw domain reset for gen12+ (Sushma, Radhakrishna) - Make GuC log sizes runtime configurable (John) - Selftest improvements (Daniele, Matt B, Andrzej) The following changes since commit 5ece208ab05e4042c80ed1e6fe6d7ce236eee89b: drm/i915/guc: Use streaming loads to speed up dumping the guc log (2022-08-17 10:07:03 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2022-09-09 for you to fetch changes up to 04f7eb3d4582a0a4da67c86e55fda7de2df86d91: drm/i915: Set correct domains values at _i915_vma_move_to_active (2022-09-08 11:06:35 +0100) UAPI Changes: - Revert "drm/i915/dg2: Add preemption changes for Wa_14015141709" The intent of Wa_14015141709 was to inform us that userspace can no longer control object-level preemption as it has on past platforms (i.e., by twiddling register bit CS_CHICKEN1[0]). The description of the workaround in the spec wasn't terribly well-written, and when we requested clarification from the hardware teams we were told that on the kernel side we should also probably stop setting FF_SLICE_CS_CHICKEN1[14], which is the register bit that directs the hardware to honor the settings in per-context register CS_CHICKEN1. It turns out that this guidance about FF_SLICE_CS_CHICKEN1[14] was a mistake; even though CS_CHICKEN1[0] is non-operational and useless to userspace, there are other bits in the register that do still work and might need to be adjusted by userspace in the future (e.g., to implement other workarounds that show up). If we don't set FF_SLICE_CS_CHICKEN1[14] in i915, then those future workarounds would not take effect. Even more details at: https://lists.freedesktop.org/archives/intel-gfx/2022-September/305478.html Driver Changes: - Align GuC/HuC firmware versioning scheme to kernel practices (John) - Fix #6639: h264 hardware video decoding broken in 5.19 on Intel(R) Celeron(R) N3060 (Nirmoy) - Meteorlake (MTL) enabling (Matt R) - GuC SLPC improvements (Vinay, Rodrigo) - Add thread execution tuning setting for ATS-M (Matt R) - Don't start PXP without mei_pxp bind (Juston) - Remove leftover verbose debug logging from GuC erro
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation
== Series Details == Series: Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation URL : https://patchwork.freedesktop.org/series/108358/ State : failure == Summary == Error: make failed CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/intel_memory_region.o In file included from : drivers/gpu/drm/i915/selftests/intel_memory_region.c: In function ‘igt_lmem_create_with_ps’: ././include/linux/compiler_types.h:334:35: error: expected ‘,’ before ‘)’ token __same_type(t, typeof(n))) ^ ./drivers/gpu/drm/i915/gem/i915_gem_object.h:630:2: note: in expansion of macro ‘assert_typable’ assert_typable(pgoff_t, n); \ ^~ drivers/gpu/drm/i915/selftests/intel_memory_region.c:851:11: note: in expansion of macro ‘i915_gem_object_get_dma_address’ daddr = i915_gem_object_get_dma_address(obj, 0); ^~~ scripts/Makefile.build:249: recipe for target 'drivers/gpu/drm/i915/intel_memory_region.o' failed make[4]: *** [drivers/gpu/drm/i915/intel_memory_region.o] Error 1 scripts/Makefile.build:465: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:465: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:465: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1853: recipe for target 'drivers' failed make: *** [drivers] Error 2
[Intel-gfx] [PATCH v3 0/2] DGFX mmap with rpm
As per PCIe Spec Section 5.3.1.4.1 When pcie function is in d3hot state, Configuration and Message requests are the only TLPs accepted by a Function in the D3hot state. All other received Requests must be handled as Unsupported Requests, and all received Completions may optionally be handled as Unexpected Completions. Therefore when gfx endpoint function is in d3 state, all pcie iomem transaction requires to transition the pcie function in D0 state. Implementation of handling i915_gem_object_pin_map will be handled in different series. Anshuman Gupta (2): drm/i915: Refactor userfault_wakeref to re-use drm/i915/dgfx: Release mmap on rpm suspend drivers/gpu/drm/i915/gem/i915_gem_mman.c | 20 ++-- drivers/gpu/drm/i915/gem/i915_gem_mman.h | 1 + drivers/gpu/drm/i915/gem/i915_gem_object.c| 2 +- .../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +- drivers/gpu/drm/i915/gem/i915_gem_pm.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 46 --- drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 1 - drivers/gpu/drm/i915/gt/intel_gt.c| 3 ++ drivers/gpu/drm/i915/gt/intel_gt_types.h | 6 +++ drivers/gpu/drm/i915/gt/intel_gtt.h | 3 -- drivers/gpu/drm/i915/i915_driver.c| 1 - drivers/gpu/drm/i915/i915_gem.c | 7 ++- 12 files changed, 75 insertions(+), 20 deletions(-) -- 2.26.2
[Intel-gfx] [PATCH v3 2/2] drm/i915/dgfx: Release mmap on rpm suspend
Release all mmap mapping for all lmem objects which are associated
with userfault such that, while pcie function in D3hot, any access
to memory mappings will raise a userfault.
Runtime resume the dgpu(when gem object lies in lmem).
This will transition the dgpu graphics function to D0
state if it was in D3 in order to access the mmap memory
mappings.
v2:
- Squashes the patches. [Matt Auld]
- Add adequate locking for lmem_userfault_list addition. [Matt Auld]
- Reused obj->userfault_count to avoid double addition. [Matt Auld]
- Added i915_gem_object_lock to check
i915_gem_object_is_lmem. [Matt Auld]
v3:
- Use i915_ttm_cpu_maps_iomem. [Matt Auld]
- Fix 'ret == 0 to ret == VM_FAULT_NOPAGE'. [Matt Auld]
- Reuse obj->userfault_count as a bool 0 or 1. [Matt Auld]
- Delete the mmaped obj from lmem_userfault_list in obj
destruction path. [Matt Auld]
- Get a wakeref for object destruction patch. [Matt Auld]
- Use intel_wakeref_auto to delay runtime PM. [Matt Auld]
PCIe Specs 5.3.1.4.1
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6331
Cc: Matthew Auld
Cc: Rodrigo Vivi
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 18 ++--
drivers/gpu/drm/i915/gem/i915_gem_mman.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_object.c| 2 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 46 ---
drivers/gpu/drm/i915/gt/intel_gt.c| 2 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++
drivers/gpu/drm/i915/i915_driver.c| 1 -
drivers/gpu/drm/i915/i915_gem.c | 5 ++
9 files changed, 68 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 2be222c03c82..55a4e9fba5ba 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -550,13 +550,10 @@ void i915_gem_object_release_mmap_gtt(struct
drm_i915_gem_object *obj)
intel_runtime_pm_put(&i915->runtime_pm, wakeref);
}
-void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj)
+void __i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj)
{
struct i915_mmap_offset *mmo, *mn;
- if (obj->ops->unmap_virtual)
- obj->ops->unmap_virtual(obj);
-
spin_lock(&obj->mmo.lock);
rbtree_postorder_for_each_entry_safe(mmo, mn,
&obj->mmo.offsets, offset) {
@@ -573,6 +570,19 @@ void i915_gem_object_release_mmap_offset(struct
drm_i915_gem_object *obj)
spin_lock(&obj->mmo.lock);
}
spin_unlock(&obj->mmo.lock);
+
+ if (obj->userfault_count) {
+ list_del(&obj->userfault_link);
+ obj->userfault_count = 0;
+ }
+}
+
+void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj)
+{
+ if (obj->ops->unmap_virtual)
+ obj->ops->unmap_virtual(obj);
+
+ __i915_gem_object_release_mmap_offset(obj);
}
static struct i915_mmap_offset *
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
index efee9e0d2508..271039fdf875 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
@@ -27,6 +27,7 @@ int i915_gem_dumb_mmap_offset(struct drm_file *file_priv,
void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
void i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
+void __i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj);
void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj);
#endif
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 389e9f157ca5..f6e60cc86b9e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -238,7 +238,7 @@ static void __i915_gem_object_free_mmaps(struct
drm_i915_gem_object *obj)
{
/* Skip serialisation and waking the device if known to be not used. */
- if (obj->userfault_count)
+ if (obj->userfault_count && !IS_DGFX(to_i915(obj->base.dev)))
i915_gem_object_release_mmap_gtt(obj);
if (!RB_EMPTY_ROOT(&obj->mmo.offsets)) {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 9f6b14ec189a..40305e2bcd49 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -298,7 +298,8 @@ struct drm_i915_gem_object {
};
/**
-* Whether the object is currently in the GGTT mmap.
+* Whether the object is currently in the GGTT or any other supported
+* fake offset mmap backed by lmem.
*/
unsigned int userfault_count;
struct list_head userfault_link;
diff --git a/d
[Intel-gfx] [PATCH v3 1/2] drm/i915: Refactor userfault_wakeref to re-use
Refactor userfault_wakeref to re-use for discrete lmem mmap mapping
as well, as on discrete GTT mmap are not supported. Moving
userfault_wakeref from ggtt to gt structure.
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 1 -
drivers/gpu/drm/i915/gt/intel_gt.c | 1 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 +++
drivers/gpu/drm/i915/gt/intel_gtt.h | 3 ---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 0c5c43852e24..2be222c03c82 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -413,7 +413,7 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
vma->mmo = mmo;
if (CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
- intel_wakeref_auto(&to_gt(i915)->ggtt->userfault_wakeref,
+ intel_wakeref_auto(&to_gt(i915)->userfault_wakeref,
msecs_to_jiffies_timeout(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND));
if (write) {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 00359ec9d58b..3428f735e786 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -24,7 +24,7 @@ void i915_gem_suspend(struct drm_i915_private *i915)
{
GEM_TRACE("%s\n", dev_name(i915->drm.dev));
- intel_wakeref_auto(&to_gt(i915)->ggtt->userfault_wakeref, 0);
+ intel_wakeref_auto(&to_gt(i915)->userfault_wakeref, 0);
flush_workqueue(i915->wq);
/*
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index 6ebda3d65086..f920d5484132 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -842,7 +842,6 @@ void intel_ggtt_init_fences(struct i915_ggtt *ggtt)
INIT_LIST_HEAD(&ggtt->fence_list);
INIT_LIST_HEAD(&ggtt->userfault_list);
- intel_wakeref_auto_init(&ggtt->userfault_wakeref, uncore->rpm);
detect_bit_6_swizzle(ggtt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index e4bac2431e41..1ce344cfa827 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -801,6 +801,7 @@ static int intel_gt_tile_setup(struct intel_gt *gt,
phys_addr_t phys_addr)
}
intel_uncore_init_early(gt->uncore, gt);
+ intel_wakeref_auto_init(>->userfault_wakeref, gt->uncore->rpm);
ret = intel_uncore_setup_mmio(gt->uncore, phys_addr);
if (ret)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 4d56f7d5a3be..e6a662f9d7c0 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -147,6 +147,9 @@ struct intel_gt {
*/
intel_wakeref_t awake;
+ /* Manual runtime pm autosuspend delay for user GGTT/lmem mmaps */
+ struct intel_wakeref_auto userfault_wakeref;
+
u32 clock_frequency;
u32 clock_period_ns;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index e639434e97fd..c0ca53cba9f0 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -386,9 +386,6 @@ struct i915_ggtt {
*/
struct list_head userfault_list;
- /* Manual runtime pm autosuspend delay for user GGTT mmaps */
- struct intel_wakeref_auto userfault_wakeref;
-
struct mutex error_mutex;
struct drm_mm_node error_capture;
struct drm_mm_node uc_fw;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4b76051312dd..70f082f7911a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1172,7 +1172,7 @@ void i915_gem_driver_unregister(struct drm_i915_private
*i915)
void i915_gem_driver_remove(struct drm_i915_private *dev_priv)
{
- intel_wakeref_auto_fini(&to_gt(dev_priv)->ggtt->userfault_wakeref);
+ intel_wakeref_auto_fini(&to_gt(dev_priv)->userfault_wakeref);
i915_gem_suspend_late(dev_priv);
intel_gt_driver_remove(to_gt(dev_priv));
--
2.26.2
[Intel-gfx] [PATCH 1/2] drm/i915/hotplug: move hotplug storm debugfs to intel_hotplug.c
The debugfs should be where the implementation details are.
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_debugfs.c | 160 +
drivers/gpu/drm/i915/display/intel_hotplug.c | 166 ++
drivers/gpu/drm/i915/display/intel_hotplug.h | 1 +
3 files changed, 169 insertions(+), 158 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 5dc364e9db49..486256749dbc 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -22,6 +22,7 @@
#include "intel_fbdev.h"
#include "intel_hdcp.h"
#include "intel_hdmi.h"
+#include "intel_hotplug.h"
#include "intel_panel.h"
#include "intel_pm.h"
#include "intel_psr.h"
@@ -1617,162 +1618,6 @@ static const struct file_operations
i915_cur_wm_latency_fops = {
.write = cur_wm_latency_write
};
-static int i915_hpd_storm_ctl_show(struct seq_file *m, void *data)
-{
- struct drm_i915_private *dev_priv = m->private;
- struct intel_hotplug *hotplug = &dev_priv->display.hotplug;
-
- /* Synchronize with everything first in case there's been an HPD
-* storm, but we haven't finished handling it in the kernel yet
-*/
- intel_synchronize_irq(dev_priv);
- flush_work(&dev_priv->display.hotplug.dig_port_work);
- flush_delayed_work(&dev_priv->display.hotplug.hotplug_work);
-
- seq_printf(m, "Threshold: %d\n", hotplug->hpd_storm_threshold);
- seq_printf(m, "Detected: %s\n",
- str_yes_no(delayed_work_pending(&hotplug->reenable_work)));
-
- return 0;
-}
-
-static ssize_t i915_hpd_storm_ctl_write(struct file *file,
- const char __user *ubuf, size_t len,
- loff_t *offp)
-{
- struct seq_file *m = file->private_data;
- struct drm_i915_private *dev_priv = m->private;
- struct intel_hotplug *hotplug = &dev_priv->display.hotplug;
- unsigned int new_threshold;
- int i;
- char *newline;
- char tmp[16];
-
- if (len >= sizeof(tmp))
- return -EINVAL;
-
- if (copy_from_user(tmp, ubuf, len))
- return -EFAULT;
-
- tmp[len] = '\0';
-
- /* Strip newline, if any */
- newline = strchr(tmp, '\n');
- if (newline)
- *newline = '\0';
-
- if (strcmp(tmp, "reset") == 0)
- new_threshold = HPD_STORM_DEFAULT_THRESHOLD;
- else if (kstrtouint(tmp, 10, &new_threshold) != 0)
- return -EINVAL;
-
- if (new_threshold > 0)
- drm_dbg_kms(&dev_priv->drm,
- "Setting HPD storm detection threshold to %d\n",
- new_threshold);
- else
- drm_dbg_kms(&dev_priv->drm, "Disabling HPD storm detection\n");
-
- spin_lock_irq(&dev_priv->irq_lock);
- hotplug->hpd_storm_threshold = new_threshold;
- /* Reset the HPD storm stats so we don't accidentally trigger a storm */
- for_each_hpd_pin(i)
- hotplug->stats[i].count = 0;
- spin_unlock_irq(&dev_priv->irq_lock);
-
- /* Re-enable hpd immediately if we were in an irq storm */
- flush_delayed_work(&dev_priv->display.hotplug.reenable_work);
-
- return len;
-}
-
-static int i915_hpd_storm_ctl_open(struct inode *inode, struct file *file)
-{
- return single_open(file, i915_hpd_storm_ctl_show, inode->i_private);
-}
-
-static const struct file_operations i915_hpd_storm_ctl_fops = {
- .owner = THIS_MODULE,
- .open = i915_hpd_storm_ctl_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
- .write = i915_hpd_storm_ctl_write
-};
-
-static int i915_hpd_short_storm_ctl_show(struct seq_file *m, void *data)
-{
- struct drm_i915_private *dev_priv = m->private;
-
- seq_printf(m, "Enabled: %s\n",
-
str_yes_no(dev_priv->display.hotplug.hpd_short_storm_enabled));
-
- return 0;
-}
-
-static int
-i915_hpd_short_storm_ctl_open(struct inode *inode, struct file *file)
-{
- return single_open(file, i915_hpd_short_storm_ctl_show,
- inode->i_private);
-}
-
-static ssize_t i915_hpd_short_storm_ctl_write(struct file *file,
- const char __user *ubuf,
- size_t len, loff_t *offp)
-{
- struct seq_file *m = file->private_data;
- struct drm_i915_private *dev_priv = m->private;
- struct intel_hotplug *hotplug = &dev_priv->display.hotplug;
- char *newline;
- char tmp[16];
- int i;
- bool new_state;
-
- if (len >= sizeof(tmp))
- return -EINVAL;
-
- if (copy_from_user(tmp, ubuf, len))
- return -EFAULT;
-
- tmp[len] = '\0';
-
- /* Strip newline,
[Intel-gfx] [PATCH 2/2] drm/i915/hotplug: refactor hotplug init slightly
Rename intel_hpd_init_work() to the more generic intel_hpd_init_early(),
and move the hotplug storm initialization there. This lets us move the
HPD_STORM_DEFAULT_THRESHOLD macro to intel_hotplug.c too.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hotplug.c | 22 +++-
drivers/gpu/drm/i915/display/intel_hotplug.h | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 3 ---
drivers/gpu/drm/i915/i915_irq.c | 11 +-
4 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 4faae25d76c0..352a1b53b63e 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -90,6 +90,9 @@ enum hpd_pin intel_hpd_pin_default(struct drm_i915_private
*dev_priv,
return HPD_PORT_A + port - PORT_A;
}
+/* Threshold == 5 for long IRQs, 50 for short */
+#define HPD_STORM_DEFAULT_THRESHOLD50
+
#define HPD_STORM_DETECT_PERIOD1000
#define HPD_STORM_REENABLE_DELAY (2 * 60 * 1000)
#define HPD_RETRY_DELAY1000
@@ -711,14 +714,23 @@ void intel_hpd_poll_disable(struct drm_i915_private
*dev_priv)
schedule_work(&dev_priv->display.hotplug.poll_init_work);
}
-void intel_hpd_init_work(struct drm_i915_private *dev_priv)
+void intel_hpd_init_early(struct drm_i915_private *i915)
{
- INIT_DELAYED_WORK(&dev_priv->display.hotplug.hotplug_work,
+ INIT_DELAYED_WORK(&i915->display.hotplug.hotplug_work,
i915_hotplug_work_func);
- INIT_WORK(&dev_priv->display.hotplug.dig_port_work,
i915_digport_work_func);
- INIT_WORK(&dev_priv->display.hotplug.poll_init_work,
i915_hpd_poll_init_work);
- INIT_DELAYED_WORK(&dev_priv->display.hotplug.reenable_work,
+ INIT_WORK(&i915->display.hotplug.dig_port_work, i915_digport_work_func);
+ INIT_WORK(&i915->display.hotplug.poll_init_work,
i915_hpd_poll_init_work);
+ INIT_DELAYED_WORK(&i915->display.hotplug.reenable_work,
intel_hpd_irq_storm_reenable_work);
+
+ i915->display.hotplug.hpd_storm_threshold = HPD_STORM_DEFAULT_THRESHOLD;
+ /* If we have MST support, we want to avoid doing short HPD IRQ storm
+* detection, as short HPD storms will occur as a natural part of
+* sideband messaging with MST.
+* On older platforms however, IRQ storms can occur with both long and
+* short pulses, as seen on some G4x systems.
+*/
+ i915->display.hotplug.hpd_short_storm_enabled = !HAS_DP_MST(i915);
}
void intel_hpd_cancel_work(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.h
b/drivers/gpu/drm/i915/display/intel_hotplug.h
index aa84e381d6c3..424ae5dbf5a0 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.h
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.h
@@ -22,7 +22,7 @@ void intel_hpd_irq_handler(struct drm_i915_private *dev_priv,
u32 pin_mask, u32 long_mask);
void intel_hpd_trigger_irq(struct intel_digital_port *dig_port);
void intel_hpd_init(struct drm_i915_private *dev_priv);
-void intel_hpd_init_work(struct drm_i915_private *dev_priv);
+void intel_hpd_init_early(struct drm_i915_private *i915);
void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
enum hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv,
enum port port);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index be201ba5e9ab..c91cccb2b8c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -75,9 +75,6 @@ struct intel_limit;
struct intel_overlay_error_state;
struct vlv_s0ix_state;
-/* Threshold == 5 for long IRQs, 50 for short */
-#define HPD_STORM_DEFAULT_THRESHOLD 50
-
#define I915_GEM_GPU_DOMAINS \
(I915_GEM_DOMAIN_RENDER | \
I915_GEM_DOMAIN_SAMPLER | \
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 515648cd1233..8ffd81243a19 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4399,7 +4399,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
intel_hpd_init_pins(dev_priv);
- intel_hpd_init_work(dev_priv);
+ intel_hpd_init_early(dev_priv);
dev->vblank_disable_immediate = true;
@@ -4413,15 +4413,6 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
dev_priv->display_irqs_enabled = false;
- dev_priv->display.hotplug.hpd_storm_threshold =
HPD_STORM_DEFAULT_THRESHOLD;
- /* If we have MST support, we want to avoid doing short HPD IRQ storm
-* detection, as short HPD storms will occur as a natural part of
-* sideband messaging with MST.
-* On older platforms however, IR
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi, On Wed, Sep 07, 2022 at 11:31:21PM +0200, Mateusz Kwiatkowski wrote: > W dniu 7.09.2022 o 16:34, Maxime Ripard pisze: > > On Mon, Sep 05, 2022 at 06:44:42PM +0200, Mateusz Kwiatkowski wrote: > >> Hi Maxime, > >> > >> W dniu 5.09.2022 o 15:37, Maxime Ripard pisze: > > + vfp = vfp_min + (porches_rem / 2); > > + vbp = porches - vfp; > > Relative position of the vertical sync within the VBI effectively moves > the > image up and down. Adding that (porches_rem / 2) moves the image up off > center > by that many pixels. I'd keep the VFP always at minimum to keep the image > centered. > >>> > >>> And you would increase the back porch only then? > >> > >> Well, increasing vbp only gives a centered image with the default 480i/576i > >> resolutions. However, only ever changing vbp will cause the image to be > >> always > >> at the bottom of the screen when the active line count is decreased (e.g. > >> setting the resolution to 720x480 but for 50Hz "PAL" - like many game > >> consoles > >> did back in the day). > >> > >> I believe that the perfect solution would: > >> > >> - Use the canonical / standard-defined blanking line counts for the > >> standard > >> vertical resolutions (480/486/576) > >> - Increase vfp and vbp from there by the same number if a smaller number of > >> active lines is specified, so that the resulting image is centered > >> - Likewise, decrease vfp and vbp by the same number if the active line > >> number > >> is larger and there is still leeway (this should allow for seamless > >>handling > >> of 480i vs. 486i for 60 Hz "NTSC") > > > > I'm not sure I understand how that's any different than the code you > > initially commented on. > > > > I would start by taking the entire blanking area, remove the sync > > period. We only have the two porches now, and I'm starting from the > > minimum, adding as many pixels in both (unless it's not an even number, > > in which case the backporch will have the extra pixel). > > > > Isn't it the same thing? > > [...] > > Unless you only want me to consider the front porch maximum? > > I think you're confusing the "post-equalizing pulses" with the "vertical back > porch" a little bit. The "vertical back porch" includes both the > post-equalizing > pulses and the entire rest of the VBI period, for the standard resolutions at > least. > > The "canonical" modelines (at least for vc4's VEC, see the notes below): > > - (vfp==4, vsync==6, vbp==39) for 576i > - (vfp==7, vsync==6, vbp==32) for 480i > - (vfp==5, vsync==6, vbp==28) for 486i (full frame NTSC as originally > specified) > > The numbers for vfp don't exactly match the theoretical values, because: > > - VEC actually adds a half-line pulse on top of VFP_ODD, and in the 625-line > mode also on top of VFP_EVEN (not always, but let's not dwell too much) > - Conversely, VEC subtracts the half-line pulse from VSYNC_ODD and VSYNC_EVEN > in the 625-line mode > - SMPTE S170M (see https://www.itu.int/rec/R-REC-BT.1700-0-200502-I/en) > defines > that active picture for NTSC is on lines 21-263 and 283-525; 263 and 283 are > half-lines that are represented as full lines in the "486i" spec It's going to be a bit difficult to match that into a drm_display_mode, since as far I understand it, all the timings are the sum of the timings of both fields in interlaced. I guess we'll have to be close enough. > - SMPTE 314M, which is the spec for DV, defines the 480 active lines as lines > 23-262 and 285-524; see Table 20 on page 26 in > > https://last.hit.bme.hu/download/firtha/video/SMPTE/SMPTE-314M%20DV25-50.pdf; > this means that the standard 480i frame shaves off four topmost and two > bottommost lines (2 and 1 per field) of the 486i full frame I'm still struggling a bit to match that into front porch, sync period and back porch. I guess the sync period is easy since it's pretty much fixed. That line 0-23 is the entire blanking area though, right? > Note that the half-line pulses in vfp/vsync may be generated in a different > way > on encoders other than vc4's VEC. Maybe we should define some concrete > semantics for vfp/vsync in analog TV modes, and compensate for that in the > drivers. But anyway, that's a separate issue. > > My point is that, to get a centered image, you can then proportionately add > values to those "canonical" vfp/vbp values. For example if someone specifies > 720x480 frame, but 50 Hz PAL, you should set (vfp==52, vsync==6, vbp==87). In this case, you add 48 both front porches, right? How is that proportionate? > Those extra vbp lines will be treated as a black bar at the top of the frame, > and extra vfp lines will be at the bottom of the frame. > > However if someone specifies e.g. 720x604, there's nothing more you could > remove from vfp, so your only option is to reduce vbp compared to the standard > mode, so you'll end up with (vfp==4, vsync==6, vbp==11). The image will not be > centered, the topmost
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
On Wed, Sep 07, 2022 at 11:31:21PM +0200, Mateusz Kwiatkowski wrote: > The "canonical" modelines (at least for vc4's VEC, see the notes below): > > - (vfp==4, vsync==6, vbp==39) for 576i > - (vfp==7, vsync==6, vbp==32) for 480i > - (vfp==5, vsync==6, vbp==28) for 486i (full frame NTSC as originally > specified) It's not clear to me either how you come up with those timings? Maxime signature.asc Description: PGP signature
[Intel-gfx] [PATCH] drm/i915: implement async_flip mode per plane tracking
Current implementation of async flip w/a relies on assumption that
previous atomic commit contains valid information if async_flip is still
enabled on the plane. It is incorrect. If previous commit did not modify
the plane its state->uapi.async_flip can be false. As a result DMAR/PIPE
errors can be observed:
i915 :00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x0080
i915 :00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x0080
DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Read NO_PASID] Request device [00:02.0] fault addr 0x0 [fault reason
0x06] PTE Read access is not set
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 6 ++
drivers/gpu/drm/i915/display/intel_display.c | 7 ---
drivers/gpu/drm/i915/display/intel_display_types.h | 3 +++
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index dd876dbbaa394d..4b4d8427b466c0 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -591,6 +591,12 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
if (new_plane_state->uapi.visible || old_plane_state->uapi.visible)
new_crtc_state->update_planes |= BIT(plane->id);
+ if (new_crtc_state->uapi.async_flip && plane->async_flip)
+ new_crtc_state->async_flip_planes |= BIT(plane->id);
+ else if (new_plane_state->uapi.visible != old_plane_state->uapi.visible
||
+new_plane_state->uapi.fb != old_plane_state->uapi.fb)
+ new_crtc_state->async_flip_planes &= ~BIT(plane->id);
+
if (new_plane_state->uapi.visible &&
intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier)) {
new_crtc_state->data_rate_y[plane->id] =
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 72e2091d9fcb59..7bab74b2a4ae2e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1292,7 +1292,8 @@ static void intel_crtc_async_flip_disable_wa(struct
intel_atomic_state *state,
intel_atomic_get_old_crtc_state(state, crtc);
const struct intel_crtc_state *new_crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
- u8 update_planes = new_crtc_state->update_planes;
+ u8 disable_async_flip_planes = old_crtc_state->async_flip_planes &
+ ~new_crtc_state->async_flip_planes;
const struct intel_plane_state *old_plane_state;
struct intel_plane *plane;
bool need_vbl_wait = false;
@@ -1301,7 +1302,7 @@ static void intel_crtc_async_flip_disable_wa(struct
intel_atomic_state *state,
for_each_old_intel_plane_in_state(state, plane, old_plane_state, i) {
if (plane->need_async_flip_disable_wa &&
plane->pipe == crtc->pipe &&
- update_planes & BIT(plane->id)) {
+ disable_async_flip_planes & BIT(plane->id)) {
/*
* Apart from the async flip bit we want to
* preserve the old state for the plane.
@@ -1418,7 +1419,7 @@ static void intel_pre_plane_update(struct
intel_atomic_state *state,
* WA for platforms where async address update enable bit
* is double buffered and only latched at start of vblank.
*/
- if (old_crtc_state->uapi.async_flip && !new_crtc_state->uapi.async_flip)
+ if (old_crtc_state->async_flip_planes &
~new_crtc_state->async_flip_planes)
intel_crtc_async_flip_disable_wa(state, crtc);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 0da9b208d56e8b..b37891a8def780 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1234,6 +1234,9 @@ struct intel_crtc_state {
/* bitmask of planes that will be updated during the commit */
u8 update_planes;
+ /* bitmask of planes with async flip active */
+ u8 async_flip_planes;
+
u8 framestart_delay; /* 1-4 */
u8 msa_timing_delay; /* 0-3 */
--
2.34.1
Re: [Intel-gfx] [PATCH v7 00/15] GSC support for XeHP SDV and DG2
On 9/9/2022 3:24 AM, Joonas Lahtinen wrote: Dave, do you have a preference how to deal with the mishap here, shall I do a force-push to drm-intel-gt-next to correctly record the Acked-by or revert and re-push? Or just leave it as is? Quoting Greg Kroah-Hartman (2022-09-01 18:09:09) On Sat, Aug 06, 2022 at 03:26:21PM +0300, Tomas Winkler wrote: Add GSC support for XeHP SDV and DG2 platforms. The series includes changes for the mei driver: - add ability to use polling instead of interrupts - add ability to use extended timeouts - setup extended operational memory for GSC The series includes changes for the i915 driver: - allocate extended operational memory for GSC - GSC on XeHP SDV offsets and definitions This patch set should be merged via gfx tree as the auxiliary device belongs there. Greg, your ACK is required for the drives/misc/mei code base, please review the patches. With the exception that you all don't know what year it is: Acked-by: Greg Kroah-Hartman Daniele, why were the patches applied without this A-b? Apologies, I usually rely on dim to pick up all the correct r-bs and acks from the ML and to warn me if something is missing, and I didn't realize that it hadn't automagically picked up the ack. I'm just preparing the drm-intel-gt-next pull request and now it appears like we're pushing a lot of commits outside of drm without any Acks. Please reach out to the maintainers *before* pushing code for other subsystems. Unless you get an explicit ack to do so, do not push such code. I'm assuming you mean the i915 maintainers here, given that there is an ack from Greg in this email? Rodrigo was in the loop of us needing to merge this via drm, so I thought I was good on that side. I'll make sure to have an explicit ack on the ML next time (which is coming relatively soon, because there are some more mei patches in the DG2 HuC series). Quoting from the committer guidelines[1] the first rule is: "Only push patches changing drivers/gpu/drm/i915." In those cases, please ping a maintainer and don't rush things. Will do. And apologies again for the mistake. Daniele Regards, Joonas [1] https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-intel.html#high-level-guidelines
Re: [Intel-gfx] Developing a new backlight driver for specific OLED screen
On Fri, 09 Sep 2022, Rodrigo Vivi wrote: > On Fri, Sep 09, 2022 at 11:35:28AM +0200, Aurélien wrote: >>Hi, >>I hope this mailing-mist is the right place for this question. > > + dri-devel mailing list that looks more appropriated. > + Hans and Lyude who were recently working to standardize some of the > backlight stuff. > >>I would like to develop a new driver in order to manage backlight for a >>specific OLED display (Samsung one). For that propose I need to use the >>dpcd aux read and write functions. >>Since this driver is independent film the i915 driver I would like to >>develop an indémependant driver. >>So my question is: how can I use the i915 API (dpcd aux communications) >>outside from the driver and register the backlight sys entries like the >>i915 does (in order to have all the softwares which plays with the >>backlight working without modifying them) ? > > I don't believe you want to use the i915 API, but move the common functions > to the drm subsystem itself and then reuse as a drm device. Aurélien, are you aware of drivers/gpu/drm/display/drm_dp_helper.c and all the functions around struct dp_aux_backlight and struct drm_edp_backlight_info? Also see drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c. Does the display use some proprietary, non-VESA DPCD registers? There's already some of that in i915 for Intel proprietary interfaces. BR, Jani. > >>Many thanks for your answers >>-- >>Aurélien -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/dgfx: Release mmap on rpm suspend
On 09/09/2022 12:24, Anshuman Gupta wrote:
Release all mmap mapping for all lmem objects which are associated
with userfault such that, while pcie function in D3hot, any access
to memory mappings will raise a userfault.
Runtime resume the dgpu(when gem object lies in lmem).
This will transition the dgpu graphics function to D0
state if it was in D3 in order to access the mmap memory
mappings.
v2:
- Squashes the patches. [Matt Auld]
- Add adequate locking for lmem_userfault_list addition. [Matt Auld]
- Reused obj->userfault_count to avoid double addition. [Matt Auld]
- Added i915_gem_object_lock to check
i915_gem_object_is_lmem. [Matt Auld]
v3:
- Use i915_ttm_cpu_maps_iomem. [Matt Auld]
- Fix 'ret == 0 to ret == VM_FAULT_NOPAGE'. [Matt Auld]
- Reuse obj->userfault_count as a bool 0 or 1. [Matt Auld]
- Delete the mmaped obj from lmem_userfault_list in obj
destruction path. [Matt Auld]
- Get a wakeref for object destruction patch. [Matt Auld]
- Use intel_wakeref_auto to delay runtime PM. [Matt Auld]
PCIe Specs 5.3.1.4.1
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6331
Cc: Matthew Auld
Cc: Rodrigo Vivi
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 18 ++--
drivers/gpu/drm/i915/gem/i915_gem_mman.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_object.c| 2 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 46 ---
drivers/gpu/drm/i915/gt/intel_gt.c| 2 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++
drivers/gpu/drm/i915/i915_driver.c| 1 -
drivers/gpu/drm/i915/i915_gem.c | 5 ++
9 files changed, 68 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 2be222c03c82..55a4e9fba5ba 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -550,13 +550,10 @@ void i915_gem_object_release_mmap_gtt(struct
drm_i915_gem_object *obj)
intel_runtime_pm_put(&i915->runtime_pm, wakeref);
}
-void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj)
+void __i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj)
{
struct i915_mmap_offset *mmo, *mn;
- if (obj->ops->unmap_virtual)
- obj->ops->unmap_virtual(obj);
-
spin_lock(&obj->mmo.lock);
rbtree_postorder_for_each_entry_safe(mmo, mn,
&obj->mmo.offsets, offset) {
@@ -573,6 +570,19 @@ void i915_gem_object_release_mmap_offset(struct
drm_i915_gem_object *obj)
spin_lock(&obj->mmo.lock);
}
spin_unlock(&obj->mmo.lock);
+
+ if (obj->userfault_count) {
+ list_del(&obj->userfault_link);
+ obj->userfault_count = 0;
+ }
+}
+
+void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj)
+{
+ if (obj->ops->unmap_virtual)
+ obj->ops->unmap_virtual(obj);
+
+ __i915_gem_object_release_mmap_offset(obj);
}
static struct i915_mmap_offset *
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
index efee9e0d2508..271039fdf875 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
@@ -27,6 +27,7 @@ int i915_gem_dumb_mmap_offset(struct drm_file *file_priv,
void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
void i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
+void __i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj);
void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj);
#endif
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 389e9f157ca5..f6e60cc86b9e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -238,7 +238,7 @@ static void __i915_gem_object_free_mmaps(struct
drm_i915_gem_object *obj)
{
/* Skip serialisation and waking the device if known to be not used. */
- if (obj->userfault_count)
+ if (obj->userfault_count && !IS_DGFX(to_i915(obj->base.dev)))
i915_gem_object_release_mmap_gtt(obj);
if (!RB_EMPTY_ROOT(&obj->mmo.offsets)) {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 9f6b14ec189a..40305e2bcd49 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -298,7 +298,8 @@ struct drm_i915_gem_object {
};
/**
-* Whether the object is currently in the GGTT mmap.
+* Whether the object is currently in the GGTT or any other supported
+* fake offset mmap backed by lmem.
*/
unsigned int userfault_co
Re: [Intel-gfx] [PATCH 6/8] drm/i915/debugfs: Add perf_limit_reasons in debugfs
On Fri, 09 Sep 2022 03:13:05 -0700, Rodrigo Vivi wrote: > > On Wed, Sep 07, 2022 at 10:22:49PM -0700, Ashutosh Dixit wrote: > > From: Tilak Tangudu > > diff --git a/drivers/gpu/drm/i915/i915_reg.h > > b/drivers/gpu/drm/i915/i915_reg.h > > index 24009786f88b..9492f8f43b25 100644 > > --- a/drivers/gpu/drm/i915/i915_reg.h > > +++ b/drivers/gpu/drm/i915/i915_reg.h > > @@ -1802,6 +1802,7 @@ > > #define POWER_LIMIT_4_MASK REG_BIT(8) > > #define POWER_LIMIT_1_MASK REG_BIT(10) > > #define POWER_LIMIT_2_MASK REG_BIT(11) > > +#define GT0_PERF_LIMIT_REASONS_LOG_MASK REG_GENMASK(31, 16) > > > > I'm kind of confused here because I saw the other bits in the patch 5. Sorry Rodrigo, patch 5 is a bug-fix patch which should probably be merged to -fixes independent of this series, I have posted it independently too: https://patchwork.freedesktop.org/series/108277/ I was debating including patch 5 as part of this series but then it was touching the same code so I ended up including it. Sorry for the confusion. > but, anyway, thanks for improving the commit msg. > > Reviewed-by: Rodrigo Vivi Thanks. -- Ashutosh
Re: [Intel-gfx] Developing a new backlight driver for specific OLED screen
Hi, > + dri-devel mailing list that looks more appropriated. > + Hans and Lyude who were recently working to standardize some of the > backlight stuff. Thank you for these contacts. I'll try there if I need. > I don't believe you want to use the i915 API, but move the common functions > to the drm subsystem itself and then reuse as a drm device. If there is enough generic code I'll do everything with the DRM API. Unfortunately I can't spend too much time in order to generalize the i915 common functions. > Aurélien, are you aware of drivers/gpu/drm/display/drm_dp_helper.c and > all the functions around struct dp_aux_backlight and struct > drm_edp_backlight_info? Not yet. Since I'm not familiar with GPU/display drivers I didn't know what could be a good starting point. Indeed I already checked the intel_dp_aux_backlight.c code. That's why I told about using the "i915 API code" at first. But since this display is independent from the GPU i didn't want to link both code. Then that's a really good point if there is already an independant API. I'll have a look this evening. > Does the display use some proprietary, non-VESA DPCD registers? There's > already some of that in i915 for Intel proprietary interfaces. For sure. It's an OLED display. Thus there is no backlight. It uses specific registers to control the brightness of the screen. Unfortunately I guess the mechanism is not shared with many OLED displays... Thank you for your help. Aurélien
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/dgfx: Release mmap on rpm suspend
Hi Anshuman,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Anshuman-Gupta/DGFX-mmap-with-rpm/20220909-192609
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-a004
(https://download.01.org/0day-ci/archive/20220910/20220915.i5hngiqu-...@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project
f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/b3f193a1659a69de9e9025c9b02a039d0a58390d
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Anshuman-Gupta/DGFX-mmap-with-rpm/20220909-192609
git checkout b3f193a1659a69de9e9025c9b02a039d0a58390d
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1065:14: warning: use of logical
>> '&&' with constant operand [-Wconstant-logical-operand]
if (wakeref && CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
^ ~
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1065:14: note: use '&' for a bitwise
operation
if (wakeref && CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
^~
&
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1065:14: note: remove constant to
silence this warning
if (wakeref && CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
~^~~~
1 warning generated.
vim +1065 drivers/gpu/drm/i915/gem/i915_gem_ttm.c
985
986 static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
987 {
988 struct vm_area_struct *area = vmf->vma;
989 struct ttm_buffer_object *bo = area->vm_private_data;
990 struct drm_device *dev = bo->base.dev;
991 struct drm_i915_gem_object *obj;
992 intel_wakeref_t wakeref = 0;
993 vm_fault_t ret;
994 int idx;
995
996 obj = i915_ttm_to_gem(bo);
997 if (!obj)
998 return VM_FAULT_SIGBUS;
999
1000 /* Sanity check that we allow writing into this object */
1001 if (unlikely(i915_gem_object_is_readonly(obj) &&
1002 area->vm_flags & VM_WRITE)) {
1003 ret = VM_FAULT_SIGBUS;
1004 goto out_rpm;
1005 }
1006
1007 ret = ttm_bo_vm_reserve(bo, vmf);
1008 if (ret)
1009 goto out_rpm;
1010
1011 if (i915_ttm_cpu_maps_iomem(bo->resource))
1012 wakeref =
intel_runtime_pm_get(&to_i915(obj->base.dev)->runtime_pm);
1013
1014 if (obj->mm.madv != I915_MADV_WILLNEED) {
1015 dma_resv_unlock(bo->base.resv);
1016 ret = VM_FAULT_SIGBUS;
1017 goto out_rpm;
1018 }
1019
1020 if (!i915_ttm_resource_mappable(bo->resource)) {
1021 int err = -ENODEV;
1022 int i;
1023
1024 for (i = 0; i < obj->mm.n_placements; i++) {
1025 struct intel_memory_region *mr =
obj->mm.placements[i];
1026 unsigned int flags;
1027
1028 if (!mr->io_size && mr->type !=
INTEL_MEMORY_SYSTEM)
1029 continue;
1030
1031 flags = obj->flags;
1032 flags &= ~I915_BO_ALLOC_GPU_ONLY;
1033 err = __i915_ttm_migrate(obj, mr, flags);
1034 if (!err)
1035 break;
1036 }
1037
1038 if (err) {
1039 drm_dbg(dev, "Unable to make resource CPU
accessible\n");
1040 dma_resv_unlock(bo->base.resv);
1041 ret = VM_FAULT_SIGBUS;
1042 goto out_rpm;
1043 }
1044 }
1045
1046 if (drm_dev_enter(dev, &idx)) {
1047 ret = ttm_bo_vm_fault_reserved(vmf,
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/dgfx: Release mmap on rpm suspend
Hi Anshuman,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Anshuman-Gupta/DGFX-mmap-with-rpm/20220909-192609
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-a013
(https://download.01.org/0day-ci/archive/20220910/202209100051.4wp6elzf-...@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project
f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/b3f193a1659a69de9e9025c9b02a039d0a58390d
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Anshuman-Gupta/DGFX-mmap-with-rpm/20220909-192609
git checkout b3f193a1659a69de9e9025c9b02a039d0a58390d
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1065:14: warning: use of logical
>> '&&' with constant operand [-Wconstant-logical-operand]
if (wakeref && CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
^ ~
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1065:14: note: use '&' for a bitwise
operation
if (wakeref && CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
^~
&
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1065:14: note: remove constant to
silence this warning
if (wakeref && CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
~^~~~
1 warning generated.
vim +1065 drivers/gpu/drm/i915/gem/i915_gem_ttm.c
985
986 static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
987 {
988 struct vm_area_struct *area = vmf->vma;
989 struct ttm_buffer_object *bo = area->vm_private_data;
990 struct drm_device *dev = bo->base.dev;
991 struct drm_i915_gem_object *obj;
992 intel_wakeref_t wakeref = 0;
993 vm_fault_t ret;
994 int idx;
995
996 obj = i915_ttm_to_gem(bo);
997 if (!obj)
998 return VM_FAULT_SIGBUS;
999
1000 /* Sanity check that we allow writing into this object */
1001 if (unlikely(i915_gem_object_is_readonly(obj) &&
1002 area->vm_flags & VM_WRITE)) {
1003 ret = VM_FAULT_SIGBUS;
1004 goto out_rpm;
1005 }
1006
1007 ret = ttm_bo_vm_reserve(bo, vmf);
1008 if (ret)
1009 goto out_rpm;
1010
1011 if (i915_ttm_cpu_maps_iomem(bo->resource))
1012 wakeref =
intel_runtime_pm_get(&to_i915(obj->base.dev)->runtime_pm);
1013
1014 if (obj->mm.madv != I915_MADV_WILLNEED) {
1015 dma_resv_unlock(bo->base.resv);
1016 ret = VM_FAULT_SIGBUS;
1017 goto out_rpm;
1018 }
1019
1020 if (!i915_ttm_resource_mappable(bo->resource)) {
1021 int err = -ENODEV;
1022 int i;
1023
1024 for (i = 0; i < obj->mm.n_placements; i++) {
1025 struct intel_memory_region *mr =
obj->mm.placements[i];
1026 unsigned int flags;
1027
1028 if (!mr->io_size && mr->type !=
INTEL_MEMORY_SYSTEM)
1029 continue;
1030
1031 flags = obj->flags;
1032 flags &= ~I915_BO_ALLOC_GPU_ONLY;
1033 err = __i915_ttm_migrate(obj, mr, flags);
1034 if (!err)
1035 break;
1036 }
1037
1038 if (err) {
1039 drm_dbg(dev, "Unable to make resource CPU
accessible\n");
1040 dma_resv_unlock(bo->base.resv);
1041 ret = VM_FAULT_SIGBUS;
1042 goto out_rpm;
1043 }
1044 }
1045
1046 if (drm_dev_enter(dev, &idx)) {
1047 ret = ttm_bo_vm_fault_reserved(vmf,
Re: [Intel-gfx] [PATCH v7 00/15] GSC support for XeHP SDV and DG2
On Fri, 2022-09-09 at 08:17 -0700, Ceraolo Spurio, Daniele wrote: > > > On 9/9/2022 3:24 AM, Joonas Lahtinen wrote: > > Dave, do you have a preference how to deal with the mishap here, > > shall I do a > > force-push to drm-intel-gt-next to correctly record the Acked-by or > > revert and > > re-push? Or just leave it as is? Dave and Daniel, this question is still pertinent. > > > > Quoting Greg Kroah-Hartman (2022-09-01 18:09:09) > > > On Sat, Aug 06, 2022 at 03:26:21PM +0300, Tomas Winkler wrote: > > > > Add GSC support for XeHP SDV and DG2 platforms. > > > > > > > > The series includes changes for the mei driver: > > > > - add ability to use polling instead of interrupts > > > > - add ability to use extended timeouts > > > > - setup extended operational memory for GSC > > > > > > > > The series includes changes for the i915 driver: > > > > - allocate extended operational memory for GSC > > > > - GSC on XeHP SDV offsets and definitions > > > > > > > > This patch set should be merged via gfx tree as > > > > the auxiliary device belongs there. > > > > Greg, your ACK is required for the drives/misc/mei code base, > > > > please review the patches. > > > With the exception that you all don't know what year it is: > > > > > > Acked-by: Greg Kroah-Hartman > > Daniele, why were the patches applied without this A-b? > > Apologies, I usually rely on dim to pick up all the correct r-bs and > acks from the ML and to warn me if something is missing, and I didn't > realize that it hadn't automagically picked up the ack. I understand the feeling. Recently I merged a patch from Vinay relying on patchwork to get the reviewed-by and I forgot to double check. dim picks up the "Link:", but I don't believe it picks any ack or rv-b from the mailing list. Patchwork does if you use pwclient or something like that. Anyway, lesson to both of us to always double-check, regardless the tool used. > > > > > I'm just preparing the drm-intel-gt-next pull request and now it > > appears > > like we're pushing a lot of commits outside of drm without any > > Acks. > > > > Please reach out to the maintainers *before* pushing code for other > > subsystems. Unless you get an explicit ack to do so, do not push > > such > > code. > > I'm assuming you mean the i915 maintainers here, given that there is > an > ack from Greg in this email? Rodrigo was in the loop of us needing to > merge this via drm, so I thought I was good on that side. I'll make > sure > to have an explicit ack on the ML next time (which is coming > relatively > soon, because there are some more mei patches in the DG2 HuC series). That's my fault indeed. I was following the movement, but I failed to step up right after I saw Greg's ack. Although I also noticed some re-send and reviews in progress even after the ack, I should had been more active there. Sorry, Rodrigo. > > > > > Quoting from the committer guidelines[1] the first rule is: > > "Only push patches changing drivers/gpu/drm/i915." > > > > In those cases, please ping a maintainer and don't rush things. > > Will do. And apologies again for the mistake. > > Daniele > > > Regards, Joonas > > > > [1] https://drm.pages.freedesktop.org/maintainer-tools/committer- > > drm-intel.html#high-level-guidelines > > >
Re: [Intel-gfx] [PATCH 6/8] drm/i915/debugfs: Add perf_limit_reasons in debugfs
On Fri, 2022-09-09 at 08:38 -0700, Dixit, Ashutosh wrote: On Fri, 09 Sep 2022 03:13:05 -0700, Rodrigo Vivi wrote: On Wed, Sep 07, 2022 at 10:22:49PM -0700, Ashutosh Dixit wrote: From: Tilak Tangudu mailto:tilak.tang...@intel.com>> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 24009786f88b..9492f8f43b25 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -1802,6 +1802,7 @@ #define POWER_LIMIT_4_MASK REG_BIT(8) #define POWER_LIMIT_1_MASK REG_BIT(10) #define POWER_LIMIT_2_MASK REG_BIT(11) +#define GT0_PERF_LIMIT_REASONS_LOG_MASK REG_GENMASK(31, 16) I'm kind of confused here because I saw the other bits in the patch 5. Sorry Rodrigo, patch 5 is a bug-fix patch which should probably be merged to -fixes independent of this series, I have posted it independently too: https://patchwork.freedesktop.org/series/108277/ yeap, better to merge this one first. I hope https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108277v2/shard-apl4/igt@i915_pm_...@engine-order.html is not related to this patch. should we trigger a retest? I was debating including patch 5 as part of this series but then it was touching the same code so I ended up including it. Sorry for the confusion. no worries. it makes sense now. Thanks for the patience but, anyway, thanks for improving the commit msg. Reviewed-by: Rodrigo Vivi mailto:rodrigo.v...@intel.com>> Thanks. -- Ashutosh
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for DGFX mmap with rpm (rev3)
== Series Details == Series: DGFX mmap with rpm (rev3) URL : https://patchwork.freedesktop.org/series/107400/ State : warning == Summary == Error: dim checkpatch failed fecdb3883843 drm/i915: Refactor userfault_wakeref to re-use 0152e06bf81b drm/i915/dgfx: Release mmap on rpm suspend -:38: WARNING:BAD_SIGN_OFF: Duplicate signature #38: Reported-by: kernel test robot total: 0 errors, 1 warnings, 0 checks, 182 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for DGFX mmap with rpm (rev3)
== Series Details ==
Series: DGFX mmap with rpm (rev3)
URL : https://patchwork.freedesktop.org/series/107400/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12109 -> Patchwork_107400v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v3/index.html
Participating hosts (39 -> 39)
--
Additional (1): fi-rkl-11600
Missing(1): fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_107400v3:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_lmem_swapping@basic@lmem0:
- {bat-dg2-11}: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12109/bat-dg2-11/igt@gem_lmem_swapping@ba...@lmem0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v3/bat-dg2-11/igt@gem_lmem_swapping@ba...@lmem0.html
Known issues
Here are the changes found in Patchwork_107400v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v3/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-rkl-11600: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v3/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_tiled_pread_basic:
- fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#3282])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v3/fi-rkl-11600/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600: NOTRUN -> [SKIP][6] ([i915#3012])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v3/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [PASS][7] -> [DMESG-FAIL][8] ([i915#4528])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12109/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v3/fi-blb-e6850/igt@i915_selftest@l...@requests.html
- fi-pnv-d510:[PASS][9] -> [DMESG-FAIL][10] ([i915#4528])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12109/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v3/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: NOTRUN -> [INCOMPLETE][11] ([i915#5982])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v3/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-rkl-11600: NOTRUN -> [SKIP][12] ([fdo#111827]) +7 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v3/fi-rkl-11600/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600: NOTRUN -> [SKIP][13] ([i915#4103])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v3/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600: NOTRUN -> [SKIP][14] ([fdo#109285] / [i915#4098])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v3/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_psr@sprite_plane_onoff:
- fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v3/fi-rkl-11600/igt@kms_psr@sprite_plane_onoff.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600: NOTRUN -> [SKIP][16] ([i915#3555] / [i915#4098])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v3/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-read:
- fi-rkl-11600: NOTRUN -> [SKIP][17] ([fdo#109295] / [i915#3291] /
[i915#3708]) +2 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v3/fi-rkl-11600/igt@prime_v...@basic-read.html
* igt@prime_vgem@basic-userptr:
- fi-rkl-11600: NOTRUN -> [SKIP][18] ([fdo#109295] / [i915#3301] /
[i915#3708])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v3/fi-rkl-11600/igt@prime_v...@basic-userptr.html
* igt@runner@aborted:
- fi-blb-e6850: NOTRUN -> [FAIL][19] ([fdo#109271] / [i915#2403] /
[i915#4312])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patc
