[PATCH 1/1] drm/nouveau/device: Get right pgsize_bitmap of iommu_domain
The suported page sizes of an iommu_domain are saved in the pgsize_bitmap
field. Retrieve the value from the right place.
Fixes: 58fd9375c2c534 ("drm/nouveau/platform: probe IOMMU if present")
Signed-off-by: Lu Baolu
---
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
index d0d52c1d4aee..992cc285f2fe 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
@@ -133,7 +133,7 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra
*tdev)
* or equal to the system's PAGE_SIZE, with a preference if
* both are equal.
*/
- pgsize_bitmap = tdev->iommu.domain->ops->pgsize_bitmap;
+ pgsize_bitmap = tdev->iommu.domain->pgsize_bitmap;
if (pgsize_bitmap & PAGE_SIZE) {
tdev->iommu.pgshift = PAGE_SHIFT;
} else {
--
2.25.1
Re: [PATCH v8 16/16] drm/i915: Remove unused i915->ggtt
On Tue, Dec 14, 2021 at 09:33:46PM +0200, Andi Shyti wrote:
> The reference to the GGTT from the private date is not used
> anymore. Remove it.
You may want to also mention here that tile0's ggtt will now be
dynamically allocated (and auto-deallocated on driver unload by the
drmm_* infrastructure).
Otherwise,
Reviewed-by: Matt Roper
Matt
>
> Suggested-by: Matt Roper
> Signed-off-by: Andi Shyti
> Cc: Michał Winiarski
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c| 7 +--
> drivers/gpu/drm/i915/gt/intel_gt.h| 2 +-
> drivers/gpu/drm/i915/i915_driver.c| 4 +++-
> drivers/gpu/drm/i915/i915_drv.h | 2 --
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 20 ++-
> drivers/gpu/drm/i915/selftests/i915_vma.c | 20 ++-
> .../gpu/drm/i915/selftests/mock_gem_device.c | 9 +++--
> drivers/gpu/drm/i915/selftests/mock_gtt.c | 9 -
> drivers/gpu/drm/i915/selftests/mock_gtt.h | 3 ++-
> 9 files changed, 44 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index f98f0fb21efb..298ff32c8d0c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -3,6 +3,7 @@
> * Copyright © 2019 Intel Corporation
> */
>
> +#include
> #include
>
> #include "intel_gt_debugfs.h"
> @@ -85,9 +86,11 @@ int intel_gt_probe_lmem(struct intel_gt *gt)
> return 0;
> }
>
> -void intel_gt_init_hw_early(struct intel_gt *gt, struct i915_ggtt *ggtt)
> +int intel_gt_assign_ggtt(struct intel_gt *gt)
> {
> - gt->ggtt = ggtt;
> + gt->ggtt = drmm_kzalloc(>->i915->drm, sizeof(*gt->ggtt), GFP_KERNEL);
> +
> + return gt->ggtt ? 0 : -ENOMEM;
> }
>
> static const struct intel_mmio_range icl_l3bank_steering_table[] = {
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
> b/drivers/gpu/drm/i915/gt/intel_gt.h
> index 3ace129eb2af..94e1bac8c0cc 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.h
> @@ -36,7 +36,7 @@ static inline struct intel_gt *huc_to_gt(struct intel_huc
> *huc)
>
> void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915);
> void __intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private
> *i915);
> -void intel_gt_init_hw_early(struct intel_gt *gt, struct i915_ggtt *ggtt);
> +int intel_gt_assign_ggtt(struct intel_gt *gt);
> int intel_gt_probe_lmem(struct intel_gt *gt);
> int intel_gt_init_mmio(struct intel_gt *gt);
> int __must_check intel_gt_init_hw(struct intel_gt *gt);
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index 3c984553d86f..5f2343389b5e 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -571,7 +571,9 @@ static int i915_driver_hw_probe(struct drm_i915_private
> *dev_priv)
>
> i915_perf_init(dev_priv);
>
> - intel_gt_init_hw_early(to_gt(dev_priv), &dev_priv->ggtt);
> + ret = intel_gt_assign_ggtt(to_gt(dev_priv));
> + if (ret)
> + goto err_perf;
>
> ret = i915_ggtt_probe_hw(dev_priv);
> if (ret)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 65724e4df3bd..8266df3e11ac 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -838,8 +838,6 @@ struct drm_i915_private {
> struct drm_atomic_state *modeset_restore_state;
> struct drm_modeset_acquire_ctx reset_ctx;
>
> - struct i915_ggtt ggtt; /* VM representing the global address space */
> -
> struct i915_gem_mm mm;
>
> /* Kernel Modesetting */
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> index 9afe7cf9d068..f62f7dac57f2 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> @@ -1737,26 +1737,28 @@ int i915_gem_gtt_mock_selftests(void)
> SUBTEST(igt_gtt_insert),
> };
> struct drm_i915_private *i915;
> - struct i915_ggtt *ggtt;
> + struct intel_gt *gt;
> int err;
>
> i915 = mock_gem_device();
> if (!i915)
> return -ENOMEM;
>
> - ggtt = kmalloc(sizeof(*ggtt), GFP_KERNEL);
> - if (!ggtt) {
> - err = -ENOMEM;
> + /* allocate the ggtt */
> + err = intel_gt_assign_ggtt(to_gt(i915));
> + if (err)
> goto out_put;
> - }
> - mock_init_ggtt(i915, ggtt);
>
> - err = i915_subtests(tests, ggtt);
> + gt = to_gt(i915);
> +
> + mock_init_ggtt(gt);
> +
> + err = i915_subtests(tests, gt->ggtt);
>
> mock_device_flush(i915);
> i915_gem_drain_freed_objects(i915);
> - mock_fini_ggtt(ggtt);
> - kfree(ggtt);
> + mock_fini_ggtt(gt->ggtt);
> +
> out_put:
> mock_destroy_device(i915);
> return err;
> diff --git a/drivers/gp
Re: [PATCH v8 15/16] drm/i915: Use to_gt() helper for GGTT accesses
On Tue, Dec 14, 2021 at 09:33:45PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> GGTT is currently available both through i915->ggtt and gt->ggtt, and we
> eventually want to get rid of the i915->ggtt one.
> Use to_gt() for all i915->ggtt accesses to help with the future
> refactoring.
>
> Signed-off-by: Michał Winiarski
> Cc: Michal Wajdeczko
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/gvt/dmabuf.c| 2 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
> drivers/gpu/drm/i915/i915_driver.c | 8
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/i915_gem.c | 23 ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 6 +++---
> drivers/gpu/drm/i915/i915_getparam.c | 2 +-
> drivers/gpu/drm/i915/i915_perf.c | 4 ++--
> 8 files changed, 26 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
> b/drivers/gpu/drm/i915/gvt/dmabuf.c
> index 8e65cd8258b9..94c3eb1586b0 100644
> --- a/drivers/gpu/drm/i915/gvt/dmabuf.c
> +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
> @@ -84,7 +84,7 @@ static int vgpu_gem_get_pages(
> kfree(st);
> return ret;
> }
> - gtt_entries = (gen8_pte_t __iomem *)dev_priv->ggtt.gsm +
> + gtt_entries = (gen8_pte_t __iomem *)to_gt(dev_priv)->ggtt->gsm +
> (fb_info->start >> PAGE_SHIFT);
> for_each_sg(st->sgl, sg, page_num, i) {
> dma_addr_t dma_addr =
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 93c3d154885b..0913daff62d7 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -390,9 +390,9 @@ static int i915_swizzle_info(struct seq_file *m, void
> *data)
> intel_wakeref_t wakeref;
>
> seq_printf(m, "bit6 swizzle for X-tiling = %s\n",
> -swizzle_string(dev_priv->ggtt.bit_6_swizzle_x));
> +swizzle_string(to_gt(dev_priv)->ggtt->bit_6_swizzle_x));
> seq_printf(m, "bit6 swizzle for Y-tiling = %s\n",
> -swizzle_string(dev_priv->ggtt.bit_6_swizzle_y));
> +swizzle_string(to_gt(dev_priv)->ggtt->bit_6_swizzle_y));
>
> if (dev_priv->quirks & QUIRK_PIN_SWIZZLED_PAGES)
> seq_puts(m, "L-shaped memory detected\n");
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index 95174938b160..3c984553d86f 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -571,6 +571,8 @@ static int i915_driver_hw_probe(struct drm_i915_private
> *dev_priv)
>
> i915_perf_init(dev_priv);
>
> + intel_gt_init_hw_early(to_gt(dev_priv), &dev_priv->ggtt);
> +
Does moving this call earlier in the function need to happen in patch
#13 rather than here? That patch converts the internals of
i915_ggtt_probe_hw() to use to_gt()->ggtt, but I believe until this
patch that pointer is uninitialized.
Matt
> ret = i915_ggtt_probe_hw(dev_priv);
> if (ret)
> goto err_perf;
> @@ -587,8 +589,6 @@ static int i915_driver_hw_probe(struct drm_i915_private
> *dev_priv)
> if (ret)
> goto err_ggtt;
>
> - intel_gt_init_hw_early(to_gt(dev_priv), &dev_priv->ggtt);
> -
> ret = intel_gt_probe_lmem(to_gt(dev_priv));
> if (ret)
> goto err_mem_regions;
> @@ -1146,7 +1146,7 @@ static int i915_drm_suspend(struct drm_device *dev)
>
> /* Must be called before GGTT is suspended. */
> intel_dpt_suspend(dev_priv);
> - i915_ggtt_suspend(&dev_priv->ggtt);
> + i915_ggtt_suspend(to_gt(dev_priv)->ggtt);
>
> i915_save_display(dev_priv);
>
> @@ -1270,7 +1270,7 @@ static int i915_drm_resume(struct drm_device *dev)
> if (ret)
> drm_err(&dev_priv->drm, "failed to re-enable GGTT\n");
>
> - i915_ggtt_resume(&dev_priv->ggtt);
> + i915_ggtt_resume(to_gt(dev_priv)->ggtt);
> /* Must be called after GGTT is resumed. */
> intel_dpt_resume(dev_priv);
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 28c1524e2e3b..65724e4df3bd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1762,7 +1762,7 @@ static inline bool
> i915_gem_object_needs_bit17_swizzle(struct drm_i915_gem_objec
> {
> struct drm_i915_private *i915 = to_i915(obj->base.dev);
>
> - return i915->ggtt.bit_6_swizzle_x == I915_BIT_6_SWIZZLE_9_10_17 &&
> + return to_gt(i915)->ggtt->bit_6_swizzle_x == I915_BIT_6_SWIZZLE_9_10_17
> &&
> i915_gem_object_is_tiled(obj);
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 8ba2119092f2..45e3b4c540a1 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -88,7 +88,8 @@ int
> i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
>
Re: [PATCH v8 14/16] drm/i915/selftests: Use to_gt() helper for GGTT accesses
On Tue, Dec 14, 2021 at 09:33:44PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> GGTT is currently available both through i915->ggtt and gt->ggtt, and we
> eventually want to get rid of the i915->ggtt one.
> Use to_gt() for all i915->ggtt accesses to help with the future
> refactoring.
>
> Signed-off-by: Michał Winiarski
> Cc: Michal Wajdeczko
> Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/selftests/i915_gem.c| 8
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c| 6 +++---
> drivers/gpu/drm/i915/selftests/i915_request.c| 2 +-
> drivers/gpu/drm/i915/selftests/i915_vma.c| 2 +-
> drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
> 5 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c
> b/drivers/gpu/drm/i915/selftests/i915_gem.c
> index b5576888cd78..1628b81d0a35 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
> @@ -41,7 +41,7 @@ static int switch_to_context(struct i915_gem_context *ctx)
>
> static void trash_stolen(struct drm_i915_private *i915)
> {
> - struct i915_ggtt *ggtt = &i915->ggtt;
> + struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
> const u64 slot = ggtt->error_capture.start;
> const resource_size_t size = resource_size(&i915->dsm);
> unsigned long page;
> @@ -99,7 +99,7 @@ static void igt_pm_suspend(struct drm_i915_private *i915)
> intel_wakeref_t wakeref;
>
> with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
> - i915_ggtt_suspend(&i915->ggtt);
> + i915_ggtt_suspend(to_gt(i915)->ggtt);
> i915_gem_suspend_late(i915);
> }
> }
> @@ -109,7 +109,7 @@ static void igt_pm_hibernate(struct drm_i915_private
> *i915)
> intel_wakeref_t wakeref;
>
> with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
> - i915_ggtt_suspend(&i915->ggtt);
> + i915_ggtt_suspend(to_gt(i915)->ggtt);
>
> i915_gem_freeze(i915);
> i915_gem_freeze_late(i915);
> @@ -125,7 +125,7 @@ static void igt_pm_resume(struct drm_i915_private *i915)
>* that runtime-pm just works.
>*/
> with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
> - i915_ggtt_resume(&i915->ggtt);
> + i915_ggtt_resume(to_gt(i915)->ggtt);
> i915_gem_resume(i915);
> }
> }
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> index 48123c3e1ff0..9afe7cf9d068 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> @@ -1122,7 +1122,7 @@ static int exercise_ggtt(struct drm_i915_private *i915,
>u64 hole_start, u64 hole_end,
>unsigned long end_time))
> {
> - struct i915_ggtt *ggtt = &i915->ggtt;
> + struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
> u64 hole_start, hole_end, last = 0;
> struct drm_mm_node *node;
> IGT_TIMEOUT(end_time);
> @@ -1182,7 +1182,7 @@ static int igt_ggtt_page(void *arg)
> const unsigned int count = PAGE_SIZE/sizeof(u32);
> I915_RND_STATE(prng);
> struct drm_i915_private *i915 = arg;
> - struct i915_ggtt *ggtt = &i915->ggtt;
> + struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
> struct drm_i915_gem_object *obj;
> intel_wakeref_t wakeref;
> struct drm_mm_node tmp;
> @@ -2110,7 +2110,7 @@ int i915_gem_gtt_live_selftests(struct drm_i915_private
> *i915)
> SUBTEST(igt_cs_tlb),
> };
>
> - GEM_BUG_ON(offset_in_page(i915->ggtt.vm.total));
> + GEM_BUG_ON(offset_in_page(to_gt(i915)->ggtt->vm.total));
>
> return i915_subtests(tests, i915);
> }
> diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
> b/drivers/gpu/drm/i915/selftests/i915_request.c
> index 92a859b34190..7f66f6d299b2 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_request.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_request.c
> @@ -843,7 +843,7 @@ static struct i915_vma *empty_batch(struct
> drm_i915_private *i915)
>
> intel_gt_chipset_flush(to_gt(i915));
>
> - vma = i915_vma_instance(obj, &i915->ggtt.vm, NULL);
> + vma = i915_vma_instance(obj, &to_gt(i915)->ggtt->vm, NULL);
> if (IS_ERR(vma)) {
> err = PTR_ERR(vma);
> goto err;
> diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c
> b/drivers/gpu/drm/i915/selftests/i915_vma.c
> index 1f10fe36619b..6ac15d3bc5bc 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_vma.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_vma.c
> @@ -967,7 +967,7 @@ static int igt_vma_remapped_gtt(void *arg)
> intel_wakeref_t wakeref;
> int err = 0;
>
> - if (!i915_ggtt_has_aperture(&i915->ggtt))
> + if (!i915_ggtt_has_aperture(to_gt(i915)->ggtt))
> return 0;
>
>
Re: [PATCH v8 13/16] drm/i915/gt: Use to_gt() helper for GGTT accesses
On Tue, Dec 14, 2021 at 09:33:43PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> GGTT is currently available both through i915->ggtt and gt->ggtt, and we
> eventually want to get rid of the i915->ggtt one.
> Use to_gt() for all i915->ggtt accesses to help with the future
> refactoring.
>
> Signed-off-by: Michał Winiarski
> Cc: Michal Wajdeczko
> Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 14 +++---
> drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 6 +++---
> drivers/gpu/drm/i915/gt/intel_region_lmem.c | 4 ++--
> drivers/gpu/drm/i915/gt/selftest_reset.c | 2 +-
> 4 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index 971e737b37b2..ec3b998392ff 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -89,7 +89,7 @@ int i915_ggtt_init_hw(struct drm_i915_private *i915)
>* beyond the end of the batch buffer, across the page boundary,
>* and beyond the end of the GTT if we do not provide a guard.
>*/
> - ret = ggtt_init_hw(&i915->ggtt);
> + ret = ggtt_init_hw(to_gt(i915)->ggtt);
> if (ret)
> return ret;
>
> @@ -725,14 +725,14 @@ int i915_init_ggtt(struct drm_i915_private *i915)
> {
> int ret;
>
> - ret = init_ggtt(&i915->ggtt);
> + ret = init_ggtt(to_gt(i915)->ggtt);
> if (ret)
> return ret;
>
> if (INTEL_PPGTT(i915) == INTEL_PPGTT_ALIASING) {
> - ret = init_aliasing_ppgtt(&i915->ggtt);
> + ret = init_aliasing_ppgtt(to_gt(i915)->ggtt);
> if (ret)
> - cleanup_init_ggtt(&i915->ggtt);
> + cleanup_init_ggtt(to_gt(i915)->ggtt);
> }
>
> return 0;
> @@ -775,7 +775,7 @@ static void ggtt_cleanup_hw(struct i915_ggtt *ggtt)
> */
> void i915_ggtt_driver_release(struct drm_i915_private *i915)
> {
> - struct i915_ggtt *ggtt = &i915->ggtt;
> + struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
>
> fini_aliasing_ppgtt(ggtt);
>
> @@ -790,7 +790,7 @@ void i915_ggtt_driver_release(struct drm_i915_private
> *i915)
> */
> void i915_ggtt_driver_late_release(struct drm_i915_private *i915)
> {
> - struct i915_ggtt *ggtt = &i915->ggtt;
> + struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
>
> GEM_WARN_ON(kref_read(&ggtt->vm.resv_ref) != 1);
> dma_resv_fini(&ggtt->vm._resv);
> @@ -1232,7 +1232,7 @@ int i915_ggtt_probe_hw(struct drm_i915_private *i915)
> {
> int ret;
>
> - ret = ggtt_probe_hw(&i915->ggtt, to_gt(i915));
> + ret = ggtt_probe_hw(to_gt(i915)->ggtt, to_gt(i915));
> if (ret)
> return ret;
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> index f8948de72036..beabf3bc9b75 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> @@ -728,8 +728,8 @@ static void detect_bit_6_swizzle(struct i915_ggtt *ggtt)
> swizzle_y = I915_BIT_6_SWIZZLE_NONE;
> }
>
> - i915->ggtt.bit_6_swizzle_x = swizzle_x;
> - i915->ggtt.bit_6_swizzle_y = swizzle_y;
> + to_gt(i915)->ggtt->bit_6_swizzle_x = swizzle_x;
> + to_gt(i915)->ggtt->bit_6_swizzle_y = swizzle_y;
> }
>
> /*
> @@ -896,7 +896,7 @@ void intel_gt_init_swizzling(struct intel_gt *gt)
> struct intel_uncore *uncore = gt->uncore;
>
> if (GRAPHICS_VER(i915) < 5 ||
> - i915->ggtt.bit_6_swizzle_x == I915_BIT_6_SWIZZLE_NONE)
> + to_gt(i915)->ggtt->bit_6_swizzle_x == I915_BIT_6_SWIZZLE_NONE)
> return;
>
> intel_uncore_rmw(uncore, DISP_ARB_CTL, 0, DISP_TILE_SURFACE_SWIZZLING);
> diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> index fde2dcb59809..21215a080088 100644
> --- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> +++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> @@ -15,7 +15,7 @@
> static int init_fake_lmem_bar(struct intel_memory_region *mem)
> {
> struct drm_i915_private *i915 = mem->i915;
> - struct i915_ggtt *ggtt = &i915->ggtt;
> + struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
> unsigned long n;
> int ret;
>
> @@ -131,7 +131,7 @@ intel_gt_setup_fake_lmem(struct intel_gt *gt)
> if (!i915->params.fake_lmem_start)
> return ERR_PTR(-ENODEV);
>
> - GEM_BUG_ON(i915_ggtt_has_aperture(&i915->ggtt));
> + GEM_BUG_ON(i915_ggtt_has_aperture(to_gt(i915)->ggtt));
>
> /* Your mappable aperture belongs to me now! */
> mappable_end = pci_resource_len(pdev, 2);
> diff --git a/drivers/gpu/drm/i915/gt/selftest_reset.c
> b/drivers/gpu/drm/i915/gt/selftest_reset.c
> index 8a873f6bda7f..37c38bdd5f47 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_reset.c
> +++ b/drivers/gpu/
Re: [PATCH v8 12/16] drm/i915/display: Use to_gt() helper for GGTT accesses
On Tue, Dec 14, 2021 at 09:33:42PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> GGTT is currently available both through i915->ggtt and gt->ggtt, and we
> eventually want to get rid of the i915->ggtt one.
> Use to_gt() for all i915->ggtt accesses to help with the future
> refactoring.
>
> Signed-off-by: Michał Winiarski
> Cc: Michal Wajdeczko
> Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
> drivers/gpu/drm/i915/display/intel_fbdev.c | 2 +-
> drivers/gpu/drm/i915/display/intel_plane_initial.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 8be01b93015f..98319c0322d7 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -595,7 +595,7 @@ static void ivb_fbc_activate(struct intel_fbc *fbc)
> else if (DISPLAY_VER(i915) == 9)
> skl_fbc_program_cfb_stride(fbc);
>
> - if (i915->ggtt.num_fences)
> + if (to_gt(i915)->ggtt->num_fences)
> snb_fbc_program_fence(fbc);
>
> intel_de_write(i915, ILK_DPFC_CONTROL,
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
> b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index adc3a81be9f7..41d279db2be6 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -180,7 +180,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
> struct drm_device *dev = helper->dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
> - struct i915_ggtt *ggtt = &dev_priv->ggtt;
> + struct i915_ggtt *ggtt = to_gt(dev_priv)->ggtt;
> const struct i915_ggtt_view view = {
> .type = I915_GGTT_VIEW_NORMAL,
> };
> diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> index 01ce1d72297f..e4186a0b8edb 100644
> --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> @@ -94,7 +94,7 @@ initial_plane_vma(struct drm_i915_private *i915,
> goto err_obj;
> }
>
> - vma = i915_vma_instance(obj, &i915->ggtt.vm, NULL);
> + vma = i915_vma_instance(obj, &to_gt(i915)->ggtt->vm, NULL);
> if (IS_ERR(vma))
> goto err_obj;
>
> --
> 2.34.1
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
Re: [PATCH v8 11/16] drm/i915/gem: Use to_gt() helper for GGTT accesses
On Tue, Dec 14, 2021 at 09:33:41PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> GGTT is currently available both through i915->ggtt and gt->ggtt, and we
> eventually want to get rid of the i915->ggtt one.
> Use to_gt() for all i915->ggtt accesses to help with the future
> refactoring.
>
> Signed-off-by: Michał Winiarski
> Cc: Michal Wajdeczko
> Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.h | 2 +-
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 19 ++-
> drivers/gpu/drm/i915/gem/i915_gem_pm.c| 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 6 +++---
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 8 +---
> drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 15 ---
> .../i915/gem/selftests/i915_gem_client_blt.c | 2 +-
> .../drm/i915/gem/selftests/i915_gem_context.c | 2 +-
> .../drm/i915/gem/selftests/i915_gem_mman.c| 19 ++-
> .../drm/i915/gem/selftests/i915_gem_object.c | 2 +-
> 11 files changed, 42 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> index babfecb17ad1..e5b0f66ea1fe 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> @@ -174,7 +174,7 @@ i915_gem_context_get_eb_vm(struct i915_gem_context *ctx)
>
> vm = ctx->vm;
> if (!vm)
> - vm = &ctx->i915->ggtt.vm;
> + vm = &to_gt(ctx->i915)->ggtt->vm;
> vm = i915_vm_get(vm);
>
> return vm;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index ec7c4a29a720..3078611d5bfe 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1106,7 +1106,7 @@ static inline struct i915_ggtt *cache_to_ggtt(struct
> reloc_cache *cache)
> {
> struct drm_i915_private *i915 =
> container_of(cache, struct i915_execbuffer, reloc_cache)->i915;
> - return &i915->ggtt;
> + return to_gt(i915)->ggtt;
> }
>
> static void reloc_cache_reset(struct reloc_cache *cache, struct
> i915_execbuffer *eb)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index 1ca5c062974e..a9effb34d7ed 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -295,7 +295,7 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
> struct drm_device *dev = obj->base.dev;
> struct drm_i915_private *i915 = to_i915(dev);
> struct intel_runtime_pm *rpm = &i915->runtime_pm;
> - struct i915_ggtt *ggtt = &i915->ggtt;
> + struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
> bool write = area->vm_flags & VM_WRITE;
> struct i915_gem_ww_ctx ww;
> intel_wakeref_t wakeref;
> @@ -388,16 +388,16 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
> assert_rpm_wakelock_held(rpm);
>
> /* Mark as being mmapped into userspace for later revocation */
> - mutex_lock(&i915->ggtt.vm.mutex);
> + mutex_lock(&to_gt(i915)->ggtt->vm.mutex);
> if (!i915_vma_set_userfault(vma) && !obj->userfault_count++)
> - list_add(&obj->userfault_link, &i915->ggtt.userfault_list);
> - mutex_unlock(&i915->ggtt.vm.mutex);
> + list_add(&obj->userfault_link,
> &to_gt(i915)->ggtt->userfault_list);
> + mutex_unlock(&to_gt(i915)->ggtt->vm.mutex);
>
> /* Track the mmo associated with the fenced vma */
> vma->mmo = mmo;
>
> if (CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
> - intel_wakeref_auto(&i915->ggtt.userfault_wakeref,
> + intel_wakeref_auto(&to_gt(i915)->ggtt->userfault_wakeref,
>
> msecs_to_jiffies_timeout(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND));
>
> if (write) {
> @@ -512,7 +512,7 @@ void i915_gem_object_release_mmap_gtt(struct
> drm_i915_gem_object *obj)
>* wakeref.
>*/
> wakeref = intel_runtime_pm_get(&i915->runtime_pm);
> - mutex_lock(&i915->ggtt.vm.mutex);
> + mutex_lock(&to_gt(i915)->ggtt->vm.mutex);
>
> if (!obj->userfault_count)
> goto out;
> @@ -530,7 +530,7 @@ void i915_gem_object_release_mmap_gtt(struct
> drm_i915_gem_object *obj)
> wmb();
>
> out:
> - mutex_unlock(&i915->ggtt.vm.mutex);
> + mutex_unlock(&to_gt(i915)->ggtt->vm.mutex);
> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
> }
>
> @@ -733,13 +733,14 @@ i915_gem_dumb_mmap_offset(struct drm_file *file,
> u32 handle,
> u64 *offset)
> {
> + struct drm_i915_private *i915 = to_i915(dev);
> enum i915_mmap_type mmap_type;
>
> if (HAS_LMEM(to_i915(dev)))
> mmap_type = I9
[PATCH] drm/amd/display: Fix the uninitialized variable in enable_stream_features()
In function enable_stream_features(), the variable "old_downspread.raw"
could be uninitialized if core_link_read_dpcd() fails, however, it is
used in the later if statement, and further, core_link_write_dpcd()
may write random value, which is potentially unsafe.
Fixes: 6016cd9dba0f ("drm/amd/display: add helper for enabling mst stream
features")
Cc: sta...@vger.kernel.org
Signed-off-by: Yizhuo Zhai
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index c8457babfdea..fd5a0e7eb029 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -1844,6 +1844,8 @@ static void enable_stream_features(struct pipe_ctx
*pipe_ctx)
union down_spread_ctrl old_downspread;
union down_spread_ctrl new_downspread;
+ memset(&old_downspread, 0, sizeof(old_downspread));
+
core_link_read_dpcd(link, DP_DOWNSPREAD_CTRL,
&old_downspread.raw, sizeof(old_downspread));
--
2.25.1
Re: [PATCH] In function nvkm_ioctl_map(), the variable "type" could be uninitialized if "nvkm_object_map()" returns error code, however, it does not check the return value and directly use the "type"
Hi Lyude:
I appreciate your feedback and I misplaced the commit message to the
title, I have modified it and resend the patch.
I made my linux development tree a mess, so I sent a brandly new one
and cc you. Thanks again for your help: )
On Tue, Nov 16, 2021 at 1:18 PM Lyude Paul wrote:
>
> This is a very long patch name, it should probably be shorter and the
> details in the patch title moved into the actual commit description
> instead. Also a couple of things aren't formatted correctly:
>
> * Cc tag for stable is missing, see
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> * Fixes tag isn't formatted properly
>
> I generally recommend using `dim fixes` from
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> in order to get the correct stable kernel CC tag and Fixes: tag (you can
> drop any of the Ccs it gives you beyond the one to stable at vger dot
> kernel dot org.
>
> Also, if you could try to Cc: me on the next version - will help me
> respond faster :).
>
> On Mon, 2021-11-15 at 23:07 -0800, Yizhuo Zhai wrote:
> > Fixes:01326050391ce("drm/nouveau/core/object: allow arguments to
> > be passed to map function")
> > Signed-off-by: Yizhuo Zhai
> > ---
> > drivers/gpu/drm/nouveau/nvkm/core/ioctl.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c
> > b/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c
> > index 735cb6816f10..4264d9d79783 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c
> > @@ -266,6 +266,8 @@ nvkm_ioctl_map(struct nvkm_client *client,
> > ret = nvkm_object_map(object, data, size, &type,
> > &args->v0.handle,
> > &args->v0.length);
> > + if (ret)
> > + return ret;
> > if (type == NVKM_OBJECT_MAP_IO)
> > args->v0.type = NVIF_IOCTL_MAP_V0_IO;
> > else
>
> --
> Cheers,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
>
--
Kind Regards,
Yizhuo Zhai
Computer Science, Graduate Student
University of California, Riverside
[PATCH] drm/nouveau/core/object: Fix the uninitialized use of "type"
In function nvkm_ioctl_map(), the variable "type" could be
uninitialized if "nvkm_object_map()" returns error code, however,
it does not check the return value and directly use the "type" in
the if statement, which is potentially unsafe.
Cc: sta...@vger.kernel.org
Fixes: 01326050391c ("drm/nouveau/core/object: allow arguments to be passed to
map function")
Signed-off-by: Yizhuo Zhai
---
drivers/gpu/drm/nouveau/nvkm/core/ioctl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c
b/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c
index 735cb6816f10..4264d9d79783 100644
--- a/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c
+++ b/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c
@@ -266,6 +266,8 @@ nvkm_ioctl_map(struct nvkm_client *client,
ret = nvkm_object_map(object, data, size, &type,
&args->v0.handle,
&args->v0.length);
+ if (ret)
+ return ret;
if (type == NVKM_OBJECT_MAP_IO)
args->v0.type = NVIF_IOCTL_MAP_V0_IO;
else
--
2.25.1
Re: [PATCH v4 0/6] drm: exynos: dsi: Convert drm bridge
Hi Jagan,
On 15.12.2021 15:56, Jagan Teki wrote:
> On Wed, Dec 15, 2021 at 7:49 PM Marek Szyprowski
> wrote:
>> On 15.12.2021 13:57, Jagan Teki wrote:
>>> On Wed, Dec 15, 2021 at 5:31 PM Marek Szyprowski
>>> wrote:
On 15.12.2021 11:15, Jagan Teki wrote:
> Updated series about drm bridge conversion of exynos dsi.
> Previous version can be accessible, here [1].
>
> Patch 1: connector reset
>
> Patch 2: panel_bridge API
>
> Patch 3: Bridge conversion
>
> Patch 4: Atomic functions
>
> Patch 5: atomic_set
>
> Patch 6: DSI init in enable
There is a little progress! :)
Devices with a simple display pipeline (only a DSI panel, like
Trats/Trats2) works till the last patch. Then, after applying ("[PATCH
v4 6/6] drm: exynos: dsi: Move DSI init in bridge enable"), I get no
display at all.
A TM2e board with in-bridge (Exynos MIC) stops displaying anything after
applying patch "[PATCH v4 2/6] drm: exynos: dsi: Use drm panel_bridge API".
In case of the Arndale board with tc358764 bridge, no much progress. The
display is broken just after applying the "[PATCH v2] drm: bridge:
tc358764: Use drm panel_bridge API" patch on top of linux-next.
In all cases the I had "drm: of: Lookup if child node has panel or
bridge" patch applied.
>>> Just skip the 6/6 for now.
>>>
>>> Apply
>>> -
>>> https://protect2.fireeye.com/v1/url?k=a24f3f76-fdd40659-a24eb439-0cc47a31cdf8-97ea12b4c5258d11&q=1&e=37a169bf-7ca5-4362-aad7-486018c7a708&u=https%3A%2F%2Fpatchwork.amarulasolutions.com%2Fpatch%2F1825%2F
>>> -
>>> https://protect2.fireeye.com/v1/url?k=a226360f-fdbd0f20-a227bd40-0cc47a31cdf8-ebd66aebee1058d7&q=1&e=37a169bf-7ca5-4362-aad7-486018c7a708&u=https%3A%2F%2Fpatchwork.amarulasolutions.com%2Fpatch%2F1823%2F
>>>
>>> Then apply 1/6 to 5/6. and update the status?
>> Okay, my fault, I didn't check that case on Arndale.
>>
>> I've checked and indeed, Trats/Trats2 and Arndale works after the above
>> 2 patches AND patches 1-5.
>>
>> The only problem is now on TM2e, which uses Exynos MIC as in-bridge for
>> Exynos DSI:
>>
>> [4.068866] [drm] Exynos DRM: using 1380.decon device for DMA
>> mapping operations
>> [4.069183] exynos-drm exynos-drm: bound 1380.decon (ops
>> decon_component_ops)
>> [4.128983] exynos-drm exynos-drm: bound 1388.decon (ops
>> decon_component_ops)
>> [4.129261] exynos-drm exynos-drm: bound 1393.mic (ops
>> exynos_mic_component_ops)
>> [4.133508] exynos-dsi 1390.dsi: [drm:exynos_dsi_host_attach]
>> *ERROR* failed to find the bridge: -19
>> [4.136392] exynos-drm exynos-drm: bound 1390.dsi (ops
>> exynos_dsi_component_ops)
>> [4.145499] rc_core: Couldn't load IR keymap rc-cec
>> [4.145666] Registered IR keymap rc-empty
>> [4.148402] rc rc0: sii8620 as /devices/virtual/rc/rc0
>> [4.156051] input: sii8620 as /devices/virtual/rc/rc0/input1
>> [4.160647] exynos-drm exynos-drm: bound 1397.hdmi (ops
>> hdmi_component_ops)
>> [4.169923] exynos-drm exynos-drm: [drm] Cannot find any crtc or sizes
>> [4.173958] exynos-drm exynos-drm: [drm] Cannot find any crtc or sizes
>> [4.182304] [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on
>> minor 0
>>
>> The display pipeline for TM2e is:
>>
>> Exynos5433 Decon -> Exynos MIC -> Exynos DSI -> s6e3ha2 DSI panel
> If Trats/Trats2 is working then it has to work. I don't see any
> difference in output pipeline. Can you please share the full log, I
> cannot see host_attach print saying "Attached.."
Well, there is a failure message about the panel:
exynos-dsi 1390.dsi: [drm:exynos_dsi_host_attach] *ERROR* failed to
find the bridge: -19
however it looks that something might be broken in dts. The in-bridge
(Exynos MIC) is on port 0 and the panel is @0, what imho might cause the
issue.
I've tried to change in in-bridge ('mic_to_dsi') port to 1 in
exynos5433.dtsi. Then the panel has been attached:
exynos-dsi 1390.dsi: [drm:exynos_dsi_host_attach] Attached s6e3hf2
device
but the display is still not working, probably due to lack of proper
Exynos MIC handling. I will investigate it later and let You know.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
[RFC 5/6] drm/amdgpu: Drop hive->in_reset
Since we serialize all resets no need to protect from concurrent
resets.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 19 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h | 1 -
3 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 55cd67b9ede2..d2701e4d0622 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -5013,25 +5013,9 @@ int amdgpu_device_gpu_recover_imp(struct amdgpu_device
*adev,
dev_info(adev->dev, "GPU %s begin!\n",
need_emergency_restart ? "jobs stop":"reset");
- /*
-* Here we trylock to avoid chain of resets executing from
-* either trigger by jobs on different adevs in XGMI hive or jobs on
-* different schedulers for same device while this TO handler is
running.
-* We always reset all schedulers for device and all devices for XGMI
-* hive so that should take care of them too.
-*/
hive = amdgpu_get_xgmi_hive(adev);
- if (hive) {
- if (atomic_cmpxchg(&hive->in_reset, 0, 1) != 0) {
- DRM_INFO("Bailing on TDR for s_job:%llx, hive: %llx as
another already in progress",
- job ? job->base.id : -1, hive->hive_id);
- amdgpu_put_xgmi_hive(hive);
- if (job && job->vm)
- drm_sched_increase_karma(&job->base);
- return 0;
- }
+ if (hive)
mutex_lock(&hive->hive_lock);
- }
reset_context.method = AMD_RESET_METHOD_NONE;
reset_context.reset_req_dev = adev;
@@ -5226,7 +5210,6 @@ int amdgpu_device_gpu_recover_imp(struct amdgpu_device
*adev,
skip_recovery:
if (hive) {
- atomic_set(&hive->in_reset, 0);
mutex_unlock(&hive->hive_lock);
amdgpu_put_xgmi_hive(hive);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
index 8b116f398101..0d54bef5c494 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
@@ -403,7 +403,6 @@ struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct
amdgpu_device *adev)
INIT_LIST_HEAD(&hive->device_list);
INIT_LIST_HEAD(&hive->node);
mutex_init(&hive->hive_lock);
- atomic_set(&hive->in_reset, 0);
atomic_set(&hive->number_devices, 0);
task_barrier_init(&hive->tb);
hive->pstate = AMDGPU_XGMI_PSTATE_UNKNOWN;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h
index 6121aaa292cb..2f2ce53645a5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h
@@ -33,7 +33,6 @@ struct amdgpu_hive_info {
struct list_head node;
atomic_t number_devices;
struct mutex hive_lock;
- atomic_t in_reset;
int hi_req_count;
struct amdgpu_device *hi_req_gpu;
struct task_barrier tb;
--
2.25.1
[RFC 4/6] drm/amdgpu: Serialize non TDR gpu recovery with TDRs
Use reset domain wq also for non TDR gpu recovery trigers
such as sysfs and RAS. We must serialize all possible
GPU recoveries to gurantee no concurrency there.
For TDR call the original recovery function directly since
it's already executed from within the wq. For others just
use a wrapper to qeueue work and wait on it to finish.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 33 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c| 2 +-
3 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index b5ff76aae7e0..8e96b9a14452 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1296,6 +1296,8 @@ bool amdgpu_device_has_job_running(struct amdgpu_device
*adev);
bool amdgpu_device_should_recover_gpu(struct amdgpu_device *adev);
int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
struct amdgpu_job* job);
+int amdgpu_device_gpu_recover_imp(struct amdgpu_device *adev,
+ struct amdgpu_job *job);
void amdgpu_device_pci_config_reset(struct amdgpu_device *adev);
int amdgpu_device_pci_reset(struct amdgpu_device *adev);
bool amdgpu_device_need_post(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b595e6d699b5..55cd67b9ede2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4979,7 +4979,7 @@ static void amdgpu_device_recheck_guilty_jobs(
* Returns 0 for success or an error on failure.
*/
-int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
+int amdgpu_device_gpu_recover_imp(struct amdgpu_device *adev,
struct amdgpu_job *job)
{
struct list_head device_list, *device_list_handle = NULL;
@@ -5236,6 +5236,37 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
return r;
}
+struct recover_work_struct {
+ struct work_struct base;
+ struct amdgpu_device *adev;
+ struct amdgpu_job *job;
+ int ret;
+};
+
+static void amdgpu_device_queue_gpu_recover_work(struct work_struct *work)
+{
+ struct recover_work_struct *recover_work = container_of(work, struct
recover_work_struct, base);
+
+ recover_work->ret = amdgpu_device_gpu_recover_imp(recover_work->adev,
recover_work->job);
+}
+/*
+ * Serialize gpu recover into reset domain single threaded wq
+ */
+int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
+ struct amdgpu_job *job)
+{
+ struct recover_work_struct work = {.adev = adev, .job = job};
+
+ INIT_WORK(&work.base, amdgpu_device_queue_gpu_recover_work);
+
+ if (!queue_work(adev->reset_domain.wq, &work.base))
+ return -EAGAIN;
+
+ flush_work(&work.base);
+
+ return work.ret;
+}
+
/**
* amdgpu_device_get_pcie_info - fence pcie info about the PCIE slot
*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index bfc47bea23db..38c9fd7b7ad4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -63,7 +63,7 @@ static enum drm_gpu_sched_stat amdgpu_job_timedout(struct
drm_sched_job *s_job)
ti.process_name, ti.tgid, ti.task_name, ti.pid);
if (amdgpu_device_should_recover_gpu(ring->adev)) {
- amdgpu_device_gpu_recover(ring->adev, job);
+ amdgpu_device_gpu_recover_imp(ring->adev, job);
} else {
drm_sched_suspend_timeout(&ring->sched);
if (amdgpu_sriov_vf(adev))
--
2.25.1
[RFC 6/6] drm/amdgpu: Drop concurrent GPU reset protection for device
Since now all GPU resets are serialzied there is no need for this.
This patch also reverts 'drm/amdgpu: race issue when jobs on 2 ring timeout'
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 89 ++
1 file changed, 7 insertions(+), 82 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index d2701e4d0622..311e0b9e1e4f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4763,11 +4763,10 @@ int amdgpu_do_asic_reset(struct list_head
*device_list_handle,
return r;
}
-static bool amdgpu_device_lock_adev(struct amdgpu_device *adev,
+static void amdgpu_device_lock_adev(struct amdgpu_device *adev,
struct amdgpu_hive_info *hive)
{
- if (atomic_cmpxchg(&adev->in_gpu_reset, 0, 1) != 0)
- return false;
+ atomic_set(&adev->in_gpu_reset, 1);
if (hive) {
down_write_nest_lock(&adev->reset_sem, &hive->hive_lock);
@@ -4786,8 +4785,6 @@ static bool amdgpu_device_lock_adev(struct amdgpu_device
*adev,
adev->mp1_state = PP_MP1_STATE_NONE;
break;
}
-
- return true;
}
static void amdgpu_device_unlock_adev(struct amdgpu_device *adev)
@@ -4798,46 +4795,6 @@ static void amdgpu_device_unlock_adev(struct
amdgpu_device *adev)
up_write(&adev->reset_sem);
}
-/*
- * to lockup a list of amdgpu devices in a hive safely, if not a hive
- * with multiple nodes, it will be similar as amdgpu_device_lock_adev.
- *
- * unlock won't require roll back.
- */
-static int amdgpu_device_lock_hive_adev(struct amdgpu_device *adev, struct
amdgpu_hive_info *hive)
-{
- struct amdgpu_device *tmp_adev = NULL;
-
- if (adev->gmc.xgmi.num_physical_nodes > 1) {
- if (!hive) {
- dev_err(adev->dev, "Hive is NULL while device has
multiple xgmi nodes");
- return -ENODEV;
- }
- list_for_each_entry(tmp_adev, &hive->device_list,
gmc.xgmi.head) {
- if (!amdgpu_device_lock_adev(tmp_adev, hive))
- goto roll_back;
- }
- } else if (!amdgpu_device_lock_adev(adev, hive))
- return -EAGAIN;
-
- return 0;
-roll_back:
- if (!list_is_first(&tmp_adev->gmc.xgmi.head, &hive->device_list)) {
- /*
-* if the lockup iteration break in the middle of a hive,
-* it may means there may has a race issue,
-* or a hive device locked up independently.
-* we may be in trouble and may not, so will try to roll back
-* the lock and give out a warnning.
-*/
- dev_warn(tmp_adev->dev, "Hive lock iteration broke in the
middle. Rolling back to unlock");
- list_for_each_entry_continue_reverse(tmp_adev,
&hive->device_list, gmc.xgmi.head) {
- amdgpu_device_unlock_adev(tmp_adev);
- }
- }
- return -EAGAIN;
-}
-
static void amdgpu_device_resume_display_audio(struct amdgpu_device *adev)
{
struct pci_dev *p = NULL;
@@ -5023,22 +4980,6 @@ int amdgpu_device_gpu_recover_imp(struct amdgpu_device
*adev,
reset_context.hive = hive;
clear_bit(AMDGPU_NEED_FULL_RESET, &reset_context.flags);
- /*
-* lock the device before we try to operate the linked list
-* if didn't get the device lock, don't touch the linked list since
-* others may iterating it.
-*/
- r = amdgpu_device_lock_hive_adev(adev, hive);
- if (r) {
- dev_info(adev->dev, "Bailing on TDR for s_job:%llx, as another
already in progress",
- job ? job->base.id : -1);
-
- /* even we skipped this reset, still need to set the job to
guilty */
- if (job && job->vm)
- drm_sched_increase_karma(&job->base);
- goto skip_recovery;
- }
-
/*
* Build list of devices to reset.
* In case we are in XGMI hive mode, resort the device list
@@ -5058,6 +4999,9 @@ int amdgpu_device_gpu_recover_imp(struct amdgpu_device
*adev,
/* block all schedulers and reset given job's ring */
list_for_each_entry(tmp_adev, device_list_handle, reset_list) {
+
+ amdgpu_device_lock_adev(tmp_adev, hive);
+
/*
* Try to put the audio codec into suspend state
* before gpu reset started.
@@ -5208,13 +5152,12 @@ int amdgpu_device_gpu_recover_imp(struct amdgpu_device
*adev,
amdgpu_device_unlock_adev(tmp_adev);
}
-skip_recovery:
if (hive) {
mutex_unlock(&hive->hive_lock);
amdgpu_put_xgmi_hive(hive);
}
- if (r && r !
[RFC 3/6] drm/amdgpu: Fix crash on modprobe
Restrict jobs resubmission to suspend case
only since schedulers not initialised yet on
probe.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 5527c68c51de..8ebd954e06c6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -582,7 +582,7 @@ void amdgpu_fence_driver_hw_init(struct amdgpu_device *adev)
if (!ring || !ring->fence_drv.initialized)
continue;
- if (!ring->no_scheduler) {
+ if (adev->in_suspend && !ring->no_scheduler) {
drm_sched_resubmit_jobs(&ring->sched);
drm_sched_start(&ring->sched, true);
}
--
2.25.1
[RFC 2/6] drm/amdgpu: Move scheduler init to after XGMI is ready
Before we initialize schedulers we must know which reset
domain are we in - for single device there iis a single
domain per device and so single wq per device. For XGMI
the reset domain spans the entire XGMI hive and so the
reset wq is per hive.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 45 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 34 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 2 +
3 files changed, 51 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 5f13195d23d1..b595e6d699b5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2284,6 +2284,47 @@ static int amdgpu_device_fw_loading(struct amdgpu_device
*adev)
return r;
}
+static int amdgpu_device_init_schedulers(struct amdgpu_device *adev)
+{
+ long timeout;
+ int r, i;
+
+ for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
+ struct amdgpu_ring *ring = adev->rings[i];
+
+ /* No need to setup the GPU scheduler for rings that don't need
it */
+ if (!ring || ring->no_scheduler)
+ continue;
+
+ switch (ring->funcs->type) {
+ case AMDGPU_RING_TYPE_GFX:
+ timeout = adev->gfx_timeout;
+ break;
+ case AMDGPU_RING_TYPE_COMPUTE:
+ timeout = adev->compute_timeout;
+ break;
+ case AMDGPU_RING_TYPE_SDMA:
+ timeout = adev->sdma_timeout;
+ break;
+ default:
+ timeout = adev->video_timeout;
+ break;
+ }
+
+ r = drm_sched_init(&ring->sched, &amdgpu_sched_ops,
+ ring->num_hw_submission,
amdgpu_job_hang_limit,
+ timeout, adev->reset_domain.wq,
ring->sched_score, ring->name);
+ if (r) {
+ DRM_ERROR("Failed to create scheduler on ring %s.\n",
+ ring->name);
+ return r;
+ }
+ }
+
+ return 0;
+}
+
+
/**
* amdgpu_device_ip_init - run init for hardware IPs
*
@@ -2412,6 +2453,10 @@ static int amdgpu_device_ip_init(struct amdgpu_device
*adev)
}
}
+ r = amdgpu_device_init_schedulers(adev);
+ if (r)
+ goto init_failed;
+
/* Don't init kfd if whole hive need to be reset during init */
if (!adev->gmc.xgmi.pending_reset)
amdgpu_amdkfd_device_init(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 3b7e86ea7167..5527c68c51de 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -456,8 +456,6 @@ int amdgpu_fence_driver_init_ring(struct amdgpu_ring *ring,
atomic_t *sched_score)
{
struct amdgpu_device *adev = ring->adev;
- long timeout;
- int r;
if (!adev)
return -EINVAL;
@@ -477,36 +475,12 @@ int amdgpu_fence_driver_init_ring(struct amdgpu_ring
*ring,
spin_lock_init(&ring->fence_drv.lock);
ring->fence_drv.fences = kcalloc(num_hw_submission * 2, sizeof(void *),
GFP_KERNEL);
- if (!ring->fence_drv.fences)
- return -ENOMEM;
- /* No need to setup the GPU scheduler for rings that don't need it */
- if (ring->no_scheduler)
- return 0;
+ ring->num_hw_submission = num_hw_submission;
+ ring->sched_score = sched_score;
- switch (ring->funcs->type) {
- case AMDGPU_RING_TYPE_GFX:
- timeout = adev->gfx_timeout;
- break;
- case AMDGPU_RING_TYPE_COMPUTE:
- timeout = adev->compute_timeout;
- break;
- case AMDGPU_RING_TYPE_SDMA:
- timeout = adev->sdma_timeout;
- break;
- default:
- timeout = adev->video_timeout;
- break;
- }
-
- r = drm_sched_init(&ring->sched, &amdgpu_sched_ops,
- num_hw_submission, amdgpu_job_hang_limit,
- timeout, NULL, sched_score, ring->name);
- if (r) {
- DRM_ERROR("Failed to create scheduler on ring %s.\n",
- ring->name);
- return r;
- }
+ if (!ring->fence_drv.fences)
+ return -ENOMEM;
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index 4d380e79752c..a4b8279e3011 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -
[RFC 1/6] drm/amdgpu: Init GPU reset single threaded wq
Do it for both single device and XGMI hive cases.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 7 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 20 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 9 +
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h | 2 ++
4 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 9f017663ac50..b5ff76aae7e0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -812,6 +812,11 @@ struct amd_powerplay {
#define AMDGPU_RESET_MAGIC_NUM 64
#define AMDGPU_MAX_DF_PERFMONS 4
+
+struct amdgpu_reset_domain {
+ struct workqueue_struct *wq;
+};
+
struct amdgpu_device {
struct device *dev;
struct pci_dev *pdev;
@@ -1096,6 +1101,8 @@ struct amdgpu_device {
struct amdgpu_reset_control *reset_cntl;
uint32_t
ip_versions[HW_ID_MAX][HWIP_MAX_INSTANCE];
+
+ struct amdgpu_reset_domain reset_domain;
};
static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 5625f7736e37..5f13195d23d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2391,9 +2391,27 @@ static int amdgpu_device_ip_init(struct amdgpu_device
*adev)
if (r)
goto init_failed;
- if (adev->gmc.xgmi.num_physical_nodes > 1)
+ if (adev->gmc.xgmi.num_physical_nodes > 1) {
+ struct amdgpu_hive_info *hive;
+
amdgpu_xgmi_add_device(adev);
+ hive = amdgpu_get_xgmi_hive(adev);
+ if (!hive || !hive->reset_domain.wq) {
+ DRM_ERROR("Failed to obtain reset domain info for XGMI
hive:%llx", hive->hive_id);
+ r = -EINVAL;
+ goto init_failed;
+ }
+
+ adev->reset_domain.wq = hive->reset_domain.wq;
+ } else {
+ adev->reset_domain.wq =
alloc_ordered_workqueue("amdgpu-reset-dev", 0);
+ if (!adev->reset_domain.wq) {
+ r = -ENOMEM;
+ goto init_failed;
+ }
+ }
+
/* Don't init kfd if whole hive need to be reset during init */
if (!adev->gmc.xgmi.pending_reset)
amdgpu_amdkfd_device_init(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
index 0fad2bf854ae..8b116f398101 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
@@ -391,6 +391,14 @@ struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct
amdgpu_device *adev)
goto pro_end;
}
+ hive->reset_domain.wq = alloc_ordered_workqueue("amdgpu-reset-hive", 0);
+ if (!hive->reset_domain.wq) {
+ dev_err(adev->dev, "XGMI: failed allocating wq for reset
domain!\n");
+ kfree(hive);
+ hive = NULL;
+ goto pro_end;
+ }
+
hive->hive_id = adev->gmc.xgmi.hive_id;
INIT_LIST_HEAD(&hive->device_list);
INIT_LIST_HEAD(&hive->node);
@@ -400,6 +408,7 @@ struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct
amdgpu_device *adev)
task_barrier_init(&hive->tb);
hive->pstate = AMDGPU_XGMI_PSTATE_UNKNOWN;
hive->hi_req_gpu = NULL;
+
/*
* hive pstate on boot is high in vega20 so we have to go to low
* pstate on after boot.
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h
index d2189bf7d428..6121aaa292cb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h
@@ -42,6 +42,8 @@ struct amdgpu_hive_info {
AMDGPU_XGMI_PSTATE_MAX_VEGA20,
AMDGPU_XGMI_PSTATE_UNKNOWN
} pstate;
+
+ struct amdgpu_reset_domain reset_domain;
};
struct amdgpu_pcs_ras_field {
--
2.25.1
[RFC 0/6] Define and use reset domain for GPU recovery in amdgpu
This patchset is based on earlier work by Boris[1] that allowed to have an ordered workqueue at the driver level that will be used by the different schedulers to queue their timeout work. On top of that I also serialized any GPU reset we trigger from within amdgpu code to also go through the same ordered wq and in this way simplify somewhat our GPU reset code so we don't need to protect from concurrency by multiple GPU reset triggeres such as TDR on one hand and sysfs trigger or RAS trigger on the other hand. As advised by Christian and Daniel I defined a reset_domain struct such that all the entities that go through reset together will be serialized one against another. TDR triggered by multiple entities within the same domain due to the same reason will not be triggered as the first such reset will cancel all the pending resets. This is relevant only to TDR timers and not to triggered resets coming from RAS or SYSFS, those will still happen after the in flight resets finishes. [1] https://patchwork.kernel.org/project/dri-devel/patch/20210629073510.2764391-3-boris.brezil...@collabora.com/ P.S Going through drm-misc-next and not amd-staging-drm-next as Boris work hasn't landed yet there. Andrey Grodzovsky (6): drm/amdgpu: Init GPU reset single threaded wq drm/amdgpu: Move scheduler init to after XGMI is ready drm/amdgpu: Fix crash on modprobe drm/amdgpu: Serialize non TDR gpu recovery with TDRs drm/amdgpu: Drop hive->in_reset drm/amdgpu: Drop concurrent GPU reset protection for device drivers/gpu/drm/amd/amdgpu/amdgpu.h| 9 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 206 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 36 +--- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 10 +- drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h | 3 +- 7 files changed, 132 insertions(+), 136 deletions(-) -- 2.25.1
Re: [PATCH v7 2/8] dt-bindings: mediatek, dp: Add Display Port binding
On Fri, 17 Dec 2021 16:08:48 +0100, Guillaume Ranquet wrote: > From: Markus Schneider-Pargmann > > This controller is present on several mediatek hardware. Currently > mt8195 and mt8395 have this controller without a functional difference, > so only one compatible field is added. > > The controller can have two forms, as a normal display port and as an > embedded display port. > > Signed-off-by: Markus Schneider-Pargmann > Signed-off-by: Guillaume Ranquet > Reviewed-by: Rob Herring > --- > .../display/mediatek/mediatek,dp.yaml | 87 +++ > 1 file changed, 87 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Documentation/devicetree/bindings/display/mediatek/mediatek,dp.example.dts:20:18: fatal error: dt-bindings/power/mt8195-power.h: No such file or directory 20 | #include | ^~ compilation terminated. make[1]: *** [scripts/Makefile.lib:373: Documentation/devicetree/bindings/display/mediatek/mediatek,dp.example.dt.yaml] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [Makefile:1413: dt_binding_check] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/1570103 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
Re: [PATCH v2 1/2] dt-bindings: display: Turn lvds.yaml into a generic schema
On Fri, 17 Dec 2021 14:25:01 +0100, Maxime Ripard wrote:
> The lvds.yaml file so far was both defining the generic LVDS properties
> (such as data-mapping) that could be used for any LVDS sink, but also
> the panel-lvds binding.
>
> That last binding was to describe LVDS panels simple enough, and had a
> number of other bindings using it as a base to specialise it further.
>
> However, this situation makes it fairly hard to extend and reuse both
> the generic parts, and the panel-lvds itself.
>
> Let's remove the panel-lvds parts and leave only the generic LVDS
> properties.
>
> Reviewed-by: Rob Herring
> Signed-off-by: Maxime Ripard
>
> ---
>
> Changes from v1:
> - Moved the schema out of panel
> ---
> .../bindings/display/{panel => }/lvds.yaml| 31 ++-
> .../display/panel/advantech,idk-1110wr.yaml | 19 ++--
> .../display/panel/innolux,ee101ia-01d.yaml| 23 --
> .../display/panel/mitsubishi,aa104xd12.yaml | 19 ++--
> .../display/panel/mitsubishi,aa121td01.yaml | 19 ++--
> .../display/panel/sgd,gktw70sdae4se.yaml | 19 ++--
> 6 files changed, 91 insertions(+), 39 deletions(-)
> rename Documentation/devicetree/bindings/display/{panel => }/lvds.yaml (86%)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
Warning: Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
references a file that doesn't exist:
Documentation/devicetree/bindings/display/panel/lvds.yaml
Warning: MAINTAINERS references a file that doesn't exist:
Documentation/devicetree/bindings/display/panel/lvds.yaml
Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml:
Documentation/devicetree/bindings/display/panel/lvds.yaml
MAINTAINERS: Documentation/devicetree/bindings/display/panel/lvds.yaml
See https://patchwork.ozlabs.org/patch/1570028
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
Re: [git pull] drm fixes for 5.16-rc6
The pull request you sent on Fri, 17 Dec 2021 15:45:54 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-12-17-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4f549bf33e3824b3f4a719afaf0fd2e01a07acd6 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: Re: Re: 回复: Re: [PATCH] drm/amdgpu: fixup bad vram size on gmc v8
If you could get me a copy of the vbios image from a problematic board, that would be helpful. In the meantime, I've applied the patch. Alex On Thu, Dec 16, 2021 at 9:38 PM 周宗敏 wrote: > Dear Alex: > > > >Is the issue reproducible with the same board in bare metal on x86?Or > does it only happen with passthrough on ARM? > > > Unfortunately, my current environment is not convenient to test this GPU > board on x86 platform. > > but I can tell you the problem still occurs on ARM without passthrough to > virtual machine. > > > In addition,at end of 2020,my colleagues also found similar problems on > MIPS platforms with Graphics chips of Radeon R7 340. > > So,I may think it can happen to no matter based on x86 ,ARM or mips. > > > I hope the above information is helpful to you，and I also think it will be > better for user if can root cause this issue. > > > Best regards. > > > > > > > > > > > > *主 题：*Re: Re: 回复: Re: [PATCH] drm/amdgpu: fixup bad vram size on gmc v8 > > *日 期：*2021-12-16 23:28 > *发件人：*Alex Deucher > *收件人：*周宗敏 > > > Is the issue reproducible with the same board in bare metal on x86? Or > does it only happen with passthrough on ARM? Looking through the archives, > the SI patch I made was for an x86 laptop. It would be nice to root > cause this, but there weren't any gfx8 boards with more than 64G of vram, > so I think it's safe. That said, if you see similar issues with newer gfx > IPs then we have an issue since the upper bit will be meaningful, so it > would be nice to root cause this. > > Alex > > > On Thu, Dec 16, 2021 at 4:36 AM 周宗敏 wrote: > >> Hi Christian, >> >> >> I'm testing for GPU passthrough feature, so I pass through this GPU to >> virtual machine to use. It based on arm64 system. >> >> As far as i know, Alex had dealt with a similar problems on >> dri/radeon/si.c . Maybe they have a same reason to cause it? >> >> the history commit message is below: >> >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0ca223b029a261e82fb2f50c52eb85d510f4260e >> >> [image: image.png] >> >> >> Thanks very much. >> >> >> >> >> >> >> >> *主 题：*Re: 回复: Re: [PATCH] drm/amdgpu: fixup bad vram size on gmc v8 >> >> *日 期：*2021-12-16 16:15 >> *发件人：*Christian König >> *收件人：*周宗敏Alex Deucher >> >> >> >> >> Hi Zongmin, >> >>that strongly sounds like the ASIC is not correctly initialized when >> trying to read the register. >> >>What board and environment are you using this GPU with? Is that a >> normal x86 system? >> >>Regards, >>Christian. >> >> >> >> Am 16.12.21 um 04:11 schrieb 周宗敏: >> >> >> >>1. >> >>the problematic boards that I have tested is [AMD/ATI] Lexa >> PRO [Radeon RX 550/550X] ; and the vbios version : >> 113-RXF9310-C09-BT >>2. >> >>When an exception occurs I can see the following changes in >> the values of vram size get from RREG32(mmCONFIG_MEMSIZE) , >> >>it seems to have garbage in the upper 16 bits >> >>[image: image.png] >> >> >> >> >>3. >> >>and then I can also see some dmesg like below: >> >>when vram size register have garbage,we may see error >> message like below: >> >>amdgpu :09:00.0: VRAM: 4286582784M 0x00F4 - >> 0x000FF8F4 (4286582784M used) >> >>the correct message should like below: >> >>amdgpu :09:00.0: VRAM: 4096M 0x00F4 - >> 0x00F4 (4096M used) >> >> >> >> >>if you have any problems,please send me mail. >> >>thanks very much. >> >> >> >> >> >> >> *主 题：*Re: [PATCH] drm/amdgpu: fixup bad vram size on gmc v8 >> >>*日 期：*2021-12-16 04:23 >>*发件人：*Alex Deucher >>*收件人：*Zongmin Zhou >> >> >> >> >> On Wed, Dec 15, 2021 at 10:31 AM Zongmin Zhouwrote: >> > >> > Some boards(like RX550) seem to have garbage in the upper >> > 16 bits of the vram size register. Check for >> > this and clamp the size properly. Fixes >> > boards reporting bogus amounts of vram. >> > >> > after add this patch,the maximum GPU VRAM size is 64GB, >> > otherwise only 64GB vram size will be used. >> >> Can you provide some examples of problematic boards and >> possibly a >> vbios image from the problematic board? What values are you >> seeing? >> It would be nice to see what the boards are reporting and >>whether the >> lower 16 bits are actually correct or if it is some other >>issue. This >> register is undefined until the asic has been initialized. >> The vbios >> programs it as part of it's asic init sequence (either via >>vesa/gop or >> the OS driver). >> >> Alex >> >> >> > >> > Signed-off-by: Zongmin Zhou >>> --- >>> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 13 >> ++--- >>> 1 file changed, 10 insertions(+), 3 deletions(-) >>> >>
CFP FOSDEM22 Graphics DevRoom
Hi, After a hiatus in 2021, the upcoming FOSDEM will have a graphics DevRoom again. This time round on a sunday, the 6th of February 2022. As usual, the focus of this DevRoom is: * Graphics drivers: from display to media to 3d drivers, both in kernel or userspace. Be it part of DRM, KMS, V4L, (direct)FB, Xorg, Mesa... * Input drivers: kernel and userspace. * Windowing systems: X, Wayland, Mir, directFB, ... * Low level toolkit stuff * Low level machine learning. * Colour management. * ... FOSDEM '22 is sadly a virtual event again. While a virtual FOSDEM lacks all the wonderful madness of a real life FOSDEM, it does have the advantage of not having to deal with travel and accomodation, the physics of humans trundling around a big university campus, or a booklet. Talks: -- Time slots will be the usual 25/50 minute talk length, you are free to fill this time up as you see fit, but you might want to reserve 5 minutes for Q&A. I expect there to be 8h available for scheduling. Since there are no travel accomodations to deal with, and there are no people who physically need to get from one end of the ULB campus to the other, and there are no 5000+ booklets to be printed, there is no first come, first serve requirement this year round. But the other side of that coin is that talks can be hard dropped from the devroom managers' side until very late in the process if anything is not in order. Hard talk submission deadline: 30th of december, 23:59UTC. Further info on when a talk video should be finished to fit in the FOSDEM infrastructure will follow, but expect somewhere between january 16th and 23rd, 3-2 weeks before the event. Again, more details will follow. Talk submission and review panel: Arkadiusz Hiler (ivyl) Luc Verhaegen (libv) Martin Ruokala (mupuf) Successful submitters will receive an email with further information on the 31st, as it's not as if I will have anything better to do given that mini-me will have been stabbed only once by then ;) Pentabarf: -- Since FOSDEM has had to flash migrate to virtual last year, no further work was sadly done to replace or fix pentabarf, a tool originally made to create the fancy FOSDEM booklet, so its pent-up-clunkiness has to be used again, especially since it actually works :) https://penta.fosdem.org/submission/FOSDEM22 Re-use your accounts from the previous years. If you have forgotten your password, then you can reset it here: https://penta.fosdem.org/user/forgot_password Here are the basic requirements before we consider a talk worth scheduling: On your personal page: * General: * First Name * Last Name * Nickname * Public Name * Image * Contact: * Contact email address * Biography: * Short Biography On your event page: * On the General page: * Event title * Event subtitle. * Track: Graphics Devroom * Persons: * Add yourself as speaker. * Abstract: * Short abstract Unlike IRL events with a booklet, you should be able to tweak this information pretty much until you are finished with your talk. That's it, hope to see your submission in penta, and your talk at FOSDEM. Luc Verhaegen.
Re: [PATCH] drm/etnaviv: limit submit sizes
Am Fr., 17. Dez. 2021 um 11:59 Uhr schrieb Lucas Stach : > > Currently we allow rediculous ammounts of kernel memory being allocated > via the etnaviv GEM_SUBMIT ioctl, which is a pretty easy DoS vector. Put > some reasonable limits in to fix this. > > The commandstream size is limited to 64KB, which was already a soft limit > on older kernels after which the kernel only took submits on a best effort > base, so there is no userspace that tries to submit commandstreams larger > than this. Even if the whole commandstream is a single incrementing address > load, the size limit also limits the number of potential relocs and > referenced buffers to slightly under 64K, so use the same limit for those > arguments. The performance monitoring infrastructure currently supports > less than 50 performance counter signals, so limiting them to 128 on a > single submit seems like a reasonably future-proof number for now. This > number can be bumped if needed without breaking the interface. > > Cc: sta...@vger.kernel.org > Reported-by: Dan Carpenter > Signed-off-by: Lucas Stach Reviewed-by: Christian Gmeiner -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info/privacypolicy
Re: [Bug Report] Desktop monitor sleep regression
On 17.12.21 15:52, Imre Deak wrote: > On Fri, Dec 17, 2021 at 03:46:21PM +0100, Thorsten Leemhuis wrote: >> added some CCs Geert added in his reply >> >> On 07.12.21 08:20, Thorsten Leemhuis wrote: >>> >>> [TLDR: adding this regression to regzbot; most of this mail is compiled >>> from a few templates paragraphs some of you might have seen already.] >>> >>> Hi, this is your Linux kernel regression tracker speaking. >> >> /me again >> >> What's up here? We are getting close to rc6, but there afaics wasn't any >> reply of substance since the report ten days ago. Hence: >> >> Could anybody please comment on this? Imre Deak, the commit Brandon >> found in the bisection contains a patch of yours, do you maybe have an >> idea what's up here? > > Yes, > https://bugzilla.kernel.org/show_bug.cgi?id=215203 > > based on which the problem is somehere in the AMD driver. Ha, sorry for the noise then, I really feel stupid: I have no idea why I didn't check the bug report for an update, as I do normally do. Much have slipped through. Ohh well, hopefully we one day have have a central place to handle these things. Ciao, Thorsten >> Ciao, Thorsten >> >> #regzbot poke >> >>> Adding the regression mailing list to the list of recipients, as it >>> should be in the loop for all regressions, as explained here: >>> https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html >>> >>> Also adding the authors and reviewers of the culprit and two appropriate >>> mailing lists. >>> >>> On 07.12.21 01:21, Brandon Nielsen wrote: Monitors no longer sleep properly on my system (dual monitor connected via DP->DVI, amdgpu, x86_64). The monitors slept properly on 5.14, but stopped during the 5.15 series. I have also filed this bug on the kernel bugzilla[0] and downstream[1]. I have performed a bisect, first "bad" commit to master is 55285e21f04517939480966164a33898c34b2af2[1], the same change made it into the 5.15 branch as e3b39825ed0813f787cb3ebdc5ecaa5131623647. >>> >>> TWIMC: That was for 5.15.3 >>> I have verified the issue exists in latest master (a51e3ac43ddbad891c2b1a4f3aa52371d6939570). Steps to reproduce: 1. Boot system (Fedora Workstation 35 in this case) 2. Log in 3. Lock screen (after a few seconds, monitors will enter power save "sleep" state with backlight off) 4. Wait (usually no more than 30 seconds, sometimes up to a few minutes) 5. Observe monitor leaving "sleep" state (backlight comes back on), but nothing is displayed [0] - https://bugzilla.kernel.org/show_bug.cgi?id=215203 [1] - https://bugzilla.redhat.com/show_bug.cgi?id=2028613 >>> >>> To be sure this issue doesn't fall through the cracks unnoticed, I'm >>> adding it to regzbot, my Linux kernel regression tracking bot: >>> >>> #regzbot ^introduced 55285e21f04517939480966164a33898c34b2af2 >>> #regzbot title fbdev/efifb: Monitors no longer sleep (amdgpu dual >>> monitor setup) >>> #regzbot ignore-activity >>> >>> Reminder: when fixing the issue, please add a 'Link:' tag with the URL >>> to the report (the parent of this mail), then regzbot will automatically >>> mark the regression as resolved once the fix lands in the appropriate >>> tree. For more details about regzbot see footer. >>> >>> Sending this to everyone that got the initial report, to make all aware >>> of the tracking. I also hope that messages like this motivate people to >>> directly get at least the regression mailing list and ideally even >>> regzbot involved when dealing with regressions, as messages like this >>> wouldn't be needed then. >>> >>> Don't worry, I'll send further messages wrt to this regression just to >>> the lists (with a tag in the subject so people can filter them away), as >>> long as they are intended just for regzbot. With a bit of luck no such >>> messages will be needed anyway. >>> >>> Ciao, Thorsten, your Linux kernel regression tracker. >>> >>> P.S.: As a Linux kernel regression tracker I'm getting a lot of reports >>> on my table. I can only look briefly into most of them. Unfortunately >>> therefore I sometimes will get things wrong or miss something important. >>> I hope that's not the case here; if you think it is, don't hesitate to >>> tell me about it in a public reply. That's in everyone's interest, as >>> what I wrote above might be misleading to everyone reading this; any >>> suggestion I gave they thus might sent someone reading this down the >>> wrong rabbit hole, which none of us wants. >>> >>> BTW, I have no personal interest in this issue, which is tracked using >>> regzbot, my Linux kernel regression tracking bot >>> (https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting >>> this mail to get things rolling again and hence don't need to be CC on >>> all further activities wrt to this regression. >>> >
Re: [PATCH v4 04/22] dt-bindings: host1x: Document optional HDMI sound-dai-cells
17.12.2021 15:06, Dmitry Osipenko пишет: > 17.12.2021 15:02, Thierry Reding пишет: >> On Fri, Dec 17, 2021 at 02:55:48PM +0300, Dmitry Osipenko wrote: >>> 17.12.2021 14:12, Mark Brown пишет: On Thu, Dec 16, 2021 at 03:20:21PM +0100, Thierry Reding wrote: > On Sat, Dec 04, 2021 at 05:37:07PM +0300, Dmitry Osipenko wrote: >> Document new optional sound-dai-cells property of HDMI node. This node >> will >> be used as endpoint of HDMI sound DAI graph. > It's probably best for this to go through ASoC along with the other > audio-related bindings. > Alternatively, I've just sent out a patch that converts the host1x > bindings to json-schema, so I could work this into that as well. It doesn't apply to the ASoC tree for whatever reason so probably best to roll it in with those JSON updates. >>> >>> This hos1tx binding patch indeed will conflict with the Thierry's patch. >>> >>> Thierry, will you be able to take the binding patches into the Tegra >>> tree and resolve all those hos1tx binding conflicts there? >> >> Yes, I'll resolve all of those conflicts in the Tegra tree. > > Thank you! > > Mark, then you may apply patches 5-13 to ASoC on top of the Vinod's > branch, skipping patch #6. Thanks in advance! > I see that Thierry applied only the host1x patch, but not the other bindings. Mark, perhaps will be easier if I'll just make the v5 which you could apply easily without a need to apply only selective patches. I'll try to post it ASAP.
[PATCH 2/2] dt-bindings: leds: lp855x: Convert to json-schema
From: Thierry Reding
Convert the Texas Instruments LP855x backlight device tree bindings from
the free-form text format to json-schema.
Signed-off-by: Thierry Reding
---
.../bindings/leds/backlight/lp855x.txt| 72 -
.../bindings/leds/backlight/ti,lp8550.yaml| 151 ++
2 files changed, 151 insertions(+), 72 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/leds/backlight/lp855x.txt
create mode 100644
Documentation/devicetree/bindings/leds/backlight/ti,lp8550.yaml
diff --git a/Documentation/devicetree/bindings/leds/backlight/lp855x.txt
b/Documentation/devicetree/bindings/leds/backlight/lp855x.txt
deleted file mode 100644
index 88f56641fc28..
--- a/Documentation/devicetree/bindings/leds/backlight/lp855x.txt
+++ /dev/null
@@ -1,72 +0,0 @@
-lp855x bindings
-
-Required properties:
- - compatible: "ti,lp8550", "ti,lp8551", "ti,lp8552", "ti,lp8553",
-"ti,lp8555", "ti,lp8556", "ti,lp8557"
- - reg: I2C slave address (u8)
- - dev-ctrl: Value of DEVICE CONTROL register (u8). It depends on the device.
-
-Optional properties:
- - bl-name: Backlight device name (string)
- - init-brt: Initial value of backlight brightness (u8)
- - pwm-period: PWM period value. Set only PWM input mode used (u32)
- - rom-addr: Register address of ROM area to be updated (u8)
- - rom-val: Register value to be updated (u8)
- - power-supply: Regulator which controls the 3V rail
- - enable-supply: Regulator which controls the EN/VDDIO input
-
-Example:
-
- /* LP8555 */
- backlight@2c {
- compatible = "ti,lp8555";
- reg = <0x2c>;
-
- dev-ctrl = /bits/ 8 <0x00>;
- pwm-period = <1>;
-
- /* 4V OV, 4 output LED0 string enabled */
- rom_14h {
- rom-addr = /bits/ 8 <0x14>;
- rom-val = /bits/ 8 <0xcf>;
- };
-
- /* Heavy smoothing, 24ms ramp time step */
- rom_15h {
- rom-addr = /bits/ 8 <0x15>;
- rom-val = /bits/ 8 <0xc7>;
- };
-
- /* 4 output LED1 string enabled */
- rom_19h {
- rom-addr = /bits/ 8 <0x19>;
- rom-val = /bits/ 8 <0x0f>;
- };
- };
-
- /* LP8556 */
- backlight@2c {
- compatible = "ti,lp8556";
- reg = <0x2c>;
-
- bl-name = "lcd-bl";
- dev-ctrl = /bits/ 8 <0x85>;
- init-brt = /bits/ 8 <0x10>;
- };
-
- /* LP8557 */
- backlight@2c {
- compatible = "ti,lp8557";
- reg = <0x2c>;
- enable-supply = <&backlight_vddio>;
- power-supply = <&backlight_vdd>;
-
- dev-ctrl = /bits/ 8 <0x41>;
- init-brt = /bits/ 8 <0x0a>;
-
- /* 4V OV, 4 output LED string enabled */
- rom_14h {
- rom-addr = /bits/ 8 <0x14>;
- rom-val = /bits/ 8 <0xcf>;
- };
- };
diff --git a/Documentation/devicetree/bindings/leds/backlight/ti,lp8550.yaml
b/Documentation/devicetree/bindings/leds/backlight/ti,lp8550.yaml
new file mode 100644
index ..412779a5462b
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/ti,lp8550.yaml
@@ -0,0 +1,151 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/ti,lp8550.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments LP855x family devicetree bindings
+
+maintainers:
+ - Milo Kim
+ - Rob Herring
+
+properties:
+ compatible:
+enum:
+ - ti,lp8550
+ - ti,lp8551
+ - ti,lp8552
+ - ti,lp8553
+ - ti,lp8555
+ - ti,lp8556
+ - ti,lp8557
+
+ reg:
+maxItems: 1
+
+ dev-ctrl:
+$ref: /schemas/types.yaml#/definitions/uint8
+description: Value of DEVICE CONTROL register. It depends on the device.
+
+ bl-name:
+$ref: /schemas/types.yaml#/definitions/string
+description: Backlight device name
+
+ init-brt:
+$ref: /schemas/types.yaml#/definitions/uint8
+description: Initial value of backlight brightness
+
+ pwm-period:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: PWM period value. Set only PWM input mode used
+
+ pwm-names:
+maxItems: 1
+
+ pwms:
+maxItems: 1
+
+ power-supply:
+description: Regulator which controls the 3V rail
+
+ enable-supply:
+description: Regulator which controls the EN/VDDIO input
+
+patternProperties:
+ '^rom_[0-9a-f]{2}h$':
+type: object
+properties:
+ rom-addr:
+$ref: /schemas/types.yaml#/definitions/uint8
+description: Register address of ROM area to be updated
+
+ rom-val:
+$ref: /schemas/types.yaml#/definitions/uint8
+description: Register
[PATCH 1/2] dt-bindings: leds: Document rfkill* trigger
From: Thierry Reding LEDs can use rfkill events as a trigger source, so document these in the device tree bindings. Signed-off-by: Thierry Reding --- .../devicetree/bindings/leds/common.yaml| 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml index 697102707703..f686907b4907 100644 --- a/Documentation/devicetree/bindings/leds/common.yaml +++ b/Documentation/devicetree/bindings/leds/common.yaml @@ -79,24 +79,25 @@ properties: the LED. $ref: /schemas/types.yaml#/definitions/string -enum: +oneOf: # LED will act as a back-light, controlled by the framebuffer system - - backlight + - const: backlight # LED will turn on (but for leds-gpio see "default-state" property in # Documentation/devicetree/bindings/leds/leds-gpio.yaml) - - default-on + - const: default-on # LED "double" flashes at a load average based rate - - heartbeat + - const: heartbeat # LED indicates disk activity - - disk-activity + - const: disk-activity # LED indicates IDE disk activity (deprecated), in new implementations # use "disk-activity" - - ide-disk + - const: ide-disk # LED flashes at a fixed, configurable rate - - timer + - const: timer # LED alters the brightness for the specified duration with one software # timer (requires "led-pattern" property) - - pattern + - const: pattern + - pattern: "^rfkill[0-9]+$" led-pattern: description: | -- 2.34.1
Re: [PATCH v4] dt-bindings: display: tegra: Convert to json-schema
On Fri, Dec 17, 2021 at 05:43:20PM +0100, Thierry Reding wrote: > From: Thierry Reding > > Convert the Tegra host1x controller bindings from the free-form text > format to json-schema. > > This also adds the missing display-hub DT bindings that were not > previously documented. > > Signed-off-by: Thierry Reding > --- > Changes in v4: > - add interconnect, interconnect-names, operating-points-v2 and > power-domains property to match latest DT updates > - drop stale reference to DPAUX pad controller bindings > - include dsi-controller.yaml and drop $nodename, #address-cells, > #size-cells and patternProperties from DSI bindings > - integrate #sound-dai-cells addition from published patch > - drop some generic, useless comments > > Changes in v3: > - split into separate YAML files for simplicity > - add display-hub DT bindings > > Changes in v2: > - use additionalProperties instead of unevaluatedProperties where > sufficient > - drop redundant $ref and add missing maxItems properties > - drop documentation for standard properties > - remove status properties from example > - drop spurious comments Hi Rob, for your convenience, I'm attaching the diff from yesterday's version 3 to make it hopefully a bit easier to review. Thierry From f016de415f8a6bf263337bc88a840093a3f7514f Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Fri, 17 Dec 2021 14:44:47 +0100 Subject: [PATCH] squash! dt-bindings: display: tegra: Convert to json-schema --- .../display/tegra/nvidia,tegra124-sor.yaml| 3 - .../display/tegra/nvidia,tegra20-dc.yaml | 7 ++ .../display/tegra/nvidia,tegra20-dsi.yaml | 25 +--- .../display/tegra/nvidia,tegra20-epp.yaml | 13 +++ .../display/tegra/nvidia,tegra20-gr2d.yaml| 13 +++ .../display/tegra/nvidia,tegra20-gr3d.yaml| 107 +- .../display/tegra/nvidia,tegra20-hdmi.yaml| 10 ++ .../display/tegra/nvidia,tegra20-host1x.yaml | 19 +++- .../display/tegra/nvidia,tegra20-isp.yaml | 12 ++ .../display/tegra/nvidia,tegra20-mpe.yaml | 15 +++ .../display/tegra/nvidia,tegra20-tvo.yaml | 7 ++ .../display/tegra/nvidia,tegra20-vi.yaml | 18 ++- 12 files changed, 215 insertions(+), 34 deletions(-) diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml index afc283796653..0188baad0865 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml @@ -14,9 +14,6 @@ description: | The Serial Output Resource (SOR) can be used to drive HDMI, LVDS, eDP and DP outputs. - See ../pinctrl/nvidia,tegra124-dpaux-padctl.txt for information - regarding the DPAUX pad controller bindings. - properties: $nodename: pattern: "^sor@[0-9a-f]+$" diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml index eeffb8d7c597..ac346af663cd 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml @@ -59,6 +59,13 @@ properties: iommus: maxItems: 1 + operating-points-v2: +$ref: "/schemas/types.yaml#/definitions/phandle" + + power-domains: +items: + - description: phandle to the core power domain + nvidia,head: $ref: /schemas/types.yaml#/definitions/uint32 description: The number of the display controller head. This is used to setup the various diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml index abab8783db1b..75546f250ad7 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml @@ -11,9 +11,6 @@ maintainers: - Jon Hunter properties: - $nodename: -pattern: "^dsi@[0-9a-f]+$" - compatible: oneOf: - enum: @@ -50,15 +47,12 @@ properties: items: - const: dsi + operating-points-v2: +$ref: "/schemas/types.yaml#/definitions/phandle" + power-domains: maxItems: 1 - '#address-cells': -const: 1 - - '#size-cells': -const: 0 - avdd-dsi-csi-supply: description: phandle of a supply that powers the DSI controller @@ -90,17 +84,8 @@ properties: gang up with in order to support up to 8 data lanes $ref: "/schemas/types.yaml#/definitions/phandle" -patternProperties: - "^panel@[0-9]+$": -type: object -properties: - reg: -maxItems: 1 - -required: - - reg - allOf: + - $ref: "../dsi-controller.yaml#" - if: properties: compatible: @@ -142,7 +127,7 @@ allOf: required: - interrupts -additionalProperties: false +unevaluatedProperties: false
[PATCH v4] dt-bindings: display: tegra: Convert to json-schema
From: Thierry Reding Convert the Tegra host1x controller bindings from the free-form text format to json-schema. This also adds the missing display-hub DT bindings that were not previously documented. Signed-off-by: Thierry Reding --- Changes in v4: - add interconnect, interconnect-names, operating-points-v2 and power-domains property to match latest DT updates - drop stale reference to DPAUX pad controller bindings - include dsi-controller.yaml and drop $nodename, #address-cells, #size-cells and patternProperties from DSI bindings - integrate #sound-dai-cells addition from published patch - drop some generic, useless comments Changes in v3: - split into separate YAML files for simplicity - add display-hub DT bindings Changes in v2: - use additionalProperties instead of unevaluatedProperties where sufficient - drop redundant $ref and add missing maxItems properties - drop documentation for standard properties - remove status properties from example - drop spurious comments .../display/tegra/nvidia,tegra114-mipi.txt| 41 -- .../display/tegra/nvidia,tegra114-mipi.yaml | 74 ++ .../display/tegra/nvidia,tegra124-dpaux.yaml | 149 .../display/tegra/nvidia,tegra124-sor.yaml| 206 ++ .../display/tegra/nvidia,tegra124-vic.yaml| 71 ++ .../display/tegra/nvidia,tegra186-dc.yaml | 85 +++ .../tegra/nvidia,tegra186-display.yaml| 310 .../tegra/nvidia,tegra186-dsi-padctl.yaml | 46 ++ .../display/tegra/nvidia,tegra20-dc.yaml | 181 + .../display/tegra/nvidia,tegra20-dsi.yaml | 159 + .../display/tegra/nvidia,tegra20-epp.yaml | 70 ++ .../display/tegra/nvidia,tegra20-gr2d.yaml| 73 ++ .../display/tegra/nvidia,tegra20-gr3d.yaml| 214 ++ .../display/tegra/nvidia,tegra20-hdmi.yaml| 126 .../display/tegra/nvidia,tegra20-host1x.txt | 675 -- .../display/tegra/nvidia,tegra20-host1x.yaml | 347 + .../display/tegra/nvidia,tegra20-isp.yaml | 67 ++ .../display/tegra/nvidia,tegra20-mpe.yaml | 73 ++ .../display/tegra/nvidia,tegra20-tvo.yaml | 58 ++ .../display/tegra/nvidia,tegra20-vi.yaml | 163 + .../display/tegra/nvidia,tegra210-csi.yaml| 52 ++ .../pinctrl/nvidia,tegra124-dpaux-padctl.txt | 59 -- 22 files changed, 2524 insertions(+), 775 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.txt create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-dpaux.yaml create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-vic.yaml create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-display.yaml create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dsi-padctl.yaml create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-epp.yaml create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr2d.yaml create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.yaml create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml delete mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-isp.yaml create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-mpe.yaml create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-tvo.yaml create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra210-csi.yaml delete mode 100644 Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-dpaux-padctl.txt diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.txt deleted file mode 100644 index e4a25cedc5cf.. --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.txt +++ /dev/null @@ -1,41 +0,0 @@ -NVIDIA Tegra MIPI pad calibration controller - -Required properties: -- compatible: "nvidia,tegra-mipi" -- reg: Physical base address and length of the controller's registers. -- clocks: Must contain an entry for each entry in clock-names. - See .
Re: [Intel-gfx] [PATCH] drm/i915/guc: Log engine resets
On Fri, Dec 17, 2021 at 12:15:53PM +, Tvrtko Ursulin wrote:
>
> On 14/12/2021 15:07, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Log engine resets done by the GuC firmware in the similar way it is done
> > by the execlists backend.
> >
> > This way we have notion of where the hangs are before the GuC gains
> > support for proper error capture.
>
> Ping - any interest to log this info?
>
> All there currently is a non-descriptive "[drm] GPU HANG: ecode
> 12:0:".
>
Yea, this could be helpful. One suggestion below.
> Also, will GuC be reporting the reason for the engine reset at any point?
>
We are working on the error state capture, presumably the registers will
give a clue what caused the hang.
As for the GuC providing a reason, that isn't defined in the interface
but that is decent idea to provide a hint in G2H what the issue was. Let
me run that by the i915 GuC developers / GuC firmware team and see what
they think.
> Regards,
>
> Tvrtko
>
> > Signed-off-by: Tvrtko Ursulin
> > Cc: Matthew Brost
> > Cc: John Harrison
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index 9739da6f..51512123dc1a 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -11,6 +11,7 @@
> > #include "gt/intel_context.h"
> > #include "gt/intel_engine_pm.h"
> > #include "gt/intel_engine_heartbeat.h"
> > +#include "gt/intel_engine_user.h"
> > #include "gt/intel_gpu_commands.h"
> > #include "gt/intel_gt.h"
> > #include "gt/intel_gt_clock_utils.h"
> > @@ -3934,9 +3935,18 @@ static void capture_error_state(struct intel_guc
> > *guc,
> > {
> > struct intel_gt *gt = guc_to_gt(guc);
> > struct drm_i915_private *i915 = gt->i915;
> > - struct intel_engine_cs *engine = __context_to_physical_engine(ce);
> > + struct intel_engine_cs *engine = ce->engine;
> > intel_wakeref_t wakeref;
> > + if (intel_engine_is_virtual(engine)) {
> > + drm_notice(&i915->drm, "%s class, engines 0x%x; GuC engine
> > reset\n",
> > + intel_engine_class_repr(engine->class),
> > + engine->mask);
> > + engine = guc_virtual_get_sibling(engine, 0);
> > + } else {
> > + drm_notice(&i915->drm, "%s GuC engine reset\n", engine->name);
Probably include the guc_id of the context too then?
Matt
> > + }
> > +
> > intel_engine_set_hung_context(engine, ce);
> > with_intel_runtime_pm(&i915->runtime_pm, wakeref)
> > i915_capture_error_state(gt, engine->mask);
> >
Re: [PATCH v2 10/37] drm/imx/dcss: Use drm_module_platform_driver() to register the driver
Hi Javier,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20211215]
[also build test ERROR on v5.16-rc5]
[cannot apply to drm/drm-next shawnguo/for-next pinchartl-media/drm/du/next
drm-exynos/exynos-drm-next v5.16-rc5 v5.16-rc4 v5.16-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Javier-Martinez-Canillas/drm-Make-drivers-to-honour-the-nomodeset-parameter/20211217-084031
base:93bf6eee76c0e716f6b32de690b1c52991547bb4
config: arm64-randconfig-r034-20211216
(https://download.01.org/0day-ci/archive/20211217/202112172338.sdp9k7tx-...@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 11.2.0
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/0day-ci/linux/commit/c7b8e02dcec35660bbc9101ae0c1db11e5f7d1ab
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Javier-Martinez-Canillas/drm-Make-drivers-to-honour-the-nomodeset-parameter/20211217-084031
git checkout c7b8e02dcec35660bbc9101ae0c1db11e5f7d1ab
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross
O=build_dir ARCH=arm64 SHELL=/bin/bash drivers/gpu/drm/imx/dcss/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All error/warnings (new ones prefixed by >>):
>> drivers/gpu/drm/imx/dcss/dcss-drv.c:134:1: warning: data definition has no
>> type or storage class
134 | drm_module_platform_driver(dcss_platform_driver);
| ^~
>> drivers/gpu/drm/imx/dcss/dcss-drv.c:134:1: error: type defaults to 'int' in
>> declaration of 'drm_module_platform_driver' [-Werror=implicit-int]
>> drivers/gpu/drm/imx/dcss/dcss-drv.c:134:1: warning: parameter names (without
>> types) in function declaration
drivers/gpu/drm/imx/dcss/dcss-drv.c:124:31: warning: 'dcss_platform_driver'
defined but not used [-Wunused-variable]
124 | static struct platform_driver dcss_platform_driver = {
| ^~~~
cc1: some warnings being treated as errors
vim +134 drivers/gpu/drm/imx/dcss/dcss-drv.c
133
> 134 drm_module_platform_driver(dcss_platform_driver);
135
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH v3 08/17] drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent new ENOSPC errors
On 17-12-2021 12:58, Matthew Auld wrote:
> On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
> wrote:
>> Now that we cannot unbind kill the currently locked object directly
> "unbind kill"
>
>> because we're removing short term pinning, we may have to unbind the
>> object from gtt manually, using a i915_gem_evict_vm() call.
>>
>> Signed-off-by: Maarten Lankhorst
> Maybe mention that this only in preparation for some future patches,
> once the actual eviction is trylock and evict_for_vm can also handle
> shared dma-resv? At this point in the series we shouldn't expect to
> hit -ENOSPC, right?
>
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 18 --
>> 1 file changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> index af81d6c3332a..00cd9642669a 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> @@ -358,8 +358,22 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
>> vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view,
>> 0, 0, flags);
>> }
>>
>> - /* The entire mappable GGTT is pinned? Unexpected! */
>> - GEM_BUG_ON(vma == ERR_PTR(-ENOSPC));
>> + /*
>> +* The entire mappable GGTT is pinned? Unexpected!
>> +* Try to evict the object we locked too, as normally we
>> skip it
>> +* due to lack of short term pinning inside execbuf.
>> +*/
>> + if (vma == ERR_PTR(-ENOSPC)) {
>> + ret = mutex_lock_interruptible(&ggtt->vm.mutex);
>> + if (!ret) {
>> + ret = i915_gem_evict_vm(&ggtt->vm);
>> + mutex_unlock(&ggtt->vm.mutex);
>> + }
>> + if (ret)
>> + goto err_reset;
>> + vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view,
>> 0, 0, flags);
>> + }
>> + GEM_WARN_ON(vma == ERR_PTR(-ENOSPC));
> Looks like this is being triggered in CI, I assume because the trylock
> could easily fail, due to contention? Is this expected for now? Do we
> keep the WARN and track it as a known issue?
I think it makes sense. I can probably fix i915_gem_evict_vm to attempt to take
all objects in a blocking way.
I had some primitives that could lock for eviction, and keep a refcount on the
object. i915_gem_evict_vm could probably be changed to use it.
>> }
>> if (IS_ERR(vma)) {
>> ret = PTR_ERR(vma);
>> --
>> 2.34.1
>>
Re: [Intel-gfx] [PATCH v3 03/17] drm/i915: Remove pages_mutex and intel_gtt->vma_ops.set/clear_pages members, v3.
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst wrote: > > Big delta, but boils down to moving set_pages to i915_vma.c, and removing > the special handling, all callers use the defaults anyway. We only remap > in ggtt, so default case will fall through. > > Because we still don't require locking in i915_vma_unpin(), handle this by > using xchg in get_pages(), as it's locked with obj->mutex, and cmpxchg in > unpin, which only fails if we race a against a new pin. > > Changes since v1: > - aliasing gtt sets ZERO_SIZE_PTR, not -ENODEV, remove special case > from __i915_vma_get_pages(). (Matt) > Changes since v2: > - Free correct old pages in __i915_vma_get_pages(). (Matt) > Remove race of clearing vma->pages accidentally from put, > free it but leave it set, as only get has the lock. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld
[PATCH v7 8/8] drm/mediatek: Add mt8195 eDP support
This adds support of eDP panel to the mt8195 DP driver.
This driver is based on an initial version by
Jason-JH.Lin .
Signed-off-by: Markus Schneider-Pargmann
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dp.c | 102 +-
1 file changed, 73 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
b/drivers/gpu/drm/mediatek/mtk_dp.c
index 41e95a0bcaa2c..a256d55346a23 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -228,6 +228,11 @@ static struct regmap_config mtk_dp_regmap_config = {
.name = "mtk-dp-registers",
};
+static bool mtk_dp_is_edp(struct mtk_dp *mtk_dp)
+{
+ return mtk_dp->next_bridge;
+}
+
static struct mtk_dp *mtk_dp_from_bridge(struct drm_bridge *b)
{
return container_of(b, struct mtk_dp, bridge);
@@ -1185,26 +1190,49 @@ static int mtk_dp_get_calibration_data(struct mtk_dp
*mtk_dp)
return PTR_ERR(buf);
}
- cal_data->glb_bias_trim =
- check_cal_data_valid(1, 0x1e, (buf[0] >> 27) & 0x1f, 0xf);
- cal_data->clktx_impse =
- check_cal_data_valid(1, 0xe, (buf[0] >> 13) & 0xf, 0x8);
- cal_data->ln0_tx_impsel_pmos =
- check_cal_data_valid(1, 0xe, (buf[1] >> 28) & 0xf, 0x8);
- cal_data->ln0_tx_impsel_nmos =
- check_cal_data_valid(1, 0xe, (buf[1] >> 24) & 0xf, 0x8);
- cal_data->ln1_tx_impsel_pmos =
- check_cal_data_valid(1, 0xe, (buf[1] >> 20) & 0xf, 0x8);
- cal_data->ln1_tx_impsel_nmos =
- check_cal_data_valid(1, 0xe, (buf[1] >> 16) & 0xf, 0x8);
- cal_data->ln2_tx_impsel_pmos =
- check_cal_data_valid(1, 0xe, (buf[1] >> 12) & 0xf, 0x8);
- cal_data->ln2_tx_impsel_nmos =
- check_cal_data_valid(1, 0xe, (buf[1] >> 8) & 0xf, 0x8);
- cal_data->ln3_tx_impsel_pmos =
- check_cal_data_valid(1, 0xe, (buf[1] >> 4) & 0xf, 0x8);
- cal_data->ln3_tx_impsel_nmos =
- check_cal_data_valid(1, 0xe, buf[1] & 0xf, 0x8);
+ if (mtk_dp_is_edp(mtk_dp)) {
+ cal_data->glb_bias_trim =
+ check_cal_data_valid(1, 0x1e, (buf[3] >> 27) & 0x1f,
0xf);
+ cal_data->clktx_impse =
+ check_cal_data_valid(1, 0xe, (buf[0] >> 9) & 0xf, 0x8);
+ cal_data->ln0_tx_impsel_pmos =
+ check_cal_data_valid(1, 0xe, (buf[2] >> 28) & 0xf, 0x8);
+ cal_data->ln0_tx_impsel_nmos =
+ check_cal_data_valid(1, 0xe, (buf[2] >> 24) & 0xf, 0x8);
+ cal_data->ln1_tx_impsel_pmos =
+ check_cal_data_valid(1, 0xe, (buf[2] >> 20) & 0xf, 0x8);
+ cal_data->ln1_tx_impsel_nmos =
+ check_cal_data_valid(1, 0xe, (buf[2] >> 16) & 0xf, 0x8);
+ cal_data->ln2_tx_impsel_pmos =
+ check_cal_data_valid(1, 0xe, (buf[2] >> 12) & 0xf, 0x8);
+ cal_data->ln2_tx_impsel_nmos =
+ check_cal_data_valid(1, 0xe, (buf[2] >> 8) & 0xf, 0x8);
+ cal_data->ln3_tx_impsel_pmos =
+ check_cal_data_valid(1, 0xe, (buf[2] >> 4) & 0xf, 0x8);
+ cal_data->ln3_tx_impsel_nmos =
+ check_cal_data_valid(1, 0xe, buf[2] & 0xf, 0x8);
+ } else {
+ cal_data->glb_bias_trim =
+ check_cal_data_valid(1, 0x1e, (buf[0] >> 27) & 0x1f,
0xf);
+ cal_data->clktx_impse =
+ check_cal_data_valid(1, 0xe, (buf[0] >> 13) & 0xf, 0x8);
+ cal_data->ln0_tx_impsel_pmos =
+ check_cal_data_valid(1, 0xe, (buf[1] >> 28) & 0xf, 0x8);
+ cal_data->ln0_tx_impsel_nmos =
+ check_cal_data_valid(1, 0xe, (buf[1] >> 24) & 0xf, 0x8);
+ cal_data->ln1_tx_impsel_pmos =
+ check_cal_data_valid(1, 0xe, (buf[1] >> 20) & 0xf, 0x8);
+ cal_data->ln1_tx_impsel_nmos =
+ check_cal_data_valid(1, 0xe, (buf[1] >> 16) & 0xf, 0x8);
+ cal_data->ln2_tx_impsel_pmos =
+ check_cal_data_valid(1, 0xe, (buf[1] >> 12) & 0xf, 0x8);
+ cal_data->ln2_tx_impsel_nmos =
+ check_cal_data_valid(1, 0xe, (buf[1] >> 8) & 0xf, 0x8);
+ cal_data->ln3_tx_impsel_pmos =
+ check_cal_data_valid(1, 0xe, (buf[1] >> 4) & 0xf, 0x8);
+ cal_data->ln3_tx_impsel_nmos =
+ check_cal_data_valid(1, 0xe, buf[1] & 0xf, 0x8);
+ }
kfree(buf);
@@ -1322,7 +1350,11 @@ static void mtk_dp_video_mute(struct mtk_dp *mtk_dp,
bool enable)
mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_3000, val,
VIDEO_MUTE_SEL_DP_ENC0_P0_MASK |
VIDEO_MUTE_SW_DP_ENC0_P0_MASK);
- mtk_dp_sip_atf_
[PATCH v7 7/8] drm/mediatek: Add mt8195 DisplayPort driver
From: Markus Schneider-Pargmann
This patch adds a DisplayPort driver for the Mediatek mt8195 SoC.
It supports the mt8195, the external DisplayPort units. It offers
hot-plug-detection, audio up to 8 channels, and DisplayPort 1.4 with up
to 4 lanes.
The driver creates a child device for the phy. The child device will
never exist without the parent being active. As they are sharing a
register range, the parent passes a regmap pointer to the child so that
both can work with the same register range. The phy driver sets device
data that is read by the parent to get the phy device that can be used
to control the phy properties.
This driver is based on an initial version by
Jason-JH.Lin .
Signed-off-by: Markus Schneider-Pargmann
Signed-off-by: Guillaume Ranquet
Reported-by: kernel test robot
---
drivers/gpu/drm/mediatek/Kconfig |7 +
drivers/gpu/drm/mediatek/Makefile |2 +
drivers/gpu/drm/mediatek/mtk_dp.c | 3028
drivers/gpu/drm/mediatek/mtk_dp_reg.h | 568 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c |1 +
drivers/gpu/drm/mediatek/mtk_drm_drv.h |1 +
6 files changed, 3607 insertions(+)
create mode 100644 drivers/gpu/drm/mediatek/mtk_dp.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_reg.h
diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index 2976d21e9a34a..029b94c716131 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -28,3 +28,10 @@ config DRM_MEDIATEK_HDMI
select PHY_MTK_HDMI
help
DRM/KMS HDMI driver for Mediatek SoCs
+
+config MTK_DPTX_SUPPORT
+ tristate "DRM DPTX Support for Mediatek SoCs"
+ depends on DRM_MEDIATEK
+ select PHY_MTK_DP
+ help
+ DRM/KMS Display Port driver for Mediatek SoCs.
diff --git a/drivers/gpu/drm/mediatek/Makefile
b/drivers/gpu/drm/mediatek/Makefile
index 29098d7c8307c..d86a6406055e6 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -21,3 +21,5 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
mtk_hdmi_ddc.o
obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
+
+obj-$(CONFIG_MTK_DPTX_SUPPORT) += mtk_dp.o
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
b/drivers/gpu/drm/mediatek/mtk_dp.c
new file mode 100644
index 0..41e95a0bcaa2c
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -0,0 +1,3028 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ * Copyright (c) 2021 BayLibre
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mtk_dp_reg.h"
+
+#define MTK_DP_AUX_WAIT_REPLY_COUNT 20
+#define MTK_DP_CHECK_SINK_CAP_TIMEOUT_COUNT 3
+
+#define MTK_DP_MAX_LANES 4
+#define MTK_DP_MAX_LINK_RATE MTK_DP_LINKRATE_HBR3
+
+#define MTK_DP_TBC_BUF_READ_START_ADDR 0x08
+
+#define MTK_DP_TRAIN_RETRY_LIMIT 8
+#define MTK_DP_TRAIN_MAX_ITERATIONS 5
+
+#define MTK_DP_AUX_WRITE_READ_WAIT_TIME_US 20
+
+#define MTK_DP_DP_VERSION_11 0x11
+
+enum mtk_dp_state {
+ MTK_DP_STATE_INITIAL,
+ MTK_DP_STATE_IDLE,
+ MTK_DP_STATE_PREPARE,
+ MTK_DP_STATE_NORMAL,
+};
+
+enum mtk_dp_train_state {
+ MTK_DP_TRAIN_STATE_STARTUP = 0,
+ MTK_DP_TRAIN_STATE_CHECKCAP,
+ MTK_DP_TRAIN_STATE_CHECKEDID,
+ MTK_DP_TRAIN_STATE_TRAINING_PRE,
+ MTK_DP_TRAIN_STATE_TRAINING,
+ MTK_DP_TRAIN_STATE_CHECKTIMING,
+ MTK_DP_TRAIN_STATE_NORMAL,
+ MTK_DP_TRAIN_STATE_POWERSAVE,
+ MTK_DP_TRAIN_STATE_DPIDLE,
+};
+
+struct mtk_dp_timings {
+ struct videomode vm;
+
+ u16 htotal;
+ u16 vtotal;
+ u8 frame_rate;
+ u32 pix_rate_khz;
+};
+
+struct mtk_dp_train_info {
+ bool tps3;
+ bool tps4;
+ bool sink_ssc;
+ bool cable_plugged_in;
+ bool cable_state_change;
+ bool cr_done;
+ bool eq_done;
+
+ // link_rate is in multiple of 0.27Gbps
+ int link_rate;
+ int lane_count;
+
+ int irq_status;
+ int check_cap_count;
+};
+
+// Same values as used by the DP Spec for MISC0 bits 1 and 2
+enum mtk_dp_color_format {
+ MTK_DP_COLOR_FORMAT_RGB_444 = 0,
+ MTK_DP_COLOR_FORMAT_YUV_422 = 1,
+ MTK_DP_COLOR_FORMAT_YUV_444 = 2,
+ MTK_DP_COLOR_FORMAT_YUV_420 = 3,
+ MTK_DP_COLOR_FORMAT_YONLY = 4,
+ MTK_DP_COLOR_FORMAT_RAW = 5,
+ MTK_DP_COLOR_FORMAT_RESERVED = 6,
+ MTK_DP_COLOR_FORMAT_DEFAULT = MTK_DP_COLOR_FORMAT_RGB_444,
+ MTK_DP_COLOR_FORMAT_UNKNOWN = 15,
+};
+
+// Multiple of 0.27Gbps
+enum mtk_dp_linkrate {
+ MTK_DP_LINKRATE_RBR = 0x6,
+ MTK_DP_LINKRATE_HBR = 0xA,
+ MTK_DP_LINKRATE_HBR2 = 0x14,
+ MTK_DP_LINKRATE_HBR25 = 0x19,
+ MTK_DP_LINKRATE_HBR3 = 0x1E,
+};
+
+// Same values as u
[PATCH v7 6/8] phy: phy-mtk-dp: Add driver for DP phy
From: Markus Schneider-Pargmann This is a new driver that supports the integrated DisplayPort phy for mediatek SoCs, especially the mt8195. The phy is integrated into the DisplayPort controller and will be created by the mtk-dp driver. This driver expects a struct regmap to be able to work on the same registers as the DisplayPort controller. It sets the device data to be the struct phy so that the DisplayPort controller can easily work with it. The driver does not have any devicetree bindings because the datasheet does not list the controller and the phy as distinct units. The interaction with the controller can be covered by the configure callback of the phy framework and its displayport parameters. Signed-off-by: Markus Schneider-Pargmann Signed-off-by: Guillaume Ranquet --- MAINTAINERS | 1 + drivers/phy/mediatek/Kconfig | 8 ++ drivers/phy/mediatek/Makefile | 1 + drivers/phy/mediatek/phy-mtk-dp.c | 219 ++ 4 files changed, 229 insertions(+) create mode 100644 drivers/phy/mediatek/phy-mtk-dp.c diff --git a/MAINTAINERS b/MAINTAINERS index 8b7a98daf8e05..c44829d8a74df 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6394,6 +6394,7 @@ L:linux-media...@lists.infradead.org (moderated for non-subscribers) S: Supported F: Documentation/devicetree/bindings/display/mediatek/ F: drivers/gpu/drm/mediatek/ +F: drivers/phy/mediatek/phy-mtk-dp.c F: drivers/phy/mediatek/phy-mtk-hdmi* F: drivers/phy/mediatek/phy-mtk-mipi* diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig index 55f8e6c048ab3..f7ec860590492 100644 --- a/drivers/phy/mediatek/Kconfig +++ b/drivers/phy/mediatek/Kconfig @@ -55,3 +55,11 @@ config PHY_MTK_MIPI_DSI select GENERIC_PHY help Support MIPI DSI for Mediatek SoCs. + +config PHY_MTK_DP + tristate "MediaTek DP-PHY Driver" + depends on ARCH_MEDIATEK || COMPILE_TEST + depends on OF + select GENERIC_PHY + help + Support DisplayPort PHY for Mediatek SoCs. diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile index ace660fbed3a1..4ba1e06504346 100644 --- a/drivers/phy/mediatek/Makefile +++ b/drivers/phy/mediatek/Makefile @@ -3,6 +3,7 @@ # Makefile for the phy drivers. # +obj-$(CONFIG_PHY_MTK_DP) += phy-mtk-dp.o obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o obj-$(CONFIG_PHY_MTK_UFS) += phy-mtk-ufs.o obj-$(CONFIG_PHY_MTK_XSPHY)+= phy-mtk-xsphy.o diff --git a/drivers/phy/mediatek/phy-mtk-dp.c b/drivers/phy/mediatek/phy-mtk-dp.c new file mode 100644 index 0..e0de2a367e788 --- /dev/null +++ b/drivers/phy/mediatek/phy-mtk-dp.c @@ -0,0 +1,219 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2021 BayLibre + * Author: Markus Schneider-Pargmann + */ + +#include +#include +#include +#include +#include +#include + +#define PHY_OFFSET 0x1000 + +#define MTK_DP_PHY_DIG_PLL_CTL_1 (PHY_OFFSET + 0x014) +# define TPLL_SSC_EN BIT(3) + +#define MTK_DP_PHY_DIG_BIT_RATE(PHY_OFFSET + 0x03C) +# define BIT_RATE_RBR 0 +# define BIT_RATE_HBR 1 +# define BIT_RATE_HBR2 2 +# define BIT_RATE_HBR3 3 + +#define MTK_DP_PHY_DIG_SW_RST (PHY_OFFSET + 0x038) +# define DP_GLB_SW_RST_PHYDBIT(0) + +#define MTK_DP_LANE0_DRIVING_PARAM_3 (PHY_OFFSET + 0x138) +#define MTK_DP_LANE1_DRIVING_PARAM_3 (PHY_OFFSET + 0x238) +#define MTK_DP_LANE2_DRIVING_PARAM_3 (PHY_OFFSET + 0x338) +#define MTK_DP_LANE3_DRIVING_PARAM_3 (PHY_OFFSET + 0x438) +# define XTP_LN_TX_LCTXC0_SW0_PRE0_DEFAULT 0x10 +# define XTP_LN_TX_LCTXC0_SW0_PRE1_DEFAULT (0x14 << 8) +# define XTP_LN_TX_LCTXC0_SW0_PRE2_DEFAULT (0x18 << 16) +# define XTP_LN_TX_LCTXC0_SW0_PRE3_DEFAULT (0x20 << 24) +# define DRIVING_PARAM_3_DEFAULT (XTP_LN_TX_LCTXC0_SW0_PRE0_DEFAULT | \ + XTP_LN_TX_LCTXC0_SW0_PRE1_DEFAULT | \ + XTP_LN_TX_LCTXC0_SW0_PRE2_DEFAULT | \ + XTP_LN_TX_LCTXC0_SW0_PRE3_DEFAULT) + +#define MTK_DP_LANE0_DRIVING_PARAM_4 (PHY_OFFSET + 0x13C) +#define MTK_DP_LANE1_DRIVING_PARAM_4 (PHY_OFFSET + 0x23C) +#define MTK_DP_LANE2_DRIVING_PARAM_4 (PHY_OFFSET + 0x33C) +#define MTK_DP_LANE3_DRIVING_PARAM_4 (PHY_OFFSET + 0x43C) +# define XTP_LN_TX_LCTXC0_SW1_PRE0_DEFAULT 0x18 +# define XTP_LN_TX_LCTXC0_SW1_PRE1_DEFAULT (0x1e << 8) +# define XTP_LN_TX_LCTXC0_SW1_PRE2_DEFAULT (0x24 << 16) +# define XTP_LN_TX_LCTXC0_SW2_PRE0_DEFAULT (0x20 << 24) +# define DRIVING_PARAM_4_DEFAULT (XTP_LN_TX_LCTXC0_SW1_PRE0_DEFAULT | \ +
[PATCH v7 5/8] drm/mediatek: dpi: Add dpintf support
From: Markus Schneider-Pargmann
dpintf is the displayport interface hardware unit. This unit is similar
to dpi and can reuse most of the code.
This patch adds support for mt8195-dpintf to this dpi driver. Main
differences are:
- Some features/functional components are not available for dpintf
which are now excluded from code execution once is_dpintf is set
- dpintf can and needs to choose between different clockdividers based
on the clockspeed. This is done by choosing a different clock parent.
- There are two additional clocks that need to be managed. These are
only set for dpintf and will be set to NULL if not supplied. The
clk_* calls handle these as normal clocks then.
- Some register contents differ slightly between the two components. To
work around this I added register bits/masks with a DPINTF_ prefix
and use them where different.
Based on a separate driver for dpintf created by
Jason-JH.Lin .
Signed-off-by: Markus Schneider-Pargmann
Signed-off-by: Guillaume Ranquet
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 304
drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 38 +++
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 4 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +-
include/linux/soc/mediatek/mtk-mmsys.h | 2 +
6 files changed, 299 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 4554e2de14309..fbc43ea4049b9 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -63,6 +63,14 @@ enum mtk_dpi_out_color_format {
MTK_DPI_COLOR_FORMAT_YCBCR_422_FULL
};
+enum TVDPLL_CLK {
+ TVDPLL_PLL = 0,
+ TVDPLL_D2 = 2,
+ TVDPLL_D4 = 4,
+ TVDPLL_D8 = 8,
+ TVDPLL_D16 = 16,
+};
+
struct mtk_dpi {
struct drm_encoder encoder;
struct drm_bridge bridge;
@@ -71,8 +79,10 @@ struct mtk_dpi {
void __iomem *regs;
struct device *dev;
struct clk *engine_clk;
+ struct clk *dpi_ck_cg;
struct clk *pixel_clk;
struct clk *tvd_clk;
+ struct clk *pclk_src[5];
int irq;
struct drm_display_mode mode;
const struct mtk_dpi_conf *conf;
@@ -125,6 +135,18 @@ struct mtk_dpi_conf {
bool edge_sel_en;
const u32 *output_fmts;
u32 num_output_fmts;
+ bool is_ck_de_pol;
+ bool is_dpintf;
+ bool csc_support;
+ bool swap_input_support;
+ // Mask used for HWIDTH, HPORCH, VSYNC_WIDTH and VSYNC_PORCH (no shift)
+ u32 dimension_mask;
+ // Mask used for HSIZE and VSIZE (no shift)
+ u32 hvsize_mask;
+ u32 channel_swap_shift;
+ u32 yuv422_en_bit;
+ u32 csc_enable_bit;
+ const struct mtk_dpi_yc_limit *limit;
};
static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
@@ -153,30 +175,30 @@ static void mtk_dpi_disable(struct mtk_dpi *dpi)
static void mtk_dpi_config_hsync(struct mtk_dpi *dpi,
struct mtk_dpi_sync_param *sync)
{
- mtk_dpi_mask(dpi, DPI_TGEN_HWIDTH,
-sync->sync_width << HPW, HPW_MASK);
- mtk_dpi_mask(dpi, DPI_TGEN_HPORCH,
-sync->back_porch << HBP, HBP_MASK);
+ mtk_dpi_mask(dpi, DPI_TGEN_HWIDTH, sync->sync_width << HPW,
+dpi->conf->dimension_mask << HPW);
+ mtk_dpi_mask(dpi, DPI_TGEN_HPORCH, sync->back_porch << HBP,
+dpi->conf->dimension_mask << HBP);
mtk_dpi_mask(dpi, DPI_TGEN_HPORCH, sync->front_porch << HFP,
-HFP_MASK);
+dpi->conf->dimension_mask << HFP);
}
static void mtk_dpi_config_vsync(struct mtk_dpi *dpi,
struct mtk_dpi_sync_param *sync,
u32 width_addr, u32 porch_addr)
{
- mtk_dpi_mask(dpi, width_addr,
-sync->sync_width << VSYNC_WIDTH_SHIFT,
-VSYNC_WIDTH_MASK);
mtk_dpi_mask(dpi, width_addr,
sync->shift_half_line << VSYNC_HALF_LINE_SHIFT,
VSYNC_HALF_LINE_MASK);
+ mtk_dpi_mask(dpi, width_addr,
+sync->sync_width << VSYNC_WIDTH_SHIFT,
+dpi->conf->dimension_mask << VSYNC_WIDTH_SHIFT);
mtk_dpi_mask(dpi, porch_addr,
sync->back_porch << VSYNC_BACK_PORCH_SHIFT,
-VSYNC_BACK_PORCH_MASK);
+dpi->conf->dimension_mask << VSYNC_BACK_PORCH_SHIFT);
mtk_dpi_mask(dpi, porch_addr,
sync->front_porch << VSYNC_FRONT_PORCH_SHIFT,
-VSYNC_FRONT_PORCH_MASK);
+dpi->conf->dimension_mask << VSYNC_FRONT_PORCH_SHIFT);
}
static void mtk_dpi_config_vsync_lodd(struct mtk_dpi *dpi,
@@ -210,13 +232,20 @@ static void mtk_dpi_confi
[PATCH v7 4/8] video/hdmi: Add audio_infoframe packing for DP
From: Markus Schneider-Pargmann
Similar to HDMI, DP uses audio infoframes as well which are structured
very similar to the HDMI ones.
This patch adds a helper function to pack the HDMI audio infoframe for
DP, called hdmi_audio_infoframe_pack_for_dp().
hdmi_audio_infoframe_pack_only() is split into two parts. One of them
packs the payload only and can be used for HDMI and DP.
Signed-off-by: Markus Schneider-Pargmann
Signed-off-by: Guillaume Ranquet
---
drivers/video/hdmi.c| 83 -
include/drm/drm_dp_helper.h | 2 +
include/linux/hdmi.h| 7 +++-
3 files changed, 72 insertions(+), 20 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 947be761dfa40..63e74d9fd210e 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -21,6 +21,7 @@
* DEALINGS IN THE SOFTWARE.
*/
+#include
#include
#include
#include
@@ -381,12 +382,34 @@ static int hdmi_audio_infoframe_check_only(const struct
hdmi_audio_infoframe *fr
*
* Returns 0 on success or a negative error code on failure.
*/
-int hdmi_audio_infoframe_check(struct hdmi_audio_infoframe *frame)
+int hdmi_audio_infoframe_check(const struct hdmi_audio_infoframe *frame)
{
return hdmi_audio_infoframe_check_only(frame);
}
EXPORT_SYMBOL(hdmi_audio_infoframe_check);
+static void
+hdmi_audio_infoframe_pack_payload(const struct hdmi_audio_infoframe *frame,
+ u8 *buffer)
+{
+ u8 channels;
+
+ if (frame->channels >= 2)
+ channels = frame->channels - 1;
+ else
+ channels = 0;
+
+ buffer[0] = ((frame->coding_type & 0xf) << 4) | (channels & 0x7);
+ buffer[1] = ((frame->sample_frequency & 0x7) << 2) |
+(frame->sample_size & 0x3);
+ buffer[2] = frame->coding_type_ext & 0x1f;
+ buffer[3] = frame->channel_allocation;
+ buffer[4] = (frame->level_shift_value & 0xf) << 3;
+
+ if (frame->downmix_inhibit)
+ buffer[4] |= BIT(7);
+}
+
/**
* hdmi_audio_infoframe_pack_only() - write HDMI audio infoframe to binary
buffer
* @frame: HDMI audio infoframe
@@ -404,7 +427,6 @@ EXPORT_SYMBOL(hdmi_audio_infoframe_check);
ssize_t hdmi_audio_infoframe_pack_only(const struct hdmi_audio_infoframe
*frame,
void *buffer, size_t size)
{
- unsigned char channels;
u8 *ptr = buffer;
size_t length;
int ret;
@@ -420,28 +442,13 @@ ssize_t hdmi_audio_infoframe_pack_only(const struct
hdmi_audio_infoframe *frame,
memset(buffer, 0, size);
- if (frame->channels >= 2)
- channels = frame->channels - 1;
- else
- channels = 0;
-
ptr[0] = frame->type;
ptr[1] = frame->version;
ptr[2] = frame->length;
ptr[3] = 0; /* checksum */
- /* start infoframe payload */
- ptr += HDMI_INFOFRAME_HEADER_SIZE;
-
- ptr[0] = ((frame->coding_type & 0xf) << 4) | (channels & 0x7);
- ptr[1] = ((frame->sample_frequency & 0x7) << 2) |
-(frame->sample_size & 0x3);
- ptr[2] = frame->coding_type_ext & 0x1f;
- ptr[3] = frame->channel_allocation;
- ptr[4] = (frame->level_shift_value & 0xf) << 3;
-
- if (frame->downmix_inhibit)
- ptr[4] |= BIT(7);
+ hdmi_audio_infoframe_pack_payload(frame,
+ ptr + HDMI_INFOFRAME_HEADER_SIZE);
hdmi_infoframe_set_checksum(buffer, length);
@@ -479,6 +486,44 @@ ssize_t hdmi_audio_infoframe_pack(struct
hdmi_audio_infoframe *frame,
}
EXPORT_SYMBOL(hdmi_audio_infoframe_pack);
+/**
+ * hdmi_audio_infoframe_pack_for_dp - Pack a HDMI Audio infoframe for
+ *displayport
+ *
+ * @frame HDMI Audio infoframe
+ * @sdp secondary data packet for display port. This is filled with the
+ * appropriate data
+ * @dp_version Display Port version to be encoded in the header
+ *
+ * Packs a HDMI Audio Infoframe to be sent over Display Port. This function
+ * fills the secondary data packet to be used for Display Port.
+ *
+ * Return: Number of total written bytes or a negative errno on failure.
+ */
+ssize_t
+hdmi_audio_infoframe_pack_for_dp(const struct hdmi_audio_infoframe *frame,
+struct dp_sdp *sdp, u8 dp_version)
+{
+ int ret;
+
+ ret = hdmi_audio_infoframe_check(frame);
+ if (ret)
+ return ret;
+
+ memset(sdp->db, 0, sizeof(sdp->db));
+
+ // Secondary-data packet header
+ sdp->sdp_header.HB0 = 0;
+ sdp->sdp_header.HB1 = frame->type;
+ sdp->sdp_header.HB2 = DP_SDP_AUDIO_INFOFRAME_HB2;
+ sdp->sdp_header.HB3 = (dp_version & 0x3f) << 2;
+
+ hdmi_audio_infoframe_pack_payload(frame, sdp->db);
+
+ return frame->length + 4;
+}
+EXPORT_SYMBOL(hdmi_audio_infoframe_pack_for_dp);
+
/**
* hdmi_vendor_infoframe_init() - initialize an HDMI vendor inf
[PATCH v7 3/8] drm/edid: Add cea_sad helpers for freq/length
From: Markus Schneider-Pargmann
This patch adds two helper functions that extract the frequency and word
length from a struct cea_sad.
For these helper functions new defines are added that help translate the
'freq' and 'byte2' fields into real numbers.
Signed-off-by: Markus Schneider-Pargmann
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/drm_edid.c | 74 ++
include/drm/drm_edid.h | 18 --
2 files changed, 90 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 12893e7be89bb..500279a82167a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4747,6 +4747,80 @@ int drm_edid_to_speaker_allocation(struct edid *edid, u8
**sadb)
}
EXPORT_SYMBOL(drm_edid_to_speaker_allocation);
+/**
+ * drm_cea_sad_get_sample_rate - Extract the sample rate from cea_sad
+ * @sad: Pointer to the cea_sad struct
+ *
+ * Extracts the cea_sad frequency field and returns the sample rate in Hz.
+ *
+ * Return: Sample rate in Hz or a negative errno if parsing failed.
+ */
+int drm_cea_sad_get_sample_rate(const struct cea_sad *sad)
+{
+ switch (sad->freq) {
+ case DRM_CEA_SAD_FREQ_32KHZ:
+ return 32000;
+ case DRM_CEA_SAD_FREQ_44KHZ:
+ return 44100;
+ case DRM_CEA_SAD_FREQ_48KHZ:
+ return 48000;
+ case DRM_CEA_SAD_FREQ_88KHZ:
+ return 88200;
+ case DRM_CEA_SAD_FREQ_96KHZ:
+ return 96000;
+ case DRM_CEA_SAD_FREQ_176KHZ:
+ return 176400;
+ case DRM_CEA_SAD_FREQ_192KHZ:
+ return 192000;
+ default:
+ return -EINVAL;
+ }
+}
+EXPORT_SYMBOL(drm_cea_sad_get_sample_rate);
+
+static bool drm_cea_sad_is_uncompressed(const struct cea_sad *sad)
+{
+ switch (sad->format) {
+ case HDMI_AUDIO_CODING_TYPE_STREAM:
+ case HDMI_AUDIO_CODING_TYPE_PCM:
+ return true;
+ default:
+ return false;
+ }
+}
+
+/**
+ * drm_cea_sad_get_uncompressed_word_length - Extract word length
+ * @sad: Pointer to the cea_sad struct
+ *
+ * Extracts the cea_sad byte2 field and returns the word length for an
+ * uncompressed stream.
+ *
+ * Note: This function may only be called for uncompressed audio.
+ *
+ * Return: Word length in bits or a negative errno if parsing failed.
+ */
+int drm_cea_sad_get_uncompressed_word_length(const struct cea_sad *sad)
+{
+ if (!drm_cea_sad_is_uncompressed(sad)) {
+ DRM_WARN("Unable to get the uncompressed word length for a
compressed format: %u\n",
+sad->format);
+ return -EINVAL;
+ }
+
+ switch (sad->byte2) {
+ case DRM_CEA_SAD_UNCOMPRESSED_WORD_16BIT:
+ return 16;
+ case DRM_CEA_SAD_UNCOMPRESSED_WORD_20BIT:
+ return 20;
+ case DRM_CEA_SAD_UNCOMPRESSED_WORD_24BIT:
+ return 24;
+ default:
+ return -EINVAL;
+ }
+}
+EXPORT_SYMBOL(drm_cea_sad_get_uncompressed_word_length);
+
/**
* drm_av_sync_delay - compute the HDMI/DP sink audio-video sync delay
* @connector: connector associated with the HDMI/DP sink
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 18f6c700f6d02..a30452b313979 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -361,12 +361,24 @@ struct edid {
/* Short Audio Descriptor */
struct cea_sad {
- u8 format;
+ u8 format; /* See HDMI_AUDIO_CODING_TYPE_* */
u8 channels; /* max number of channels - 1 */
- u8 freq;
+ u8 freq; /* See CEA_SAD_FREQ_* */
u8 byte2; /* meaning depends on format */
};
+#define DRM_CEA_SAD_FREQ_32KHZ BIT(0)
+#define DRM_CEA_SAD_FREQ_44KHZ BIT(1)
+#define DRM_CEA_SAD_FREQ_48KHZ BIT(2)
+#define DRM_CEA_SAD_FREQ_88KHZ BIT(3)
+#define DRM_CEA_SAD_FREQ_96KHZ BIT(4)
+#define DRM_CEA_SAD_FREQ_176KHZ BIT(5)
+#define DRM_CEA_SAD_FREQ_192KHZ BIT(6)
+
+#define DRM_CEA_SAD_UNCOMPRESSED_WORD_16BIT BIT(0)
+#define DRM_CEA_SAD_UNCOMPRESSED_WORD_20BIT BIT(1)
+#define DRM_CEA_SAD_UNCOMPRESSED_WORD_24BIT BIT(2)
+
struct drm_encoder;
struct drm_connector;
struct drm_connector_state;
@@ -374,6 +386,8 @@ struct drm_display_mode;
int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb);
+int drm_cea_sad_get_sample_rate(const struct cea_sad *sad);
+int drm_cea_sad_get_uncompressed_word_length(const struct cea_sad *sad);
int drm_av_sync_delay(struct drm_connector *connector,
const struct drm_display_mode *mode);
--
2.32.0
[PATCH v7 2/8] dt-bindings: mediatek,dp: Add Display Port binding
From: Markus Schneider-Pargmann
This controller is present on several mediatek hardware. Currently
mt8195 and mt8395 have this controller without a functional difference,
so only one compatible field is added.
The controller can have two forms, as a normal display port and as an
embedded display port.
Signed-off-by: Markus Schneider-Pargmann
Signed-off-by: Guillaume Ranquet
Reviewed-by: Rob Herring
---
.../display/mediatek/mediatek,dp.yaml | 87 +++
1 file changed, 87 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml
new file mode 100644
index 0..068b11d766e21
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,dp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek Display Port Controller
+
+maintainers:
+ - CK Hu
+ - Jitao shi
+
+description: |
+ Device tree bindings for the Mediatek (embedded) Display Port controller
+ present on some Mediatek SoCs.
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt8195-dp-tx
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: faxi clock
+
+ clock-names:
+items:
+ - const: faxi
+
+ power-domains:
+maxItems: 1
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Input endpoint of the controller, usually dp_intf
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Output endpoint of the controller
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+edp_tx: edp_tx@1c50 {
+compatible = "mediatek,mt8195-dp-tx";
+reg = <0 0x1c50 0 0x8000>;
+interrupts = ;
+power-domains = <&spm MT8195_POWER_DOMAIN_EPD_TX>;
+pinctrl-names = "default";
+pinctrl-0 = <&edp_pin>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+edp_in: endpoint {
+remote-endpoint = <&dp_intf0_out>;
+};
+};
+port@1 {
+reg = <1>;
+edp_out: endpoint {
+ remote-endpoint = <&panel_in>;
+};
+};
+};
+};
--
2.32.0
[PATCH v7 1/8] dt-bindings: mediatek,dpi: Add DP_INTF compatible
From: Markus Schneider-Pargmann DP_INTF is similar to DPI but does not have the exact same feature set or register layouts. DP_INTF is the sink of the display pipeline that is connected to the DisplayPort controller and encoder unit. It takes the same clocks as DPI. Signed-off-by: Markus Schneider-Pargmann Signed-off-by: Guillaume Ranquet Reviewed-by: Rob Herring --- .../bindings/display/mediatek/mediatek,dpi.yaml | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml index dd2896a40ff08..53acf9a84f7fb 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml @@ -4,16 +4,16 @@ $id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: mediatek DPI Controller Device Tree Bindings +title: mediatek DPI/DP_INTF Controller Device Tree Bindings maintainers: - CK Hu - Jitao shi description: | - The Mediatek DPI function block is a sink of the display subsystem and - provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a parallel - output bus. + The Mediatek DPI and DP_INTF function blocks are a sink of the display + subsystem and provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a + parallel output bus. properties: compatible: @@ -23,6 +23,7 @@ properties: - mediatek,mt8173-dpi - mediatek,mt8183-dpi - mediatek,mt8192-dpi + - mediatek,mt8195-dpintf reg: maxItems: 1 @@ -54,7 +55,7 @@ properties: $ref: /schemas/graph.yaml#/properties/port description: Output port node. This port should be connected to the input port of an - attached HDMI or LVDS encoder chip. + attached HDMI, LVDS or DisplayPort encoder chip. required: - compatible -- 2.32.0
Re: [Intel-gfx] [PATCH v3 13/17] drm/i915: Add object locking to i915_gem_evict_for_node and i915_gem_evict_something
On 17-12-2021 14:55, Matthew Auld wrote: > On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst > wrote: >> Because we will start to require the obj->resv lock for unbinding, >> ensure these shrinker functions also take the lock. >> >> This requires some function signature changes, to ensure that the >> ww context is passed around, but is mostly straightforward. > Do we even need this? We aren't handling the shared dma-resv for these > ones, right? Or more just to have a consistent-ish interface? Yeah, we don't currently use it, but it will allow for easier eviction in the future, with -EDEADLK handling when required. It will currently only annotate the objects as being held by the ww context, which can cause -EDEADLK when other threads try to lock. Ideally we'd take a ref to the object and perform a blocking lock, but our locking and eviction code can't handle that right now. >> Previously this was split up into several patches, but reworking >> should allow for easier bisection. >> >> Signed-off-by: Maarten Lankhorst >> --- >> drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +- >> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +- >> drivers/gpu/drm/i915/gvt/aperture_gm.c| 2 +- >> drivers/gpu/drm/i915/i915_drv.h | 2 ++ >> drivers/gpu/drm/i915/i915_gem_evict.c | 34 +++ >> drivers/gpu/drm/i915/i915_gem_gtt.c | 8 +++-- >> drivers/gpu/drm/i915/i915_gem_gtt.h | 3 ++ >> drivers/gpu/drm/i915/i915_vgpu.c | 2 +- >> drivers/gpu/drm/i915/i915_vma.c | 9 ++--- >> .../gpu/drm/i915/selftests/i915_gem_evict.c | 17 +- >> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 14 >> 11 files changed, 63 insertions(+), 32 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c >> b/drivers/gpu/drm/i915/gt/intel_ggtt.c >> index a287c9186ec9..ed43e9c80aaa 100644 >> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c >> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c >> @@ -504,7 +504,7 @@ static int ggtt_reserve_guc_top(struct i915_ggtt *ggtt) >> GEM_BUG_ON(ggtt->vm.total <= GUC_GGTT_TOP); >> size = ggtt->vm.total - GUC_GGTT_TOP; >> >> - ret = i915_gem_gtt_reserve(&ggtt->vm, &ggtt->uc_fw, size, >> + ret = i915_gem_gtt_reserve(&ggtt->vm, NULL, &ggtt->uc_fw, size, >>GUC_GGTT_TOP, I915_COLOR_UNEVICTABLE, >>PIN_NOEVICT); >> if (ret) >> diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >> b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >> index e5ad4d5a91c0..a3597a6bb805 100644 >> --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >> +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c >> @@ -1382,7 +1382,7 @@ static int evict_vma(void *data) >> complete(&arg->completion); >> >> mutex_lock(&vm->mutex); >> - err = i915_gem_evict_for_node(vm, &evict, 0); >> + err = i915_gem_evict_for_node(vm, NULL, &evict, 0); >> mutex_unlock(&vm->mutex); >> >> return err; >> diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c >> b/drivers/gpu/drm/i915/gvt/aperture_gm.c >> index 0d6d59871308..c08098a167e9 100644 >> --- a/drivers/gpu/drm/i915/gvt/aperture_gm.c >> +++ b/drivers/gpu/drm/i915/gvt/aperture_gm.c >> @@ -63,7 +63,7 @@ static int alloc_gm(struct intel_vgpu *vgpu, bool high_gm) >> >> mutex_lock(>->ggtt->vm.mutex); >> mmio_hw_access_pre(gt); >> - ret = i915_gem_gtt_insert(>->ggtt->vm, node, >> + ret = i915_gem_gtt_insert(>->ggtt->vm, NULL, node, >> size, I915_GTT_PAGE_SIZE, >> I915_COLOR_UNEVICTABLE, >> start, end, flags); >> diff --git a/drivers/gpu/drm/i915/i915_drv.h >> b/drivers/gpu/drm/i915/i915_drv.h >> index c180019c607f..2a98192a89c1 100644 >> --- a/drivers/gpu/drm/i915/i915_drv.h >> +++ b/drivers/gpu/drm/i915/i915_drv.h >> @@ -1718,11 +1718,13 @@ i915_gem_vm_lookup(struct drm_i915_file_private >> *file_priv, u32 id) >> >> /* i915_gem_evict.c */ >> int __must_check i915_gem_evict_something(struct i915_address_space *vm, >> + struct i915_gem_ww_ctx *ww, >> u64 min_size, u64 alignment, >> unsigned long color, >> u64 start, u64 end, >> unsigned flags); >> int __must_check i915_gem_evict_for_node(struct i915_address_space *vm, >> +struct i915_gem_ww_ctx *ww, >> struct drm_mm_node *node, >> unsigned int flags); >> int i915_gem_evict_vm(struct i915_address_space *vm, >> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c >> b/drivers/gpu/drm/i915/i915_gem_evict.c >> index bfd66f539fc1..f502a617b35c
[PATCH v3 5/7] drm/i915: Use the vma resource as argument for gtt binding / unbinding
When introducing asynchronous unbinding, the vma itself may no longer
be alive when the actual binding or unbinding takes place.
Update the gtt i915_vma_ops accordingly to take a struct i915_vma_resource
instead of a struct i915_vma for the bind_vma() and unbind_vma() ops.
Similarly change the insert_entries() op for struct i915_address_space.
Replace a couple of i915_vma_snapshot members with their newly introduced
i915_vma_resource counterparts, since they have the same lifetime.
Also make sure to avoid changing the struct i915_vma_flags (in particular
the bind flags) async. That should now only be done sync under the
vm mutex.
v2:
- Update the vma_res::bound_flags when binding to the aliased ggtt
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/display/intel_dpt.c | 27 ++---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +
.../gpu/drm/i915/gem/selftests/huge_pages.c | 37 +++
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 19 ++--
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 37 +++
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 70 ++---
drivers/gpu/drm/i915/gt/intel_gtt.h | 15 +--
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 22 +++--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 13 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 3 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 6 +-
drivers/gpu/drm/i915/i915_vma.c | 24 -
drivers/gpu/drm/i915/i915_vma.h | 11 +--
drivers/gpu/drm/i915/i915_vma_resource.c | 9 +-
drivers/gpu/drm/i915/i915_vma_resource.h | 99 ++-
drivers/gpu/drm/i915/i915_vma_snapshot.c | 4 -
drivers/gpu/drm/i915/i915_vma_snapshot.h | 8 --
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 64
drivers/gpu/drm/i915/selftests/mock_gtt.c | 12 +--
21 files changed, 307 insertions(+), 206 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
b/drivers/gpu/drm/i915/display/intel_dpt.c
index 963ca7155b06..f9f2a4ef38cd 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -48,7 +48,7 @@ static void dpt_insert_page(struct i915_address_space *vm,
}
static void dpt_insert_entries(struct i915_address_space *vm,
- struct i915_vma *vma,
+ struct i915_vma_resource *vma_res,
enum i915_cache_level level,
u32 flags)
{
@@ -64,8 +64,8 @@ static void dpt_insert_entries(struct i915_address_space *vm,
* not to allow the user to override access to a read only page.
*/
- i = vma->node.start / I915_GTT_PAGE_SIZE;
- for_each_sgt_daddr(addr, sgt_iter, vma->pages)
+ i = vma_res->start / I915_GTT_PAGE_SIZE;
+ for_each_sgt_daddr(addr, sgt_iter, vma_res->bi.pages)
gen8_set_pte(&base[i++], pte_encode | addr);
}
@@ -76,35 +76,38 @@ static void dpt_clear_range(struct i915_address_space *vm,
static void dpt_bind_vma(struct i915_address_space *vm,
struct i915_vm_pt_stash *stash,
-struct i915_vma *vma,
+struct i915_vma_resource *vma_res,
enum i915_cache_level cache_level,
u32 flags)
{
- struct drm_i915_gem_object *obj = vma->obj;
u32 pte_flags;
+ if (vma_res->bound_flags)
+ return;
+
/* Applicable to VLV (gen8+ do not support RO in the GGTT) */
pte_flags = 0;
- if (vma->vm->has_read_only && i915_gem_object_is_readonly(obj))
+ if (vm->has_read_only && vma_res->bi.readonly)
pte_flags |= PTE_READ_ONLY;
- if (i915_gem_object_is_lmem(obj))
+ if (vma_res->bi.lmem)
pte_flags |= PTE_LM;
- vma->vm->insert_entries(vma->vm, vma, cache_level, pte_flags);
+ vm->insert_entries(vm, vma_res, cache_level, pte_flags);
- vma->page_sizes.gtt = I915_GTT_PAGE_SIZE;
+ vma_res->page_sizes_gtt = I915_GTT_PAGE_SIZE;
/*
* Without aliasing PPGTT there's no difference between
* GLOBAL/LOCAL_BIND, it's all the same ptes. Hence unconditionally
* upgrade to both bound if we bind either to avoid double-binding.
*/
- atomic_or(I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND, &vma->flags);
+ vma_res->bound_flags = I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND;
}
-static void dpt_unbind_vma(struct i915_address_space *vm, struct i915_vma *vma)
+static void dpt_unbind_vma(struct i915_address_space *vm,
+ struct i915_vma_resource *vma_res)
{
- vm->clear_range(vm, vma->node.start, vma->size);
+ vm->clear_range(vm, vma_res->start, vma_res->vma_size);
}
static void dpt_cleanup(struct i915_ad
[PATCH v3 7/7] drm/i915: Use struct vma_resource instead of struct vma_snapshot
There is always a struct vma_resource guaranteed to be alive when we
access a corresponding struct vma_snapshot.
So ditch the latter and instead of allocating vma_snapshots, reference
the already existning vma_resource.
This requires a couple of extra members in struct vma_resource but that's
a small price to pay for the simplification.
v2:
- Fix a missing include and declaration (kernel test robot )
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 -
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 15 +--
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 9 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 87 ++--
drivers/gpu/drm/i915/i915_request.c | 12 +-
drivers/gpu/drm/i915/i915_request.h | 6 +-
drivers/gpu/drm/i915/i915_vma.c | 14 +-
drivers/gpu/drm/i915/i915_vma_resource.c | 3 +
drivers/gpu/drm/i915/i915_vma_resource.h | 28 +++-
drivers/gpu/drm/i915/i915_vma_snapshot.c | 125 --
drivers/gpu/drm/i915/i915_vma_snapshot.h | 101 --
11 files changed, 88 insertions(+), 313 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.c
delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 98433ad74194..aa86ac33effc 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -175,7 +175,6 @@ i915-y += \
i915_ttm_buddy_manager.o \
i915_vma.o \
i915_vma_resource.o \
- i915_vma_snapshot.o \
intel_wopcm.o
# general-purpose microcontroller (GuC) support
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index b6faae1f9081..51649bbb8cc3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -29,7 +29,6 @@
#include "i915_gem_ioctls.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
-#include "i915_vma_snapshot.h"
struct eb_vma {
struct i915_vma *vma;
@@ -1952,7 +1951,6 @@ static void eb_capture_stage(struct i915_execbuffer *eb)
{
const unsigned int count = eb->buffer_count;
unsigned int i = count, j;
- struct i915_vma_snapshot *vsnap;
while (i--) {
struct eb_vma *ev = &eb->vma[i];
@@ -1962,11 +1960,6 @@ static void eb_capture_stage(struct i915_execbuffer *eb)
if (!(flags & EXEC_OBJECT_CAPTURE))
continue;
- vsnap = i915_vma_snapshot_alloc(GFP_KERNEL);
- if (!vsnap)
- continue;
-
- i915_vma_snapshot_init(vsnap, vma, "user");
for_each_batch_create_order(eb, j) {
struct i915_capture_list *capture;
@@ -1975,10 +1968,9 @@ static void eb_capture_stage(struct i915_execbuffer *eb)
continue;
capture->next = eb->capture_lists[j];
- capture->vma_snapshot = i915_vma_snapshot_get(vsnap);
+ capture->vma_res = i915_vma_resource_get(vma->resource);
eb->capture_lists[j] = capture;
}
- i915_vma_snapshot_put(vsnap);
}
}
@@ -3281,9 +3273,8 @@ eb_requests_create(struct i915_execbuffer *eb, struct
dma_fence *in_fence,
* _onstack interface.
*/
if (eb->batches[i]->vma)
-
i915_vma_snapshot_init_onstack(&eb->requests[i]->batch_snapshot,
- eb->batches[i]->vma,
- "batch");
+ eb->requests[i]->batch_res =
+
i915_vma_resource_get(eb->batches[i]->vma->resource);
if (eb->batch_pool) {
GEM_BUG_ON(intel_context_is_parallel(eb->context));
intel_gt_buffer_pool_mark_active(eb->batch_pool,
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 74aa90587061..d1daa4cc2895 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1708,18 +1708,15 @@ static void intel_engine_print_registers(struct
intel_engine_cs *engine,
static void print_request_ring(struct drm_printer *m, struct i915_request *rq)
{
- struct i915_vma_snapshot *vsnap = &rq->batch_snapshot;
+ struct i915_vma_resource *vma_res = rq->batch_res;
void *ring;
int size;
- if (!i915_vma_snapshot_present(vsnap))
- vsnap = NULL;
-
drm_printf(m,
"[head %04x, postfix %04x, tail %04x, batch 0x%08x_%08x]:\n",
rq->head, rq->postfix, rq->tail,
- vsnap ? upper_32_bits(vsnap->vma_resou
[PATCH v3 6/7] drm/i915: Use vma resources for async unbinding
Implement async (non-blocking) unbinding by not syncing the vma before
calling unbind on the vma_resource.
Add the resulting unbind fence to the object's dma_resv from where it is
picked up by the ttm migration code.
Ideally these unbind fences should be coalesced with the migration blit
fence to avoid stalling the migration blit waiting for unbind, as they
can certainly go on in parallel, but since we don't yet have a
reasonable data structure to use to coalesce fences and attach the
resulting fence to a timeline, we defer that for now.
Note that with async unbinding, even while the unbind waits for the
preceding bind to complete before unbinding, the vma itself might have been
destroyed in the process, clearing the vma pages. Therefore we can
only allow async unbinding if we have a refcounted sg-list and keep a
refcount on that for the vma resource pages to stay intact until
binding occurs. If this condition is not met, a request for an async
unbind is diverted to a sync unbind.
v2:
- Use a separate kmem_cache for vma resources for now to isolate their
memory allocation and aid debugging.
- Move the check for vm closed to the actual unbinding thread. Regardless
of whether the vm is closed, we need the unbind fence to properly wait
for capture.
- Clear vma_res::vm on unbind and update its documentation.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 11 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gtt.c | 4 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 3 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 3 +
drivers/gpu/drm/i915/i915_module.c | 3 +
drivers/gpu/drm/i915/i915_vma.c | 180 --
drivers/gpu/drm/i915/i915_vma.h | 3 +-
drivers/gpu/drm/i915/i915_vma_resource.c | 325 +--
drivers/gpu/drm/i915/i915_vma_resource.h | 45 +++
11 files changed, 518 insertions(+), 62 deletions(-)
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 e8a99e8cd129..0b0477f0af8b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -142,7 +142,16 @@ int i915_ttm_move_notify(struct ttm_buffer_object *bo)
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
int ret;
- ret = i915_gem_object_unbind(obj, I915_GEM_OBJECT_UNBIND_ACTIVE);
+ /*
+* Note: The async unbinding here will actually transform the
+* blocking wait for unbind into a wait before finally submitting
+* evict / migration blit and thus stall the migration timeline
+* which may not be good for overall throughput. We should make
+* sure we await the unbind fences *after* the migration blit
+* instead of *before* as we currently do.
+*/
+ ret = i915_gem_object_unbind(obj, I915_GEM_OBJECT_UNBIND_ACTIVE |
+I915_GEM_OBJECT_UNBIND_ASYNC);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index ad54941fcb98..3e9fbbfa13c6 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -145,7 +145,7 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
continue;
if (!i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND)) {
- __i915_vma_evict(vma);
+ __i915_vma_evict(vma, false);
drm_mm_remove_node(&vma->node);
}
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 30683c06b344..b582a4c6c3c7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -161,6 +161,9 @@ static void __i915_vm_release(struct work_struct *work)
struct i915_address_space *vm =
container_of(work, struct i915_address_space, release_work);
+ /* Synchronize async unbinds. */
+ i915_vma_resource_bind_dep_sync_all(vm);
+
vm->cleanup(vm);
i915_address_space_fini(vm);
@@ -189,6 +192,7 @@ void i915_address_space_init(struct i915_address_space *vm,
int subclass)
if (!kref_read(&vm->resv_ref))
kref_init(&vm->resv_ref);
+ vm->pending_unbind = RB_ROOT_CACHED;
INIT_WORK(&vm->release_work, __i915_vm_release);
atomic_set(&vm->open, 1);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 19c2497630e8..b9bd60cb2687 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -267,6 +267,9 @@ struct i915_address_space {
/* Flags used when creating page-table objects for this vm */
unsigned long lmem_pt_obj_flags;
+ /*
[PATCH v3 2/7] drm/i915: Break out the i915_deps utility
Since it's starting to be used outside the i915 TTM move code, move it
to a separate set of files.
v2:
- Update the documentation.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 176 +
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h | 17 --
drivers/gpu/drm/i915/i915_deps.c | 244 +++
drivers/gpu/drm/i915/i915_deps.h | 46
drivers/gpu/drm/i915/i915_request.c | 2 +-
6 files changed, 293 insertions(+), 193 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_deps.c
create mode 100644 drivers/gpu/drm/i915/i915_deps.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6ddd2d2bbaaf..1b62b9f65196 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -163,6 +163,7 @@ i915-y += \
i915_active.o \
i915_buddy.o \
i915_cmd_parser.o \
+ i915_deps.o \
i915_gem_evict.o \
i915_gem_gtt.o \
i915_gem_ww.o \
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 960145c8200f..e8a99e8cd129 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -5,6 +5,7 @@
#include
+#include "i915_deps.h"
#include "i915_drv.h"
#include "intel_memory_region.h"
#include "intel_region_ttm.h"
@@ -41,181 +42,6 @@ void i915_ttm_migrate_set_failure_modes(bool gpu_migration,
}
#endif
-/**
- * DOC: 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
- * the migration fence with the unbind fences if these are coalesced
- * post-migration.
- *
- * While collecting the individual dependencies, we store the refcounted
- * struct dma_fence pointers in a realloc-managed pointer array, since
- * that can be easily fed into a dma_fence_array. Other options are
- * available, like for example an xarray for similarity with drm/sched.
- * Can be changed easily if needed.
- *
- * A struct i915_deps need to be initialized using i915_deps_init().
- * If i915_deps_add_dependency() or i915_deps_add_resv() return an
- * error code they will internally call i915_deps_fini(), which frees
- * all internal references and allocations.
- *
- * We might want to break this out into a separate file as a utility.
- */
-
-#define I915_DEPS_MIN_ALLOC_CHUNK 8U
-
-static void i915_deps_reset_fences(struct i915_deps *deps)
-{
- if (deps->fences != &deps->single)
- kfree(deps->fences);
- deps->num_deps = 0;
- deps->fences_size = 1;
- deps->fences = &deps->single;
-}
-
-static void i915_deps_init(struct i915_deps *deps, gfp_t gfp)
-{
- deps->fences = NULL;
- deps->gfp = gfp;
- i915_deps_reset_fences(deps);
-}
-
-static void i915_deps_fini(struct i915_deps *deps)
-{
- unsigned int i;
-
- for (i = 0; i < deps->num_deps; ++i)
- dma_fence_put(deps->fences[i]);
-
- if (deps->fences != &deps->single)
- kfree(deps->fences);
-}
-
-static int i915_deps_grow(struct i915_deps *deps, struct dma_fence *fence,
- const struct ttm_operation_ctx *ctx)
-{
- int ret;
-
- if (deps->num_deps >= deps->fences_size) {
- unsigned int new_size = 2 * deps->fences_size;
- struct dma_fence **new_fences;
-
- new_size = max(new_size, I915_DEPS_MIN_ALLOC_CHUNK);
- new_fences = kmalloc_array(new_size, sizeof(*new_fences),
deps->gfp);
- if (!new_fences)
- goto sync;
-
- memcpy(new_fences, deps->fences,
- deps->fences_size * sizeof(*new_fences));
- swap(new_fences, deps->fences);
- if (new_fences != &deps->single)
- kfree(new_fences);
- deps->fences_size = new_size;
- }
- deps->fences[deps->num_deps++] = dma_fence_get(fence);
- return 0;
-
-sync:
- if (ctx->no_wait_gpu && !dma_fence_is_signaled(fence)) {
- ret = -EBUSY;
- goto unref;
- }
-
- ret = dma_fence_wait(fence, ctx->interruptible);
- if (ret)
- goto unref;
-
- ret = fence->error;
- if (ret)
- goto unref;
-
- return 0;
-
-unref:
- i915_deps_fini(deps);
- return ret;
-}
-
-static int i915_deps_sync(const struct i915_deps *deps,
- const struct ttm_operation_ctx *ctx)
-{
- struct dma_fence **fences = deps->fences;
- unsigned int i;
- int ret = 0;
-
- for (i = 0; i < deps->num_deps; ++i, ++fences) {
- if (ctx->no_wait_gpu && !dma_fence_is_signaled(*fences)) {
- ret = -EBUSY;
-
[PATCH v3 4/7] drm/i915: Initial introduction of vma resources
Introduce vma resources, sort of similar to TTM resources, needed for
asynchronous bind management. Initially we will use them to hold
completion of unbinding when we capture data from a vma, but they will
be used extensively in upcoming patches for asynchronous vma unbinding.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
drivers/gpu/drm/i915/i915_vma.c | 55 +++-
drivers/gpu/drm/i915/i915_vma.h | 19 ++-
drivers/gpu/drm/i915/i915_vma_resource.c | 124 ++
drivers/gpu/drm/i915/i915_vma_resource.h | 70 ++
drivers/gpu/drm/i915/i915_vma_snapshot.c | 15 +--
drivers/gpu/drm/i915/i915_vma_snapshot.h | 7 +-
drivers/gpu/drm/i915/i915_vma_types.h | 5 +
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 99 --
10 files changed, 334 insertions(+), 63 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.c
create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1b62b9f65196..98433ad74194 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -174,6 +174,7 @@ i915-y += \
i915_trace_points.o \
i915_ttm_buddy_manager.o \
i915_vma.o \
+ i915_vma_resource.o \
i915_vma_snapshot.o \
intel_wopcm.o
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 6013f7e18f60..b6faae1f9081 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1422,7 +1422,7 @@ eb_relocate_entry(struct i915_execbuffer *eb,
mutex_lock(&vma->vm->mutex);
err = i915_vma_bind(target->vma,
target->vma->obj->cache_level,
- PIN_GLOBAL, NULL);
+ PIN_GLOBAL, NULL, NULL);
mutex_unlock(&vma->vm->mutex);
reloc_cache_remap(&eb->reloc_cache, ev->vma->obj);
if (err)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index d792a3d0da7a..4308659bf552 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -37,6 +37,7 @@
#include "i915_sw_fence_work.h"
#include "i915_trace.h"
#include "i915_vma.h"
+#include "i915_vma_resource.h"
static struct kmem_cache *slab_vmas;
@@ -385,6 +386,8 @@ static int i915_vma_verify_bind_complete(struct i915_vma
*vma)
* @cache_level: mapping cache level
* @flags: flags like global or local mapping
* @work: preallocated worker for allocating and binding the PTE
+ * @vma_res: pointer to a preallocated vma resource. The resource is either
+ * consumed or freed.
*
* DMA addresses are taken from the scatter-gather table of this object (or of
* this VMA in case of non-default GGTT views) and PTE entries set up.
@@ -393,7 +396,8 @@ static int i915_vma_verify_bind_complete(struct i915_vma
*vma)
int i915_vma_bind(struct i915_vma *vma,
enum i915_cache_level cache_level,
u32 flags,
- struct i915_vma_work *work)
+ struct i915_vma_work *work,
+ struct i915_vma_resource *vma_res)
{
u32 bind_flags;
u32 vma_flags;
@@ -404,11 +408,15 @@ int i915_vma_bind(struct i915_vma *vma,
if (GEM_DEBUG_WARN_ON(range_overflows(vma->node.start,
vma->node.size,
- vma->vm->total)))
+ vma->vm->total))) {
+ kfree(vma_res);
return -ENODEV;
+ }
- if (GEM_DEBUG_WARN_ON(!flags))
+ if (GEM_DEBUG_WARN_ON(!flags)) {
+ kfree(vma_res);
return -EINVAL;
+ }
bind_flags = flags;
bind_flags &= I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND;
@@ -417,11 +425,21 @@ int i915_vma_bind(struct i915_vma *vma,
vma_flags &= I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND;
bind_flags &= ~vma_flags;
- if (bind_flags == 0)
+ if (bind_flags == 0) {
+ kfree(vma_res);
return 0;
+ }
GEM_BUG_ON(!vma->pages);
+ if (vma->resource || !vma_res) {
+ /* Rebinding with an additional I915_VMA_*_BIND */
+ GEM_WARN_ON(!vma_flags);
+ kfree(vma_res);
+ } else {
+ i915_vma_resource_init(vma_res);
+ vma->resource = vma_res;
+ }
trace_i915_vma_bind(vma, bind_flags);
if (work && bind_flags & vma->vm->bind_async_flags) {
struct dma_fence *prev;
@@ -897,6 +915,7 @
[PATCH v3 3/7] drm/i915: Require the vm mutex for i915_vma_bind()
Protect updates of struct i915_vma flags and async binding / unbinding
with the vm::mutex. This means that i915_vma_bind() needs to assert
vm::mutex held. In order to make that possible drop the caching of
kmap_atomic() maps around i915_vma_bind().
An alternative would be to use kmap_local() but since we block cpu
unplugging during sleeps inside kmap_local() sections this may have
unwanted side-effects. Particularly since we might wait for gpu while
holding the vm mutex.
This change may theoretically increase execbuf cpu-usage on snb, but
at least on non-highmem systems that increase should be very small.
Signed-off-by: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 50 ++-
drivers/gpu/drm/i915/i915_vma.c | 1 +
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 2213f7b613da..6013f7e18f60 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1109,6 +1109,47 @@ static inline struct i915_ggtt *cache_to_ggtt(struct
reloc_cache *cache)
return &i915->ggtt;
}
+static void reloc_cache_unmap(struct reloc_cache *cache)
+{
+ void *vaddr;
+
+ if (!cache->vaddr)
+ return;
+
+ vaddr = unmask_page(cache->vaddr);
+ if (cache->vaddr & KMAP)
+ kunmap_atomic(vaddr);
+ else
+ io_mapping_unmap_atomic((void __iomem *)vaddr);
+}
+
+static void reloc_cache_remap(struct reloc_cache *cache,
+ struct drm_i915_gem_object *obj)
+{
+ void *vaddr;
+
+ if (!cache->vaddr)
+ return;
+
+ if (cache->vaddr & KMAP) {
+ struct page *page = i915_gem_object_get_page(obj, cache->page);
+
+ vaddr = kmap_atomic(page);
+ cache->vaddr = unmask_flags(cache->vaddr) |
+ (unsigned long)vaddr;
+ } else {
+ struct i915_ggtt *ggtt = cache_to_ggtt(cache);
+ unsigned long offset;
+
+ offset = cache->node.start;
+ if (!drm_mm_node_allocated(&cache->node))
+ offset += cache->page << PAGE_SHIFT;
+
+ cache->vaddr = (unsigned long)
+ io_mapping_map_atomic_wc(&ggtt->iomap, offset);
+ }
+}
+
static void reloc_cache_reset(struct reloc_cache *cache, struct
i915_execbuffer *eb)
{
void *vaddr;
@@ -1373,10 +1414,17 @@ eb_relocate_entry(struct i915_execbuffer *eb,
* batchbuffers.
*/
if (reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION &&
- GRAPHICS_VER(eb->i915) == 6) {
+ GRAPHICS_VER(eb->i915) == 6 &&
+ !i915_vma_is_bound(target->vma, I915_VMA_GLOBAL_BIND)) {
+ struct i915_vma *vma = target->vma;
+
+ reloc_cache_unmap(&eb->reloc_cache);
+ mutex_lock(&vma->vm->mutex);
err = i915_vma_bind(target->vma,
target->vma->obj->cache_level,
PIN_GLOBAL, NULL);
+ mutex_unlock(&vma->vm->mutex);
+ reloc_cache_remap(&eb->reloc_cache, ev->vma->obj);
if (err)
return err;
}
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 927f0d4f8e11..d792a3d0da7a 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -398,6 +398,7 @@ int i915_vma_bind(struct i915_vma *vma,
u32 bind_flags;
u32 vma_flags;
+ lockdep_assert_held(&vma->vm->mutex);
GEM_BUG_ON(!drm_mm_node_allocated(&vma->node));
GEM_BUG_ON(vma->size > vma->node.size);
--
2.31.1
[PATCH v3 1/7] drm/i915: Avoid using the i915_fence_array when collecting dependencies
Since the gt migration code was using only a single fence for
dependencies, these were collected in a dma_fence_array. However, it
turns out that it's illegal to use some dma_fences in a dma_fence_array,
in particular other dma_fence_arrays and dma_fence_chains, and this
causes trouble for us moving forward.
Have the gt migration code instead take a const struct i915_deps for
dependencies. This means we can skip the dma_fence_array creation
and instead pass the struct i915_deps instead to circumvent the
problem.
v2:
- Make the prev_deps() function static. (kernel test robot )
- Update the struct i915_deps kerneldoc.
Fixes: 5652df829b3c ("drm/i915/ttm: Update i915_gem_obj_copy_ttm() to be
asynchronous")
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 129 +--
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h | 17 +++
drivers/gpu/drm/i915/gt/intel_migrate.c | 24 ++--
drivers/gpu/drm/i915/gt/intel_migrate.h | 9 +-
drivers/gpu/drm/i915/i915_request.c | 22
drivers/gpu/drm/i915/i915_request.h | 2 +
6 files changed, 91 insertions(+), 112 deletions(-)
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 80df9f592407..960145c8200f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -3,8 +3,6 @@
* Copyright © 2021 Intel Corporation
*/
-#include
-
#include
#include "i915_drv.h"
@@ -44,17 +42,12 @@ void i915_ttm_migrate_set_failure_modes(bool gpu_migration,
#endif
/**
- * DOC: Set of utilities to dynamically collect dependencies and
- * eventually coalesce them into a single fence which is fed into
- * the GT migration code, since it only accepts a single dependency
- * fence.
- * The single fence returned from these utilities, in the case of
- * dependencies from multiple fence contexts, a struct dma_fence_array,
- * since the i915 request code can break that up and await the individual
- * fences.
+ * DOC: 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
- * the migration fence with the unbind fences.
+ * the migration fence with the unbind fences if these are coalesced
+ * post-migration.
*
* While collecting the individual dependencies, we store the refcounted
* struct dma_fence pointers in a realloc-managed pointer array, since
@@ -65,32 +58,13 @@ void i915_ttm_migrate_set_failure_modes(bool gpu_migration,
* A struct i915_deps need to be initialized using i915_deps_init().
* If i915_deps_add_dependency() or i915_deps_add_resv() return an
* error code they will internally call i915_deps_fini(), which frees
- * all internal references and allocations. After a call to
- * i915_deps_to_fence(), or i915_deps_sync(), the struct should similarly
- * be viewed as uninitialized.
+ * all internal references and allocations.
*
* We might want to break this out into a separate file as a utility.
*/
#define I915_DEPS_MIN_ALLOC_CHUNK 8U
-/**
- * struct i915_deps - Collect dependencies into a single dma-fence
- * @single: Storage for pointer if the collection is a single fence.
- * @fence: Allocated array of fence pointers if more than a single fence;
- * otherwise points to the address of @single.
- * @num_deps: Current number of dependency fences.
- * @fences_size: Size of the @fences array in number of pointers.
- * @gfp: Allocation mode.
- */
-struct i915_deps {
- struct dma_fence *single;
- struct dma_fence **fences;
- unsigned int num_deps;
- unsigned int fences_size;
- gfp_t gfp;
-};
-
static void i915_deps_reset_fences(struct i915_deps *deps)
{
if (deps->fences != &deps->single)
@@ -163,7 +137,7 @@ static int i915_deps_grow(struct i915_deps *deps, struct
dma_fence *fence,
return ret;
}
-static int i915_deps_sync(struct i915_deps *deps,
+static int i915_deps_sync(const struct i915_deps *deps,
const struct ttm_operation_ctx *ctx)
{
struct dma_fence **fences = deps->fences;
@@ -183,7 +157,6 @@ static int i915_deps_sync(struct i915_deps *deps,
break;
}
- i915_deps_fini(deps);
return ret;
}
@@ -221,34 +194,6 @@ static int i915_deps_add_dependency(struct i915_deps *deps,
return i915_deps_grow(deps, fence, ctx);
}
-static struct dma_fence *i915_deps_to_fence(struct i915_deps *deps,
- const struct ttm_operation_ctx *ctx)
-{
- struct dma_fence_array *array;
-
- if (deps->num_deps == 0)
- return NULL;
-
- if (deps->num_deps == 1) {
- deps->num_deps = 0;
- return deps->fences[0];
- }
-
- /*
-* TODO: Alter the allocation mode here to not try too hard to
-* make things asy
[PATCH v3 0/7] drm/i915: Asynchronous vma unbinding
This patch series introduces infrastructure for asynchronous vma unbinding. The single enabled use-case is initially at buffer object migration where we otherwise sync when unbinding vmas before migration. This in theory allows us to pipeline any number of migrations, but in practice the number is restricted by a sync wait when filling the migration context ring. We might want to look at that moving forward if needed. The other main use-case is to be able to pipeline vma evictions, for example with softpinning where a new vma wants to reuse the vm range of an already active vma. We can't support this just yet because we need dma_resv locking around vma eviction for that, which is under implementation. Patch 1 and 2 are mainly a fix and a subsequent rearrangement of code, Patch 3 is needed for consistent bind locking, Patch 4 introduces vma resource first for error capture purposes. Patch 5 changes the vm backend interface to take vma resources rather than vmas, Patch 6 introduces the async unbinding itself, and finally Patch 7 realizes we have duplicated functionality and removes the vma snapshots. v2: -- Some kernel test robot reports addressed. -- kmem cache for vma resources, See patch 6 -- Various fixes all over the place. See separate commit messages. v3: -- Re-add a missing i915_vma_resource_put() -- Remove a stray debug printout Thomas Hellström (7): drm/i915: Avoid using the i915_fence_array when collecting dependencies drm/i915: Break out the i915_deps utility drm/i915: Require the vm mutex for i915_vma_bind() drm/i915: Initial introduction of vma resources drm/i915: Use the vma resource as argument for gtt binding / unbinding drm/i915: Use vma resources for async unbinding drm/i915: Use struct vma_resource instead of struct vma_snapshot drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/display/intel_dpt.c | 27 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 67 ++- .../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +- drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 304 ++ .../gpu/drm/i915/gem/selftests/huge_pages.c | 37 +- drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 19 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 37 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 9 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 72 ++-- drivers/gpu/drm/i915/gt/intel_gtt.c | 4 + drivers/gpu/drm/i915/gt/intel_gtt.h | 18 +- drivers/gpu/drm/i915/gt/intel_migrate.c | 24 +- drivers/gpu/drm/i915/gt/intel_migrate.h | 9 +- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 22 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 13 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +- drivers/gpu/drm/i915/i915_debugfs.c | 3 +- drivers/gpu/drm/i915/i915_deps.c | 244 +++ drivers/gpu/drm/i915/i915_deps.h | 46 +++ drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gem.c | 3 + drivers/gpu/drm/i915/i915_gpu_error.c | 87 ++-- drivers/gpu/drm/i915/i915_module.c| 3 + drivers/gpu/drm/i915/i915_request.c | 34 +- drivers/gpu/drm/i915/i915_request.h | 8 +- drivers/gpu/drm/i915/i915_vma.c | 214 +- drivers/gpu/drm/i915/i915_vma.h | 33 +- drivers/gpu/drm/i915/i915_vma_resource.c | 387 ++ drivers/gpu/drm/i915/i915_vma_resource.h | 232 +++ drivers/gpu/drm/i915/i915_vma_snapshot.c | 134 -- drivers/gpu/drm/i915/i915_vma_snapshot.h | 112 - drivers/gpu/drm/i915/i915_vma_types.h | 5 + drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 159 --- drivers/gpu/drm/i915/selftests/mock_gtt.c | 12 +- 35 files changed, 1571 insertions(+), 840 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_deps.c create mode 100644 drivers/gpu/drm/i915/i915_deps.h create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.c create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.h delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.c delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.h -- 2.31.1
Re: [Bug Report] Desktop monitor sleep regression
On Fri, Dec 17, 2021 at 03:46:21PM +0100, Thorsten Leemhuis wrote: > added some CCs Geert added in his reply > > On 07.12.21 08:20, Thorsten Leemhuis wrote: > > > > [TLDR: adding this regression to regzbot; most of this mail is compiled > > from a few templates paragraphs some of you might have seen already.] > > > > Hi, this is your Linux kernel regression tracker speaking. > > /me again > > What's up here? We are getting close to rc6, but there afaics wasn't any > reply of substance since the report ten days ago. Hence: > > Could anybody please comment on this? Imre Deak, the commit Brandon > found in the bisection contains a patch of yours, do you maybe have an > idea what's up here? Yes, https://bugzilla.kernel.org/show_bug.cgi?id=215203 based on which the problem is somehere in the AMD driver. > Ciao, Thorsten > > #regzbot poke > > > Adding the regression mailing list to the list of recipients, as it > > should be in the loop for all regressions, as explained here: > > https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html > > > > Also adding the authors and reviewers of the culprit and two appropriate > > mailing lists. > > > > On 07.12.21 01:21, Brandon Nielsen wrote: > >> Monitors no longer sleep properly on my system (dual monitor connected > >> via DP->DVI, amdgpu, x86_64). The monitors slept properly on 5.14, but > >> stopped during the 5.15 series. I have also filed this bug on the kernel > >> bugzilla[0] and downstream[1]. > >> > >> I have performed a bisect, first "bad" commit to master is > >> 55285e21f04517939480966164a33898c34b2af2[1], the same change made it > >> into the 5.15 branch as e3b39825ed0813f787cb3ebdc5ecaa5131623647. > > > > TWIMC: That was for 5.15.3 > > > >> I have > >> verified the issue exists in latest master > >> (a51e3ac43ddbad891c2b1a4f3aa52371d6939570). > >> > >> Steps to reproduce: > >> > >> 1. Boot system (Fedora Workstation 35 in this case) > >> 2. Log in > >> 3. Lock screen (after a few seconds, monitors will enter power save > >> "sleep" state with backlight off) > >> 4. Wait (usually no more than 30 seconds, sometimes up to a few minutes) > >> 5. Observe monitor leaving "sleep" state (backlight comes back on), > >> but nothing is displayed > >> > >> [0] - https://bugzilla.kernel.org/show_bug.cgi?id=215203 > >> [1] - https://bugzilla.redhat.com/show_bug.cgi?id=2028613 > > > > To be sure this issue doesn't fall through the cracks unnoticed, I'm > > adding it to regzbot, my Linux kernel regression tracking bot: > > > > #regzbot ^introduced 55285e21f04517939480966164a33898c34b2af2 > > #regzbot title fbdev/efifb: Monitors no longer sleep (amdgpu dual > > monitor setup) > > #regzbot ignore-activity > > > > Reminder: when fixing the issue, please add a 'Link:' tag with the URL > > to the report (the parent of this mail), then regzbot will automatically > > mark the regression as resolved once the fix lands in the appropriate > > tree. For more details about regzbot see footer. > > > > Sending this to everyone that got the initial report, to make all aware > > of the tracking. I also hope that messages like this motivate people to > > directly get at least the regression mailing list and ideally even > > regzbot involved when dealing with regressions, as messages like this > > wouldn't be needed then. > > > > Don't worry, I'll send further messages wrt to this regression just to > > the lists (with a tag in the subject so people can filter them away), as > > long as they are intended just for regzbot. With a bit of luck no such > > messages will be needed anyway. > > > > Ciao, Thorsten, your Linux kernel regression tracker. > > > > P.S.: As a Linux kernel regression tracker I'm getting a lot of reports > > on my table. I can only look briefly into most of them. Unfortunately > > therefore I sometimes will get things wrong or miss something important. > > I hope that's not the case here; if you think it is, don't hesitate to > > tell me about it in a public reply. That's in everyone's interest, as > > what I wrote above might be misleading to everyone reading this; any > > suggestion I gave they thus might sent someone reading this down the > > wrong rabbit hole, which none of us wants. > > > > BTW, I have no personal interest in this issue, which is tracked using > > regzbot, my Linux kernel regression tracking bot > > (https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting > > this mail to get things rolling again and hence don't need to be CC on > > all further activities wrt to this regression. > >
[PATCH 07/10] drm/qxl: Move ioctl array next to its only user
Move the array qxl_ioctl to qxl_drv.c and initialize the num_ioctls
field of struct drm_driver at runtime. Replaces the current fragile
ioctl setup and allows for generating the module init/exit code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_drv.c | 12 +-
drivers/gpu/drm/qxl/qxl_drv.h | 13 +++
drivers/gpu/drm/qxl/qxl_ioctl.c | 41 ++---
3 files changed, 27 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index e4b16421500b..323671e9cfc8 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -269,6 +269,16 @@ static struct pci_driver qxl_pci_driver = {
.driver.pm = &qxl_pm_ops,
};
+static const struct drm_ioctl_desc qxl_ioctls[] = {
+ DRM_IOCTL_DEF_DRV(QXL_ALLOC, qxl_alloc_ioctl, DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(QXL_MAP, qxl_map_ioctl, DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(QXL_EXECBUFFER, qxl_execbuffer_ioctl, DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(QXL_UPDATE_AREA, qxl_update_area_ioctl, DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(QXL_GETPARAM, qxl_getparam_ioctl, DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(QXL_CLIENTCAP, qxl_clientcap_ioctl, DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(QXL_ALLOC_SURF, qxl_alloc_surf_ioctl, DRM_AUTH),
+};
+
static struct drm_driver qxl_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
@@ -282,6 +292,7 @@ static struct drm_driver qxl_driver = {
.gem_prime_import_sg_table = qxl_gem_prime_import_sg_table,
.fops = &qxl_fops,
.ioctls = qxl_ioctls,
+ .num_ioctls = ARRAY_SIZE(qxl_ioctls),
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
.date = DRIVER_DATE,
@@ -299,7 +310,6 @@ static int __init qxl_init(void)
if (qxl_modeset == 0)
return -EINVAL;
- qxl_driver.num_ioctls = qxl_max_ioctls;
return pci_register_driver(&qxl_pci_driver);
}
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 359266d9e860..29641ceaab7d 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -65,7 +65,6 @@ struct dma_buf_map;
#define QXL_DEBUGFS_MAX_COMPONENTS 32
extern int qxl_num_crtc;
-extern int qxl_max_ioctls;
#define QXL_INTERRUPT_MASK (\
QXL_INTERRUPT_DISPLAY |\
@@ -261,9 +260,6 @@ struct qxl_device {
int qxl_debugfs_fence_init(struct qxl_device *rdev);
-extern const struct drm_ioctl_desc qxl_ioctls[];
-extern int qxl_max_ioctl;
-
int qxl_device_init(struct qxl_device *qdev, struct pci_dev *pdev);
void qxl_device_fini(struct qxl_device *qdev);
@@ -457,4 +453,13 @@ struct qxl_drv_surface *
qxl_surface_lookup(struct drm_device *dev, int surface_id);
void qxl_surface_evict(struct qxl_device *qdev, struct qxl_bo *surf, bool
freeing);
+/* qxl_ioctl.c */
+int qxl_alloc_ioctl(struct drm_device *dev, void *data, struct drm_file
*file_priv);
+int qxl_map_ioctl(struct drm_device *dev, void *data, struct drm_file
*file_priv);
+int qxl_execbuffer_ioctl(struct drm_device *dev, void *data, struct drm_file
*file_priv);
+int qxl_update_area_ioctl(struct drm_device *dev, void *data, struct drm_file
*file);
+int qxl_getparam_ioctl(struct drm_device *dev, void *data, struct drm_file
*file_priv);
+int qxl_clientcap_ioctl(struct drm_device *dev, void *data, struct drm_file
*file_priv);
+int qxl_alloc_surf_ioctl(struct drm_device *dev, void *data, struct drm_file
*file);
+
#endif
diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index 38aabcbe2238..30f58b21372a 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -33,8 +33,7 @@
* TODO: allocating a new gem(in qxl_bo) for each request.
* This is wasteful since bo's are page aligned.
*/
-static int qxl_alloc_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
+int qxl_alloc_ioctl(struct drm_device *dev, void *data, struct drm_file
*file_priv)
{
struct qxl_device *qdev = to_qxl(dev);
struct drm_qxl_alloc *qxl_alloc = data;
@@ -61,8 +60,7 @@ static int qxl_alloc_ioctl(struct drm_device *dev, void *data,
return 0;
}
-static int qxl_map_ioctl(struct drm_device *dev, void *data,
-struct drm_file *file_priv)
+int qxl_map_ioctl(struct drm_device *dev, void *data, struct drm_file
*file_priv)
{
struct qxl_device *qdev = to_qxl(dev);
struct drm_qxl_map *qxl_map = data;
@@ -272,8 +270,7 @@ static int qxl_process_single_command(struct qxl_device
*qdev,
return ret;
}
-static int qxl_execbuffer_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
+int qxl_execbuffer_ioctl(struct drm_device *dev, void *data, struct drm_file
*file_priv)
{
struct qxl_device *qdev = to_qxl(dev);
struct drm_qxl_execbuffer *execbuffer = data;
@@ -297,8 +294,7 @@ static int
[PATCH 06/10] drm/mgag200: Replace module-init boiler-plate code with DRM helpers
Remove custom mgag200_init() and mgag200_exit() functions and initialize
the module with DRM_module helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index 740108a006ba..217844d71ab5 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include "mgag200_drv.h"
@@ -375,24 +376,7 @@ static struct pci_driver mgag200_pci_driver = {
.remove = mgag200_pci_remove,
};
-static int __init mgag200_init(void)
-{
- if (drm_firmware_drivers_only() && mgag200_modeset == -1)
- return -EINVAL;
-
- if (mgag200_modeset == 0)
- return -EINVAL;
-
- return pci_register_driver(&mgag200_pci_driver);
-}
-
-static void __exit mgag200_exit(void)
-{
- pci_unregister_driver(&mgag200_pci_driver);
-}
-
-module_init(mgag200_init);
-module_exit(mgag200_exit);
+drm_module_pci_driver_if_modeset(mgag200_pci_driver, mgag200_modeset);
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
--
2.34.1
[PATCH 04/10] drm/cirrus: Replace module-init boiler-plate code with DRM helpers
Remove custom cirrus_init() and cirrus_exit() functions and initialize
the module with DRM module helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/cirrus.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
index c95d9ff7d600..ecf2475d0f16 100644
--- a/drivers/gpu/drm/tiny/cirrus.c
+++ b/drivers/gpu/drm/tiny/cirrus.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
@@ -633,21 +634,7 @@ static struct pci_driver cirrus_pci_driver = {
.remove = cirrus_pci_remove,
};
-static int __init cirrus_init(void)
-{
- if (drm_firmware_drivers_only())
- return -EINVAL;
-
- return pci_register_driver(&cirrus_pci_driver);
-}
-
-static void __exit cirrus_exit(void)
-{
- pci_unregister_driver(&cirrus_pci_driver);
-}
-
-module_init(cirrus_init);
-module_exit(cirrus_exit);
+drm_module_pci_driver(cirrus_pci_driver)
MODULE_DEVICE_TABLE(pci, pciidlist);
MODULE_LICENSE("GPL");
--
2.34.1
Re: [Bug Report] Desktop monitor sleep regression
added some CCs Geert added in his reply On 07.12.21 08:20, Thorsten Leemhuis wrote: > > [TLDR: adding this regression to regzbot; most of this mail is compiled > from a few templates paragraphs some of you might have seen already.] > > Hi, this is your Linux kernel regression tracker speaking. /me again What's up here? We are getting close to rc6, but there afaics wasn't any reply of substance since the report ten days ago. Hence: Could anybody please comment on this? Imre Deak, the commit Brandon found in the bisection contains a patch of yours, do you maybe have an idea what's up here? Ciao, Thorsten #regzbot poke > Adding the regression mailing list to the list of recipients, as it > should be in the loop for all regressions, as explained here: > https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html > > Also adding the authors and reviewers of the culprit and two appropriate > mailing lists. > > On 07.12.21 01:21, Brandon Nielsen wrote: >> Monitors no longer sleep properly on my system (dual monitor connected >> via DP->DVI, amdgpu, x86_64). The monitors slept properly on 5.14, but >> stopped during the 5.15 series. I have also filed this bug on the kernel >> bugzilla[0] and downstream[1]. >> >> I have performed a bisect, first "bad" commit to master is >> 55285e21f04517939480966164a33898c34b2af2[1], the same change made it >> into the 5.15 branch as e3b39825ed0813f787cb3ebdc5ecaa5131623647. > > TWIMC: That was for 5.15.3 > >> I have >> verified the issue exists in latest master >> (a51e3ac43ddbad891c2b1a4f3aa52371d6939570). >> >> Steps to reproduce: >> >> 1. Boot system (Fedora Workstation 35 in this case) >> 2. Log in >> 3. Lock screen (after a few seconds, monitors will enter power save >> "sleep" state with backlight off) >> 4. Wait (usually no more than 30 seconds, sometimes up to a few minutes) >> 5. Observe monitor leaving "sleep" state (backlight comes back on), >> but nothing is displayed >> >> [0] - https://bugzilla.kernel.org/show_bug.cgi?id=215203 >> [1] - https://bugzilla.redhat.com/show_bug.cgi?id=2028613 > > To be sure this issue doesn't fall through the cracks unnoticed, I'm > adding it to regzbot, my Linux kernel regression tracking bot: > > #regzbot ^introduced 55285e21f04517939480966164a33898c34b2af2 > #regzbot title fbdev/efifb: Monitors no longer sleep (amdgpu dual > monitor setup) > #regzbot ignore-activity > > Reminder: when fixing the issue, please add a 'Link:' tag with the URL > to the report (the parent of this mail), then regzbot will automatically > mark the regression as resolved once the fix lands in the appropriate > tree. For more details about regzbot see footer. > > Sending this to everyone that got the initial report, to make all aware > of the tracking. I also hope that messages like this motivate people to > directly get at least the regression mailing list and ideally even > regzbot involved when dealing with regressions, as messages like this > wouldn't be needed then. > > Don't worry, I'll send further messages wrt to this regression just to > the lists (with a tag in the subject so people can filter them away), as > long as they are intended just for regzbot. With a bit of luck no such > messages will be needed anyway. > > Ciao, Thorsten, your Linux kernel regression tracker. > > P.S.: As a Linux kernel regression tracker I'm getting a lot of reports > on my table. I can only look briefly into most of them. Unfortunately > therefore I sometimes will get things wrong or miss something important. > I hope that's not the case here; if you think it is, don't hesitate to > tell me about it in a public reply. That's in everyone's interest, as > what I wrote above might be misleading to everyone reading this; any > suggestion I gave they thus might sent someone reading this down the > wrong rabbit hole, which none of us wants. > > BTW, I have no personal interest in this issue, which is tracked using > regzbot, my Linux kernel regression tracking bot > (https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting > this mail to get things rolling again and hence don't need to be CC on > all further activities wrt to this regression. >
[PATCH 10/10] drm/vmwgfx: Replace module-init boiler-plate code with DRM helpers
Remove custom vmwgfx_init() and vmwgfx_exit() functions and initialize
the module with DRM_module helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 2d59bdad0373..0c1ccf174787 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -32,9 +32,10 @@
#include
#include
+#include
#include
+#include
#include
-#include
#include
#include
#include
@@ -1651,26 +1652,7 @@ static int vmw_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
return ret;
}
-static int __init vmwgfx_init(void)
-{
- int ret;
-
- if (drm_firmware_drivers_only())
- return -EINVAL;
-
- ret = pci_register_driver(&vmw_pci_driver);
- if (ret)
- DRM_ERROR("Failed initializing DRM.\n");
- return ret;
-}
-
-static void __exit vmwgfx_exit(void)
-{
- pci_unregister_driver(&vmw_pci_driver);
-}
-
-module_init(vmwgfx_init);
-module_exit(vmwgfx_exit);
+drm_module_pci_driver(vmw_pci_driver);
MODULE_AUTHOR("VMware Inc. and others");
MODULE_DESCRIPTION("Standalone drm driver for the VMware SVGA device");
--
2.34.1
[PATCH 05/10] drm/hisilicon/hibmc: Replace module initialization with DRM helpers
Replace module_pci_driver() with drm_module_pci_driver(). The DRM macro
respects drm_firmware_drivers_only() and fails if the flag has been set.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 610fc8e135f9..fe4269c5aa0a 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include "hibmc_drm_drv.h"
@@ -379,7 +380,7 @@ static struct pci_driver hibmc_pci_driver = {
.driver.pm =&hibmc_pm_ops,
};
-module_pci_driver(hibmc_pci_driver);
+drm_module_pci_driver(hibmc_pci_driver);
MODULE_DEVICE_TABLE(pci, hibmc_pci_table);
MODULE_AUTHOR("RongrongZou ");
--
2.34.1
[PATCH 08/10] drm/qxl: Replace module-init boiler-plate code with DRM helpers
Remove custom qxl_init() and qxl_exit() functions and initialize
the module with DRM module helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_drv.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 323671e9cfc8..1cb6f0c224bb 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -303,23 +304,7 @@ static struct drm_driver qxl_driver = {
.release = qxl_drm_release,
};
-static int __init qxl_init(void)
-{
- if (drm_firmware_drivers_only() && qxl_modeset == -1)
- return -EINVAL;
-
- if (qxl_modeset == 0)
- return -EINVAL;
- return pci_register_driver(&qxl_pci_driver);
-}
-
-static void __exit qxl_exit(void)
-{
- pci_unregister_driver(&qxl_pci_driver);
-}
-
-module_init(qxl_init);
-module_exit(qxl_exit);
+drm_module_pci_driver_if_modeset(qxl_pci_driver, qxl_modeset);
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
--
2.34.1
[PATCH 09/10] drm/vboxvideo: Replace module-init boiler-plate code with DRM helpers
Remove custom vbox_init() and vbox_exit() functions and initialize
the module with DRM module helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vboxvideo/vbox_drv.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index f35d9e44c6b7..f4f2bd79a7cb 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "vbox_drv.h"
@@ -190,24 +191,7 @@ static const struct drm_driver driver = {
DRM_GEM_VRAM_DRIVER,
};
-static int __init vbox_init(void)
-{
- if (drm_firmware_drivers_only() && vbox_modeset == -1)
- return -EINVAL;
-
- if (vbox_modeset == 0)
- return -EINVAL;
-
- return pci_register_driver(&vbox_pci_driver);
-}
-
-static void __exit vbox_exit(void)
-{
- pci_unregister_driver(&vbox_pci_driver);
-}
-
-module_init(vbox_init);
-module_exit(vbox_exit);
+drm_module_pci_driver_if_modeset(vbox_pci_driver, vbox_modeset);
MODULE_AUTHOR("Oracle Corporation");
MODULE_AUTHOR("Hans de Goede ");
--
2.34.1
[RFC][PATCH 00/10] drm: Add DRM module helpers for existing PCI drivers
This is an RFC patchset to complement the helper macros provided in [1]. The module helpers create module init and exit helpers that respect the kernel parameters that enable/disable DRM drivers. There's one more patch that prepares qxl by moving some code around. It's required to make use of the helpers from within qxl. Javier, please see if you find anything useful here and cherry-pick into your patchset. The driver changes should complement the ones in your patchset. The module macros are similar to yours and should be easily mergable. I tested the macros with ast. [1] https://patchwork.freedesktop.org/series/98162/ Thomas Zimmermann (10): drm: Provide PCI module-init macros drm/ast: Replace module-init boiler-plate code with DRM helpers drm/bochs: Replace module-init boiler-plate code with DRM helpers drm/cirrus: Replace module-init boiler-plate code with DRM helpers drm/hisilicon/hibmc: Replace module initialization with DRM helpers drm/mgag200: Replace module-init boiler-plate code with DRM helpers drm/qxl: Move ioctl array next to its only user drm/qxl: Replace module-init boiler-plate code with DRM helpers drm/vboxvideo: Replace module-init boiler-plate code with DRM helpers drm/vmwgfx: Replace module-init boiler-plate code with DRM helpers Documentation/gpu/drm-internals.rst | 6 ++ drivers/gpu/drm/ast/ast_drv.c | 18 +--- .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 3 +- drivers/gpu/drm/mgag200/mgag200_drv.c | 20 +--- drivers/gpu/drm/qxl/qxl_drv.c | 31 +++--- drivers/gpu/drm/qxl/qxl_drv.h | 13 ++- drivers/gpu/drm/qxl/qxl_ioctl.c | 41 ++-- drivers/gpu/drm/tiny/bochs.c | 20 +--- drivers/gpu/drm/tiny/cirrus.c | 17 +--- drivers/gpu/drm/vboxvideo/vbox_drv.c | 20 +--- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 24 + include/drm/drm_module.h | 95 +++ 12 files changed, 145 insertions(+), 163 deletions(-) create mode 100644 include/drm/drm_module.h base-commit: 3f422828221d9ceefcddef0be33561b1646a1cbe -- 2.34.1
[PATCH 03/10] drm/bochs: Replace module-init boiler-plate code with DRM helpers
Remove custom bochs_init() and bochs_exit() functions and initialize
the module with DRM module helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/bochs.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c
index fc26a1ce11ee..ed971c8bb446 100644
--- a/drivers/gpu/drm/tiny/bochs.c
+++ b/drivers/gpu/drm/tiny/bochs.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
@@ -716,24 +717,7 @@ static struct pci_driver bochs_pci_driver = {
/* -- */
/* module init/exit */
-static int __init bochs_init(void)
-{
- if (drm_firmware_drivers_only() && bochs_modeset == -1)
- return -EINVAL;
-
- if (bochs_modeset == 0)
- return -EINVAL;
-
- return pci_register_driver(&bochs_pci_driver);
-}
-
-static void __exit bochs_exit(void)
-{
- pci_unregister_driver(&bochs_pci_driver);
-}
-
-module_init(bochs_init);
-module_exit(bochs_exit);
+drm_module_pci_driver_if_modeset(bochs_pci_driver, bochs_modeset);
MODULE_DEVICE_TABLE(pci, bochs_pci_tbl);
MODULE_AUTHOR("Gerd Hoffmann ");
--
2.34.1
[PATCH 01/10] drm: Provide PCI module-init macros
Provide helper macros to register PCI-based DRM drivers. The new
macros behave like module_pci_driver() with an additional test if
DRM modesetting has been enabled.
Signed-off-by: Thomas Zimmermann
---
Documentation/gpu/drm-internals.rst | 6 ++
include/drm/drm_module.h| 95 +
2 files changed, 101 insertions(+)
create mode 100644 include/drm/drm_module.h
diff --git a/Documentation/gpu/drm-internals.rst
b/Documentation/gpu/drm-internals.rst
index 607f78f0f189..38afed24a75c 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -75,6 +75,12 @@ update it, its value is mostly useless. The DRM core prints
it to the
kernel log at initialization time and passes it to userspace through the
DRM_IOCTL_VERSION ioctl.
+Module Initialization
+-
+
+.. kernel-doc:: include/drm/drm_module.h
+ :doc: overview
+
Managing Ownership of the Framebuffer Aperture
--
diff --git a/include/drm/drm_module.h b/include/drm/drm_module.h
new file mode 100644
index ..eb3fd7bcbec9
--- /dev/null
+++ b/include/drm/drm_module.h
@@ -0,0 +1,95 @@
+/* SPDX-License-Identifier: MIT */
+
+#ifndef DRM_MODULE_H
+#define DRM_MODULE_H
+
+#include
+
+#include
+
+/**
+ * DOC: overview
+ *
+ * This library provides helpers registering DRM drivers during module
+ * initialization and shutdown. The provided helpers act like bus-specific
+ * module helpers, such as module_pci_driver(), but respect additional
+ * parameters that control DRM driver registration.
+ *
+ * Below is an example of initializing a DRM driver for a device on the
+ * PCI bus.
+ *
+ * .. code-block:: c
+ *
+ * struct pci_driver my_pci_drv = {
+ * };
+ *
+ * drm_module_pci_driver(my_pci_drv);
+ *
+ * The generated code will test if DRM drivers are enabled and register
+ * the PCI driver my_pci_drv. For more complex module initialization, you
+ * can still use module_init() and module_exit() in your driver.
+ */
+
+/*
+ * PCI drivers
+ */
+
+static inline int __init drm_pci_register_driver(struct pci_driver *pci_drv)
+{
+ if (drm_firmware_drivers_only())
+ return -ENODEV;
+
+ return pci_register_driver(pci_drv);
+}
+
+/**
+ * drm_module_pci_driver - Register a DRM driver for PCI-based devices
+ * @__pci_drv: the PCI driver structure
+ *
+ * Registers a DRM driver for devices on the PCI bus. The helper
+ * macro behaves like module_pci_driver() but tests the state of
+ * drm_firmware_drivers_only(). For more complex module initialization,
+ * use module_init() and module_exit() directly.
+ *
+ * Each module may only use this macro once. Calling it replaces
+ * module_init() and module_exit().
+ */
+#define drm_module_pci_driver(__pci_drv) \
+ module_driver(__pci_drv, drm_pci_register_driver, pci_unregister_driver)
+
+static inline int __init
+drm_pci_register_driver_if_modeset(struct pci_driver *pci_drv, int modeset)
+{
+ if (drm_firmware_drivers_only() && modeset == -1)
+ return -ENODEV;
+ if (modeset == 0)
+ return -ENODEV;
+
+ return pci_register_driver(pci_drv);
+}
+
+static inline void __exit
+drm_pci_unregister_driver_if_modeset(struct pci_driver *pci_drv, int modeset)
+{
+ pci_unregister_driver(pci_drv);
+}
+
+/**
+ * drm_module_pci_driver_if_modeset - Register a DRM driver for PCI-based
devices
+ * @__pci_drv: the PCI driver structure
+ * @__modeset: an additional parameter that disables the driver
+ *
+ * This macro is deprecated and only provided for existing drivers. For
+ * new drivers, use drm_module_pci_driver().
+ *
+ * Registers a DRM driver for devices on the PCI bus. The helper macro
+ * behaves like drm_module_pci_driver() with an additional driver-specific
+ * flag. If __modeset is 0, the driver has been disabled, if __modeset is
+ * -1 the driver state depends on the global DRM state. For all other
+ * values, the PCI driver has been enabled. The default should be -1.
+ */
+#define drm_module_pci_driver_if_modeset(__pci_drv, __modeset) \
+ module_driver(__pci_drv, drm_pci_register_driver_if_modeset, \
+ drm_pci_unregister_driver_if_modeset, __modeset)
+
+#endif
--
2.34.1
[PATCH 02/10] drm/ast: Replace module-init boiler-plate code with DRM helpers
Remove custom ast_init() and ast_exit() functions and initialize the
module with DRM module helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.c | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 6d8613f6fe1c..7465c4f0156a 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include "ast_drv.h"
@@ -230,22 +231,7 @@ static struct pci_driver ast_pci_driver = {
.driver.pm = &ast_pm_ops,
};
-static int __init ast_init(void)
-{
- if (drm_firmware_drivers_only() && ast_modeset == -1)
- return -EINVAL;
-
- if (ast_modeset == 0)
- return -EINVAL;
- return pci_register_driver(&ast_pci_driver);
-}
-static void __exit ast_exit(void)
-{
- pci_unregister_driver(&ast_pci_driver);
-}
-
-module_init(ast_init);
-module_exit(ast_exit);
+drm_module_pci_driver_if_modeset(ast_pci_driver, ast_modeset);
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
--
2.34.1
Re: completely rework the dma_resv semantic
Hi Daniel, looks like this is going nowhere and you don't seem to have time to review. What can we do? Thanks, Christian. Am 07.12.21 um 13:33 schrieb Christian König: Hi Daniel, just a gentle ping that you wanted to take a look at this. Not much changed compared to the last version, only a minor bugfix in the dma_resv_get_singleton error handling. Regards, Christian.
Re: [PATCH v2 01/37] drm: Add drm_module_{pci,platform}_driver() helper macros
Hi Javier,
looks good already. Some comments are below.
Am 17.12.21 um 01:37 schrieb Javier Martinez Canillas:
According to disable Documentation/admin-guide/kernel-parameters.txt, the
nomodeset parameter can be used to disable kernel modesetting.
DRM drivers will not perform display-mode changes or accelerated rendering
and only the system framebuffer will be available if it was set-up.
But only a few DRM drivers currently check for nomodeset, so let's add two
helper macros that can be used by DRM drivers for PCI and platform devices
to have module init functions that checks if the drivers could be loaded.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
---
(no changes since v1)
include/drm/drm_drv.h | 50 +++
1 file changed, 50 insertions(+)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
I worked on a similar patch today and found that drm_drv.h is actually
not a good place. Half of DRM includes this file and now it all depends
on linux/pci.h and linux/platform.h (and probably other later).
I propose to put the module helpers into and include
it where necessary.
index f6159acb8856..4001d73428c5 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -29,6 +29,8 @@
#include
#include
+#include
+#include
#include
@@ -604,4 +606,52 @@ int drm_dev_set_unique(struct drm_device *dev, const char *name);
extern bool drm_firmware_drivers_only(void);
+/**
+ * drm_pci_register_driver() - register a DRM driver for PCI devices
+ * @drv: PCI driver structure
+ *
+ * Returns zero on success or a negative errno code on failure.
+ */
+static inline int drm_pci_register_driver(struct pci_driver *drv)
This should be declared as __init, so it goes into a separate section of
the module. IIRC the page in the init section are released after the
module has been loaded.
I'd either not document the register functions, or explicitly say that
the module macros are the preferred way of using them.
+{
+ if (drm_firmware_drivers_only())
+ return -ENODEV;
+
+ return pci_register_driver(drv);
+}
+
+/**
+ * drm_module_pci_driver() - helper macro for registering a DRM PCI driver
Docs for the __pci_driver argument
+ *
+ * Helper macro for DRM PCI drivers which do not do anything special in their
+ * module init/exit and just need the DRM specific module init.
+ */
+#define drm_module_pci_driver(__pci_driver) \
+ module_driver(__pci_driver, drm_pci_register_driver, \
+ pci_unregister_driver)
+
+/**
+ * drm_platform_driver_register - register a DRM driver for platform devices
+ * @drv: platform driver structure
+ *
+ * Returns zero on success or a negative errno code on failure.
+ */
+static inline int drm_platform_driver_register(struct platform_driver *drv)
+{
+ if (drm_firmware_drivers_only())
+ return -ENODEV;
+
+ return platform_driver_register(drv);
+}
+
+/**
+ * drm_module_platform_driver() - helper macro for registering a DRM platform
driver
Docs for the __platform_driver argument
Best regards
Thomas
+ *
+ * Helper macro for DRM platform drivers which do not do anything special in
their
+ * module init/exit and just need the DRM specific module init.
+ */
+#define drm_module_platform_driver(__platform_driver) \
+ module_driver(__platform_driver, drm_platform_driver_register, \
+ platform_driver_unregister)
+
#endif
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
[GIT PULL] drm/tegra: Changes for v5.17-rc1
Hi Dave, Daniel, The following changes since commit 136057256686de39cc3a07c2e39ef6bc43003ff6: Linux 5.16-rc2 (2021-11-21 13:47:39 -0800) are available in the Git repository at: https://gitlab.freedesktop.org/drm/tegra.git tags/drm/tegra/for-5.17-rc1 for you to fetch changes up to d210919dbdc8a82c676cc3e3c370b1802be63124: drm/tegra: Add back arm_iommu_detach_device() (2021-12-16 14:30:45 +0100) This is unusually big because it contains essentially two cycles' worth of work. I'm still not sure what happened for v5.16-rc1, but the PR was never merged. Fingers crossed that it will work better this time. As mentioned last time already, the userspace for the new NVDEC driver can be found here: https://github.com/cyndis/vaapi-tegra-driver Thanks, Thierry drm/tegra: Changes for v5.17-rc1 This contains a fairly large rework that makes the buffer objects behave more according to what the DMA-BUF infrastructure expects. A buffer object cache is implemented on top of that to make certain operations such as page-flipping more efficient by avoiding needless map/unmap operations. This in turn is useful to implement asynchronous commits to support legacy cursor updates. Another fairly big addition is the NVDEC driver. This uses the updated UABI introduced in v5.15-rc1 to provide access to the video decode engines found on Tegra210 and later. This also includes some power management improvements that are useful on older devices in particular because they, together with a bunch of other changes across the kernel, allow the system to scale down frequency and voltages when mostly idle and prevent these devices from becoming excessively hot. The remainder of these changes is an assortment of cleanups and minor fixes. Arnd Bergmann (3): gpu: host1x: select CONFIG_DMA_SHARED_BUFFER drm/tegra: Mark nvdec_writel() as inline drm/tegra: Mark nvdec PM functions as __maybe_unused Dmitry Osipenko (19): soc/tegra: Enable runtime PM during OPP state-syncing soc/tegra: Add devm_tegra_core_dev_init_opp_table_common() drm/tegra: dc: rgb: Move PCLK shifter programming to CRTC drm/tegra: dc: rgb: Allow changing PLLD rate on Tegra30+ drm/tegra: hdmi: Unwind tegra_hdmi_init() errors drm/tegra: hdmi: Register audio CODEC on Tegra20 gpu: host1x: Add initial runtime PM and OPP support gpu: host1x: Add host1x_channel_stop() drm/tegra: submit: Add missing pm_runtime_mark_last_busy() drm/tegra: dc: Support OPP and SoC core voltage scaling drm/tegra: hdmi: Add OPP support drm/tegra: gr2d: Support generic power domain and runtime PM drm/tegra: gr3d: Support generic power domain and runtime PM drm/tegra: vic: Stop channel on suspend drm/tegra: nvdec: Stop channel on suspend drm/tegra: submit: Remove pm_runtime_enabled() checks drm/tegra: Consolidate runtime PM management of older UAPI codepath gpu: host1x: Add back arm_iommu_detach_device() drm/tegra: Add back arm_iommu_detach_device() Mikko Perttunen (3): drm/tegra: Add NVDEC driver drm/tegra: Bump VIC/NVDEC clock rates to Fmax drm/tegra: vic: Use autosuspend Randy Dunlap (1): gpu: host1x: Drop excess kernel-doc entry @key Robin Murphy (2): drm/tegra: vic: Fix DMA API misuse gpu: host1x: Add missing DMA API include Thierry Reding (8): Merge branch 'tegra-for-5.17-soc-opp' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into drm/tegra/for-next drm/tegra: Implement correct DMA-BUF semantics drm/tegra: Implement buffer object cache drm/tegra: Do not reference tegra_plane_funcs directly drm/tegra: Propagate errors from drm_gem_plane_helper_prepare_fb() drm/tegra: Support asynchronous commits for cursor drm/tegra: gr2d: Explicitly control module reset drm/tegra: vic: Handle tegra_drm_alloc() failure Wan Jiabing (1): drm/tegra: Remove duplicate struct declaration drivers/gpu/drm/tegra/Kconfig | 3 + drivers/gpu/drm/tegra/Makefile | 3 +- drivers/gpu/drm/tegra/dc.c | 194 +-- drivers/gpu/drm/tegra/dc.h | 3 + drivers/gpu/drm/tegra/drm.c| 30 ++- drivers/gpu/drm/tegra/drm.h| 1 + drivers/gpu/drm/tegra/gem.c| 171 +- drivers/gpu/drm/tegra/gr2d.c | 151 +++- drivers/gpu/drm/tegra/gr3d.c | 353 +++- drivers/gpu/drm/tegra/hdmi.c | 183 +-- drivers/gpu/drm/tegra/hub.h| 1 - drivers/gpu/drm/tegra/nvdec.c | 466 + drivers/gpu/drm/tegra/plane.c | 65 ++ drivers/gpu/drm/tegra/plane.h | 2 +- drivers/gpu/drm/tegra/rgb.c| 53 - drivers/gpu/drm/tegra/submit.c | 77 -- drivers/gpu/drm/tegra/uapi.c
Re: [Intel-gfx] [PATCH v3 13/17] drm/i915: Add object locking to i915_gem_evict_for_node and i915_gem_evict_something
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst wrote: > > Because we will start to require the obj->resv lock for unbinding, > ensure these shrinker functions also take the lock. > > This requires some function signature changes, to ensure that the > ww context is passed around, but is mostly straightforward. Do we even need this? We aren't handling the shared dma-resv for these ones, right? Or more just to have a consistent-ish interface? > > Previously this was split up into several patches, but reworking > should allow for easier bisection. > > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +- > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +- > drivers/gpu/drm/i915/gvt/aperture_gm.c| 2 +- > drivers/gpu/drm/i915/i915_drv.h | 2 ++ > drivers/gpu/drm/i915/i915_gem_evict.c | 34 +++ > drivers/gpu/drm/i915/i915_gem_gtt.c | 8 +++-- > drivers/gpu/drm/i915/i915_gem_gtt.h | 3 ++ > drivers/gpu/drm/i915/i915_vgpu.c | 2 +- > drivers/gpu/drm/i915/i915_vma.c | 9 ++--- > .../gpu/drm/i915/selftests/i915_gem_evict.c | 17 +- > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 14 > 11 files changed, 63 insertions(+), 32 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c > b/drivers/gpu/drm/i915/gt/intel_ggtt.c > index a287c9186ec9..ed43e9c80aaa 100644 > --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c > @@ -504,7 +504,7 @@ static int ggtt_reserve_guc_top(struct i915_ggtt *ggtt) > GEM_BUG_ON(ggtt->vm.total <= GUC_GGTT_TOP); > size = ggtt->vm.total - GUC_GGTT_TOP; > > - ret = i915_gem_gtt_reserve(&ggtt->vm, &ggtt->uc_fw, size, > + ret = i915_gem_gtt_reserve(&ggtt->vm, NULL, &ggtt->uc_fw, size, >GUC_GGTT_TOP, I915_COLOR_UNEVICTABLE, >PIN_NOEVICT); > if (ret) > diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > index e5ad4d5a91c0..a3597a6bb805 100644 > --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c > @@ -1382,7 +1382,7 @@ static int evict_vma(void *data) > complete(&arg->completion); > > mutex_lock(&vm->mutex); > - err = i915_gem_evict_for_node(vm, &evict, 0); > + err = i915_gem_evict_for_node(vm, NULL, &evict, 0); > mutex_unlock(&vm->mutex); > > return err; > diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c > b/drivers/gpu/drm/i915/gvt/aperture_gm.c > index 0d6d59871308..c08098a167e9 100644 > --- a/drivers/gpu/drm/i915/gvt/aperture_gm.c > +++ b/drivers/gpu/drm/i915/gvt/aperture_gm.c > @@ -63,7 +63,7 @@ static int alloc_gm(struct intel_vgpu *vgpu, bool high_gm) > > mutex_lock(>->ggtt->vm.mutex); > mmio_hw_access_pre(gt); > - ret = i915_gem_gtt_insert(>->ggtt->vm, node, > + ret = i915_gem_gtt_insert(>->ggtt->vm, NULL, node, > size, I915_GTT_PAGE_SIZE, > I915_COLOR_UNEVICTABLE, > start, end, flags); > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index c180019c607f..2a98192a89c1 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1718,11 +1718,13 @@ i915_gem_vm_lookup(struct drm_i915_file_private > *file_priv, u32 id) > > /* i915_gem_evict.c */ > int __must_check i915_gem_evict_something(struct i915_address_space *vm, > + struct i915_gem_ww_ctx *ww, > u64 min_size, u64 alignment, > unsigned long color, > u64 start, u64 end, > unsigned flags); > int __must_check i915_gem_evict_for_node(struct i915_address_space *vm, > +struct i915_gem_ww_ctx *ww, > struct drm_mm_node *node, > unsigned int flags); > int i915_gem_evict_vm(struct i915_address_space *vm, > diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c > b/drivers/gpu/drm/i915/i915_gem_evict.c > index bfd66f539fc1..f502a617b35c 100644 > --- a/drivers/gpu/drm/i915/i915_gem_evict.c > +++ b/drivers/gpu/drm/i915/i915_gem_evict.c > @@ -51,6 +51,7 @@ static int ggtt_flush(struct intel_gt *gt) > > static bool > mark_free(struct drm_mm_scan *scan, > + struct i915_gem_ww_ctx *ww, > struct i915_vma *vma, > unsigned int flags, > struct list_head *unwind) > @@ -58,6 +59,9 @@ mark_free(struct drm_mm_scan *scan, > if (i915_vma_is_pinned(vma)) > return false; > > + if (!i915_gem_object_trylock
[PATCH v6 6/7] drm/sun4i: tcon: Enable the A20 dual-link output
The A20 second TCON (TCON1) can be used as a secondary output to drive a
dual-link LVDS output. Let's add it to our capabilities.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 5e8f020d8c03..fef9457d898e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1519,6 +1519,7 @@ static const struct sun4i_tcon_quirks
sun7i_a20_tcon0_quirks = {
};
static const struct sun4i_tcon_quirks sun7i_a20_quirks = {
+ .supports_lvds = true,
.has_channel_0 = true,
.has_channel_1 = true,
.dclk_min_div = 4,
--
2.33.1
[PATCH v6 7/7] [DO NOT MERGE] ARM: dts: sun7i: Enable LVDS Dual-Link on the Cubieboard
For the sake of the example, let's enable an LVDS Dual-Link display on a
Cubieboard.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 69 +
1 file changed, 69 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
index e35e6990c4b2..b10d387385d9 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
@@ -85,6 +85,49 @@ led-1 {
gpios = <&pio 7 20 GPIO_ACTIVE_HIGH>;
};
};
+
+ panel: panel {
+ compatible = "panel-lvds";
+ width-mm = <153>;
+ height-mm = <90>;
+ data-mapping = "vesa-24";
+
+ panel-timing {
+ clock-frequency = <14850>;
+ hfront-porch = <88>;
+ hactive = <1920>;
+ hback-porch = <148>;
+ hsync-len = <44>;
+
+ vfront-porch = <4>;
+ vactive = <1080>;
+ vback-porch = <36>;
+ vsync-len = <5>;
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dual-lvds-even-pixels;
+
+ panel_input_0: endpoint {
+ remote-endpoint = <&tcon0_out_panel>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dual-lvds-odd-pixels;
+
+ panel_input_1: endpoint {
+ remote-endpoint = <&tcon1_out_panel>;
+ };
+ };
+ };
+ };
};
&ahci {
@@ -218,6 +261,32 @@ ®_usb2_vbus {
status = "okay";
};
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_lvds0_pins>;
+ link-companion = <&tcon1>;
+ status = "okay";
+};
+
+&tcon0_out {
+ tcon0_out_panel: endpoint@0 {
+ remote-endpoint = <&panel_input_0>;
+ };
+};
+
+&tcon1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_lvds1_pins>;
+ link-companion = <&tcon0>;
+ status = "okay";
+};
+
+&tcon1_out {
+ tcon1_out_panel: endpoint@0 {
+ remote-endpoint = <&panel_input_1>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.33.1
[PATCH v6 3/7] dt-bindings: display: sun4i: Add LVDS link companion property
The Allwinner SoCs with two TCONs and LVDS output can use both to drive an LVDS dual-link. Add a new property to express that link between these two TCONs. Reviewed-by: Laurent Pinchart Signed-off-by: Maxime Ripard --- .../bindings/display/allwinner,sun4i-a10-tcon.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml index 3a7d5d731712..42dcb8a86433 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml @@ -113,6 +113,12 @@ properties: - const: edp - const: lvds + link-companion: +$ref: /schemas/types.yaml#/definitions/phandle +description: > + Phandle to the other TCON in the system used to drive a dual-link LVDS + output. This property shall be set in both TCON instances. + ports: $ref: /schemas/graph.yaml#/properties/ports -- 2.33.1
[PATCH v6 4/7] drm/sun4i: tcon: Refactor the LVDS and panel probing
The current code to parse the DT, deal with the older device trees, and
register either the RGB or LVDS output has so far grown organically into
the bind function and has become quite hard to extend properly.
Let's move it into a single function that grabs all the resources it needs
and registers the proper panel output.
Reviewed-by: Chen-Yu Tsai
Reviewed-by: Laurent Pinchart
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 127 +
1 file changed, 58 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 88db2d2a9336..4e01807ecf41 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -866,6 +866,63 @@ static int sun4i_tcon_init_regmap(struct device *dev,
return 0;
}
+static int sun4i_tcon_register_panel(struct drm_device *drm,
+struct sun4i_tcon *tcon)
+{
+ struct device_node *companion;
+ struct device_node *remote;
+ struct device *dev = tcon->dev;
+ int ret;
+
+ /*
+* If we have an LVDS panel connected to the TCON, we should
+* just probe the LVDS connector. Otherwise, let's just register
+* an RGB panel.
+*/
+ remote = of_graph_get_remote_node(dev->of_node, 1, 0);
+ if (!tcon->quirks->supports_lvds ||
+ !of_device_is_compatible(remote, "panel-lvds"))
+ return sun4i_rgb_init(drm, tcon);
+
+ /*
+* This can only be made optional since we've had DT
+* nodes without the LVDS reset properties.
+*
+* If the property is missing, just disable LVDS, and
+* print a warning.
+*/
+ tcon->lvds_rst = devm_reset_control_get_optional(dev, "lvds");
+ if (IS_ERR(tcon->lvds_rst)) {
+ dev_err(dev, "Couldn't get our reset line\n");
+ return PTR_ERR(tcon->lvds_rst);
+ } else if (!tcon->lvds_rst) {
+ dev_warn(dev, "Missing LVDS reset property, please upgrade your
DT\n");
+ return -ENODEV;
+ }
+
+ reset_control_reset(tcon->lvds_rst);
+
+ /*
+* This can only be made optional since we've had DT
+* nodes without the LVDS clocks properties.
+*
+* If the property is missing, just disable LVDS, and
+* print a warning.
+*/
+ if (tcon->quirks->has_lvds_alt) {
+ tcon->lvds_pll = devm_clk_get_optional(dev, "lvds-alt");
+ if (IS_ERR(tcon->lvds_pll)) {
+ dev_err(dev, "Couldn't get the LVDS PLL\n");
+ return PTR_ERR(tcon->lvds_pll);
+ } else if (!tcon->lvds_pll) {
+ dev_warn(dev, "Missing LVDS PLL clock, please upgrade
your DT\n");
+ return -ENODEV;
+ }
+ }
+
+ return sun4i_lvds_init(drm, tcon);
+}
+
/*
* On SoCs with the old display pipeline design (Display Engine 1.0),
* the TCON is always tied to just one backend. Hence we can traverse
@@ -1113,10 +1170,8 @@ static int sun4i_tcon_bind(struct device *dev, struct
device *master,
struct drm_device *drm = data;
struct sun4i_drv *drv = drm->dev_private;
struct sunxi_engine *engine;
- struct device_node *remote;
struct sun4i_tcon *tcon;
struct reset_control *edp_rstc;
- bool has_lvds_rst, has_lvds_alt, can_lvds;
int ret;
engine = sun4i_tcon_find_engine(drv, dev->of_node);
@@ -1161,58 +1216,6 @@ static int sun4i_tcon_bind(struct device *dev, struct
device *master,
return ret;
}
- if (tcon->quirks->supports_lvds) {
- /*
-* This can only be made optional since we've had DT
-* nodes without the LVDS reset properties.
-*
-* If the property is missing, just disable LVDS, and
-* print a warning.
-*/
- tcon->lvds_rst = devm_reset_control_get_optional(dev, "lvds");
- if (IS_ERR(tcon->lvds_rst)) {
- dev_err(dev, "Couldn't get our reset line\n");
- return PTR_ERR(tcon->lvds_rst);
- } else if (tcon->lvds_rst) {
- has_lvds_rst = true;
- reset_control_reset(tcon->lvds_rst);
- } else {
- has_lvds_rst = false;
- }
-
- /*
-* This can only be made optional since we've had DT
-* nodes without the LVDS reset properties.
-*
-* If the property is missing, just disable LVDS, and
-* print a warning.
-*/
- if (tcon->quirks->has_lvds_alt) {
- tcon->lvds_pll = devm_clk_get(dev, "lvds-alt");
- if (IS_ERR(tcon->lv
[PATCH v6 5/7] drm/sun4i: tcon: Support the LVDS Dual-Link
The A20 and other SoC with two TCONs (A31, R40, etc.) can use its second
TCON as the secondary LVDS link in a dual-link setup, with the TCON0 being
the main link. Extend a bit the parsing code to leverage the DRM dual-link
code, register only the LVDS output on the primary TCON, and add the needed
bits to setup the TCON properly.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 36 ++
drivers/gpu/drm/sun4i/sun4i_tcon.h | 4
2 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 4e01807ecf41..5e8f020d8c03 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -475,6 +475,10 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon
*tcon,
SUN4I_TCON0_BASIC2_V_BACKPORCH(bp));
reg = SUN4I_TCON0_LVDS_IF_CLK_SEL_TCON0;
+
+ if (tcon->lvds_dual_link)
+ reg |= SUN4I_TCON0_LVDS_IF_DUAL_LINK;
+
if (sun4i_tcon_get_pixel_depth(encoder) == 24)
reg |= SUN4I_TCON0_LVDS_IF_BITWIDTH_24BITS;
else
@@ -884,6 +888,16 @@ static int sun4i_tcon_register_panel(struct drm_device
*drm,
!of_device_is_compatible(remote, "panel-lvds"))
return sun4i_rgb_init(drm, tcon);
+ /*
+* Only the TCON0 will be relevant for the LVDS output, so if
+* our ID is something else, let's prevent our TCON from
+* registering its own LVDS output
+*/
+ if (tcon->id) {
+ dev_dbg(dev, "TCON used as an LVDS secondary link.");
+ return 0;
+ }
+
/*
* This can only be made optional since we've had DT
* nodes without the LVDS reset properties.
@@ -920,6 +934,28 @@ static int sun4i_tcon_register_panel(struct drm_device
*drm,
}
}
+ /*
+* If we don't have a second TCON, we will never be able to do
+* dual-link LVDS, so we don't have much more to do.
+*/
+ companion = of_parse_phandle(dev->of_node, "link-companion", 0);
+ if (!companion)
+ return sun4i_lvds_init(drm, tcon);
+
+ /*
+* Let's do a sanity check on the dual-link setup to make sure
+* everything is properly described.
+*/
+ ret = drm_of_lvds_get_dual_link_pixel_order(dev->of_node, 1, 0,
+ companion, 1, 0);
+ if (ret < 0) {
+ dev_err(dev, "Invalid Dual-Link Configuration.\n");
+ return ret;
+ }
+
+ dev_info(dev, "Primary TCON, enabling LVDS Dual-Link");
+ tcon->lvds_dual_link = true;
+
return sun4i_lvds_init(drm, tcon);
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index e624f6977eb8..7609a880a8a7 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -98,6 +98,7 @@
#define SUN4I_TCON0_LVDS_IF_REG0x84
#define SUN4I_TCON0_LVDS_IF_EN BIT(31)
+#define SUN4I_TCON0_LVDS_IF_DUAL_LINK BIT(30)
#define SUN4I_TCON0_LVDS_IF_BITWIDTH_MASK BIT(26)
#define SUN4I_TCON0_LVDS_IF_BITWIDTH_18BITS(1 << 26)
#define SUN4I_TCON0_LVDS_IF_BITWIDTH_24BITS(0 << 26)
@@ -281,6 +282,9 @@ struct sun4i_tcon {
/* Associated crtc */
struct sun4i_crtc *crtc;
+ /* Is the LVDS link a dual-channel link? */
+ boollvds_dual_link;
+
int id;
/* TCON list management */
--
2.33.1
[PATCH v6 2/7] drm/of: Change the prototype of drm_of_lvds_get_dual_link_pixel_order
The drm_of_lvds_get_dual_link_pixel_order() function took so far the
device_node of the two ports used together to make up a dual-link LVDS
output.
This assumes that a binding would use an entire port for the LVDS output.
However, some bindings have used endpoints instead and thus we need to
operate at the endpoint level. Change slightly the arguments to allow that.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 9 +-
drivers/gpu/drm/drm_of.c | 138 --
drivers/gpu/drm/rcar-du/rcar_lvds.c | 8 +-
include/drm/drm_of.h | 16 ++-
4 files changed, 123 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index 945f08de45f1..763be3a43565 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -568,15 +568,10 @@ static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx, enum
sn65dsi83_model model)
ctx->lvds_dual_link = false;
ctx->lvds_dual_link_even_odd_swap = false;
if (model != MODEL_SN65DSI83) {
- struct device_node *port2, *port3;
int dual_link;
- port2 = of_graph_get_port_by_id(dev->of_node, 2);
- port3 = of_graph_get_port_by_id(dev->of_node, 3);
- dual_link = drm_of_lvds_get_dual_link_pixel_order(port2, port3);
- of_node_put(port2);
- of_node_put(port3);
-
+ dual_link = drm_of_lvds_get_dual_link_pixel_order(dev->of_node,
2, -1,
+ dev->of_node,
3, -1);
if (dual_link == DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS) {
ctx->lvds_dual_link = true;
/* Odd pixels to LVDS Channel A, even pixels to B */
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 59d368ea006b..0759fff201ef 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -303,13 +303,35 @@ static int drm_of_lvds_get_port_pixels_type(struct
device_node *port_node)
(odd_pixels ? DRM_OF_LVDS_ODD : 0);
}
-static int drm_of_lvds_get_remote_pixels_type(
- const struct device_node *port_node)
+static int drm_of_lvds_get_remote_pixels_type(const struct device_node
*endpoint)
{
- struct device_node *endpoint = NULL;
- int pixels_type = -EPIPE;
+ struct device_node *remote_port;
+ int pixels_type;
- for_each_child_of_node(port_node, endpoint) {
+ remote_port = of_graph_get_remote_port(endpoint);
+ if (!remote_port)
+ return -EPIPE;
+
+ pixels_type = drm_of_lvds_get_port_pixels_type(remote_port);
+ of_node_put(remote_port);
+
+ if (pixels_type < 0)
+ return -EPIPE;
+
+ return pixels_type;
+}
+
+static int drm_of_lvds_check_remote_port(const struct device_node *dev, int id)
+{
+ struct device_node *endpoint;
+ struct device_node *port;
+ int previous_pt = -EPIPE;
+
+ port = of_graph_get_port_by_id(dev, id);
+ if (!port)
+ return -EINVAL;
+
+ for_each_child_of_node(port, endpoint) {
struct device_node *remote_port;
int current_pt;
@@ -318,14 +340,19 @@ static int drm_of_lvds_get_remote_pixels_type(
remote_port = of_graph_get_remote_port(endpoint);
if (!remote_port) {
- of_node_put(endpoint);
+ of_node_put(port);
return -EPIPE;
}
current_pt = drm_of_lvds_get_port_pixels_type(remote_port);
of_node_put(remote_port);
- if (pixels_type < 0)
- pixels_type = current_pt;
+ if (!current_pt) {
+ of_node_put(port);
+ return -EINVAL;
+ }
+
+ if (previous_pt < 0)
+ previous_pt = current_pt;
/*
* Sanity check, ensure that all remote endpoints have the same
@@ -334,19 +361,26 @@ static int drm_of_lvds_get_remote_pixels_type(
* configurations by passing the endpoints explicitly to
* drm_of_lvds_get_dual_link_pixel_order().
*/
- if (!current_pt || pixels_type != current_pt) {
- of_node_put(endpoint);
+ if (previous_pt != current_pt) {
+ of_node_put(port);
return -EINVAL;
}
+
+ previous_pt = current_pt;
}
- return pixels_type;
+ of_node_put(port);
+ return previous_pt < 0 ? previous_pt : 0;
}
/**
* drm_of_lvds_get_dual_link_pixel_order - Get LVDS dual-link pixel order
- * @port1: First DT port node of the Dual-link LVDS source
- * @port2: Second D
[PATCH v6 1/7] of: Make of_graph_get_port_by_id take a const device_node
of_graph_get_port_by_id doesn't modify the device_node pointer it takes
as argument, so we can make it const.
Signed-off-by: Maxime Ripard
---
drivers/of/property.c| 2 +-
include/linux/of_graph.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 8e90071de6ed..8ad0ce5c87f3 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -603,7 +603,7 @@ EXPORT_SYMBOL(of_graph_parse_endpoint);
* Return: A 'port' node pointer with refcount incremented. The caller
* has to use of_node_put() on it when done.
*/
-struct device_node *of_graph_get_port_by_id(struct device_node *parent, u32 id)
+struct device_node *of_graph_get_port_by_id(const struct device_node *parent,
u32 id)
{
struct device_node *node, *port;
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index 4d7756087b6b..87f3f4d0d0df 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -42,7 +42,7 @@ bool of_graph_is_present(const struct device_node *node);
int of_graph_parse_endpoint(const struct device_node *node,
struct of_endpoint *endpoint);
int of_graph_get_endpoint_count(const struct device_node *np);
-struct device_node *of_graph_get_port_by_id(struct device_node *node, u32 id);
+struct device_node *of_graph_get_port_by_id(const struct device_node *node,
u32 id);
struct device_node *of_graph_get_next_endpoint(const struct device_node
*parent,
struct device_node *previous);
struct device_node *of_graph_get_endpoint_by_regs(
@@ -74,7 +74,7 @@ static inline int of_graph_get_endpoint_count(const struct
device_node *np)
}
static inline struct device_node *of_graph_get_port_by_id(
- struct device_node *node, u32 id)
+ const struct device_node *node, u32 id)
{
return NULL;
}
--
2.33.1
[PATCH v6 0/7] drm/sun4i: Add support for dual-link LVDS on the A20
Hi, This is another attempt at supporting the LVDS dual-link output on the Allwinner A20. Let me know what you think, Maxime Changes from v5: - Rebased on current next - Enhanced the property binding description Changes from v4: - Rebased on 5.15 Changes from v3: - Reintroduce the endpoint sanity check (and make of_graph_get_port_by_id const in the process) - Make a few doc fixes - Fix device_node leakage - Changed allwinner,lvds-companion to more generic link-companion - Rebased on 5.11 Changes from v2: - Added the DT binding description - Split the patch to enable the A20 - Reworked a bit the error messages Changes from v1: - Reworked the DT bindings - Refactored a bit the panel registration in the tcon code. Maxime Ripard (7): of: Make of_graph_get_port_by_id take a const device_node drm/of: Change the prototype of drm_of_lvds_get_dual_link_pixel_order dt-bindings: display: sun4i: Add LVDS link companion property drm/sun4i: tcon: Refactor the LVDS and panel probing drm/sun4i: tcon: Support the LVDS Dual-Link drm/sun4i: tcon: Enable the A20 dual-link output [DO NOT MERGE] ARM: dts: sun7i: Enable LVDS Dual-Link on the Cubieboard .../display/allwinner,sun4i-a10-tcon.yaml | 6 + arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 69 drivers/gpu/drm/bridge/ti-sn65dsi83.c | 9 +- drivers/gpu/drm/drm_of.c | 138 +++ drivers/gpu/drm/rcar-du/rcar_lvds.c | 8 +- drivers/gpu/drm/sun4i/sun4i_tcon.c| 164 ++ drivers/gpu/drm/sun4i/sun4i_tcon.h| 4 + drivers/of/property.c | 2 +- include/drm/drm_of.h | 16 +- include/linux/of_graph.h | 4 +- 10 files changed, 300 insertions(+), 120 deletions(-) -- 2.33.1
Re: [PATCH v2 36/37] drm/tilcdc: Add support for the nomodeset kernel parameter
On 2021-12-17 2:37, Javier Martinez Canillas wrote:
According to disable Documentation/admin-guide/kernel-parameters.txt,
this
parameter can be used to disable kernel modesetting.
DRM drivers will not perform display-mode changes or accelerated
rendering
and only the system framebuffer will be available if it was set-up.
But only a few DRM drivers currently check for nomodeset, make this
driver
to also support the command line parameter.
Signed-off-by: Javier Martinez Canillas
Acked-by: Jyri Sarha
---
(no changes since v1)
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index cc567c87057d..eee3c447fbac 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -604,6 +604,9 @@ static struct platform_driver
tilcdc_platform_driver = {
static int __init tilcdc_drm_init(void)
{
+ if (drm_firmware_drivers_only())
+ return -ENODEV;
+
DBG("init");
tilcdc_panel_init();
return platform_driver_register(&tilcdc_platform_driver);
[PATCH v2 2/2] dt-bindings: panel: Introduce a panel-lvds binding
Following the previous patch, let's introduce a generic panel-lvds binding that documents the panels that don't have any particular constraint documented. Reviewed-by: Rob Herring Signed-off-by: Maxime Ripard --- Changes from v1: - Added missing compatible - Fixed lint --- .../bindings/display/panel/panel-lvds.yaml| 57 +++ 1 file changed, 57 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/panel-lvds.yaml diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml new file mode 100644 index ..fcc50db6a812 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/panel-lvds.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic LVDS Display Panel Device Tree Bindings + +maintainers: + - Lad Prabhakar + - Thierry Reding + +allOf: + - $ref: panel-common.yaml# + - $ref: /schemas/display/lvds.yaml/# + +select: + properties: +compatible: + contains: +const: panel-lvds + + not: +properties: + compatible: +contains: + enum: +- advantech,idk-1110wr +- advantech,idk-2121wr +- innolux,ee101ia-01d +- mitsubishi,aa104xd12 +- mitsubishi,aa121td01 +- sgd,gktw70sdae4se + + required: +- compatible + +properties: + compatible: +items: + - enum: + - auo,b101ew05 + - tbs,a711-panel + + - const: panel-lvds + +unevaluatedProperties: false + +required: + - compatible + - data-mapping + - width-mm + - height-mm + - panel-timing + - port + +... -- 2.33.1
[PATCH v2 1/2] dt-bindings: display: Turn lvds.yaml into a generic schema
The lvds.yaml file so far was both defining the generic LVDS properties
(such as data-mapping) that could be used for any LVDS sink, but also
the panel-lvds binding.
That last binding was to describe LVDS panels simple enough, and had a
number of other bindings using it as a base to specialise it further.
However, this situation makes it fairly hard to extend and reuse both
the generic parts, and the panel-lvds itself.
Let's remove the panel-lvds parts and leave only the generic LVDS
properties.
Reviewed-by: Rob Herring
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Moved the schema out of panel
---
.../bindings/display/{panel => }/lvds.yaml| 31 ++-
.../display/panel/advantech,idk-1110wr.yaml | 19 ++--
.../display/panel/innolux,ee101ia-01d.yaml| 23 --
.../display/panel/mitsubishi,aa104xd12.yaml | 19 ++--
.../display/panel/mitsubishi,aa121td01.yaml | 19 ++--
.../display/panel/sgd,gktw70sdae4se.yaml | 19 ++--
6 files changed, 91 insertions(+), 39 deletions(-)
rename Documentation/devicetree/bindings/display/{panel => }/lvds.yaml (86%)
diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml
b/Documentation/devicetree/bindings/display/lvds.yaml
similarity index 86%
rename from Documentation/devicetree/bindings/display/panel/lvds.yaml
rename to Documentation/devicetree/bindings/display/lvds.yaml
index 49460c9dceea..55751402fb13 100644
--- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
+++ b/Documentation/devicetree/bindings/display/lvds.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
-$id: http://devicetree.org/schemas/display/panel/lvds.yaml#
+$id: http://devicetree.org/schemas/display/lvds.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: LVDS Display Panel
+title: LVDS Display Common Properties
maintainers:
- Laurent Pinchart
@@ -26,18 +26,7 @@ description: |+
Device compatible with those specifications have been marketed under the
FPD-Link and FlatLink brands.
-allOf:
- - $ref: panel-common.yaml#
-
properties:
- compatible:
-contains:
- const: panel-lvds
-description:
- Shall contain "panel-lvds" in addition to a mandatory panel-specific
- compatible string defined in individual panel bindings. The "panel-lvds"
- value shall never be used on its own.
-
data-mapping:
enum:
- jeida-18
@@ -96,22 +85,6 @@ properties:
If set, reverse the bit order described in the data mappings below on all
data lanes, transmitting bits for slots 6 to 0 instead of 0 to 6.
- port: true
- ports: true
-
-required:
- - compatible
- - data-mapping
- - width-mm
- - height-mm
- - panel-timing
-
-oneOf:
- - required:
- - port
- - required:
- - ports
-
additionalProperties: true
...
diff --git
a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
index 93878c2cd370..3a8c2c11f9bd 100644
--- a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
+++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
@@ -11,13 +11,23 @@ maintainers:
- Thierry Reding
allOf:
- - $ref: lvds.yaml#
+ - $ref: panel-common.yaml#
+ - $ref: /schemas/display/lvds.yaml/#
+
+select:
+ properties:
+compatible:
+ contains:
+const: advantech,idk-1110wr
+
+ required:
+- compatible
properties:
compatible:
items:
- const: advantech,idk-1110wr
- - {} # panel-lvds, but not listed here to avoid false select
+ - const: panel-lvds
data-mapping:
const: jeida-24
@@ -35,6 +45,11 @@ additionalProperties: false
required:
- compatible
+ - data-mapping
+ - width-mm
+ - height-mm
+ - panel-timing
+ - port
examples:
- |+
diff --git
a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
index a69681e724cb..566e11f6bfc0 100644
--- a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
+++ b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
@@ -11,15 +11,26 @@ maintainers:
- Thierry Reding
allOf:
- - $ref: lvds.yaml#
+ - $ref: panel-common.yaml#
+ - $ref: /schemas/display/lvds.yaml/#
+
+select:
+ properties:
+compatible:
+ contains:
+const: innolux,ee101ia-01d
+
+ required:
+- compatible
properties:
compatible:
items:
- const: innolux,ee101ia-01d
- - {} # panel-lvds, but not listed here to avoid false select
+ - const: panel-lvds
backlight: true
+ data-mapping: true
enable-gpios: true
power-supply: true
width-mm: true
@@ -27,5 +38,13 @@ properties:
panel-timing: true
port: true
+required:
+ - compatible
+ - data-mapping
+ - width-mm
+ - height-mm
+ - panel-timin
Re: [Intel-gfx] [PATCH v3 12/17] drm/i915: Add locking to i915_gem_evict_vm()
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> i915_gem_evict_vm will need to be able to evict objects that are
> locked by the current ctx. By testing if the current context already
> locked the object, we can do this correctly. This allows us to
> evict the entire vm even if we already hold some objects' locks.
>
> Previously, this was spread over several commits, but it makes
> more sense to commit the changes to i915_gem_evict_vm separately
> from the changes to i915_gem_evict_something() and
> i915_gem_evict_for_node().
>
> Signed-off-by: Maarten Lankhorst
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 3 +-
> drivers/gpu/drm/i915/i915_gem_evict.c | 30 +--
> drivers/gpu/drm/i915/i915_vma.c | 7 -
> .../gpu/drm/i915/selftests/i915_gem_evict.c | 10 +--
> 6 files changed, 46 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 2213f7b613da..eb3649e844ff 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -766,7 +766,7 @@ static int eb_reserve(struct i915_execbuffer *eb)
> case 1:
> /* Too fragmented, unbind everything and retry */
> mutex_lock(&eb->context->vm->mutex);
> - err = i915_gem_evict_vm(eb->context->vm);
> + err = i915_gem_evict_vm(eb->context->vm, &eb->ww);
> mutex_unlock(&eb->context->vm->mutex);
> if (err)
> return err;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index 00cd9642669a..2856098cb449 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -366,7 +366,7 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
> if (vma == ERR_PTR(-ENOSPC)) {
> ret = mutex_lock_interruptible(&ggtt->vm.mutex);
> if (!ret) {
> - ret = i915_gem_evict_vm(&ggtt->vm);
> + ret = i915_gem_evict_vm(&ggtt->vm, &ww);
> mutex_unlock(&ggtt->vm.mutex);
> }
> if (ret)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d51628d10f9d..c180019c607f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1725,7 +1725,8 @@ int __must_check i915_gem_evict_something(struct
> i915_address_space *vm,
> int __must_check i915_gem_evict_for_node(struct i915_address_space *vm,
> struct drm_mm_node *node,
> unsigned int flags);
> -int i915_gem_evict_vm(struct i915_address_space *vm);
> +int i915_gem_evict_vm(struct i915_address_space *vm,
> + struct i915_gem_ww_ctx *ww);
>
> /* i915_gem_internal.c */
> struct drm_i915_gem_object *
> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
> b/drivers/gpu/drm/i915/i915_gem_evict.c
> index 2b73ddb11c66..bfd66f539fc1 100644
> --- a/drivers/gpu/drm/i915/i915_gem_evict.c
> +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> @@ -367,7 +367,7 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
> * To clarify: This is for freeing up virtual address space, not for freeing
> * memory in e.g. the shrinker.
> */
> -int i915_gem_evict_vm(struct i915_address_space *vm)
> +int i915_gem_evict_vm(struct i915_address_space *vm, struct i915_gem_ww_ctx
> *ww)
> {
> int ret = 0;
>
> @@ -388,24 +388,50 @@ int i915_gem_evict_vm(struct i915_address_space *vm)
> do {
> struct i915_vma *vma, *vn;
> LIST_HEAD(eviction_list);
> + LIST_HEAD(locked_eviction_list);
>
> list_for_each_entry(vma, &vm->bound_list, vm_link) {
> if (i915_vma_is_pinned(vma))
> continue;
>
> + /*
> +* If we already own the lock, trylock fails. In case
> the resv
> +* is shared among multiple objects, we still need
> the object ref.
What is "object ref" here? I assume it's just leftovers...
Otherwise,
Reviewed-by: Matthew Auld
> +*/
> + if (ww && (dma_resv_locking_ctx(vma->obj->base.resv)
> == &ww->ctx)) {
> + __i915_vma_pin(vma);
> + list_add(&vma->evict_link,
> &locked_eviction_list);
> + continue;
> + }
> +
> + i
Re: [Intel-gfx] [PATCH v3 11/17] drm/i915: Add ww ctx to i915_gem_object_trylock
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst wrote: > > This is required for i915_gem_evict_vm, to be able to evict the entire VM, > including objects that are already locked to the current ww ctx. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld
Re: [PATCH v3 09/17] drm/i915: Trylock the object when shrinking
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst wrote: > > We're working on requiring the obj->resv lock during unbind, fix > the shrinker to take the objectl ock. lock > > Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld
Re: [Intel-gfx] [PATCH] drm/i915/guc: Log engine resets
On 14/12/2021 15:07, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Log engine resets done by the GuC firmware in the similar way it is done
by the execlists backend.
This way we have notion of where the hangs are before the GuC gains
support for proper error capture.
Ping - any interest to log this info?
All there currently is a non-descriptive "[drm] GPU HANG: ecode
12:0:".
Also, will GuC be reporting the reason for the engine reset at any point?
Regards,
Tvrtko
Signed-off-by: Tvrtko Ursulin
Cc: Matthew Brost
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 9739da6f..51512123dc1a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -11,6 +11,7 @@
#include "gt/intel_context.h"
#include "gt/intel_engine_pm.h"
#include "gt/intel_engine_heartbeat.h"
+#include "gt/intel_engine_user.h"
#include "gt/intel_gpu_commands.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_clock_utils.h"
@@ -3934,9 +3935,18 @@ static void capture_error_state(struct intel_guc *guc,
{
struct intel_gt *gt = guc_to_gt(guc);
struct drm_i915_private *i915 = gt->i915;
- struct intel_engine_cs *engine = __context_to_physical_engine(ce);
+ struct intel_engine_cs *engine = ce->engine;
intel_wakeref_t wakeref;
+ if (intel_engine_is_virtual(engine)) {
+ drm_notice(&i915->drm, "%s class, engines 0x%x; GuC engine
reset\n",
+ intel_engine_class_repr(engine->class),
+ engine->mask);
+ engine = guc_virtual_get_sibling(engine, 0);
+ } else {
+ drm_notice(&i915->drm, "%s GuC engine reset\n", engine->name);
+ }
+
intel_engine_set_hung_context(engine, ce);
with_intel_runtime_pm(&i915->runtime_pm, wakeref)
i915_capture_error_state(gt, engine->mask);
Re: [Intel-gfx] [PATCH v2 6/7] drm/i915: Use vma resources for async unbinding
Hi "Thomas,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on next-20211216]
[cannot apply to drm-exynos/exynos-drm-next drm/drm-next
drm-intel/for-linux-next tegra-drm/drm/tegra/for-next airlied/drm-next
v5.16-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Thomas-Hellstr-m/drm-i915-Asynchronous-vma-unbinding/20211217-172108
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-r021-20211216
(https://download.01.org/0day-ci/archive/20211217/202112172015.hcepn2cg-...@intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project
9043c3d65b11b442226015acfbf8167684586cfa)
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/0day-ci/linux/commit/45f1249183a30dea38defee195b33c7f6753d9f9
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Thomas-Hellstr-m/drm-i915-Asynchronous-vma-unbinding/20211217-172108
git checkout 45f1249183a30dea38defee195b33c7f6753d9f9
# save the config file to linux build tree
mkdir build_dir
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 as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/i915_vma_resource.c:379:39: warning: format specifies
>> type 'unsigned long' but the argument has type 'unsigned int' [-Wformat]
pr_err("vma resource size is %lu\n", sizeof(struct
i915_vma_resource));
~~~ ^~~~
%u
include/linux/printk.h:493:33: note: expanded from macro 'pr_err'
printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
~~~ ^~~
include/linux/printk.h:450:60: note: expanded from macro 'printk'
#define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
~~~^~~
include/linux/printk.h:422:19: note: expanded from macro 'printk_index_wrap'
_p_func(_fmt, ##__VA_ARGS__); \
^~~
1 warning generated.
vim +379 drivers/gpu/drm/i915/i915_vma_resource.c
376
377 int __init i915_vma_resource_module_init(void)
378 {
> 379 pr_err("vma resource size is %lu\n", sizeof(struct
> i915_vma_resource));
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH v4 00/22] Support HDMI audio on NVIDIA Tegra20
17.12.2021 09:04, Vinod Koul пишет: > On 16-12-21, 17:29, Dmitry Osipenko wrote: >> 15.12.2021 22:19, Dmitry Osipenko пишет: >>> 15.12.2021 21:57, Mark Brown пишет: On Sat, Dec 04, 2021 at 05:37:03PM +0300, Dmitry Osipenko wrote: > I based S/PDIF patches on Arnd's Bergmann patch from a separate series [1] > that removes obsolete slave_id. This eases merging of the patches by > removing the merge conflict. This is a note for Mark Brown. That's not in my tree so I'll need either a pull request with the series or a resend after the merge window. >>> This patch is included as a part of this series, please see the patch #6. >>> >>> I saw that Vinod Koul already merged it into his DMA tree [1] a day ago, >>> but there is no stable branch there. >>> >>> [1] >>> https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git/log/?h=next >>> >> >> Vinod, will you be a able to create immutable branch for us with the >> "dmaengine: kill off dma_slave_config->slave_id" patches [1]? >> >> [1] https://lore.kernel.org/all/2021112203.4103644-1-a...@kernel.org/ > > Here you go: > > The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf: > > Linux 5.16-rc1 (2021-11-14 13:56:52 -0800) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git > tags/dmaengine_topic_slave_id_removal_5.17 > > for you to fetch changes up to 3c219644075795a99271d345efdfa8b256e55161: > > dmaengine: remove slave_id config field (2021-12-17 11:23:56 +0530) > > > dmaengine_topic_slave_id_removal_5.17 > > Tag for dmaengine slave_id removal topic branch which should be merged > into v5.17 > > > Arnd Bergmann (11): > ASoC: tegra20-spdif: stop setting slave_id > dmaengine: tegra20-apb: stop checking config->slave_id > ASoC: dai_dma: remove slave_id field > spi: pic32: stop setting dma_config->slave_id > mmc: bcm2835: stop setting chan_config->slave_id > dmaengine: shdma: remove legacy slave_id parsing > dmaengine: pxa/mmp: stop referencing config->slave_id > dmaengine: sprd: stop referencing config->slave_id > dmaengine: qcom-adm: stop abusing slave_id config > dmaengine: xilinx_dpdma: stop using slave_id field > dmaengine: remove slave_id config field > > drivers/dma/mmp_pdma.c | 6 -- > drivers/dma/pxa_dma.c | 7 --- > drivers/dma/qcom/qcom_adm.c| 56 > +--- > drivers/dma/sh/shdma-base.c| 8 > drivers/dma/sprd-dma.c | 3 --- > drivers/dma/tegra20-apb-dma.c | 6 -- > drivers/dma/xilinx/xilinx_dpdma.c | 17 +++-- > drivers/gpu/drm/xlnx/zynqmp_disp.c | 9 +++-- > drivers/mmc/host/bcm2835.c | 2 -- > drivers/mtd/nand/raw/qcom_nandc.c | 14 -- > drivers/spi/spi-pic32.c| 2 -- > drivers/tty/serial/msm_serial.c| 15 +-- > include/linux/dma/qcom_adm.h | 12 > include/linux/dma/xilinx_dpdma.h | 11 +++ > include/linux/dmaengine.h | 4 > include/sound/dmaengine_pcm.h | 2 -- > sound/core/pcm_dmaengine.c | 5 ++--- > sound/soc/tegra/tegra20_spdif.c| 1 - > 18 files changed, 117 insertions(+), 63 deletions(-) > create mode 100644 include/linux/dma/qcom_adm.h > create mode 100644 include/linux/dma/xilinx_dpdma.h Thank you!
Re: [PATCH v4 04/22] dt-bindings: host1x: Document optional HDMI sound-dai-cells
17.12.2021 15:02, Thierry Reding пишет: > On Fri, Dec 17, 2021 at 02:55:48PM +0300, Dmitry Osipenko wrote: >> 17.12.2021 14:12, Mark Brown пишет: >>> On Thu, Dec 16, 2021 at 03:20:21PM +0100, Thierry Reding wrote: On Sat, Dec 04, 2021 at 05:37:07PM +0300, Dmitry Osipenko wrote: > Document new optional sound-dai-cells property of HDMI node. This node > will > be used as endpoint of HDMI sound DAI graph. >>> It's probably best for this to go through ASoC along with the other audio-related bindings. >>> Alternatively, I've just sent out a patch that converts the host1x bindings to json-schema, so I could work this into that as well. >>> >>> It doesn't apply to the ASoC tree for whatever reason so probably best >>> to roll it in with those JSON updates. >>> >> >> This hos1tx binding patch indeed will conflict with the Thierry's patch. >> >> Thierry, will you be able to take the binding patches into the Tegra >> tree and resolve all those hos1tx binding conflicts there? > > Yes, I'll resolve all of those conflicts in the Tegra tree. Thank you! Mark, then you may apply patches 5-13 to ASoC on top of the Vinod's branch, skipping patch #6. Thanks in advance!
Re: [PATCH v4 04/22] dt-bindings: host1x: Document optional HDMI sound-dai-cells
On Fri, Dec 17, 2021 at 02:55:48PM +0300, Dmitry Osipenko wrote: > 17.12.2021 14:12, Mark Brown пишет: > > On Thu, Dec 16, 2021 at 03:20:21PM +0100, Thierry Reding wrote: > >> On Sat, Dec 04, 2021 at 05:37:07PM +0300, Dmitry Osipenko wrote: > >>> Document new optional sound-dai-cells property of HDMI node. This node > >>> will > >>> be used as endpoint of HDMI sound DAI graph. > > > >> It's probably best for this to go through ASoC along with the other > >> audio-related bindings. > > > >> Alternatively, I've just sent out a patch that converts the host1x > >> bindings to json-schema, so I could work this into that as well. > > > > It doesn't apply to the ASoC tree for whatever reason so probably best > > to roll it in with those JSON updates. > > > > This hos1tx binding patch indeed will conflict with the Thierry's patch. > > Thierry, will you be able to take the binding patches into the Tegra > tree and resolve all those hos1tx binding conflicts there? Yes, I'll resolve all of those conflicts in the Tegra tree. Thierry signature.asc Description: PGP signature
Re: [PATCH v3 08/17] drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent new ENOSPC errors
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> Now that we cannot unbind kill the currently locked object directly
"unbind kill"
> because we're removing short term pinning, we may have to unbind the
> object from gtt manually, using a i915_gem_evict_vm() call.
>
> Signed-off-by: Maarten Lankhorst
Maybe mention that this only in preparation for some future patches,
once the actual eviction is trylock and evict_for_vm can also handle
shared dma-resv? At this point in the series we shouldn't expect to
hit -ENOSPC, right?
> ---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index af81d6c3332a..00cd9642669a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -358,8 +358,22 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
> vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view, 0,
> 0, flags);
> }
>
> - /* The entire mappable GGTT is pinned? Unexpected! */
> - GEM_BUG_ON(vma == ERR_PTR(-ENOSPC));
> + /*
> +* The entire mappable GGTT is pinned? Unexpected!
> +* Try to evict the object we locked too, as normally we skip
> it
> +* due to lack of short term pinning inside execbuf.
> +*/
> + if (vma == ERR_PTR(-ENOSPC)) {
> + ret = mutex_lock_interruptible(&ggtt->vm.mutex);
> + if (!ret) {
> + ret = i915_gem_evict_vm(&ggtt->vm);
> + mutex_unlock(&ggtt->vm.mutex);
> + }
> + if (ret)
> + goto err_reset;
> + vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view, 0,
> 0, flags);
> + }
> + GEM_WARN_ON(vma == ERR_PTR(-ENOSPC));
Looks like this is being triggered in CI, I assume because the trylock
could easily fail, due to contention? Is this expected for now? Do we
keep the WARN and track it as a known issue?
> }
> if (IS_ERR(vma)) {
> ret = PTR_ERR(vma);
> --
> 2.34.1
>
Re: [PATCH v4 04/22] dt-bindings: host1x: Document optional HDMI sound-dai-cells
17.12.2021 14:12, Mark Brown пишет: > On Thu, Dec 16, 2021 at 03:20:21PM +0100, Thierry Reding wrote: >> On Sat, Dec 04, 2021 at 05:37:07PM +0300, Dmitry Osipenko wrote: >>> Document new optional sound-dai-cells property of HDMI node. This node will >>> be used as endpoint of HDMI sound DAI graph. > >> It's probably best for this to go through ASoC along with the other >> audio-related bindings. > >> Alternatively, I've just sent out a patch that converts the host1x >> bindings to json-schema, so I could work this into that as well. > > It doesn't apply to the ASoC tree for whatever reason so probably best > to roll it in with those JSON updates. > This hos1tx binding patch indeed will conflict with the Thierry's patch. Thierry, will you be able to take the binding patches into the Tegra tree and resolve all those hos1tx binding conflicts there?
Re: [PATCH v3 07/17] drm/i915: Ensure i915_vma tests do not get -ENOSPC with the locking changes.
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst wrote: > > Now that we require locking to evict, multiple vmas from the same object > might not be evicted. This is expected and required, because execbuf will > move to short-term pinning by using the lock only. This will cause these > tests to fail, because they create a ton of vma's for the same object. > > Unbind manually to prevent spurious -ENOSPC in those mock tests. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld
PSA: drm-misc-next-fixes is open
Hi, I'm just letting you know that drm-misc-next-fixes is now open for bug fixes. -rc6 will presumably be tagged this weekend, which means that drm-next is in feature freeze until the next -rc1 comes out. The transition from/to drm-misc-fixes-next often results in patches that are applied to the wrong tree and get stuck there for a long time. Some rules of thumb: * if your patch fixes a bug in drm-next, please put it into drm-misc-next-fixes, * if your patch fixes a bug in upstream, please put it into drm-misc-fixes, * anything else should go into drm-misc-next. The flow chart is at [1]. Best regards Thomas [1] https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#where-do-i-apply-my-patch -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v2 0/8] Host1x context isolation support
On 14/12/2021 15:38, Robin Murphy wrote: ... IOMMU/DT folks, any thoughts about this approach? The patches that are of interest outside of Host1x/TegraDRM specifics are patches 1, 2, 4, and 5. FWIW it looks fairly innocuous to me. I don't understand host1x - neither hardware nor driver abstractions - well enough to meaningfully review it all (e.g. maybe it's deliberate that the bus .dma_configure method isn't used?), but the SMMU patch seems fine given the Kconfig solution to avoid module linkage problems. Thanks Robin! Will, Joerg, is OK with you? Mikko, I believe we are missing a dt-binding change to document the 'memory-contexts' node which I assume you will add if everyone is OK with this? Cheers Jon -- nvpublic
Re: [Intel-gfx] [PATCH 4/7] drm/i915/guc: Don't hog IRQs when destroying contexts
On 17/12/2021 11:06, Tvrtko Ursulin wrote:
On 14/12/2021 17:04, Matthew Brost wrote:
From: John Harrison
While attempting to debug a CT deadlock issue in various CI failures
(most easily reproduced with gem_ctx_create/basic-files), I was seeing
CPU deadlock errors being reported. This were because the context
destroy loop was blocking waiting on H2G space from inside an IRQ
spinlock. There no was deadlock as such, it's just that the H2G queue
was full of context destroy commands and GuC was taking a long time to
process them. However, the kernel was seeing the large amount of time
spent inside the IRQ lock as a dead CPU. Various Bad Things(tm) would
then happen (heartbeat failures, CT deadlock errors, outstanding H2G
WARNs, etc.).
Re-working the loop to only acquire the spinlock around the list
management (which is all it is meant to protect) rather than the
entire destroy operation seems to fix all the above issues.
v2:
(John Harrison)
- Fix typo in comment message
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 45 ---
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 36c2965db49b..96fcf869e3ff 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2644,7 +2644,6 @@ static inline void guc_lrc_desc_unpin(struct
intel_context *ce)
unsigned long flags;
bool disabled;
- lockdep_assert_held(&guc->submission_state.lock);
GEM_BUG_ON(!intel_gt_pm_is_awake(gt));
GEM_BUG_ON(!lrc_desc_registered(guc, ce->guc_id.id));
GEM_BUG_ON(ce != __get_context(guc, ce->guc_id.id));
@@ -2660,7 +2659,7 @@ static inline void guc_lrc_desc_unpin(struct
intel_context *ce)
}
spin_unlock_irqrestore(&ce->guc_state.lock, flags);
if (unlikely(disabled)) {
- __release_guc_id(guc, ce);
+ release_guc_id(guc, ce);
__guc_context_destroy(ce);
return;
}
@@ -2694,36 +2693,48 @@ static void __guc_context_destroy(struct
intel_context *ce)
static void guc_flush_destroyed_contexts(struct intel_guc *guc)
{
- struct intel_context *ce, *cn;
+ struct intel_context *ce;
unsigned long flags;
GEM_BUG_ON(!submission_disabled(guc) &&
guc_submission_initialized(guc));
- spin_lock_irqsave(&guc->submission_state.lock, flags);
- list_for_each_entry_safe(ce, cn,
- &guc->submission_state.destroyed_contexts,
- destroyed_link) {
- list_del_init(&ce->destroyed_link);
- __release_guc_id(guc, ce);
+ while (!list_empty(&guc->submission_state.destroyed_contexts)) {
Are lockless false negatives a concern here - I mean this thread not
seeing something just got added to the list?
+ spin_lock_irqsave(&guc->submission_state.lock, flags);
+ ce =
list_first_entry_or_null(&guc->submission_state.destroyed_contexts,
+ struct intel_context,
+ destroyed_link);
+ if (ce)
+ list_del_init(&ce->destroyed_link);
+ spin_unlock_irqrestore(&guc->submission_state.lock, flags);
+
+ if (!ce)
+ break;
+
+ release_guc_id(guc, ce);
This looks suboptimal and in conflict with this part of the commit message:
"""
Re-working the loop to only acquire the spinlock around the list
management (which is all it is meant to protect) rather than the
entire destroy operation seems to fix all the above issues.
"""
Because you end up doing:
... loop ...
spin_lock_irqsave(&guc->submission_state.lock, flags);
list_del_init(&ce->destroyed_link);
spin_unlock_irqrestore(&guc->submission_state.lock, flags);
release_guc_id, which calls:
spin_lock_irqsave(&guc->submission_state.lock, flags);
__release_guc_id(guc, ce);
spin_unlock_irqrestore(&guc->submission_state.lock, flags);
So a) the lock seems to be protecting more than just list management, or
release_guc_if is wrong, and b) the loop ends up with highly
questionable hammering on the lock.
Is there any point to this part of the patch? Or the only business end
of the patch is below:
__guc_context_destroy(ce);
}
- spin_unlock_irqrestore(&guc->submission_state.lock, flags);
}
static void deregister_destroyed_contexts(struct intel_guc *guc)
{
- struct intel_context *ce, *cn;
+ struct intel_context *ce;
unsigned long flags;
- spin_lock_irqsave(&guc->submission_state.lock, flags);
- list_for_each_entry_safe(ce, cn,
- &guc->submission_state.destroyed_contexts,
- destroyed_link) {
- list_del_init(&ce->destroyed_link);
+ while (!list_empty(&guc->submission_state.destroyed_contexts)) {
+ spin_lock_irqsave(&guc->submission_s
Re: [PATCH v4 04/22] dt-bindings: host1x: Document optional HDMI sound-dai-cells
On Thu, Dec 16, 2021 at 03:20:21PM +0100, Thierry Reding wrote: > On Sat, Dec 04, 2021 at 05:37:07PM +0300, Dmitry Osipenko wrote: > > Document new optional sound-dai-cells property of HDMI node. This node will > > be used as endpoint of HDMI sound DAI graph. > It's probably best for this to go through ASoC along with the other > audio-related bindings. > Alternatively, I've just sent out a patch that converts the host1x > bindings to json-schema, so I could work this into that as well. It doesn't apply to the ASoC tree for whatever reason so probably best to roll it in with those JSON updates. signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH 4/7] drm/i915/guc: Don't hog IRQs when destroying contexts
On 14/12/2021 17:04, Matthew Brost wrote:
From: John Harrison
While attempting to debug a CT deadlock issue in various CI failures
(most easily reproduced with gem_ctx_create/basic-files), I was seeing
CPU deadlock errors being reported. This were because the context
destroy loop was blocking waiting on H2G space from inside an IRQ
spinlock. There no was deadlock as such, it's just that the H2G queue
was full of context destroy commands and GuC was taking a long time to
process them. However, the kernel was seeing the large amount of time
spent inside the IRQ lock as a dead CPU. Various Bad Things(tm) would
then happen (heartbeat failures, CT deadlock errors, outstanding H2G
WARNs, etc.).
Re-working the loop to only acquire the spinlock around the list
management (which is all it is meant to protect) rather than the
entire destroy operation seems to fix all the above issues.
v2:
(John Harrison)
- Fix typo in comment message
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 45 ---
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 36c2965db49b..96fcf869e3ff 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2644,7 +2644,6 @@ static inline void guc_lrc_desc_unpin(struct
intel_context *ce)
unsigned long flags;
bool disabled;
- lockdep_assert_held(&guc->submission_state.lock);
GEM_BUG_ON(!intel_gt_pm_is_awake(gt));
GEM_BUG_ON(!lrc_desc_registered(guc, ce->guc_id.id));
GEM_BUG_ON(ce != __get_context(guc, ce->guc_id.id));
@@ -2660,7 +2659,7 @@ static inline void guc_lrc_desc_unpin(struct
intel_context *ce)
}
spin_unlock_irqrestore(&ce->guc_state.lock, flags);
if (unlikely(disabled)) {
- __release_guc_id(guc, ce);
+ release_guc_id(guc, ce);
__guc_context_destroy(ce);
return;
}
@@ -2694,36 +2693,48 @@ static void __guc_context_destroy(struct intel_context
*ce)
static void guc_flush_destroyed_contexts(struct intel_guc *guc)
{
- struct intel_context *ce, *cn;
+ struct intel_context *ce;
unsigned long flags;
GEM_BUG_ON(!submission_disabled(guc) &&
guc_submission_initialized(guc));
- spin_lock_irqsave(&guc->submission_state.lock, flags);
- list_for_each_entry_safe(ce, cn,
-&guc->submission_state.destroyed_contexts,
-destroyed_link) {
- list_del_init(&ce->destroyed_link);
- __release_guc_id(guc, ce);
+ while (!list_empty(&guc->submission_state.destroyed_contexts)) {
Are lockless false negatives a concern here - I mean this thread not seeing
something just got added to the list?
+ spin_lock_irqsave(&guc->submission_state.lock, flags);
+ ce =
list_first_entry_or_null(&guc->submission_state.destroyed_contexts,
+ struct intel_context,
+ destroyed_link);
+ if (ce)
+ list_del_init(&ce->destroyed_link);
+ spin_unlock_irqrestore(&guc->submission_state.lock, flags);
+
+ if (!ce)
+ break;
+
+ release_guc_id(guc, ce);
This looks suboptimal and in conflict with this part of the commit message:
"""
Re-working the loop to only acquire the spinlock around the list
management (which is all it is meant to protect) rather than the
entire destroy operation seems to fix all the above issues.
"""
Because you end up doing:
... loop ...
spin_lock_irqsave(&guc->submission_state.lock, flags);
list_del_init(&ce->destroyed_link);
spin_unlock_irqrestore(&guc->submission_state.lock, flags);
release_guc_id, which calls:
spin_lock_irqsave(&guc->submission_state.lock, flags);
__release_guc_id(guc, ce);
spin_unlock_irqrestore(&guc->submission_state.lock, flags);
So a) the lock seems to be protecting more than just list management, or
release_guc_if is wrong, and b) the loop ends up with highly questionable
hammering on the lock.
Is there any point to this part of the patch? Or the only business end of the
patch is below:
__guc_context_destroy(ce);
}
- spin_unlock_irqrestore(&guc->submission_state.lock, flags);
}
static void deregister_destroyed_contexts(struct intel_guc *guc)
{
- struct intel_context *ce, *cn;
+ struct intel_context *ce;
unsigned long flags;
- spin_lock_irqsave(&guc->submission_state.lock, flags);
- list_for_each_entry_safe(ce, cn,
-&guc->submission_state.destroyed_contexts,
-
[PATCH] drm/etnaviv: limit submit sizes
Currently we allow rediculous ammounts of kernel memory being allocated
via the etnaviv GEM_SUBMIT ioctl, which is a pretty easy DoS vector. Put
some reasonable limits in to fix this.
The commandstream size is limited to 64KB, which was already a soft limit
on older kernels after which the kernel only took submits on a best effort
base, so there is no userspace that tries to submit commandstreams larger
than this. Even if the whole commandstream is a single incrementing address
load, the size limit also limits the number of potential relocs and
referenced buffers to slightly under 64K, so use the same limit for those
arguments. The performance monitoring infrastructure currently supports
less than 50 performance counter signals, so limiting them to 128 on a
single submit seems like a reasonably future-proof number for now. This
number can be bumped if needed without breaking the interface.
Cc: sta...@vger.kernel.org
Reported-by: Dan Carpenter
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 486259e154af..225fa5879ebd 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -469,6 +469,12 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void
*data,
return -EINVAL;
}
+ if (args->stream_size > SZ_64K || args->nr_relocs > SZ_64K ||
+ args->nr_bos > SZ_64K || args->nr_pmrs > 128) {
+ DRM_ERROR("submit arguments out of size limits\n");
+ return -EINVAL;
+ }
+
/*
* Copy the command submission and bo array to kernel space in
* one go, and do this outside of any locks.
--
2.30.2
Re: [Intel-gfx] [PATCH v3 05/17] drm/i915: Force ww lock for i915_gem_object_ggtt_pin_ww, v2.
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst wrote: > > We will need the lock to unbind the vma, and wait for bind to complete. > Remove the special casing for the !ww path, and force ww locking for all. > > Changes since v1: > - Pass err to for_i915_gem_ww handling for -EDEADLK handling. > > Signed-off-by: Maarten Lankhorst Deja-vu, Reviewed-by: Matthew Auld
Re: [PATCH v3 04/17] drm/i915: Take object lock in i915_ggtt_pin if ww is not set
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst wrote: > > i915_vma_wait_for_bind needs the vma lock held, fix the caller. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld
Re: [PATCH] drm/panfrost: Avoid user size passed to kvmalloc()
On 17/12/2021 09:28, Dan Carpenter wrote: > On Fri, Dec 17, 2021 at 09:16:19AM +, Steven Price wrote: >> On 17/12/2021 09:10, Dan Carpenter wrote: >>> On Fri, Dec 17, 2021 at 08:55:50AM +, Steven Price wrote: However this one is harder to fix without setting an arbitrary cap on the number of BOs during a sumbit. I'm not sure how other drivers handle this - the ones I've looked at so far all have the same issue. There's obviously the list that Dan already sent, but e.g. msm has the same bug in msm_gem_submit.c:submit_create() with an amusing bug where the check for (sz > SIZE_MAX) will never hit, although the call is to kzalloc() so large allocations are going to fail anyway. >>> >>> sz is u64 and SIZE_MAX is ULONG_MAX so the (sz > SIZE_MAX) condition >>> does work to prevent an integer overflow on 32bit systems. But it's not >>> beautiful. >> >> sz is the result of struct_size() which returns a size_t, and SIZE_MAX >> in case of an overflow. > > Correct. > >> However the check is *greater than* SIZE_MAX >> which will never occur even on 32 bit systems. > > You've missed a part. We add ((u64)nr_cmds * sizeof(submit->cmd[0])) > to SIZE_MAX. If nr_cmds is zero then, whatever, the kzmalloc() will > fail. No big deal. But if it's non-zero then "sz" is larger than > SIZE_MAX and we allocate a smaller buffer than expected leading to > memory corruption. Ah, my bracket matching is obviously off today - somehow I hadn't noticed that the second line wasn't part of the call to struct_size(). > Btw, it turns out that I had a hand in writing that check so hooray for > me. :) #HoorayForMe Indeed hooray for you! ;) Although it still all seems like a very round-a-bout way of enforcing an arbitrary maximum on the size! Thanks, Steve
[PATCH] dma-buf: dma-heap: Add a size limitation for allocation
From: Guangming Currently, there is no size check for allocation. If the alloc size is larger than DRAM, it will cause OOM issue. Besides, if it runs on a process that won't be killed by OOM flow, it will cause a kernel exception finally, and we couldn't find the correct memory usage by dma-buf dump api such as "dma_buf_debug_show" since the allocation is still on going and the corresponding dmabuf is not exported. However, it sounds not simple enough to adding a count to count how many pages has been allocated before allocating done. So adding a size limitation here to prevent this case. Signed-off-by: Guangming Signed-off-by: jianjiao zeng --- drivers/dma-buf/dma-heap.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c index 56bf5ad01ad5..8b75998a106c 100644 --- a/drivers/dma-buf/dma-heap.c +++ b/drivers/dma-buf/dma-heap.c @@ -107,6 +107,9 @@ static long dma_heap_ioctl_allocate(struct file *file, void *data) if (heap_allocation->heap_flags & ~DMA_HEAP_VALID_HEAP_FLAGS) return -EINVAL; + if (heap_allocation->len / PAGE_SIZE > totalram_pages() / 2) + return -EINVAL; + fd = dma_heap_buffer_alloc(heap, heap_allocation->len, heap_allocation->fd_flags, heap_allocation->heap_flags); -- 2.17.1
