dri-devel October 2021

dri-devel@lists.freedesktop.org

347 participants
825 discussions

[PATCH] drm/i915/selftests: Skip hangcheck selftest on DG1
by Matthew Brost 21 Oct '21

21 Oct '21

The hangcheck selftest blows on DG1 CI and aborts the BAT run. Investigation is underway to root cause the failure but in the meantime disable to this test on DG1 to unblock CI. Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> --- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c index 7e2d99dd012d..e2115afbd073 100644 --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c @@ -2018,6 +2018,14 @@ int intel_hangcheck_live_selftests(struct drm_i915_private *i915) intel_wakeref_t wakeref; int err; + /* + * FIXME: This test is blowing up in CI on DG1 due to engine resets + * sporadically timing out. Investigation to root cause this under way. + * In the meantime skip this test to unblock CI. + */ + if (IS_DG1(i915)) + return 0; + if (!intel_has_gpu_reset(gt)) return 0; -- 2.32.0

2 1

[PATCH] drm/i915/selftests: Increase timeout in requests perf selftest
by Matthew Brost 21 Oct '21

21 Oct '21

perf_parallel_engines is micro benchmark to test i915 request scheduling. The test creates a thread per physical engine and submits NOP requests and waits the requests to complete in a loop. In execlists mode this works perfectly fine as powerful CPU has enough cores to feed each engine and process the CSBs. With GuC submission the uC gets overwhelmed as all threads feed into a single CTB channel and the GuC gets bombarded with CSBs as contexts are immediately switched in and out on the engines due to the zero runtime of the requests. When the GuC is overwhelmed scheduling of contexts is unfair due to the nature of the GuC scheduling algorithm. This behavior is understood and deemed acceptable as this micro benchmark isn't close to real world use case. Increasing the timeout of wait period for requests to complete. This makes the test understand that is ok for contexts to get starved in this scenario. A future patch / cleanup may just delete these micro benchmark tests as they basically mean nothing. We care about real workloads not made up ones. Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> --- drivers/gpu/drm/i915/selftests/i915_request.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c b/drivers/gpu/drm/i915/selftests/i915_request.c index d67710d10615..6496671a113c 100644 --- a/drivers/gpu/drm/i915/selftests/i915_request.c +++ b/drivers/gpu/drm/i915/selftests/i915_request.c @@ -2805,7 +2805,7 @@ static int p_sync0(void *arg) i915_request_add(rq); err = 0; - if (i915_request_wait(rq, 0, HZ / 5) < 0) + if (i915_request_wait(rq, 0, HZ) < 0) err = -ETIME; i915_request_put(rq); if (err) @@ -2876,7 +2876,7 @@ static int p_sync1(void *arg) i915_request_add(rq); err = 0; - if (prev && i915_request_wait(prev, 0, HZ / 5) < 0) + if (prev && i915_request_wait(prev, 0, HZ) < 0) err = -ETIME; i915_request_put(prev); prev = rq; -- 2.32.0

3 2

[PATCH AUTOSEL 5.14 02/26] drm/msm/a6xx: Serialize GMU communication
by Sasha Levin 21 Oct '21

21 Oct '21

