Re: [Intel-gfx] [CI 2/2] drm/i915/gem: Pull phys pread/pwrite implementations to the backend
On Thu, Nov 05, 2020 at 06:41:25PM +, Chris Wilson wrote:
> Quoting Chris Wilson (2020-11-05 15:49:34)
> > Move the specialised interactions with the physical GEM object from the
> > pread/pwrite ioctl handler into the phys backend.
which depends on the backend...
> >
>
> Fixes: c6790dc22312 ("drm/i915: Wean off drm_pci_alloc/drm_pci_free")
which was a fixes to 4.5 stable, but I could only find it into 5.4+
so...
> Testcase: igt/gem_pwrite/exhaustion
> > Signed-off-by: Chris Wilson
> > Reviewed-by: Matthew Auld
> Cc: sta...@vger.kernel.org
When cherry-picking to drm-intel-fixes, should I add
Cc: sta...@vger.kernel.org # 5.4.y: c6790dc22312: drm/i915: Wean off
drm_pci_alloc/drm_pci_free
Cc: sta...@vger.kernel.org # 5.4.y
> -Chris
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 2/2] drm/i915/gvt: Add GVT resume routine to i915
On 2020.10.27 12:54:06 +0800, Colin Xu wrote: > This patch add gvt resume wrapper into i915_drm_resume(). > GVT relies on i915 so resume gvt at last. > > V2: > - Direct call into gvt suspend/resume wrapper in intel_gvt.h/intel_gvt.c. > The wrapper and implementation will check and call gvt routine. (zhenyu) > > V3: > Refresh. > > V4: > Rebase. > > V5: > Fail intel_gvt_suspend() if fail to save GGTT. > > V6: > Save host entry to per-vGPU gtt.ggtt_mm on each host_entry update so > only need the resume routine. > > V7: > Refresh. > > Signed-off-by: Hang Yuan > Signed-off-by: Colin Xu > --- > drivers/gpu/drm/i915/i915_drv.c | 2 ++ > 1 file changed, 2 insertions(+) Patch title is a bit incorrect as this is to change in drm/i915: ... other than that Reviewed-by: Zhenyu Wang Although this is to change i915 file, I think it's easy enough to be merged through gvt tree, let me know if there's any concern. Thanks > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index d3237b0d821d..2c15c9440f8a 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -1270,6 +1270,8 @@ static int i915_drm_resume(struct drm_device *dev) > > intel_power_domains_enable(dev_priv); > > + intel_gvt_resume(dev_priv); > + > enable_rpm_wakeref_asserts(&dev_priv->runtime_pm); > > return 0; > -- > 2.29.1 > > ___ > intel-gvt-dev mailing list > intel-gvt-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev -- $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 1/2] drm/i915/gvt: Save/restore HW status to support GVT suspend/resume
On 2020.10.27 12:53:08 +0800, Colin Xu wrote:
> This patch save/restore necessary GVT info during i915 suspend/resume so
> that GVT enabled QEMU VM can continue running.
>
> Only GGTT and fence regs are saved/restored now. GVT will save GGTT
> entries on each host_entry update, restore the saved dirty entries
> and re-init fence regs in resume routine.
>
> V2:
> - Change kzalloc/kfree to vzalloc/vfree since the space allocated
> from kmalloc may not enough for all saved GGTT entries.
> - Keep gvt suspend/resume wrapper in intel_gvt.h/intel_gvt.c and
> move the actual implementation to gvt.h/gvt.c. (zhenyu)
> - Check gvt config on and active with intel_gvt_active(). (zhenyu)
>
> V3: (zhenyu)
> - Incorrect copy length. Should be num entries * entry size.
> - Use memcpy_toio()/memcpy_fromio() instead of memcpy for iomem.
> - Add F_PM_SAVE flags to indicate which MMIOs to save/restore for PM.
>
> V4:
> Rebase.
>
> V5:
> Fail intel_gvt_save_ggtt as -ENOMEM if fail to alloc memory to save
> ggtt. Free allocated ggtt_entries on failure.
>
> V6:
> Save host entry to per-vGPU gtt.ggtt_mm on each host_entry update.
>
> V7:
> Restore GGTT entry based on present bit.
> Split fence restore and mmio restore in different functions.
>
> Signed-off-by: Hang Yuan
> Signed-off-by: Colin Xu
> ---
Reviewed-by: Zhenyu Wang
> drivers/gpu/drm/i915/gvt/gtt.c | 64 +
> drivers/gpu/drm/i915/gvt/gtt.h | 4 ++
> drivers/gpu/drm/i915/gvt/gvt.c | 9
> drivers/gpu/drm/i915/gvt/gvt.h | 3 ++
> drivers/gpu/drm/i915/gvt/handlers.c | 44 ++--
> drivers/gpu/drm/i915/gvt/mmio.h | 4 ++
> drivers/gpu/drm/i915/intel_gvt.c| 15 +++
> drivers/gpu/drm/i915/intel_gvt.h| 5 +++
> 8 files changed, 145 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> index a3a4305eda01..897c007ea96a 100644
> --- a/drivers/gpu/drm/i915/gvt/gtt.c
> +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> @@ -636,9 +636,18 @@ static void ggtt_set_host_entry(struct intel_vgpu_mm *mm,
> struct intel_gvt_gtt_entry *entry, unsigned long index)
> {
> struct intel_gvt_gtt_pte_ops *pte_ops = mm->vgpu->gvt->gtt.pte_ops;
> + unsigned long offset = index;
>
> GEM_BUG_ON(mm->type != INTEL_GVT_MM_GGTT);
>
> + if (vgpu_gmadr_is_aperture(mm->vgpu, index << I915_GTT_PAGE_SHIFT)) {
> + offset -= (vgpu_aperture_gmadr_base(mm->vgpu) >> PAGE_SHIFT);
> + mm->ggtt_mm.host_ggtt_aperture[offset] = entry->val64;
> + } else if (vgpu_gmadr_is_hidden(mm->vgpu, index <<
> I915_GTT_PAGE_SHIFT)) {
> + offset -= (vgpu_hidden_gmadr_base(mm->vgpu) >> PAGE_SHIFT);
> + mm->ggtt_mm.host_ggtt_hidden[offset] = entry->val64;
> + }
> +
> pte_ops->set_entry(NULL, entry, index, false, 0, mm->vgpu);
> }
>
> @@ -1944,6 +1953,21 @@ static struct intel_vgpu_mm
> *intel_vgpu_create_ggtt_mm(struct intel_vgpu *vgpu)
> return ERR_PTR(-ENOMEM);
> }
>
> + mm->ggtt_mm.host_ggtt_aperture = vzalloc((vgpu_aperture_sz(vgpu) >>
> PAGE_SHIFT) * sizeof(u64));
> + if (!mm->ggtt_mm.host_ggtt_aperture) {
> + vfree(mm->ggtt_mm.virtual_ggtt);
> + vgpu_free_mm(mm);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + mm->ggtt_mm.host_ggtt_hidden = vzalloc((vgpu_hidden_sz(vgpu) >>
> PAGE_SHIFT) * sizeof(u64));
> + if (!mm->ggtt_mm.host_ggtt_hidden) {
> + vfree(mm->ggtt_mm.host_ggtt_aperture);
> + vfree(mm->ggtt_mm.virtual_ggtt);
> + vgpu_free_mm(mm);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> return mm;
> }
>
> @@ -1971,6 +1995,8 @@ void _intel_vgpu_mm_release(struct kref *mm_ref)
> invalidate_ppgtt_mm(mm);
> } else {
> vfree(mm->ggtt_mm.virtual_ggtt);
> + vfree(mm->ggtt_mm.host_ggtt_aperture);
> + vfree(mm->ggtt_mm.host_ggtt_hidden);
> }
>
> vgpu_free_mm(mm);
> @@ -2852,3 +2878,41 @@ void intel_vgpu_reset_gtt(struct intel_vgpu *vgpu)
> intel_vgpu_destroy_all_ppgtt_mm(vgpu);
> intel_vgpu_reset_ggtt(vgpu, true);
> }
> +
> +/**
> + * intel_gvt_restore_ggtt - restore all vGPU's ggtt entries
> + * @gvt: intel gvt device
> + *
> + * This function is called at driver resume stage to restore
> + * GGTT entries of every vGPU.
> + *
> + */
> +void intel_gvt_restore_ggtt(struct intel_gvt *gvt)
> +{
> + struct intel_vgpu *vgpu;
> + struct intel_vgpu_mm *mm;
> + int id;
> + gen8_pte_t pte;
> + u32 idx, num_low, num_hi, offset;
> +
> + /* Restore dirty host ggtt for all vGPUs */
> + idr_for_each_entry(&(gvt)->vgpu_idr, vgpu, id) {
> + mm = vgpu->gtt.ggtt_mm;
> +
> + num_low = vgpu_aperture_sz(vgpu) >> PAGE_SHIFT;
> + offset = vgpu_aperture_gmadr_base(vgpu) >> PAGE_SHIFT;
> + for (idx = 0; idx < num_low; idx++) {
>
Re: [Intel-gfx] [PATCH RFC PKS/PMEM 05/58] kmap: Introduce k[un]map_thread
On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote: > Ira, > > On Fri, Oct 09 2020 at 12:49, ira weiny wrote: > > From: Ira Weiny > > > > To correctly support the semantics of kmap() with Kernel protection keys > > (PKS), kmap() may be required to set the protections on multiple > > processors (globally). Enabling PKS globally can be very expensive > > depending on the requested operation. Furthermore, enabling a domain > > globally reduces the protection afforded by PKS. > > > > Most kmap() (Aprox 209 of 229) callers use the map within a single thread > > and > > have no need for the protection domain to be enabled globally. However, the > > remaining callers do not follow this pattern and, as best I can tell, expect > > the mapping to be 'global' and available to any thread who may access the > > mapping.[1] > > > > We don't anticipate global mappings to pmem, however in general there is a > > danger in changing the semantics of kmap(). Effectively, this would cause > > an > > unresolved page fault with little to no information about why the failure > > occurred. > > > > To resolve this a number of options were considered. > > > > 1) Attempt to change all the thread local kmap() calls to kmap_atomic()[2] > > 2) Introduce a flags parameter to kmap() to indicate if the mapping should > > be > >global or not > > 3) Change ~20 call sites to 'kmap_global()' to indicate that they require a > >global enablement of the pages. > > 4) Change ~209 call sites to 'kmap_thread()' to indicate that the mapping > > is to > >be used within that thread of execution only > > > > Option 1 is simply not feasible. Option 2 would require all of the call > > sites > > of kmap() to change. Option 3 seems like a good minimal change but there > > is a > > danger that new code may miss the semantic change of kmap() and not get the > > behavior the developer intended. Therefore, #4 was chosen. > > There is Option #5: There is now yes. :-D > > Convert the thread local kmap() invocations to the proposed kmap_local() > interface which is coming along [1]. I've been trying to follow that thread. > > That solves a couple of issues: > > 1) It relieves the current kmap_atomic() usage sites from the implict > pagefault/preempt disable semantics which apply even when > CONFIG_HIGHMEM is disabled. kmap_local() still can be invoked from > atomic context. > > 2) Due to #1 it allows to replace the conditional usage of kmap() and > kmap_atomic() for purely thread local mappings. > > 3) It puts the burden on the HIGHMEM inflicted systems > > 4) It is actually more efficient for most of the pure thread local use > cases on HIGHMEM inflicted systems because it avoids the overhead of > the global lock and the potential kmap slot exhaustion. A potential > preemption will be more expensive, but that's not really the case we > want to optimize for. > > 5) It solves the RT issue vs. kmap_atomic() > > So instead of creating yet another variety of kmap() which is just > scratching the particular PKRS itch, can we please consolidate all of > that on the wider reaching kmap_local() approach? Yes I agree. We absolutely don't want more kmap*() calls and I was hoping to dovetail into your kmap_local() work.[2] I've pivoted away from this work a bit to clean up all the kmap()/memcpy*()/kunmaps() as discussed elsewhere in the thread first.[3] I was hoping your work would land and then I could s/kmap_thread()/kmap_local()/ on all of these patches. Also, we can convert the new memcpy_*_page() calls to kmap_local() as well. [For now my patch just uses kmap_atomic().] I've not looked at all of the patches in your latest version. Have you included converting any of the kmap() call sites? I thought you were more focused on converting the kmap_atomic() to kmap_local()? Ira > > Thanks, > > tglx > > [1] https://lore.kernel.org/lkml/20201103092712.714480...@linutronix.de/ [2] https://lore.kernel.org/lkml/20201012195354.gc2046...@iweiny-desk2.sc.intel.com/ [3] https://lore.kernel.org/lkml/20201009213434.GA839@sol.localdomain/ https://lore.kernel.org/lkml/20201013200149.gi3576...@zeniv.linux.org.uk/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: build warning after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
In file included from include/linux/kernel.h:14,
from include/asm-generic/bug.h:20,
from arch/arm/include/asm/bug.h:60,
from include/linux/bug.h:5,
from include/linux/io.h:11,
from include/linux/dma-buf-map.h:9,
from include/linux/dma-buf.h:16,
from drivers/gpu/drm/drm_fb_helper.c:33:
drivers/gpu/drm/drm_fb_helper.c: In function 'fb_read_screen_base':
include/linux/minmax.h:18:28: warning: comparison of distinct pointer types
lacks a cast
18 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
|^~
include/linux/minmax.h:32:4: note: in expansion of macro '__typecheck'
32 | (__typecheck(x, y) && __no_side_effects(x, y))
|^~~
include/linux/minmax.h:42:24: note: in expansion of macro '__safe_cmp'
42 | __builtin_choose_expr(__safe_cmp(x, y), \
|^~
include/linux/minmax.h:51:19: note: in expansion of macro '__careful_cmp'
51 | #define min(x, y) __careful_cmp(x, y, <)
| ^
drivers/gpu/drm/drm_fb_helper.c:2041:22: note: in expansion of macro 'min'
2041 | size_t alloc_size = min(count, PAGE_SIZE);
| ^~~
drivers/gpu/drm/drm_fb_helper.c: In function 'fb_write_screen_base':
include/linux/minmax.h:18:28: warning: comparison of distinct pointer types
lacks a cast
18 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
|^~
include/linux/minmax.h:32:4: note: in expansion of macro '__typecheck'
32 | (__typecheck(x, y) && __no_side_effects(x, y))
|^~~
include/linux/minmax.h:42:24: note: in expansion of macro '__safe_cmp'
42 | __builtin_choose_expr(__safe_cmp(x, y), \
|^~
include/linux/minmax.h:51:19: note: in expansion of macro '__careful_cmp'
51 | #define min(x, y) __careful_cmp(x, y, <)
| ^
drivers/gpu/drm/drm_fb_helper.c:2115:22: note: in expansion of macro 'min'
2115 | size_t alloc_size = min(count, PAGE_SIZE);
| ^~~
Introduced by commit
222ec45f4c69 ("drm/fb_helper: Support framebuffers in I/O memory")
--
Cheers,
Stephen Rothwell
pgpJKA47i4E4Z.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/msm/msm_gem.c:1014:10: error: initialization of 'int (*)(struct
drm_gem_object *, struct dma_buf_map *)' from incompatible pointer type 'void *
(*)(struct drm_gem_object *)' [-Werror=incompatible-pointer-types]
1014 | .vmap = msm_gem_prime_vmap,
| ^~
drivers/gpu/drm/msm/msm_gem.c:1014:10: note: (near initialization for
'msm_gem_object_funcs.vmap')
drivers/gpu/drm/msm/msm_gem.c:1015:12: error: initialization of 'void
(*)(struct drm_gem_object *, struct dma_buf_map *)' from incompatible pointer
type 'void (*)(struct drm_gem_object *, void *)'
[-Werror=incompatible-pointer-types]
1015 | .vunmap = msm_gem_prime_vunmap,
|^~~~
Caused by commit
49a3f51dfeee ("drm/gem: Use struct dma_buf_map in GEM vmap ops and convert
GEM backends")
interacting with commit
3c9edd9c85f5 ("drm/msm: Introduce GEM object funcs")
from the drm tree.
I tried reverting commit 3c9edd9c85f5 (as 49a3f51dfeee does not revert
cleanly) but that just produced more errors, so I have disabled
CONFIG_DRM_MSM for now.
--
Cheers,
Stephen Rothwell
pgpKF9QObojh9.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RFC PKS/PMEM 05/58] kmap: Introduce k[un]map_thread
Ira, On Fri, Oct 09 2020 at 12:49, ira weiny wrote: > From: Ira Weiny > > To correctly support the semantics of kmap() with Kernel protection keys > (PKS), kmap() may be required to set the protections on multiple > processors (globally). Enabling PKS globally can be very expensive > depending on the requested operation. Furthermore, enabling a domain > globally reduces the protection afforded by PKS. > > Most kmap() (Aprox 209 of 229) callers use the map within a single thread and > have no need for the protection domain to be enabled globally. However, the > remaining callers do not follow this pattern and, as best I can tell, expect > the mapping to be 'global' and available to any thread who may access the > mapping.[1] > > We don't anticipate global mappings to pmem, however in general there is a > danger in changing the semantics of kmap(). Effectively, this would cause an > unresolved page fault with little to no information about why the failure > occurred. > > To resolve this a number of options were considered. > > 1) Attempt to change all the thread local kmap() calls to kmap_atomic()[2] > 2) Introduce a flags parameter to kmap() to indicate if the mapping should be >global or not > 3) Change ~20 call sites to 'kmap_global()' to indicate that they require a >global enablement of the pages. > 4) Change ~209 call sites to 'kmap_thread()' to indicate that the mapping is > to >be used within that thread of execution only > > Option 1 is simply not feasible. Option 2 would require all of the call sites > of kmap() to change. Option 3 seems like a good minimal change but there is a > danger that new code may miss the semantic change of kmap() and not get the > behavior the developer intended. Therefore, #4 was chosen. There is Option #5: Convert the thread local kmap() invocations to the proposed kmap_local() interface which is coming along [1]. That solves a couple of issues: 1) It relieves the current kmap_atomic() usage sites from the implict pagefault/preempt disable semantics which apply even when CONFIG_HIGHMEM is disabled. kmap_local() still can be invoked from atomic context. 2) Due to #1 it allows to replace the conditional usage of kmap() and kmap_atomic() for purely thread local mappings. 3) It puts the burden on the HIGHMEM inflicted systems 4) It is actually more efficient for most of the pure thread local use cases on HIGHMEM inflicted systems because it avoids the overhead of the global lock and the potential kmap slot exhaustion. A potential preemption will be more expensive, but that's not really the case we want to optimize for. 5) It solves the RT issue vs. kmap_atomic() So instead of creating yet another variety of kmap() which is just scratching the particular PKRS itch, can we please consolidate all of that on the wider reaching kmap_local() approach? Thanks, tglx [1] https://lore.kernel.org/lkml/20201103092712.714480...@linutronix.de/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Limit VFE threads based on GT
On Fri, Oct 16, 2020 at 06:54:11PM +0100, Chris Wilson wrote:
> MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the
> range [0, n-1] where n is #EU * (#threads/EU) with the number of threads
> based on plaform and the number of EU based on the number of slices and
> subslices. This is a fixed number per platform/gt, so appropriately
> limit the number of threads we spawn to match the device.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2024
> Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Prathap Kumar Valsan
> Cc: Akeem G Abodunrin
> Cc: Balestrieri Francesco
> Cc: Bloomfield Jon
> Cc: # v5.7+
> ---
> ...
I tested this patch and found that it prevents the GPU hang I had
reported on the HP Pavilion Mini 300-020 in
https://gitlab.freedesktop.org/drm/intel/-/issues/2413.
In more detail: I built linux-next at tag next-20201106 without
the patch, and booted the result on an Ubuntu 20.04 base system. As
expected, I observed the hang that I had previously reported as soon as
Cinnnamon started when I entered graphical.target.
I then applied this patch - that being the only change to my kernel -
and I was able to boot to graphical.target 5 times consecutively without
any GPU hang.
You may add my endorsements:
Tested-by: Randy Wright
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2413
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2106
--
Randy WrightHewlett Packard Enterprise
Phone: (970) 898-0998 Mail: rwri...@hpe.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: Relocate cnl_get_ddi_pll()
From: Ville Syrjälä
Move cnl_get_ddi_pll() into a better spot from between
icl_get_ddi_pll() and dg1_get_ddi_pll(). Also reorder
the calls to the skl and bxt functions because ocd.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 48 ++--
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 8ab622c0186e..322db0f3bbc6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11033,28 +11033,6 @@ static void dg1_get_ddi_pll(struct drm_i915_private
*dev_priv, enum port port,
icl_set_active_port_dpll(pipe_config, port_dpll_id);
}
-static void cnl_get_ddi_pll(struct drm_i915_private *dev_priv, enum port port,
- struct intel_crtc_state *pipe_config)
-{
- struct intel_shared_dpll *pll;
- enum intel_dpll_id id;
- bool pll_active;
- u32 temp;
-
- temp = intel_de_read(dev_priv, DPCLKA_CFGCR0) &
DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
- id = temp >> DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port);
-
- if (drm_WARN_ON(&dev_priv->drm, id < SKL_DPLL0 || id > SKL_DPLL2))
- return;
-
- pll = intel_get_shared_dpll_by_id(dev_priv, id);
-
- pipe_config->shared_dpll = pll;
- pll_active = intel_dpll_get_hw_state(dev_priv, pll,
-&pipe_config->dpll_hw_state);
- drm_WARN_ON(&dev_priv->drm, !pll_active);
-}
-
static void icl_get_ddi_pll(struct drm_i915_private *dev_priv, enum port port,
struct intel_crtc_state *pipe_config)
{
@@ -11109,6 +11087,28 @@ static void icl_get_ddi_pll(struct drm_i915_private
*dev_priv, enum port port,
icl_set_active_port_dpll(pipe_config, port_dpll_id);
}
+static void cnl_get_ddi_pll(struct drm_i915_private *dev_priv, enum port port,
+ struct intel_crtc_state *pipe_config)
+{
+ struct intel_shared_dpll *pll;
+ enum intel_dpll_id id;
+ bool pll_active;
+ u32 temp;
+
+ temp = intel_de_read(dev_priv, DPCLKA_CFGCR0) &
DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
+ id = temp >> DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port);
+
+ if (drm_WARN_ON(&dev_priv->drm, id < SKL_DPLL0 || id > SKL_DPLL2))
+ return;
+
+ pll = intel_get_shared_dpll_by_id(dev_priv, id);
+
+ pipe_config->shared_dpll = pll;
+ pll_active = intel_dpll_get_hw_state(dev_priv, pll,
+&pipe_config->dpll_hw_state);
+ drm_WARN_ON(&dev_priv->drm, !pll_active);
+}
+
static void bxt_get_ddi_pll(struct drm_i915_private *dev_priv,
enum port port,
struct intel_crtc_state *pipe_config)
@@ -11382,10 +11382,10 @@ static void hsw_get_ddi_port_state(struct intel_crtc
*crtc,
icl_get_ddi_pll(dev_priv, port, pipe_config);
else if (IS_CANNONLAKE(dev_priv))
cnl_get_ddi_pll(dev_priv, port, pipe_config);
- else if (IS_GEN9_BC(dev_priv))
- skl_get_ddi_pll(dev_priv, port, pipe_config);
else if (IS_GEN9_LP(dev_priv))
bxt_get_ddi_pll(dev_priv, port, pipe_config);
+ else if (IS_GEN9_BC(dev_priv))
+ skl_get_ddi_pll(dev_priv, port, pipe_config);
else
hsw_get_ddi_pll(dev_priv, port, pipe_config);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: Move intel_dpll_get_hw_state() into the hsw+ platform specific functions
From: Ville Syrjälä
On icl+ we want to populate both crtc_state.{shared_dpll,dpll_hw_state}
and crtc_state.port_dplls[] during readout, whereas on pre-icl we
want to leave the latter stuff untouched. Rather than adding more ifs
into hsw_get_ddi_port_state() to copy the DPLL hw state around let's
just move the whole dpll readout into hsw_get_ddi_dpll() & co.
Slightly repetitive, but meh.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 68 +++-
1 file changed, 52 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index a7c4cd7a8a31..8ab622c0186e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11010,7 +11010,10 @@ static void dg1_get_ddi_pll(struct drm_i915_private
*dev_priv, enum port port,
{
enum icl_port_dpll_id port_dpll_id = ICL_PORT_DPLL_DEFAULT;
enum phy phy = intel_port_to_phy(dev_priv, port);
+ struct icl_port_dpll *port_dpll;
+ struct intel_shared_dpll *pll;
enum intel_dpll_id id;
+ bool pll_active;
u32 clk_sel;
clk_sel = intel_de_read(dev_priv, DG1_DPCLKA_CFGCR0(phy)) &
DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
@@ -11019,8 +11022,13 @@ static void dg1_get_ddi_pll(struct drm_i915_private
*dev_priv, enum port port,
if (WARN_ON(id > DPLL_ID_DG1_DPLL3))
return;
- pipe_config->icl_port_dplls[port_dpll_id].pll =
- intel_get_shared_dpll_by_id(dev_priv, id);
+ pll = intel_get_shared_dpll_by_id(dev_priv, id);
+ port_dpll = &pipe_config->icl_port_dplls[port_dpll_id];
+
+ port_dpll->pll = pll;
+ pll_active = intel_dpll_get_hw_state(dev_priv, pll,
+&port_dpll->hw_state);
+ drm_WARN_ON(&dev_priv->drm, !pll_active);
icl_set_active_port_dpll(pipe_config, port_dpll_id);
}
@@ -11028,7 +11036,9 @@ static void dg1_get_ddi_pll(struct drm_i915_private
*dev_priv, enum port port,
static void cnl_get_ddi_pll(struct drm_i915_private *dev_priv, enum port port,
struct intel_crtc_state *pipe_config)
{
+ struct intel_shared_dpll *pll;
enum intel_dpll_id id;
+ bool pll_active;
u32 temp;
temp = intel_de_read(dev_priv, DPCLKA_CFGCR0) &
DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
@@ -11037,7 +11047,12 @@ static void cnl_get_ddi_pll(struct drm_i915_private
*dev_priv, enum port port,
if (drm_WARN_ON(&dev_priv->drm, id < SKL_DPLL0 || id > SKL_DPLL2))
return;
- pipe_config->shared_dpll = intel_get_shared_dpll_by_id(dev_priv, id);
+ pll = intel_get_shared_dpll_by_id(dev_priv, id);
+
+ pipe_config->shared_dpll = pll;
+ pll_active = intel_dpll_get_hw_state(dev_priv, pll,
+&pipe_config->dpll_hw_state);
+ drm_WARN_ON(&dev_priv->drm, !pll_active);
}
static void icl_get_ddi_pll(struct drm_i915_private *dev_priv, enum port port,
@@ -11045,7 +11060,10 @@ static void icl_get_ddi_pll(struct drm_i915_private
*dev_priv, enum port port,
{
enum phy phy = intel_port_to_phy(dev_priv, port);
enum icl_port_dpll_id port_dpll_id;
+ struct icl_port_dpll *port_dpll;
+ struct intel_shared_dpll *pll;
enum intel_dpll_id id;
+ bool pll_active;
u32 temp;
if (intel_phy_is_combo(dev_priv, phy)) {
@@ -11080,8 +11098,13 @@ static void icl_get_ddi_pll(struct drm_i915_private
*dev_priv, enum port port,
return;
}
- pipe_config->icl_port_dplls[port_dpll_id].pll =
- intel_get_shared_dpll_by_id(dev_priv, id);
+ pll = intel_get_shared_dpll_by_id(dev_priv, id);
+ port_dpll = &pipe_config->icl_port_dplls[port_dpll_id];
+
+ port_dpll->pll = pll;
+ pll_active = intel_dpll_get_hw_state(dev_priv, pll,
+&port_dpll->hw_state);
+ drm_WARN_ON(&dev_priv->drm, !pll_active);
icl_set_active_port_dpll(pipe_config, port_dpll_id);
}
@@ -11090,7 +3,9 @@ static void bxt_get_ddi_pll(struct drm_i915_private
*dev_priv,
enum port port,
struct intel_crtc_state *pipe_config)
{
+ struct intel_shared_dpll *pll;
enum intel_dpll_id id;
+ bool pll_active;
switch (port) {
case PORT_A:
@@ -11107,13 +11132,20 @@ static void bxt_get_ddi_pll(struct drm_i915_private
*dev_priv,
return;
}
- pipe_config->shared_dpll = intel_get_shared_dpll_by_id(dev_priv, id);
+ pll = intel_get_shared_dpll_by_id(dev_priv, id);
+
+ pipe_config->shared_dpll = pll;
+ pll_active = intel_dpll_get_hw_state(dev_priv, pll,
+&pipe_config->dpll_hw_state);
+ drm_WARN_ON(&dev_priv->drm,
[Intel-gfx] [PATCH 1/4] drm/i915: Introduce intel_dpll_get_hw_state()
From: Ville Syrjälä
Add a wrapper for the pll .get_hw_state() vfunc. Makes life
a bit less miserable when you don't have to worry where the
function pointer is stored.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 14 +++--
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 20 ---
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 3 +++
3 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 2729c852c668..a7c4cd7a8a31 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10927,6 +10927,7 @@ static bool ilk_get_pipe_config(struct intel_crtc *crtc,
if (intel_de_read(dev_priv, PCH_TRANSCONF(crtc->pipe)) & TRANS_ENABLE) {
struct intel_shared_dpll *pll;
enum intel_dpll_id pll_id;
+ bool pll_active;
pipe_config->has_pch_encoder = true;
@@ -10954,8 +10955,9 @@ static bool ilk_get_pipe_config(struct intel_crtc *crtc,
intel_get_shared_dpll_by_id(dev_priv, pll_id);
pll = pipe_config->shared_dpll;
- drm_WARN_ON(dev, !pll->info->funcs->get_hw_state(dev_priv, pll,
-&pipe_config->dpll_hw_state));
+ pll_active = intel_dpll_get_hw_state(dev_priv, pll,
+
&pipe_config->dpll_hw_state);
+ drm_WARN_ON(dev, !pll_active);
tmp = pipe_config->dpll_hw_state.dpll;
pipe_config->pixel_multiplier =
@@ -11346,9 +11348,9 @@ static void hsw_get_ddi_port_state(struct intel_crtc
*crtc,
pll = pipe_config->shared_dpll;
if (pll) {
- drm_WARN_ON(&dev_priv->drm,
- !pll->info->funcs->get_hw_state(dev_priv, pll,
- &pipe_config->dpll_hw_state));
+ bool pll_active = intel_dpll_get_hw_state(dev_priv, pll,
+
&pipe_config->dpll_hw_state);
+ drm_WARN_ON(&dev_priv->drm, !pll_active);
}
/*
@@ -14587,7 +14589,7 @@ verify_single_dpll_state(struct drm_i915_private
*dev_priv,
drm_dbg_kms(&dev_priv->drm, "%s\n", pll->info->name);
- active = pll->info->funcs->get_hw_state(dev_priv, pll, &dpll_hw_state);
+ active = intel_dpll_get_hw_state(dev_priv, pll, &dpll_hw_state);
if (!(pll->info->flags & INTEL_DPLL_ALWAYS_ON)) {
I915_STATE_WARN(!pll->on && pll->active_mask,
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index a95e6a2ac698..1604c20bac33 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -141,7 +141,7 @@ void assert_shared_dpll(struct drm_i915_private *dev_priv,
"asserting DPLL %s with no DPLL\n", onoff(state)))
return;
- cur_state = pll->info->funcs->get_hw_state(dev_priv, pll, &hw_state);
+ cur_state = intel_dpll_get_hw_state(dev_priv, pll, &hw_state);
I915_STATE_WARN(cur_state != state,
"%s assertion failure (expected %s, current %s)\n",
pll->info->name, onoff(state), onoff(cur_state));
@@ -4527,13 +4527,27 @@ int intel_dpll_get_freq(struct drm_i915_private *i915,
return pll->info->funcs->get_freq(i915, pll);
}
+/**
+ * intel_dpll_get_hw_state - readout the DPLL's hardware state
+ * @i915: i915 device
+ * @pll: DPLL for which to calculate the output frequency
+ * @hw_state: DPLL's hardware state
+ *
+ * Read out @pll's hardware state into @hw_state.
+ */
+bool intel_dpll_get_hw_state(struct drm_i915_private *i915,
+struct intel_shared_dpll *pll,
+struct intel_dpll_hw_state *hw_state)
+{
+ return pll->info->funcs->get_hw_state(i915, pll, hw_state);
+}
+
static void readout_dpll_hw_state(struct drm_i915_private *i915,
struct intel_shared_dpll *pll)
{
struct intel_crtc *crtc;
- pll->on = pll->info->funcs->get_hw_state(i915, pll,
-&pll->state.hw_state);
+ pll->on = intel_dpll_get_hw_state(i915, pll, &pll->state.hw_state);
if (IS_JSL_EHL(i915) && pll->on &&
pll->info->id == DPLL_ID_EHL_DPLL4) {
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
index 205542fb8dc7..4357f92eafd6 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
@@ -400,6 +400,9 @@ void intel_update_active_dpll(struct intel_atomic_state
*state,
struct intel_encoder *encoder
[Intel-gfx] [PATCH 3/4] drm/i915: Use actual readout results for .get_freq()
From: Ville Syrjälä
Currently the DPLL .get_freq() uses pll->state.hw_state which
is not the thing we actually read out (except during driver
load/resume). Outside of that pll->state.hw_state is just the
thing we committed last time around. During state check we
just read the thing into crtc_state->dpll_hw_state, so that
is what we should use for calculating the DPLL output frequency.
I think we used to do this so that the results of the readout
were actually used, but somehow it got changed when the
.get_freq() refactoring happened.
Cc: Imre Deak
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/icl_dsi.c| 3 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 3 +-
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 78 +++
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 8 +-
4 files changed, 54 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 096652921453..769bb1b0d543 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1496,7 +1496,8 @@ static void gen11_dsi_get_config(struct intel_encoder
*encoder,
/* FIXME: adapt icl_ddi_clock_get() for DSI and use that? */
pipe_config->port_clock = intel_dpll_get_freq(i915,
- pipe_config->shared_dpll);
+ pipe_config->shared_dpll,
+
&pipe_config->dpll_hw_state);
pipe_config->hw.adjusted_mode.crtc_clock = intel_dsi->pclk;
if (intel_dsi->dual_link)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index d4b1b73c7aab..9d80e47e9558 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1755,7 +1755,8 @@ static void intel_ddi_clock_get(struct intel_encoder
*encoder,
encoder->port);
else
pipe_config->port_clock =
- intel_dpll_get_freq(dev_priv, pipe_config->shared_dpll);
+ intel_dpll_get_freq(dev_priv, pipe_config->shared_dpll,
+ &pipe_config->dpll_hw_state);
ddi_dotclock_get(pipe_config);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 1604c20bac33..0f14c4dee02c 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -891,11 +891,12 @@ hsw_ddi_wrpll_get_dpll(struct intel_atomic_state *state,
}
static int hsw_ddi_wrpll_get_freq(struct drm_i915_private *dev_priv,
- const struct intel_shared_dpll *pll)
+ const struct intel_shared_dpll *pll,
+ const struct intel_dpll_hw_state *pll_state)
{
int refclk;
int n, p, r;
- u32 wrpll = pll->state.hw_state.wrpll;
+ u32 wrpll = pll_state->wrpll;
switch (wrpll & WRPLL_REF_MASK) {
case WRPLL_REF_SPECIAL_HSW:
@@ -962,7 +963,8 @@ hsw_ddi_lcpll_get_dpll(struct intel_crtc_state *crtc_state)
}
static int hsw_ddi_lcpll_get_freq(struct drm_i915_private *i915,
- const struct intel_shared_dpll *pll)
+ const struct intel_shared_dpll *pll,
+ const struct intel_dpll_hw_state *pll_state)
{
int link_clock = 0;
@@ -1002,11 +1004,12 @@ hsw_ddi_spll_get_dpll(struct intel_atomic_state *state,
}
static int hsw_ddi_spll_get_freq(struct drm_i915_private *i915,
-const struct intel_shared_dpll *pll)
+const struct intel_shared_dpll *pll,
+const struct intel_dpll_hw_state *pll_state)
{
int link_clock = 0;
- switch (pll->state.hw_state.spll & SPLL_FREQ_MASK) {
+ switch (pll_state->spll & SPLL_FREQ_MASK) {
case SPLL_FREQ_810MHz:
link_clock = 81000;
break;
@@ -1577,9 +1580,9 @@ static bool skl_ddi_hdmi_pll_dividers(struct
intel_crtc_state *crtc_state)
}
static int skl_ddi_wrpll_get_freq(struct drm_i915_private *i915,
- const struct intel_shared_dpll *pll)
+ const struct intel_shared_dpll *pll,
+ const struct intel_dpll_hw_state *pll_state)
{
- const struct intel_dpll_hw_state *pll_state = &pll->state.hw_state;
int ref_clock = i915->dpll.ref_clks.nssc;
u32 p0, p1, p2, dco_freq;
@@ -1688,12 +1691,12 @@ skl_ddi_dp_set_dpll_hw_state(struct intel_crtc_state
*crtc_state)
}
static int skl_ddi_lcpll_get_freq(struct drm_i915_private *i915,
-
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Pass intel_atomic_state around
On Fri, Nov 06, 2020 at 07:30:37PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pass the whole intel_atomic_state to skl_build_pipe_wm()
> and skl_allocate_pipe_ddb() so we can start to iterate
> stuff containerd in the commit.
>
> Signed-off-by: Ville Syrjälä
This looks good to me,
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/intel_pm.c | 24 +---
> 1 file changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index f54375b11964..e9ac6f1a5d28 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4791,9 +4791,11 @@ skl_plane_wm_level(const struct intel_crtc_state
> *crtc_state,
> }
>
> static int
> -skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
> +skl_allocate_pipe_ddb(struct intel_atomic_state *state,
> + struct intel_crtc *crtc)
> {
> - struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + struct intel_crtc_state *crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> struct skl_ddb_entry *alloc = &crtc_state->wm.skl.ddb;
> u16 alloc_size, start = 0;
> @@ -5583,9 +5585,12 @@ static int icl_build_plane_wm(struct intel_crtc_state
> *crtc_state,
> return 0;
> }
>
> -static int skl_build_pipe_wm(struct intel_crtc_state *crtc_state)
> +static int skl_build_pipe_wm(struct intel_atomic_state *state,
> + struct intel_crtc *crtc)
> {
> - struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + struct intel_crtc_state *crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> struct skl_pipe_wm *pipe_wm = &crtc_state->wm.skl.optimal;
> struct intel_plane *plane;
> const struct intel_plane_state *plane_state;
> @@ -5794,7 +5799,7 @@ skl_compute_ddb(struct intel_atomic_state *state)
>
> for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> new_crtc_state, i) {
> - ret = skl_allocate_pipe_ddb(new_crtc_state);
> + ret = skl_allocate_pipe_ddb(state, crtc);
> if (ret)
> return ret;
>
> @@ -6092,7 +6097,6 @@ skl_compute_wm(struct intel_atomic_state *state)
> {
> struct intel_crtc *crtc;
> struct intel_crtc_state *new_crtc_state;
> - struct intel_crtc_state *old_crtc_state;
> int ret, i;
>
> ret = skl_ddb_add_affected_pipes(state);
> @@ -6104,9 +6108,8 @@ skl_compute_wm(struct intel_atomic_state *state)
>* Note that skl_ddb_add_affected_pipes may have added more CRTC's that
>* weren't otherwise being modified if pipe allocations had to change.
>*/
> - for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> - new_crtc_state, i) {
> - ret = skl_build_pipe_wm(new_crtc_state);
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + ret = skl_build_pipe_wm(state, crtc);
> if (ret)
> return ret;
> }
> @@ -6124,8 +6127,7 @@ skl_compute_wm(struct intel_atomic_state *state)
>* based on how much ddb is available. Now we can actually
>* check if the final watermarks changed.
>*/
> - for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> - new_crtc_state, i) {
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> ret = skl_wm_add_affected_planes(state, crtc);
> if (ret)
> return ret;
> --
> 2.26.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 7/7] drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.
All the review comments addressed here,
@Ville could you review this?
Manasi
On Mon, Nov 09, 2020 at 12:12:46PM -0800, Manasi Navare wrote:
> From: Maarten Lankhorst
>
> Small changes to intel_dp_mode_valid(), allow listing modes that
> can only be supported in the bigjoiner configuration, which is
> not supported yet.
>
> v13:
> * Allow bigjoiner if hdisplay >5120
> v12:
> * slice_count logic simplify (Ville)
> * Fix unnecessary changes in downstream_mode_valid (Ville)
> v11:
> * Make intel_dp_can_bigjoiner non static
> so it can be used in intel_display (Manasi)
> v10:
> * Simplify logic (Ville)
> * Allow bigjoiner on edp (Ville)
> v9:
> * Restric Bigjoiner on PORT A (Ville)
> v8:
> * use source dotclock for max dotclock (Manasi)
> v7:
> * Add can_bigjoiner() helper (Ville)
> * Pass bigjoiner to plane_size validation (Ville)
> v6:
> * Rebase after dp_downstream mode valid changes (Manasi)
> v5:
> * Increase max plane width to support 8K with bigjoiner (Maarten)
> v4:
> * Rebase (Manasi)
>
> Changes since v1:
> - Disallow bigjoiner on eDP.
> Changes since v2:
> - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock,
> and split off the downstream and source checking to its own function.
> (Ville)
> v3:
> * Rebase (Manasi)
>
> Signed-off-by: Manasi Navare
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 5 +-
> drivers/gpu/drm/i915/display/intel_display.h | 3 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 78
> drivers/gpu/drm/i915/display/intel_dp.h | 1 +
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
> drivers/gpu/drm/i915/display/intel_dsi.c | 2 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c| 2 +-
> 7 files changed, 73 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 77718c828d66..c08b92149cea 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -17791,7 +17791,8 @@ intel_mode_valid(struct drm_device *dev,
>
> enum drm_mode_status
> intel_mode_valid_max_plane_size(struct drm_i915_private *dev_priv,
> - const struct drm_display_mode *mode)
> + const struct drm_display_mode *mode,
> + bool bigjoiner)
> {
> int plane_width_max, plane_height_max;
>
> @@ -17808,7 +17809,7 @@ intel_mode_valid_max_plane_size(struct
> drm_i915_private *dev_priv,
>* too big for that.
>*/
> if (INTEL_GEN(dev_priv) >= 11) {
> - plane_width_max = 5120;
> + plane_width_max = 5120 << bigjoiner;
> plane_height_max = 4320;
> } else {
> plane_width_max = 5120;
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index be774f216065..d24077df1711 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -513,7 +513,8 @@ u32 intel_plane_fb_max_stride(struct drm_i915_private
> *dev_priv,
> bool intel_plane_can_remap(const struct intel_plane_state *plane_state);
> enum drm_mode_status
> intel_mode_valid_max_plane_size(struct drm_i915_private *dev_priv,
> - const struct drm_display_mode *mode);
> + const struct drm_display_mode *mode,
> + bool bigjoiner);
> enum phy intel_port_to_phy(struct drm_i915_private *i915, enum port port);
> bool is_trans_port_sync_mode(const struct intel_crtc_state *state);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index ec8359f03aaf..c7eb619662d1 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -254,6 +254,17 @@ intel_dp_max_data_rate(int max_link_clock, int max_lanes)
> return max_link_clock * max_lanes;
> }
>
> +bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct intel_encoder *encoder = &intel_dig_port->base;
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + return INTEL_GEN(dev_priv) >= 12 ||
> + (INTEL_GEN(dev_priv) == 11 &&
> + encoder->port != PORT_A);
> +}
> +
> static int cnl_max_source_rate(struct intel_dp *intel_dp)
> {
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> @@ -519,7 +530,8 @@ small_joiner_ram_size_bits(struct drm_i915_private *i915)
>
> static u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> u32 link_clock, u32 lane_count,
> -u32 mode_clock, u32 mode_hdisplay)
> +u32 mode_clock, u32 mode_h
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/edp/jsl: Update vswing table for HBR and HBR2 (rev3)
On Tue, 2020-10-20 at 07:40 +, Patchwork wrote:
> Patch Details
> Series: drm/i915/edp/jsl: Update vswing table for HBR and HBR2 (rev3) URL:
> https://patchwork.freedesktop.org/series/82206/ State: success Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18738/index.html
> CI Bug Log - changes from CI_DRM_9166_full ->
> Patchwork_18738_fullSummarySUCCESS
> No regressions found.
Thanks for the patch, pushed to dinq.
> Known issuesHere are the changes found in Patchwork_18738_full that come from
> known issues:
> IGT changesIssues hit * igt@gem_exec_reloc@basic-many-active@rcs0:shard-snb:
> PASS -> FAIL (i915#2389)
> * igt@gem_exec_whisper@basic-forked-all:shard-glk: PASS -> DMESG-WARN
> (i915#118 / i915#95)
> * igt@gem_userptr_blits@unsync-unmap-cycles:shard-skl: PASS -> TIMEOUT
> (i915#2424) +1 similar issue
> * igt@i915_pm_dc@dc6-psr:shard-skl: PASS -> FAIL (i915#454)
> * igt@kms_draw_crc@draw-method-xrgb-render-xtiled:shard-snb: PASS ->
> FAIL (i915#54)
> * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:shard-skl: PASS ->
> INCOMPLETE (i915#198)
> * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:shard-skl: PASS -> FAIL
> (fdo#108145 / i915#265)
> * igt@kms_plane_scaling@pipe-c-plane-scaling:shard-skl: PASS -> DMESG-WARN
> (i915#1982) +6 similar issues
> * igt@kms_psr@psr2_cursor_render:shard-iclb: PASS -> SKIP (fdo#109441) +3
> similar issues
> * igt@kms_universal_plane@universal-plane-gen9-features-pipe-a:shard-kbl:
> PASS -> DMESG-WARN (i915#1982)
> * igt@kms_vblank@crtc-id:shard-tglb: PASS -> DMESG-WARN (i915#1982)
> Possible fixes * igt@api_intel_bb@blit-noreloc-purge-cache:shard-snb: FAIL ->
> PASS
> * igt@gem_exec_parallel@fds@vecs0:shard-iclb: DMESG-WARN (i915#1982) -> PASS
> * igt@gem_exec_reloc@basic-many-active@vecs0:shard-glk: FAIL (i915#2389) ->
> PASS +2 similar issues
> * igt@gem_exec_whisper@basic-contexts:shard-glk: DMESG-WARN (i915#118 /
> i915#95) -> PASS +2 similar issues
> * igt@i915_pm_backlight@fade_with_suspend:shard-skl: INCOMPLETE -> PASS
> * igt@i915_suspend@debugfs-reader:shard-kbl: INCOMPLETE (i915#155) -> PASS
> * {igt@kms_async_flips@async-flip-with-page-flip-events}:shard-kbl: FAIL
> (i915#2521) -> PASS +1 similar issueshard-apl: FAIL (i915#1635 /
> i915#2521) -> PASS
> * igt@kms_big_fb@linear-32bpp-rotate-180:shard-glk: DMESG-FAIL (i915#118 /
> i915#95) -> PASS
> * igt@kms_big_fb@y-tiled-8bpp-rotate-180:shard-kbl: DMESG-WARN (i915#1982)
> -> PASS +1 similar issueshard-apl: DMESG-WARN (i915#1635 / i915#1982) ->
> PASS
> * igt@kms_ccs@pipe-a-crc-primary-rotation-180:shard-skl: FAIL -> PASS
> * igt@kms_cursor_crc@pipe-c-cursor-128x128-onscreen:shard-skl: FAIL
> (i915#54) -> PASS
> * igt@kms_cursor_legacy@cursor-vs-flip-varying-size:shard-hsw: FAIL
> (i915#2370) -> PASS
> * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-xtiled:shard-skl: DMESG-WARN
> (i915#1982) -> PASS +6 similar issues
> * igt@kms_draw_crc@draw-method-xrgb2101010-blt-untiled:shard-snb: FAIL
> (i915#54) -> PASS
> * igt@kms_flip@2x-flip-vs-absolute-wf_vblank@ab-vga1-hdmi-a1:shard-hsw:
> DMESG-WARN (i915#1982) -> PASS
> * igt@kms_flip@plain-flip-fb-recreate@b-edp1:shard-skl: FAIL (i915#2122) ->
> PASS
> * igt@kms_frontbuffer_tracking@fbc-modesetfrombusy:shard-snb: FAIL
> (i915#2546) -> PASS
> *
> igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-blt:shard-tglb:
> DMESG-WARN (i915#1982) -> PASS +1 similar issue
> * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:shard-skl: FAIL (fdo#108145
> / i915#265) -> PASS +1 similar issue
> * igt@kms_psr@psr2_cursor_blt:shard-iclb: SKIP (fdo#109441) -> PASS +1
> similar issue
> * igt@kms_vblank@pipe-c-ts-continuation-suspend:shard-skl: INCOMPLETE
> (i915#198) -> PASS
> * igt@perf@polling-parameterized:shard-skl: FAIL (i915#1542) -> PASS
> Warnings * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:shard-skl:
> DMESG-WARN (i915#1982) -> FAIL (fdo#108145 / i915#265)
> * igt@kms_setmode@basic:shard-skl: FAIL (i915#31) -> DMESG-FAIL (i915#1982 /
> i915#31)
> * igt@prime_vgem@coherency-blt:shard-snb: FAIL -> INCOMPLETE (i915#82)
> {name}: This element is suppressed. This means it is ignored when computing
> the status of the difference (SUCCESS, WARNING, or FAILURE).
> Participating hosts (11 -> 11)No changes in participating hosts
> Build changes * Linux: CI_DRM_9166 -> Patchwork_18738
> CI-20190529: 20190529
> CI_DRM_9166: f10a69af784776f63cf892611a6baa33e8c35fca @
> git://anongit.freedesktop.org/gfx-ci/linux
> IGT_5822: b4bcf05cb9839037128905deda7146434155cc41 @
> git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
> Patchwork_18738: 4edc2bd181ae441b0057ee5108b0e76883c42310 @
> git://anongit.freedesktop.org/gfx-ci/linux
> piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
> git://anongit.freedesktop.org/piglit
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/li
Re: [Intel-gfx] [PATCH V2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
On Tue, 2020-10-20 at 11:06 +0530, Tejas Upadhyay wrote:
> JSL has update in vswing table for eDP.
>
> BSpec: 21257
>
> Changes since V1:
> - Fixed few checkpatch errors
>
Reviewed-by: José Roberto de Souza
> Cc: Souza Jose
> Signed-off-by: Tejas Upadhyay
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 87 +++-
> 1 file changed, 85 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index bb0b9930958f..8fd81a3932a4 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -582,6 +582,34 @@ static const struct cnl_ddi_buf_trans
> ehl_combo_phy_ddi_translations_dp[] = {
> { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> };
>
>
>
>
> +static const struct cnl_ddi_buf_trans
> jsl_combo_phy_ddi_translations_edp_hbr[] = {
> + /* NT mV Trans mV db*/
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> + { 0x8, 0x7F, 0x38, 0x00, 0x07 },/* 200 250 1.9 */
> + { 0x1, 0x7F, 0x33, 0x00, 0x0C },/* 200 300 3.5 */
> + { 0xA, 0x35, 0x36, 0x00, 0x09 },/* 200 350 4.9 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> + { 0x1, 0x7F, 0x38, 0x00, 0x07 },/* 250 300 1.6 */
> + { 0xA, 0x35, 0x35, 0x00, 0x0A },/* 250 350 2.9 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> +};
> +
> +static const struct cnl_ddi_buf_trans
> jsl_combo_phy_ddi_translations_edp_hbr2[] = {
> + /* NT mV Trans mV db*/
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 250 1.9 */
> + { 0x1, 0x7F, 0x3D, 0x00, 0x02 },/* 200 300 3.5 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 200 350 4.9 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 250 300 1.6 */
> + { 0xA, 0x35, 0x3A, 0x00, 0x05 },/* 250 350 2.9 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> +};
> +
> struct icl_mg_phy_ddi_buf_trans {
> u32 cri_txdeemph_override_11_6;
> u32 cri_txdeemph_override_5_0;
> @@ -1162,6 +1190,57 @@ ehl_get_combo_buf_trans(struct intel_encoder *encoder,
> return ehl_get_combo_buf_trans_dp(encoder, crtc_state,
> n_entries);
> }
>
>
>
>
> +static const struct cnl_ddi_buf_trans *
> +jsl_get_combo_buf_trans_hdmi(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state,
> + int *n_entries)
> +{
> + *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
> + return icl_combo_phy_ddi_translations_hdmi;
> +}
> +
> +static const struct cnl_ddi_buf_trans *
> +jsl_get_combo_buf_trans_dp(struct intel_encoder *encoder,
> +const struct intel_crtc_state *crtc_state,
> +int *n_entries)
> +{
> + *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
> + return icl_combo_phy_ddi_translations_dp_hbr2;
> +}
> +
> +static const struct cnl_ddi_buf_trans *
> +jsl_get_combo_buf_trans_edp(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state,
> + int *n_entries)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + if (dev_priv->vbt.edp.low_vswing) {
> + if (crtc_state->port_clock > 27) {
> + *n_entries =
> ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr2);
> + return jsl_combo_phy_ddi_translations_edp_hbr2;
> + } else {
> + *n_entries =
> ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr);
> + return jsl_combo_phy_ddi_translations_edp_hbr;
> + }
> + }
> +
> + return jsl_get_combo_buf_trans_dp(encoder, crtc_state, n_entries);
> +}
> +
> +static const struct cnl_ddi_buf_trans *
> +jsl_get_combo_buf_trans(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state,
> + int *n_entries)
> +{
> + if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> + return jsl_get_combo_buf_trans_hdmi(encoder, crtc_state,
> n_entries);
> + else if (intel_crtc_has_type(crtc_state, I
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Do not setup hpd without display
On Fri, 2020-11-06 at 14:55 -0800, Lucas De Marchi wrote: > Now that hpd/display related calls are split from the rest in > intel_irq_init(), skip all of that in case we don't have display. Reviewed-by: José Roberto de Souza > > Cc: José Roberto de Souza > Cc: Jani Nikula > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/i915_irq.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > index 4faf7cb9c158..01f5749a5905 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -4212,6 +4212,9 @@ void intel_irq_init(struct drm_i915_private *dev_priv) > if (HAS_GT_UC(dev_priv) && INTEL_GEN(dev_priv) < 11) > dev_priv->gt.pm_guc_events = GUC_INTR_GUC2HOST << 16; > > > > > + if (!HAS_DISPLAY(dev_priv)) > + return; > + > intel_hpd_init_pins(dev_priv); > > > > > intel_hpd_init_work(dev_priv); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable atomics in L3 for gen9
On Mon, Nov 09, 2020 at 08:15:05PM +, Chris Wilson wrote:
> Quoting Jason Ekstrand (2020-11-09 19:52:26)
> > We need to land this patch. The number of bugs we have piling up in
> > Mesa gitlab related to this is getting a lot larger than I'd like.
> > I've gone back and forth with various HW and SW people internally for
> > countless e-mail threads and there is no other good workaround. Yes,
> > the perf hit to atomics sucks but, fortunately, most games don't use
> > them heavily enough for it to make a significant impact. We should
> > just eat the perf hit and fix the hangs.
>
> Drat, I thought you had found an alternative fix in the
> bad GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC w/a.
>
> So be it.
I don't suppose this could be just lack of programming the magic
MOCS entry for L3 evictions?
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -132,6 +132,9 @@ static const struct drm_i915_mocs_entry skl_mocs_table[] = {
MOCS_ENTRY(I915_MOCS_CACHED,
LE_3_WB | LE_TC_2_LLC_ELLC | LE_LRUM(3),
L3_3_WB)
+ MOCS_ENTRY(63,
+ LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_1_UC)
};
/* NOTE: the LE_TGT_CACHE is not used on Broxton */
The code seems to claim we can't even program that on gen9, but there's
nothing in the current spec to back that up AFAICS.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm/i915: move display-related to the end of intel_irq_init()
On Fri, 2020-11-06 at 14:55 -0800, Lucas De Marchi wrote: > In intel_irq_init() move what's display/hpd related after what is gt and > guc. This makes it easier to support !HAS_DISPLAY() in future. Reviewed-by: José Roberto de Souza > > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/i915_irq.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > index 2ab4edf7f25c..4faf7cb9c158 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -4204,10 +4204,6 @@ void intel_irq_init(struct drm_i915_private *dev_priv) > struct drm_device *dev = &dev_priv->drm; > int i; > > > > > - intel_hpd_init_pins(dev_priv); > - > - intel_hpd_init_work(dev_priv); > - > INIT_WORK(&dev_priv->l3_parity.error_work, ivb_parity_work); > for (i = 0; i < MAX_L3_SLICES; ++i) > dev_priv->l3_parity.remap_info[i] = NULL; > @@ -4216,6 +4212,10 @@ void intel_irq_init(struct drm_i915_private *dev_priv) > if (HAS_GT_UC(dev_priv) && INTEL_GEN(dev_priv) < 11) > dev_priv->gt.pm_guc_events = GUC_INTR_GUC2HOST << 16; > > > > > + intel_hpd_init_pins(dev_priv); > + > + intel_hpd_init_work(dev_priv); > + > dev->vblank_disable_immediate = true; > > > > > /* Most platforms treat the display irq block as an always-on ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915: re-order if/else ladder for hpd_irq_setup
On Fri, 2020-11-06 at 14:55 -0800, Lucas De Marchi wrote:
> Use the convention of new platforms first. No need to special case
> HAS_GMCH() since that stopped being true at the lattest on gen8 (for
> cherryview).
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_irq.c | 27 ---
> 1 file changed, 12 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index e0eb32bd9607..2ab4edf7f25c 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -4237,21 +4237,18 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
> */
> dev_priv->hotplug.hpd_short_storm_enabled = !HAS_DP_MST(dev_priv);
>
>
>
>
> - if (HAS_GMCH(dev_priv)) {
> - if (I915_HAS_HOTPLUG(dev_priv))
> - dev_priv->display.hpd_irq_setup = i915_hpd_irq_setup;
> - } else {
> - if (HAS_PCH_DG1(dev_priv))
> - dev_priv->display.hpd_irq_setup = dg1_hpd_irq_setup;
> - else if (INTEL_GEN(dev_priv) >= 11)
> - dev_priv->display.hpd_irq_setup = gen11_hpd_irq_setup;
> - else if (IS_GEN9_LP(dev_priv))
> - dev_priv->display.hpd_irq_setup = bxt_hpd_irq_setup;
> - else if (INTEL_PCH_TYPE(dev_priv) >= PCH_SPT)
> - dev_priv->display.hpd_irq_setup = spt_hpd_irq_setup;
> - else
> - dev_priv->display.hpd_irq_setup = ilk_hpd_irq_setup;
> - }
> + if (HAS_PCH_DG1(dev_priv))
> + dev_priv->display.hpd_irq_setup = dg1_hpd_irq_setup;
> + else if (INTEL_GEN(dev_priv) >= 11)
> + dev_priv->display.hpd_irq_setup = gen11_hpd_irq_setup;
> + else if (IS_GEN9_LP(dev_priv))
> + dev_priv->display.hpd_irq_setup = bxt_hpd_irq_setup;
> + else if (INTEL_PCH_TYPE(dev_priv) >= PCH_SPT)
> + dev_priv->display.hpd_irq_setup = spt_hpd_irq_setup;
> + else if (HAS_GMCH(dev_priv) && I915_HAS_HOTPLUG(dev_priv))
> + dev_priv->display.hpd_irq_setup = i915_hpd_irq_setup;
> + else
> + dev_priv->display.hpd_irq_setup = ilk_hpd_irq_setup;
> }
>
>
>
>
> /**
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/8] drm/i915/display: return earlier from intel_modeset_init() without display
On Fri, 2020-11-06 at 14:55 -0800, Lucas De Marchi wrote:
> From: Jani Nikula
>
> !HAS_DISPLAY() implies !HAS_OVERLAY(), skipping overlay setup anyway, so
> return earlier from intel_modeset_init() for clarity.
Reviewed-by: José Roberto de Souza
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index b6a9d41a043e..b3e6c43f0cb2 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -18364,11 +18364,11 @@ int intel_modeset_init(struct drm_i915_private
> *i915)
> {
> int ret;
>
>
>
>
> - intel_overlay_setup(i915);
> -
> if (!HAS_DISPLAY(i915))
> return 0;
>
>
>
>
> + intel_overlay_setup(i915);
> +
> ret = intel_fbdev_init(&i915->drm);
> if (ret)
> return ret;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Disable atomics in L3 for gen9
Enabling atomic operations in L3 leads to unrecoverable GPU hangs, as
the machine stops responding milliseconds after receipt of the reset
request [GDRT]. By disabling the cached atomics, the hang do not occur
and we presume the GPU would reset normally for similar hangs.
Reported-by: Jason Ekstrand
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110998
Signed-off-by: Chris Wilson
Cc: Jason Ekstrand
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 8
drivers/gpu/drm/i915/i915_reg.h | 7 +++
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index fed9503a7c4e..dc20b0344f17 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1959,6 +1959,14 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
wa_write_or(wal,
GEN8_L3SQCREG4,
GEN8_LQSC_FLUSH_COHERENT_LINES);
+
+ /* Disable atomics in L3 to prevent unrecoverable hangs */
+ wa_write_masked_or(wal, GEN9_SCRATCH_LNCF1,
+ GEN9_LNCF_NONIA_COHERENT_ATOMICS_ENABLE, 0);
+ wa_write_masked_or(wal, GEN8_L3SQCREG4,
+ GEN8_LQSQ_NONIA_COHERENT_ATOMICS_ENABLE, 0);
+ wa_write_masked_or(wal, GEN9_SCRATCH1,
+ EVICTION_PERF_FIX_ENABLE, 0);
}
if (IS_GEN(i915, 7))
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index bb0656875697..c9646dca6ed0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8209,6 +8209,7 @@ enum {
#define GEN11_LQSC_CLEAN_EVICT_DISABLE(1 << 6)
#define GEN8_LQSC_RO_PERF_DIS (1 << 27)
#define GEN8_LQSC_FLUSH_COHERENT_LINES(1 << 21)
+#define GEN8_LQSQ_NONIA_COHERENT_ATOMICS_ENABLE REG_BIT(22)
/* GEN8 chicken */
#define HDC_CHICKEN0 _MMIO(0x7300)
@@ -12029,6 +12030,12 @@ enum skl_power_gate {
#define __GEN11_VCS2_MOCS0 0x1
#define GEN11_MFX2_MOCS(i) _MMIO(__GEN11_VCS2_MOCS0 + (i) * 4)
+#define GEN9_SCRATCH_LNCF1 _MMIO(0xb008)
+#define GEN9_LNCF_NONIA_COHERENT_ATOMICS_ENABLE REG_BIT(0)
+
+#define GEN9_SCRATCH1 _MMIO(0xb11c)
+#define EVICTION_PERF_FIX_ENABLE REG_BIT(8)
+
#define GEN10_SCRATCH_LNCF2_MMIO(0xb0a0)
#define PMFLUSHDONE_LNICRSDROP (1 << 20)
#define PMFLUSH_GAPL3UNBLOCK (1 << 21)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable atomics in L3 for gen9
Quoting Jason Ekstrand (2020-11-09 19:52:26) > We need to land this patch. The number of bugs we have piling up in > Mesa gitlab related to this is getting a lot larger than I'd like. > I've gone back and forth with various HW and SW people internally for > countless e-mail threads and there is no other good workaround. Yes, > the perf hit to atomics sucks but, fortunately, most games don't use > them heavily enough for it to make a significant impact. We should > just eat the perf hit and fix the hangs. Drat, I thought you had found an alternative fix in the bad GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC w/a. So be it. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 7/7] drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.
From: Maarten Lankhorst
Small changes to intel_dp_mode_valid(), allow listing modes that
can only be supported in the bigjoiner configuration, which is
not supported yet.
v13:
* Allow bigjoiner if hdisplay >5120
v12:
* slice_count logic simplify (Ville)
* Fix unnecessary changes in downstream_mode_valid (Ville)
v11:
* Make intel_dp_can_bigjoiner non static
so it can be used in intel_display (Manasi)
v10:
* Simplify logic (Ville)
* Allow bigjoiner on edp (Ville)
v9:
* Restric Bigjoiner on PORT A (Ville)
v8:
* use source dotclock for max dotclock (Manasi)
v7:
* Add can_bigjoiner() helper (Ville)
* Pass bigjoiner to plane_size validation (Ville)
v6:
* Rebase after dp_downstream mode valid changes (Manasi)
v5:
* Increase max plane width to support 8K with bigjoiner (Maarten)
v4:
* Rebase (Manasi)
Changes since v1:
- Disallow bigjoiner on eDP.
Changes since v2:
- Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock,
and split off the downstream and source checking to its own function.
(Ville)
v3:
* Rebase (Manasi)
Signed-off-by: Manasi Navare
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 5 +-
drivers/gpu/drm/i915/display/intel_display.h | 3 +-
drivers/gpu/drm/i915/display/intel_dp.c | 78
drivers/gpu/drm/i915/display/intel_dp.h | 1 +
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
drivers/gpu/drm/i915/display/intel_dsi.c | 2 +-
drivers/gpu/drm/i915/display/intel_hdmi.c| 2 +-
7 files changed, 73 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 77718c828d66..c08b92149cea 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -17791,7 +17791,8 @@ intel_mode_valid(struct drm_device *dev,
enum drm_mode_status
intel_mode_valid_max_plane_size(struct drm_i915_private *dev_priv,
- const struct drm_display_mode *mode)
+ const struct drm_display_mode *mode,
+ bool bigjoiner)
{
int plane_width_max, plane_height_max;
@@ -17808,7 +17809,7 @@ intel_mode_valid_max_plane_size(struct drm_i915_private
*dev_priv,
* too big for that.
*/
if (INTEL_GEN(dev_priv) >= 11) {
- plane_width_max = 5120;
+ plane_width_max = 5120 << bigjoiner;
plane_height_max = 4320;
} else {
plane_width_max = 5120;
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index be774f216065..d24077df1711 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -513,7 +513,8 @@ u32 intel_plane_fb_max_stride(struct drm_i915_private
*dev_priv,
bool intel_plane_can_remap(const struct intel_plane_state *plane_state);
enum drm_mode_status
intel_mode_valid_max_plane_size(struct drm_i915_private *dev_priv,
- const struct drm_display_mode *mode);
+ const struct drm_display_mode *mode,
+ bool bigjoiner);
enum phy intel_port_to_phy(struct drm_i915_private *i915, enum port port);
bool is_trans_port_sync_mode(const struct intel_crtc_state *state);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index ec8359f03aaf..c7eb619662d1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -254,6 +254,17 @@ intel_dp_max_data_rate(int max_link_clock, int max_lanes)
return max_link_clock * max_lanes;
}
+bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct intel_encoder *encoder = &intel_dig_port->base;
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+
+ return INTEL_GEN(dev_priv) >= 12 ||
+ (INTEL_GEN(dev_priv) == 11 &&
+encoder->port != PORT_A);
+}
+
static int cnl_max_source_rate(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
@@ -519,7 +530,8 @@ small_joiner_ram_size_bits(struct drm_i915_private *i915)
static u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
u32 link_clock, u32 lane_count,
- u32 mode_clock, u32 mode_hdisplay)
+ u32 mode_clock, u32 mode_hdisplay,
+ bool bigjoiner)
{
u32 bits_per_pixel, max_bpp_small_joiner_ram;
int i;
@@ -537,6 +549,10 @@ static u16 intel_dp_dsc_get_output_bpp(struct
drm_i915_private *i915,
/* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz. width */
max_bpp_small_joi
[Intel-gfx] [PATCH v8 2/7] drm/i915: Move encoder->get_config to a new function
No functional changes, create a separate intel_encoder_get_config()
function that calls encoder->get_config hook.
This is needed so that later we can add beigjoienr related
readout here.
Signed-off-by: Manasi Navare
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6faca1e739c8..e8ef2c57ff05 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8222,6 +8222,12 @@ static u32 ilk_pipe_pixel_rate(const struct
intel_crtc_state *crtc_state)
pfit_w * pfit_h);
}
+static void intel_encoder_get_config(struct intel_encoder *encoder,
+struct intel_crtc_state *crtc_state)
+{
+ encoder->get_config(encoder, crtc_state);
+}
+
static void intel_crtc_compute_pixel_rate(struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
@@ -12475,7 +12481,7 @@ intel_encoder_current_mode(struct intel_encoder
*encoder)
return NULL;
}
- encoder->get_config(encoder, crtc_state);
+ intel_encoder_get_config(encoder, crtc_state);
intel_mode_from_pipe_config(mode, crtc_state);
@@ -14520,7 +14526,7 @@ verify_crtc_state(struct intel_crtc *crtc,
pipe_name(pipe));
if (active)
- encoder->get_config(encoder, pipe_config);
+ intel_encoder_get_config(encoder, pipe_config);
}
intel_crtc_compute_pixel_rate(pipe_config);
@@ -18833,7 +18839,7 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
crtc_state = to_intel_crtc_state(crtc->base.state);
encoder->base.crtc = &crtc->base;
- encoder->get_config(encoder, crtc_state);
+ intel_encoder_get_config(encoder, crtc_state);
if (encoder->sync_state)
encoder->sync_state(encoder, crtc_state);
} else {
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 6/7] drm/i915/dp: Add from_crtc_state to copy color blobs
No functional changes here, just adds a from_crtc_state
as a prep for bigjoiner
v2:
* More prep with intel_atomic_state (Ville)
Cc: Ville Syrjälä
Signed-off-by: Manasi Navare
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic.c | 9 +
drivers/gpu/drm/i915/display/intel_atomic.h | 3 ++-
drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 63d8d6840655..e00fdc47c0eb 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -269,14 +269,15 @@ void intel_crtc_free_hw_state(struct intel_crtc_state
*crtc_state)
intel_crtc_put_color_blobs(crtc_state);
}
-void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state)
+void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
+const struct intel_crtc_state *from_crtc_state)
{
drm_property_replace_blob(&crtc_state->hw.degamma_lut,
- crtc_state->uapi.degamma_lut);
+ from_crtc_state->uapi.degamma_lut);
drm_property_replace_blob(&crtc_state->hw.gamma_lut,
- crtc_state->uapi.gamma_lut);
+ from_crtc_state->uapi.gamma_lut);
drm_property_replace_blob(&crtc_state->hw.ctm,
- crtc_state->uapi.ctm);
+ from_crtc_state->uapi.ctm);
}
/**
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h
b/drivers/gpu/drm/i915/display/intel_atomic.h
index 285de07011dc..62a3365ed5e6 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic.h
@@ -43,7 +43,8 @@ struct drm_crtc_state *intel_crtc_duplicate_state(struct
drm_crtc *crtc);
void intel_crtc_destroy_state(struct drm_crtc *crtc,
struct drm_crtc_state *state);
void intel_crtc_free_hw_state(struct intel_crtc_state *crtc_state);
-void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state);
+void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
+const struct intel_crtc_state
*from_crtc_state);
struct drm_atomic_state *intel_atomic_state_alloc(struct drm_device *dev);
void intel_atomic_state_free(struct drm_atomic_state *state);
void intel_atomic_state_clear(struct drm_atomic_state *state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index b3b81339ed52..77718c828d66 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -13476,7 +13476,9 @@ static void
intel_crtc_copy_uapi_to_hw_state_nomodeset(struct intel_atomic_state *state,
struct intel_crtc_state *crtc_state)
{
- intel_crtc_copy_color_blobs(crtc_state);
+ const struct intel_crtc_state *from_crtc_state = crtc_state;
+
+ intel_crtc_copy_color_blobs(crtc_state, from_crtc_state);
}
static void
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 3/7] drm/i915/dp: Add a wrapper function around get_pipe_config
Create a new function intel_crtc_get_pipe_config()
that calls platform specific hooks for get_pipe_config()
No functional change here.
Suggested-by: Ville Syrjälä
Signed-off-by: Manasi Navare
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index e8ef2c57ff05..1530faf143f5 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11479,6 +11479,14 @@ static bool hsw_get_pipe_config(struct intel_crtc
*crtc,
return active;
}
+static bool intel_crtc_get_pipe_config(struct intel_crtc *crtc,
+ struct intel_crtc_state *pipe_config)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+
+ return dev_priv->display.get_pipe_config(crtc, pipe_config);
+}
+
static u32 intel_cursor_base(const struct intel_plane_state *plane_state)
{
struct drm_i915_private *dev_priv =
@@ -12475,7 +12483,7 @@ intel_encoder_current_mode(struct intel_encoder
*encoder)
return NULL;
}
- if (!dev_priv->display.get_pipe_config(crtc, crtc_state)) {
+ if (!intel_crtc_get_pipe_config(crtc, crtc_state)) {
kfree(crtc_state);
kfree(mode);
return NULL;
@@ -14495,7 +14503,7 @@ verify_crtc_state(struct intel_crtc *crtc,
pipe_config->hw.enable = new_crtc_state->hw.enable;
pipe_config->hw.active =
- dev_priv->display.get_pipe_config(crtc, pipe_config);
+ intel_crtc_get_pipe_config(crtc, pipe_config);
/* we keep both pipes enabled on 830 */
if (IS_I830(dev_priv) && pipe_config->hw.active)
@@ -18808,7 +18816,7 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
intel_crtc_state_reset(crtc_state, crtc);
crtc_state->hw.active = crtc_state->hw.enable =
- dev_priv->display.get_pipe_config(crtc, crtc_state);
+ intel_crtc_get_pipe_config(crtc, crtc_state);
crtc->base.enabled = crtc_state->hw.enable;
crtc->active = crtc_state->hw.active;
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 5/7] drm/i915: Pass intel_atomic_state instead of drm_atomic_state
No functional changes, to align with previous cleanups pass
intel_atomic_state instead of drm_atomic_state.
Also pass this intel_atomic_state with crtc_state to
some of the atomic_check functions.
v2:
* Squash some changes from next patch (Ville)
Signed-off-by: Manasi Navare
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 31 +++-
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 367902691c2c..b3b81339ed52 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12685,7 +12685,7 @@ static bool encoders_cloneable(const struct
intel_encoder *a,
b->cloneable & (1 << a->type));
}
-static bool check_single_encoder_cloning(struct drm_atomic_state *state,
+static bool check_single_encoder_cloning(struct intel_atomic_state *state,
struct intel_crtc *crtc,
struct intel_encoder *encoder)
{
@@ -12694,7 +12694,7 @@ static bool check_single_encoder_cloning(struct
drm_atomic_state *state,
struct drm_connector_state *connector_state;
int i;
- for_each_new_connector_in_state(state, connector, connector_state, i) {
+ for_each_new_connector_in_state(&state->base, connector,
connector_state, i) {
if (connector_state->crtc != &crtc->base)
continue;
@@ -13473,13 +13473,15 @@ static bool check_digital_port_conflicts(struct
intel_atomic_state *state)
}
static void
-intel_crtc_copy_uapi_to_hw_state_nomodeset(struct intel_crtc_state *crtc_state)
+intel_crtc_copy_uapi_to_hw_state_nomodeset(struct intel_atomic_state *state,
+ struct intel_crtc_state *crtc_state)
{
intel_crtc_copy_color_blobs(crtc_state);
}
static void
-intel_crtc_copy_uapi_to_hw_state(struct intel_crtc_state *crtc_state)
+intel_crtc_copy_uapi_to_hw_state(struct intel_atomic_state *state,
+struct intel_crtc_state *crtc_state)
{
crtc_state->hw.enable = crtc_state->uapi.enable;
crtc_state->hw.active = crtc_state->uapi.active;
@@ -13487,7 +13489,7 @@ intel_crtc_copy_uapi_to_hw_state(struct
intel_crtc_state *crtc_state)
crtc_state->hw.pipe_mode = crtc_state->hw.adjusted_mode =
crtc_state->uapi.adjusted_mode;
crtc_state->hw.scaling_filter = crtc_state->uapi.scaling_filter;
- intel_crtc_copy_uapi_to_hw_state_nomodeset(crtc_state);
+ intel_crtc_copy_uapi_to_hw_state_nomodeset(state, crtc_state);
}
static void intel_crtc_copy_hw_to_uapi_state(struct intel_crtc_state
*crtc_state)
@@ -13510,7 +13512,8 @@ static void intel_crtc_copy_hw_to_uapi_state(struct
intel_crtc_state *crtc_state
}
static int
-intel_crtc_prepare_cleared_state(struct intel_crtc_state *crtc_state)
+intel_crtc_prepare_cleared_state(struct intel_atomic_state *state,
+struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -13542,16 +13545,16 @@ intel_crtc_prepare_cleared_state(struct
intel_crtc_state *crtc_state)
memcpy(crtc_state, saved_state, sizeof(*crtc_state));
kfree(saved_state);
- intel_crtc_copy_uapi_to_hw_state(crtc_state);
+ intel_crtc_copy_uapi_to_hw_state(state, crtc_state);
return 0;
}
static int
-intel_modeset_pipe_config(struct intel_crtc_state *pipe_config)
+intel_modeset_pipe_config(struct intel_atomic_state *state,
+ struct intel_crtc_state *pipe_config)
{
struct drm_crtc *crtc = pipe_config->uapi.crtc;
- struct drm_atomic_state *state = pipe_config->uapi.state;
struct drm_i915_private *i915 = to_i915(pipe_config->uapi.crtc->dev);
struct drm_connector *connector;
struct drm_connector_state *connector_state;
@@ -13593,7 +13596,7 @@ intel_modeset_pipe_config(struct intel_crtc_state
*pipe_config)
&pipe_config->pipe_src_w,
&pipe_config->pipe_src_h);
- for_each_new_connector_in_state(state, connector, connector_state, i) {
+ for_each_new_connector_in_state(&state->base, connector,
connector_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(connector_state->best_encoder);
@@ -13631,7 +13634,7 @@ intel_modeset_pipe_config(struct intel_crtc_state
*pipe_config)
* adjust it according to limitations or connector properties, and also
* a chance to reject the mode entirely.
*/
- for_each_new_connector_in_state(state, connector, connector_state, i) {
+ for_each_new_connector_in_state(&state->base, connector,
connector_state, i)
[Intel-gfx] [PATCH v8 4/7] drm/i915: Add hw.pipe_mode to allow bigjoiner pipe/transcoder split
From: Maarten Lankhorst
With bigjoiner, there will be 2 pipes driving 2 halves of 1 transcoder,
because of this, we need a pipe_mode for various calculations, including
for example watermarks, plane clipping, etc.
v10:
* remove redundant pipe_mode assignment (Ville)
v9:
* pipe_mode in state dump nd state check (Ville)
v8:
* Add pipe_mode in readout in verify_crtc_state (Ville)
v7:
* Remove redundant comment (Ville)
* Just keep mode instead of pipe_mode (Ville)
v6:
* renaming in separate function, only pipe_mode here (Ville)
* Add description (Maarten)
v5:
* Rebase (Manasi)
v4:
* Manual rebase (Manasi)
v3:
* Change state to crtc_state, fix rebase err (Manasi)
v2:
* Manual Rebase (Manasi)
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
Reviewed-by: Animesh Manna
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 55 +-
.../drm/i915/display/intel_display_types.h| 11 ++-
drivers/gpu/drm/i915/intel_pm.c | 76 +--
3 files changed, 84 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1530faf143f5..367902691c2c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6167,18 +6167,16 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
static int skl_update_scaler_crtc(struct intel_crtc_state *crtc_state)
{
- const struct drm_display_mode *adjusted_mode =
- &crtc_state->hw.adjusted_mode;
+ const struct drm_display_mode *pipe_mode = &crtc_state->hw.pipe_mode;
int width, height;
if (crtc_state->pch_pfit.enabled) {
width = drm_rect_width(&crtc_state->pch_pfit.dst);
height = drm_rect_height(&crtc_state->pch_pfit.dst);
} else {
- width = adjusted_mode->crtc_hdisplay;
- height = adjusted_mode->crtc_vdisplay;
+ width = pipe_mode->crtc_hdisplay;
+ height = pipe_mode->crtc_vdisplay;
}
-
return skl_update_scaler(crtc_state, !crtc_state->hw.active,
SKL_CRTC_INDEX,
&crtc_state->scaler_state.scaler_id,
@@ -8192,7 +8190,7 @@ static bool intel_crtc_supports_double_wide(const struct
intel_crtc *crtc)
static u32 ilk_pipe_pixel_rate(const struct intel_crtc_state *crtc_state)
{
- u32 pixel_rate = crtc_state->hw.adjusted_mode.crtc_clock;
+ u32 pixel_rate = crtc_state->hw.pipe_mode.crtc_clock;
unsigned int pipe_w, pipe_h, pfit_w, pfit_h;
/*
@@ -8225,7 +8223,11 @@ static u32 ilk_pipe_pixel_rate(const struct
intel_crtc_state *crtc_state)
static void intel_encoder_get_config(struct intel_encoder *encoder,
struct intel_crtc_state *crtc_state)
{
+ struct drm_display_mode *pipe_mode = &crtc_state->hw.pipe_mode;
+
encoder->get_config(encoder, crtc_state);
+
+ *pipe_mode = crtc_state->hw.adjusted_mode;
}
static void intel_crtc_compute_pixel_rate(struct intel_crtc_state *crtc_state)
@@ -8235,7 +8237,7 @@ static void intel_crtc_compute_pixel_rate(struct
intel_crtc_state *crtc_state)
if (HAS_GMCH(dev_priv))
/* FIXME calculate proper pipe pixel rate for GMCH pfit */
crtc_state->pixel_rate =
- crtc_state->hw.adjusted_mode.crtc_clock;
+ crtc_state->hw.pipe_mode.crtc_clock;
else
crtc_state->pixel_rate =
ilk_pipe_pixel_rate(crtc_state);
@@ -8245,9 +8247,11 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
struct intel_crtc_state *pipe_config)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- const struct drm_display_mode *adjusted_mode =
&pipe_config->hw.adjusted_mode;
+ struct drm_display_mode *pipe_mode = &pipe_config->hw.pipe_mode;
int clock_limit = dev_priv->max_dotclk_freq;
+ *pipe_mode = pipe_config->hw.adjusted_mode;
+
if (INTEL_GEN(dev_priv) < 4) {
clock_limit = dev_priv->max_cdclk_freq * 9 / 10;
@@ -8256,16 +8260,16 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
* is > 90% of the (display) core speed.
*/
if (intel_crtc_supports_double_wide(crtc) &&
- adjusted_mode->crtc_clock > clock_limit) {
+ pipe_mode->crtc_clock > clock_limit) {
clock_limit = dev_priv->max_dotclk_freq;
pipe_config->double_wide = true;
}
}
- if (adjusted_mode->crtc_clock > clock_limit) {
+ if (pipe_mode->crtc_clock > clock_limit) {
drm_dbg_kms(&dev_priv->drm,
"requested pixel clock (%d kHz) too
[Intel-gfx] [PATCH v8 1/7] drm/i915/dp: Some reshuffling in mode_valid as prep for bigjoiner modes
No functional changes. This patch just moves some mode checks
around to prepare for adding bigjoiner related mode validation
Cc: Ville Syrjälä
Signed-off-by: Manasi Navare
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 3b0dbda5919a..ec8359f03aaf 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -721,6 +721,9 @@ intel_dp_mode_valid(struct drm_connector *connector,
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
return MODE_NO_DBLESCAN;
+ if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+ return MODE_H_ILLEGAL;
+
if (intel_dp_is_edp(intel_dp) && fixed_mode) {
if (mode->hdisplay > fixed_mode->hdisplay)
return MODE_PANEL;
@@ -731,6 +734,9 @@ intel_dp_mode_valid(struct drm_connector *connector,
target_clock = fixed_mode->clock;
}
+ if (mode->clock < 1)
+ return MODE_CLOCK_LOW;
+
max_link_clock = intel_dp_max_link_rate(intel_dp);
max_lanes = intel_dp_max_lane_count(intel_dp);
@@ -771,12 +777,6 @@ intel_dp_mode_valid(struct drm_connector *connector,
target_clock > max_dotclk)
return MODE_CLOCK_HIGH;
- if (mode->clock < 1)
- return MODE_CLOCK_LOW;
-
- if (mode->flags & DRM_MODE_FLAG_DBLCLK)
- return MODE_H_ILLEGAL;
-
status = intel_dp_mode_valid_downstream(intel_connector,
mode, target_clock);
if (status != MODE_OK)
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable atomics in L3 for gen9
We need to land this patch. The number of bugs we have piling up in Mesa gitlab related to this is getting a lot larger than I'd like. I've gone back and forth with various HW and SW people internally for countless e-mail threads and there is no other good workaround. Yes, the perf hit to atomics sucks but, fortunately, most games don't use them heavily enough for it to make a significant impact. We should just eat the perf hit and fix the hangs. Reviewed-by: Jason Ekstrand --Jason On Wed, Jul 24, 2019 at 3:02 PM Francisco Jerez wrote: > > Chris Wilson writes: > > > Quoting Francisco Jerez (2019-07-23 23:19:13) > >> Chris Wilson writes: > >> > >> > Quoting Tvrtko Ursulin (2019-07-22 12:41:36) > >> >> > >> >> On 20/07/2019 15:31, Chris Wilson wrote: > >> >> > Enabling atomic operations in L3 leads to unrecoverable GPU hangs, as > >> >> > the machine stops responding milliseconds after receipt of the reset > >> >> > request [GDRT]. By disabling the cached atomics, the hang do not occur > >> >> > and we presume the GPU would reset normally for similar hangs. > >> >> > > >> >> > Reported-by: Jason Ekstrand > >> >> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110998 > >> >> > Signed-off-by: Chris Wilson > >> >> > Cc: Jason Ekstrand > >> >> > Cc: Mika Kuoppala > >> >> > Cc: Tvrtko Ursulin > >> >> > --- > >> >> > Jason reports that Windows is not clearing L3SQCREG4:22 and does not > >> >> > suffer the same GPU hang so it is likely some other w/a that interacts > >> >> > badly. Fwiw, these 3 are the only registers I could find that mention > >> >> > atomic ops (and appear to be part of the same chain for memory > >> >> > access). > >> >> > >> >> Bit-toggling itself looks fine to me and matches what I could find in > >> >> the docs. (All three bits across three registers should be equal.) > >> >> > >> >> What I am curious about is what are the other consequences of disabling > >> >> L3 atomics? Performance drop somewhere? > >> > > >> > The test I have where it goes from dead to passing, that's a considerable > >> > performance improvement ;) > >> > > >> > I imagine not being able to use L3 for atomics is pretty dire, whether > >> > that > >> > has any impact, I have no clue. > >> > > >> > It is still very likely that we see this because we are doing something > >> > wrong elsewhere. > >> > >> This reminds me of f3fc4884ebe6ae649d3723be14b219230d3b7fd2 followed by > >> d351f6d94893f3ba98b1b20c5ef44c35fc1da124 due to the massive impact (of > >> the order of 20x IIRC) using the L3 turned out to have on the > >> performance of HDC atomics, on at least that platform. It seems > >> unfortunate that we're going to lose L3 atomics on Gen9 now, even though > >> it's only buffer atomics which are broken IIUC, and even though the > >> Windows driver is somehow getting away without disabling them. Some of > >> our setup must be wrong either in the kernel or in userspace... Are > >> these registers at least whitelisted so userspace can re-enable L3 > >> atomics once the problem is addressed? Wouldn't it be a more specific > >> workaround for userspace to simply use a non-L3-cacheable MOCS for > >> (rarely used) buffer surfaces, so it could benefit from L3 atomics > >> elsewhere? > > > > If it was the case that disabling L3 atomics was the only way to prevent > > the machine lockup under this scenario, then I think it is > > unquestionably the right thing to do, and we could not leave it to > > userspace to dtrt. We should never add non-context saved unsafe > > registers to the whitelist (if setting a register may cause data > > corruption or worse in another context/process, that is bad) despite our > > repeated transgressions. However, there's no evidence to say that it does > > prevent the machine lockup as it prevents the GPU hang that lead to the > > lockup on reset. > > > > Other than GPGPU requiring a flush around every sneeze, I did not see > > anything in the gen9 w/a list that seemed like a match. Nevertheless, I > > expect there is a more precise w/a than a blanket disable. > > -Chris > > Supposedly there is a more precise one (setting the surface state MOCS > to UC for buffer images), but it relies on userspace doing the right > thing for the machine not to lock up. There is a good chance that the > reason why L3 atomics hang on such buffers is ultimately under userspace > control, in which case we'll eventually have to undo the programming > done in this patch in order to re-enable L3 atomics once the problem is > addressed. That means that userspace will have the freedom to hang the > machine hard once again, which sounds really bad, but it's no real news > for us (*cough* HSW *cough*), and it might be the only way to match the > performance of the Windows driver. > > What can we do here? Add an i915 option to enable performance features > that can lead to the system hanging hard under malicious (or > incompetent) userspace programming? Probably only the user can tell > whether
Re: [Intel-gfx] [CI 2/2] drm/i915/gem: Pull phys pread/pwrite implementations to the backend
>-Original Message-
>From: Intel-gfx On Behalf Of Chris
>Wilson
>Sent: Thursday, November 5, 2020 10:50 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [CI 2/2] drm/i915/gem: Pull phys pread/pwrite
>implementations to the backend
>
>Move the specialised interactions with the physical GEM object from the
>pread/pwrite ioctl handler into the phys backend.
>
>Signed-off-by: Chris Wilson
>Reviewed-by: Matthew Auld
>---
> drivers/gpu/drm/i915/gem/i915_gem_phys.c | 55
>
> drivers/gpu/drm/i915/i915_gem.c | 26 ---
> 2 files changed, 55 insertions(+), 26 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
>b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
>index 28147aab47b9..3a4dfe2ef1da 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
>@@ -134,6 +134,58 @@ i915_gem_object_put_pages_phys(struct
>drm_i915_gem_object *obj,
> vaddr, dma);
> }
>
>+static int
>+phys_pwrite(struct drm_i915_gem_object *obj,
>+ const struct drm_i915_gem_pwrite *args)
>+{
>+ void *vaddr = sg_page(obj->mm.pages->sgl) + args->offset;
>+ char __user *user_data = u64_to_user_ptr(args->data_ptr);
>+ int err;
>+
>+ err = i915_gem_object_wait(obj,
>+ I915_WAIT_INTERRUPTIBLE |
>+ I915_WAIT_ALL,
>+ MAX_SCHEDULE_TIMEOUT);
>+ if (err)
>+ return err;
>+
>+ /*
>+ * We manually control the domain here and pretend that it
>+ * remains coherent i.e. in the GTT domain, like shmem_pwrite.
>+ */
>+ i915_gem_object_invalidate_frontbuffer(obj, ORIGIN_CPU);
>+
>+ if (copy_from_user(vaddr, user_data, args->size))
>+ return -EFAULT;
>+
>+ drm_clflush_virt_range(vaddr, args->size);
>+ intel_gt_chipset_flush(&to_i915(obj->base.dev)->gt);
>+
>+ i915_gem_object_flush_frontbuffer(obj, ORIGIN_CPU);
>+ return 0;
So the original code path (through pwrite_ioctl()) includes a pin/unpin.
That doesn't need to be done here?
Thanks,
Mike
>+}
>+
>+static int
>+phys_pread(struct drm_i915_gem_object *obj,
>+ const struct drm_i915_gem_pread *args)
>+{
>+ void *vaddr = sg_page(obj->mm.pages->sgl) + args->offset;
>+ char __user *user_data = u64_to_user_ptr(args->data_ptr);
>+ int err;
>+
>+ err = i915_gem_object_wait(obj,
>+ I915_WAIT_INTERRUPTIBLE,
>+ MAX_SCHEDULE_TIMEOUT);
>+ if (err)
>+ return err;
>+
>+ drm_clflush_virt_range(vaddr, args->size);
>+ if (copy_to_user(user_data, vaddr, args->size))
>+ return -EFAULT;
>+
>+ return 0;
>+}
>+
> static void phys_release(struct drm_i915_gem_object *obj)
> {
> fput(obj->base.filp);
>@@ -144,6 +196,9 @@ static const struct drm_i915_gem_object_ops
>i915_gem_phys_ops = {
> .get_pages = i915_gem_object_get_pages_phys,
> .put_pages = i915_gem_object_put_pages_phys,
>
>+ .pread = phys_pread,
>+ .pwrite = phys_pwrite,
>+
> .release = phys_release,
> };
>
>diff --git a/drivers/gpu/drm/i915/i915_gem.c
>b/drivers/gpu/drm/i915/i915_gem.c
>index d58fe1ddc3e1..58276694c848 100644
>--- a/drivers/gpu/drm/i915/i915_gem.c
>+++ b/drivers/gpu/drm/i915/i915_gem.c
>@@ -179,30 +179,6 @@ int i915_gem_object_unbind(struct
>drm_i915_gem_object *obj,
> return ret;
> }
>
>-static int
>-i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
>- struct drm_i915_gem_pwrite *args,
>- struct drm_file *file)
>-{
>- void *vaddr = sg_page(obj->mm.pages->sgl) + args->offset;
>- char __user *user_data = u64_to_user_ptr(args->data_ptr);
>-
>- /*
>- * We manually control the domain here and pretend that it
>- * remains coherent i.e. in the GTT domain, like shmem_pwrite.
>- */
>- i915_gem_object_invalidate_frontbuffer(obj, ORIGIN_CPU);
>-
>- if (copy_from_user(vaddr, user_data, args->size))
>- return -EFAULT;
>-
>- drm_clflush_virt_range(vaddr, args->size);
>- intel_gt_chipset_flush(&to_i915(obj->base.dev)->gt);
>-
>- i915_gem_object_flush_frontbuffer(obj, ORIGIN_CPU);
>- return 0;
>-}
>-
> static int
> i915_gem_create(struct drm_file *file,
> struct intel_memory_region *mr,
>@@ -872,8 +848,6 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void
>*data,
> if (ret == -EFAULT || ret == -ENOSPC) {
> if (i915_gem_object_has_struct_page(obj))
> ret = i915_gem_shmem_pwrite(obj, args);
>- else
>- ret = i915_gem_phys_pwrite(obj, args, file);
> }
>
> i915_gem_object_unpin_pages(obj);
>--
>2.20.1
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/region: fix order when adding blocks
== Series Details ==
Series: drm/i915/region: fix order when adding blocks
URL : https://patchwork.freedesktop.org/series/83641/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9295_full -> Patchwork_18873_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18873_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18873_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_18873_full:
### IGT changes ###
Possible regressions
* igt@gem_partial_pwrite_pread@reads-display:
- shard-snb: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/shard-snb4/igt@gem_partial_pwrite_pr...@reads-display.html
* igt@kms_big_fb@x-tiled-64bpp-rotate-180:
- shard-snb: NOTRUN -> [FAIL][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/shard-snb4/igt@kms_big...@x-tiled-64bpp-rotate-180.html
* igt@kms_flip@blocking-wf_vblank@a-vga1:
- shard-hsw: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9295/shard-hsw5/igt@kms_flip@blocking-wf_vbl...@a-vga1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/shard-hsw1/igt@kms_flip@blocking-wf_vbl...@a-vga1.html
* igt@perf_pmu@module-unload:
- shard-hsw: NOTRUN -> [INCOMPLETE][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/shard-hsw6/igt@perf_...@module-unload.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_pwrite@basic-exhaustion}:
- shard-hsw: NOTRUN -> [WARN][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/shard-hsw6/igt@gem_pwr...@basic-exhaustion.html
- shard-glk: NOTRUN -> [WARN][7]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/shard-glk4/igt@gem_pwr...@basic-exhaustion.html
New tests
-
New tests have been introduced between CI_DRM_9295_full and
Patchwork_18873_full:
### New CI tests (1) ###
* boot:
- Statuses : 199 pass(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_18873_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@kms:
- shard-glk: [PASS][8] -> [INCOMPLETE][9] ([i915#2244])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9295/shard-glk8/igt@gem_...@kms.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/shard-glk3/igt@gem_...@kms.html
- shard-snb: [PASS][10] -> [DMESG-WARN][11] ([i915#1982])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9295/shard-snb6/igt@gem_...@kms.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/shard-snb5/igt@gem_...@kms.html
* igt@gem_exec_whisper@basic-queues-priority:
- shard-glk: [PASS][12] -> [DMESG-WARN][13] ([i915#118] /
[i915#95])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9295/shard-glk7/igt@gem_exec_whis...@basic-queues-priority.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/shard-glk3/igt@gem_exec_whis...@basic-queues-priority.html
* igt@gem_exec_whisper@basic-sync-all:
- shard-hsw: [PASS][14] -> [FAIL][15] ([i915#1888])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9295/shard-hsw4/igt@gem_exec_whis...@basic-sync-all.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/shard-hsw7/igt@gem_exec_whis...@basic-sync-all.html
* igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][16] -> [SKIP][17] ([i915#2190])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9295/shard-tglb7/igt@gem_huc_c...@huc-copy.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/shard-tglb6/igt@gem_huc_c...@huc-copy.html
* igt@kms_cursor_crc@pipe-b-cursor-128x42-random:
- shard-skl: [PASS][18] -> [FAIL][19] ([i915#54]) +5 similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9295/shard-skl9/igt@kms_cursor_...@pipe-b-cursor-128x42-random.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/shard-skl10/igt@kms_cursor_...@pipe-b-cursor-128x42-random.html
* igt@kms_cursor_edge_walk@pipe-c-256x256-right-edge:
- shard-glk: [PASS][20] -> [DMESG-WARN][21] ([i915#1982]) +1
similar issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9295/shard-glk2/igt@kms_cursor_edge_w...@pipe-c-256x256-right-edge.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/shard-glk9/ig
[Intel-gfx] [PATCH] drm/i915/selftests: Improve granularity for mocs reset checks
Allow us to validate mocs configurations after reset if we have either
engine or global reset.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_mocs.c | 40 +
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_mocs.c
b/drivers/gpu/drm/i915/gt/selftest_mocs.c
index b25eba50c88e..21dcd91cbd62 100644
--- a/drivers/gpu/drm/i915/gt/selftest_mocs.c
+++ b/drivers/gpu/drm/i915/gt/selftest_mocs.c
@@ -361,29 +361,34 @@ static int active_engine_reset(struct intel_context *ce,
static int __live_mocs_reset(struct live_mocs *mocs,
struct intel_context *ce)
{
+ struct intel_gt *gt = ce->engine->gt;
int err;
- err = intel_engine_reset(ce->engine, "mocs");
- if (err)
- return err;
+ if (intel_has_reset_engine(gt)) {
+ err = intel_engine_reset(ce->engine, "mocs");
+ if (err)
+ return err;
- err = check_mocs_engine(mocs, ce);
- if (err)
- return err;
+ err = check_mocs_engine(mocs, ce);
+ if (err)
+ return err;
- err = active_engine_reset(ce, "mocs");
- if (err)
- return err;
+ err = active_engine_reset(ce, "mocs");
+ if (err)
+ return err;
- err = check_mocs_engine(mocs, ce);
- if (err)
- return err;
+ err = check_mocs_engine(mocs, ce);
+ if (err)
+ return err;
+ }
- intel_gt_reset(ce->engine->gt, ce->engine->mask, "mocs");
+ if (intel_has_gpu_reset(gt)) {
+ intel_gt_reset(gt, ce->engine->mask, "mocs");
- err = check_mocs_engine(mocs, ce);
- if (err)
- return err;
+ err = check_mocs_engine(mocs, ce);
+ if (err)
+ return err;
+ }
return 0;
}
@@ -398,9 +403,6 @@ static int live_mocs_reset(void *arg)
/* Check the mocs setup is retained over per-engine and global resets */
- if (!intel_has_reset_engine(gt))
- return 0;
-
err = live_mocs_init(&mocs, gt);
if (err)
return err;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/region: fix order when adding blocks
== Series Details == Series: drm/i915/region: fix order when adding blocks URL : https://patchwork.freedesktop.org/series/83641/ State : success == Summary == CI Bug Log - changes from CI_DRM_9295 -> Patchwork_18873 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/index.html New tests - New tests have been introduced between CI_DRM_9295 and Patchwork_18873: ### New CI tests (1) ### * boot: - Statuses : 39 pass(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_18873 that come from known issues: ### IGT changes ### Issues hit * igt@core_hotunplug@unbind-rebind: - fi-tgl-u2: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9295/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html * igt@i915_getparams_basic@basic-subslice-total: - fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9295/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html * igt@i915_module_load@reload: - fi-bsw-kefka: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9295/fi-bsw-kefka/igt@i915_module_l...@reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/fi-bsw-kefka/igt@i915_module_l...@reload.html * igt@i915_selftest@live@active: - fi-bsw-nick:[PASS][7] -> [DMESG-FAIL][8] ([i915#541]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9295/fi-bsw-nick/igt@i915_selftest@l...@active.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/fi-bsw-nick/igt@i915_selftest@l...@active.html Possible fixes * igt@kms_busy@basic@flip: - fi-kbl-soraka: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9295/fi-kbl-soraka/igt@kms_busy@ba...@flip.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/fi-kbl-soraka/igt@kms_busy@ba...@flip.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-byt-j1900: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9295/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@vgem_basic@setversion: - fi-tgl-y: [DMESG-WARN][13] ([i915#402]) -> [PASS][14] +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9295/fi-tgl-y/igt@vgem_ba...@setversion.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/fi-tgl-y/igt@vgem_ba...@setversion.html Warnings * igt@i915_pm_rpm@basic-pci-d3-state: - fi-tgl-y: [DMESG-WARN][15] ([i915#2411]) -> [DMESG-WARN][16] ([i915#1982] / [i915#2411]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9295/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541 Participating hosts (43 -> 39) -- Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u Build changes - * Linux: CI_DRM_9295 -> Patchwork_18873 CI-20190529: 20190529 CI_DRM_9295: f6794c7c0df8fa828266593950865196dbd8b645 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5839: 2dbd64a6301e36eb432bc50ad7021fabaeebd1f4 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_18873: f0922274d9736e9341f98c10e15d8c75749934e2 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == f0922274d973 drm/i915/region: fix order when adding blocks == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18873/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/region: fix order when adding blocks
Quoting Chris Wilson (2020-11-09 11:28:04) > Quoting Matthew Auld (2020-11-09 11:12:49) > > When performing an allocation we try split it down into the largest > > possible power-of-two blocks/pages-sizes, and for the common case we > > expect to allocate the blocks in descending order. This also naturally > > fits with our GTT alignment tricks(including the hugepages selftest), > > where we sometimes try to align to the largest possible GTT page-size > > for the allocation, in the hope that translates to bigger GTT > > page-sizes. Currently, we seem to incorrectly add the blocks in the > > opposite order, which is definitely not the intended behaviour. > > Right, so currently we end up with small -> large blocks, and you want > to change it so that we use large -> small blocks, because we want to > keep things aligned for as long as possible (if we start small, we > immediately spoil the alignment provided for us). Reviewed-by: Chris Wilson > How can we test this? Create a 2MiB + 4KiB object and ask if > page_sizes.gtt has a 2MiB? I don't think it can be directly observed > from userspace, right? Is it possible to generalise the characteristic > we expect and prevent future errors? But we should try and capture some testing :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/region: fix order when adding blocks
Quoting Matthew Auld (2020-11-09 11:12:49) > When performing an allocation we try split it down into the largest > possible power-of-two blocks/pages-sizes, and for the common case we > expect to allocate the blocks in descending order. This also naturally > fits with our GTT alignment tricks(including the hugepages selftest), > where we sometimes try to align to the largest possible GTT page-size > for the allocation, in the hope that translates to bigger GTT > page-sizes. Currently, we seem to incorrectly add the blocks in the > opposite order, which is definitely not the intended behaviour. Right, so currently we end up with small -> large blocks, and you want to change it so that we use large -> small blocks, because we want to keep things aligned for as long as possible (if we start small, we immediately spoil the alignment provided for us). How can we test this? Create a 2MiB + 4KiB object and ask if page_sizes.gtt has a 2MiB? I don't think it can be directly observed from userspace, right? Is it possible to generalise the characteristic we expect and prevent future errors? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for User friendly lsgpu default output
== Series Details == Series: User friendly lsgpu default output URL : https://patchwork.freedesktop.org/series/83640/ State : failure == Summary == Applying: intel_gpu_top: User friendly device listing error: sha1 information is lacking or useless (lib/igt_device_scan.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 intel_gpu_top: User friendly device listing When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/region: fix order when adding blocks
When performing an allocation we try split it down into the largest possible power-of-two blocks/pages-sizes, and for the common case we expect to allocate the blocks in descending order. This also naturally fits with our GTT alignment tricks(including the hugepages selftest), where we sometimes try to align to the largest possible GTT page-size for the allocation, in the hope that translates to bigger GTT page-sizes. Currently, we seem to incorrectly add the blocks in the opposite order, which is definitely not the intended behaviour. Reported-by: CQ Tang Signed-off-by: Matthew Auld Cc: Chris Wilson Cc: CQ Tang --- drivers/gpu/drm/i915/intel_memory_region.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_memory_region.c b/drivers/gpu/drm/i915/intel_memory_region.c index 180e1078ef7c..b326993a1026 100644 --- a/drivers/gpu/drm/i915/intel_memory_region.c +++ b/drivers/gpu/drm/i915/intel_memory_region.c @@ -114,7 +114,7 @@ __intel_memory_region_get_pages_buddy(struct intel_memory_region *mem, n_pages -= BIT(order); block->private = mem; - list_add(&block->link, blocks); + list_add_tail(&block->link, blocks); if (!n_pages) break; -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 1/3] intel_gpu_top: User friendly device listing
From: Tvrtko Ursulin
Adding a new device selection print type suitable for user-facing
use cases like intel_gpu_top -L and later lsgpu.
Instead of:
sys:/sys/devices/pci:00/:00:02.0/drm/card0
subsystem : drm
drm card: /dev/dri/card0
parent : sys:/sys/devices/pci:00/:00:02.0
sys:/sys/devices/pci:00/:00:02.0/drm/renderD128
subsystem : drm
drm render : /dev/dri/renderD128
parent : sys:/sys/devices/pci:00/:00:02.0
sys:/sys/devices/pci:00/:00:02.0
subsystem : pci
drm card: /dev/dri/card0
drm render : /dev/dri/renderD128
vendor : 8086
device : 193B
New format looks like:
card0 8086:193Bdrm:/dev/dri/card0
└─renderD128 drm:/dev/dri/renderD128
Advantages are more compact, more readable, one entry per GPU, shorter
string to copy and paste to intel_gpu_top -d, or respective usage.
Signed-off-by: Tvrtko Ursulin
Cc: Petri Latvala
Cc: Zbigniew Kempczyński
---
lib/igt_device_scan.c | 109 +-
lib/igt_device_scan.h | 1 +
tools/intel_gpu_top.c | 3 +-
3 files changed, 100 insertions(+), 13 deletions(-)
diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
index c581a31ae55e..e66ccdc25aeb 100644
--- a/lib/igt_device_scan.c
+++ b/lib/igt_device_scan.c
@@ -735,18 +735,26 @@ static inline void _pr_simple2(const char *k, const char
*v1, const char *v2)
printf("%-16s: %s:%s\n", k, v1, v2);
}
-static void igt_devs_print_simple(struct igt_list_head *view)
+static bool __check_empty(struct igt_list_head *view)
{
- struct igt_device *dev;
-
if (!view)
- return;
+ return true;
if (igt_list_empty(view)) {
printf("No GPU devices found\n");
- return;
+ return true;
}
+ return false;
+}
+
+static void igt_devs_print_simple(struct igt_list_head *view)
+{
+ struct igt_device *dev;
+
+ if (__check_empty(view))
+ return;
+
igt_list_for_each_entry(dev, view, link) {
printf("sys:%s\n", dev->syspath);
if (dev->subsystem)
@@ -768,6 +776,89 @@ static void igt_devs_print_simple(struct igt_list_head
*view)
}
}
+static struct igt_device *
+__find_pci(struct igt_list_head *view, const char *drm)
+{
+ struct igt_device *dev;
+
+ igt_list_for_each_entry(dev, view, link) {
+ if (!is_pci_subsystem(dev) || !dev->drm_card)
+ continue;
+
+ if (!strcmp(dev->drm_card, drm))
+ return dev;
+ }
+
+ return NULL;
+}
+
+static void igt_devs_print_user(struct igt_list_head *view)
+{
+ struct igt_device *dev;
+
+ if (__check_empty(view))
+ return;
+
+ igt_list_for_each_entry(dev, view, link) {
+ unsigned int i, num_children;
+ struct igt_device *pci_dev;
+ struct igt_device *dev2;
+ char filter[64];
+ char *drm_name;
+ int ret;
+
+ if (!is_drm_subsystem(dev))
+ continue;
+ if (!dev->drm_card || dev->drm_render)
+ continue;
+
+ drm_name = rindex(dev->drm_card, '/');
+ if (!drm_name || !*++drm_name)
+ continue;
+
+ ret = snprintf(filter, sizeof(filter), "drm:%s", dev->drm_card);
+ igt_assert(ret < sizeof(filter));
+
+ pci_dev = __find_pci(view, dev->drm_card);
+ if (pci_dev)
+ printf("%-24s%4s:%4s%s\n",
+ drm_name, pci_dev->vendor, pci_dev->device,
+ filter);
+ else
+ printf("%-24s %s\n", drm_name, filter);
+
+ num_children = 0;
+ igt_list_for_each_entry(dev2, view, link) {
+ if (!is_drm_subsystem(dev2) || !dev2->drm_render)
+ continue;
+ if (strcmp(dev2->parent->syspath, dev->parent->syspath))
+ continue;
+
+ num_children++;
+ }
+
+ i = 0;
+ igt_list_for_each_entry(dev2, view, link) {
+ if (!is_drm_subsystem(dev2) || !dev2->drm_render)
+ continue;
+ if (strcmp(dev2->parent->syspath, dev->parent->syspath))
+ continue;
+
+ drm_name = rindex(dev2->drm_render, '/');
+ if (!drm_name || !*++drm_name)
+ continue;
+
+ ret = snprintf(filter, sizeof(filter), "drm:%s",
+
[Intel-gfx] [RFC 0/3] User friendly lsgpu default output
From: Tvrtko Ursulin As per individual changelogs end result is: $ lsgpu card0 8086:193Bdrm:/dev/dri/card0 └─renderD128 drm:/dev/dri/renderD128 $ lsgpu --sysfs card0 8086:193B sys:/sys/devices/pci:00/:00:02.0/drm/card0 └─renderD128 sys:/sys/devices/pci:00/:00:02.0/drm/renderD128 $ lsgpu --pci card0 8086:193B pci:/sys/devices/pci:00/:00:02.0 └─renderD128 Tvrtko Ursulin (3): intel_gpu_top: User friendly device listing lsgpu: User friendly device listing lsgpu: Add filter type print-out selection lib/igt_device_scan.c | 154 +- lib/igt_device_scan.h | 16 - tools/intel_gpu_top.c | 7 +- tools/lsgpu.c | 38 +-- 4 files changed, 188 insertions(+), 27 deletions(-) -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 2/3] lsgpu: User friendly device listing
From: Tvrtko Ursulin
New default user frindly device listing mode which replaces:
sys:/sys/devices/pci:00/:00:02.0/drm/card0
subsystem : drm
drm card: /dev/dri/card0
parent : sys:/sys/devices/pci:00/:00:02.0
sys:/sys/devices/pci:00/:00:02.0/drm/renderD128
subsystem : drm
drm render : /dev/dri/renderD128
parent : sys:/sys/devices/pci:00/:00:02.0
sys:/sys/devices/pci:00/:00:02.0
subsystem : pci
drm card: /dev/dri/card0
drm render : /dev/dri/renderD128
vendor : 8086
device : 193B
With:
card0 8086:193Bdrm:/dev/dri/card0
└─renderD128 drm:/dev/dri/renderD128
Advantages are more compact, more readable, one entry per GPU.
Legacy format can be chose using the -s / --print-simple command line
switches.
Signed-off-by: Tvrtko Ursulin
Cc: Petri Latvala
Cc: Zbigniew Kempczyński
---
tools/lsgpu.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/tools/lsgpu.c b/tools/lsgpu.c
index 2541d1c24e66..3b234b73361a 100644
--- a/tools/lsgpu.c
+++ b/tools/lsgpu.c
@@ -70,6 +70,7 @@
*/
enum {
+ OPT_PRINT_SIMPLE = 's',
OPT_PRINT_DETAIL = 'p',
OPT_LIST_VENDORS = 'v',
OPT_LIST_FILTERS = 'l',
@@ -85,6 +86,7 @@ static char *igt_device;
static const char *usage_str =
"usage: lsgpu [options]\n\n"
"Options:\n"
+ " -s, --print-simple Print simple (legacy) device details\n"
" -p, --print-details Print devices with details\n"
" -v, --list-vendors List recognized vendors\n"
" -l, --list-filter-types List registered device filters types\n"
@@ -151,6 +153,7 @@ static char *get_device_from_rc(void)
int main(int argc, char *argv[])
{
static struct option long_options[] = {
+ {"print-simple", no_argument, NULL,
OPT_PRINT_SIMPLE},
{"print-detail", no_argument, NULL,
OPT_PRINT_DETAIL},
{"list-vendors", no_argument, NULL,
OPT_LIST_VENDORS},
{"list-filter-types", no_argument, NULL,
OPT_LIST_FILTERS},
@@ -160,12 +163,15 @@ int main(int argc, char *argv[])
};
int c, index = 0;
char *env_device = NULL, *opt_device = NULL, *rc_device = NULL;
- enum igt_devices_print_type printtype = IGT_PRINT_SIMPLE;
+ enum igt_devices_print_type printtype = IGT_PRINT_USER;
- while ((c = getopt_long(argc, argv, "pvld:h",
+ while ((c = getopt_long(argc, argv, "spvld:h",
long_options, &index)) != -1) {
switch(c) {
+ case OPT_PRINT_SIMPLE:
+ printtype = IGT_PRINT_SIMPLE;
+ break;
case OPT_PRINT_DETAIL:
printtype = IGT_PRINT_DETAIL;
break;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 3/3] lsgpu: Add filter type print-out selection
From: Tvrtko Ursulin
In the previous patch we switched the lsgpu output to a short and user
friendly format but some users will need a shorthand for getting other
types of device selection filters than the defaut drm.
Add some command line switches to enable this:
$ lsgpu
card0 8086:193Bdrm:/dev/dri/card0
└─renderD128 drm:/dev/dri/renderD128
$ lsgpu --sysfs
card0 8086:193B
sys:/sys/devices/pci:00/:00:02.0/drm/card0
└─renderD128
sys:/sys/devices/pci:00/:00:02.0/drm/renderD128
$ lsgpu --pci
card0 8086:193Bpci:/sys/devices/pci:00/:00:02.0
└─renderD128
Signed-off-by: Tvrtko Ursulin
Suggested-by: Zbigniew Kempczyński
Cc: Petri Latvala
---
lib/igt_device_scan.c | 69 ---
lib/igt_device_scan.h | 15 --
tools/intel_gpu_top.c | 6 +++-
tools/lsgpu.c | 32 +++-
4 files changed, 95 insertions(+), 27 deletions(-)
diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
index e66ccdc25aeb..54b565b68524 100644
--- a/lib/igt_device_scan.c
+++ b/lib/igt_device_scan.c
@@ -748,7 +748,9 @@ static bool __check_empty(struct igt_list_head *view)
return false;
}
-static void igt_devs_print_simple(struct igt_list_head *view)
+static void
+igt_devs_print_simple(struct igt_list_head *view,
+ const struct igt_devices_print_format *fmt)
{
struct igt_device *dev;
@@ -792,7 +794,36 @@ __find_pci(struct igt_list_head *view, const char *drm)
return NULL;
}
-static void igt_devs_print_user(struct igt_list_head *view)
+static void __print_filter(char *buf, int len,
+ const struct igt_devices_print_format *fmt,
+ struct igt_device *dev,
+ bool render)
+{
+ int ret;
+
+ switch (fmt->option) {
+ case IGT_PRINT_DRM:
+ ret = snprintf(buf, len, "drm:%s",
+ render ? dev->drm_render : dev->drm_card);
+ igt_assert(ret < len);
+ break;
+ case IGT_PRINT_SYSFS:
+ ret = snprintf(buf, len, "sys:%s", dev->syspath);
+ igt_assert(ret < len);
+ break;
+ case IGT_PRINT_PCI:
+ if (!render) {
+ ret = snprintf(buf, len, "pci:%s",
+ dev->parent->syspath);
+ igt_assert(ret < len);
+ }
+ break;
+ };
+}
+
+static void
+igt_devs_print_user(struct igt_list_head *view,
+ const struct igt_devices_print_format *fmt)
{
struct igt_device *dev;
@@ -805,7 +836,6 @@ static void igt_devs_print_user(struct igt_list_head *view)
struct igt_device *dev2;
char filter[64];
char *drm_name;
- int ret;
if (!is_drm_subsystem(dev))
continue;
@@ -816,8 +846,7 @@ static void igt_devs_print_user(struct igt_list_head *view)
if (!drm_name || !*++drm_name)
continue;
- ret = snprintf(filter, sizeof(filter), "drm:%s", dev->drm_card);
- igt_assert(ret < sizeof(filter));
+ __print_filter(filter, sizeof(filter), fmt, dev, false);
pci_dev = __find_pci(view, dev->drm_card);
if (pci_dev)
@@ -848,13 +877,15 @@ static void igt_devs_print_user(struct igt_list_head
*view)
if (!drm_name || !*++drm_name)
continue;
- ret = snprintf(filter, sizeof(filter), "drm:%s",
- dev2->drm_render);
- igt_assert(ret < sizeof(filter));
-
- printf("%s%-22s %s\n",
- (++i == num_children) ? "└─" : "├─",
- drm_name, filter);
+ printf("%s%-22s",
+ (++i == num_children) ? "└─" : "├─", drm_name);
+ if (fmt->option != IGT_PRINT_PCI) {
+ __print_filter(filter, sizeof(filter), fmt,
+ dev2, true);
+ printf(" %s\n", filter);
+ } else {
+ printf("\n");
+ }
}
}
}
@@ -879,7 +910,10 @@ static void print_ht(GHashTable *ht)
g_list_free(keys);
}
-static void igt_devs_print_detail(struct igt_list_head *view)
+static void
+igt_devs_print_detail(struct igt_list_head *view,
+ const struct igt_devices_print_format *fmt)
+
{
struct igt_device *dev;
@@ -903,7 +937,8 @@ static void igt_devs_print_detail(struct igt_list_head
*view)
}
[Intel-gfx] 4.19-stable: Re: [PATCH 2/3] drm/i915: Break up error capture compression loops with cond_resched()
Hi! > As the error capture will compress user buffers as directed to by the > user, it can take an arbitrary amount of time and space. Break up the > compression loops with a call to cond_resched(), that will allow other > processes to schedule (avoiding the soft lockups) and also serve as a > warning should we try to make this loop atomic in the future. > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > Cc: sta...@vger.kernel.org > Reviewed-by: Mika Kuoppala This was queued for 4.19-stable, but is very likely wrong. > @@ -397,6 +399,7 @@ static int compress_page(struct i915_vma_compress *c, > if (!(wc && i915_memcpy_from_wc(ptr, src, PAGE_SIZE))) > memcpy(ptr, src, PAGE_SIZE); > dst->pages[dst->page_count++] = ptr; > + cond_resched(); > > return 0; > } 4.19 compress_page begins with static int compress_page(struct compress *c, ... page = __get_free_page(GFP_ATOMIC | __GFP_NOWARN); and likely may not sleep. That changed with commit a42f45a2a85998453078, but that one is not present in 4.19.. I believe we don't need this in stable: dumping of error file will not take so long to trigger softlockup detectors... and if userland access blocked, we would be able to reschedule, anyway. Best regards, Pavel -- http://www.livejournal.com/~pavelmachek signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drm/i915/display: Do not reset display when there is none
On Fri, 06 Nov 2020, Lucas De Marchi wrote: > From: José Roberto de Souza > > Display is always disabled and enabled when resetting any engine, but if > there is no display it should not do anything with display and only > reset the needed engines. > > Cc: Jani Nikula > Signed-off-by: José Roberto de Souza > Signed-off-by: Lucas De Marchi Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/i915/display/intel_display.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index ab04c89cdf05..b6a9d41a043e 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -4958,6 +4958,9 @@ void intel_display_prepare_reset(struct > drm_i915_private *dev_priv) > struct drm_atomic_state *state; > int ret; > > + if (!HAS_DISPLAY(dev_priv)) > + return; > + > /* reset doesn't touch the display */ > if (!dev_priv->params.force_reset_modeset_test && > !gpu_reset_clobbers_display(dev_priv)) > @@ -5018,6 +5021,9 @@ void intel_display_finish_reset(struct drm_i915_private > *dev_priv) > struct drm_atomic_state *state; > int ret; > > + if (!HAS_DISPLAY(dev_priv)) > + return; > + > /* reset doesn't touch the display */ > if (!test_bit(I915_RESET_MODESET, &dev_priv->gt.reset.flags)) > return; -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/8] drm/i915/display: add namespace to intel_finish_reset
On Fri, 06 Nov 2020, Lucas De Marchi wrote:
> Rename intel_finish_reset to intel_display_finish_reset, so it's clear
> from gt/ that we are calling out the display code.
Reviewed-by: Jani Nikula
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> drivers/gpu/drm/i915/display/intel_display.h | 2 +-
> drivers/gpu/drm/i915/gt/intel_reset.c| 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 4050bc60f632..ab04c89cdf05 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5011,7 +5011,7 @@ void intel_display_prepare_reset(struct
> drm_i915_private *dev_priv)
> state->acquire_ctx = ctx;
> }
>
> -void intel_finish_reset(struct drm_i915_private *dev_priv)
> +void intel_display_finish_reset(struct drm_i915_private *dev_priv)
> {
> struct drm_device *dev = &dev_priv->drm;
> struct drm_modeset_acquire_ctx *ctx = &dev_priv->reset_ctx;
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index 30960cc8b8a6..a988f9518ece 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -591,7 +591,7 @@ int lpt_get_iclkip(struct drm_i915_private *dev_priv);
> bool intel_fuzzy_clock_check(int clock1, int clock2);
>
> void intel_display_prepare_reset(struct drm_i915_private *dev_priv);
> -void intel_finish_reset(struct drm_i915_private *dev_priv);
> +void intel_display_finish_reset(struct drm_i915_private *dev_priv);
> void intel_dp_get_m_n(struct intel_crtc *crtc,
> struct intel_crtc_state *pipe_config);
> void intel_dp_set_m_n(const struct intel_crtc_state *crtc_state,
> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
> b/drivers/gpu/drm/i915/gt/intel_reset.c
> index d71bad8c07b7..6b07ff5249f5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> @@ -1198,7 +1198,7 @@ static void intel_gt_reset_global(struct intel_gt *gt,
>
> intel_gt_reset(gt, engine_mask, reason);
>
> - intel_finish_reset(gt->i915);
> + intel_display_finish_reset(gt->i915);
> }
>
> if (!test_bit(I915_WEDGED, >->reset.flags))
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915/display: add namespace to intel_prepare_reset
On Fri, 06 Nov 2020, Lucas De Marchi wrote:
> Rename intel_prepare_reset to intel_display_prepare_reset, so it's clear
> from gt/ that we are calling out the display code.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> drivers/gpu/drm/i915/display/intel_display.h | 2 +-
> drivers/gpu/drm/i915/gt/intel_reset.c| 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 6faca1e739c8..4050bc60f632 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4951,7 +4951,7 @@ static bool gpu_reset_clobbers_display(struct
> drm_i915_private *dev_priv)
> intel_has_gpu_reset(&dev_priv->gt));
> }
>
> -void intel_prepare_reset(struct drm_i915_private *dev_priv)
> +void intel_display_prepare_reset(struct drm_i915_private *dev_priv)
> {
> struct drm_device *dev = &dev_priv->drm;
> struct drm_modeset_acquire_ctx *ctx = &dev_priv->reset_ctx;
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index be774f216065..30960cc8b8a6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -590,7 +590,7 @@ void vlv_force_pll_off(struct drm_i915_private *dev_priv,
> enum pipe pipe);
> int lpt_get_iclkip(struct drm_i915_private *dev_priv);
> bool intel_fuzzy_clock_check(int clock1, int clock2);
>
> -void intel_prepare_reset(struct drm_i915_private *dev_priv);
> +void intel_display_prepare_reset(struct drm_i915_private *dev_priv);
> void intel_finish_reset(struct drm_i915_private *dev_priv);
> void intel_dp_get_m_n(struct intel_crtc *crtc,
> struct intel_crtc_state *pipe_config);
> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
> b/drivers/gpu/drm/i915/gt/intel_reset.c
> index 4e5e13dc95da..d71bad8c07b7 100644
> --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> @@ -1191,7 +1191,7 @@ static void intel_gt_reset_global(struct intel_gt *gt,
>
> /* Use a watchdog to ensure that our reset completes */
> intel_wedge_on_timeout(&w, gt, 5 * HZ) {
> - intel_prepare_reset(gt->i915);
> + intel_display_prepare_reset(gt->i915);
>
> /* Flush everyone using a resource about to be clobbered */
> synchronize_srcu_expedited(>->reset.backoff_srcu);
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Final prep series for bigjoiner (rev2)
== Series Details ==
Series: Final prep series for bigjoiner (rev2)
URL : https://patchwork.freedesktop.org/series/83547/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9294 -> Patchwork_18871
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18871 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18871, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18871/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18871:
### CI changes ###
Possible regressions
* boot (NEW):
- fi-icl-y: [PASS][1] -> [FAIL][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9294/fi-icl-y/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18871/fi-icl-y/boot.html
- fi-cfl-8109u: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9294/fi-cfl-8109u/boot.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18871/fi-cfl-8109u/boot.html
- fi-cfl-8700k: [PASS][5] -> [FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9294/fi-cfl-8700k/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18871/fi-cfl-8700k/boot.html
- {fi-ehl-1}: [PASS][7] -> [FAIL][8]
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9294/fi-ehl-1/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18871/fi-ehl-1/boot.html
- fi-skl-6700k2: [PASS][9] -> [FAIL][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9294/fi-skl-6700k2/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18871/fi-skl-6700k2/boot.html
- fi-cfl-guc: [PASS][11] -> [FAIL][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9294/fi-cfl-guc/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18871/fi-cfl-guc/boot.html
- fi-skl-lmem:[PASS][13] -> [FAIL][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9294/fi-skl-lmem/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18871/fi-skl-lmem/boot.html
- fi-glk-dsi: [PASS][15] -> [FAIL][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9294/fi-glk-dsi/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18871/fi-glk-dsi/boot.html
- fi-kbl-7500u: [PASS][17] -> [FAIL][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9294/fi-kbl-7500u/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18871/fi-kbl-7500u/boot.html
- fi-skl-guc: [PASS][19] -> [FAIL][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9294/fi-skl-guc/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18871/fi-skl-guc/boot.html
New tests
-
New tests have been introduced between CI_DRM_9294 and Patchwork_18871:
### New CI tests (1) ###
* boot:
- Statuses : 12 fail(s) 25 pass(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_18871 that come from known issues:
### CI changes ###
Issues hit
* boot (NEW):
- fi-apl-guc: [PASS][21] -> [FAIL][22] ([i915#1635] / [i915#348])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9294/fi-apl-guc/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18871/fi-apl-guc/boot.html
- fi-bxt-dsi: [PASS][23] -> [FAIL][24] ([i915#1635])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9294/fi-bxt-dsi/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18871/fi-bxt-dsi/boot.html
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-byt-j1900: [PASS][25] -> [DMESG-WARN][26] ([i915#1982]) +1
similar issue
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9294/fi-byt-j1900/igt@i915_module_l...@reload.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18871/fi-byt-j1900/igt@i915_module_l...@reload.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-byt-j1900: [DMESG-WARN][27] ([i915#1982]) -> [PASS][28]
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9294/fi-byt-j1900/igt@gem_exec_susp...@basic-s3.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18871/fi-byt-j1900/igt@gem_exec_susp...@basic-s3.html
* igt@kms_busy@basic@flip:
- {fi-kbl-7560u}: [DMESG-WARN][29] ([i915#1982]) -> [PASS][30] +1
similar issue
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9294/fi-kbl-7560u/igt@kms_busy@ba...@flip.html
[30]:
https://intel-gfx-ci.01.org/tre
Re: [Intel-gfx] [PATCH v4 15/16] drm/i915/hdcp: Support for HDCP 2.2 MST shim callbacks
On 2020-11-09 at 11:06:24 +0530, Anshuman Gupta wrote:
> On 2020-11-06 at 16:42:21 +0530, Ramalingam C wrote:
> > On 2020-11-06 at 14:57:25 +0530, Ramalingam C wrote:
> > > On 2020-11-03 at 11:57:00 +0530, Anshuman Gupta wrote:
> > > > Add support for HDCP 2.2 DP MST shim callback.
> > > > This adds existing DP HDCP shim callback for Link Authentication
> > > > and Encryption and HDCP 2.2 stream encryption
> > > > callback.
> > > >
> > > > v2:
> > > > Added a WARN_ON() instead of drm_err. [Uma]
> > > > Cosmetic changes. [Uma]
> > >
> > > Reviewed-by: Ramalingam C
> > I think we can improvise further here.
> >
> > > >
> > > > Cc: Ramalingam C
> > > > Reviewed-by: Uma Shankar
> > > > Signed-off-by: Anshuman Gupta
> > > > ---
> > > > .../drm/i915/display/intel_display_types.h| 4 +
> > > > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 80 +--
> > > > 2 files changed, 76 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > index dfb5be64e03a..4cbb151ff3cf 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > @@ -374,6 +374,10 @@ struct intel_hdcp_shim {
> > > > int (*config_stream_type)(struct intel_digital_port *dig_port,
> > > > bool is_repeater, u8 type);
> > > >
> > > > + /* Enable/Disable HDCP 2.2 stream encryption on DP MST
> > > > Transport Link */
> > > > + int (*stream_2_2_encryption)(struct intel_digital_port
> > > > *dig_port,
> > > > +bool enable);
> > > > +
> > > > /* HDCP2.2 Link Integrity Check */
> > > > int (*check_2_2_link)(struct intel_digital_port *dig_port,
> > > > struct intel_connector *connector);
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > > > index 4be61e7fde4e..35c1543fe0e2 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > > > @@ -698,18 +698,14 @@ intel_dp_mst_hdcp_stream_encryption(struct
> > > > intel_digital_port *dig_port,
> > > > return 0;
> > > > }
> > > >
> > > > -static
> > > > -bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *dig_port,
> > > > - struct intel_connector *connector)
> > > > +static bool intel_dp_mst_get_qses_status(struct intel_digital_port
> > > > *dig_port,
> > > > +struct intel_connector
> > > > *connector)
> > > > {
> > > > struct drm_i915_private *i915 =
> > > > to_i915(dig_port->base.base.dev);
> > > > - struct intel_dp *intel_dp = &dig_port->dp;
> > > > struct drm_dp_query_stream_enc_status_ack_reply reply;
> > > > + struct intel_dp *intel_dp = &dig_port->dp;
> > > > int ret;
> > > >
> > > > - if (!intel_dp_hdcp_check_link(dig_port, connector))
> > > > - return false;
> > > > -
> > > > ret = drm_dp_send_query_stream_enc_status(&intel_dp->mst_mgr,
> > > > connector->port,
> > > > &reply);
> > > > if (ret) {
> > > > @@ -722,6 +718,69 @@ bool intel_dp_mst_hdcp_check_link(struct
> > > > intel_digital_port *dig_port,
> > > > return reply.auth_completed && reply.encryption_enabled;
> > > > }
> > > >
> > > > +static
> > > > +bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *dig_port,
> > > > + struct intel_connector *connector)
> > > > +{
> > > > + if (!intel_dp_hdcp_check_link(dig_port, connector))
> > > > + return false;
> > > > +
> > > > + return intel_dp_mst_get_qses_status(dig_port, connector);
> > > > +}
> > > > +
> > > > +static int
> > > > +intel_dp_mst_hdcp2_stream_encryption(struct intel_digital_port
> > > > *dig_port,
> > > > +bool enable)
> > > > +{
> > > > + struct drm_i915_private *i915 =
> > > > to_i915(dig_port->base.base.dev);
> > > > + struct hdcp_port_data *data = &dig_port->port_data;
> > > > + struct intel_dp *dp = &dig_port->dp;
> > > > + struct intel_hdcp *hdcp = &dp->attached_connector->hdcp;
> > > > + enum port port = dig_port->base.port;
> > > > + /* HDCP2.x register uses stream transcoder */
> > > > + enum transcoder cpu_transcoder = hdcp->stream_transcoder;
> > > > + int ret;
> > > > +
> > > > + drm_WARN_ON(&i915->drm, enable &&
> > > > + !!(intel_de_read(i915, HDCP2_AUTH_STREAM(i915,
> > > > cpu_transcoder, port))
> > > > + & AUTH_STREAM_TYPE) !=
> > > > data->streams[0].stream_type);
> > > > +
> > > > + ret = intel_dp_mst_toggle_hdcp_stream_select(dig_port
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Final prep series for bigjoiner (rev2)
== Series Details ==
Series: Final prep series for bigjoiner (rev2)
URL : https://patchwork.freedesktop.org/series/83547/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6cf2a64fbb76 drm/i915/dp: Some reshuffling in mode_valid as prep for bigjoiner
modes
99648dc9d2bf drm/i915: Move encoder->get_config to a new function
c8081c28ad59 drm/i915/dp: Add a wrapper function around get_pipe_config
2ea170a05527 drm/i915: Add hw.pipe_mode to allow bigjoiner pipe/transcoder split
-:183: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#183: FILE: drivers/gpu/drm/i915/display/intel_display.c:13485:
+ crtc_state->hw.pipe_mode = crtc_state->hw.adjusted_mode =
crtc_state->uapi.adjusted_mode;
total: 0 errors, 0 warnings, 1 checks, 392 lines checked
9ec71e9df46e drm/i915: Pass intel_atomic_state instead of drm_atomic_state
8036c2301b4a drm/i915/dp: Add from_crtc_state to copy color blobs
18446671587a drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.
-:191: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the
previous line
#191: FILE: drivers/gpu/drm/i915/display/intel_dp.c:774:
+ if ((target_clock > max_dotclk || mode->hdisplay > 5120)
+ && intel_dp_can_bigjoiner(intel_dp)) {
total: 0 errors, 0 warnings, 1 checks, 211 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