From: Rob Clark <robdclark(a)chromium.org> [ Upstream commit f6f59072e821901d96c791864a07d57d8ec8d312 ] I've seen some crashes in our crash reporting that *look* like multiple threads stomping on each other while communicating with GMU. So wrap all those paths in a lock. Signed-off-by: Rob Clark <robdclark(a)chromium.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6 ++++ drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 3 ++ drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 40 +++++++++++++++++++++++---- 3 files changed, 43 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c index b349692219b7..c95985792076 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c @@ -296,6 +296,8 @@ int a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state) u32 val; int request, ack; + WARN_ON_ONCE(!mutex_is_locked(&gmu->lock)); + if (state >= ARRAY_SIZE(a6xx_gmu_oob_bits)) return -EINVAL; @@ -337,6 +339,8 @@ void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state) { int bit; + WARN_ON_ONCE(!mutex_is_locked(&gmu->lock)); + if (state >= ARRAY_SIZE(a6xx_gmu_oob_bits)) return; @@ -1478,6 +1482,8 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node) if (!pdev) return -ENODEV; + mutex_init(&gmu->lock); + gmu->dev = &pdev->dev; of_dma_configure(gmu->dev, node, true); diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h index 71dfa60070cc..19c1a0ddee7a 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h @@ -44,6 +44,9 @@ struct a6xx_gmu_bo { struct a6xx_gmu { struct device *dev; + /* For serializing communication with the GMU: */ + struct mutex lock; + struct msm_gem_address_space *aspace; void * __iomem mmio; diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c index 183b9f9c1b31..64586eb8cda5 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c @@ -859,7 +859,7 @@ static int a6xx_zap_shader_init(struct msm_gpu *gpu) A6XX_RBBM_INT_0_MASK_UCHE_OOB_ACCESS | \ A6XX_RBBM_INT_0_MASK_UCHE_TRAP_INTR) -static int a6xx_hw_init(struct msm_gpu *gpu) +static int hw_init(struct msm_gpu *gpu) { struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu); struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu); @@ -1107,6 +1107,19 @@ static int a6xx_hw_init(struct msm_gpu *gpu) return ret; } +static int a6xx_hw_init(struct msm_gpu *gpu) +{ + struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu); + struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu); + int ret; + + mutex_lock(&a6xx_gpu->gmu.lock); + ret = hw_init(gpu); + mutex_unlock(&a6xx_gpu->gmu.lock); + + return ret; +} + static void a6xx_dump(struct msm_gpu *gpu) { DRM_DEV_INFO(&gpu->pdev->dev, "status: %08x\n", @@ -1481,7 +1494,9 @@ static int a6xx_pm_resume(struct msm_gpu *gpu) trace_msm_gpu_resume(0); + mutex_lock(&a6xx_gpu->gmu.lock); ret = a6xx_gmu_resume(a6xx_gpu); + mutex_unlock(&a6xx_gpu->gmu.lock); if (ret) return ret; @@ -1504,7 +1519,9 @@ static int a6xx_pm_suspend(struct msm_gpu *gpu) devfreq_suspend_device(gpu->devfreq.devfreq); + mutex_lock(&a6xx_gpu->gmu.lock); ret = a6xx_gmu_stop(a6xx_gpu); + mutex_unlock(&a6xx_gpu->gmu.lock); if (ret) return ret; @@ -1519,18 +1536,19 @@ static int a6xx_get_timestamp(struct msm_gpu *gpu, uint64_t *value) { struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu); struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu); - static DEFINE_MUTEX(perfcounter_oob); - mutex_lock(&perfcounter_oob); + mutex_lock(&a6xx_gpu->gmu.lock); /* Force the GPU power on so we can read this register */ a6xx_gmu_set_oob(&a6xx_gpu->gmu, GMU_OOB_PERFCOUNTER_SET); *value = gpu_read64(gpu, REG_A6XX_CP_ALWAYS_ON_COUNTER_LO, - REG_A6XX_CP_ALWAYS_ON_COUNTER_HI); + REG_A6XX_CP_ALWAYS_ON_COUNTER_HI); a6xx_gmu_clear_oob(&a6xx_gpu->gmu, GMU_OOB_PERFCOUNTER_SET); - mutex_unlock(&perfcounter_oob); + + mutex_unlock(&a6xx_gpu->gmu.lock); + return 0; } @@ -1594,6 +1612,16 @@ static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu) return (unsigned long)busy_time; } +void a6xx_gpu_set_freq(struct msm_gpu *gpu, struct dev_pm_opp *opp) +{ + struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu); + struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu); + + mutex_lock(&a6xx_gpu->gmu.lock); + a6xx_gmu_set_freq(gpu, opp); + mutex_unlock(&a6xx_gpu->gmu.lock); +} + static struct msm_gem_address_space * a6xx_create_address_space(struct msm_gpu *gpu, struct platform_device *pdev) { @@ -1740,7 +1768,7 @@ static const struct adreno_gpu_funcs funcs = { #endif .gpu_busy = a6xx_gpu_busy, .gpu_get_freq = a6xx_gmu_get_freq, - .gpu_set_freq = a6xx_gmu_set_freq, + .gpu_set_freq = a6xx_gpu_set_freq, #if defined(CONFIG_DRM_MSM_GPU_STATE) .gpu_state_get = a6xx_gpu_state_get, .gpu_state_put = a6xx_gpu_state_put, -- 2.33.0

1 0

[PATCH v3 0/5] drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers
by Lyude Paul 20 Oct '21

20 Oct '21

When I originally moved all of the VESA backlight code in i915 into DRM helpers, one of the things I didn't have the hardware or time for testing was machines that used a combination of PWM and DPCD in order to control their backlights. This has since then caused some breakages and resulted in us disabling DPCD backlight support on such machines. This works fine, unless you have a machine that actually needs this functionality for backlight controls to work at all. Additionally, we will need to support PWM for when we start adding support for VESA's product (as in the product of multiplication) control mode for better brightness ranges. So - let's finally finish up implementing basic support for these types of backlights to solve these problems in our DP helpers, along with implementing support for this in i915. And since digging into this issue solved the last questions we really had about probing backlights in i915 for the most part, let's update some of the comments around that as well! Changes (v3): * Add likely fix for weird backlight scaling issues on samus-fi-bdw in intel's CI, which pointed out we've been leaving some (currently) unsupported backlight features on by mistake which certainly have the potential to cause problems. Changes (v2): * Fixup docs * Add patch to stop us from breaking nouveau Lyude Paul (5): drm/i915: Add support for panels with VESA backlights with PWM enable/disable drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux enable/brightness drm/dp: Disable unsupported features in DP_EDP_BACKLIGHT_MODE_SET_REGISTER drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs() drivers/gpu/drm/drm_dp_helper.c | 82 +++++++++++++------ .../drm/i915/display/intel_dp_aux_backlight.c | 80 ++++++++++++++---- drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 +- include/drm/drm_dp_helper.h | 7 +- 4 files changed, 128 insertions(+), 46 deletions(-) -- 2.31.1

4 11

[PATCH] drm/i915/guc: Set all engine props values for GuC virtual engines
by Matthew Brost 20 Oct '21

20 Oct '21

Set all engine props values for GuC virtual engines as a request can point to a virtual engine with GuC submission and these props are used all over the driver. This differs from execlists where a request can only point to a virtual engine. Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> --- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 5 +---- 1 file changed, 1 insertion(+), 4 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 38b47e73e35d..1341752dc70e 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -4303,10 +4303,7 @@ guc_create_virtual(struct intel_engine_cs **siblings, unsigned int count, ve->base.flags |= sibling->flags; - ve->base.props.timeslice_duration_ms = - sibling->props.timeslice_duration_ms; - ve->base.props.preempt_timeout_ms = - sibling->props.preempt_timeout_ms; + ve->base.props = sibling->props; } } -- 2.32.0

1 0

[PATCH] io-mapping: remove fallback for writecombine
by Lucas De Marchi 20 Oct '21

20 Oct '21

The fallback was introduced in commit 80c33624e472 ("io-mapping: Fixup for different names of writecombine") to fix the build on microblaze. 5 years later, it seems all archs now provide a pgprot_writecombine(), so just remove the other possible fallbacks. For microblaze, pgprot_writecombine() is available since commit 97ccedd793ac ("microblaze: Provide pgprot_device/writecombine macros for nommu"). This is build-tested on microblaze with the following hack to always build mm/io-mapping.o and without diying on a x86-only macro (_PAGE_CACHE_MASK) Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: linux-mm(a)kvack.org Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Lucas De Marchi <lucas.demarchi(a)intel.com> --- include/linux/io-mapping.h | 6 ------ 1 file changed, 6 deletions(-) diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h index e9743cfd8585..66a774d2710e 100644 --- a/include/linux/io-mapping.h +++ b/include/linux/io-mapping.h @@ -132,13 +132,7 @@ io_mapping_init_wc(struct io_mapping *iomap, iomap->base = base; iomap->size = size; -#if defined(pgprot_noncached_wc) /* archs can't agree on a name ... */ - iomap->prot = pgprot_noncached_wc(PAGE_KERNEL); -#elif defined(pgprot_writecombine) iomap->prot = pgprot_writecombine(PAGE_KERNEL); -#else - iomap->prot = pgprot_noncached(PAGE_KERNEL); -#endif return iomap; } -- 2.33.1

1 0

Re: [Intel-gfx] [PATCH 2/4] mm: add a io_mapping_map_user helper
by Lucas De Marchi 20 Oct '21

20 Oct '21

On Fri, Mar 26, 2021 at 06:55:03AM +0100, Christoph Hellwig wrote: >Add a helper that calls remap_pfn_range for an struct io_mapping, relying >on the pgprot pre-validation done when creating the mapping instead of >doing it at runtime. > >Signed-off-by: Christoph Hellwig <hch(a)lst.de> >--- > include/linux/io-mapping.h | 3 +++ > mm/Kconfig | 3 +++ > mm/Makefile | 1 + > mm/io-mapping.c | 29 +++++++++++++++++++++++++++++ > 4 files changed, 36 insertions(+) > create mode 100644 mm/io-mapping.c > >diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h >index c093e81310a9b3..e9743cfd858527 100644 >--- a/include/linux/io-mapping.h >+++ b/include/linux/io-mapping.h >@@ -220,3 +220,6 @@ io_mapping_free(struct io_mapping *iomap) > } > > #endif /* _LINUX_IO_MAPPING_H */ >+ >+int io_mapping_map_user(struct io_mapping *iomap, struct vm_area_struct *vma, >+ unsigned long addr, unsigned long pfn, unsigned long size); I'm not sure what exactly brought me to check this, but while debugging I noticed this outside the header guard. But then after some more checks I saw nothing actually selects CONFIG_IO_MAPPING because commit using it was reverted in commit 0e4fe0c9f2f9 ("Revert "i915: use io_mapping_map_user"") Is this something we want to re-attempt moving to mm/ ? thanks Lucas De Marchi >diff --git a/mm/Kconfig b/mm/Kconfig >index 24c045b24b9506..6b0f2cfbfac0f3 100644 >--- a/mm/Kconfig >+++ b/mm/Kconfig >@@ -872,4 +872,7 @@ config MAPPING_DIRTY_HELPERS > config KMAP_LOCAL > bool > >+# struct io_mapping based helper. Selected by drivers that need them >+config IO_MAPPING >+ bool > endmenu >diff --git a/mm/Makefile b/mm/Makefile >index 72227b24a61688..c0135e385984bb 100644 >--- a/mm/Makefile >+++ b/mm/Makefile >@@ -120,3 +120,4 @@ obj-$(CONFIG_MEMFD_CREATE) += memfd.o > obj-$(CONFIG_MAPPING_DIRTY_HELPERS) += mapping_dirty_helpers.o > obj-$(CONFIG_PTDUMP_CORE) += ptdump.o > obj-$(CONFIG_PAGE_REPORTING) += page_reporting.o >+obj-$(CONFIG_IO_MAPPING) += io-mapping.o >diff --git a/mm/io-mapping.c b/mm/io-mapping.c >new file mode 100644 >index 00000000000000..01b3627999304e >--- /dev/null >+++ b/mm/io-mapping.c >@@ -0,0 +1,29 @@ >+// SPDX-License-Identifier: GPL-2.0-only >+ >+#include <linux/mm.h> >+#include <linux/io-mapping.h> >+ >+/** >+ * io_mapping_map_user - remap an I/O mapping to userspace >+ * @iomap: the source io_mapping >+ * @vma: user vma to map to >+ * @addr: target user address to start at >+ * @pfn: physical address of kernel memory >+ * @size: size of map area >+ * >+ * Note: this is only safe if the mm semaphore is held when called. >+ */ >+int io_mapping_map_user(struct io_mapping *iomap, struct vm_area_struct *vma, >+ unsigned long addr, unsigned long pfn, unsigned long size) >+{ >+ vm_flags_t expected_flags = VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; >+ >+ if (WARN_ON_ONCE((vma->vm_flags & expected_flags) != expected_flags)) >+ return -EINVAL; >+ >+ /* We rely on prevalidation of the io-mapping to skip track_pfn(). */ >+ return remap_pfn_range_notrack(vma, addr, pfn, size, >+ __pgprot((pgprot_val(iomap->prot) & _PAGE_CACHE_MASK) | >+ (pgprot_val(vma->vm_page_prot) & ~_PAGE_CACHE_MASK))); >+} >+EXPORT_SYMBOL_GPL(io_mapping_map_user); >-- >2.30.1 > >_______________________________________________ >Intel-gfx mailing list >Intel-gfx(a)lists.freedesktop.org >https://lists.freedesktop.org/mailman/listinfo/intel-gfx >

2 1

[PATCH v4 0/7] drm/mediatek: Add mt8195 DisplayPort driver
by Markus Schneider-Pargmann 20 Oct '21

20 Oct '21

Hi everyone, this series is built around the DisplayPort driver. The dpi/dpintf driver and the added helper functions are required for the DisplayPort driver to work. In v4 I split the phy driver and dp driver into two patches as requested. Also I added an entry for phy-mtk-dp in MAINTAINERS and made tiny fixups to the binding files. The series is based on v5.15-rc1 but also applies cleanly on linux-next. Note: This patch series is currently tested on v5.10 and I am still working on testing it on v5.15. Thanks in advance for any feedback and comments. Best, Markus Functional dependencies are: - Add Mediatek Soc DRM (vdosys0) support for mt8195 https://lore.kernel.org/linux-mediatek/20210921155218.10387-1-jason-jh.lin@… - Add MediaTek SoC DRM (vdosys1) support for mt8195 https://lore.kernel.org/linux-mediatek/20211004062140.29803-1-nancy.lin@med… Older revisions: RFC - https://lore.kernel.org/linux-mediatek/20210816192523.1739365-1-msp@baylibr… v1 - https://lore.kernel.org/linux-mediatek/20210906193529.718845-1-msp@baylibre… v2 - https://lore.kernel.org/linux-mediatek/20210920084424.231825-1-msp@baylibre… v3 - https://lore.kernel.org/linux-mediatek/20211001094443.2770169-1-msp@baylibr… Markus Schneider-Pargmann (7): dt-bindings: mediatek,dpintf: Add DP_INTF binding dt-bindings: mediatek,dp: Add Display Port binding drm/edid: Add cea_sad helpers for freq/length video/hdmi: Add audio_infoframe packing for DP drm/mediatek: dpi: Add dpintf support phy: phy-mtk-dp: Add driver for DP phy drm/mediatek: Add mt8195 DisplayPort driver .../display/mediatek/mediatek,dp.yaml | 89 + .../display/mediatek/mediatek,dpintf.yaml | 86 + MAINTAINERS | 1 + drivers/gpu/drm/drm_edid.c | 74 + drivers/gpu/drm/mediatek/Kconfig | 7 + drivers/gpu/drm/mediatek/Makefile | 2 + drivers/gpu/drm/mediatek/mtk_dp.c | 2825 +++++++++++++++++ drivers/gpu/drm/mediatek/mtk_dp_reg.h | 535 ++++ drivers/gpu/drm/mediatek/mtk_dpi.c | 248 +- drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 12 + 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 | 6 +- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 + drivers/phy/mediatek/Kconfig | 8 + drivers/phy/mediatek/Makefile | 1 + drivers/phy/mediatek/phy-mtk-dp.c | 218 ++ drivers/video/hdmi.c | 83 +- include/drm/drm_dp_helper.h | 2 + include/drm/drm_edid.h | 18 +- include/linux/hdmi.h | 7 +- include/linux/soc/mediatek/mtk-mmsys.h | 2 + 22 files changed, 4156 insertions(+), 74 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,dpintf.yaml create mode 100644 drivers/gpu/drm/mediatek/mtk_dp.c create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_reg.h create mode 100644 drivers/phy/mediatek/phy-mtk-dp.c -- 2.33.0

3 15

[PATCH 1/4] drm: Remove slot checks in dp mst topology during commit
by Bhawanpreet Lakha 20 Oct '21

20 Oct '21

This code path is used during commit, and we dont expect things to fail during the commit stage, so remove this. Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha(a)amd.com> --- drivers/gpu/drm/drm_dp_mst_topology.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index ad0795afc21c..5ab3b3a46e89 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -4332,10 +4332,6 @@ static int drm_dp_init_vcpi(struct drm_dp_mst_topology_mgr *mgr, { int ret; - /* max. time slots - one slot for MTP header */ - if (slots > 63) - return -ENOSPC; - vcpi->pbn = pbn; vcpi->aligned_pbn = slots * mgr->pbn_div; vcpi->num_slots = slots; @@ -4538,7 +4534,7 @@ bool drm_dp_mst_allocate_vcpi(struct drm_dp_mst_topology_mgr *mgr, ret = drm_dp_init_vcpi(mgr, &port->vcpi, pbn, slots); if (ret) { - drm_dbg_kms(mgr->dev, "failed to init vcpi slots=%d max=63 ret=%d\n", + drm_dbg_kms(mgr->dev, "failed to init vcpi slots=%d ret=%d\n", DIV_ROUND_UP(pbn, mgr->pbn_div), ret); drm_dp_mst_topology_put_port(port); goto out; -- 2.25.1

2 5

[PATCH v4 1/7] dt-bindings: mediatek,dpintf: Add DP_INTF binding
by Markus Schneider-Pargmann 20 Oct '21

20 Oct '21

DP_INTF is a similar functional block to mediatek,dpi but is different in that it serves the DisplayPort controller on mediatek SoCs and uses different clocks. Therefore this patch creates a new binding file for this functional block. Signed-off-by: Markus Schneider-Pargmann <msp(a)baylibre.com> --- Notes: Changes v3 -> v4: - Fixed clock names in the example as the clock patch series is merged into next now - Add missing ports decleration to the example Changes v1 -> v2: - Move the devicetree binding from mediatek,dpi into its own binding file. .../display/mediatek/mediatek,dpintf.yaml | 86 +++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,dpintf.yaml diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpintf.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpintf.yaml new file mode 100644 index 000000000000..3b5e0c148c97 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpintf.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,dpintf.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek DP_INTF Controller Device Tree Bindings + +maintainers: + - CK Hu <ck.hu(a)mediatek.com> + - Jitao shi <jitao.shi(a)mediatek.com> + +description: | + The Mediatek DP_INTF function block is a sink of the display subsystem + connected to the display port controller. + +properties: + compatible: + enum: + - mediatek,mt8195-dpintf + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: hf_fmm Clock + - description: hf_fdp Clock + - description: Pixel Clock + - description: DP_INTF PLL + + clock-names: + items: + - const: hf_fmm + - const: hf_fdp + - const: pixel + - const: pll + + port: + $ref: /schemas/graph.yaml#/properties/port + description: + Output port node. This port should be connected to the input port of an + attached display port controller. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/mt8195-clk.h> + + dp_intf1: dp_intf1@1c113000 { + compatible = "mediatek,mt8195-dpintf"; + reg = <0 0x1c113000 0 0x1000>; + interrupts = <GIC_SPI 513 IRQ_TYPE_LEVEL_HIGH 0>; + clocks = <&vdosys1 CLK_VDO1_DP_INTF0_MM>, + <&vdosys1 CLK_VDO1_DPINTF>, + <&topckgen CLK_TOP_DP>, + <&topckgen CLK_APMIXED_TVDPLL2>; + clock-names = "hf_fmm", + "hf_fdp", + "pixel", + "pll"; + + ports { + port { + dpintf1_out: endpoint { + remote-endpoint = <&dp_in>; + }; + }; + }; + }; + +... -- 2.33.0

2 5

← Newer
1
...
37
38
39
40
41
42
43
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2021