date:20230406

== Series Details ==

Series: Add hwmon support for dgfx selftests (rev9)
URL   : https://patchwork.freedesktop.org/series/109850/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12972_full -> Patchwork_109850v9_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

Known issues


  Here are the changes found in Patchwork_109850v9_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_barrier_race@remote-request@rcs0:
- shard-apl:  [PASS][1] -> [ABORT][2] ([i915#8211] / [i915#8234])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12972/shard-apl3/igt@gem_barrier_race@remote-requ...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109850v9/shard-apl2/igt@gem_barrier_race@remote-requ...@rcs0.html

  * igt@gem_lmem_swapping@massive:
- shard-apl:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109850v9/shard-apl6/igt@gem_lmem_swapp...@massive.html

  * igt@gem_render_copy@x-tiled-to-vebox-yf-tiled:
- shard-apl:  NOTRUN -> [SKIP][4] ([fdo#109271]) +56 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109850v9/shard-apl2/igt@gem_render_c...@x-tiled-to-vebox-yf-tiled.html

  * igt@i915_module_load@reload:
- shard-snb:  [PASS][5] -> [ABORT][6] ([i915#4528])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12972/shard-snb2/igt@i915_module_l...@reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109850v9/shard-snb4/igt@i915_module_l...@reload.html

  * igt@i915_pm_rps@engine-order:
- shard-apl:  NOTRUN -> [FAIL][7] ([i915#6537])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109850v9/shard-apl6/igt@i915_pm_...@engine-order.html

  * igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc:
- shard-apl:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3886]) +2 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109850v9/shard-apl6/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_content_protection@uevent@pipe-a-dp-1:
- shard-apl:  NOTRUN -> [FAIL][9] ([i915#1339])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109850v9/shard-apl6/igt@kms_content_protection@uev...@pipe-a-dp-1.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl:  [PASS][10] -> [FAIL][11] ([i915#2346])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12972/shard-apl7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109850v9/shard-apl4/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html

  * igt@kms_psr2_su@page_flip-nv12:
- shard-apl:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#658])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109850v9/shard-apl6/igt@kms_psr2_su@page_flip-nv12.html

  * igt@kms_writeback@writeback-fb-id:
- shard-apl:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#2437])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109850v9/shard-apl2/igt@kms_writeb...@writeback-fb-id.html

  
 Possible fixes 

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- {shard-rkl}:[FAIL][14] ([i915#2842]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12972/shard-rkl-3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109850v9/shard-rkl-2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl:  [FAIL][16] ([i915#2842]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12972/shard-apl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109850v9/shard-apl3/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@kms_cursor_crc@cursor-suspend@pipe-c-dp-1:
- shard-apl:  [ABORT][18] ([i915#180]) -> [PASS][19] +1 similar 
issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12972/shard-apl2/igt@kms_cursor_crc@cursor-susp...@pipe-c-dp-1.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109850v9/shard-apl6/igt@kms_cursor_crc@cursor-susp...@pipe-c-dp-1.html

  * igt@kms_cursor_legacy@forked-move@pipe-b:
- {shard-dg1}:[INCOMPLETE][20] ([i915#8011]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12972/shard-dg1-14/igt@kms_cursor_legacy@forked-m...@pipe-b.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109850v9/shard-dg1-16/igt@kms_cursor_legacy@forked-m...@pipe-b.html

  * igt@kms_cursor_legacy@single-move@pipe-b

Re: [Intel-gfx] [PATCH 1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers

On Wed, 5 Apr 2023 at 19:46, Patrik Jakobsson
 wrote:
>
> On Wed, Apr 5, 2023 at 7:15 PM Daniel Vetter  wrote:
> >
> > On Wed, 5 Apr 2023 at 18:54, Javier Martinez Canillas
> >  wrote:
> > >
> > > Daniel Vetter  writes:
> > >
> > > > On Wed, Apr 05, 2023 at 04:32:19PM +0200, Thomas Zimmermann wrote:
> > >
> > > [...]
> > >
> > > >> > > >/*
> > > >> > > > * WARNING: Apparently we must kick fbdev drivers before 
> > > >> > > > vgacon,
> > > >> > > > * otherwise the vga fbdev driver falls over.
> > > >> > > > */
> > > >> > > >ret = vga_remove_vgacon(pdev);
> > > >> >
> > > >> > This isn't enough, we also nuke stuff that's mapping the vga fb 
> > > >> > range.
> > >
> > > Ah, also need aperture_detach_devices(VGA_FB_PHYS_BASE, VGA_FB_PHYS_SIZE) 
> > > then.
> > >
> > > [...]
> > >
> > > >> int aperture_remove_legacy_vga_devices(struct pci_dev *pdev)
> > > >> {
> > > >>  aperture_detach_devices(VGA_FB_PHYS_BASE, VGA_FB_PHYS_SIZE);
> > > >>
> > > >>  return vga_remove_vgacon(pdev);
> > > >> }
> > > >>
> > > >> And that can be called from gma500 and the pci aperture helper.
> > > >
> > > > But you still pass a pci_dev to that helper. Which just doesn't make any
> > > > sense to me (assuming your entire point is that this isn't just a normal
> > > > pci device but some special legacy vga thing), but if we go with (void)
> > > > then there's more refactoring to do because the vga_remove_vgacon also
> > > > wants a pdev.
> > > >
> > > > All so that we don't call aperture_detach_devices() on a bunch of pci
> > > > bars, which apparently is not problem for any other driver, but 
> > > > absolutely
> > > > is a huge problem for gma500 somehow.
> > > >
> > > > I don't understand why.
> > > >
> > >
> > > Yeah, agreed that if vga_remove_vgacon() isn't enough and another helper
> > > is needed then starts to get a little silly. Maybe one option is to add a
> > > 3rd param to aperture_remove_conflicting_pci_devices() and skip the logic
> > > to iterate over PCI bars and call aperture_remove_conflicting_devices() ?
> >
> > The thing I don't get: Why does this matter for gma500 and not any of
> > the other pci devices? Look at your gpu, realize there's a lot more
> > than the one pci bar for vram or stolen memory, realize that we're
> > nuking bars that cannot possible contain the framebuffer for everyone
> > else too. Like the entire "gpus have a lot of bars" thing is the
> > reason why I pulled the sysfb_disable one level up, because we've been
> > doing that quite a few times before this patch (yes it's not the main
> > thing, but the side-effect cleanup is why I've gone down this rabbit
> > hole and wrote the entire series here):
> >
> > https://lore.kernel.org/dri-devel/20230404201842.567344-7-daniel.vet...@ffwll.ch/
> >
> > But somehow for gma500 it's a problem, while for everyone else it's
> > fine. That's the part I dont get, or Thomas&me have been talking past
> > each another and there's another issue that I'm missing.
> > -Daniel
>
> I'm also getting confused here.
>
> AFAIK the stolen memory works the same for gma500 hardware as other
> Intel GPUs. Are you saying that there is a difference in how gma500
> hardware works? I always assumed that i915 got away with not dealing
> much with stolen memory because it simply doesn't use it for
> allocations. In gma500 we use it for fbdev and cursors. The actual
> pages reserved by the bios can be accessed through a pci bar if you
> map it so (which IIRC we do) but I suppose that doesn't help
> identifying it as a range reserved by other drivers.

The other integrated gpu have their fw fb behind a pci bar, and stolen
is often entirely hidden from the cpu for direct access. gma500 seems
different with having stolen as just a specially marked up range of
normal system memory. That's why the usual pci helper doesn't catch
everything for gma500.

> The reason I've kept the stolen allocation logic is because some
> gma500 systems don't have a lot of memory. But that is mostly the old
> Pouslbo systems. Perhaps it is time to ditch the stolen allocation
> code?

Yeah that's all fine.
-Daniel

>
> -Patrik
>
> >
> > > > Consider this me throwing in the towel. If you&Javier are convinced this
> > > > makes sense please type it up and merge it, but I'm not going to type
> > > > something that just doesn't make sense to me.
> > >
> > > Honestly, I would just go with the double drm_aperture_remove_*() helper
> > > calls (your original patch) unless that causes real issues. There is no
> > > point on blocking all your series just for this IMO.
> > >
> > > Then latter if Thomas has strong opinions can send a follow-up patch for
> > > the gma500 driver and the aperture helpers.
> > >
> > > > -Daniel
> > > >
> > >
> > > --
> > > Best regards,
> > >
> > > Javier Martinez Canillas
> > > Core Platforms
> > > Red Hat
> > >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch



-- 
Daniel Vetter
Softwa

Re: [Intel-gfx] [PATCH 1/7] drm/i915/mtl: Define MOCS and PAT tables for MTL

2023-04-06 Thread Andi Shyti

Hi Fei,

On Mon, Apr 03, 2023 at 03:50:26PM +0300, Jani Nikula wrote:
> On Fri, 31 Mar 2023, fei.y...@intel.com wrote:
> > From: Fei Yang 
> >
> > On MTL, GT can no longer allocate on LLC - only the CPU can.
> > This, along with addition of support for ADM/L4 cache calls a
> > MOCS/PAT table update.
> > Also add PTE encode functions for MTL as it has different PAT
> > index definition than previous platforms.
> 
> As a general observation, turning something into a function pointer and
> extending it to more platforms should be two separate changes.

Agree with Jani. Fei, would you mind splitting this patch? It
eases the review, as well.

Thanks,
Andi

> BR,
> Jani.
> 
> >
> > BSpec: 44509, 45101, 44235
> >
> > Cc: Matt Roper 
> > Cc: Lucas De Marchi 
> > Signed-off-by: Madhumitha Tolakanahalli Pradeep 
> > 
> > Signed-off-by: Aravind Iddamsetty 
> > Signed-off-by: Fei Yang 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dpt.c |  2 +-
> >  drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 43 --
> >  drivers/gpu/drm/i915/gt/gen8_ppgtt.h |  3 +
> >  drivers/gpu/drm/i915/gt/intel_ggtt.c | 36 ++-
> >  drivers/gpu/drm/i915/gt/intel_gtt.c  | 23 ++-
> >  drivers/gpu/drm/i915/gt/intel_gtt.h  | 20 ++-
> >  drivers/gpu/drm/i915/gt/intel_mocs.c | 76 ++--
> >  drivers/gpu/drm/i915/gt/selftest_mocs.c  |  2 +-
> >  drivers/gpu/drm/i915/i915_pci.c  |  1 +
> >  9 files changed, 189 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
> > b/drivers/gpu/drm/i915/display/intel_dpt.c
> > index b8027392144d..c5eacfdba1a5 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> > @@ -300,7 +300,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
> > vm->vma_ops.bind_vma= dpt_bind_vma;
> > vm->vma_ops.unbind_vma  = dpt_unbind_vma;
> >  
> > -   vm->pte_encode = gen8_ggtt_pte_encode;
> > +   vm->pte_encode = vm->gt->ggtt->vm.pte_encode;
> >  
> > dpt->obj = dpt_obj;
> > dpt->obj->is_dpt = true;
> > diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
> > b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> > index 4daaa6f55668..4197b43150cc 100644
> > --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> > +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> > @@ -55,6 +55,34 @@ static u64 gen8_pte_encode(dma_addr_t addr,
> > return pte;
> >  }
> >  
> > +static u64 mtl_pte_encode(dma_addr_t addr,
> > + enum i915_cache_level level,
> > + u32 flags)
> > +{
> > +   gen8_pte_t pte = addr | GEN8_PAGE_PRESENT | GEN8_PAGE_RW;
> > +
> > +   if (unlikely(flags & PTE_READ_ONLY))
> > +   pte &= ~GEN8_PAGE_RW;
> > +
> > +   if (flags & PTE_LM)
> > +   pte |= GEN12_PPGTT_PTE_LM | GEN12_PPGTT_PTE_NC;
> > +
> > +   switch (level) {
> > +   case I915_CACHE_NONE:
> > +   pte |= GEN12_PPGTT_PTE_PAT1;
> > +   break;
> > +   case I915_CACHE_LLC:
> > +   case I915_CACHE_L3_LLC:
> > +   pte |= GEN12_PPGTT_PTE_PAT0 | GEN12_PPGTT_PTE_PAT1;
> > +   break;
> > +   case I915_CACHE_WT:
> > +   pte |= GEN12_PPGTT_PTE_PAT0;
> > +   break;
> > +   }
> > +
> > +   return pte;
> > +}
> > +
> >  static void gen8_ppgtt_notify_vgt(struct i915_ppgtt *ppgtt, bool create)
> >  {
> > struct drm_i915_private *i915 = ppgtt->vm.i915;
> > @@ -427,7 +455,7 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
> >   u32 flags)
> >  {
> > struct i915_page_directory *pd;
> > -   const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
> > +   const gen8_pte_t pte_encode = ppgtt->vm.pte_encode(0, cache_level, 
> > flags);
> > gen8_pte_t *vaddr;
> >  
> > pd = i915_pd_entry(pdp, gen8_pd_index(idx, 2));
> > @@ -580,7 +608,7 @@ static void gen8_ppgtt_insert_huge(struct 
> > i915_address_space *vm,
> >enum i915_cache_level cache_level,
> >u32 flags)
> >  {
> > -   const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
> > +   const gen8_pte_t pte_encode = vm->pte_encode(0, cache_level, flags);
> > unsigned int rem = sg_dma_len(iter->sg);
> > u64 start = vma_res->start;
> >  
> > @@ -743,7 +771,7 @@ static void gen8_ppgtt_insert_entry(struct 
> > i915_address_space *vm,
> > GEM_BUG_ON(pt->is_compact);
> >  
> > vaddr = px_vaddr(pt);
> > -   vaddr[gen8_pd_index(idx, 0)] = gen8_pte_encode(addr, level, flags);
> > +   vaddr[gen8_pd_index(idx, 0)] = vm->pte_encode(addr, level, flags);
> > drm_clflush_virt_range(&vaddr[gen8_pd_index(idx, 0)], sizeof(*vaddr));
> >  }
> >  
> > @@ -773,7 +801,7 @@ static void __xehpsdv_ppgtt_insert_entry_lm(struct 
> > i915_address_space *vm,
> > }
> >  
> > vaddr = px_vaddr(pt);
> > -   vaddr[gen8_pd_index(idx, 0) / 16] = gen8_pte_encode(addr, level, flags);
> > +   vaddr[gen8_pd_index(idx, 0) / 16] = vm->pte_encode(addr, level, flags);
> >  }
> >  
>

[Intel-gfx] [PULL] drm-intel-gt-next

2023-04-06 Thread Joonas Lahtinen

Hi Dave & Daniel,

Here goes the final drm-intel-gt-next pull request for v6.4.

As top items we have a fix for context runtime accounting, Meteorlake
enabling, DMAR error noise elimination due to GPU error capture, BAR
resizing forcewake fix and memory contents clearing fix for discrete.
More robust GuC loading on systems with IFWI that leaves GPU to slow
frequency and a potential UAF closed on perf add_config IOCTL.

There is also change to the uAPI headers to eliminate flexible-array
member kernel-wide request, which does not impact binaries and also
should not impact compilation.

Then the usual amount of smaller fixes and cleanups. A good amount of
kerneldoc fixes included.

Best Regards, Joonas

***

drm-intel-gt-next-2023-04-06:

UAPI Changes:

- (Build-time only, should not have any impact)
  drm/i915/uapi: Replace fake flex-array with flexible-array member

  "Zero-length arrays as fake flexible arrays are deprecated and we are
  moving towards adopting C99 flexible-array members instead."

  This is on core kernel request moving towards GCC 13.

Driver Changes:

- Fix context runtime accounting on sysfs fdinfo for heavy workloads (Tvrtko)
- Add support for OA media units on MTL (Umesh)
- Add new workarounds for Meteorlake (Daniele, Radhakrishna, Haridhar)
- Fix sysfs to read actual frequency for MTL and Gen6 and earlier
  (Ashutosh)
- Synchronize i915/BIOS on C6 enabling on MTL (Vinay)
- Fix DMAR error noise due to GPU error capture (Andrej)
- Fix forcewake during BAR resize on discrete (Andrzej)
- Flush lmem contents after construction on discrete (Chris)
- Fix GuC loading timeout on systems where IFWI programs low boot
  frequency (John)
- Fix race condition UAF in i915_perf_add_config_ioctl (Min)

- Sanitycheck MMIO access early in driver load and during forcewake
  (Matt)
- Wakeref fixes for GuC RC error scenario and active VM tracking (Chris)
- Cancel HuC delayed load timer on reset (Daniele)
- Limit double GT reset to pre-MTL (Daniele)
- Use i915 instead of dev_priv insied the file_priv structure (Andi)
- Improve GuC load error reporting (John)
- Simplify VCS/BSD engine selection logic (Tvrtko)
- Perform uc late init after probe error injection (Andrzej)
- Fix format for perf_limit_reasons in debugfs (Vinay)
- Create per-gt debugfs files (Andi)

- Documentation and kerneldoc fixes (Nirmoy, Lee)
- Selftest improvements (Fei, Jonathan)

The following changes since commit d2a9692ad4295e227e3352fdbf14b8491b01e1c9:

  drm/i915/gt: make kobj attributes const (2023-03-15 12:20:11 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2023-04-06

for you to fetch changes up to 4b51210f98c2b89ce37aede5b8dc5105be0572c6:

  drm/i915/mtl: Add Wa_14017856879 (2023-04-05 07:59:12 -0700)


UAPI Changes:

- (Build-time only, should not have any impact)
  drm/i915/uapi: Replace fake flex-array with flexible-array member

  "Zero-length arrays as fake flexible arrays are deprecated and we are
  moving towards adopting C99 flexible-array members instead."

  This is on core kernel request moving towards GCC 13.

Driver Changes:

- Fix context runtime accounting on sysfs fdinfo for heavy workloads (Tvrtko)
- Add support for OA media units on MTL (Umesh)
- Add new workarounds for Meteorlake (Daniele, Radhakrishna, Haridhar)
- Fix sysfs to read actual frequency for MTL and Gen6 and earlier
  (Ashutosh)
- Synchronize i915/BIOS on C6 enabling on MTL (Vinay)
- Fix DMAR error noise due to GPU error capture (Andrej)
- Fix forcewake during BAR resize on discrete (Andrzej)
- Flush lmem contents after construction on discrete (Chris)
- Fix GuC loading timeout on systems where IFWI programs low boot
  frequency (John)
- Fix race condition UAF in i915_perf_add_config_ioctl (Min)

- Sanitycheck MMIO access early in driver load and during forcewake
  (Matt)
- Wakeref fixes for GuC RC error scenario and active VM tracking (Chris)
- Cancel HuC delayed load timer on reset (Daniele)
- Limit double GT reset to pre-MTL (Daniele)
- Use i915 instead of dev_priv insied the file_priv structure (Andi)
- Improve GuC load error reporting (John)
- Simplify VCS/BSD engine selection logic (Tvrtko)
- Perform uc late init after probe error injection (Andrzej)
- Fix format for perf_limit_reasons in debugfs (Vinay)
- Create per-gt debugfs files (Andi)

- Documentation and kerneldoc fixes (Nirmoy, Lee)
- Selftest improvements (Fei, Jonathan)


Andi Shyti (3):
  drm/i915/gt: Create per-gt debugfs files
  drm/i915/debugfs: Enable upper layer interfaces to act on all gt's
  drm/i915: Use i915 instead of dev_priv insied the file_priv structure

Andrzej Hajda (4):
  drm/i915/gt: prevent forcewake releases during BAR resize
  drm/i915/gt: introduce vm->scratch_range callback
  drm/i915: add guard page to ggtt->error_capture
  drm/i915/

Re: [Intel-gfx] [PATCH v10 0/4] Add hwmon support for dgfx selftests

On Wed, 05 Apr 2023, Riana Tauro  wrote:
> Rename librapl library to libpower. Add hwmon support in libpower for
> dgfx.
> Use libpower in selftests.
>
> Rev2 : Update commit message
> Rev3 : Remove redundant code
> Rev4 : Add hwmon per-gt support
> Rev5 : No functional changes.
>Change author for last patch
> Rev6 : re-order libpower library patch
>add check for single gt in hwmon function
> Rev7 : Same as Rev 5 with a single gt check
>in hwmon function
> Rev8 : Skip power comparison in live_rc6_manual for
>discrete graphics
> Rev9 : Update commit message
> Rev10: No functional changes
>Fix a spelling

Please do *not* send two revisions 15 minutes apart just to fix a
spelling error.

As a rule of thumb, for each revision, wait for review comments and test
results for at least a day. Usually longer. Don't accumulate a lot of
revisions for no benefit. It just causes extra work and
confusion. Rushing it does not pay off, on the contrary.

Now, you have review comments to v9 sent after v10 was out. You also
have both revisions in CI shards queue waiting to be tested, consuming
resources for no benefit. Based on the review comment there will be
another version; do not send it until you have figured out with the
reviewer what needs to be done and there's been enough time for people
to chime in.

In general, the revision log above shows a lot of new revisions for
non-functional changes. Don't do that until you have green light for the
functional changes, and the non-functional polish on top is just one
final version.

BR,
Jani.

>
> Riana Tauro (3):
>   drm/i915/selftests: Rename librapl library to libpower
>   drm/i915/hwmon: Add helper function to obtain energy values
>   drm/i915/selftests: skip comparison of power for discrete graphics
>
> Tilak Tangudu (1):
>   drm/i915/selftests: Add hwmon support in libpower for dgfx
>
>  drivers/gpu/drm/i915/Makefile |  2 +-
>  drivers/gpu/drm/i915/gt/selftest_rc6.c| 22 ++-
>  drivers/gpu/drm/i915/gt/selftest_rps.c| 26 -
>  drivers/gpu/drm/i915/gt/selftest_slpc.c   |  4 +--
>  drivers/gpu/drm/i915/i915_hwmon.c | 28 +++
>  drivers/gpu/drm/i915/i915_hwmon.h |  3 ++
>  drivers/gpu/drm/i915/selftests/libpower.c | 33 ++
>  drivers/gpu/drm/i915/selftests/libpower.h | 19 +
>  drivers/gpu/drm/i915/selftests/librapl.c  | 34 ---
>  drivers/gpu/drm/i915/selftests/librapl.h  | 17 
>  10 files changed, 114 insertions(+), 74 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/selftests/libpower.c
>  create mode 100644 drivers/gpu/drm/i915/selftests/libpower.h
>  delete mode 100644 drivers/gpu/drm/i915/selftests/librapl.c
>  delete mode 100644 drivers/gpu/drm/i915/selftests/librapl.h

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 1/7] drm/i915/mtl: Define MOCS and PAT tables for MTL

2023-04-06 Thread Das, Nirmoy


Hi Fei,

On 4/1/2023 8:38 AM, fei.y...@intel.com wrote:

From: Fei Yang 

On MTL, GT can no longer allocate on LLC - only the CPU can.
This, along with addition of support for ADM/L4 cache calls a
MOCS/PAT table update.
Also add PTE encode functions for MTL as it has different PAT
index definition than previous platforms.

BSpec: 44509, 45101, 44235

Cc: Matt Roper 
Cc: Lucas De Marchi 
Signed-off-by: Madhumitha Tolakanahalli Pradeep 

Signed-off-by: Aravind Iddamsetty 
Signed-off-by: Fei Yang 
---
  drivers/gpu/drm/i915/display/intel_dpt.c |  2 +-
  drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 43 --
  drivers/gpu/drm/i915/gt/gen8_ppgtt.h |  3 +
  drivers/gpu/drm/i915/gt/intel_ggtt.c | 36 ++-
  drivers/gpu/drm/i915/gt/intel_gtt.c  | 23 ++-
  drivers/gpu/drm/i915/gt/intel_gtt.h  | 20 ++-
  drivers/gpu/drm/i915/gt/intel_mocs.c | 76 ++--
  drivers/gpu/drm/i915/gt/selftest_mocs.c  |  2 +-
  drivers/gpu/drm/i915/i915_pci.c  |  1 +
  9 files changed, 189 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
b/drivers/gpu/drm/i915/display/intel_dpt.c
index b8027392144d..c5eacfdba1a5 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -300,7 +300,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
vm->vma_ops.bind_vma= dpt_bind_vma;
vm->vma_ops.unbind_vma  = dpt_unbind_vma;
  
-	vm->pte_encode = gen8_ggtt_pte_encode;

+   vm->pte_encode = vm->gt->ggtt->vm.pte_encode;
  
  	dpt->obj = dpt_obj;

dpt->obj->is_dpt = true;
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 4daaa6f55668..4197b43150cc 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -55,6 +55,34 @@ static u64 gen8_pte_encode(dma_addr_t addr,
return pte;
  }
  
+static u64 mtl_pte_encode(dma_addr_t addr,

+ enum i915_cache_level level,
+ u32 flags)
+{
+   gen8_pte_t pte = addr | GEN8_PAGE_PRESENT | GEN8_PAGE_RW;
+
+   if (unlikely(flags & PTE_READ_ONLY))
+   pte &= ~GEN8_PAGE_RW;
+
+   if (flags & PTE_LM)
+   pte |= GEN12_PPGTT_PTE_LM | GEN12_PPGTT_PTE_NC;
+
+   switch (level) {
+   case I915_CACHE_NONE:
+   pte |= GEN12_PPGTT_PTE_PAT1;
+   break;
+   case I915_CACHE_LLC:
+   case I915_CACHE_L3_LLC:
+   pte |= GEN12_PPGTT_PTE_PAT0 | GEN12_PPGTT_PTE_PAT1;
+   break;
+   case I915_CACHE_WT:
+   pte |= GEN12_PPGTT_PTE_PAT0;
+   break;
+   }
+
+   return pte;
+}
+
  static void gen8_ppgtt_notify_vgt(struct i915_ppgtt *ppgtt, bool create)
  {
struct drm_i915_private *i915 = ppgtt->vm.i915;
@@ -427,7 +455,7 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
  u32 flags)
  {
struct i915_page_directory *pd;
-   const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
+   const gen8_pte_t pte_encode = ppgtt->vm.pte_encode(0, cache_level, 
flags);
gen8_pte_t *vaddr;
  
  	pd = i915_pd_entry(pdp, gen8_pd_index(idx, 2));

@@ -580,7 +608,7 @@ static void gen8_ppgtt_insert_huge(struct 
i915_address_space *vm,
   enum i915_cache_level cache_level,
   u32 flags)
  {
-   const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
+   const gen8_pte_t pte_encode = vm->pte_encode(0, cache_level, flags);
unsigned int rem = sg_dma_len(iter->sg);
u64 start = vma_res->start;
  
@@ -743,7 +771,7 @@ static void gen8_ppgtt_insert_entry(struct i915_address_space *vm,

GEM_BUG_ON(pt->is_compact);
  
  	vaddr = px_vaddr(pt);

-   vaddr[gen8_pd_index(idx, 0)] = gen8_pte_encode(addr, level, flags);
+   vaddr[gen8_pd_index(idx, 0)] = vm->pte_encode(addr, level, flags);
drm_clflush_virt_range(&vaddr[gen8_pd_index(idx, 0)], sizeof(*vaddr));
  }
  
@@ -773,7 +801,7 @@ static void __xehpsdv_ppgtt_insert_entry_lm(struct i915_address_space *vm,

}
  
  	vaddr = px_vaddr(pt);

-   vaddr[gen8_pd_index(idx, 0) / 16] = gen8_pte_encode(addr, level, flags);
+   vaddr[gen8_pd_index(idx, 0) / 16] = vm->pte_encode(addr, level, flags);
  }
  
  static void xehpsdv_ppgtt_insert_entry(struct i915_address_space *vm,

@@ -820,7 +848,7 @@ static int gen8_init_scratch(struct i915_address_space *vm)
pte_flags |= PTE_LM;
  
  	vm->scratch[0]->encode =

-   gen8_pte_encode(px_dma(vm->scratch[0]),
+   vm->pte_encode(px_dma(vm->scratch[0]),
I915_CACHE_NONE, pte_flags);
  
  	for (i = 1; i <= vm->top; i++) {

@@ -963,7 +991,10 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
 */
ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
  
-	ppgtt->vm.pte_encode =

Re: [Intel-gfx] [PATCH 1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers

2023-04-06 Thread Javier Martinez Canillas

Thomas Zimmermann  writes:

[...]

> Am 04.04.23 um 22:18 schrieb Daniel Vetter:
> Gma500 therefore calls both helpers to catch all cases. It's confusing
> as it implies that there's something about the PCI device that requires
> ownership management. The relationship between the PCI device and the
> VGA devices is non-obvious. At worst, readers might assume that calling
> two functions for aperture clearing ownership is a bug in the driver.
>

Yeah, or someone looking as the driver for reference may wrongly think
that calling both aperture helpers are needed for PCI drivers and that
is not the case.

> Hence, move the PCI removal helper's code for VGA functionality into
> a separate function and call this function from gma500. Documents the
> purpose of each call to aperture helpers. The change contains comments
> and example code form the discussion at [1].
>
> Signed-off-by: Thomas Zimmermann 
> Link: 
> https://patchwork.kernel.org/project/dri-devel/patch/20230404201842.567344-1-daniel.vet...@ffwll.ch/
>  # 1
> ---

Looks good to me and I agree that it makes the code easier to understand.

Reviewed-by: Javier Martinez Canillas 

I've a couple of comments below though:

[...]

> + * Hardware for gma500 is a hybrid device, which both acts as a PCI
> + * device (for legacy vga functionality) but also more like an
> + * integrated display on a SoC where the framebuffer simply
> + * resides in main memory and not in a special PCI bar (that
> + * internally redirects to a stolen range of main memory) like all
> + * other integrated PCI display devices have.
> + *

Is "have" the correct word here or "do" ? Or maybe "are implemented" ?

> + * To catch all cases we need to remove conflicting firmware devices
> + * for the stolen system memory and for the VGA functionality. As we
> + * currently cannot easily find the framebuffer's location in stolen
> + * memory, we remove all framebuffers here.
> + *
> + * TODO: Refactor psb_driver_load() to map vdc_reg earlier. Then
> + *   we might be able to read the framebuffer range from the
> + *   device.
> + */
> +static int gma_remove_conflicting_framebuffers(struct pci_dev *pdev,
> +const struct drm_driver 
> *req_driver)
>  {
> - struct drm_psb_private *dev_priv;
> - struct drm_device *dev;
> + resource_size_t base = 0;
> + resource_size_t size = PHYS_ADDR_MAX;
> + const char *name = req_driver->name;
>   int ret;
>  
> - /*
> -  * We cannot yet easily find the framebuffer's location in memory. So
> -  * remove all framebuffers here. Note that we still want the pci special
> -  * handling to kick out vgacon.
> -  *
> -  * TODO: Refactor psb_driver_load() to map vdc_reg earlier. Then we
> -  *   might be able to read the framebuffer range from the device.
> -  */
> - ret = drm_aperture_remove_framebuffers(&driver);
> + ret = aperture_remove_conflicting_devices(base, size, name);
>   if (ret)
>   return ret;
>  
> - ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &driver);
> + return __aperture_remove_legacy_vga_devices(pdev);

I don't like the __ prefix for this function name, as it usually implies
that is a function that is only local to the compilation unit. But it is
an exported symbol from the aperture infrastructure.

[...]
  
> +/**
> + * __aperture_remove_legacy_vga_devices - remove legacy VGA devices of a PCI 
> devices
> + * @pdev: PCI device
> + *
> + * This function removes VGA devices provided by @pdev, such as a VGA
> + * framebuffer or a console. This is useful if you have a VGA-compatible
> + * PCI graphics device with framebuffers in non-BAR locations. Drivers
> + * should acquire ownership of those memory areas and afterwards call
> + * this helper to release remaining VGA devices.
> + *
> + * If your hardware has its framebuffers accessible via PCI BARS, use
> + * aperture_remove_conflicting_pci_devices() instead. The function will
> + * release any VGA devices automatically.
> + *
> + * WARNING: Apparently we must remove graphics drivers before calling
> + *  this helper. Otherwise the vga fbdev driver falls over if
> + *  we have vgacon configured.
> + *
> + * Returns:
> + * 0 on success, or a negative errno code otherwise
> + */
> +int __aperture_remove_legacy_vga_devices(struct pci_dev *pdev)
> +{
> + /* VGA framebuffer */
> + aperture_detach_devices(VGA_FB_PHYS_BASE, VGA_FB_PHYS_SIZE);
> +
> + /* VGA textmode console */
> + return vga_remove_vgacon(pdev);
> +}
> +EXPORT_SYMBOL(__aperture_remove_legacy_vga_devices);

I would just call this symbol aperture_remove_legacy_vga_devices() as
mentioned, the fact that aperture_remove_conflicting_pci_devices() use it
internally is an implementation detail IMO. But it's an exported symbol so
the naming should be consistent.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [Intel-gfx] [PATCH 1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers

2023-04-06 Thread Thomas Zimmermann


Hi

Am 06.04.23 um 10:38 schrieb Javier Martinez Canillas:

Thomas Zimmermann  writes:

[...]


Am 04.04.23 um 22:18 schrieb Daniel Vetter:
Gma500 therefore calls both helpers to catch all cases. It's confusing
as it implies that there's something about the PCI device that requires
ownership management. The relationship between the PCI device and the
VGA devices is non-obvious. At worst, readers might assume that calling
two functions for aperture clearing ownership is a bug in the driver.



Yeah, or someone looking as the driver for reference may wrongly think
that calling both aperture helpers are needed for PCI drivers and that
is not the case.


Hence, move the PCI removal helper's code for VGA functionality into
a separate function and call this function from gma500. Documents the
purpose of each call to aperture helpers. The change contains comments
and example code form the discussion at [1].

Signed-off-by: Thomas Zimmermann 
Link: 
https://patchwork.kernel.org/project/dri-devel/patch/20230404201842.567344-1-daniel.vet...@ffwll.ch/
 # 1
---


Looks good to me and I agree that it makes the code easier to understand.

Reviewed-by: Javier Martinez Canillas 


Thanks for the review.



I've a couple of comments below though:

[...]


+ * Hardware for gma500 is a hybrid device, which both acts as a PCI
+ * device (for legacy vga functionality) but also more like an
+ * integrated display on a SoC where the framebuffer simply
+ * resides in main memory and not in a special PCI bar (that
+ * internally redirects to a stolen range of main memory) like all
+ * other integrated PCI display devices have.
+ *


Is "have" the correct word here or "do" ? Or maybe "are implemented" ?


Right. I'll update this.




+ * To catch all cases we need to remove conflicting firmware devices
+ * for the stolen system memory and for the VGA functionality. As we
+ * currently cannot easily find the framebuffer's location in stolen
+ * memory, we remove all framebuffers here.
+ *
+ * TODO: Refactor psb_driver_load() to map vdc_reg earlier. Then
+ *   we might be able to read the framebuffer range from the
+ *   device.
+ */
+static int gma_remove_conflicting_framebuffers(struct pci_dev *pdev,
+  const struct drm_driver 
*req_driver)
  {
-   struct drm_psb_private *dev_priv;
-   struct drm_device *dev;
+   resource_size_t base = 0;
+   resource_size_t size = PHYS_ADDR_MAX;
+   const char *name = req_driver->name;
int ret;
  
-	/*

-* We cannot yet easily find the framebuffer's location in memory. So
-* remove all framebuffers here. Note that we still want the pci special
-* handling to kick out vgacon.
-*
-* TODO: Refactor psb_driver_load() to map vdc_reg earlier. Then we
-*   might be able to read the framebuffer range from the device.
-*/
-   ret = drm_aperture_remove_framebuffers(&driver);
+   ret = aperture_remove_conflicting_devices(base, size, name);
if (ret)
return ret;
  
-	ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &driver);

+   return __aperture_remove_legacy_vga_devices(pdev);


I don't like the __ prefix for this function name, as it usually implies
that is a function that is only local to the compilation unit. But it is
an exported symbol from the aperture infrastructure.

[...]
   

+/**
+ * __aperture_remove_legacy_vga_devices - remove legacy VGA devices of a PCI 
devices
+ * @pdev: PCI device
+ *
+ * This function removes VGA devices provided by @pdev, such as a VGA
+ * framebuffer or a console. This is useful if you have a VGA-compatible
+ * PCI graphics device with framebuffers in non-BAR locations. Drivers
+ * should acquire ownership of those memory areas and afterwards call
+ * this helper to release remaining VGA devices.
+ *
+ * If your hardware has its framebuffers accessible via PCI BARS, use
+ * aperture_remove_conflicting_pci_devices() instead. The function will
+ * release any VGA devices automatically.
+ *
+ * WARNING: Apparently we must remove graphics drivers before calling
+ *  this helper. Otherwise the vga fbdev driver falls over if
+ *  we have vgacon configured.
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise
+ */
+int __aperture_remove_legacy_vga_devices(struct pci_dev *pdev)
+{
+   /* VGA framebuffer */
+   aperture_detach_devices(VGA_FB_PHYS_BASE, VGA_FB_PHYS_SIZE);
+
+   /* VGA textmode console */
+   return vga_remove_vgacon(pdev);
+}
+EXPORT_SYMBOL(__aperture_remove_legacy_vga_devices);


I would just call this symbol aperture_remove_legacy_vga_devices() as
mentioned, the fact that aperture_remove_conflicting_pci_devices() use it
internally is an implementation detail IMO. But it's an exported symbol so
the naming should be consistent.


That prefix __ is supposed to indicate that it's not a all-in-one 
solution. Most of all, it doesn't d

[Intel-gfx] [PATCH] drm/i915: Query compressed bpp properly using correct DPCD and DP Spec info

2023-04-06 Thread Stanislav Lisovskiy

Currently we seem to be using wrong DPCD register for reading compressed bpps,
reading min/max input bpc instead of compressed bpp.
Fix that, so that we now apply min/max compressed bpp limitations we get
from DP Spec Table 2-157 DP v2.0 and/or correspondent DPCD register
DP_DSC_MAX_BITS_PER_PIXEL_LOW/HIGH.

This might also allow us to get rid of an ugly compressed bpp recalculation,
which we had to add to make some MST hubs usable.

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 76 ++---
 1 file changed, 52 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index a88b852c437c..9479c7e0b269 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -174,6 +174,50 @@ static int intel_dp_mst_compute_link_config(struct 
intel_encoder *encoder,
return 0;
 }
 
+static u16 dsc_max_sink_compressed_bppx16(const u8 
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
+ struct intel_crtc_state *pipe_config,
+ int bpc)
+{
+   u16 max_bppx16 = dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_LOW - 
DP_DSC_SUPPORT] |
+(dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_HI - 
DP_DSC_SUPPORT] &
+ DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK << 
DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT);
+
+   if (max_bppx16)
+   return max_bppx16;
+   /*
+* If support not given in DPCD 67h, 68h use the Maximum Allowed bit 
rate
+* values as given in spec Table 2-157 DP v2.0
+*/
+   switch (pipe_config->output_format) {
+   case INTEL_OUTPUT_FORMAT_RGB:
+   case INTEL_OUTPUT_FORMAT_YCBCR444:
+   return bpc << 4;
+   case INTEL_OUTPUT_FORMAT_YCBCR420:
+   return (3 * (bpc / 2)) << 4;
+   default:
+   MISSING_CASE(pipe_config->output_format);
+   break;
+   }
+
+   return 0;
+}
+
+static u16 dsc_min_compressed_bppx16(struct intel_crtc_state *pipe_config)
+{
+   switch (pipe_config->output_format) {
+   case INTEL_OUTPUT_FORMAT_RGB:
+   case INTEL_OUTPUT_FORMAT_YCBCR444:
+   return 8 << 4;
+   case INTEL_OUTPUT_FORMAT_YCBCR420:
+   return 6 << 4;
+   default:
+   MISSING_CASE(pipe_config->output_format);
+   break;
+   }
+
+   return 0;
+}
+
 static int intel_dp_dsc_mst_compute_link_config(struct intel_encoder *encoder,
struct intel_crtc_state 
*crtc_state,
struct drm_connector_state 
*conn_state,
@@ -191,8 +235,6 @@ static int intel_dp_dsc_mst_compute_link_config(struct 
intel_encoder *encoder,
u8 dsc_bpc[3] = {0};
int min_bpp, max_bpp, sink_min_bpp, sink_max_bpp;
u8 dsc_max_bpc;
-   bool need_timeslot_recalc = false;
-   u32 last_compressed_bpp;
 
/* Max DSC Input BPC for ICL is 10 and for TGL+ is 12 */
if (DISPLAY_VER(i915) >= 12)
@@ -228,6 +270,14 @@ static int intel_dp_dsc_mst_compute_link_config(struct 
intel_encoder *encoder,
if (max_bpp > sink_max_bpp)
max_bpp = sink_max_bpp;
 
+   /* Get Min/Max compressed bpp's for those Input Bpps we got for 
source/sink */
+   max_bpp = min(max_bpp, 
dsc_max_sink_compressed_bppx16(intel_dp->dsc_dpcd, crtc_state, max_bpp / 3) >> 
4);
+   min_bpp = max(min_bpp, dsc_min_compressed_bppx16(crtc_state) >> 4);
+
+   /* Align compressed bpps according to our own constraints */
+   max_bpp = intel_dp_dsc_nearest_valid_bpp(i915, max_bpp, 
crtc_state->pipe_bpp);
+   min_bpp = intel_dp_dsc_nearest_valid_bpp(i915, min_bpp, 
crtc_state->pipe_bpp);
+
slots = intel_dp_mst_find_vcpi_slots_for_bpp(encoder, crtc_state, 
max_bpp,
 min_bpp, limits,
 conn_state, 2 * 3, true);
@@ -235,28 +285,6 @@ static int intel_dp_dsc_mst_compute_link_config(struct 
intel_encoder *encoder,
if (slots < 0)
return slots;
 
-   last_compressed_bpp = crtc_state->dsc.compressed_bpp;
-
-   crtc_state->dsc.compressed_bpp = intel_dp_dsc_nearest_valid_bpp(i915,
-   
last_compressed_bpp,
-   
crtc_state->pipe_bpp);
-
-   if (crtc_state->dsc.compressed_bpp != last_compressed_bpp)
-   need_timeslot_recalc = true;
-
-   /*
-* Apparently some MST hubs dislike if vcpi slots are not matching 
precisely
-* the actual compressed bpp we use.
-*/
-   if (need_timeslot_recalc) {
-   slots = intel_dp_mst_find_vcpi_slots_for_bpp(encoder, 
crtc_state,
-

Re: [Intel-gfx] [PATCH 02/12] drm/i915: Introduce intel_csc_matrix struct




On 3/29/2023 7:19 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Introduce a structure that can hold our CSC matrices. In there
we shall have the preoffsets, postoffsets, and coefficients,
all in platform specific format (at least for now).

We shall start by converting the ilk+ code to make use of
the new structure. chv will come later.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/intel_color.c| 188 +-
  .../drm/i915/display/intel_display_types.h|   6 +
  2 files changed, 97 insertions(+), 97 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 3c3e2f5a5cde..b1059e0c0665 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -120,40 +120,42 @@ struct intel_color_funcs {
  #define ILK_CSC_COEFF_LIMITED_RANGE ((235 - 16) << (12 - 8)) /* exponent 0 */
  #define ILK_CSC_POSTOFF_LIMITED_RANGE (16 << (12 - 8))
  
-/* Nop pre/post offsets */

-static const u16 ilk_csc_off_zero[3] = {};
-
-/* Identity matrix */
-static const u16 ilk_csc_coeff_identity[9] = {
-   ILK_CSC_COEFF_1_0, 0, 0,
-   0, ILK_CSC_COEFF_1_0, 0,
-   0, 0, ILK_CSC_COEFF_1_0,
-};
-
-/* Limited range RGB post offsets */
-static const u16 ilk_csc_postoff_limited_range[3] = {
-   ILK_CSC_POSTOFF_LIMITED_RANGE,
-   ILK_CSC_POSTOFF_LIMITED_RANGE,
-   ILK_CSC_POSTOFF_LIMITED_RANGE,
+static const struct intel_csc_matrix ilk_csc_matrix_identity = {
+   .preoff = {},
+   .coeff = {
+   ILK_CSC_COEFF_1_0, 0, 0,
+   0, ILK_CSC_COEFF_1_0, 0,
+   0, 0, ILK_CSC_COEFF_1_0,
+   },
+   .postoff = {},
  };
  
  /* Full range RGB -> limited range RGB matrix */

-static const u16 ilk_csc_coeff_limited_range[9] = {
-   ILK_CSC_COEFF_LIMITED_RANGE, 0, 0,
-   0, ILK_CSC_COEFF_LIMITED_RANGE, 0,
-   0, 0, ILK_CSC_COEFF_LIMITED_RANGE,
+static const struct intel_csc_matrix ilk_csc_matrix_limited_range = {
+   .preoff = {},
+   .coeff = {
+   ILK_CSC_COEFF_LIMITED_RANGE, 0, 0,
+   0, ILK_CSC_COEFF_LIMITED_RANGE, 0,
+   0, 0, ILK_CSC_COEFF_LIMITED_RANGE,
+   },
+   .postoff = {
+   ILK_CSC_POSTOFF_LIMITED_RANGE,
+   ILK_CSC_POSTOFF_LIMITED_RANGE,
+   ILK_CSC_POSTOFF_LIMITED_RANGE,
+   },
  };
  
  /* BT.709 full range RGB -> limited range YCbCr matrix */

-static const u16 ilk_csc_coeff_rgb_to_ycbcr[9] = {
-   0x1e08, 0x9cc0, 0xb528,
-   0x2ba8, 0x09d8, 0x37e8,
-   0xbce8, 0x9ad8, 0x1e08,
-};
-
-/* Limited range YCbCr post offsets */
-static const u16 ilk_csc_postoff_rgb_to_ycbcr[3] = {
-   0x0800, 0x0100, 0x0800,
+static const struct intel_csc_matrix ilk_csc_matrix_rgb_to_ycbcr = {
+   .preoff = {},
+   .coeff = {
+   0x1e08, 0x9cc0, 0xb528,
+   0x2ba8, 0x09d8, 0x37e8,
+   0xbce8, 0x9ad8, 0x1e08,
+   },
+   .postoff = {
+   0x0800, 0x0100, 0x0800,
+   },
  };
  
  static bool lut_is_legacy(const struct drm_property_blob *lut)

@@ -188,69 +190,66 @@ static u64 *ctm_mult_by_limited(u64 *result, const u64 
*input)
  }
  
  static void ilk_update_pipe_csc(struct intel_crtc *crtc,

-   const u16 preoff[3],
-   const u16 coeff[9],
-   const u16 postoff[3])
+   const struct intel_csc_matrix *csc)
  {
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
  
-	intel_de_write_fw(i915, PIPE_CSC_PREOFF_HI(pipe), preoff[0]);

-   intel_de_write_fw(i915, PIPE_CSC_PREOFF_ME(pipe), preoff[1]);
-   intel_de_write_fw(i915, PIPE_CSC_PREOFF_LO(pipe), preoff[2]);
+   intel_de_write_fw(i915, PIPE_CSC_PREOFF_HI(pipe), csc->preoff[0]);
+   intel_de_write_fw(i915, PIPE_CSC_PREOFF_ME(pipe), csc->preoff[1]);
+   intel_de_write_fw(i915, PIPE_CSC_PREOFF_LO(pipe), csc->preoff[2]);
  
  	intel_de_write_fw(i915, PIPE_CSC_COEFF_RY_GY(pipe),

- coeff[0] << 16 | coeff[1]);
-   intel_de_write_fw(i915, PIPE_CSC_COEFF_BY(pipe), coeff[2] << 16);
+ csc->coeff[0] << 16 | csc->coeff[1]);
+   intel_de_write_fw(i915, PIPE_CSC_COEFF_BY(pipe),
+ csc->coeff[2] << 16);
  
  	intel_de_write_fw(i915, PIPE_CSC_COEFF_RU_GU(pipe),

- coeff[3] << 16 | coeff[4]);
-   intel_de_write_fw(i915, PIPE_CSC_COEFF_BU(pipe), coeff[5] << 16);
+ csc->coeff[3] << 16 | csc->coeff[4]);
+   intel_de_write_fw(i915, PIPE_CSC_COEFF_BU(pipe),
+ csc->coeff[5] << 16);
  
  	intel_de_write_fw(i915, PIPE_CSC_COEFF_RV_GV(pipe),

- coeff[6] << 16 | coeff[7]);
-   intel_de_write_fw(i915, PIPE_CSC_COEFF_BV(pipe), coeff[8] << 16);
+ csc->coeff[

Re: [Intel-gfx] [PATCH 03/12] drm/i915: Split chv_load_cgm_csc() into pieces




On 3/29/2023 7:19 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Split chv_cgm_csc_convert_ctm() out from chv_load_cgm_csc() so
that we have functions with clear jobs. This is also how the ilk+
code is already structured.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/intel_color.c | 19 +--
  1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index b1059e0c0665..47af24e64a7e 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -399,16 +399,13 @@ static void icl_load_csc_matrix(const struct 
intel_crtc_state *crtc_state)
}
  }
  
-static void chv_load_cgm_csc(struct intel_crtc *crtc,

-const struct drm_property_blob *blob)
+static void chv_cgm_csc_convert_ctm(u16 coeffs[9],
+   const struct drm_property_blob *blob)
  {
-   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
const struct drm_color_ctm *ctm = blob->data;
-   enum pipe pipe = crtc->pipe;
-   u16 coeffs[9];
int i;
  
-	for (i = 0; i < ARRAY_SIZE(coeffs); i++) {

+   for (i = 0; i < 9; i++) {


Can still use ARRAY_SIZE(coeffs).

In any case the patch looks good to me.

Reviewed-by: Ankit Nautiyal 



u64 abs_coeff = ((1ULL << 63) - 1) & ctm->matrix[i];
  
  		/* Round coefficient. */

@@ -425,6 +422,16 @@ static void chv_load_cgm_csc(struct intel_crtc *crtc,
coeffs[i] |= ((abs_coeff >> 32) & 7) << 12;
coeffs[i] |= (abs_coeff >> 20) & 0xfff;
}
+}
+
+static void chv_load_cgm_csc(struct intel_crtc *crtc,
+const struct drm_property_blob *blob)
+{
+   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
+   u16 coeffs[9];
+
+   chv_cgm_csc_convert_ctm(coeffs, blob);
  
  	intel_de_write_fw(i915, CGM_PIPE_CSC_COEFF01(pipe),

  coeffs[1] << 16 | coeffs[0]);

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers (rev2)

== Series Details ==

Series: series starting with [1/8] drm/gma500: Use 
drm_aperture_remove_conflicting_pci_framebuffers (rev2)
URL   : https://patchwork.freedesktop.org/series/116115/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/116115/revisions/2/mbox/ not 
applied
Patch is empty.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To record the empty patch as an empty commit, run "git am --allow-empty".
To restore the original branch and stop patching, run "git am --abort".
Build failed, no error log produced

Re: [Intel-gfx] [PATCH 1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers

2023-04-06 Thread Javier Martinez Canillas

Thomas Zimmermann  writes:

[...]

>>> +EXPORT_SYMBOL(__aperture_remove_legacy_vga_devices);
>> 
>> I would just call this symbol aperture_remove_legacy_vga_devices() as
>> mentioned, the fact that aperture_remove_conflicting_pci_devices() use it
>> internally is an implementation detail IMO. But it's an exported symbol so
>> the naming should be consistent.
>
> That prefix __ is supposed to indicate that it's not a all-in-one 
> solution. Most of all, it doesn't do sysfb_disable(). The helper is 
> meant to be used as part of a larger function. I tried to outline this 
> in the comment, where I say that drivers should first aquire framebuffer 
> ownership and then call this helper. If naming isn't a showstopper, I'd 
> like to keep the underscores.
>

Sure, I see that we have other symbols exported in DRM that have a __
prefix in their name. So maybe I am the one who was confused on the
meaning of it.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [Intel-gfx] [PATCH 04/12] drm/i915: Start using struct intel_csc_matrix for chv cgm csc




On 3/29/2023 7:19 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Convert chv_cgm_csc_convert_ctm() over to using the nee


nitpick: typo: new.

Otherwise LGTM.

Reviewed-by: Ankit Nautiyal 


intel_csc_matrix structure. No pre/post offsets on this
hardware so only the coefficients get filled out.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/intel_color.c | 24 +++---
  1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 47af24e64a7e..a76cea4ab1ec 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -399,7 +399,7 @@ static void icl_load_csc_matrix(const struct 
intel_crtc_state *crtc_state)
}
  }
  
-static void chv_cgm_csc_convert_ctm(u16 coeffs[9],

+static void chv_cgm_csc_convert_ctm(struct intel_csc_matrix *csc,
const struct drm_property_blob *blob)
  {
const struct drm_color_ctm *ctm = blob->data;
@@ -413,14 +413,14 @@ static void chv_cgm_csc_convert_ctm(u16 coeffs[9],
/* Clamp to hardware limits. */
abs_coeff = clamp_val(abs_coeff, 0, CTM_COEFF_8_0 - 1);
  
-		coeffs[i] = 0;

+   csc->coeff[i] = 0;
  
  		/* Write coefficients in S3.12 format. */

if (ctm->matrix[i] & (1ULL << 63))
-   coeffs[i] |= 1 << 15;
+   csc->coeff[i] |= 1 << 15;
  
-		coeffs[i] |= ((abs_coeff >> 32) & 7) << 12;

-   coeffs[i] |= (abs_coeff >> 20) & 0xfff;
+   csc->coeff[i] |= ((abs_coeff >> 32) & 7) << 12;
+   csc->coeff[i] |= (abs_coeff >> 20) & 0xfff;
}
  }
  
@@ -429,20 +429,20 @@ static void chv_load_cgm_csc(struct intel_crtc *crtc,

  {
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
-   u16 coeffs[9];
+   struct intel_csc_matrix tmp;
  
-	chv_cgm_csc_convert_ctm(coeffs, blob);

+   chv_cgm_csc_convert_ctm(&tmp, blob);
  
  	intel_de_write_fw(i915, CGM_PIPE_CSC_COEFF01(pipe),

- coeffs[1] << 16 | coeffs[0]);
+ tmp.coeff[1] << 16 | tmp.coeff[0]);
intel_de_write_fw(i915, CGM_PIPE_CSC_COEFF23(pipe),
- coeffs[3] << 16 | coeffs[2]);
+ tmp.coeff[3] << 16 | tmp.coeff[2]);
intel_de_write_fw(i915, CGM_PIPE_CSC_COEFF45(pipe),
- coeffs[5] << 16 | coeffs[4]);
+ tmp.coeff[5] << 16 | tmp.coeff[4]);
intel_de_write_fw(i915, CGM_PIPE_CSC_COEFF67(pipe),
- coeffs[7] << 16 | coeffs[6]);
+ tmp.coeff[7] << 16 | tmp.coeff[6]);
intel_de_write_fw(i915, CGM_PIPE_CSC_COEFF8(pipe),
- coeffs[8]);
+ tmp.coeff[8]);
  }
  
  /* convert hw value with given bit_precision to lut property val */

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set cache at BO creation

2023-04-06 Thread Matthew Auld

On Sat, 1 Apr 2023 at 07:37,  wrote:
>
> From: Fei Yang 
>
> To comply with the design that buffer objects shall have immutable
> cache setting through out its life cycle, {set, get}_caching ioctl's
> are no longer supported from MTL onward. With that change caching
> policy can only be set at object creation time. The current code
> applies a default (platform dependent) cache setting for all objects.
> However this is not optimal for performance tuning. The patch extends
> the existing gem_create uAPI to let user set PAT index for the object
> at creation time.
> The new extension is platform independent, so UMD's can switch to using
> this extension for older platforms as well, while {set, get}_caching are
> still supported on these legacy paltforms for compatibility reason.

Do we forbid {set, get}_caching, when combined with this new extension
on the same BO? There is some documentation in @cache_dirty. The
concern is being able to subvert the flush-on-acquire for non-LLC.

>
> Cc: Chris Wilson 
> Cc: Matt Roper 
> Signed-off-by: Fei Yang 
> Reviewed-by: Andi Shyti 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_create.c | 33 
>  include/uapi/drm/i915_drm.h| 36 ++
>  tools/include/uapi/drm/i915_drm.h  | 36 ++
>  3 files changed, 105 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_create.c
> index e76c9703680e..1c6e2034d28e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
> @@ -244,6 +244,7 @@ struct create_ext {
> unsigned int n_placements;
> unsigned int placement_mask;
> unsigned long flags;
> +   unsigned int pat_index;
>  };
>
>  static void repr_placements(char *buf, size_t size,
> @@ -393,11 +394,39 @@ static int ext_set_protected(struct i915_user_extension 
> __user *base, void *data
> return 0;
>  }
>
> +static int ext_set_pat(struct i915_user_extension __user *base, void *data)
> +{
> +   struct create_ext *ext_data = data;
> +   struct drm_i915_private *i915 = ext_data->i915;
> +   struct drm_i915_gem_create_ext_set_pat ext;
> +   unsigned int max_pat_index;
> +
> +   BUILD_BUG_ON(sizeof(struct drm_i915_gem_create_ext_set_pat) !=
> +offsetofend(struct drm_i915_gem_create_ext_set_pat, 
> rsvd));
> +
> +   if (copy_from_user(&ext, base, sizeof(ext)))
> +   return -EFAULT;
> +
> +   max_pat_index = INTEL_INFO(i915)->max_pat_index;
> +
> +   if (ext.pat_index > max_pat_index) {
> +   drm_dbg(&i915->drm, "PAT index is invalid: %u\n",
> +   ext.pat_index);
> +   return -EINVAL;
> +   }
> +
> +   ext_data->pat_index = ext.pat_index;
> +
> +   return 0;
> +}
> +
>  static const i915_user_extension_fn create_extensions[] = {
> [I915_GEM_CREATE_EXT_MEMORY_REGIONS] = ext_set_placements,
> [I915_GEM_CREATE_EXT_PROTECTED_CONTENT] = ext_set_protected,
> +   [I915_GEM_CREATE_EXT_SET_PAT] = ext_set_pat,
>  };
>
> +#define PAT_INDEX_NOT_SET  0x
>  /**
>   * Creates a new mm object and returns a handle to it.
>   * @dev: drm device pointer
> @@ -417,6 +446,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
> *data,
> if (args->flags & ~I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS)
> return -EINVAL;
>
> +   ext_data.pat_index = PAT_INDEX_NOT_SET;
> ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
>create_extensions,
>ARRAY_SIZE(create_extensions),
> @@ -453,5 +483,8 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
> *data,
> if (IS_ERR(obj))
> return PTR_ERR(obj);
>
> +   if (ext_data.pat_index != PAT_INDEX_NOT_SET)
> +   i915_gem_object_set_pat_index(obj, ext_data.pat_index);
> +
> return i915_gem_publish(obj, file, &args->size, &args->handle);
>  }
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index dba7c5a5b25e..03c5c314846e 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -3630,9 +3630,13 @@ struct drm_i915_gem_create_ext {
>  *
>  * For I915_GEM_CREATE_EXT_PROTECTED_CONTENT usage see
>  * struct drm_i915_gem_create_ext_protected_content.
> +*
> +* For I915_GEM_CREATE_EXT_SET_PAT usage see
> +* struct drm_i915_gem_create_ext_set_pat.
>  */
>  #define I915_GEM_CREATE_EXT_MEMORY_REGIONS 0
>  #define I915_GEM_CREATE_EXT_PROTECTED_CONTENT 1
> +#define I915_GEM_CREATE_EXT_SET_PAT 2
> __u64 extensions;
>  };
>
> @@ -3747,6 +3751,38 @@ struct drm_i915_gem_create_ext_protected_content {
> __u32 flags;
>  };
>
> +/**
> + * struct drm_i915_gem_create_ext_set_pat - The
> + * I915_GEM_CREATE_EXT_SET_PAT extension.
> + *

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Store ilk+ csc matrices in the crtc state




On 3/29/2023 7:19 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Embed a pair of intel_csc_matrix structs in the crtc state,
and fill them out appropriately during atomic_check().

Since pre-ivb platforms don't have programmable post offsets
we shall leave those zeroed, mainly in preparation for
state readout+check.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/intel_color.c| 82 ++-
  .../drm/i915/display/intel_display_types.h|  2 +
  2 files changed, 63 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index a76cea4ab1ec..a6f7eba59e12 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -158,6 +158,11 @@ static const struct intel_csc_matrix 
ilk_csc_matrix_rgb_to_ycbcr = {
},
  };
  
+static void intel_csc_clear(struct intel_csc_matrix *csc)

+{
+   memset(csc, 0, sizeof(*csc));
+}
+
  static bool lut_is_legacy(const struct drm_property_blob *lut)
  {
return lut && drm_color_lut_size(lut) == LEGACY_LUT_LENGTH;
@@ -292,10 +297,21 @@ static bool ilk_csc_limited_range(const struct 
intel_crtc_state *crtc_state)
return !ilk_lut_limited_range(crtc_state);
  }
  
+static void ilk_csc_copy(struct drm_i915_private *i915,

+struct intel_csc_matrix *dst,
+const struct intel_csc_matrix *src)
+{
+   *dst = *src;
+
+   if (DISPLAY_VER(i915) < 7)
+   memset(dst->postoff, 0, sizeof(dst->postoff));
+}
+
  static void ilk_csc_convert_ctm(const struct intel_crtc_state *crtc_state,
struct intel_csc_matrix *csc,
bool limited_color_range)
  {
+   struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
const struct drm_color_ctm *ctm = crtc_state->hw.ctm->data;
const u64 *input;
u64 temp[9];
@@ -303,9 +319,9 @@ static void ilk_csc_convert_ctm(const struct 
intel_crtc_state *crtc_state,
  
  	/* for preoff/postoff */

if (limited_color_range)
-   *csc = ilk_csc_matrix_limited_range;
+   ilk_csc_copy(i915, csc, &ilk_csc_matrix_limited_range);
else
-   *csc = ilk_csc_matrix_identity;
+   ilk_csc_copy(i915, csc, &ilk_csc_matrix_identity);
  
  	if (limited_color_range)

input = ctm_mult_by_limited(temp, ctm->matrix);
@@ -351,22 +367,17 @@ static void ilk_csc_convert_ctm(const struct 
intel_crtc_state *crtc_state,
}
  }
  
-static void ilk_load_csc_matrix(const struct intel_crtc_state *crtc_state)

+static void ilk_assign_csc(struct intel_crtc_state *crtc_state)
  {
-   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
-   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+   struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
bool limited_color_range = ilk_csc_limited_range(crtc_state);
  
  	if (crtc_state->hw.ctm) {

-   struct intel_csc_matrix tmp;
-
-   ilk_csc_convert_ctm(crtc_state, &tmp, limited_color_range);
-
-   ilk_update_pipe_csc(crtc, &tmp);
+   ilk_csc_convert_ctm(crtc_state, &crtc_state->csc, 
limited_color_range);
} else if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB) {
-   ilk_update_pipe_csc(crtc, &ilk_csc_matrix_rgb_to_ycbcr);
+   ilk_csc_copy(i915, &crtc_state->csc, 
&ilk_csc_matrix_rgb_to_ycbcr);
} else if (limited_color_range) {
-   ilk_update_pipe_csc(crtc, &ilk_csc_matrix_limited_range);
+   ilk_csc_copy(i915, &crtc_state->csc, 
&ilk_csc_matrix_limited_range);
} else if (crtc_state->csc_enable) {
/*
 * On GLK both pipe CSC and degamma LUT are controlled
@@ -376,29 +387,50 @@ static void ilk_load_csc_matrix(const struct 
intel_crtc_state *crtc_state)
 */
drm_WARN_ON(&i915->drm, !IS_GEMINILAKE(i915));
  
-		ilk_update_pipe_csc(crtc, &ilk_csc_matrix_identity);

+   ilk_csc_copy(i915, &crtc_state->csc, &ilk_csc_matrix_identity);
+   } else {
+   intel_csc_clear(&crtc_state->csc);
}
  }
  
-static void icl_load_csc_matrix(const struct intel_crtc_state *crtc_state)

+static void ilk_load_csc_matrix(const struct intel_crtc_state *crtc_state)
  {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
  
+	if (crtc_state->csc_enable)

+   ilk_update_pipe_csc(crtc, &crtc_state->csc);
+}
+
+static void icl_assign_csc(struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
+
if (crtc_state->hw.ctm) {
-   struct intel_csc_matrix tmp;
-
-   ilk_csc_convert_ctm(crtc_state, &tmp, false);
-
-   ilk_update_pipe_csc(crtc, &tmp);
+

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Disable PL1 power limit when loading GuC firmware

2023-04-06 Thread kernel test robot

Hi Ashutosh,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-tip/drm-tip]

url:
https://github.com/intel-lab-lkp/linux/commits/Ashutosh-Dixit/drm-i915-hwmon-Get-mutex-and-rpm-ref-just-once-in-hwm_power_max_write/20230406-124659
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
patch link:
https://lore.kernel.org/r/20230406044522.3108359-3-ashutosh.dixit%40intel.com
patch subject: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Disable PL1 power limit 
when loading GuC firmware
config: i386-randconfig-a002-20230403 
(https://download.01.org/0day-ci/archive/20230406/202304061654.yjntbbxy-...@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project 
f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/b4aa935db7f0b46437cdaa39f0149ad835ceb73c
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Ashutosh-Dixit/drm-i915-hwmon-Get-mutex-and-rpm-ref-just-once-in-hwm_power_max_write/20230406-124659
git checkout b4aa935db7f0b46437cdaa39f0149ad835ceb73c
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=i386 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot 
| Link: 
https://lore.kernel.org/oe-kbuild-all/202304061654.yjntbbxy-...@intel.com/

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/i915/gt/uc/intel_uc.c:484:6: warning: variable 'pl1en' is 
>> used uninitialized whenever 'if' condition is true 
>> [-Wsometimes-uninitialized]
   if (ret)
   ^~~
   drivers/gpu/drm/i915/gt/uc/intel_uc.c:573:41: note: uninitialized use occurs 
here
   i915_hwmon_power_max_restore(gt->i915, pl1en);
  ^
   drivers/gpu/drm/i915/gt/uc/intel_uc.c:484:2: note: remove the 'if' if its 
condition is always false
   if (ret)
   ^~~~
   drivers/gpu/drm/i915/gt/uc/intel_uc.c:475:6: warning: variable 'pl1en' is 
used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
   if (!intel_uc_fw_is_loadable(&guc->fw)) {
   ^~
   drivers/gpu/drm/i915/gt/uc/intel_uc.c:573:41: note: uninitialized use occurs 
here
   i915_hwmon_power_max_restore(gt->i915, pl1en);
  ^
   drivers/gpu/drm/i915/gt/uc/intel_uc.c:475:2: note: remove the 'if' if its 
condition is always false
   if (!intel_uc_fw_is_loadable(&guc->fw)) {
   ^
   drivers/gpu/drm/i915/gt/uc/intel_uc.c:465:12: note: initialize the variable 
'pl1en' to silence this warning
   bool pl1en;
 ^
  = 0
   2 warnings generated.


vim +484 drivers/gpu/drm/i915/gt/uc/intel_uc.c

afd088ac05f120d drivers/gpu/drm/i915/gt/uc/intel_uc.c John Harrison  
2022-01-06  457  
6fbeda0bfd210f9 drivers/gpu/drm/i915/gt/uc/intel_uc.c Michal Wajdeczko   
2020-01-10  458  static int __uc_init_hw(struct intel_uc *uc)
6fbeda0bfd210f9 drivers/gpu/drm/i915/gt/uc/intel_uc.c Michal Wajdeczko   
2020-01-10  459  {
2f8c06cb6622b55 drivers/gpu/drm/i915/gt/uc/intel_uc.c Michal Wajdeczko   
2023-01-28  460struct intel_gt *gt = uc_to_gt(uc);
2f8c06cb6622b55 drivers/gpu/drm/i915/gt/uc/intel_uc.c Michal Wajdeczko   
2023-01-28  461struct drm_i915_private *i915 = gt->i915;
6fbeda0bfd210f9 drivers/gpu/drm/i915/gt/uc/intel_uc.c Michal Wajdeczko   
2020-01-10  462struct intel_guc *guc = &uc->guc;
6fbeda0bfd210f9 drivers/gpu/drm/i915/gt/uc/intel_uc.c Michal Wajdeczko   
2020-01-10  463struct intel_huc *huc = &uc->huc;
6fbeda0bfd210f9 drivers/gpu/drm/i915/gt/uc/intel_uc.c Michal Wajdeczko   
2020-01-10  464int ret, attempts;
b4aa935db7f0b46 drivers/gpu/drm/i915/gt/uc/intel_uc.c Ashutosh Dixit 
2023-04-05  465bool pl1en;
6fbeda0bfd210f9 drivers/gpu/drm/i915/gt/uc/intel_uc.c Michal Wajdeczko   
2020-01-10  466  
6fbeda0bfd210f9 drivers/gpu/drm/i915/gt/uc/intel_uc.c Michal Wajdeczko   
2020-01-10  467GEM_BUG_ON(!intel_uc_supports_guc(uc));
bfe5a40a7b9a967 drivers/gpu/drm/i915/gt/uc/intel_uc.c Daniele Ceraolo Spurio 
2020-02-18  468GEM_BUG_ON(!intel_uc_wants_guc(uc));
356c484822e6ac9 drivers/gpu/drm/i915/gt/uc/in

Re: [Intel-gfx] [PATCH 03/12] drm/i915: Split chv_load_cgm_csc() into pieces




On 4/6/2023 2:33 PM, Nautiyal, Ankit K wrote:


On 3/29/2023 7:19 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Split chv_cgm_csc_convert_ctm() out from chv_load_cgm_csc() so
that we have functions with clear jobs. This is also how the ilk+
code is already structured.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/intel_color.c | 19 +--
  1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c

index b1059e0c0665..47af24e64a7e 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -399,16 +399,13 @@ static void icl_load_csc_matrix(const struct 
intel_crtc_state *crtc_state)

  }
  }
  -static void chv_load_cgm_csc(struct intel_crtc *crtc,
- const struct drm_property_blob *blob)
+static void chv_cgm_csc_convert_ctm(u16 coeffs[9],
+    const struct drm_property_blob *blob)
  {
-    struct drm_i915_private *i915 = to_i915(crtc->base.dev);
  const struct drm_color_ctm *ctm = blob->data;
-    enum pipe pipe = crtc->pipe;
-    u16 coeffs[9];
  int i;
  -    for (i = 0; i < ARRAY_SIZE(coeffs); i++) {
+    for (i = 0; i < 9; i++) {


Can still use ARRAY_SIZE(coeffs).


This comment can be ignored.

I realized, we are using 9 throughout to iterate over the coefficients, 
so lets keep it here too.


Patch is good as is.




In any case the patch looks good to me.

Reviewed-by: Ankit Nautiyal 



  u64 abs_coeff = ((1ULL << 63) - 1) & ctm->matrix[i];
    /* Round coefficient. */
@@ -425,6 +422,16 @@ static void chv_load_cgm_csc(struct intel_crtc 
*crtc,

  coeffs[i] |= ((abs_coeff >> 32) & 7) << 12;
  coeffs[i] |= (abs_coeff >> 20) & 0xfff;
  }
+}
+
+static void chv_load_cgm_csc(struct intel_crtc *crtc,
+ const struct drm_property_blob *blob)
+{
+    struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+    enum pipe pipe = crtc->pipe;
+    u16 coeffs[9];
+
+    chv_cgm_csc_convert_ctm(coeffs, blob);
    intel_de_write_fw(i915, CGM_PIPE_CSC_COEFF01(pipe),
    coeffs[1] << 16 | coeffs[0]);

Re: [Intel-gfx] [PATCH 06/12] drm/i915: Utilize crtc_state->csc on chv




On 3/29/2023 7:19 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Store the chv cgm csc matrix in the crtc state as well. We
shall store it in the same place where we store the ilk+
pipe csc matrix (as opposed to the output csc matrix).

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/intel_color.c | 35 +-
  1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index a6f7eba59e12..7e8820583942 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -431,10 +431,10 @@ static void icl_load_csc_matrix(const struct 
intel_crtc_state *crtc_state)
icl_update_output_csc(crtc, &crtc_state->output_csc);
  }
  
-static void chv_cgm_csc_convert_ctm(struct intel_csc_matrix *csc,

-   const struct drm_property_blob *blob)
+static void chv_cgm_csc_convert_ctm(const struct intel_crtc_state *crtc_state,
+   struct intel_csc_matrix *csc)
  {
-   const struct drm_color_ctm *ctm = blob->data;
+   const struct drm_color_ctm *ctm = crtc_state->hw.ctm->data;
int i;
  
  	for (i = 0; i < 9; i++) {

@@ -457,24 +457,30 @@ static void chv_cgm_csc_convert_ctm(struct 
intel_csc_matrix *csc,
  }
  
  static void chv_load_cgm_csc(struct intel_crtc *crtc,

-const struct drm_property_blob *blob)
+const struct intel_csc_matrix *csc)
  {
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
-   struct intel_csc_matrix tmp;
-
-   chv_cgm_csc_convert_ctm(&tmp, blob);
  
  	intel_de_write_fw(i915, CGM_PIPE_CSC_COEFF01(pipe),

- tmp.coeff[1] << 16 | tmp.coeff[0]);
+ csc->coeff[1] << 16 | csc->coeff[0]);
intel_de_write_fw(i915, CGM_PIPE_CSC_COEFF23(pipe),
- tmp.coeff[3] << 16 | tmp.coeff[2]);
+ csc->coeff[3] << 16 | csc->coeff[2]);
intel_de_write_fw(i915, CGM_PIPE_CSC_COEFF45(pipe),
- tmp.coeff[5] << 16 | tmp.coeff[4]);
+ csc->coeff[5] << 16 | csc->coeff[4]);
intel_de_write_fw(i915, CGM_PIPE_CSC_COEFF67(pipe),
- tmp.coeff[7] << 16 | tmp.coeff[6]);
+ csc->coeff[7] << 16 | csc->coeff[6]);
intel_de_write_fw(i915, CGM_PIPE_CSC_COEFF8(pipe),
- tmp.coeff[8]);
+ csc->coeff[8]);
+}
+
+static void chv_assign_csc(struct intel_crtc_state *crtc_state)
+{
+   if (crtc_state->hw.ctm) {
+   chv_cgm_csc_convert_ctm(crtc_state, &crtc_state->csc);
+   } else {
+   intel_csc_clear(&crtc_state->csc);
+   }


It does make sense to have a block for csc and another for output_csc, 
analogous to the load part.


We are anyway adding drm_Warn later, so braces can be dropped here and 
introduced in patch adding warn_ons


Otherwise the Patch looks good to me.

Reviewed-by: Ankit Nautiyal 



  }
  
  /* convert hw value with given bit_precision to lut property val */

@@ -1442,10 +1448,9 @@ static void chv_load_luts(const struct intel_crtc_state 
*crtc_state)
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
const struct drm_property_blob *pre_csc_lut = crtc_state->pre_csc_lut;
const struct drm_property_blob *post_csc_lut = crtc_state->post_csc_lut;
-   const struct drm_property_blob *ctm = crtc_state->hw.ctm;
  
  	if (crtc_state->cgm_mode & CGM_PIPE_MODE_CSC)

-   chv_load_cgm_csc(crtc, ctm);
+   chv_load_cgm_csc(crtc, &crtc_state->csc);
  
  	if (crtc_state->cgm_mode & CGM_PIPE_MODE_DEGAMMA)

chv_load_cgm_degamma(crtc, pre_csc_lut);
@@ -1872,6 +1877,8 @@ static int chv_color_check(struct intel_crtc_state 
*crtc_state)
  
  	intel_assign_luts(crtc_state);
  
+	chv_assign_csc(crtc_state);

+
crtc_state->preload_luts = chv_can_preload_luts(crtc_state);
  
  	return 0;

Re: [Intel-gfx] [PATCH 07/12] drm/i915: Sprinke a few sanity check WARNS during csc assignment


LGTM.

Reviewed-by: Ankit Nautiyal 

On 3/29/2023 7:19 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Make sure the csc enable bit(s) match the way we're about to
fill the csc matrices.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/intel_color.c | 22 ++
  1 file changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 7e8820583942..2988c91d8ff6 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -373,10 +373,16 @@ static void ilk_assign_csc(struct intel_crtc_state 
*crtc_state)
bool limited_color_range = ilk_csc_limited_range(crtc_state);
  
  	if (crtc_state->hw.ctm) {

+   drm_WARN_ON(&i915->drm, !crtc_state->csc_enable);
+
ilk_csc_convert_ctm(crtc_state, &crtc_state->csc, 
limited_color_range);
} else if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB) {
+   drm_WARN_ON(&i915->drm, !crtc_state->csc_enable);
+
ilk_csc_copy(i915, &crtc_state->csc, 
&ilk_csc_matrix_rgb_to_ycbcr);
} else if (limited_color_range) {
+   drm_WARN_ON(&i915->drm, !crtc_state->csc_enable);
+
ilk_csc_copy(i915, &crtc_state->csc, 
&ilk_csc_matrix_limited_range);
} else if (crtc_state->csc_enable) {
/*
@@ -406,16 +412,26 @@ static void icl_assign_csc(struct intel_crtc_state 
*crtc_state)
struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
  
  	if (crtc_state->hw.ctm) {

+   drm_WARN_ON(&i915->drm, (crtc_state->csc_mode & ICL_CSC_ENABLE) 
== 0);
+
ilk_csc_convert_ctm(crtc_state, &crtc_state->csc, false);
} else {
+   drm_WARN_ON(&i915->drm, (crtc_state->csc_mode & ICL_CSC_ENABLE) 
!= 0);
+
intel_csc_clear(&crtc_state->csc);
}
  
  	if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB) {

+   drm_WARN_ON(&i915->drm, (crtc_state->csc_mode & 
ICL_OUTPUT_CSC_ENABLE) == 0);
+
ilk_csc_copy(i915, &crtc_state->output_csc, 
&ilk_csc_matrix_rgb_to_ycbcr);
} else if (crtc_state->limited_color_range) {
+   drm_WARN_ON(&i915->drm, (crtc_state->csc_mode & 
ICL_OUTPUT_CSC_ENABLE) == 0);
+
ilk_csc_copy(i915, &crtc_state->output_csc, 
&ilk_csc_matrix_limited_range);
} else {
+   drm_WARN_ON(&i915->drm, (crtc_state->csc_mode & 
ICL_OUTPUT_CSC_ENABLE) != 0);
+
intel_csc_clear(&crtc_state->output_csc);
}
  }
@@ -476,9 +492,15 @@ static void chv_load_cgm_csc(struct intel_crtc *crtc,
  
  static void chv_assign_csc(struct intel_crtc_state *crtc_state)

  {
+   struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
+
if (crtc_state->hw.ctm) {
+   drm_WARN_ON(&i915->drm, (crtc_state->cgm_mode & 
CGM_PIPE_MODE_CSC) == 0);
+
chv_cgm_csc_convert_ctm(crtc_state, &crtc_state->csc);
} else {
+   drm_WARN_ON(&i915->drm, (crtc_state->cgm_mode & 
CGM_PIPE_MODE_CSC) != 0);
+
intel_csc_clear(&crtc_state->csc);
}
  }

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Query compressed bpp properly using correct DPCD and DP Spec info

== Series Details ==

Series: drm/i915: Query compressed bpp properly using correct DPCD and DP Spec 
info
URL   : https://patchwork.freedesktop.org/series/116179/
State : warning

== Summary ==

Error: dim checkpatch failed
3cce658f5bbb drm/i915: Query compressed bpp properly using correct DPCD and DP 
Spec info
-:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#7: 
Currently we seem to be using wrong DPCD register for reading compressed bpps,

-:87: WARNING:LONG_LINE: line length of 113 exceeds 100 columns
#87: FILE: drivers/gpu/drm/i915/display/intel_dp_mst.c:274:
+   max_bpp = min(max_bpp, 
dsc_max_sink_compressed_bppx16(intel_dp->dsc_dpcd, crtc_state, max_bpp / 3) >> 
4);

total: 0 errors, 2 warnings, 0 checks, 100 lines checked

Re: [Intel-gfx] [PATCH 08/12] drm/i915: Add hardware csc readout for ilk+


Patch LGTM.

Perhaps TODO part, to check for case of PSR and if DC states are already 
off can be taken as separate patch.


Reviewed-by: Ankit Nautiyal 

On 3/29/2023 7:19 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Read out the pipe/output csc matrices on ilk+ and stash the results
(in the hardware specific format) into the appropriate place
in the crtc state.

Note that on skl/glk/icl the pipe csc unit suffers from an issue
where *reads* of the coefficient/offset registers also disarm
the double buffer update (if currently armed via CSC_MODE write).
So it's rather important that the readout only happens after the
csc registers have been latched. Fortunately the state checker
only runs after the start of vblank where the latching happens.

And on skl/glk the DMC + CSC register read has the potential to
corrupt the latched CSC register values, so let's add a comment
reminding us that the DC states should remain off until the
readout has been completed.

TODO: maybe we could somehow check to make sure PSR has in fact
latched the new register values already, and that DC states
have been off all along?

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/intel_color.c   | 133 +++
  drivers/gpu/drm/i915/display/intel_display.c |   6 +
  2 files changed, 139 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 2988c91d8ff6..86b0d8260574 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -25,6 +25,7 @@
  #include "i915_reg.h"
  #include "intel_color.h"
  #include "intel_de.h"
+#include "intel_display_power.h"
  #include "intel_display_types.h"
  #include "intel_dsb.h"
  
@@ -70,6 +71,11 @@ struct intel_color_funcs {

  const struct drm_property_blob *blob1,
  const struct drm_property_blob *blob2,
  bool is_pre_csc_lut);
+   /*
+* Read out the CSCs (if any) from the hardware into the
+* software state. Used by eg. the hardware state checker.
+*/
+   void (*read_csc)(struct intel_crtc_state *crtc_state);
  };
  
  #define CTM_COEFF_SIGN	(1ULL << 63)

@@ -227,6 +233,72 @@ static void ilk_update_pipe_csc(struct intel_crtc *crtc,
intel_de_write_fw(i915, PIPE_CSC_POSTOFF_LO(pipe), csc->postoff[2]);
  }
  
+static void ilk_read_pipe_csc(struct intel_crtc *crtc,

+ struct intel_csc_matrix *csc)
+{
+   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
+   u32 tmp;
+
+   csc->preoff[0] = intel_de_read_fw(i915, PIPE_CSC_PREOFF_HI(pipe));
+   csc->preoff[1] = intel_de_read_fw(i915, PIPE_CSC_PREOFF_ME(pipe));
+   csc->preoff[2] = intel_de_read_fw(i915, PIPE_CSC_PREOFF_LO(pipe));
+
+   tmp = intel_de_read_fw(i915, PIPE_CSC_COEFF_RY_GY(pipe));
+   csc->coeff[0] = tmp >> 16;
+   csc->coeff[1] = tmp & 0x;
+   tmp = intel_de_read_fw(i915, PIPE_CSC_COEFF_BY(pipe));
+   csc->coeff[2] = tmp >> 16;
+
+   tmp = intel_de_read_fw(i915, PIPE_CSC_COEFF_RU_GU(pipe));
+   csc->coeff[3] = tmp >> 16;
+   csc->coeff[4] = tmp & 0x;
+   tmp = intel_de_read_fw(i915, PIPE_CSC_COEFF_BU(pipe));
+   csc->coeff[5] = tmp >> 16;
+
+   tmp = intel_de_read_fw(i915, PIPE_CSC_COEFF_RV_GV(pipe));
+   csc->coeff[6] = tmp >> 16;
+   csc->coeff[7] = tmp & 0x;
+   tmp = intel_de_read_fw(i915, PIPE_CSC_COEFF_BV(pipe));
+   csc->coeff[8] = tmp >> 16;
+
+   if (DISPLAY_VER(i915) < 7)
+   return;
+
+   csc->postoff[0] = intel_de_read_fw(i915, PIPE_CSC_POSTOFF_HI(pipe));
+   csc->postoff[1] = intel_de_read_fw(i915, PIPE_CSC_POSTOFF_ME(pipe));
+   csc->postoff[2] = intel_de_read_fw(i915, PIPE_CSC_POSTOFF_LO(pipe));
+}
+
+static void ilk_read_csc(struct intel_crtc_state *crtc_state)
+{
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+
+   if (crtc_state->csc_enable)
+   ilk_read_pipe_csc(crtc, &crtc_state->csc);
+}
+
+static void skl_read_csc(struct intel_crtc_state *crtc_state)
+{
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+
+   /*
+* Display WA #1184: skl,glk
+* Wa_1406463849: icl
+*
+* Danger! On SKL-ICL *reads* from the CSC coeff/offset registers
+* will disarm an already armed CSC double buffer update.
+* So this must not be called while armed. Fortunately the state checker
+* readout happens only after the update has been already been latched.
+*
+* On earlier and later platforms only writes to said registers will
+* disarm the update. This is considered normal behavior and also
+* happens with various other hardware units.
+*/
+   if (crtc_state->csc_enable)
+   ilk_read_pipe_csc(crtc, &crtc_state->csc);
+}
+
  static void

Re: [Intel-gfx] [PATCH 09/12] drm/i915: Implement chv cgm csc readout


LGTM.

Reviewed-by: Ankit Nautiyal 

On 3/29/2023 7:19 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Read out the csc matrix on chv, and stash the result into the
correct spot in the crtc state.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/intel_color.c | 36 ++
  1 file changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 86b0d8260574..baadf62aabb4 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -612,6 +612,41 @@ static void chv_load_cgm_csc(struct intel_crtc *crtc,
  csc->coeff[8]);
  }
  
+static void chv_read_cgm_csc(struct intel_crtc *crtc,

+struct intel_csc_matrix *csc)
+{
+   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
+   u32 tmp;
+
+   tmp = intel_de_read_fw(i915, CGM_PIPE_CSC_COEFF01(pipe));
+   csc->coeff[0] = tmp & 0x;
+   csc->coeff[1] = tmp >> 16;
+
+   tmp = intel_de_read_fw(i915, CGM_PIPE_CSC_COEFF23(pipe));
+   csc->coeff[2] = tmp & 0x;
+   csc->coeff[3] = tmp >> 16;
+
+   tmp = intel_de_read_fw(i915, CGM_PIPE_CSC_COEFF45(pipe));
+   csc->coeff[4] = tmp & 0x;
+   csc->coeff[5] = tmp >> 16;
+
+   tmp = intel_de_read_fw(i915, CGM_PIPE_CSC_COEFF67(pipe));
+   csc->coeff[6] = tmp & 0x;
+   csc->coeff[7] = tmp >> 16;
+
+   tmp = intel_de_read_fw(i915, CGM_PIPE_CSC_COEFF8(pipe));
+   csc->coeff[8] = tmp & 0x;
+}
+
+static void chv_read_csc(struct intel_crtc_state *crtc_state)
+{
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+
+   if (crtc_state->cgm_mode & CGM_PIPE_MODE_CSC)
+   chv_read_cgm_csc(crtc, &crtc_state->csc);
+}
+
  static void chv_assign_csc(struct intel_crtc_state *crtc_state)
  {
struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
@@ -3329,6 +3364,7 @@ static const struct intel_color_funcs chv_color_funcs = {
.load_luts = chv_load_luts,
.read_luts = chv_read_luts,
.lut_equal = chv_lut_equal,
+   .read_csc = chv_read_csc,
  };
  
  static const struct intel_color_funcs i965_color_funcs = {

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Query compressed bpp properly using correct DPCD and DP Spec info

== Series Details ==

Series: drm/i915: Query compressed bpp properly using correct DPCD and DP Spec 
info
URL   : https://patchwork.freedesktop.org/series/116179/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12979 -> Patchwork_116179v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116179v1/index.html

Participating hosts (36 -> 35)
--

  Missing(1): fi-snb-2520m 

Known issues


  Here are the changes found in Patchwork_116179v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rps@basic-api:
- bat-dg2-11: [PASS][1] -> [FAIL][2] ([i915#8308])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12979/bat-dg2-11/igt@i915_pm_...@basic-api.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116179v1/bat-dg2-11/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-8109u:   [PASS][3] -> [DMESG-FAIL][4] ([i915#5334])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12979/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116179v1/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@migrate:
- bat-adlp-9: [PASS][5] -> [DMESG-FAIL][6] ([i915#7699])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12979/bat-adlp-9/igt@i915_selftest@l...@migrate.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116179v1/bat-adlp-9/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@reset:
- bat-rpls-1: [PASS][7] -> [ABORT][8] ([i915#4983])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12979/bat-rpls-1/igt@i915_selftest@l...@reset.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116179v1/bat-rpls-1/igt@i915_selftest@l...@reset.html

  
 Possible fixes 

  * igt@i915_selftest@live@migrate:
- bat-dg2-11: [DMESG-WARN][9] ([i915#7699]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12979/bat-dg2-11/igt@i915_selftest@l...@migrate.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116179v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-c-dp-1:
- bat-dg2-8:  [FAIL][11] ([i915#7932]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12979/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-c-dp-1.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116179v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-c-dp-1.html

  
 Warnings 

  * igt@i915_selftest@live@reset:
- bat-rpls-2: [ABORT][13] ([i915#4983] / [i915#7913] / [i915#7981]) 
-> [ABORT][14] ([i915#4983] / [i915#7913])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12979/bat-rpls-2/igt@i915_selftest@l...@reset.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116179v1/bat-rpls-2/igt@i915_selftest@l...@reset.html

  
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
  [i915#7981]: https://gitlab.freedesktop.org/drm/intel/issues/7981
  [i915#8308]: https://gitlab.freedesktop.org/drm/intel/issues/8308


Build changes
-

  * Linux: CI_DRM_12979 -> Patchwork_116179v1

  CI-20190529: 20190529
  CI_DRM_12979: e0f93494298ec55cb7cd551251e6653df57f6b07 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7242: 32df2fea760a8b72516761657971a7edb08bd0bb @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_116179v1: e0f93494298ec55cb7cd551251e6653df57f6b07 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

b46b4059fba0 drm/i915: Query compressed bpp properly using correct DPCD and DP 
Spec info

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116179v1/index.html

Re: [Intel-gfx] [PATCH v9 06/25] kvm/vfio: Accept vfio device file from userspace

Hi Yi,

On 4/1/23 17:18, Yi Liu wrote:
> This defines KVM_DEV_VFIO_FILE* and make alias with KVM_DEV_VFIO_GROUP*.
> Old userspace uses KVM_DEV_VFIO_GROUP* works as well.
>
> Reviewed-by: Jason Gunthorpe 
> Reviewed-by: Kevin Tian 
> Tested-by: Terrence Xu 
> Tested-by: Nicolin Chen 
> Tested-by: Matthew Rosato 
> Tested-by: Yanting Jiang 
> Signed-off-by: Yi Liu 
> ---
>  Documentation/virt/kvm/devices/vfio.rst | 53 +
>  include/uapi/linux/kvm.h| 16 ++--
>  virt/kvm/vfio.c | 16 
>  3 files changed, 56 insertions(+), 29 deletions(-)
>
> diff --git a/Documentation/virt/kvm/devices/vfio.rst 
> b/Documentation/virt/kvm/devices/vfio.rst
> index 79b6811bb4f3..277d727ec1a2 100644
> --- a/Documentation/virt/kvm/devices/vfio.rst
> +++ b/Documentation/virt/kvm/devices/vfio.rst
> @@ -9,24 +9,38 @@ Device types supported:
>- KVM_DEV_TYPE_VFIO
>  
>  Only one VFIO instance may be created per VM.  The created device
> -tracks VFIO groups in use by the VM and features of those groups
> -important to the correctness and acceleration of the VM.  As groups
> -are enabled and disabled for use by the VM, KVM should be updated
> -about their presence.  When registered with KVM, a reference to the
> -VFIO-group is held by KVM.
> +tracks VFIO files (group or device) in use by the VM and features
> +of those groups/devices important to the correctness and acceleration
> +of the VM.  As groups/devices are enabled and disabled for use by the
> +VM, KVM should be updated about their presence.  When registered with
> +KVM, a reference to the VFIO file is held by KVM.
>  
>  Groups:
> -  KVM_DEV_VFIO_GROUP
> -
> -KVM_DEV_VFIO_GROUP attributes:
> -  KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device tracking
> - kvm_device_attr.addr points to an int32_t file descriptor
> - for the VFIO group.
> -  KVM_DEV_VFIO_GROUP_DEL: Remove a VFIO group from VFIO-KVM device tracking
> - kvm_device_attr.addr points to an int32_t file descriptor
> - for the VFIO group.
> -  KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: attaches a guest visible TCE table
> +  KVM_DEV_VFIO_FILE
> + alias: KVM_DEV_VFIO_GROUP
> +
> +KVM_DEV_VFIO_FILE attributes:
> +  KVM_DEV_VFIO_FILE_ADD: Add a VFIO file (group/device) to VFIO-KVM device
> + tracking
> +
> + alias: KVM_DEV_VFIO_GROUP_ADD
> +
> + kvm_device_attr.addr points to an int32_t file descriptor for the
> + VFIO file.
> +
> +  KVM_DEV_VFIO_FILE_DEL: Remove a VFIO file (group/device) from VFIO-KVM
> + device tracking
> +
> + alias: KVM_DEV_VFIO_GROUP_DEL
> +
> + kvm_device_attr.addr points to an int32_t file descriptor for the
> + VFIO file.
> +
> +  KVM_DEV_VFIO_FILE_SET_SPAPR_TCE: attaches a guest visible TCE table
>   allocated by sPAPR KVM.
> +
> + alias: KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE
> +
>   kvm_device_attr.addr points to a struct::
>  
>   struct kvm_vfio_spapr_tce {
> @@ -40,9 +54,14 @@ KVM_DEV_VFIO_GROUP attributes:
>   - @tablefd is a file descriptor for a TCE table allocated via
> KVM_CREATE_SPAPR_TCE.
>  
> + only accepts vfio group file as SPAPR has no iommufd support
So then what is the point of introducing

KVM_DEV_VFIO_FILE_SET_SPAPR_TCE at this stage?

I think would have separated the

Groups:
  KVM_DEV_VFIO_FILE
alias: KVM_DEV_VFIO_GROUP

KVM_DEV_VFIO_FILE attributes:
  KVM_DEV_VFIO_FILE_ADD: Add a VFIO file (group/device) to VFIO-KVM device
tracking

kvm_device_attr.addr points to an int32_t file descriptor for the
VFIO file.

  KVM_DEV_VFIO_FILE_DEL: Remove a VFIO file (group/device) from VFIO-KVM
device tracking

kvm_device_attr.addr points to an int32_t file descriptor for the
VFIO file.

KVM_DEV_VFIO_GROUP (legacy kvm device group restricted to the handling of VFIO 
group fd)
  KVM_DEV_VFIO_GROUP_ADD: same as KVM_DEV_VFIO_FILE_ADD for group fd only
  KVM_DEV_VFIO_GROUP_DEL: same as KVM_DEV_VFIO_FILE_DEL for group fd only
  KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: attaches a guest visible TCE table
allocated by sPAPR KVM.
kvm_device_attr.addr points to a struct::

struct kvm_vfio_spapr_tce {
__s32   groupfd;
__s32   tablefd;
};

where:

- @groupfd is a file descriptor for a VFIO group;
- @tablefd is a file descriptor for a TCE table allocated via
  KVM_CREATE_SPAPR_TCE.


You don't say anything about potential restriction, ie. what if the user calls 
KVM_DEV_VFIO_FILE with device fds while it has been using legacy 
container/group API?

Thanks

Eric

> +
>  ::
>  
> -The GROUP_ADD operation above should be invoked prior to accessing the
> +The FILE/GROUP_ADD operation above should be invoked prior to accessing the
>  device file descriptor via VFIO_GROUP_GET_DEVICE_FD in order to support
>  drivers which require a kvm pointer to be set in their .open_

Re: [Intel-gfx] [PATCH 10/12] drm/i915: Include the csc matrices in the crtc state dump




On 3/29/2023 7:20 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Include the csc matrices in the state dump. The format being
hardware specific we just dump as hex for now. Might have
to think of some way to get a bit more human readable
output...


Yeah if we can read coeff and print in decimals, will be really helpful. 
Can be taken as a separate patch.



With Checkpatch warning fixed (spaces around operands) while printing 
coeffs, this is:


Reviewed-by: Ankit Nautiyal 



Signed-off-by: Ville Syrjälä 
---
  .../drm/i915/display/intel_crtc_state_dump.c  | 43 +++
  1 file changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c 
b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
index 766633566fd6..2c410ad53ccd 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
@@ -158,6 +158,41 @@ static void intel_dump_plane_state(const struct 
intel_plane_state *plane_state)
DRM_RECT_ARG(&plane_state->uapi.dst));
  }
  
+static void

+ilk_dump_csc(struct drm_i915_private *i915, const char *name,
+const struct intel_csc_matrix *csc)
+{
+   int i;
+
+   drm_dbg_kms(&i915->drm,
+   "%s: pre offsets: 0x%04x 0x%04x 0x%04x\n", name,
+   csc->preoff[0], csc->preoff[1], csc->preoff[2]);
+
+   for (i = 0; i < 3; i++)
+   drm_dbg_kms(&i915->drm,
+   "%s: coefficients: 0x%04x 0x%04x 0x%04x\n", name,
+   csc->coeff[3*i+0], csc->coeff[3*i+1], 
csc->coeff[3*i+2]);
+
+   if (DISPLAY_VER(i915) < 7)
+   return;
+
+   drm_dbg_kms(&i915->drm,
+   "%s: post offsets: 0x%04x 0x%04x 0x%04x\n", name,
+   csc->postoff[0], csc->postoff[1], csc->postoff[2]);
+}
+
+static void
+chv_dump_csc(struct drm_i915_private *i915, const char *name,
+const struct intel_csc_matrix *csc)
+{
+   int i;
+
+   for (i = 0; i < 3; i++)
+   drm_dbg_kms(&i915->drm,
+   "%s: coefficients: 0x%04x 0x%04x 0x%04x\n", name,
+   csc->coeff[3*i+0], csc->coeff[3*i+1], 
csc->coeff[3*i+2]);
+}
+
  void intel_crtc_state_dump(const struct intel_crtc_state *pipe_config,
   struct intel_atomic_state *state,
   const char *context)
@@ -325,6 +360,14 @@ void intel_crtc_state_dump(const struct intel_crtc_state 
*pipe_config,
pipe_config->post_csc_lut ?
drm_color_lut_size(pipe_config->post_csc_lut) : 0);
  
+	if (DISPLAY_VER(i915) >= 11)

+   ilk_dump_csc(i915, "output csc", &pipe_config->output_csc);
+
+   if (!HAS_GMCH(i915))
+   ilk_dump_csc(i915, "pipe csc", &pipe_config->csc);
+   else if (IS_CHERRYVIEW(i915))
+   chv_dump_csc(i915, "cgm csc", &pipe_config->csc);
+
  dump_planes:
if (!state)
return;

Re: [Intel-gfx] [PATCH 11/12] drm/i915: Hook up csc into state checker


LGTM.

Reviewed-by: Ankit Nautiyal 

On 3/29/2023 7:20 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Have the state checker validate that the csc matrices
look correct when read back from the hardware.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/intel_display.c | 21 
  1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index aa22241c971c..763f7fdfb27c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5643,6 +5643,24 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
} \
  } while (0)
  
+#define PIPE_CONF_CHECK_CSC(name) do { \

+   PIPE_CONF_CHECK_X(name.preoff[0]); \
+   PIPE_CONF_CHECK_X(name.preoff[1]); \
+   PIPE_CONF_CHECK_X(name.preoff[2]); \
+   PIPE_CONF_CHECK_X(name.coeff[0]); \
+   PIPE_CONF_CHECK_X(name.coeff[1]); \
+   PIPE_CONF_CHECK_X(name.coeff[2]); \
+   PIPE_CONF_CHECK_X(name.coeff[3]); \
+   PIPE_CONF_CHECK_X(name.coeff[4]); \
+   PIPE_CONF_CHECK_X(name.coeff[5]); \
+   PIPE_CONF_CHECK_X(name.coeff[6]); \
+   PIPE_CONF_CHECK_X(name.coeff[7]); \
+   PIPE_CONF_CHECK_X(name.coeff[8]); \
+   PIPE_CONF_CHECK_X(name.postoff[0]); \
+   PIPE_CONF_CHECK_X(name.postoff[1]); \
+   PIPE_CONF_CHECK_X(name.postoff[2]); \
+} while (0)
+
  #define PIPE_CONF_QUIRK(quirk) \
((current_config->quirks | pipe_config->quirks) & (quirk))
  
@@ -5740,6 +5758,9 @@ intel_pipe_config_compare(const struct intel_crtc_state *current_config,

PIPE_CONF_CHECK_COLOR_LUT(pre_csc_lut, true);
PIPE_CONF_CHECK_COLOR_LUT(post_csc_lut, false);
  
+		PIPE_CONF_CHECK_CSC(csc);

+   PIPE_CONF_CHECK_CSC(output_csc);
+
if (current_config->active_planes) {
PIPE_CONF_CHECK_BOOL(has_psr);
PIPE_CONF_CHECK_BOOL(has_psr2);

[Intel-gfx] ✓ Fi.CI.IGT: success for Add hwmon support for dgfx selftests

== Series Details ==

Series: Add hwmon support for dgfx selftests
URL   : https://patchwork.freedesktop.org/series/116136/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12973_full -> Patchwork_116136v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_116136v1_full:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_barrier_race@remote-request@rcs0:
- {shard-rkl}:[PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12973/shard-rkl-6/igt@gem_barrier_race@remote-requ...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116136v1/shard-rkl-4/igt@gem_barrier_race@remote-requ...@rcs0.html

  
Known issues


  Here are the changes found in Patchwork_116136v1_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_eio@in-flight-contexts-1us:
- shard-apl:  [PASS][3] -> [TIMEOUT][4] ([i915#3063])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12973/shard-apl6/igt@gem_...@in-flight-contexts-1us.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116136v1/shard-apl2/igt@gem_...@in-flight-contexts-1us.html

  * igt@gem_eio@reset-stress:
- shard-snb:  [PASS][5] -> [TIMEOUT][6] ([i915#3063])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12973/shard-snb4/igt@gem_...@reset-stress.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116136v1/shard-snb4/igt@gem_...@reset-stress.html

  * igt@kms_cursor_crc@cursor-suspend@pipe-c-dp-1:
- shard-apl:  [PASS][7] -> [ABORT][8] ([i915#180]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12973/shard-apl3/igt@kms_cursor_crc@cursor-susp...@pipe-c-dp-1.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116136v1/shard-apl4/igt@kms_cursor_crc@cursor-susp...@pipe-c-dp-1.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk:  [PASS][9] -> [FAIL][10] ([i915#2346]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12973/shard-glk4/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116136v1/shard-glk4/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl:  [PASS][11] -> [FAIL][12] ([i915#2346])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12973/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116136v1/shard-apl1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html

  * igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk:  NOTRUN -> [SKIP][13] ([fdo#109271])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116136v1/shard-glk9/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-dp1:
- shard-apl:  [PASS][14] -> [FAIL][15] ([i915#79])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12973/shard-apl3/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-dp1.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116136v1/shard-apl2/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-dp1.html

  
 Possible fixes 

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-apl:  [ABORT][16] ([i915#180]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12973/shard-apl1/igt@gem_ctx_isolation@preservation...@rcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116136v1/shard-apl3/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl:  [FAIL][18] ([i915#2842]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12973/shard-apl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116136v1/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- {shard-rkl}:[FAIL][20] ([i915#2842]) -> [PASS][21] +1 similar 
issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12973/shard-rkl-3/igt@gem_exec_fair@basic-p...@rcs0.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116136v1/shard-rkl-7/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_suspend@basic-s4-devices@smem:
- {shard-tglu}:   [ABORT][22] ([

Re: [Intel-gfx] [PATCH] drm/i915: Query compressed bpp properly using correct DPCD and DP Spec info

On Thu, 06 Apr 2023, Stanislav Lisovskiy  wrote:
> Currently we seem to be using wrong DPCD register for reading compressed bpps,
> reading min/max input bpc instead of compressed bpp.
> Fix that, so that we now apply min/max compressed bpp limitations we get
> from DP Spec Table 2-157 DP v2.0 and/or correspondent DPCD register
> DP_DSC_MAX_BITS_PER_PIXEL_LOW/HIGH.
>
> This might also allow us to get rid of an ugly compressed bpp recalculation,
> which we had to add to make some MST hubs usable.
>
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 76 ++---
>  1 file changed, 52 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index a88b852c437c..9479c7e0b269 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -174,6 +174,50 @@ static int intel_dp_mst_compute_link_config(struct 
> intel_encoder *encoder,
>   return 0;
>  }
>  
> +static u16 dsc_max_sink_compressed_bppx16(const u8 
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
> +   struct intel_crtc_state *pipe_config,
> +   int bpc)
> +{
> + u16 max_bppx16 = dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_LOW - 
> DP_DSC_SUPPORT] |
> +  (dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_HI - 
> DP_DSC_SUPPORT] &
> +   DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK << 
> DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT);

This duplicates drm_edp_dsc_sink_output_bpp().

Both have operator precedence wrong, leading to the high byte always
being ignored. For example, sink reported max bpp of 32 turns to 0, and
24 turns to 8.

Broken since 2018. 0575650077ea ("drm/dp: DRM DP helper/macros to get DP
sink DSC parameters").

The definition of DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT is misleading wrt
all of our regular usage. We should never have a FOO_MASK << FOO_SHIFT
in code, the MASK should always be already shifted in place. Here we do,
because the shift is not for shifting the mask in place, it's for
combining the high and low bytes. But I don't really think
DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT should exist, at all.

BR,
Jani.



> +
> + if (max_bppx16)
> + return max_bppx16;
> + /*
> +  * If support not given in DPCD 67h, 68h use the Maximum Allowed bit 
> rate
> +  * values as given in spec Table 2-157 DP v2.0
> +  */
> + switch (pipe_config->output_format) {
> + case INTEL_OUTPUT_FORMAT_RGB:
> + case INTEL_OUTPUT_FORMAT_YCBCR444:
> + return bpc << 4;
> + case INTEL_OUTPUT_FORMAT_YCBCR420:
> + return (3 * (bpc / 2)) << 4;
> + default:
> + MISSING_CASE(pipe_config->output_format);
> + break;
> + }
> +
> + return 0;
> +}
> +
> +static u16 dsc_min_compressed_bppx16(struct intel_crtc_state *pipe_config)
> +{
> + switch (pipe_config->output_format) {
> + case INTEL_OUTPUT_FORMAT_RGB:
> + case INTEL_OUTPUT_FORMAT_YCBCR444:
> + return 8 << 4;
> + case INTEL_OUTPUT_FORMAT_YCBCR420:
> + return 6 << 4;
> + default:
> + MISSING_CASE(pipe_config->output_format);
> + break;
> + }
> +
> + return 0;
> +}
> +
>  static int intel_dp_dsc_mst_compute_link_config(struct intel_encoder 
> *encoder,
>   struct intel_crtc_state 
> *crtc_state,
>   struct drm_connector_state 
> *conn_state,
> @@ -191,8 +235,6 @@ static int intel_dp_dsc_mst_compute_link_config(struct 
> intel_encoder *encoder,
>   u8 dsc_bpc[3] = {0};
>   int min_bpp, max_bpp, sink_min_bpp, sink_max_bpp;
>   u8 dsc_max_bpc;
> - bool need_timeslot_recalc = false;
> - u32 last_compressed_bpp;
>  
>   /* Max DSC Input BPC for ICL is 10 and for TGL+ is 12 */
>   if (DISPLAY_VER(i915) >= 12)
> @@ -228,6 +270,14 @@ static int intel_dp_dsc_mst_compute_link_config(struct 
> intel_encoder *encoder,
>   if (max_bpp > sink_max_bpp)
>   max_bpp = sink_max_bpp;
>  
> + /* Get Min/Max compressed bpp's for those Input Bpps we got for 
> source/sink */
> + max_bpp = min(max_bpp, 
> dsc_max_sink_compressed_bppx16(intel_dp->dsc_dpcd, crtc_state, max_bpp / 3) 
> >> 4);
> + min_bpp = max(min_bpp, dsc_min_compressed_bppx16(crtc_state) >> 4);
> +
> + /* Align compressed bpps according to our own constraints */
> + max_bpp = intel_dp_dsc_nearest_valid_bpp(i915, max_bpp, 
> crtc_state->pipe_bpp);
> + min_bpp = intel_dp_dsc_nearest_valid_bpp(i915, min_bpp, 
> crtc_state->pipe_bpp);
> +
>   slots = intel_dp_mst_find_vcpi_slots_for_bpp(encoder, crtc_state, 
> max_bpp,
>min_bpp, limits,
>conn_state, 2 * 3, true);
> @@ -235,28 +285,6 @@ static

Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO

2023-04-06 Thread Liu, Yi L

> From: Jason Gunthorpe 
> Sent: Thursday, April 6, 2023 7:23 AM
> 
> On Wed, Apr 05, 2023 at 01:49:45PM -0600, Alex Williamson wrote:
> 
> > > > QEMU can make a policy decision today because the kernel provides a
> > > > sufficiently reliable interface, ie. based on the set of owned groups, a
> > > > hot-reset is all but guaranteed to work.
> > >
> > > And we don't change that with cdev. If qemu wants to make the policy
> > > decision it keeps using the exact same _INFO interface to make that
> > > decision same it has always made.
> > >
> > > We weaken the actual reset action to only consider the security side.
> > >
> > > Applications that want this exclusive reset group policy simply must
> > > check it on their own. It is a reasonable API design.
> >
> > I disagree, as I've argued before, the info ioctl becomes so weak and
> > effectively arbitrary from a user perspective at being able to predict
> > whether the hot-reset ioctl works that it becomes useless, diminishing
> > the entire hot-reset info/execute API.
> 
> reset should be strictly more permissive than INFO. If INFO predicts
> reset is permitted then reset should succeed.
> 
> We don't change INFO so it cannot "becomes so weak"  ??
> 
> We don't care about the cases where INFO says it will not succeed but
> reset does (temporarily) succeed.
> 
> I don't get what argument you are trying to make or what you think is
> diminished..
> 
> Again, userspace calls INFO, if info says yes then reset *always
> works*, exactly just like today.
>
> Userspace will call reset with a 0 length FD list and it uses a
> security only check that is strictly more permissive than what
> get_info will return. So the new check is simple in the kernel and
> always works in the cases we need it to work.
> 
> What is getting things into trouble is insisting that RESET have
> additional restrictions beyond the minimum checks required for
> security.
> 
> > > I don't view it as a loophole, it is flexability to use the API in a
> > > way that is different from what qemu wants - eg an app like dpdk may
> > > be willing to tolerate a reset group that becomes unavailable after
> > > startup. Who knows, why should we force this in the kernel?
> >
> > Because look at all the problems it's causing to try to introduce these
> > loopholes without also introducing subtle bugs.
> 
> These problems are coming from tring to do this integrated version,
> not from my approach!
> 
> AFAICT there was nothing wrong with my original plan of using the
> empty fd list for reset. What Yi has here is some mashup of what you
> and I both suggested.

Hi Alex, Jason,

could be this reason. So let me try to gather the changes of this series
does and the impact as far as I know.

1) only check the ownership of opened devices in the dev_set
 in HOT_RESET ioctl.
 - Impact: it changes the relationship between _INFO  and HOT_RESET.
   As " Each group must have IOMMU protection established for the
   ioctl to succeed." in [1], existing design actually means userspace
   should own all the affected groups before heading to do HOT_RESET.
   With the change here, the user does not need to ensure all affected
   groups are opened and it can do hot-reset successfully as long as the
   devices in the affected group are just un-opened and can be reset.

   [1] 
https://patchwork.kernel.org/project/linux-pci/patch/20130814200845.21923.64284.st...@bling.home/

2) Allow passing zero-length fd array to do hot reset
- Impact: this uses the iommufd as ownership check in the kernel side.
  It is only supposed to be used by the users that open cdev instead of
  users that open group. The drawback is that it cannot cover the noiommu
  devices as noiommu does not use iommufd at all. But it works well for
  most cases.

3) Allow hot reset be successful when the dev_set is singleton
 - Impact: this makes sense but it seems to mess up the boundary between
 the group path and cdev path w.r.t. the usage of zero-length fd approach.
 The group path can succeed to do hot reset even if it is passing an empty
 fd array if the dev_set happens to be singleton.

4) Allow passing device fd to do hot reset
- Impact: this is a new way for hot reset. should have no impact.

5) Extend the _INFO to report devid
- Impact: this changes the way user to decode the info reported back.
devid and groupid are returned per the way the queried device is opened.
Since it was suggested to support the scenario in which some devices
are opened via cdev while some devices are opened via group. This makes
us to return invalid_devid for the device that is opened via group if
it is affected by the hot reset of a device that is opened via cdev.

This was proposed to support the future device fd passing usage which is
only available in cdev path.

To me the major confusion is from 1) and 3). 1) changes the meaning of
_INFO and HOT_RESET, while

Re: [Intel-gfx] [PATCH] drm/i915: Query compressed bpp properly using correct DPCD and DP Spec info

2023-04-06 Thread Lisovskiy, Stanislav

Not planning to upstream that actually, just for some bug on gitlab.
Want to see if that helps the reporter, then at least there is an idea whats 
the problem.


From: Jani Nikula 
Sent: Thursday, April 6, 2023 12:59 PM
To: Lisovskiy, Stanislav; intel-gfx@lists.freedesktop.org
Cc: Manasi Navare
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Query compressed bpp properly using 
correct DPCD and DP Spec info

On Thu, 06 Apr 2023, Stanislav Lisovskiy  wrote:
> Currently we seem to be using wrong DPCD register for reading compressed bpps,
> reading min/max input bpc instead of compressed bpp.
> Fix that, so that we now apply min/max compressed bpp limitations we get
> from DP Spec Table 2-157 DP v2.0 and/or correspondent DPCD register
> DP_DSC_MAX_BITS_PER_PIXEL_LOW/HIGH.
>
> This might also allow us to get rid of an ugly compressed bpp recalculation,
> which we had to add to make some MST hubs usable.
>
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 76 ++---
>  1 file changed, 52 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index a88b852c437c..9479c7e0b269 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -174,6 +174,50 @@ static int intel_dp_mst_compute_link_config(struct 
> intel_encoder *encoder,
>   return 0;
>  }
>
> +static u16 dsc_max_sink_compressed_bppx16(const u8 
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
> +   struct intel_crtc_state *pipe_config,
> +   int bpc)
> +{
> + u16 max_bppx16 = dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_LOW - 
> DP_DSC_SUPPORT] |
> +  (dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_HI - 
> DP_DSC_SUPPORT] &
> +   DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK << 
> DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT);

This duplicates drm_edp_dsc_sink_output_bpp().

Both have operator precedence wrong, leading to the high byte always
being ignored. For example, sink reported max bpp of 32 turns to 0, and
24 turns to 8.

Broken since 2018. 0575650077ea ("drm/dp: DRM DP helper/macros to get DP
sink DSC parameters").

The definition of DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT is misleading wrt
all of our regular usage. We should never have a FOO_MASK << FOO_SHIFT
in code, the MASK should always be already shifted in place. Here we do,
because the shift is not for shifting the mask in place, it's for
combining the high and low bytes. But I don't really think
DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT should exist, at all.

BR,
Jani.



> +
> + if (max_bppx16)
> + return max_bppx16;
> + /*
> +  * If support not given in DPCD 67h, 68h use the Maximum Allowed bit 
> rate
> +  * values as given in spec Table 2-157 DP v2.0
> +  */
> + switch (pipe_config->output_format) {
> + case INTEL_OUTPUT_FORMAT_RGB:
> + case INTEL_OUTPUT_FORMAT_YCBCR444:
> + return bpc << 4;
> + case INTEL_OUTPUT_FORMAT_YCBCR420:
> + return (3 * (bpc / 2)) << 4;
> + default:
> + MISSING_CASE(pipe_config->output_format);
> + break;
> + }
> +
> + return 0;
> +}
> +
> +static u16 dsc_min_compressed_bppx16(struct intel_crtc_state *pipe_config)
> +{
> + switch (pipe_config->output_format) {
> + case INTEL_OUTPUT_FORMAT_RGB:
> + case INTEL_OUTPUT_FORMAT_YCBCR444:
> + return 8 << 4;
> + case INTEL_OUTPUT_FORMAT_YCBCR420:
> + return 6 << 4;
> + default:
> + MISSING_CASE(pipe_config->output_format);
> + break;
> + }
> +
> + return 0;
> +}
> +
>  static int intel_dp_dsc_mst_compute_link_config(struct intel_encoder 
> *encoder,
>   struct intel_crtc_state 
> *crtc_state,
>   struct drm_connector_state 
> *conn_state,
> @@ -191,8 +235,6 @@ static int intel_dp_dsc_mst_compute_link_config(struct 
> intel_encoder *encoder,
>   u8 dsc_bpc[3] = {0};
>   int min_bpp, max_bpp, sink_min_bpp, sink_max_bpp;
>   u8 dsc_max_bpc;
> - bool need_timeslot_recalc = false;
> - u32 last_compressed_bpp;
>
>   /* Max DSC Input BPC for ICL is 10 and for TGL+ is 12 */
>   if (DISPLAY_VER(i915) >= 12)
> @@ -228,6 +270,14 @@ static int intel_dp_dsc_mst_compute_link_config(struct 
> intel_encoder *encoder,
>   if (max_bpp > sink_max_bpp)
>   max_bpp = sink_max_bpp;
>
> + /* Get Min/Max compressed bpp's for those Input Bpps we got for 
> source/sink */
> + max_bpp = min(max_bpp, 
> dsc_max_sink_compressed_bppx16(intel_dp->dsc_dpcd, crtc_state, max_bpp / 3) 
> >> 4);
> + min_bpp = max(min_bpp, dsc_min_compressed_bppx16(crtc_state) >> 4);
> +
> + /* Align compressed bpps according to our own constraints */
> +

Re: [Intel-gfx] [PATCH] drm/i915: Query compressed bpp properly using correct DPCD and DP Spec info

On Thu, 06 Apr 2023, "Lisovskiy, Stanislav"  
wrote:
> Not planning to upstream that actually, just for some bug on gitlab.
> Want to see if that helps the reporter, then at least there is an idea whats 
> the problem.

The issue in drm_edp_dsc_sink_output_bpp() needs to be fixed regardless.

BR,
Jani.


>
> 
> From: Jani Nikula 
> Sent: Thursday, April 6, 2023 12:59 PM
> To: Lisovskiy, Stanislav; intel-gfx@lists.freedesktop.org
> Cc: Manasi Navare
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Query compressed bpp properly 
> using correct DPCD and DP Spec info
>
> On Thu, 06 Apr 2023, Stanislav Lisovskiy  
> wrote:
>> Currently we seem to be using wrong DPCD register for reading compressed 
>> bpps,
>> reading min/max input bpc instead of compressed bpp.
>> Fix that, so that we now apply min/max compressed bpp limitations we get
>> from DP Spec Table 2-157 DP v2.0 and/or correspondent DPCD register
>> DP_DSC_MAX_BITS_PER_PIXEL_LOW/HIGH.
>>
>> This might also allow us to get rid of an ugly compressed bpp recalculation,
>> which we had to add to make some MST hubs usable.
>>
>> Signed-off-by: Stanislav Lisovskiy 
>> ---
>>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 76 ++---
>>  1 file changed, 52 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
>> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
>> index a88b852c437c..9479c7e0b269 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
>> @@ -174,6 +174,50 @@ static int intel_dp_mst_compute_link_config(struct 
>> intel_encoder *encoder,
>>   return 0;
>>  }
>>
>> +static u16 dsc_max_sink_compressed_bppx16(const u8 
>> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
>> +   struct intel_crtc_state *pipe_config,
>> +   int bpc)
>> +{
>> + u16 max_bppx16 = dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_LOW - 
>> DP_DSC_SUPPORT] |
>> +  (dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_HI - 
>> DP_DSC_SUPPORT] &
>> +   DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK << 
>> DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT);
>
> This duplicates drm_edp_dsc_sink_output_bpp().
>
> Both have operator precedence wrong, leading to the high byte always
> being ignored. For example, sink reported max bpp of 32 turns to 0, and
> 24 turns to 8.
>
> Broken since 2018. 0575650077ea ("drm/dp: DRM DP helper/macros to get DP
> sink DSC parameters").
>
> The definition of DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT is misleading wrt
> all of our regular usage. We should never have a FOO_MASK << FOO_SHIFT
> in code, the MASK should always be already shifted in place. Here we do,
> because the shift is not for shifting the mask in place, it's for
> combining the high and low bytes. But I don't really think
> DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT should exist, at all.
>
> BR,
> Jani.
>
>
>
>> +
>> + if (max_bppx16)
>> + return max_bppx16;
>> + /*
>> +  * If support not given in DPCD 67h, 68h use the Maximum Allowed bit 
>> rate
>> +  * values as given in spec Table 2-157 DP v2.0
>> +  */
>> + switch (pipe_config->output_format) {
>> + case INTEL_OUTPUT_FORMAT_RGB:
>> + case INTEL_OUTPUT_FORMAT_YCBCR444:
>> + return bpc << 4;
>> + case INTEL_OUTPUT_FORMAT_YCBCR420:
>> + return (3 * (bpc / 2)) << 4;
>> + default:
>> + MISSING_CASE(pipe_config->output_format);
>> + break;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static u16 dsc_min_compressed_bppx16(struct intel_crtc_state *pipe_config)
>> +{
>> + switch (pipe_config->output_format) {
>> + case INTEL_OUTPUT_FORMAT_RGB:
>> + case INTEL_OUTPUT_FORMAT_YCBCR444:
>> + return 8 << 4;
>> + case INTEL_OUTPUT_FORMAT_YCBCR420:
>> + return 6 << 4;
>> + default:
>> + MISSING_CASE(pipe_config->output_format);
>> + break;
>> + }
>> +
>> + return 0;
>> +}
>> +
>>  static int intel_dp_dsc_mst_compute_link_config(struct intel_encoder 
>> *encoder,
>>   struct intel_crtc_state 
>> *crtc_state,
>>   struct drm_connector_state 
>> *conn_state,
>> @@ -191,8 +235,6 @@ static int intel_dp_dsc_mst_compute_link_config(struct 
>> intel_encoder *encoder,
>>   u8 dsc_bpc[3] = {0};
>>   int min_bpp, max_bpp, sink_min_bpp, sink_max_bpp;
>>   u8 dsc_max_bpc;
>> - bool need_timeslot_recalc = false;
>> - u32 last_compressed_bpp;
>>
>>   /* Max DSC Input BPC for ICL is 10 and for TGL+ is 12 */
>>   if (DISPLAY_VER(i915) >= 12)
>> @@ -228,6 +270,14 @@ static int intel_dp_dsc_mst_compute_link_config(struct 
>> intel_encoder *encoder,
>>   if (max_bpp > sink_max_bpp)
>>   max_bpp = sink_max_bpp;
>>
>> + /* Get Min/Max compressed bpp's for those Input Bpps we g

Re: [Intel-gfx] [PATCH 03/12] drm/i915: Split chv_load_cgm_csc() into pieces

2023-04-06 Thread Ville Syrjälä

On Thu, Apr 06, 2023 at 02:33:05PM +0530, Nautiyal, Ankit K wrote:
> 
> On 3/29/2023 7:19 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > Split chv_cgm_csc_convert_ctm() out from chv_load_cgm_csc() so
> > that we have functions with clear jobs. This is also how the ilk+
> > code is already structured.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/i915/display/intel_color.c | 19 +--
> >   1 file changed, 13 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index b1059e0c0665..47af24e64a7e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -399,16 +399,13 @@ static void icl_load_csc_matrix(const struct 
> > intel_crtc_state *crtc_state)
> > }
> >   }
> >   
> > -static void chv_load_cgm_csc(struct intel_crtc *crtc,
> > -const struct drm_property_blob *blob)
> > +static void chv_cgm_csc_convert_ctm(u16 coeffs[9],
> > +   const struct drm_property_blob *blob)
> >   {
> > -   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > const struct drm_color_ctm *ctm = blob->data;
> > -   enum pipe pipe = crtc->pipe;
> > -   u16 coeffs[9];
> > int i;
> >   
> > -   for (i = 0; i < ARRAY_SIZE(coeffs); i++) {
> > +   for (i = 0; i < 9; i++) {
> 
> Can still use ARRAY_SIZE(coeffs).

Nope. Arrays passed to functions are in fact pointers in C.

> 
> In any case the patch looks good to me.
> 
> Reviewed-by: Ankit Nautiyal 
> 
> 
> > u64 abs_coeff = ((1ULL << 63) - 1) & ctm->matrix[i];
> >   
> > /* Round coefficient. */
> > @@ -425,6 +422,16 @@ static void chv_load_cgm_csc(struct intel_crtc *crtc,
> > coeffs[i] |= ((abs_coeff >> 32) & 7) << 12;
> > coeffs[i] |= (abs_coeff >> 20) & 0xfff;
> > }
> > +}
> > +
> > +static void chv_load_cgm_csc(struct intel_crtc *crtc,
> > +const struct drm_property_blob *blob)
> > +{
> > +   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > +   enum pipe pipe = crtc->pipe;
> > +   u16 coeffs[9];
> > +
> > +   chv_cgm_csc_convert_ctm(coeffs, blob);
> >   
> > intel_de_write_fw(i915, CGM_PIPE_CSC_COEFF01(pipe),
> >   coeffs[1] << 16 | coeffs[0]);

-- 
Ville Syrjälä
Intel

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Increase AUX timeout for Type-C (rev2)

== Series Details ==

Series: drm/i915/display: Increase AUX timeout for Type-C (rev2)
URL   : https://patchwork.freedesktop.org/series/116010/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12973_full -> Patchwork_116010v2_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_116010v2_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_116010v2_full, please notify your bug team to allow 
them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_116010v2_full:

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rc6_residency@rc6-idle@bcs0:
- shard-apl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12973/shard-apl3/igt@i915_pm_rc6_residency@rc6-i...@bcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v2/shard-apl4/igt@i915_pm_rc6_residency@rc6-i...@bcs0.html

  
Known issues


  Here are the changes found in Patchwork_116010v2_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl:  [PASS][3] -> [FAIL][4] ([i915#2842]) +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12973/shard-apl7/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v2/shard-apl4/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_render_copy@x-tiled-to-vebox-yf-tiled:
- shard-apl:  NOTRUN -> [SKIP][5] ([fdo#109271]) +10 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v2/shard-apl3/igt@gem_render_c...@x-tiled-to-vebox-yf-tiled.html

  * igt@i915_pm_rps@reset:
- shard-snb:  [PASS][6] -> [INCOMPLETE][7] ([i915#7790])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12973/shard-snb4/igt@i915_pm_...@reset.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v2/shard-snb5/igt@i915_pm_...@reset.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk:  [PASS][8] -> [FAIL][9] ([i915#2346])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12973/shard-glk4/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v2/shard-glk7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
- shard-apl:  [PASS][10] -> [FAIL][11] ([i915#2346])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12973/shard-apl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v2/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html

  * igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk:  NOTRUN -> [SKIP][12] ([fdo#109271])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v2/shard-glk3/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html

  * igt@kms_fbcon_fbt@fbc-suspend:
- shard-apl:  [PASS][13] -> [FAIL][14] ([i915#4767])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12973/shard-apl6/igt@kms_fbcon_...@fbc-suspend.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v2/shard-apl6/igt@kms_fbcon_...@fbc-suspend.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-dp1:
- shard-apl:  [PASS][15] -> [FAIL][16] ([i915#79])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12973/shard-apl3/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-dp1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v2/shard-apl6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-dp1.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-hdmi-a2:
- shard-glk:  [PASS][17] -> [FAIL][18] ([i915#79]) +1 similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12973/shard-glk6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-hdmi-a2.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v2/shard-glk2/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-hdmi-a2.html

  * igt@kms_writeback@writeback-fb-id:
- shard-apl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#2437])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v2/shard-apl3/igt@kms_writeb...@writeback-fb-id.html

  
 Possible fixes 

  * igt@gem_ctx_exec@basic-nohangcheck:
- {shard-tglu}:   [FAIL][20] ([i915#6268]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12973/s

Re: [Intel-gfx] [PATCH v9 06/25] kvm/vfio: Accept vfio device file from userspace

2023-04-06 Thread Liu, Yi L

Hi Eric,

> From: Eric Auger 
> Sent: Thursday, April 6, 2023 5:47 PM
> 
> Hi Yi,
> 
> On 4/1/23 17:18, Yi Liu wrote:
> > This defines KVM_DEV_VFIO_FILE* and make alias with KVM_DEV_VFIO_GROUP*.
> > Old userspace uses KVM_DEV_VFIO_GROUP* works as well.
> >
> > Reviewed-by: Jason Gunthorpe 
> > Reviewed-by: Kevin Tian 
> > Tested-by: Terrence Xu 
> > Tested-by: Nicolin Chen 
> > Tested-by: Matthew Rosato 
> > Tested-by: Yanting Jiang 
> > Signed-off-by: Yi Liu 
> > ---
> >  Documentation/virt/kvm/devices/vfio.rst | 53 +
> >  include/uapi/linux/kvm.h| 16 ++--
> >  virt/kvm/vfio.c | 16 
> >  3 files changed, 56 insertions(+), 29 deletions(-)
> >
> > diff --git a/Documentation/virt/kvm/devices/vfio.rst
> b/Documentation/virt/kvm/devices/vfio.rst
> > index 79b6811bb4f3..277d727ec1a2 100644
> > --- a/Documentation/virt/kvm/devices/vfio.rst
> > +++ b/Documentation/virt/kvm/devices/vfio.rst
> > @@ -9,24 +9,38 @@ Device types supported:
> >- KVM_DEV_TYPE_VFIO
> >
> >  Only one VFIO instance may be created per VM.  The created device
> > -tracks VFIO groups in use by the VM and features of those groups
> > -important to the correctness and acceleration of the VM.  As groups
> > -are enabled and disabled for use by the VM, KVM should be updated
> > -about their presence.  When registered with KVM, a reference to the
> > -VFIO-group is held by KVM.
> > +tracks VFIO files (group or device) in use by the VM and features
> > +of those groups/devices important to the correctness and acceleration
> > +of the VM.  As groups/devices are enabled and disabled for use by the
> > +VM, KVM should be updated about their presence.  When registered with
> > +KVM, a reference to the VFIO file is held by KVM.
> >
> >  Groups:
> > -  KVM_DEV_VFIO_GROUP
> > -
> > -KVM_DEV_VFIO_GROUP attributes:
> > -  KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device tracking
> > -   kvm_device_attr.addr points to an int32_t file descriptor
> > -   for the VFIO group.
> > -  KVM_DEV_VFIO_GROUP_DEL: Remove a VFIO group from VFIO-KVM device
> tracking
> > -   kvm_device_attr.addr points to an int32_t file descriptor
> > -   for the VFIO group.
> > -  KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: attaches a guest visible TCE table
> > +  KVM_DEV_VFIO_FILE
> > +   alias: KVM_DEV_VFIO_GROUP
> > +
> > +KVM_DEV_VFIO_FILE attributes:
> > +  KVM_DEV_VFIO_FILE_ADD: Add a VFIO file (group/device) to VFIO-KVM device
> > +   tracking
> > +
> > +   alias: KVM_DEV_VFIO_GROUP_ADD
> > +
> > +   kvm_device_attr.addr points to an int32_t file descriptor for the
> > +   VFIO file.
> > +
> > +  KVM_DEV_VFIO_FILE_DEL: Remove a VFIO file (group/device) from VFIO-KVM
> > +   device tracking
> > +
> > +   alias: KVM_DEV_VFIO_GROUP_DEL
> > +
> > +   kvm_device_attr.addr points to an int32_t file descriptor for the
> > +   VFIO file.
> > +
> > +  KVM_DEV_VFIO_FILE_SET_SPAPR_TCE: attaches a guest visible TCE table
> > allocated by sPAPR KVM.
> > +
> > +   alias: KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE
> > +
> > kvm_device_attr.addr points to a struct::
> >
> > struct kvm_vfio_spapr_tce {
> > @@ -40,9 +54,14 @@ KVM_DEV_VFIO_GROUP attributes:
> > - @tablefd is a file descriptor for a TCE table allocated via
> >   KVM_CREATE_SPAPR_TCE.
> >
> > +   only accepts vfio group file as SPAPR has no iommufd support
> So then what is the point of introducing
> 
> KVM_DEV_VFIO_FILE_SET_SPAPR_TCE at this stage?

the major reason is to make the naming aligned since this patch
names the groups as KVM_DEV_VFIO_FILE.

> 
> I think would have separated the
> 
> Groups:
>   KVM_DEV_VFIO_FILE
>   alias: KVM_DEV_VFIO_GROUP
> 
> KVM_DEV_VFIO_FILE attributes:
>   KVM_DEV_VFIO_FILE_ADD: Add a VFIO file (group/device) to VFIO-KVM device
>   tracking
> 
>   kvm_device_attr.addr points to an int32_t file descriptor for the
>   VFIO file.
> 
>   KVM_DEV_VFIO_FILE_DEL: Remove a VFIO file (group/device) from VFIO-KVM
>   device tracking
> 
>   kvm_device_attr.addr points to an int32_t file descriptor for the
>   VFIO file.
> 
> KVM_DEV_VFIO_GROUP (legacy kvm device group restricted to the handling of VFIO
> group fd)
>   KVM_DEV_VFIO_GROUP_ADD: same as KVM_DEV_VFIO_FILE_ADD for group fd only
>   KVM_DEV_VFIO_GROUP_DEL: same as KVM_DEV_VFIO_FILE_DEL for group fd only
>   KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: attaches a guest visible TCE table
>   allocated by sPAPR KVM.
>   kvm_device_attr.addr points to a struct::
> 
>   struct kvm_vfio_spapr_tce {
>   __s32   groupfd;
>   __s32   tablefd;
>   };
> 
>   where:
> 
>   - @groupfd is a file descriptor for a VFIO group;
>   - @tablefd is a file descriptor for a TCE table allocated via
> KVM_CREATE_SPAPR_TCE.

hmmm, this way is clearer. I'd adopt it if it's acceptable.

> 
> You don't say anything about potential restriction, ie. what if the user calls
>

Re: [Intel-gfx] [PATCH] drm/i915: Query compressed bpp properly using correct DPCD and DP Spec info

2023-04-06 Thread Ville Syrjälä

On Thu, Apr 06, 2023 at 12:59:40PM +0300, Jani Nikula wrote:
> On Thu, 06 Apr 2023, Stanislav Lisovskiy  
> wrote:
> > Currently we seem to be using wrong DPCD register for reading compressed 
> > bpps,
> > reading min/max input bpc instead of compressed bpp.
> > Fix that, so that we now apply min/max compressed bpp limitations we get
> > from DP Spec Table 2-157 DP v2.0 and/or correspondent DPCD register
> > DP_DSC_MAX_BITS_PER_PIXEL_LOW/HIGH.
> >
> > This might also allow us to get rid of an ugly compressed bpp recalculation,
> > which we had to add to make some MST hubs usable.
> >
> > Signed-off-by: Stanislav Lisovskiy 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c | 76 ++---
> >  1 file changed, 52 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index a88b852c437c..9479c7e0b269 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -174,6 +174,50 @@ static int intel_dp_mst_compute_link_config(struct 
> > intel_encoder *encoder,
> > return 0;
> >  }
> >  
> > +static u16 dsc_max_sink_compressed_bppx16(const u8 
> > dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
> > + struct intel_crtc_state *pipe_config,
> > + int bpc)
> > +{
> > +   u16 max_bppx16 = dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_LOW - 
> > DP_DSC_SUPPORT] |
> > +(dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_HI - 
> > DP_DSC_SUPPORT] &
> > + DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK << 
> > DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT);
> 
> This duplicates drm_edp_dsc_sink_output_bpp().

These registers are not even valid for non-eDP.

> 
> Both have operator precedence wrong, leading to the high byte always
> being ignored. For example, sink reported max bpp of 32 turns to 0, and
> 24 turns to 8.
> 
> Broken since 2018. 0575650077ea ("drm/dp: DRM DP helper/macros to get DP
> sink DSC parameters").
> 
> The definition of DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT is misleading wrt
> all of our regular usage. We should never have a FOO_MASK << FOO_SHIFT
> in code, the MASK should always be already shifted in place. Here we do,
> because the shift is not for shifting the mask in place, it's for
> combining the high and low bytes. But I don't really think
> DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT should exist, at all.
> 
> BR,
> Jani.
> 
> 
> 
> > +
> > +   if (max_bppx16)
> > +   return max_bppx16;
> > +   /*
> > +* If support not given in DPCD 67h, 68h use the Maximum Allowed bit 
> > rate
> > +* values as given in spec Table 2-157 DP v2.0
> > +*/
> > +   switch (pipe_config->output_format) {
> > +   case INTEL_OUTPUT_FORMAT_RGB:
> > +   case INTEL_OUTPUT_FORMAT_YCBCR444:
> > +   return bpc << 4;
> > +   case INTEL_OUTPUT_FORMAT_YCBCR420:
> > +   return (3 * (bpc / 2)) << 4;
> > +   default:
> > +   MISSING_CASE(pipe_config->output_format);
> > +   break;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static u16 dsc_min_compressed_bppx16(struct intel_crtc_state *pipe_config)
> > +{
> > +   switch (pipe_config->output_format) {
> > +   case INTEL_OUTPUT_FORMAT_RGB:
> > +   case INTEL_OUTPUT_FORMAT_YCBCR444:
> > +   return 8 << 4;
> > +   case INTEL_OUTPUT_FORMAT_YCBCR420:
> > +   return 6 << 4;
> > +   default:
> > +   MISSING_CASE(pipe_config->output_format);
> > +   break;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> >  static int intel_dp_dsc_mst_compute_link_config(struct intel_encoder 
> > *encoder,
> > struct intel_crtc_state 
> > *crtc_state,
> > struct drm_connector_state 
> > *conn_state,
> > @@ -191,8 +235,6 @@ static int intel_dp_dsc_mst_compute_link_config(struct 
> > intel_encoder *encoder,
> > u8 dsc_bpc[3] = {0};
> > int min_bpp, max_bpp, sink_min_bpp, sink_max_bpp;
> > u8 dsc_max_bpc;
> > -   bool need_timeslot_recalc = false;
> > -   u32 last_compressed_bpp;
> >  
> > /* Max DSC Input BPC for ICL is 10 and for TGL+ is 12 */
> > if (DISPLAY_VER(i915) >= 12)
> > @@ -228,6 +270,14 @@ static int intel_dp_dsc_mst_compute_link_config(struct 
> > intel_encoder *encoder,
> > if (max_bpp > sink_max_bpp)
> > max_bpp = sink_max_bpp;
> >  
> > +   /* Get Min/Max compressed bpp's for those Input Bpps we got for 
> > source/sink */
> > +   max_bpp = min(max_bpp, 
> > dsc_max_sink_compressed_bppx16(intel_dp->dsc_dpcd, crtc_state, max_bpp / 3) 
> > >> 4);
> > +   min_bpp = max(min_bpp, dsc_min_compressed_bppx16(crtc_state) >> 4);
> > +
> > +   /* Align compressed bpps according to our own constraints */
> > +   max_bpp = intel_dp_dsc_nearest_valid_bpp(i915, max_bpp, 
> > crtc_state->pipe_bpp);
> > +   min_bpp = intel_dp_dsc_nearest_valid_bpp(i915, min_bpp, 
> > crtc_state->pipe_

Re: [Intel-gfx] [PATCH 01/12] drm/i915: Fix limited range csc matrix


Hi Ville,

HDMI1.4b indeed says max value for 16bpc as 60160 (0xeb00)
And black level of 4096.

Got me thinking that we might need to consider bpc for getting the 
Coeffs and the offsets.

IIUC for CSC Full range to Limited range:
out = in * gain  + offset

Gain :
So for 8 bpc, as you have mentioned
multiplier or gain will be: (235-16) / 255 = 0.8588 ~0.86
offset will be 16, as range is from 16-235

16 bpc
Multiplier: (60160-4096)/65535 = 0.8555 ~0.86
Offset for 16bit: should be 4096

So it seems Multiplier of 0.86 should be alright for different bpc, but 
offset would vary.


Also CSC Postoff programming for the offset doesn’t seem very clear to me.
For CSC BT709 RGB Full range->YCbCr Limited Range, we use offset of {16, 
128, 128} for Y, Cb, Cr, and we write 0x800, 0x100, 0x100 for these values.


But below for Limited range Post offset 16,  we seem to be shifting by 
(12 - 8) i.e 4. Am I missing something?



Regards,

Ankit

On 3/29/2023 7:19 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Our current limited range matrix is a bit off. I think it
was originally calculated with rounding, as if we wanted
the normal pixel replication type of behaviour.
That is, since the 8bpc max value is 0xeb we assumed the
16bpc max value should be 0xebeb, but what the HDMI spec
actually says it should be is 0xeb00.

So to get what we want we make the formula
  out = in * (235-16) << (12-8) / in_max + 16 << (12-8),
with 12 being precision of the csc, 8 being the precision
of the constants we used.

The hardware takes its coefficients as floating point
values, but the (235−16)/255 = ~.86, so exponent 0
is what we want anyway, so it works out perfectly without
having to hardcode it in hex or start playing with floats.

In terms of raw numbers we are feeding the hardware the
post offset changes from 0x101 to 0x100, and the coefficient
changes from 0xdc0 to 0xdb0 (~.860->~.855). So this should
make everything come out just a tad darker.

I already used better constants in lut_limited_range() earlier
so the output of the two paths should be closer now.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/intel_color.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 36aac88143ac..3c3e2f5a5cde 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -116,10 +116,9 @@ struct intel_color_funcs {
  #define ILK_CSC_COEFF_FP(coeff, fbits)\
(clamp_val(((coeff) >> (32 - (fbits) - 3)) + 4, 0, 0xfff) & 0xff8)
  
-#define ILK_CSC_COEFF_LIMITED_RANGE 0x0dc0

  #define ILK_CSC_COEFF_1_0 0x7800
-
-#define ILK_CSC_POSTOFF_LIMITED_RANGE (16 * (1 << 12) / 255)
+#define ILK_CSC_COEFF_LIMITED_RANGE ((235 - 16) << (12 - 8)) /* exponent 0 */
+#define ILK_CSC_POSTOFF_LIMITED_RANGE (16 << (12 - 8))
  
  /* Nop pre/post offsets */

  static const u16 ilk_csc_off_zero[3] = {};

Re: [Intel-gfx] [PATCH i-g-t 8/8] gputop: Basic vendor agnostic GPU top tool




On 05/04/2023 18:57, Rob Clark wrote:

On Tue, Jan 31, 2023 at 3:33 AM Tvrtko Ursulin
 wrote:


From: Tvrtko Ursulin 

Rudimentary vendor agnostic example of how lib_igt_drm_clients can be used
to display a sorted by card and usage list of processes using GPUs.

Borrows a bit of code from intel_gpu_top but for now omits the fancy
features like interactive functionality, card selection, client
aggregation, sort modes, JSON output  and pretty engine names. Also no
support for global GPU or system metrics.

On the other hand it shows clients from all DRM cards which
intel_gpu_top does not do.

Signed-off-by: Tvrtko Ursulin 
Cc: Rob Clark 
Cc: Christian König 
Acked-by: Christian König 


Reviewed-by: Rob Clark 


Presumably for 8/8 only?

The rest of the series does not apply any more by now. I need to rebase..

Regards,

Tvrtko




---
  tools/gputop.c| 260 ++
  tools/meson.build |   5 +
  2 files changed, 265 insertions(+)
  create mode 100644 tools/gputop.c

diff --git a/tools/gputop.c b/tools/gputop.c
new file mode 100644
index ..d259cac1ab17
--- /dev/null
+++ b/tools/gputop.c
@@ -0,0 +1,260 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "igt_drm_clients.h"
+#include "igt_drm_fdinfo.h"
+
+static const char *bars[] = { " ", "▏", "▎", "▍", "▌", "▋", "▊", "▉", "█" };
+
+static void n_spaces(const unsigned int n)
+{
+   unsigned int i;
+
+   for (i = 0; i < n; i++)
+   putchar(' ');
+}
+
+static void print_percentage_bar(double percent, int max_len)
+{
+   int bar_len, i, len = max_len - 2;
+   const int w = 8;
+
+   assert(max_len > 0);
+
+   bar_len = ceil(w * percent * len / 100.0);
+   if (bar_len > w * len)
+   bar_len = w * len;
+
+   putchar('|');
+
+   for (i = bar_len; i >= w; i -= w)
+   printf("%s", bars[w]);
+   if (i)
+   printf("%s", bars[i]);
+
+   len -= (bar_len + (w - 1)) / w;
+   n_spaces(len);
+
+   putchar('|');
+}
+
+static int
+print_client_header(struct igt_drm_client *c, int lines, int con_w, int con_h,
+   int *engine_w)
+{
+   const char *pidname = "PID   NAME ";
+   int ret, len = strlen(pidname);
+
+   if (lines++ >= con_h || len >= con_w)
+   return lines;
+   printf("\033[7m");
+   ret = printf("DRM minor %u", c->drm_minor);
+   n_spaces(con_w - ret);
+
+   if (lines++ >= con_h)
+   return lines;
+   printf("\n%s", pidname);
+
+   if (c->engines->num_engines) {
+   unsigned int i;
+   int width;
+
+   *engine_w = width = (con_w - len) / c->engines->num_engines;
+
+   for (i = 0; i <= c->engines->max_engine_id; i++) {
+   const char *name = c->engines->names[i];
+   int name_len = strlen(name);
+   int pad = (width - name_len) / 2;
+   int spaces = width - pad - name_len;
+
+   if (!name)
+   continue;
+
+   if (pad < 0 || spaces < 0)
+   continue;
+
+   n_spaces(pad);
+   printf("%s", name);
+   n_spaces(spaces);
+   len += pad + name_len + spaces;
+   }
+   }
+
+   n_spaces(con_w - len);
+   printf("\033[0m\n");
+
+   return lines;
+}
+
+
+static bool
+newheader(const struct igt_drm_client *c, const struct igt_drm_client *pc)
+{
+   return !pc || c->drm_minor != pc->drm_minor;
+}
+
+static int
+print_client(struct igt_drm_client *c, struct igt_drm_client **prevc,
+double t, int lines, int con_w, int con_h,
+unsigned int period_us, int *engine_w)
+{
+   unsigned int i;
+
+   /* Filter out idle clients. */
+   if (!c->total_runtime || c->samples < 2)
+   return lines;
+
+   /* Print header when moving to a different DRM card. */
+   if (newheader(c, *prevc)) {
+   lines = print_client_header(c, lines, con_w, con_h, engine_w);
+   if (lines >= con_h)
+   return lines;
+   }
+
+   *prevc = c;
+
+   printf("%8u %17s ", c->pid, c->print_name);
+   lines++;
+
+   for (i = 0; c->samples > 1 && i <= c->engines->max_engine_id; i++) {
+   double pct;
+
+   if (!c->engines->capacity[i])
+   continue;
+
+   pct = (double)c->val[i] / period_us / 1e3 * 100 /
+ c->engines->capacity[i];
+
+   /*
+* Guard aga

Re: [Intel-gfx] [PATCH 01/12] drm/i915: Fix limited range csc matrix

2023-04-06 Thread Ville Syrjälä

On Thu, Apr 06, 2023 at 04:26:48PM +0530, Nautiyal, Ankit K wrote:
> Hi Ville,
> 
> HDMI1.4b indeed says max value for 16bpc as 60160 (0xeb00)
> And black level of 4096.
> 
> Got me thinking that we might need to consider bpc for getting the 
> Coeffs and the offsets.
> IIUC for CSC Full range to Limited range:
> out = in * gain  + offset
> 
> Gain :
> So for 8 bpc, as you have mentioned
> multiplier or gain will be: (235-16) / 255 = 0.8588 ~0.86
> offset will be 16, as range is from 16-235
> 
> 16 bpc
> Multiplier: (60160-4096)/65535 = 0.8555 ~0.86
> Offset for 16bit: should be 4096
> 
> So it seems Multiplier of 0.86 should be alright for different bpc, but 
> offset would vary.

It's all still in the pipe's internal precision. So any 16 vs. 4096
distinction doesn't exist.

> 
> Also CSC Postoff programming for the offset doesn’t seem very clear to me.
> For CSC BT709 RGB Full range->YCbCr Limited Range, we use offset of {16, 
> 128, 128} for Y, Cb, Cr, and we write 0x800, 0x100, 0x100 for these values.

Y is the middle channel. We write 0x800,0x100,0x800

> 
> But below for Limited range Post offset 16,  we seem to be shifting by 
> (12 - 8) i.e 4. Am I missing something?
> 
> 
> Regards,
> 
> Ankit
> 
> On 3/29/2023 7:19 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > Our current limited range matrix is a bit off. I think it
> > was originally calculated with rounding, as if we wanted
> > the normal pixel replication type of behaviour.
> > That is, since the 8bpc max value is 0xeb we assumed the
> > 16bpc max value should be 0xebeb, but what the HDMI spec
> > actually says it should be is 0xeb00.
> >
> > So to get what we want we make the formula
> >   out = in * (235-16) << (12-8) / in_max + 16 << (12-8),
> > with 12 being precision of the csc, 8 being the precision
> > of the constants we used.
> >
> > The hardware takes its coefficients as floating point
> > values, but the (235−16)/255 = ~.86, so exponent 0
> > is what we want anyway, so it works out perfectly without
> > having to hardcode it in hex or start playing with floats.
> >
> > In terms of raw numbers we are feeding the hardware the
> > post offset changes from 0x101 to 0x100, and the coefficient
> > changes from 0xdc0 to 0xdb0 (~.860->~.855). So this should
> > make everything come out just a tad darker.
> >
> > I already used better constants in lut_limited_range() earlier
> > so the output of the two paths should be closer now.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/i915/display/intel_color.c | 5 ++---
> >   1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index 36aac88143ac..3c3e2f5a5cde 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -116,10 +116,9 @@ struct intel_color_funcs {
> >   #define ILK_CSC_COEFF_FP(coeff, fbits)\
> > (clamp_val(((coeff) >> (32 - (fbits) - 3)) + 4, 0, 0xfff) & 0xff8)
> >   
> > -#define ILK_CSC_COEFF_LIMITED_RANGE 0x0dc0
> >   #define ILK_CSC_COEFF_1_0 0x7800
> > -
> > -#define ILK_CSC_POSTOFF_LIMITED_RANGE (16 * (1 << 12) / 255)
> > +#define ILK_CSC_COEFF_LIMITED_RANGE ((235 - 16) << (12 - 8)) /* exponent 0 
> > */
> > +#define ILK_CSC_POSTOFF_LIMITED_RANGE (16 << (12 - 8))
> >   
> >   /* Nop pre/post offsets */
> >   static const u16 ilk_csc_off_zero[3] = {};

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH 1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers

2023-04-06 Thread Patrik Jakobsson

On Thu, Apr 6, 2023 at 9:32 AM Daniel Vetter  wrote:
>
> On Wed, 5 Apr 2023 at 19:46, Patrik Jakobsson
>  wrote:
> >
> > On Wed, Apr 5, 2023 at 7:15 PM Daniel Vetter  wrote:
> > >
> > > On Wed, 5 Apr 2023 at 18:54, Javier Martinez Canillas
> > >  wrote:
> > > >
> > > > Daniel Vetter  writes:
> > > >
> > > > > On Wed, Apr 05, 2023 at 04:32:19PM +0200, Thomas Zimmermann wrote:
> > > >
> > > > [...]
> > > >
> > > > >> > > >/*
> > > > >> > > > * WARNING: Apparently we must kick fbdev drivers 
> > > > >> > > > before vgacon,
> > > > >> > > > * otherwise the vga fbdev driver falls over.
> > > > >> > > > */
> > > > >> > > >ret = vga_remove_vgacon(pdev);
> > > > >> >
> > > > >> > This isn't enough, we also nuke stuff that's mapping the vga fb 
> > > > >> > range.
> > > >
> > > > Ah, also need aperture_detach_devices(VGA_FB_PHYS_BASE, 
> > > > VGA_FB_PHYS_SIZE) then.
> > > >
> > > > [...]
> > > >
> > > > >> int aperture_remove_legacy_vga_devices(struct pci_dev *pdev)
> > > > >> {
> > > > >>  aperture_detach_devices(VGA_FB_PHYS_BASE, VGA_FB_PHYS_SIZE);
> > > > >>
> > > > >>  return vga_remove_vgacon(pdev);
> > > > >> }
> > > > >>
> > > > >> And that can be called from gma500 and the pci aperture helper.
> > > > >
> > > > > But you still pass a pci_dev to that helper. Which just doesn't make 
> > > > > any
> > > > > sense to me (assuming your entire point is that this isn't just a 
> > > > > normal
> > > > > pci device but some special legacy vga thing), but if we go with 
> > > > > (void)
> > > > > then there's more refactoring to do because the vga_remove_vgacon also
> > > > > wants a pdev.
> > > > >
> > > > > All so that we don't call aperture_detach_devices() on a bunch of pci
> > > > > bars, which apparently is not problem for any other driver, but 
> > > > > absolutely
> > > > > is a huge problem for gma500 somehow.
> > > > >
> > > > > I don't understand why.
> > > > >
> > > >
> > > > Yeah, agreed that if vga_remove_vgacon() isn't enough and another helper
> > > > is needed then starts to get a little silly. Maybe one option is to add 
> > > > a
> > > > 3rd param to aperture_remove_conflicting_pci_devices() and skip the 
> > > > logic
> > > > to iterate over PCI bars and call aperture_remove_conflicting_devices() 
> > > > ?
> > >
> > > The thing I don't get: Why does this matter for gma500 and not any of
> > > the other pci devices? Look at your gpu, realize there's a lot more
> > > than the one pci bar for vram or stolen memory, realize that we're
> > > nuking bars that cannot possible contain the framebuffer for everyone
> > > else too. Like the entire "gpus have a lot of bars" thing is the
> > > reason why I pulled the sysfb_disable one level up, because we've been
> > > doing that quite a few times before this patch (yes it's not the main
> > > thing, but the side-effect cleanup is why I've gone down this rabbit
> > > hole and wrote the entire series here):
> > >
> > > https://lore.kernel.org/dri-devel/20230404201842.567344-7-daniel.vet...@ffwll.ch/
> > >
> > > But somehow for gma500 it's a problem, while for everyone else it's
> > > fine. That's the part I dont get, or Thomas&me have been talking past
> > > each another and there's another issue that I'm missing.
> > > -Daniel
> >
> > I'm also getting confused here.
> >
> > AFAIK the stolen memory works the same for gma500 hardware as other
> > Intel GPUs. Are you saying that there is a difference in how gma500
> > hardware works? I always assumed that i915 got away with not dealing
> > much with stolen memory because it simply doesn't use it for
> > allocations. In gma500 we use it for fbdev and cursors. The actual
> > pages reserved by the bios can be accessed through a pci bar if you
> > map it so (which IIRC we do) but I suppose that doesn't help
> > identifying it as a range reserved by other drivers.
>
> The other integrated gpu have their fw fb behind a pci bar, and stolen
> is often entirely hidden from the cpu for direct access. gma500 seems
> different with having stolen as just a specially marked up range of
> normal system memory. That's why the usual pci helper doesn't catch
> everything for gma500.

Right, now I get it. You don't have the GATT on some systems so the
range can never be inside the aperture on those systems anyway.

The GATT probably went away because there is no need for it since you
don't get coherency with the PowerVR parts anyway.

Thanks for explaining

>
> > The reason I've kept the stolen allocation logic is because some
> > gma500 systems don't have a lot of memory. But that is mostly the old
> > Pouslbo systems. Perhaps it is time to ditch the stolen allocation
> > code?
>
> Yeah that's all fine.
> -Daniel
>
> >
> > -Patrik
> >
> > >
> > > > > Consider this me throwing in the towel. If you&Javier are convinced 
> > > > > this
> > > > > makes sense please type it up and merge it, but I'm not going to type
> > > > > something that just doesn't make sense to me.
> > > >
> > >

[Intel-gfx] [PULL] drm-intel-gt-next

2023-04-06 Thread Maarten Lankhorst


Hi Dave, Daniel,
Pull request to avoid backmerges. ;)
Cheers,
~Maarten

drm-misc-next-2023-04-06:
drm-misc-next for v6.4-rc1:

UAPI Changes:

Cross-subsystem Changes:
- Document port and rotation dt bindings better.
- For panel timing DT bindings, document that vsync and hsync are
  first, rather than last in image.
- Fix video/aperture typos.

Core Changes:
- Reject prime DMA-Buf attachment if get_sg_table is missing.
  (For self-importing dma-buf only.)
- Add prime import/export to vram-helper.
- Fix oops in drm/vblank when init is not called.
- Fixup xres/yres_virtual and other fixes in fb helper.
- Improve SCDC debugs.
- Skip setting deadline on modesets.
- Assorted TTM fixes.

Driver Changes:
- Add lima usage stats.
- Assorted fixes to bridge/lt8192b, tc358767, ivpu,
  bridge/ti-sn65dsi83, ps8640.
- Use pci aperture helpers in drm/ast lynxfb, radeonfb.
- Revert some lima patches, as they required a commit that has been
  reverted upstream.
- Add AUO NE135FBM-N41 v8.1 eDP panel.
- Add QAIC accel driver.
The following changes since commit 7d690f936e9bc9fbd6394fb3d4ad181af03ee393:

  drm/panfrost: Add basic support for speed binning (2023-03-31 11:44:11 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2023-04-06

for you to fetch changes up to e44f18c6ff8beef7b2b10592287f0a9766376d9b:

  drm/ttm: Make the call to ttm_tt_populate() interruptible when faulting 
(2023-04-06 10:01:42 +0200)


drm-misc-next for v6.4-rc1:

UAPI Changes:

Cross-subsystem Changes:
- Document port and rotation dt bindings better.
- For panel timing DT bindings, document that vsync and hsync are
  first, rather than last in image.
- Fix video/aperture typos.

Core Changes:
- Reject prime DMA-Buf attachment if get_sg_table is missing.
  (For self-importing dma-buf only.)
- Add prime import/export to vram-helper.
- Fix oops in drm/vblank when init is not called.
- Fixup xres/yres_virtual and other fixes in fb helper.
- Improve SCDC debugs.
- Skip setting deadline on modesets.
- Assorted TTM fixes.

Driver Changes:
- Add lima usage stats.
- Assorted fixes to bridge/lt8192b, tc358767, ivpu,
  bridge/ti-sn65dsi83, ps8640.
- Use pci aperture helpers in drm/ast lynxfb, radeonfb.
- Revert some lima patches, as they required a commit that has been
  reverted upstream.
- Add AUO NE135FBM-N41 v8.1 eDP panel.
- Add QAIC accel driver.


Alexander Stein (2):
  drm/bridge: ti-sn65dsi83: use dev_err_probe if host attach failed
  drm/bridge: ti-sn65dsi86: Allow GPIO operations to sleep

AngeloGioacchino Del Regno (1):
  drm/panel-edp: Add AUO NE135FBM-N41 v8.1 panel entry

Daniel Vetter (7):
  drm/ast: Use drm_aperture_remove_conflicting_pci_framebuffers
  staging/lynxfb: Use pci aperture helper
  fbdev/radeon: use pci aperture helpers
  drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
  drm/fb-helper: drop redundant pixclock check from drm_fb_helper_set_par()
  drm/fb-helper: fix input validation gaps in check_var
  drm/atomic-helper: Don't set deadline for modesets

Erico Nunes (3):
  drm/lima: add usage counting method to ctx_mgr
  drm/lima: allocate unique id per drm_file
  drm/lima: add show_fdinfo for drm usage stats

Francesco Dolcini (1):
  drm/bridge: lt8912b: Fix DSI Video Mode

Harshit Mogalapalli (1):
  drm/lima/lima_drv: Add missing unwind goto in lima_pdev_probe()

Jeffrey Hugo (7):
  accel/qaic: Add documentation for AIC100 accelerator driver
  accel/qaic: Add uapi and core driver file
  accel/qaic: Add MHI controller
  accel/qaic: Add control path
  accel/qaic: Add datapath
  accel/qaic: Add qaic driver to the build system
  MAINTAINERS: Add entry for QAIC driver

Karol Wachowski (1):
  accel/ivpu: Remove D3hot delay for Meteorlake

Krzysztof Kozlowski (5):
  dt-bindings: display: sitronix,st7789v: document dc-gpios
  dt-bindings: display: xinpeng,xpp055c272: document port
  dt-bindings: display: feiyang,fy07024di26a30d: document port
  dt-bindings: display: elida,kd35t133: document port and rotation
  dt-bindings: display: sitronix,st7701: document port and rotation

Luca Ceresoli (2):
  drm: bridge: ldb: add missing \n in dev_warn() string
  drm: bridge: ldb: add support for using channel 1 only

Marek Vasut (3):
  drm/bridge: tc358767: Enable DSI burst mode, LPM, non-continuous clock
  dt-bindings: display: Start the info graphics with HS/VS change
  drm/bridge: ti-sn65dsi83: Do not generate HFP/HBP/HSA and EOT packet

Pin-yen Lin (1):
  drm/bridge: ps8640: Use constant sleep time for polling hpd

Pranjal Ramajor Asha Kanojiya (1):
  accel/qaic: Add mhi_qaic_cntl

Qiang Yu (3):
  Revert "drm/lima: add show_fdinfo for drm usage stats"
  Revert "drm/lima: allocate unique id per drm_fi

Re: [Intel-gfx] [PATCH 01/12] drm/i915: Fix limited range csc matrix




On 4/6/2023 4:40 PM, Ville Syrjälä wrote:

On Thu, Apr 06, 2023 at 04:26:48PM +0530, Nautiyal, Ankit K wrote:

Hi Ville,

HDMI1.4b indeed says max value for 16bpc as 60160 (0xeb00)
And black level of 4096.

Got me thinking that we might need to consider bpc for getting the
Coeffs and the offsets.
IIUC for CSC Full range to Limited range:
out = in * gain  + offset

Gain :
So for 8 bpc, as you have mentioned
multiplier or gain will be: (235-16) / 255 = 0.8588 ~0.86
offset will be 16, as range is from 16-235

16 bpc
Multiplier: (60160-4096)/65535 = 0.8555 ~0.86
Offset for 16bit: should be 4096

So it seems Multiplier of 0.86 should be alright for different bpc, but
offset would vary.

It's all still in the pipe's internal precision. So any 16 vs. 4096
distinction doesn't exist.


Hmm alright.



Also CSC Postoff programming for the offset doesn’t seem very clear to me.
For CSC BT709 RGB Full range->YCbCr Limited Range, we use offset of {16,
128, 128} for Y, Cb, Cr, and we write 0x800, 0x100, 0x100 for these values.

Y is the middle channel. We write 0x800,0x100,0x800


Ah ok.. so offset of 16 is indeed 0x100, and not 0x800. (facepalm) I 
misread and created unnecessary confusion.


Thanks for your patience to clear the confusion.


Changes to coeff and offset seem to be correct now.

Reviewed-by: Ankit Nautiyal 




But below for Limited range Post offset 16,  we seem to be shifting by
(12 - 8) i.e 4. Am I missing something?


Regards,

Ankit

On 3/29/2023 7:19 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Our current limited range matrix is a bit off. I think it
was originally calculated with rounding, as if we wanted
the normal pixel replication type of behaviour.
That is, since the 8bpc max value is 0xeb we assumed the
16bpc max value should be 0xebeb, but what the HDMI spec
actually says it should be is 0xeb00.

So to get what we want we make the formula
   out = in * (235-16) << (12-8) / in_max + 16 << (12-8),
with 12 being precision of the csc, 8 being the precision
of the constants we used.

The hardware takes its coefficients as floating point
values, but the (235−16)/255 = ~.86, so exponent 0
is what we want anyway, so it works out perfectly without
having to hardcode it in hex or start playing with floats.

In terms of raw numbers we are feeding the hardware the
post offset changes from 0x101 to 0x100, and the coefficient
changes from 0xdc0 to 0xdb0 (~.860->~.855). So this should
make everything come out just a tad darker.

I already used better constants in lut_limited_range() earlier
so the output of the two paths should be closer now.

Signed-off-by: Ville Syrjälä 
---
   drivers/gpu/drm/i915/display/intel_color.c | 5 ++---
   1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 36aac88143ac..3c3e2f5a5cde 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -116,10 +116,9 @@ struct intel_color_funcs {
   #define ILK_CSC_COEFF_FP(coeff, fbits)   \
(clamp_val(((coeff) >> (32 - (fbits) - 3)) + 4, 0, 0xfff) & 0xff8)
   
-#define ILK_CSC_COEFF_LIMITED_RANGE 0x0dc0

   #define ILK_CSC_COEFF_1_0 0x7800
-
-#define ILK_CSC_POSTOFF_LIMITED_RANGE (16 * (1 << 12) / 255)
+#define ILK_CSC_COEFF_LIMITED_RANGE ((235 - 16) << (12 - 8)) /* exponent 0 */
+#define ILK_CSC_POSTOFF_LIMITED_RANGE (16 << (12 - 8))
   
   /* Nop pre/post offsets */

   static const u16 ilk_csc_off_zero[3] = {};

Re: [Intel-gfx] [PATCH] drm/i915: Query compressed bpp properly using correct DPCD and DP Spec info

2023-04-06 Thread Lisovskiy, Stanislav

On Thu, Apr 06, 2023 at 01:56:00PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 06, 2023 at 12:59:40PM +0300, Jani Nikula wrote:
> > On Thu, 06 Apr 2023, Stanislav Lisovskiy  
> > wrote:
> > > Currently we seem to be using wrong DPCD register for reading compressed 
> > > bpps,
> > > reading min/max input bpc instead of compressed bpp.
> > > Fix that, so that we now apply min/max compressed bpp limitations we get
> > > from DP Spec Table 2-157 DP v2.0 and/or correspondent DPCD register
> > > DP_DSC_MAX_BITS_PER_PIXEL_LOW/HIGH.
> > >
> > > This might also allow us to get rid of an ugly compressed bpp 
> > > recalculation,
> > > which we had to add to make some MST hubs usable.
> > >
> > > Signed-off-by: Stanislav Lisovskiy 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_dp_mst.c | 76 ++---
> > >  1 file changed, 52 insertions(+), 24 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > index a88b852c437c..9479c7e0b269 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > @@ -174,6 +174,50 @@ static int intel_dp_mst_compute_link_config(struct 
> > > intel_encoder *encoder,
> > >   return 0;
> > >  }
> > >  
> > > +static u16 dsc_max_sink_compressed_bppx16(const u8 
> > > dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
> > > +   struct intel_crtc_state *pipe_config,
> > > +   int bpc)
> > > +{
> > > + u16 max_bppx16 = dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_LOW - 
> > > DP_DSC_SUPPORT] |
> > > +  (dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_HI - 
> > > DP_DSC_SUPPORT] &
> > > +   DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK << 
> > > DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT);
> > 
> > This duplicates drm_edp_dsc_sink_output_bpp().
> 
> These registers are not even valid for non-eDP.

You need to mention this then in review for Ankit's patches, as I took it from
there, he still is working on this series I guess and at some point we should 
use that DSC api also for MST.

Stan
> 
> > 
> > Both have operator precedence wrong, leading to the high byte always
> > being ignored. For example, sink reported max bpp of 32 turns to 0, and
> > 24 turns to 8.
> > 
> > Broken since 2018. 0575650077ea ("drm/dp: DRM DP helper/macros to get DP
> > sink DSC parameters").
> > 
> > The definition of DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT is misleading wrt
> > all of our regular usage. We should never have a FOO_MASK << FOO_SHIFT
> > in code, the MASK should always be already shifted in place. Here we do,
> > because the shift is not for shifting the mask in place, it's for
> > combining the high and low bytes. But I don't really think
> > DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT should exist, at all.
> > 
> > BR,
> > Jani.
> > 
> > 
> > 
> > > +
> > > + if (max_bppx16)
> > > + return max_bppx16;
> > > + /*
> > > +  * If support not given in DPCD 67h, 68h use the Maximum Allowed bit 
> > > rate
> > > +  * values as given in spec Table 2-157 DP v2.0
> > > +  */
> > > + switch (pipe_config->output_format) {
> > > + case INTEL_OUTPUT_FORMAT_RGB:
> > > + case INTEL_OUTPUT_FORMAT_YCBCR444:
> > > + return bpc << 4;
> > > + case INTEL_OUTPUT_FORMAT_YCBCR420:
> > > + return (3 * (bpc / 2)) << 4;
> > > + default:
> > > + MISSING_CASE(pipe_config->output_format);
> > > + break;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static u16 dsc_min_compressed_bppx16(struct intel_crtc_state 
> > > *pipe_config)
> > > +{
> > > + switch (pipe_config->output_format) {
> > > + case INTEL_OUTPUT_FORMAT_RGB:
> > > + case INTEL_OUTPUT_FORMAT_YCBCR444:
> > > + return 8 << 4;
> > > + case INTEL_OUTPUT_FORMAT_YCBCR420:
> > > + return 6 << 4;
> > > + default:
> > > + MISSING_CASE(pipe_config->output_format);
> > > + break;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > >  static int intel_dp_dsc_mst_compute_link_config(struct intel_encoder 
> > > *encoder,
> > >   struct intel_crtc_state 
> > > *crtc_state,
> > >   struct drm_connector_state 
> > > *conn_state,
> > > @@ -191,8 +235,6 @@ static int 
> > > intel_dp_dsc_mst_compute_link_config(struct intel_encoder *encoder,
> > >   u8 dsc_bpc[3] = {0};
> > >   int min_bpp, max_bpp, sink_min_bpp, sink_max_bpp;
> > >   u8 dsc_max_bpc;
> > > - bool need_timeslot_recalc = false;
> > > - u32 last_compressed_bpp;
> > >  
> > >   /* Max DSC Input BPC for ICL is 10 and for TGL+ is 12 */
> > >   if (DISPLAY_VER(i915) >= 12)
> > > @@ -228,6 +270,14 @@ static int 
> > > intel_dp_dsc_mst_compute_link_config(struct intel_encoder *encoder,
> > >   if (max_bpp > sink_max_bpp)
> > >   max_bpp = sink_max_bpp;
> > >  
> > > + /* Get Min/Max compressed bpp's for those Input Bpps we got for 
> > > source/sink */
> > > + max_bpp = min(

Re: [Intel-gfx] [PATCH 5/5] drm/debugfs: remove debugfs_root pointer from minor

On Fri, 31 Mar 2023, "Christian König"  wrote:
> We only keept that around for API compatibility with drivers. Clean all
> this up and use the per device debugfs directory.
>
> Signed-off-by: Christian König 
> ---
>  drivers/accel/drm_accel.c  |  2 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c|  4 ++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |  3 +--
>  .../gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c|  3 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c |  3 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|  4 +---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c |  5 ++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c|  6 +++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c|  6 +++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  3 +--
>  .../gpu/drm/amd/amdgpu/amdgpu_securedisplay.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|  3 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c|  3 +--
>  .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c  |  2 +-
>  drivers/gpu/drm/amd/pm/amdgpu_pm.c |  3 +--
>  drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c  |  2 +-
>  drivers/gpu/drm/arm/malidp_drv.c   |  2 +-
>  drivers/gpu/drm/armada/armada_debugfs.c|  2 +-
>  drivers/gpu/drm/drm_debugfs.c  |  3 ---
>  drivers/gpu/drm/drm_mipi_dbi.c |  2 +-
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c  |  2 +-
>  .../drm/i915/display/intel_display_debugfs.c   |  4 ++--
>  drivers/gpu/drm/i915/display/intel_dmc.c   |  2 +-
>  drivers/gpu/drm/i915/display/intel_fbc.c   |  2 +-
>  drivers/gpu/drm/i915/display/intel_hotplug.c   |  9 ++---
>  drivers/gpu/drm/i915/display/intel_psr.c   |  6 --
>  drivers/gpu/drm/i915/display/intel_wm.c|  9 ++---
>  drivers/gpu/drm/i915/display/skl_watermark.c   |  6 --
>  drivers/gpu/drm/i915/gt/intel_gt_debugfs.c |  4 ++--
>  drivers/gpu/drm/i915/gvt/debugfs.c |  6 +++---
>  drivers/gpu/drm/i915/i915_debugfs.c|  6 +++---
>  drivers/gpu/drm/i915/i915_debugfs_params.c |  2 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c   |  4 ++--
>  drivers/gpu/drm/msm/adreno/a5xx_debugfs.c  |  4 ++--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|  2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  2 +-
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c   |  2 +-
>  drivers/gpu/drm/msm/dp/dp_debug.c  |  2 +-
>  drivers/gpu/drm/msm/msm_debugfs.c  | 18 +-
>  drivers/gpu/drm/msm/msm_perf.c |  2 +-
>  drivers/gpu/drm/msm/msm_rd.c   |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_debugfs.c  |  6 +++---
>  drivers/gpu/drm/omapdrm/omap_debugfs.c |  4 ++--
>  drivers/gpu/drm/pl111/pl111_debugfs.c  |  2 +-
>  drivers/gpu/drm/qxl/qxl_debugfs.c  |  4 ++--
>  drivers/gpu/drm/qxl/qxl_ttm.c  |  4 ++--
>  drivers/gpu/drm/radeon/r100.c  |  6 +++---
>  drivers/gpu/drm/radeon/r300.c  |  2 +-
>  drivers/gpu/drm/radeon/r420.c  |  2 +-
>  drivers/gpu/drm/radeon/r600.c  |  2 +-
>  drivers/gpu/drm/radeon/radeon_fence.c  |  2 +-
>  drivers/gpu/drm/radeon/radeon_gem.c|  2 +-
>  drivers/gpu/drm/radeon/radeon_ib.c |  2 +-
>  drivers/gpu/drm/radeon/radeon_pm.c |  2 +-
>  drivers/gpu/drm/radeon/radeon_ring.c   |  2 +-
>  drivers/gpu/drm/radeon/radeon_ttm.c|  2 +-
>  drivers/gpu/drm/radeon/rs400.c |  2 +-
>  drivers/gpu/drm/radeon/rv515.c |  2 +-
>  drivers/gpu/drm/sti/sti_cursor.c   |  2 +-
>  drivers/gpu/drm/sti/sti_drv.c  |  4 ++--
>  drivers/gpu/drm/sti/sti_dvo.c  |  2 +-
>  drivers/gpu/drm/sti/sti_gdp.c  |  2 +-
>  drivers/gpu/drm/sti/sti_hda.c  |  2 +-
>  drivers/gpu/drm/sti/sti_hdmi.c |  2 +-
>  drivers/gpu/drm/sti/sti_hqvdp.c|  2 +-
>  drivers/gpu/drm/sti/sti_mixer.c|  2 +-
>  drivers/gpu/drm/sti/sti_tvout.c|  2 +-
>  drivers/gpu/drm/sti/sti_vid.c  |  2 +-
>  drivers/gpu/drm/tegra/drm.c|  2 +-
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c|  2 +-
>  drivers/gpu/drm/tiny/arcpgu.c  |  2 +-
>  drivers/gpu/drm/vc4/vc4_hvs.c  |  2 +-
>  drivers/gpu/drm/virtio/virtgpu_debugfs.c   |  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c|  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_gem.c|  2 +-
>  include/drm/drm_file.h |  2 --
>  77 files changed, 120 insertions(+), 127 deletions(-)
>
> diff --git a/drivers/accel/drm_accel.c b/drivers/accel/drm_accel.c
> index 82c54bc2dcad..7e4176c736a5 100644
> --- a/drivers/accel/drm_accel.c
> +++ b/drivers/accel

Re: [Intel-gfx] [PULL] drm-intel-gt-next

On Thu, 06 Apr 2023, Maarten Lankhorst  
wrote:
> Hi Dave, Daniel,
> Pull request to avoid backmerges. ;)
> Cheers,
> ~Maarten

Not using dim for this? Is the subject line copy-pasted from another
pull request? :)

BR,
Jani.

>
> drm-misc-next-2023-04-06:
> drm-misc-next for v6.4-rc1:
>
> UAPI Changes:
>
> Cross-subsystem Changes:
> - Document port and rotation dt bindings better.
> - For panel timing DT bindings, document that vsync and hsync are
>first, rather than last in image.
> - Fix video/aperture typos.
>
> Core Changes:
> - Reject prime DMA-Buf attachment if get_sg_table is missing.
>(For self-importing dma-buf only.)
> - Add prime import/export to vram-helper.
> - Fix oops in drm/vblank when init is not called.
> - Fixup xres/yres_virtual and other fixes in fb helper.
> - Improve SCDC debugs.
> - Skip setting deadline on modesets.
> - Assorted TTM fixes.
>
> Driver Changes:
> - Add lima usage stats.
> - Assorted fixes to bridge/lt8192b, tc358767, ivpu,
>bridge/ti-sn65dsi83, ps8640.
> - Use pci aperture helpers in drm/ast lynxfb, radeonfb.
> - Revert some lima patches, as they required a commit that has been
>reverted upstream.
> - Add AUO NE135FBM-N41 v8.1 eDP panel.
> - Add QAIC accel driver.
> The following changes since commit 7d690f936e9bc9fbd6394fb3d4ad181af03ee393:
>
>drm/panfrost: Add basic support for speed binning (2023-03-31 11:44:11 
> +0200)
>
> are available in the Git repository at:
>
>git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2023-04-06
>
> for you to fetch changes up to e44f18c6ff8beef7b2b10592287f0a9766376d9b:
>
>drm/ttm: Make the call to ttm_tt_populate() interruptible when faulting 
> (2023-04-06 10:01:42 +0200)
>
> 
> drm-misc-next for v6.4-rc1:
>
> UAPI Changes:
>
> Cross-subsystem Changes:
> - Document port and rotation dt bindings better.
> - For panel timing DT bindings, document that vsync and hsync are
>first, rather than last in image.
> - Fix video/aperture typos.
>
> Core Changes:
> - Reject prime DMA-Buf attachment if get_sg_table is missing.
>(For self-importing dma-buf only.)
> - Add prime import/export to vram-helper.
> - Fix oops in drm/vblank when init is not called.
> - Fixup xres/yres_virtual and other fixes in fb helper.
> - Improve SCDC debugs.
> - Skip setting deadline on modesets.
> - Assorted TTM fixes.
>
> Driver Changes:
> - Add lima usage stats.
> - Assorted fixes to bridge/lt8192b, tc358767, ivpu,
>bridge/ti-sn65dsi83, ps8640.
> - Use pci aperture helpers in drm/ast lynxfb, radeonfb.
> - Revert some lima patches, as they required a commit that has been
>reverted upstream.
> - Add AUO NE135FBM-N41 v8.1 eDP panel.
> - Add QAIC accel driver.
>
> 
> Alexander Stein (2):
>drm/bridge: ti-sn65dsi83: use dev_err_probe if host attach failed
>drm/bridge: ti-sn65dsi86: Allow GPIO operations to sleep
>
> AngeloGioacchino Del Regno (1):
>drm/panel-edp: Add AUO NE135FBM-N41 v8.1 panel entry
>
> Daniel Vetter (7):
>drm/ast: Use drm_aperture_remove_conflicting_pci_framebuffers
>staging/lynxfb: Use pci aperture helper
>fbdev/radeon: use pci aperture helpers
>drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
>drm/fb-helper: drop redundant pixclock check from 
> drm_fb_helper_set_par()
>drm/fb-helper: fix input validation gaps in check_var
>drm/atomic-helper: Don't set deadline for modesets
>
> Erico Nunes (3):
>drm/lima: add usage counting method to ctx_mgr
>drm/lima: allocate unique id per drm_file
>drm/lima: add show_fdinfo for drm usage stats
>
> Francesco Dolcini (1):
>drm/bridge: lt8912b: Fix DSI Video Mode
>
> Harshit Mogalapalli (1):
>drm/lima/lima_drv: Add missing unwind goto in lima_pdev_probe()
>
> Jeffrey Hugo (7):
>accel/qaic: Add documentation for AIC100 accelerator driver
>accel/qaic: Add uapi and core driver file
>accel/qaic: Add MHI controller
>accel/qaic: Add control path
>accel/qaic: Add datapath
>accel/qaic: Add qaic driver to the build system
>MAINTAINERS: Add entry for QAIC driver
>
> Karol Wachowski (1):
>accel/ivpu: Remove D3hot delay for Meteorlake
>
> Krzysztof Kozlowski (5):
>dt-bindings: display: sitronix,st7789v: document dc-gpios
>dt-bindings: display: xinpeng,xpp055c272: document port
>dt-bindings: display: feiyang,fy07024di26a30d: document port
>dt-bindings: display: elida,kd35t133: document port and rotation
>dt-bindings: display: sitronix,st7701: document port and rotation
>
> Luca Ceresoli (2):
>drm: bridge: ldb: add missing \n in dev_warn() string
>drm: bridge: ldb: add support for using channel 1 only
>
> Marek Vasut (3):
>drm/bridge: tc358767: Enable DSI burst mode, LPM, non-continuous cloc

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/tc: demote a kernel-doc comment to a regular comment

== Series Details ==

Series: series starting with [1/2] drm/i915/tc: demote a kernel-doc comment to 
a regular comment
URL   : https://patchwork.freedesktop.org/series/116144/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12974_full -> Patchwork_116144v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_116144v1_full:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_exec_suspend@basic-s3@lmem0:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116144v1/shard-dg1-16/igt@gem_exec_suspend@basic...@lmem0.html

  
Known issues


  Here are the changes found in Patchwork_116144v1_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rps@reset:
- shard-snb:  [PASS][2] -> [INCOMPLETE][3] ([i915#7790])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-snb4/igt@i915_pm_...@reset.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116144v1/shard-snb2/igt@i915_pm_...@reset.html

  * igt@kms_flip@flip-vs-blocking-wf-vblank@c-hdmi-a1:
- shard-glk:  [PASS][4] -> [FAIL][5] ([i915#2122])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-glk6/igt@kms_flip@flip-vs-blocking-wf-vbl...@c-hdmi-a1.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116144v1/shard-glk4/igt@kms_flip@flip-vs-blocking-wf-vbl...@c-hdmi-a1.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-dp1:
- shard-apl:  [PASS][6] -> [FAIL][7] ([i915#79])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-apl1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-dp1.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116144v1/shard-apl3/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-dp1.html

  * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:
- shard-apl:  [PASS][8] -> [ABORT][9] ([i915#180])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-apl6/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116144v1/shard-apl1/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html

  
 Possible fixes 

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl:  [FAIL][10] ([i915#2842]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-apl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116144v1/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- {shard-rkl}:[FAIL][12] ([i915#2842]) -> [PASS][13] +2 similar 
issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-rkl-3/igt@gem_exec_fair@basic-p...@vecs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116144v1/shard-rkl-6/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@i915_pm_dc@dc6-dpms:
- {shard-tglu}:   [FAIL][14] ([i915#3989] / [i915#454]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-tglu-7/igt@i915_pm...@dc6-dpms.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116144v1/shard-tglu-2/igt@i915_pm...@dc6-dpms.html

  * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
- {shard-rkl}:[FAIL][16] ([i915#3743]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-rkl-7/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116144v1/shard-rkl-4/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html

  * igt@kms_cursor_legacy@forked-move@pipe-b:
- {shard-rkl}:[INCOMPLETE][18] ([i915#8011]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-rkl-7/igt@kms_cursor_legacy@forked-m...@pipe-b.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116144v1/shard-rkl-4/igt@kms_cursor_legacy@forked-m...@pipe-b.html

  * igt@kms_flip@2x-flip-vs-expired-vblank@ab-hdmi-a1-hdmi-a2:
- shard-glk:  [FAIL][20] ([i915#2122]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-glk3/igt@kms_flip@2x-flip-vs-expired-vbl...@ab-hdmi-a1-hdmi-a2.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116144v1/shard-glk4/igt@kms_flip@2x-flip-vs-expired-vbl...@ab-hdmi-a1-hdmi-a2.html

  * igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a2:
- shard-glk:

Re: [Intel-gfx] [PATCH] drm/i915: Query compressed bpp properly using correct DPCD and DP Spec info

2023-04-06 Thread Lisovskiy, Stanislav

On Thu, Apr 06, 2023 at 01:56:00PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 06, 2023 at 12:59:40PM +0300, Jani Nikula wrote:
> > On Thu, 06 Apr 2023, Stanislav Lisovskiy  
> > wrote:
> > > Currently we seem to be using wrong DPCD register for reading compressed 
> > > bpps,
> > > reading min/max input bpc instead of compressed bpp.
> > > Fix that, so that we now apply min/max compressed bpp limitations we get
> > > from DP Spec Table 2-157 DP v2.0 and/or correspondent DPCD register
> > > DP_DSC_MAX_BITS_PER_PIXEL_LOW/HIGH.
> > >
> > > This might also allow us to get rid of an ugly compressed bpp 
> > > recalculation,
> > > which we had to add to make some MST hubs usable.
> > >
> > > Signed-off-by: Stanislav Lisovskiy 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_dp_mst.c | 76 ++---
> > >  1 file changed, 52 insertions(+), 24 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > index a88b852c437c..9479c7e0b269 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > @@ -174,6 +174,50 @@ static int intel_dp_mst_compute_link_config(struct 
> > > intel_encoder *encoder,
> > >   return 0;
> > >  }
> > >  
> > > +static u16 dsc_max_sink_compressed_bppx16(const u8 
> > > dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
> > > +   struct intel_crtc_state *pipe_config,
> > > +   int bpc)
> > > +{
> > > + u16 max_bppx16 = dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_LOW - 
> > > DP_DSC_SUPPORT] |
> > > +  (dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_HI - 
> > > DP_DSC_SUPPORT] &
> > > +   DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK << 
> > > DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT);
> > 
> > This duplicates drm_edp_dsc_sink_output_bpp().
> 
> These registers are not even valid for non-eDP.

BTW just checked DP 2.0 spec, says "For DP v2.0 (and higher) and eDP v1.4a (and 
higher)"
for registers 0x67, 0x68.

Otherwise if those are cleared and for older DP/eDP standards it instruct to 
use Table 2-154.

So I guess this function can be used still.

Stan

> 
> > 
> > Both have operator precedence wrong, leading to the high byte always
> > being ignored. For example, sink reported max bpp of 32 turns to 0, and
> > 24 turns to 8.
> > 
> > Broken since 2018. 0575650077ea ("drm/dp: DRM DP helper/macros to get DP
> > sink DSC parameters").
> > 
> > The definition of DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT is misleading wrt
> > all of our regular usage. We should never have a FOO_MASK << FOO_SHIFT
> > in code, the MASK should always be already shifted in place. Here we do,
> > because the shift is not for shifting the mask in place, it's for
> > combining the high and low bytes. But I don't really think
> > DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT should exist, at all.
> > 
> > BR,
> > Jani.
> > 
> > 
> > 
> > > +
> > > + if (max_bppx16)
> > > + return max_bppx16;
> > > + /*
> > > +  * If support not given in DPCD 67h, 68h use the Maximum Allowed bit 
> > > rate
> > > +  * values as given in spec Table 2-157 DP v2.0
> > > +  */
> > > + switch (pipe_config->output_format) {
> > > + case INTEL_OUTPUT_FORMAT_RGB:
> > > + case INTEL_OUTPUT_FORMAT_YCBCR444:
> > > + return bpc << 4;
> > > + case INTEL_OUTPUT_FORMAT_YCBCR420:
> > > + return (3 * (bpc / 2)) << 4;
> > > + default:
> > > + MISSING_CASE(pipe_config->output_format);
> > > + break;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static u16 dsc_min_compressed_bppx16(struct intel_crtc_state 
> > > *pipe_config)
> > > +{
> > > + switch (pipe_config->output_format) {
> > > + case INTEL_OUTPUT_FORMAT_RGB:
> > > + case INTEL_OUTPUT_FORMAT_YCBCR444:
> > > + return 8 << 4;
> > > + case INTEL_OUTPUT_FORMAT_YCBCR420:
> > > + return 6 << 4;
> > > + default:
> > > + MISSING_CASE(pipe_config->output_format);
> > > + break;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > >  static int intel_dp_dsc_mst_compute_link_config(struct intel_encoder 
> > > *encoder,
> > >   struct intel_crtc_state 
> > > *crtc_state,
> > >   struct drm_connector_state 
> > > *conn_state,
> > > @@ -191,8 +235,6 @@ static int 
> > > intel_dp_dsc_mst_compute_link_config(struct intel_encoder *encoder,
> > >   u8 dsc_bpc[3] = {0};
> > >   int min_bpp, max_bpp, sink_min_bpp, sink_max_bpp;
> > >   u8 dsc_max_bpc;
> > > - bool need_timeslot_recalc = false;
> > > - u32 last_compressed_bpp;
> > >  
> > >   /* Max DSC Input BPC for ICL is 10 and for TGL+ is 12 */
> > >   if (DISPLAY_VER(i915) >= 12)
> > > @@ -228,6 +270,14 @@ static int 
> > > intel_dp_dsc_mst_compute_link_config(struct intel_encoder *encoder,
> > >   if (max_bpp > sink_max_bpp)
> > >   max_bpp = sink_max_bpp;
> > >  
> > > + /* Get Min/Max compressed bpp's for tho

Re: [Intel-gfx] [PULL] drm-intel-gt-next

On Thu, Apr 06, 2023 at 11:18:06AM +0300, Joonas Lahtinen wrote:
> Hi Dave & Daniel,
> 
> Here goes the final drm-intel-gt-next pull request for v6.4.
> 
> As top items we have a fix for context runtime accounting, Meteorlake
> enabling, DMAR error noise elimination due to GPU error capture, BAR
> resizing forcewake fix and memory contents clearing fix for discrete.
> More robust GuC loading on systems with IFWI that leaves GPU to slow
> frequency and a potential UAF closed on perf add_config IOCTL.
> 
> There is also change to the uAPI headers to eliminate flexible-array
> member kernel-wide request, which does not impact binaries and also
> should not impact compilation.
> 
> Then the usual amount of smaller fixes and cleanups. A good amount of
> kerneldoc fixes included.
> 
> Best Regards, Joonas
> 
> ***
> 
> drm-intel-gt-next-2023-04-06:
> 
> UAPI Changes:
> 
> - (Build-time only, should not have any impact)
>   drm/i915/uapi: Replace fake flex-array with flexible-array member
> 
>   "Zero-length arrays as fake flexible arrays are deprecated and we are
>   moving towards adopting C99 flexible-array members instead."
> 
>   This is on core kernel request moving towards GCC 13.
> 
> Driver Changes:
> 
> - Fix context runtime accounting on sysfs fdinfo for heavy workloads (Tvrtko)
> - Add support for OA media units on MTL (Umesh)
> - Add new workarounds for Meteorlake (Daniele, Radhakrishna, Haridhar)
> - Fix sysfs to read actual frequency for MTL and Gen6 and earlier
>   (Ashutosh)
> - Synchronize i915/BIOS on C6 enabling on MTL (Vinay)
> - Fix DMAR error noise due to GPU error capture (Andrej)
> - Fix forcewake during BAR resize on discrete (Andrzej)
> - Flush lmem contents after construction on discrete (Chris)
> - Fix GuC loading timeout on systems where IFWI programs low boot
>   frequency (John)
> - Fix race condition UAF in i915_perf_add_config_ioctl (Min)
> 
> - Sanitycheck MMIO access early in driver load and during forcewake
>   (Matt)
> - Wakeref fixes for GuC RC error scenario and active VM tracking (Chris)
> - Cancel HuC delayed load timer on reset (Daniele)
> - Limit double GT reset to pre-MTL (Daniele)
> - Use i915 instead of dev_priv insied the file_priv structure (Andi)
> - Improve GuC load error reporting (John)
> - Simplify VCS/BSD engine selection logic (Tvrtko)
> - Perform uc late init after probe error injection (Andrzej)
> - Fix format for perf_limit_reasons in debugfs (Vinay)
> - Create per-gt debugfs files (Andi)
> 
> - Documentation and kerneldoc fixes (Nirmoy, Lee)
> - Selftest improvements (Fei, Jonathan)
> 
> The following changes since commit d2a9692ad4295e227e3352fdbf14b8491b01e1c9:
> 
>   drm/i915/gt: make kobj attributes const (2023-03-15 12:20:11 +0200)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm-intel 
> tags/drm-intel-gt-next-2023-04-06
> 
> for you to fetch changes up to 4b51210f98c2b89ce37aede5b8dc5105be0572c6:
> 
>   drm/i915/mtl: Add Wa_14017856879 (2023-04-05 07:59:12 -0700)

Pulled, thanks

> 
> 
> UAPI Changes:
> 
> - (Build-time only, should not have any impact)
>   drm/i915/uapi: Replace fake flex-array with flexible-array member
> 
>   "Zero-length arrays as fake flexible arrays are deprecated and we are
>   moving towards adopting C99 flexible-array members instead."
> 
>   This is on core kernel request moving towards GCC 13.
> 
> Driver Changes:
> 
> - Fix context runtime accounting on sysfs fdinfo for heavy workloads (Tvrtko)
> - Add support for OA media units on MTL (Umesh)
> - Add new workarounds for Meteorlake (Daniele, Radhakrishna, Haridhar)
> - Fix sysfs to read actual frequency for MTL and Gen6 and earlier
>   (Ashutosh)
> - Synchronize i915/BIOS on C6 enabling on MTL (Vinay)
> - Fix DMAR error noise due to GPU error capture (Andrej)
> - Fix forcewake during BAR resize on discrete (Andrzej)
> - Flush lmem contents after construction on discrete (Chris)
> - Fix GuC loading timeout on systems where IFWI programs low boot
>   frequency (John)
> - Fix race condition UAF in i915_perf_add_config_ioctl (Min)
> 
> - Sanitycheck MMIO access early in driver load and during forcewake
>   (Matt)
> - Wakeref fixes for GuC RC error scenario and active VM tracking (Chris)
> - Cancel HuC delayed load timer on reset (Daniele)
> - Limit double GT reset to pre-MTL (Daniele)
> - Use i915 instead of dev_priv insied the file_priv structure (Andi)
> - Improve GuC load error reporting (John)
> - Simplify VCS/BSD engine selection logic (Tvrtko)
> - Perform uc late init after probe error injection (Andrzej)
> - Fix format for perf_limit_reasons in debugfs (Vinay)
> - Create per-gt debugfs files (Andi)
> 
> - Documentation and kerneldoc fixes (Nirmoy, Lee)
> - Selftest improvements (Fei, Jonathan)
> 
> 
> Andi Shyti (3):
>   drm/i915/gt: Create per-gt debugfs files
>   drm/i915/debugfs: Enable up

Re: [Intel-gfx] [PATCH v9 07/25] vfio: Pass struct vfio_device_file * to vfio_device_open/close()

Hi Yi,

On 4/1/23 17:18, Yi Liu wrote:
> This avoids passing too much parameters in multiple functions.
> Reviewed-by: Kevin Tian 
> Reviewed-by: Jason Gunthorpe 
> Tested-by: Terrence Xu 
> Tested-by: Nicolin Chen 
> Tested-by: Matthew Rosato 
> Tested-by: Yanting Jiang 
> Signed-off-by: Yi Liu 
> ---
>  drivers/vfio/group.c | 20 ++--
>  drivers/vfio/vfio.h  |  8 
>  drivers/vfio/vfio_main.c | 25 +++--
>  3 files changed, 33 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
> index 4f937ebaf6f7..9a7b2765eef6 100644
> --- a/drivers/vfio/group.c
> +++ b/drivers/vfio/group.c
> @@ -169,8 +169,9 @@ static void vfio_device_group_get_kvm_safe(struct 
> vfio_device *device)
>   spin_unlock(&device->group->kvm_ref_lock);
>  }
>  
> -static int vfio_device_group_open(struct vfio_device *device)
> +static int vfio_device_group_open(struct vfio_device_file *df)
>  {
> + struct vfio_device *device = df->device;
>   int ret;
>  
>   mutex_lock(&device->group->group_lock);
> @@ -190,7 +191,11 @@ static int vfio_device_group_open(struct vfio_device 
> *device)
>   if (device->open_count == 0)
>   vfio_device_group_get_kvm_safe(device);
>  
> - ret = vfio_device_open(device, device->group->iommufd);
> + df->iommufd = device->group->iommufd;
> +
> + ret = vfio_device_open(df);
> + if (ret)
> + df->iommufd = NULL;
>  
>   if (device->open_count == 0)
>   vfio_device_put_kvm(device);
> @@ -202,12 +207,15 @@ static int vfio_device_group_open(struct vfio_device 
> *device)
>   return ret;
>  }
>  
> -void vfio_device_group_close(struct vfio_device *device)
> +void vfio_device_group_close(struct vfio_device_file *df)
>  {
> + struct vfio_device *device = df->device;
> +
>   mutex_lock(&device->group->group_lock);
>   mutex_lock(&device->dev_set->lock);
>  
> - vfio_device_close(device, device->group->iommufd);
> + vfio_device_close(df);
> + df->iommufd = NULL; 
>   if (device->open_count == 0)
>   vfio_device_put_kvm(device);
> @@ -228,7 +236,7 @@ static struct file *vfio_device_open_file(struct 
> vfio_device *device)
>   goto err_out;
>   }
>  
> - ret = vfio_device_group_open(device);
> + ret = vfio_device_group_open(df);
>   if (ret)
>   goto err_free;
>  
> @@ -260,7 +268,7 @@ static struct file *vfio_device_open_file(struct 
> vfio_device *device)
>   return filep;
>  
>  err_close_device:
> - vfio_device_group_close(device);
> + vfio_device_group_close(df);
>  err_free:
>   kfree(df);
>  err_out:
> diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
> index e4672d91a6f7..cffc08f5a6f1 100644
> --- a/drivers/vfio/vfio.h
> +++ b/drivers/vfio/vfio.h
> @@ -20,13 +20,13 @@ struct vfio_device_file {
>   struct vfio_device *device;
>   spinlock_t kvm_ref_lock; /* protect kvm field */
>   struct kvm *kvm;
> + struct iommufd_ctx *iommufd; /* protected by struct 
> vfio_device_set::lock */
>  };
>  
>  void vfio_device_put_registration(struct vfio_device *device);
>  bool vfio_device_try_get_registration(struct vfio_device *device);
> -int vfio_device_open(struct vfio_device *device, struct iommufd_ctx 
> *iommufd);
> -void vfio_device_close(struct vfio_device *device,
> -struct iommufd_ctx *iommufd);
> +int vfio_device_open(struct vfio_device_file *df);
> +void vfio_device_close(struct vfio_device_file *df);
>  struct vfio_device_file *
>  vfio_allocate_device_file(struct vfio_device *device);
>  
> @@ -91,7 +91,7 @@ void vfio_device_group_register(struct vfio_device *device);
>  void vfio_device_group_unregister(struct vfio_device *device);
>  int vfio_device_group_use_iommu(struct vfio_device *device);
>  void vfio_device_group_unuse_iommu(struct vfio_device *device);
> -void vfio_device_group_close(struct vfio_device *device);
> +void vfio_device_group_close(struct vfio_device_file *df);
>  struct vfio_group *vfio_group_from_file(struct file *file);
>  bool vfio_group_has_dev(struct vfio_group *group, struct vfio_device 
> *device);
>  bool vfio_group_enforced_coherent(struct vfio_group *group);
> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> index cb543791b28b..2ea6cb6d03c7 100644
> --- a/drivers/vfio/vfio_main.c
> +++ b/drivers/vfio/vfio_main.c
> @@ -419,9 +419,10 @@ vfio_allocate_device_file(struct vfio_device *device)
>   return df;
>  }
>  
> -static int vfio_device_first_open(struct vfio_device *device,
> -   struct iommufd_ctx *iommufd)
> +static int vfio_device_first_open(struct vfio_device_file *df)
>  {
> + struct vfio_device *device = df->device;
> + struct iommufd_ctx *iommufd = df->iommufd;
>   int ret;
>  
>   lockdep_assert_held(&device->dev_set->lock);
> @@ -453,9 +454,11 @@ static int vfio_device_first_open(struct vfio_device 
> *device,
>

Re: [Intel-gfx] [PATCH 1/2] drm/i915/tc: demote a kernel-doc comment to a regular comment

On Wed, 05 Apr 2023, "Govindapillai, Vinod"  
wrote:
> On Wed, 2023-04-05 at 13:41 +0300, Jani Nikula wrote:
>> There's not much point in a static work function having a kernel-doc
>> comment. Just clean it up and make it a regular comment.
>>
>> This fixes the kernel-doc warnings:
>>
>> drivers/gpu/drm/i915/display/intel_tc.c:1370: warning: Function
>> parameter or member 'work' not described in
>> 'intel_tc_port_disconnect_phy_work'
>>
>> drivers/gpu/drm/i915/display/intel_tc.c:1370: warning: Excess function
>> parameter 'dig_port' description in 'intel_tc_port_disconnect_phy_work'
>>
>> Signed-off-by: Jani Nikula 
>> ---
>
> Thanks.
>
> Reviewed-by: Vinod Govindapillai 

Thanks for the review, pushed to drm-intel-next.

BR,
Jani.

>
>
>>  drivers/gpu/drm/i915/display/intel_tc.c | 5 +
>>  1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
>> b/drivers/gpu/drm/i915/display/intel_tc.c
>> index 2bb02d4e6859..3b60995e9dfb 100644
>> --- a/drivers/gpu/drm/i915/display/intel_tc.c
>> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
>> @@ -1358,10 +1358,7 @@ void intel_tc_port_lock(struct intel_digital_port 
>> *dig_port)
>> __intel_tc_port_lock(to_tc_port(dig_port), 1);
>>  }
>>
>> -/**
>> - * intel_tc_port_disconnect_phy_work: disconnect TypeC PHY from display port
>> - * @dig_port: digital port
>> - *
>> +/*
>>   * Disconnect the given digital port from its TypeC PHY (handing back the
>>   * control of the PHY to the TypeC subsystem). This will happen in a delayed
>>   * manner after each aux transactions and modeset disables.
>

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PULL] drm-intel-gt-next

On Thu, Apr 06, 2023 at 03:34:04PM +0300, Jani Nikula wrote:
> On Thu, 06 Apr 2023, Maarten Lankhorst  
> wrote:
> > Hi Dave, Daniel,
> > Pull request to avoid backmerges. ;)
> > Cheers,
> > ~Maarten
> 
> Not using dim for this? Is the subject line copy-pasted from another
> pull request? :)

dim did at least manage to eat it all correctly I think :-)

Pulled, thanks

> 
> BR,
> Jani.
> 
> >
> > drm-misc-next-2023-04-06:
> > drm-misc-next for v6.4-rc1:
> >
> > UAPI Changes:
> >
> > Cross-subsystem Changes:
> > - Document port and rotation dt bindings better.
> > - For panel timing DT bindings, document that vsync and hsync are
> >first, rather than last in image.
> > - Fix video/aperture typos.
> >
> > Core Changes:
> > - Reject prime DMA-Buf attachment if get_sg_table is missing.
> >(For self-importing dma-buf only.)
> > - Add prime import/export to vram-helper.
> > - Fix oops in drm/vblank when init is not called.
> > - Fixup xres/yres_virtual and other fixes in fb helper.
> > - Improve SCDC debugs.
> > - Skip setting deadline on modesets.
> > - Assorted TTM fixes.
> >
> > Driver Changes:
> > - Add lima usage stats.
> > - Assorted fixes to bridge/lt8192b, tc358767, ivpu,
> >bridge/ti-sn65dsi83, ps8640.
> > - Use pci aperture helpers in drm/ast lynxfb, radeonfb.
> > - Revert some lima patches, as they required a commit that has been
> >reverted upstream.
> > - Add AUO NE135FBM-N41 v8.1 eDP panel.
> > - Add QAIC accel driver.
> > The following changes since commit 7d690f936e9bc9fbd6394fb3d4ad181af03ee393:
> >
> >drm/panfrost: Add basic support for speed binning (2023-03-31 11:44:11 
> > +0200)
> >
> > are available in the Git repository at:
> >
> >git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2023-04-06
> >
> > for you to fetch changes up to e44f18c6ff8beef7b2b10592287f0a9766376d9b:
> >
> >drm/ttm: Make the call to ttm_tt_populate() interruptible when faulting 
> > (2023-04-06 10:01:42 +0200)
> >
> > 
> > drm-misc-next for v6.4-rc1:
> >
> > UAPI Changes:
> >
> > Cross-subsystem Changes:
> > - Document port and rotation dt bindings better.
> > - For panel timing DT bindings, document that vsync and hsync are
> >first, rather than last in image.
> > - Fix video/aperture typos.
> >
> > Core Changes:
> > - Reject prime DMA-Buf attachment if get_sg_table is missing.
> >(For self-importing dma-buf only.)
> > - Add prime import/export to vram-helper.
> > - Fix oops in drm/vblank when init is not called.
> > - Fixup xres/yres_virtual and other fixes in fb helper.
> > - Improve SCDC debugs.
> > - Skip setting deadline on modesets.
> > - Assorted TTM fixes.
> >
> > Driver Changes:
> > - Add lima usage stats.
> > - Assorted fixes to bridge/lt8192b, tc358767, ivpu,
> >bridge/ti-sn65dsi83, ps8640.
> > - Use pci aperture helpers in drm/ast lynxfb, radeonfb.
> > - Revert some lima patches, as they required a commit that has been
> >reverted upstream.
> > - Add AUO NE135FBM-N41 v8.1 eDP panel.
> > - Add QAIC accel driver.
> >
> > 
> > Alexander Stein (2):
> >drm/bridge: ti-sn65dsi83: use dev_err_probe if host attach failed
> >drm/bridge: ti-sn65dsi86: Allow GPIO operations to sleep
> >
> > AngeloGioacchino Del Regno (1):
> >drm/panel-edp: Add AUO NE135FBM-N41 v8.1 panel entry
> >
> > Daniel Vetter (7):
> >drm/ast: Use drm_aperture_remove_conflicting_pci_framebuffers
> >staging/lynxfb: Use pci aperture helper
> >fbdev/radeon: use pci aperture helpers
> >drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
> >drm/fb-helper: drop redundant pixclock check from 
> > drm_fb_helper_set_par()
> >drm/fb-helper: fix input validation gaps in check_var
> >drm/atomic-helper: Don't set deadline for modesets
> >
> > Erico Nunes (3):
> >drm/lima: add usage counting method to ctx_mgr
> >drm/lima: allocate unique id per drm_file
> >drm/lima: add show_fdinfo for drm usage stats
> >
> > Francesco Dolcini (1):
> >drm/bridge: lt8912b: Fix DSI Video Mode
> >
> > Harshit Mogalapalli (1):
> >drm/lima/lima_drv: Add missing unwind goto in lima_pdev_probe()
> >
> > Jeffrey Hugo (7):
> >accel/qaic: Add documentation for AIC100 accelerator driver
> >accel/qaic: Add uapi and core driver file
> >accel/qaic: Add MHI controller
> >accel/qaic: Add control path
> >accel/qaic: Add datapath
> >accel/qaic: Add qaic driver to the build system
> >MAINTAINERS: Add entry for QAIC driver
> >
> > Karol Wachowski (1):
> >accel/ivpu: Remove D3hot delay for Meteorlake
> >
> > Krzysztof Kozlowski (5):
> >dt-bindings: display: sitronix,st7789v: document dc-gpios
> >dt-bindings: display: xinpeng,xpp055c272: document port
> >dt-bindings: display: feiyang,fy07024di26a30d: docum

[Intel-gfx] [PATCH v3 1/8] drm/i915/mtl: Initial DDI port setup

From: Clint Taylor 

Initialization sequences and C10 phy are in place to be able to enable
the first 2 ports of MTL. The other ports use C20 phy that still need
to be properly added. Enable the first ports for now, keeping a TODO
comment about the others.

Cc: Radhakrishna Sripada 
Reviewed-by: Lucas De Marchi 
Signed-off-by: Clint Taylor 
---
 drivers/gpu/drm/i915/display/intel_display.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 010ee793e1ff..fa7807d04ac2 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7729,7 +7729,11 @@ static void intel_setup_outputs(struct drm_i915_private 
*dev_priv)
if (!HAS_DISPLAY(dev_priv))
return;
 
-   if (IS_DG2(dev_priv)) {
+   if (IS_METEORLAKE(dev_priv)) {
+   /* TODO: initialize TC ports as well */
+   intel_ddi_init(dev_priv, PORT_A);
+   intel_ddi_init(dev_priv, PORT_B);
+   } else if (IS_DG2(dev_priv)) {
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
intel_ddi_init(dev_priv, PORT_C);
-- 
2.34.1

[Intel-gfx] [PATCH v3 0/8] drm/i915/mtl: Add Support for C10 phy

Phy programming support for C10 phy. This is the first part of
the series that adds support for PICA phy. Later stage the support
for C20 phy is added. This series gets the eDP going.

v2: Register refinitions in intel_cx0_phy_regs.h file (Jani)
v3: Add waits for between message bus writes (Imre)
General cleanups and macro definitions (Imre)

Signed-off-by: Mika Kahola 

Ankit Nautiyal (1):
  drm/i915/display/mtl: Fill port width in
DDI_BUF_/TRANS_DDI_FUNC_/PORT_BUF_CTL for HDMI

Clint Taylor (1):
  drm/i915/mtl: Initial DDI port setup

José Roberto de Souza (1):
  drm/i915/mtl/display: Implement DisplayPort sequences

Mika Kahola (4):
  drm/i915/mtl: Add DP rates
  drm/i915/mtl: Create separate reg file for PICA registers
  drm/i915/mtl: Add vswing programming for C10 phys
  drm/i915/mtl: MTL PICA hotplug detection

Radhakrishna Sripada (1):
  drm/i915/mtl: Add Support for C10 PHY message bus and pll programming

 drivers/gpu/drm/i915/Makefile |1 +
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 1259 +
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  |   47 +
 .../gpu/drm/i915/display/intel_cx0_phy_regs.h |  190 +++
 drivers/gpu/drm/i915/display/intel_ddi.c  |  447 +-
 .../drm/i915/display/intel_ddi_buf_trans.c|   31 +-
 .../drm/i915/display/intel_ddi_buf_trans.h|6 +
 drivers/gpu/drm/i915/display/intel_display.c  |6 +-
 .../i915/display/intel_display_power_map.c|1 +
 .../drm/i915/display/intel_display_types.h|   13 +
 drivers/gpu/drm/i915/display/intel_dp.c   |   15 +-
 drivers/gpu/drm/i915/display/intel_dpll.c |   26 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c |2 +-
 .../drm/i915/display/intel_modeset_verify.c   |2 +
 drivers/gpu/drm/i915/i915_irq.c   |  249 +++-
 drivers/gpu/drm/i915/i915_reg.h   |   43 +-
 drivers/gpu/drm/i915/i915_reg_defs.h  |   57 +
 17 files changed, 2361 insertions(+), 34 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.h
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h

-- 
2.34.1

[Intel-gfx] [PATCH v3 5/8] drm/i915/mtl: Add vswing programming for C10 phys

C10 phys uses direct mapping internally for voltage and pre-emphasis levels.
Program the levels directly to the fields in the VDR Registers.

Bspec: 65449

v2: From table "C10: Tx EQ settings for DP 1.4x" it shows level 1
and preemphasis 1 instead of two times of level 1 preemphasis 0.
Fix this in the driver code as well.
v3: VSwing update (Clint)

Cc: Imre Deak 
Cc: Uma Shankar 
Signed-off-by: Clint Taylor 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 61 +--
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  |  3 +
 .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 14 +
 drivers/gpu/drm/i915/display/intel_ddi.c  |  4 +-
 .../drm/i915/display/intel_ddi_buf_trans.c| 31 +-
 .../drm/i915/display/intel_ddi_buf_trans.h|  6 ++
 .../i915/display/intel_display_power_map.c|  1 +
 7 files changed, 114 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index f3e13edd27ba..81910d55bb63 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -6,6 +6,8 @@
 #include "i915_reg.h"
 #include "intel_cx0_phy.h"
 #include "intel_cx0_phy_regs.h"
+#include "intel_ddi.h"
+#include "intel_ddi_buf_trans.h"
 #include "intel_de.h"
 #include "intel_display_types.h"
 #include "intel_dp.h"
@@ -292,6 +294,57 @@ static void intel_cx0_rmw(struct drm_i915_private *i915, 
enum port port,
__intel_cx0_rmw(i915, port, lane, addr, clear, set, committed);
 }
 
+void intel_cx0_phy_set_signal_levels(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   const struct intel_ddi_buf_trans *trans;
+   intel_wakeref_t wakeref;
+   int n_entries, ln;
+
+   wakeref = intel_cx0_phy_transaction_begin(encoder);
+
+   trans = encoder->get_buf_trans(encoder, crtc_state, &n_entries);
+   if (drm_WARN_ON_ONCE(&i915->drm, !trans))
+   return;
+
+   intel_cx0_rmw(i915, encoder->port, INTEL_CX0_BOTH_LANES, 
PHY_C10_VDR_CONTROL(1),
+ 0, C10_VDR_CTRL_MSGBUS_ACCESS,
+ MB_WRITE_COMMITTED);
+
+   for (ln = 0; ln < 4; ln++) {
+   int level = intel_ddi_level(encoder, crtc_state, ln);
+   int lane, tx;
+
+   lane = ln / 2;
+   tx = ln % 2 + 1;
+
+   intel_cx0_rmw(i915, encoder->port, lane + 1, 
PHY_CX0_VDR_OVRD_CONTROL(lane, tx, 0),
+   C10_PHY_OVRD_LEVEL_MASK,
+   
C10_PHY_OVRD_LEVEL(trans->entries[level].snps.pre_cursor),
+   MB_WRITE_COMMITTED);
+   intel_cx0_rmw(i915, encoder->port, lane + 1, 
PHY_CX0_VDR_OVRD_CONTROL(lane, tx, 1),
+   C10_PHY_OVRD_LEVEL_MASK,
+   
C10_PHY_OVRD_LEVEL(trans->entries[level].snps.vswing),
+   MB_WRITE_COMMITTED);
+   intel_cx0_rmw(i915, encoder->port, lane + 1, 
PHY_CX0_VDR_OVRD_CONTROL(lane, tx, 2),
+   C10_PHY_OVRD_LEVEL_MASK,
+   
C10_PHY_OVRD_LEVEL(trans->entries[level].snps.post_cursor),
+   MB_WRITE_COMMITTED);
+   }
+
+   /* Write Override enables in 0xD71 */
+   intel_cx0_rmw(i915, encoder->port, INTEL_CX0_BOTH_LANES, 
PHY_C10_VDR_OVRD,
+   0, PHY_C10_VDR_OVRD_TX1 | PHY_C10_VDR_OVRD_TX2,
+   MB_WRITE_COMMITTED);
+
+   intel_cx0_rmw(i915, encoder->port, INTEL_CX0_BOTH_LANES, 
PHY_C10_VDR_CONTROL(1),
+ 0, C10_VDR_CTRL_UPDATE_CFG,
+ MB_WRITE_COMMITTED);
+
+   intel_cx0_phy_transaction_end(encoder, wakeref);
+}
+
 /*
  * Basic DP link rates with 38.4 MHz reference clock.
  * Note: The tables below are with SSC. In non-ssc
@@ -765,10 +818,9 @@ static void intel_program_port_clock_ctl(struct 
intel_encoder *encoder,
val |= crtc_state->cx0pll_state.ssc_enabled ? XELPDP_SSC_ENABLE_PLLB : 
0;
 
intel_de_rmw(i915, XELPDP_PORT_CLOCK_CTL(encoder->port),
-XELPDP_LANE1_PHY_CLOCK_SELECT |
-XELPDP_FORWARD_CLOCK_UNGATE |
+XELPDP_LANE1_PHY_CLOCK_SELECT | 
XELPDP_FORWARD_CLOCK_UNGATE |
 XELPDP_DDI_CLOCK_SELECT_MASK |
-XELPDP_SSC_ENABLE_PLLB, val);
+XELPDP_SSC_ENABLE_PLLA | XELPDP_SSC_ENABLE_PLLB, val);
 }
 
 static u32 intel_cx0_get_powerdown_update(u8 lane_mask)
@@ -1143,7 +1195,8 @@ static void intel_c10pll_disable(struct intel_encoder 
*encoder)
 
/* 7. Program PORT_CLOCK_CTL register to disable and gate clocks. */
intel_de_rmw(i915, XELPDP_PORT_CLOCK_CTL(encoder->port),
-

[Intel-gfx] [PATCH v3 4/8] drm/i915/mtl: Add Support for C10 PHY message bus and pll programming

From: Radhakrishna Sripada 

XELPDP has C10 and C20 phys from Synopsys to drive displays. Each phy
has a dedicated PIPE 5.2 Message bus for configuration. This message
bus is used to configure the phy internal registers.

XELPDP has C10 phys to drive output to the EDP and the native output
from the display engine. Add structures, programming hardware state
readout logic. Port clock calculations are similar to DG2. Use the DG2
formulae to calculate the port clock but use the relevant pll signals.
Note: PHY lane 0 is always used for PLL programming.

Add sequences for C10 phy enable/disable phy lane reset,
powerdown change sequence and phy lane programming.

Bspec: 64539, 64568, 64599, 65100, 65101, 65450, 65451, 67610, 67636

v2: Squash patches related to C10 phy message bus and pll
programming support (Jani)
Move register definitions to a new file i.e. intel_cx0_reg_defs.h (Jani)
Move macro definitions (Jani)
DP rates as separate patch (Jani)
Spin out xelpdp register definitions into a separate file (Jani)
Replace macro to select registers based on phy lane with
function calls (Jani)
Fix styling issues (Jani)
Call XELPDP_PORT_P2M_MSGBUS_STATUS() with port instead of phy (Lucas)
v3: Move clear request flag into try-loop
v4: On PHY idle change drm_err_once() as drm_dbg_kms() (Jani)
use __intel_de_wait_for_register() instead of __intel_wait_for_register
and uncomment intel_uncore.h (Jani)
Add DP-alt support for PHY lane programming (Khaled)
v4: Add tx and cmn on c10mpllb_state (Imre)
Add missing waits for pending transactions between two message bus
writes (Imre)
General cleanups and simplifications (Imre)

Cc: Mika Kahola 
Cc: Imre Deak 
Cc: Uma Shankar 
Cc: Gustavo Sousa 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/Makefile |1 +
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 1206 +
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  |   44 +
 .../gpu/drm/i915/display/intel_cx0_phy_regs.h |   53 +-
 drivers/gpu/drm/i915/display/intel_ddi.c  |   22 +-
 .../drm/i915/display/intel_display_types.h|   13 +
 drivers/gpu/drm/i915/display/intel_dpll.c |   26 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c |2 +-
 .../drm/i915/display/intel_modeset_verify.c   |2 +
 drivers/gpu/drm/i915/i915_reg.h   |5 +
 drivers/gpu/drm/i915/i915_reg_defs.h  |   57 +
 11 files changed, 1419 insertions(+), 12 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 97b0d4ae221a..4ee3b5850dd0 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -298,6 +298,7 @@ i915-y += \
display/icl_dsi.o \
display/intel_backlight.o \
display/intel_crt.o \
+   display/intel_cx0_phy.o \
display/intel_ddi.o \
display/intel_ddi_buf_trans.o \
display/intel_display_trace.o \
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
new file mode 100644
index ..f3e13edd27ba
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -0,0 +1,1206 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include "i915_reg.h"
+#include "intel_cx0_phy.h"
+#include "intel_cx0_phy_regs.h"
+#include "intel_de.h"
+#include "intel_display_types.h"
+#include "intel_dp.h"
+#include "intel_panel.h"
+#include "intel_psr.h"
+#include "intel_tc.h"
+
+#define MB_WRITE_COMMITTED  true
+#define MB_WRITE_UNCOMMITTEDfalse
+
+bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy)
+{
+   if (IS_METEORLAKE(dev_priv) && (phy < PHY_C))
+   return true;
+
+   return false;
+}
+
+static int lane_mask_to_lane(u8 lane_mask)
+{
+   if (WARN_ON((lane_mask & ~INTEL_CX0_BOTH_LANES) ||
+   hweight8(lane_mask) != 1))
+   return 0;
+
+   return ilog2(lane_mask);
+}
+
+static void
+assert_dc_off(struct drm_i915_private *i915)
+{
+   bool enabled;
+
+   enabled = intel_display_power_is_enabled(i915, POWER_DOMAIN_DC_OFF);
+   drm_WARN_ON(&i915->drm, !enabled);
+}
+
+/*
+ * Prepare HW for CX0 phy transactions.
+ *
+ * It is required that PSR and DC5/6 are disabled before any CX0 message
+ * bus transaction is executed.
+ */
+static intel_wakeref_t intel_cx0_phy_transaction_begin(struct intel_encoder 
*encoder)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+   intel_psr_pause(intel_dp);
+   return intel_display_power_get(i915, POWER_DOMAIN_DC_OFF);
+}
+
+static void intel_cx0_phy_transaction_end(struct intel_encoder *encoder, 
intel_wakeref_t wakeref)
+{
+   struct drm_i915_private *i91

[Intel-gfx] [PATCH v3 2/8] drm/i915/mtl: Add DP rates

Add DP rates for Meteorlake.

Reviewed-by: Vinod Govindapillai 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index f0bace9d98a1..3367ae98c2bd 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -421,6 +421,11 @@ static int ehl_max_source_rate(struct intel_dp *intel_dp)
return 81;
 }
 
+static int mtl_max_source_rate(struct intel_dp *intel_dp)
+{
+   return intel_dp_is_edp(intel_dp) ? 675000 : 81;
+}
+
 static int vbt_max_link_rate(struct intel_dp *intel_dp)
 {
struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
@@ -445,6 +450,10 @@ static void
 intel_dp_set_source_rates(struct intel_dp *intel_dp)
 {
/* The values must be in increasing order */
+   static const int mtl_rates[] = {
+   162000, 216000, 243000, 27, 324000, 432000, 54, 675000,
+   81,
+   };
static const int icl_rates[] = {
162000, 216000, 27, 324000, 432000, 54, 648000, 81,
100, 135,
@@ -470,7 +479,11 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
drm_WARN_ON(&dev_priv->drm,
intel_dp->source_rates || intel_dp->num_source_rates);
 
-   if (DISPLAY_VER(dev_priv) >= 11) {
+   if (DISPLAY_VER(dev_priv) >= 14) {
+   source_rates = mtl_rates;
+   size = ARRAY_SIZE(mtl_rates);
+   max_rate = mtl_max_source_rate(intel_dp);
+   } else if (DISPLAY_VER(dev_priv) >= 11) {
source_rates = icl_rates;
size = ARRAY_SIZE(icl_rates);
if (IS_DG2(dev_priv))
-- 
2.34.1

[Intel-gfx] [PATCH v3 3/8] drm/i915/mtl: Create separate reg file for PICA registers

Create a separate file to store registers for PICA chips
C10 and C20.

v2: Rename file (Jani)
v3: Use _PICK_EVEN_2RANGES() macro (Lucas)
Coding style fixed (Lucas)
v4: Redefine macros (Imre)

Reviewed-by: Vinod Govindapillai  (v3)
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Mika Kahola 
---
 .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 133 ++
 1 file changed, 133 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h 
b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
new file mode 100644
index ..27723c1a93d9
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
@@ -0,0 +1,133 @@
+/* SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __INTEL_CX0_PHY_REGS_H__
+#define __INTEL_CX0_PHY_REGS_H__
+
+#include "i915_reg_defs.h"
+
+#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A  0x64040
+#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B  0x64140
+#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1  0x16F240
+#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2  0x16F440
+#define XELPDP_PORT_M2P_MSGBUS_CTL(port, lane) 
_MMIO(_PICK_EVEN_2RANGES(port, PORT_TC1, \
+   
 _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A, \
+   
 _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B, \
+   
 _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1, \
+   
 _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2) + (lane) * 4)
+#define   XELPDP_PORT_M2P_TRANSACTION_PENDING  REG_BIT(31)
+#define   XELPDP_PORT_M2P_COMMAND_TYPE_MASKREG_GENMASK(30, 27)
+#define   XELPDP_PORT_M2P_COMMAND_WRITE_UNCOMMITTED
REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x1)
+#define   XELPDP_PORT_M2P_COMMAND_WRITE_COMMITTED  
REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x2)
+#define   XELPDP_PORT_M2P_COMMAND_READ 
REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x3)
+#define   XELPDP_PORT_M2P_DATA_MASKREG_GENMASK(23, 16)
+#define   XELPDP_PORT_M2P_DATA(val)
REG_FIELD_PREP(XELPDP_PORT_M2P_DATA_MASK, val)
+#define   XELPDP_PORT_M2P_TRANSACTION_RESETREG_BIT(15)
+#define   XELPDP_PORT_M2P_ADDRESS_MASK REG_GENMASK(11, 0)
+#define   XELPDP_PORT_M2P_ADDRESS(val) 
REG_FIELD_PREP(XELPDP_PORT_M2P_ADDRESS_MASK, val)
+#define XELPDP_PORT_P2M_MSGBUS_STATUS(port, lane)  
_MMIO(_PICK_EVEN_2RANGES(port, PORT_TC1, \
+   
 _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A, \
+   
 _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B, \
+   
 _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1, \
+   
 _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2) + (lane) * 4 + 8)
+#define   XELPDP_PORT_P2M_RESPONSE_READY   REG_BIT(31)
+#define   XELPDP_PORT_P2M_COMMAND_TYPE_MASKREG_GENMASK(30, 27)
+#define   XELPDP_PORT_P2M_COMMAND_READ_ACK 0x4
+#define   XELPDP_PORT_P2M_COMMAND_WRITE_ACK0x5
+#define   XELPDP_PORT_P2M_DATA_MASKREG_GENMASK(23, 16)
+#define   XELPDP_PORT_P2M_DATA(val)
REG_FIELD_PREP(XELPDP_PORT_P2M_DATA_MASK, val)
+#define   XELPDP_PORT_P2M_ERROR_SETREG_BIT(15)
+
+#define XELPDP_MSGBUS_TIMEOUT_SLOW 1
+#define XELPDP_MSGBUS_TIMEOUT_FAST_US  2
+#define XELPDP_PCLK_PLL_ENABLE_TIMEOUT_US  3200
+#define XELPDP_PCLK_PLL_DISABLE_TIMEOUT_US 20
+#define XELPDP_PORT_BUF_SOC_READY_TIMEOUT_US   100
+#define XELPDP_PORT_RESET_START_TIMEOUT_US 5
+#define XELPDP_PORT_POWERDOWN_UPDATE_TIMEOUT_US100
+#define XELPDP_PORT_RESET_END_TIMEOUT  15
+#define XELPDP_REFCLK_ENABLE_TIMEOUT_US1
+
+#define _XELPDP_PORT_BUF_CTL1_LN0_A0x64004
+#define _XELPDP_PORT_BUF_CTL1_LN0_B0x64104
+#define _XELPDP_PORT_BUF_CTL1_LN0_USBC10x16F200
+#define _XELPDP_PORT_BUF_CTL1_LN0_USBC20x16F400
+#define XELPDP_PORT_BUF_CTL1(port) 
_MMIO(_PICK_EVEN_2RANGES(port, PORT_TC1, \
+   
 _XELPDP_PORT_BUF_CTL1_LN0_A, \
+   
 _XELPDP_PORT_BUF_CTL1_LN0_B, \
+

[Intel-gfx] [PATCH v3 6/8] drm/i915/mtl: MTL PICA hotplug detection

PICA is used for DP alt mode and TBT modes. Hotplug interruption is routed
from PICA chip to south display engine and from there to north display
engine. This patch adds functionality to enable hotplug detection for
all Type-C ports (4 ports available).

Differently from HPD in south display, PICA provides a dedicated HPD
control register for each supported port, so we loop over ports
ourselves instead of using intel_hpd_hotplug_enables() or
intel_get_hpd_pins().

BSpec: 49305, 55726, 65107, 65300

Signed-off-by: Madhumitha Tolakanahalli Pradeep 

Signed-off-by: Gustavo Sousa 
Signed-off-by: Imre Deak 
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/i915_irq.c | 249 +++-
 drivers/gpu/drm/i915/i915_reg.h |  31 +++-
 2 files changed, 273 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d24bdea65a3d..54ca5b65493f 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -162,6 +162,13 @@ static const u32 hpd_gen11[HPD_NUM_PINS] = {
[HPD_PORT_TC6] = GEN11_TC_HOTPLUG(HPD_PORT_TC6) | 
GEN11_TBT_HOTPLUG(HPD_PORT_TC6),
 };
 
+static const u32 hpd_xelpdp[HPD_NUM_PINS] = {
+   [HPD_PORT_TC1] = XELPDP_TBT_HOTPLUG(HPD_PORT_TC1) | 
XELPDP_DP_ALT_HOTPLUG(HPD_PORT_TC1),
+   [HPD_PORT_TC2] = XELPDP_TBT_HOTPLUG(HPD_PORT_TC2) | 
XELPDP_DP_ALT_HOTPLUG(HPD_PORT_TC2),
+   [HPD_PORT_TC3] = XELPDP_TBT_HOTPLUG(HPD_PORT_TC3) | 
XELPDP_DP_ALT_HOTPLUG(HPD_PORT_TC3),
+   [HPD_PORT_TC4] = XELPDP_TBT_HOTPLUG(HPD_PORT_TC4) | 
XELPDP_DP_ALT_HOTPLUG(HPD_PORT_TC4),
+};
+
 static const u32 hpd_icp[HPD_NUM_PINS] = {
[HPD_PORT_A] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_A),
[HPD_PORT_B] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_B),
@@ -182,6 +189,16 @@ static const u32 hpd_sde_dg1[HPD_NUM_PINS] = {
[HPD_PORT_TC1] = SDE_TC_HOTPLUG_DG2(HPD_PORT_TC1),
 };
 
+static const u32 hpd_mtp[HPD_NUM_PINS] = {
+   [HPD_PORT_A] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_A),
+   [HPD_PORT_B] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_B),
+   [HPD_PORT_TC1] = SDE_TC_HOTPLUG_ICP(HPD_PORT_TC1),
+   [HPD_PORT_TC2] = SDE_TC_HOTPLUG_ICP(HPD_PORT_TC2),
+   [HPD_PORT_TC3] = SDE_TC_HOTPLUG_ICP(HPD_PORT_TC3),
+   [HPD_PORT_TC4] = SDE_TC_HOTPLUG_ICP(HPD_PORT_TC4),
+};
+
+
 static void intel_hpd_init_pins(struct drm_i915_private *dev_priv)
 {
struct intel_hotplug *hpd = &dev_priv->display.hotplug;
@@ -195,7 +212,9 @@ static void intel_hpd_init_pins(struct drm_i915_private 
*dev_priv)
return;
}
 
-   if (DISPLAY_VER(dev_priv) >= 11)
+   if (DISPLAY_VER(dev_priv) >= 14)
+   hpd->hpd = hpd_xelpdp;
+   else if (DISPLAY_VER(dev_priv) >= 11)
hpd->hpd = hpd_gen11;
else if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv))
hpd->hpd = hpd_bxt;
@@ -214,6 +233,8 @@ static void intel_hpd_init_pins(struct drm_i915_private 
*dev_priv)
 
if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
hpd->pch_hpd = hpd_sde_dg1;
+   else if (INTEL_PCH_TYPE(dev_priv) >= PCH_MTP)
+   hpd->pch_hpd = hpd_mtp;
else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
hpd->pch_hpd = hpd_icp;
else if (HAS_PCH_CNP(dev_priv) || HAS_PCH_SPT(dev_priv))
@@ -1559,6 +1580,44 @@ static void cpt_irq_handler(struct drm_i915_private 
*dev_priv, u32 pch_iir)
cpt_serr_int_handler(dev_priv);
 }
 
+static void xelpdp_pica_irq_handler(struct drm_i915_private *dev_priv, u32 iir)
+{
+   enum hpd_pin pin;
+   u32 hotplug_trigger = iir & (XELPDP_DP_ALT_HOTPLUG_MASK | 
XELPDP_TBT_HOTPLUG_MASK);
+   u32 trigger_aux = iir & XELPDP_AUX_TC_MASK;
+   u32 pin_mask = 0, long_mask = 0;
+
+   for (pin = HPD_PORT_TC1; pin <= HPD_PORT_TC4; pin++) {
+   u32 val;
+
+   if (!(dev_priv->display.hotplug.hpd[pin] & hotplug_trigger))
+   continue;
+
+   pin_mask |= BIT(pin);
+
+   val = intel_uncore_read(&dev_priv->uncore, 
XELPDP_PORT_HOTPLUG_CTL(pin));
+   intel_uncore_write(&dev_priv->uncore, 
XELPDP_PORT_HOTPLUG_CTL(pin), val);
+
+   if (val & (XELPDP_DP_ALT_HPD_LONG_DETECT | 
XELPDP_TBT_HPD_LONG_DETECT))
+   long_mask |= BIT(pin);
+   }
+
+   if (pin_mask) {
+   drm_dbg(&dev_priv->drm,
+   "pica hotplug event received, stat 0x%08x, pins 0x%08x, 
long 0x%08x\n",
+   hotplug_trigger, pin_mask, long_mask);
+
+   intel_hpd_irq_handler(dev_priv, pin_mask, long_mask);
+   }
+
+   if (trigger_aux)
+   dp_aux_irq_handler(dev_priv);
+
+   if (!pin_mask && !trigger_aux)
+   drm_err(&dev_priv->drm,
+   "Unexpected DE HPD/AUX interrupt 0x%08x\n", iir);
+}
+
 static void icp_irq_handler(struct drm_i915_private *dev_priv, u32 pch_iir)
 {
u32 ddi_hotplug_trigger = pch_iir & SDE_

[Intel-gfx] [PATCH v3 7/8] drm/i915/display/mtl: Fill port width in DDI_BUF_/TRANS_DDI_FUNC_/PORT_BUF_CTL for HDMI

From: Ankit Nautiyal 

MTL requires the PORT_CTL_WIDTH, TRANS_DDI_FUNC_CTL and DDI_BUF_CTL
to be filled with 4 lanes for TMDS mode.
This patch enables D2D link and fills PORT_WIDTH in appropriate
registers.

v2:
  - Added fixes from Clint's Add HDMI implementation changes.
  - Modified commit message.
v3:
  - Use TRANS_DDI_PORT_WIDTH() instead of DDI_PORT_WIDTH() for the value
of TRANS_DDI_FUNC_CTL_*. (Gustavo)

Signed-off-by: Ankit Nautiyal 
Signed-off-by: Taylor, Clinton A 
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 48 +---
 drivers/gpu/drm/i915/i915_reg.h  |  2 +
 2 files changed, 44 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index e97d7627d9d1..20b0844b8240 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -516,6 +516,8 @@ intel_ddi_transcoder_func_reg_val_get(struct intel_encoder 
*encoder,
temp |= TRANS_DDI_HDMI_SCRAMBLING;
if (crtc_state->hdmi_high_tmds_clock_ratio)
temp |= TRANS_DDI_HIGH_TMDS_CHAR_RATE;
+   if (DISPLAY_VER(dev_priv) >= 14)
+   temp |= TRANS_DDI_PORT_WIDTH(crtc_state->lane_count);
} else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_ANALOG)) {
temp |= TRANS_DDI_MODE_SELECT_FDI_OR_128B132B;
temp |= (crtc_state->fdi_lanes - 1) << 1;
@@ -2891,6 +2893,10 @@ static void intel_enable_ddi_hdmi(struct 
intel_atomic_state *state,
if (has_buf_trans_select(dev_priv))
hsw_prepare_hdmi_ddi_buffers(encoder, crtc_state);
 
+   /* e. Enable D2D Link for C10/C20 Phy */
+   if (DISPLAY_VER(dev_priv) >= 14)
+   mtl_ddi_enable_d2d(encoder);
+
encoder->set_signal_levels(encoder, crtc_state);
 
/* Display WA #1143: skl,kbl,cfl */
@@ -2936,13 +2942,39 @@ static void intel_enable_ddi_hdmi(struct 
intel_atomic_state *state,
 *
 * On ADL_P the PHY link rate and lane count must be programmed but
 * these are both 0 for HDMI.
+*
+* But MTL onwards HDMI2.1 is supported and in TMDS mode this
+* is always filled with 4 lanes, already set in the crtc_state.
+* The same is required to be filled in PORT_BUF_CTL for C10/20 Phy.
 */
-   buf_ctl = dig_port->saved_port_bits | DDI_BUF_CTL_ENABLE;
-   if (IS_ALDERLAKE_P(dev_priv) && intel_phy_is_tc(dev_priv, phy)) {
-   drm_WARN_ON(&dev_priv->drm, 
!intel_tc_port_in_legacy_mode(dig_port));
-   buf_ctl |= DDI_BUF_CTL_TC_PHY_OWNERSHIP;
+   if (DISPLAY_VER(dev_priv) >= 14) {
+   u32 ddi_buf = 0;
+   u8  lane_count = mtl_get_port_width(crtc_state->lane_count);
+   u32 port_buf = 0;
+
+   port_buf |= XELPDP_PORT_WIDTH(lane_count);
+
+   if (intel_bios_is_lane_reversal_needed(dev_priv, port))
+   port_buf |= XELPDP_PORT_REVERSAL;
+
+   intel_de_rmw(dev_priv, XELPDP_PORT_BUF_CTL1(port), 0, port_buf);
+
+   ddi_buf |= DDI_BUF_CTL_ENABLE |
+  DDI_PORT_WIDTH(lane_count);
+
+   intel_de_write(dev_priv, DDI_BUF_CTL(port),
+  dig_port->saved_port_bits | ddi_buf);
+
+   /* i. Poll for PORT_BUF_CTL Idle Status == 0, timeout after 100 
us */
+   intel_wait_ddi_buf_active(dev_priv, port);
+   } else {
+   buf_ctl = dig_port->saved_port_bits | DDI_BUF_CTL_ENABLE;
+   if (IS_ALDERLAKE_P(dev_priv) && intel_phy_is_tc(dev_priv, phy)) 
{
+   drm_WARN_ON(&dev_priv->drm, 
!intel_tc_port_in_legacy_mode(dig_port));
+   buf_ctl |= DDI_BUF_CTL_TC_PHY_OWNERSHIP;
+   }
+   intel_de_write(dev_priv, DDI_BUF_CTL(port), buf_ctl);
}
-   intel_de_write(dev_priv, DDI_BUF_CTL(port), buf_ctl);
 
intel_wait_ddi_buf_active(dev_priv, port);
 
@@ -3357,7 +3389,11 @@ static void intel_ddi_read_func_ctl(struct intel_encoder 
*encoder,
fallthrough;
case TRANS_DDI_MODE_SELECT_DVI:
pipe_config->output_types |= BIT(INTEL_OUTPUT_HDMI);
-   pipe_config->lane_count = 4;
+   if (DISPLAY_VER(dev_priv) >= 14)
+   pipe_config->lane_count =
+   ((temp & DDI_PORT_WIDTH_MASK) >> 
DDI_PORT_WIDTH_SHIFT) + 1;
+   else
+   pipe_config->lane_count = 4;
break;
case TRANS_DDI_MODE_SELECT_DP_SST:
if (encoder->type == INTEL_OUTPUT_EDP)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8d49676148f2..c4d363248bd2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5597,6 +5597,8 @@ enum skl_power_gat

[Intel-gfx] [PATCH v3 8/8] drm/i915/mtl/display: Implement DisplayPort sequences

From: José Roberto de Souza 

The differences between MTL and TGL DP sequences are big enough to
MTL have its own functions.

Also it is much easier to follow MTL sequences against spec with
its own functions.

One change worthy to mention is the move of
'intel_display_power_get(dev_priv, dig_port->ddi_io_power_domain)'.
This call is not necessary for MTL but we have _put() counter part in
intel_ddi_post_disable_dp() that needs to balanced.
We could add a display version check on it but instead here it is
moving it to intel_ddi_pre_enable_dp() so it is executed for all
platforms in a single place and this will not cause any harm in MTL
and newer platforms.

v2:
 - Fix logic to wait for buf idle.
 - Use the right register to wait for ddi active.(RK)
v3:
 - Increase wait timeout for ddi buf active (Mika)
v4:
 - Increase idle timeout for ddi buf idle (Mika)

BSpec: 65448 65505
Acked-by: Matt Roper 
Signed-off-by: Satyeshwar Singh 
Signed-off-by: Clint Taylor 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Ankit Nautiyal 
Signed-off-by: José Roberto de Souza 
Signed-off-by: Mika Kahola 
---
 .../gpu/drm/i915/display/intel_cx0_phy_regs.h |   8 +
 drivers/gpu/drm/i915/display/intel_ddi.c  | 375 +-
 drivers/gpu/drm/i915/i915_reg.h   |   5 +
 3 files changed, 373 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h 
b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
index a72f79ea5e6c..e23f921a5168 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
@@ -59,8 +59,16 @@

 _XELPDP_PORT_BUF_CTL1_LN0_B, \

 _XELPDP_PORT_BUF_CTL1_LN0_USBC1, \

 _XELPDP_PORT_BUF_CTL1_LN0_USBC2))
+#define   XELPDP_PORT_BUF_D2D_LINK_ENABLE  REG_BIT(29)
+#define   XELPDP_PORT_BUF_D2D_LINK_STATE   REG_BIT(28)
 #define   XELPDP_PORT_BUF_SOC_PHY_READYREG_BIT(24)
+#define   XELPDP_PORT_BUF_PORT_DATA_WIDTH_MASK REG_GENMASK(19, 18)
+#define   XELPDP_PORT_BUF_PORT_DATA_10BIT  
REG_FIELD_PREP(XELPDP_PORT_BUF_PORT_DATA_WIDTH_MASK, 0)
+#define   XELPDP_PORT_BUF_PORT_DATA_20BIT  
REG_FIELD_PREP(XELPDP_PORT_BUF_PORT_DATA_WIDTH_MASK, 1)
+#define   XELPDP_PORT_BUF_PORT_DATA_40BIT  
REG_FIELD_PREP(XELPDP_PORT_BUF_PORT_DATA_WIDTH_MASK, 2)
 #define   XELPDP_PORT_REVERSAL REG_BIT(16)
+#define   XELPDP_PORT_BUF_IO_SELECTION REG_BIT(11)
+#define   XELPDP_PORT_BUF_PHY_IDLE REG_BIT(7)
 #define   XELPDP_TC_PHY_OWNERSHIP  REG_BIT(6)
 #define   XELPDP_TCSS_POWER_REQUESTREG_BIT(5)
 #define   XELPDP_TCSS_POWER_STATE  REG_BIT(4)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 20b0844b8240..c3178cac3dee 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -40,6 +40,7 @@
 #include "intel_connector.h"
 #include "intel_crtc.h"
 #include "intel_cx0_phy.h"
+#include "intel_cx0_phy_regs.h"
 #include "intel_ddi.h"
 #include "intel_ddi_buf_trans.h"
 #include "intel_de.h"
@@ -170,6 +171,18 @@ static void hsw_prepare_hdmi_ddi_buffers(struct 
intel_encoder *encoder,
   trans->entries[level].hsw.trans2);
 }
 
+static void mtl_wait_ddi_buf_idle(struct drm_i915_private *i915, enum port 
port)
+{
+   int ret;
+
+   /* FIXME: find out why Bspec's 100us timeout is too short */
+   ret = wait_for_us((intel_de_read(i915, XELPDP_PORT_BUF_CTL1(port)) &
+  XELPDP_PORT_BUF_PHY_IDLE), 1);
+   if (ret)
+   drm_err(&i915->drm, "Timeout waiting for DDI BUF %c to get 
idle\n",
+   port_name(port));
+}
+
 void intel_wait_ddi_buf_idle(struct drm_i915_private *dev_priv,
 enum port port)
 {
@@ -197,7 +210,9 @@ static void intel_wait_ddi_buf_active(struct 
drm_i915_private *dev_priv,
return;
}
 
-   if (IS_DG2(dev_priv)) {
+   if (DISPLAY_VER(dev_priv) >= 14) {
+   timeout_us = 1;
+   } else if (IS_DG2(dev_priv)) {
timeout_us = 1200;
} else if (DISPLAY_VER(dev_priv) >= 12) {
if (intel_phy_is_tc(dev_priv, phy))
@@ -208,8 +223,12 @@ static void intel_wait_ddi_buf_active(struct 
drm_i915_private *dev_priv,
timeout_us = 500;
}
 
-   ret = _wait_for(!(intel_de_read(dev_priv, DDI_BUF_CTL(port)) &
- DDI_BUF_IS_IDLE), timeout_us, 10, 10);
+   if (DISPLAY_VER(dev_priv) >= 14)
+   ret = _wait_for(!(intel_de_read(dev_priv, 
XELPDP_PORT_BUF_C

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/atomic-helper: Don't set deadline for modesets (rev2)

== Series Details ==

Series: drm/atomic-helper: Don't set deadline for modesets (rev2)
URL   : https://patchwork.freedesktop.org/series/116140/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12974_full -> Patchwork_116140v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

Known issues


  Here are the changes found in Patchwork_116140v2_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-apl:  [PASS][1] -> [FAIL][2] ([i915#2842])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-apl6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116140v2/shard-apl6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@i915_selftest@live@gt_heartbeat:
- shard-glk:  [PASS][3] -> [DMESG-FAIL][4] ([i915#5334])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-glk3/igt@i915_selftest@live@gt_heartbeat.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116140v2/shard-glk3/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_async_flips@alternate-sync-async-flip@pipe-b-hdmi-a-1:
- shard-glk:  [PASS][5] -> [FAIL][6] ([i915#2521])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-glk4/igt@kms_async_flips@alternate-sync-async-f...@pipe-b-hdmi-a-1.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116140v2/shard-glk1/igt@kms_async_flips@alternate-sync-async-f...@pipe-b-hdmi-a-1.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl:  [PASS][7] -> [FAIL][8] ([i915#2346]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-apl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116140v2/shard-apl1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible@b-hdmi-a1:
- shard-glk:  [PASS][9] -> [FAIL][10] ([i915#2122])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-glk8/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-hdmi-a1.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116140v2/shard-glk4/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-hdmi-a1.html

  
 Possible fixes 

  * igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][11] ([i915#7742]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-rkl-4/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116140v2/shard-rkl-7/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html

  * igt@gem_exec_fair@basic-none@bcs0:
- {shard-rkl}:[FAIL][13] ([i915#2842]) -> [PASS][14] +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-rkl-4/igt@gem_exec_fair@basic-n...@bcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116140v2/shard-rkl-7/igt@gem_exec_fair@basic-n...@bcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- {shard-tglu}:   [FAIL][15] ([i915#2842]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-tglu-6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116140v2/shard-tglu-10/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@i915_pm_dc@dc6-dpms:
- {shard-tglu}:   [FAIL][17] ([i915#3989] / [i915#454]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-tglu-7/igt@i915_pm...@dc6-dpms.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116140v2/shard-tglu-9/igt@i915_pm...@dc6-dpms.html

  * igt@i915_pm_rc6_residency@rc6-idle@rcs0:
- {shard-dg1}:[FAIL][19] ([i915#3591]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-dg1-18/igt@i915_pm_rc6_residency@rc6-i...@rcs0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116140v2/shard-dg1-14/igt@i915_pm_rc6_residency@rc6-i...@rcs0.html

  * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
- {shard-rkl}:[FAIL][21] ([i915#3743]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12974/shard-rkl-7/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116140v2/shard-rkl-2/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk:  [FAIL][23] ([i915#2346]) -> [PASS][24]

[Intel-gfx] [PATCH 1/2] drm/dsc: fix drm_edp_dsc_sink_output_bpp() DPCD high byte usage

The operator precedence between << and & is wrong, leading to the high
byte being completely ignored. For example, with the 6.4 format, 32
becomes 0 and 24 becomes 8. Fix it, and remove the slightly confusing
and unnecessary DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT macro while at it.

Fixes: 0575650077ea ("drm/dp: DRM DP helper/macros to get DP sink DSC 
parameters")
Cc: Stanislav Lisovskiy 
Cc: Manasi Navare 
Cc: Anusha Srivatsa 
Cc:  # v5.0+
Signed-off-by: Jani Nikula 
---
 include/drm/display/drm_dp.h| 1 -
 include/drm/display/drm_dp_helper.h | 5 ++---
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index 358db4a9f167..89d5a700b04d 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -286,7 +286,6 @@
 
 #define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068   /* eDP 1.4 */
 # define DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK  (0x3 << 0)
-# define DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT 8
 # define DP_DSC_MAX_BPP_DELTA_VERSION_MASK  0x06
 # define DP_DSC_MAX_BPP_DELTA_AVAILABILITY  0x08
 
diff --git a/include/drm/display/drm_dp_helper.h 
b/include/drm/display/drm_dp_helper.h
index 533d3ee7fe05..86f24a759268 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -181,9 +181,8 @@ static inline u16
 drm_edp_dsc_sink_output_bpp(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
 {
return dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_LOW - DP_DSC_SUPPORT] |
-   (dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_HI - DP_DSC_SUPPORT] &
-DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK <<
-DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT);
+   ((dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_HI - DP_DSC_SUPPORT] &
+ DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK) << 8);
 }
 
 static inline u32
-- 
2.39.2

[Intel-gfx] [PATCH 2/2] drm/dsc: fix DP_DSC_MAX_BPP_DELTA_* macro values

The macro values just don't match the specs. Fix them.

Fixes: 1482ec00be4a ("drm: Add missing DP DSC extended capability definitions.")
Cc: Vinod Govindapillai 
Cc: Stanislav Lisovskiy 
Signed-off-by: Jani Nikula 
---
 include/drm/display/drm_dp.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index 89d5a700b04d..f8813c1e059b 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -286,8 +286,8 @@
 
 #define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068   /* eDP 1.4 */
 # define DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK  (0x3 << 0)
-# define DP_DSC_MAX_BPP_DELTA_VERSION_MASK  0x06
-# define DP_DSC_MAX_BPP_DELTA_AVAILABILITY  0x08
+# define DP_DSC_MAX_BPP_DELTA_VERSION_MASK  (0x3 << 5) /* eDP 1.5 & DP 2.0 */
+# define DP_DSC_MAX_BPP_DELTA_AVAILABILITY  (1 << 7)   /* eDP 1.5 & DP 2.0 */
 
 #define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069
 # define DP_DSC_RGB (1 << 0)
-- 
2.39.2

Re: [Intel-gfx] [PATCH] drm/i915: Query compressed bpp properly using correct DPCD and DP Spec info

On Thu, 06 Apr 2023, Jani Nikula  wrote:
> On Thu, 06 Apr 2023, "Lisovskiy, Stanislav"  
> wrote:
>> Not planning to upstream that actually, just for some bug on gitlab.
>> Want to see if that helps the reporter, then at least there is an idea whats 
>> the problem.
>
> The issue in drm_edp_dsc_sink_output_bpp() needs to be fixed regardless.

https://patchwork.freedesktop.org/patch/msgid/20230406134615.1422509-1-jani.nik...@intel.com

>
> BR,
> Jani.
>
>
>>
>> 
>> From: Jani Nikula 
>> Sent: Thursday, April 6, 2023 12:59 PM
>> To: Lisovskiy, Stanislav; intel-gfx@lists.freedesktop.org
>> Cc: Manasi Navare
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Query compressed bpp properly 
>> using correct DPCD and DP Spec info
>>
>> On Thu, 06 Apr 2023, Stanislav Lisovskiy  
>> wrote:
>>> Currently we seem to be using wrong DPCD register for reading compressed 
>>> bpps,
>>> reading min/max input bpc instead of compressed bpp.
>>> Fix that, so that we now apply min/max compressed bpp limitations we get
>>> from DP Spec Table 2-157 DP v2.0 and/or correspondent DPCD register
>>> DP_DSC_MAX_BITS_PER_PIXEL_LOW/HIGH.
>>>
>>> This might also allow us to get rid of an ugly compressed bpp recalculation,
>>> which we had to add to make some MST hubs usable.
>>>
>>> Signed-off-by: Stanislav Lisovskiy 
>>> ---
>>>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 76 ++---
>>>  1 file changed, 52 insertions(+), 24 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
>>> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
>>> index a88b852c437c..9479c7e0b269 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
>>> @@ -174,6 +174,50 @@ static int intel_dp_mst_compute_link_config(struct 
>>> intel_encoder *encoder,
>>>   return 0;
>>>  }
>>>
>>> +static u16 dsc_max_sink_compressed_bppx16(const u8 
>>> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
>>> +   struct intel_crtc_state 
>>> *pipe_config,
>>> +   int bpc)
>>> +{
>>> + u16 max_bppx16 = dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_LOW - 
>>> DP_DSC_SUPPORT] |
>>> +  (dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_HI - 
>>> DP_DSC_SUPPORT] &
>>> +   DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK << 
>>> DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT);
>>
>> This duplicates drm_edp_dsc_sink_output_bpp().
>>
>> Both have operator precedence wrong, leading to the high byte always
>> being ignored. For example, sink reported max bpp of 32 turns to 0, and
>> 24 turns to 8.
>>
>> Broken since 2018. 0575650077ea ("drm/dp: DRM DP helper/macros to get DP
>> sink DSC parameters").
>>
>> The definition of DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT is misleading wrt
>> all of our regular usage. We should never have a FOO_MASK << FOO_SHIFT
>> in code, the MASK should always be already shifted in place. Here we do,
>> because the shift is not for shifting the mask in place, it's for
>> combining the high and low bytes. But I don't really think
>> DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT should exist, at all.
>>
>> BR,
>> Jani.
>>
>>
>>
>>> +
>>> + if (max_bppx16)
>>> + return max_bppx16;
>>> + /*
>>> +  * If support not given in DPCD 67h, 68h use the Maximum Allowed bit 
>>> rate
>>> +  * values as given in spec Table 2-157 DP v2.0
>>> +  */
>>> + switch (pipe_config->output_format) {
>>> + case INTEL_OUTPUT_FORMAT_RGB:
>>> + case INTEL_OUTPUT_FORMAT_YCBCR444:
>>> + return bpc << 4;
>>> + case INTEL_OUTPUT_FORMAT_YCBCR420:
>>> + return (3 * (bpc / 2)) << 4;
>>> + default:
>>> + MISSING_CASE(pipe_config->output_format);
>>> + break;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static u16 dsc_min_compressed_bppx16(struct intel_crtc_state *pipe_config)
>>> +{
>>> + switch (pipe_config->output_format) {
>>> + case INTEL_OUTPUT_FORMAT_RGB:
>>> + case INTEL_OUTPUT_FORMAT_YCBCR444:
>>> + return 8 << 4;
>>> + case INTEL_OUTPUT_FORMAT_YCBCR420:
>>> + return 6 << 4;
>>> + default:
>>> + MISSING_CASE(pipe_config->output_format);
>>> + break;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>>  static int intel_dp_dsc_mst_compute_link_config(struct intel_encoder 
>>> *encoder,
>>>   struct intel_crtc_state 
>>> *crtc_state,
>>>   struct drm_connector_state 
>>> *conn_state,
>>> @@ -191,8 +235,6 @@ static int intel_dp_dsc_mst_compute_link_config(struct 
>>> intel_encoder *encoder,
>>>   u8 dsc_bpc[3] = {0};
>>>   int min_bpp, max_bpp, sink_min_bpp, sink_max_bpp;
>>>   u8 dsc_max_bpc;
>>> - bool need_timeslot_recalc = false;
>>> - u32 last_compressed_bpp;
>>>
>>>   /* Max DSC Input BPC for ICL is 10 and for TGL+ is 12 */
>>>   if

[Intel-gfx] [PULL] drm-intel-next

2023-04-06 Thread Rodrigo Vivi

Hi Daniel,

Here goes drm-intel-next-2023-04-06:

- Fix DPT+shmem combo and add i915.enable_dpt modparam (Ville)
- i915.enable_sagv module parameter (Ville)
- Correction to QGV related register addresses (Vinod)
- IPS debugfs per-crtc and new file for false_color (Ville)
- More clean-up and reorganization of Display code (Jani)
- DP DSC related fixes and improvements (Stanislav, Ankit, Suraj, Swati)
- Make utility pin asserts more accurate (Ville)
- Meteor Lake enabling (Daniele)
- High refresh rate PSR fixes (Jouni)
- Cursor and Plane chicken register fixes (Ville)
- Align the ADL-P TypeC sequences with hardware specification (Imre)
- Documentation build fixes and improvements to catch bugs earlier (Lee, Jani)
- PL1 power limit hwmon entry changed to use 0 as disabled state (Ashutosh)
- DP aux sync fix and improvements (Ville)
- DP MST fixes and w/a (Stanislav)
- Limit PXP drm-errors or warning on firmware API failures (Alan)

Thanks,
Rodrigo.

The following changes since commit 46f28427f6f824b6cff06fa025a55350b7de454a:

  Merge tag 'drm-rcar-next-20230325' of 
git://git.kernel.org/pub/scm/linux/kernel/git/pinchartl/linux into drm-next 
(2023-03-27 18:20:20 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2023-04-06

for you to fetch changes up to b358793c3bf231c455c55e0173256a86483997a8:

  drm/i915/wakeref: fix kernel-doc comment (2023-04-06 15:39:26 +0300)


- Fix DPT+shmem combo and add i915.enable_dpt modparam (Ville)
- i915.enable_sagv module parameter (Ville)
- Correction to QGV related register addresses (Vinod)
- IPS debugfs per-crtc and new file for false_color (Ville)
- More clean-up and reorganization of Display code (Jani)
- DP DSC related fixes and improvements (Stanislav, Ankit, Suraj, Swati)
- Make utility pin asserts more accurate (Ville)
- Meteor Lake enabling (Daniele)
- High refresh rate PSR fixes (Jouni)
- Cursor and Plane chicken register fixes (Ville)
- Align the ADL-P TypeC sequences with hardware specification (Imre)
- Documentation build fixes and improvements to catch bugs earlier (Lee, Jani)
- PL1 power limit hwmon entry changed to use 0 as disabled state (Ashutosh)
- DP aux sync fix and improvements (Ville)
- DP MST fixes and w/a (Stanislav)
- Limit PXP drm-errors or warning on firmware API failures (Alan)


Alan Previn (1):
  drm/i915/pxp: limit drm-errors or warning on firmware API failures

Ankit Nautiyal (2):
  drm/dp_helper: Add helper to check DSC support with given o/p format
  drm/i915/dp: Check if DSC supports the given output_format

Ashutosh Dixit (1):
  drm/i915/hwmon: Use 0 to designate disabled PL1 power limit

Daniele Ceraolo Spurio (1):
  drm/i915/mtl: Fix MTL stolen memory GGTT mapping

Imre Deak (29):
  drm/i915/tc: Group the TC PHY setup/query functions per platform
  drm/i915/tc: Use the adlp prefix for ADLP TC PHY functions
  drm/i915/tc: Rename tc_phy_status_complete() to tc_phy_is_ready()
  drm/i915/tc: Use the tc_phy prefix for all TC PHY functions
  drm/i915/tc: Move TC port fields to a new intel_tc_port struct
  drm/i915/tc: Check for TC PHY explicitly in 
intel_tc_port_fia_max_lane_count()
  drm/i915/tc: Move the intel_tc_port struct declaration to intel_tc.c
  drm/i915/tc: Add TC PHY hook to get the PHY HPD live status
  drm/i915/tc: Add TC PHY hooks to get the PHY ready/owned state
  drm/i915/tc: Add TC PHY hook to read out the PHY HW state
  drm/i915/tc: Add generic TC PHY connect/disconnect handlers
  drm/i915/tc: Factor out tc_phy_verify_legacy_or_dp_alt_mode()
  drm/i915/tc: Add TC PHY hooks to connect/disconnect the PHY
  drm/i915/tc: Fix up the legacy VBT flag only in disconnected mode
  drm/i915/tc: Check TC mode instead of the VBT legacy flag
  drm/i915/tc: Block/unblock TC-cold in the PHY connect/disconnect hooks
  drm/i915/tc: Remove redundant wakeref=0 check from unblock_tc_cold()
  drm/i915/tc: Drop tc_cold_block()/unblock()'s power domain parameter
  drm/i915/tc: Add TC PHY hook to get the TC-cold blocking power domain
  drm/i915/tc: Add asserts in TC PHY hooks that the required power is on
  drm/i915/tc: Add TC PHY hook to init the PHY
  drm/i915/adlp/tc: Use the DE HPD ISR register for hotplug detection
  drm/i915/tc: Get power ref for reading the HPD live status register
  drm/i915/tc: Don't connect the PHY in intel_tc_port_connected()
  drm/i915/adlp/tc: Align the connect/disconnect PHY sequence with bspec
  drm/i915: Move shared DPLL disabling into CRTC disable hook
  drm/i915: Disable DPLLs before disconnecting the TC PHY
  drm/i915: Remove TC PHY disconnect workaround
  drm/i915: Remove the encoder update_prepare()/complete() hooks

Jani Nikula (14):
  drm/i915: remove unused config DRM_I915_UNSTABLE

Re: [Intel-gfx] [PATCH v9 08/25] vfio: Block device access via device fd until device is opened




On 4/1/23 17:18, Yi Liu wrote:
> Allow the vfio_device file to be in a state where the device FD is
> opened but the device cannot be used by userspace (i.e. its .open_device()
> hasn't been called). This inbetween state is not used when the device
> FD is spawned from the group FD, however when we create the device FD
> directly by opening a cdev it will be opened in the blocked state.
>
> The reason for the inbetween state is that userspace only gets a FD but
> doesn't gain access permission until binding the FD to an iommufd. So in
> the blocked state, only the bind operation is allowed. Completing bind
> will allow user to further access the device.
>
> This is implemented by adding a flag in struct vfio_device_file to mark
> the blocked state and using a simple smp_load_acquire() to obtain the
> flag value and serialize all the device setup with the thread accessing
> this device.
>
> Following this lockless scheme, it can safely handle the device FD
> unbound->bound but it cannot handle bound->unbound. To allow this we'd
> need to add a lock on all the vfio ioctls which seems costly. So once
> device FD is bound, it remains bound until the FD is closed.
>
> Suggested-by: Jason Gunthorpe 
> Reviewed-by: Kevin Tian 
> Reviewed-by: Jason Gunthorpe 
> Tested-by: Terrence Xu 
> Tested-by: Nicolin Chen 
> Tested-by: Matthew Rosato 
> Tested-by: Yanting Jiang 
> Signed-off-by: Yi Liu 
Reviewed-by: Eric Auger 

Eric
> ---
>  drivers/vfio/group.c | 11 ++-
>  drivers/vfio/vfio.h  |  1 +
>  drivers/vfio/vfio_main.c | 42 ++--
>  3 files changed, 47 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
> index 9a7b2765eef6..71f0a9a4016e 100644
> --- a/drivers/vfio/group.c
> +++ b/drivers/vfio/group.c
> @@ -194,9 +194,18 @@ static int vfio_device_group_open(struct 
> vfio_device_file *df)
>   df->iommufd = device->group->iommufd;
>  
>   ret = vfio_device_open(df);
> - if (ret)
> + if (ret) {
>   df->iommufd = NULL;
> + goto out_put_kvm;
> + }
> +
> + /*
> +  * Paired with smp_load_acquire() in vfio_device_fops::ioctl/
> +  * read/write/mmap and vfio_file_has_device_access()
> +  */
> + smp_store_release(&df->access_granted, true);
>  
> +out_put_kvm:
>   if (device->open_count == 0)
>   vfio_device_put_kvm(device);
>  
> diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
> index cffc08f5a6f1..854f2c97cb9a 100644
> --- a/drivers/vfio/vfio.h
> +++ b/drivers/vfio/vfio.h
> @@ -18,6 +18,7 @@ struct vfio_container;
>  
>  struct vfio_device_file {
>   struct vfio_device *device;
> + bool access_granted;
>   spinlock_t kvm_ref_lock; /* protect kvm field */
>   struct kvm *kvm;
>   struct iommufd_ctx *iommufd; /* protected by struct 
> vfio_device_set::lock */
> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> index 2ea6cb6d03c7..6d5d3c2180c8 100644
> --- a/drivers/vfio/vfio_main.c
> +++ b/drivers/vfio/vfio_main.c
> @@ -1114,6 +1114,10 @@ static long vfio_device_fops_unl_ioctl(struct file 
> *filep,
>   struct vfio_device *device = df->device;
>   int ret;
>  
> + /* Paired with smp_store_release() following vfio_device_open() */
> + if (!smp_load_acquire(&df->access_granted))
> + return -EINVAL;
> +
>   ret = vfio_device_pm_runtime_get(device);
>   if (ret)
>   return ret;
> @@ -1141,6 +1145,10 @@ static ssize_t vfio_device_fops_read(struct file 
> *filep, char __user *buf,
>   struct vfio_device_file *df = filep->private_data;
>   struct vfio_device *device = df->device;
>  
> + /* Paired with smp_store_release() following vfio_device_open() */
> + if (!smp_load_acquire(&df->access_granted))
> + return -EINVAL;
> +
>   if (unlikely(!device->ops->read))
>   return -EINVAL;
>  
> @@ -1154,6 +1162,10 @@ static ssize_t vfio_device_fops_write(struct file 
> *filep,
>   struct vfio_device_file *df = filep->private_data;
>   struct vfio_device *device = df->device;
>  
> + /* Paired with smp_store_release() following vfio_device_open() */
> + if (!smp_load_acquire(&df->access_granted))
> + return -EINVAL;
> +
>   if (unlikely(!device->ops->write))
>   return -EINVAL;
>  
> @@ -1165,6 +1177,10 @@ static int vfio_device_fops_mmap(struct file *filep, 
> struct vm_area_struct *vma)
>   struct vfio_device_file *df = filep->private_data;
>   struct vfio_device *device = df->device;
>  
> + /* Paired with smp_store_release() following vfio_device_open() */
> + if (!smp_load_acquire(&df->access_granted))
> + return -EINVAL;
> +
>   if (unlikely(!device->ops->mmap))
>   return -EINVAL;
>  
> @@ -1201,6 +1217,25 @@ bool vfio_file_is_valid(struct file *file)
>  }
>  EXPORT_SYMBOL_GPL(vfio_file_is_valid);
>  
> +/*
> + * Return true if the input file

Re: [Intel-gfx] [PATCH v9 09/25] vfio: Add cdev_device_open_cnt to vfio_group

Hi Yi,

On 4/1/23 17:18, Yi Liu wrote:
> for counting the devices that are opened via the cdev path. This count
> is increased and decreased by the cdev path. The group path checks it
> to achieve exclusion with the cdev path. With this, only one path (group
> path or cdev path) will claim DMA ownership. This avoids scenarios in
> which devices within the same group may be opened via different paths.
>
> Reviewed-by: Kevin Tian 
> Reviewed-by: Jason Gunthorpe 
> Tested-by: Terrence Xu 
> Tested-by: Nicolin Chen 
> Tested-by: Matthew Rosato 
> Tested-by: Yanting Jiang 
> Signed-off-by: Yi Liu 
Reviewed-by: Eric Auger 

Thanks

Eric
> ---
>  drivers/vfio/group.c | 33 +
>  drivers/vfio/vfio.h  |  3 +++
>  2 files changed, 36 insertions(+)
>
> diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
> index 71f0a9a4016e..d55ce3ca44b7 100644
> --- a/drivers/vfio/group.c
> +++ b/drivers/vfio/group.c
> @@ -383,6 +383,33 @@ static long vfio_group_fops_unl_ioctl(struct file *filep,
>   }
>  }
>  
> +int vfio_device_block_group(struct vfio_device *device)
> +{
> + struct vfio_group *group = device->group;
> + int ret = 0;
> +
> + mutex_lock(&group->group_lock);
> + if (group->opened_file) {
> + ret = -EBUSY;
> + goto out_unlock;
> + }
> +
> + group->cdev_device_open_cnt++;
> +
> +out_unlock:
> + mutex_unlock(&group->group_lock);
> + return ret;
> +}
> +
> +void vfio_device_unblock_group(struct vfio_device *device)
> +{
> + struct vfio_group *group = device->group;
> +
> + mutex_lock(&group->group_lock);
> + group->cdev_device_open_cnt--;
> + mutex_unlock(&group->group_lock);
> +}
> +
>  static int vfio_group_fops_open(struct inode *inode, struct file *filep)
>  {
>   struct vfio_group *group =
> @@ -405,6 +432,11 @@ static int vfio_group_fops_open(struct inode *inode, 
> struct file *filep)
>   goto out_unlock;
>   }
>  
> + if (group->cdev_device_open_cnt) {
> + ret = -EBUSY;
> + goto out_unlock;
> + }
> +
>   /*
>* Do we need multiple instances of the group open?  Seems not.
>*/
> @@ -479,6 +511,7 @@ static void vfio_group_release(struct device *dev)
>   mutex_destroy(&group->device_lock);
>   mutex_destroy(&group->group_lock);
>   WARN_ON(group->iommu_group);
> + WARN_ON(group->cdev_device_open_cnt);
>   ida_free(&vfio.group_ida, MINOR(group->dev.devt));
>   kfree(group);
>  }
> diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
> index 854f2c97cb9a..b2f20b78a707 100644
> --- a/drivers/vfio/vfio.h
> +++ b/drivers/vfio/vfio.h
> @@ -83,8 +83,11 @@ struct vfio_group {
>   struct blocking_notifier_head   notifier;
>   struct iommufd_ctx  *iommufd;
>   spinlock_t  kvm_ref_lock;
> + unsigned intcdev_device_open_cnt;
>  };
>  
> +int vfio_device_block_group(struct vfio_device *device);
> +void vfio_device_unblock_group(struct vfio_device *device);
>  int vfio_device_set_group(struct vfio_device *device,
> enum vfio_group_type type);
>  void vfio_device_remove_group(struct vfio_device *device);

[Intel-gfx] [PATCH i-g-t 1/8] lib: Extract igt_drm_clients from intel_gpu_top

From: Tvrtko Ursulin 

Extract some code into a new library to prepare for further work towards
making a vendor agnostic gputop tool.

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_drm_clients.c | 432 +++
 lib/igt_drm_clients.h |  85 +++
 lib/meson.build   |   8 +
 tools/intel_gpu_top.c | 519 +++---
 tools/meson.build |   2 +-
 5 files changed, 605 insertions(+), 441 deletions(-)
 create mode 100644 lib/igt_drm_clients.c
 create mode 100644 lib/igt_drm_clients.h

diff --git a/lib/igt_drm_clients.c b/lib/igt_drm_clients.c
new file mode 100644
index ..45de2d0f1cc5
--- /dev/null
+++ b/lib/igt_drm_clients.c
@@ -0,0 +1,432 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "igt_drm_clients.h"
+#include "igt_drm_fdinfo.h"
+
+#ifndef ARRAY_SIZE
+#define ARRAY_SIZE(array) (sizeof(array) / sizeof(array[0]))
+#endif
+
+/**
+ * igt_drm_clients_init:
+ * @private_data: private data to store in the struct
+ *
+ * Allocate and initialise the clients structure to be used with further API
+ * calls.
+ */
+struct igt_drm_clients *igt_drm_clients_init(void *private_data)
+{
+   struct igt_drm_clients *clients;
+
+   clients = malloc(sizeof(*clients));
+   if (!clients)
+   return NULL;
+
+   memset(clients, 0, sizeof(*clients));
+
+   clients->private_data = private_data;
+
+   return clients;
+}
+
+static struct igt_drm_client *
+igt_drm_clients_find(struct igt_drm_clients *clients,
+enum igt_drm_client_status status,
+unsigned int id)
+{
+   unsigned int start, num;
+   struct igt_drm_client *c;
+
+   start = status == IGT_DRM_CLIENT_FREE ? clients->active_clients : 0; /* 
Free block at the end. */
+   num = clients->num_clients - start;
+
+   for (c = &clients->client[start]; num; c++, num--) {
+   if (status != c->status)
+   continue;
+
+   if (status == IGT_DRM_CLIENT_FREE || c->id == id)
+   return c;
+   }
+
+   return NULL;
+}
+
+static void
+igt_drm_client_update(struct igt_drm_client *c, unsigned int pid, char *name,
+ const struct drm_client_fdinfo *info)
+{
+   unsigned int i;
+
+   /* Update client pid if it changed (fd sharing). */
+   if (c->pid != pid)
+   c->pid = pid;
+
+   /* Update client name if it changed (fd sharing). */
+   if (strcmp(c->name, name)) {
+   char *p;
+
+   strncpy(c->name, name, sizeof(c->name) - 1);
+   strncpy(c->print_name, name, sizeof(c->print_name) - 1);
+
+   p = c->print_name;
+   while (*p) {
+   if (!isprint(*p))
+   *p = '*';
+   p++;
+   }
+   }
+
+   c->last_runtime = 0;
+   c->total_runtime = 0;
+
+   for (i = 0; i < c->clients->num_classes; i++) {
+   assert(i < ARRAY_SIZE(info->busy));
+
+   if (info->busy[i] < c->last[i])
+   continue; /* It will catch up soon. */
+
+   c->total_runtime += info->busy[i];
+   c->val[i] = info->busy[i] - c->last[i];
+   c->last_runtime += c->val[i];
+   c->last[i] = info->busy[i];
+   }
+
+   c->samples++;
+   c->status = IGT_DRM_CLIENT_ALIVE;
+}
+
+static void
+igt_drm_client_add(struct igt_drm_clients *clients,
+  const struct drm_client_fdinfo *info,
+  unsigned int pid, char *name)
+{
+   struct igt_drm_client *c;
+
+   assert(!igt_drm_clients_find(clients, IGT_DRM_CLIENT_ALIVE, info->id));
+
+   c = igt_drm_clients_find(clients, IGT_DRM_CLIENT_FREE, 0);
+   if (!c) {
+   unsigned int idx = clients->num_clients;
+
+   /*
+* Grow the array a bit past the current requirement to avoid
+* constant reallocation when clients are dynamically appearing
+* and disappearing.
+*/
+   clients->num_clients += (clients->num_clients + 2) / 2;
+   clients->client = realloc(clients->client,
+ clients->num_clients * sizeof(*c));
+   assert(clients->client);
+
+   c = &clients->client[idx];
+   memset(c, 0, (clients->num_clients - idx) * sizeof(*c));
+   }
+
+   c->id = info->id;
+   c->clients = clients;
+   c->val = calloc(clients->num_classes, sizeof(c->val));
+   c->last = calloc(clients->num_classes, sizeof(c->last));
+   assert(c->val && c->last);
+
+   igt_drm_client_update(c, pid, name, info);
+}
+
+static
+void igt_drm_client_free(struct

[Intel-gfx] [PATCH i-g-t v4 0/8] Vendor agnostic gputop

From: Tvrtko Ursulin 

This is a pile of patches which implements a rudimentary vendor agnostic gputop
tool based of the new DRM spec as documented in
Documentation/gpu/drm-usage-stats.rst.

First part of the series is code refactoring which should be reasonably stable.
I've tested it all while working on it both against intel_gpu_top and gputop.

Last patch is the actual tool itself. It works but it is rather rudimentary
which is hopefully good enough for a start.

Fundamental difference between intel_gpu_top and gputop is that the former is
centered around a single card and only shows processes belonging to it. Gputop
on the other hand has an idea to show all processes with DRM file descriptors
open and sort them into groups per card. It also makes no effort to provide
sorting modes, well any interactivity, or any pretty names for GPUs or engines.

It looks like this:

DRM minor 0
PID   NAMErender   copy   video
3816  kwin_x11 |███▎  ||  ||  ||  |
3523  Xorg |▊ ||  ||  ||  |
 1120449   mpv |  ||  ||▋ ||  |
 1120529  glxgears |▋ ||  ||  ||  |
 1120449   mpv |▍ ||  ||  ||  |
3860   plasmashell |▏ ||  ||  ||  |
4764   krunner |  ||  ||  ||  |
  575206chrome |  ||  ||  ||  |
  833481   firefox |  ||  ||  ||  |
  892924   thunderbird |  ||  ||  ||  |


I did test it as well with two cards and confirmed that too works.

Rob Clark also tested it with a patch which exports the respective data from the
msm driver and confirmed it works fine. Christian König tested it with in
progress patches for amdgpu and that worked as well.

v2:
 * Fixed SPDX headers and added a bunch of code comments/docs throughout.

v3:
 * Rebased and some patch titles renamed as requested. (Kamil)

v4:
 * Just a rebase for conflicts due passage of time.

Tvrtko Ursulin (8):
  lib: Extract igt_drm_clients from intel_gpu_top
  lib: Allow specifying custom engine map
  lib/igt_drm_clients: Record client drm minor
  lib/igt_drm_clients: Support multiple DRM cards
  lib/igt_drm_fdinfo: Track largest engine index
  lib/igt_drm_clients: Decouple hardcoded engine assumptions
  lib/igt_drm_clients: Enforce client status sort order in the library
  gputop: Basic vendor agnostic GPU top tool

 lib/igt_drm_clients.c   | 503 ++
 lib/igt_drm_clients.h   |  87 ++
 lib/igt_drm_fdinfo.c|  50 ++-
 lib/igt_drm_fdinfo.h|  16 +-
 lib/meson.build |   8 +
 tests/i915/drm_fdinfo.c |  19 +-
 tools/gputop.c  | 260 
 tools/intel_gpu_top.c   | 675 +++-
 tools/meson.build   |   7 +-
 9 files changed, 1112 insertions(+), 513 deletions(-)
 create mode 100644 lib/igt_drm_clients.c
 create mode 100644 lib/igt_drm_clients.h
 create mode 100644 tools/gputop.c

-- 
2.37.2

[Intel-gfx] [PATCH i-g-t 3/8] lib/igt_drm_clients: Record client drm minor

From: Tvrtko Ursulin 

Prepare for supporting clients belonging to multiple DRM cards by storing
the DRM minor in the client record.

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_drm_clients.c | 22 ++
 lib/igt_drm_clients.h |  1 +
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/lib/igt_drm_clients.c b/lib/igt_drm_clients.c
index eabd43773f2d..c23a3fae9793 100644
--- a/lib/igt_drm_clients.c
+++ b/lib/igt_drm_clients.c
@@ -115,7 +115,7 @@ igt_drm_client_update(struct igt_drm_client *c, unsigned 
int pid, char *name,
 static void
 igt_drm_client_add(struct igt_drm_clients *clients,
   const struct drm_client_fdinfo *info,
-  unsigned int pid, char *name)
+  unsigned int pid, char *name, unsigned int drm_minor)
 {
struct igt_drm_client *c;
 
@@ -140,6 +140,7 @@ igt_drm_client_add(struct igt_drm_clients *clients,
}
 
c->id = info->id;
+   c->drm_minor = drm_minor;
c->clients = clients;
c->val = calloc(clients->num_classes, sizeof(c->val));
c->last = calloc(clients->num_classes, sizeof(c->last));
@@ -286,16 +287,21 @@ static bool get_task_name(const char *buffer, char *out, 
unsigned long sz)
return true;
 }
 
-static bool is_drm_fd(int fd_dir, const char *name)
+static bool is_drm_fd(int fd_dir, const char *name, unsigned int *minor)
 {
struct stat stat;
int ret;
 
ret = fstatat(fd_dir, name, &stat, 0);
 
-   return ret == 0 &&
-  (stat.st_mode & S_IFMT) == S_IFCHR &&
-  major(stat.st_rdev) == 226;
+   if (ret == 0 &&
+   (stat.st_mode & S_IFMT) == S_IFCHR &&
+   major(stat.st_rdev) == 226) {
+   *minor = minor(stat.st_rdev);
+   return true;
+   }
+
+   return false;
 }
 
 /**
@@ -348,10 +354,10 @@ igt_drm_clients_scan(struct igt_drm_clients *clients,
return clients;
 
while ((proc_dent = readdir(proc_dir)) != NULL) {
+   unsigned int client_pid, minor = 0;
int pid_dir = -1, fd_dir = -1;
struct dirent *fdinfo_dent;
char client_name[64] = { };
-   unsigned int client_pid;
DIR *fdinfo_dir = NULL;
char buf[4096];
size_t count;
@@ -393,7 +399,7 @@ igt_drm_clients_scan(struct igt_drm_clients *clients,
if (!isdigit(fdinfo_dent->d_name[0]))
continue;
 
-   if (!is_drm_fd(fd_dir, fdinfo_dent->d_name))
+   if (!is_drm_fd(fd_dir, fdinfo_dent->d_name, &minor))
continue;
 
if (!__igt_parse_drm_fdinfo(dirfd(fdinfo_dir),
@@ -412,7 +418,7 @@ igt_drm_clients_scan(struct igt_drm_clients *clients,
info.id);
if (!c)
igt_drm_client_add(clients, &info, client_pid,
-  client_name);
+  client_name, minor);
else
igt_drm_client_update(c, client_pid,
  client_name, &info);
diff --git a/lib/igt_drm_clients.h b/lib/igt_drm_clients.h
index bced19adb055..ffa219c9c9fd 100644
--- a/lib/igt_drm_clients.h
+++ b/lib/igt_drm_clients.h
@@ -44,6 +44,7 @@ struct igt_drm_client {
 
enum igt_drm_client_status status;
unsigned int id; /* DRM client id from fdinfo. */
+   unsigned int drm_minor; /* DRM minor of this client. */
unsigned int pid; /* PID which has this DRM fd open. */
char name[24]; /* Process name of the owning PID. */
char print_name[24]; /* Name without any non-printable characters. */
-- 
2.37.2

[Intel-gfx] [PATCH i-g-t 4/8] lib/igt_drm_clients: Support multiple DRM cards

From: Tvrtko Ursulin 

Require DRM minor match during client lookup.

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_drm_clients.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/lib/igt_drm_clients.c b/lib/igt_drm_clients.c
index c23a3fae9793..e11c8b18188f 100644
--- a/lib/igt_drm_clients.c
+++ b/lib/igt_drm_clients.c
@@ -49,7 +49,7 @@ struct igt_drm_clients *igt_drm_clients_init(void 
*private_data)
 static struct igt_drm_client *
 igt_drm_clients_find(struct igt_drm_clients *clients,
 enum igt_drm_client_status status,
-unsigned int id)
+unsigned int drm_minor, unsigned int id)
 {
unsigned int start, num;
struct igt_drm_client *c;
@@ -61,7 +61,8 @@ igt_drm_clients_find(struct igt_drm_clients *clients,
if (status != c->status)
continue;
 
-   if (status == IGT_DRM_CLIENT_FREE || c->id == id)
+   if (status == IGT_DRM_CLIENT_FREE ||
+   (drm_minor == c->drm_minor && c->id == id))
return c;
}
 
@@ -119,9 +120,10 @@ igt_drm_client_add(struct igt_drm_clients *clients,
 {
struct igt_drm_client *c;
 
-   assert(!igt_drm_clients_find(clients, IGT_DRM_CLIENT_ALIVE, info->id));
+   assert(!igt_drm_clients_find(clients, IGT_DRM_CLIENT_ALIVE,
+drm_minor, info->id));
 
-   c = igt_drm_clients_find(clients, IGT_DRM_CLIENT_FREE, 0);
+   c = igt_drm_clients_find(clients, IGT_DRM_CLIENT_FREE, 0, 0);
if (!c) {
unsigned int idx = clients->num_clients;
 
@@ -411,11 +413,11 @@ igt_drm_clients_scan(struct igt_drm_clients *clients,
continue;
 
if (igt_drm_clients_find(clients, IGT_DRM_CLIENT_ALIVE,
-   info.id))
+minor, info.id))
continue; /* Skip duplicate fds. */
 
c = igt_drm_clients_find(clients, IGT_DRM_CLIENT_PROBE,
-   info.id);
+minor, info.id);
if (!c)
igt_drm_client_add(clients, &info, client_pid,
   client_name, minor);
-- 
2.37.2

[Intel-gfx] [PATCH i-g-t 2/8] lib: Allow specifying custom engine map

From: Tvrtko Ursulin 

Instead of hard coding the engine names, allow a map of names to indices
to either be passed in or it gets auto-detected (less efficient) while
parsing.
---
 lib/igt_drm_clients.c   | 18 +---
 lib/igt_drm_clients.h   |  3 ++-
 lib/igt_drm_fdinfo.c| 48 +++--
 lib/igt_drm_fdinfo.h| 15 ++---
 tests/i915/drm_fdinfo.c | 19 
 tools/intel_gpu_top.c   | 16 +++---
 6 files changed, 89 insertions(+), 30 deletions(-)

diff --git a/lib/igt_drm_clients.c b/lib/igt_drm_clients.c
index 45de2d0f1cc5..eabd43773f2d 100644
--- a/lib/igt_drm_clients.c
+++ b/lib/igt_drm_clients.c
@@ -302,14 +302,26 @@ static bool is_drm_fd(int fd_dir, const char *name)
  * igt_drm_clients_scan:
  * @clients: Previously initialised clients object
  * @filter_client: Callback for client filtering
+ * @name_map: Array of engine name strings
+ * @map_entries: Number of items in the @name_map array
  *
  * Scan all open file descriptors from all processes in order to find all DRM
  * clients and manage our internal list.
+ *
+ * If @name_map is provided each found engine in the fdinfo struct must
+ * correspond to one of the provided names. In this case the index of the 
engine
+ * stats tracked in struct igt_drm_client will be tracked under the same index
+ * as the engine name provided.
+ *
+ * If @name_map is not provided engine names will be auto-detected (this is
+ * less performant) and indices will correspond with auto-detected names as
+ * listed int clients->engine_class[].
  */
 struct igt_drm_clients *
 igt_drm_clients_scan(struct igt_drm_clients *clients,
 bool (*filter_client)(const struct igt_drm_clients *,
-  const struct drm_client_fdinfo *))
+  const struct drm_client_fdinfo *),
+const char **name_map, unsigned int map_entries)
 {
struct dirent *proc_dent;
struct igt_drm_client *c;
@@ -385,8 +397,8 @@ igt_drm_clients_scan(struct igt_drm_clients *clients,
continue;
 
if (!__igt_parse_drm_fdinfo(dirfd(fdinfo_dir),
-   fdinfo_dent->d_name,
-   &info))
+   fdinfo_dent->d_name, &info,
+   name_map, map_entries))
continue;
 
if (filter_client && !filter_client(clients, &info))
diff --git a/lib/igt_drm_clients.h b/lib/igt_drm_clients.h
index 969793d5b51e..bced19adb055 100644
--- a/lib/igt_drm_clients.h
+++ b/lib/igt_drm_clients.h
@@ -76,7 +76,8 @@ void igt_drm_clients_free(struct igt_drm_clients *clients);
 struct igt_drm_clients *
 igt_drm_clients_scan(struct igt_drm_clients *clients,
 bool (*filter_client)(const struct igt_drm_clients *,
-  const struct drm_client_fdinfo *));
+  const struct drm_client_fdinfo *),
+const char **name_map, unsigned int map_entries);
 
 struct igt_drm_clients *
 igt_drm_clients_sort(struct igt_drm_clients *clients,
diff --git a/lib/igt_drm_fdinfo.c b/lib/igt_drm_fdinfo.c
index 250d9e8917f2..68c89ad2c17e 100644
--- a/lib/igt_drm_fdinfo.c
+++ b/lib/igt_drm_fdinfo.c
@@ -22,6 +22,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -53,14 +54,10 @@ static size_t read_fdinfo(char *buf, const size_t sz, int 
at, const char *name)
 }
 
 static int parse_engine(char *line, struct drm_client_fdinfo *info,
-   size_t prefix_len, uint64_t *val)
+   size_t prefix_len,
+   const char **name_map, unsigned int map_entries,
+   uint64_t *val)
 {
-   static const char *e2class[] = {
-   "render",
-   "copy",
-   "video",
-   "video-enhance",
-   };
ssize_t name_len;
char *name, *p;
int found = -1;
@@ -76,10 +73,26 @@ static int parse_engine(char *line, struct 
drm_client_fdinfo *info,
 
name = line + prefix_len;
 
-   for (i = 0; i < ARRAY_SIZE(e2class); i++) {
-   if (!strncmp(name, e2class[i], name_len)) {
-   found = i;
-   break;
+   if (name_map) {
+   for (i = 0; i < map_entries; i++) {
+   if (!strncmp(name, name_map[i], name_len)) {
+   found = i;
+   break;
+   }
+   }
+   } else {
+   for (i = 0; i < info->num_engines; i++) {
+   if (!strncmp(name, info->names[i], name_len)) {
+   found = i;
+   break;
+

[Intel-gfx] [PATCH i-g-t 5/8] lib/igt_drm_fdinfo: Track largest engine index

From: Tvrtko Ursulin 

Prep code for incoming work.

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_drm_fdinfo.c | 2 ++
 lib/igt_drm_fdinfo.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/lib/igt_drm_fdinfo.c b/lib/igt_drm_fdinfo.c
index 68c89ad2c17e..b850d2210ae7 100644
--- a/lib/igt_drm_fdinfo.c
+++ b/lib/igt_drm_fdinfo.c
@@ -162,6 +162,8 @@ __igt_parse_drm_fdinfo(int dir, const char *fd, struct 
drm_client_fdinfo *info,
info->capacity[idx] = 1;
info->busy[idx] = val;
info->num_engines++;
+   if (idx > info->last_engine_index)
+   info->last_engine_index = idx;
}
} else if (!strncmp(l, "drm-engine-capacity-", 20)) {
idx = parse_engine(l, info,
diff --git a/lib/igt_drm_fdinfo.h b/lib/igt_drm_fdinfo.h
index fa4982f4030e..6284e05e868a 100644
--- a/lib/igt_drm_fdinfo.h
+++ b/lib/igt_drm_fdinfo.h
@@ -38,6 +38,7 @@ struct drm_client_fdinfo {
unsigned long id;
 
unsigned int num_engines;
+   unsigned int last_engine_index;
unsigned int capacity[DRM_CLIENT_FDINFO_MAX_ENGINES];
char names[DRM_CLIENT_FDINFO_MAX_ENGINES][256];
uint64_t busy[DRM_CLIENT_FDINFO_MAX_ENGINES];
-- 
2.37.2

[Intel-gfx] [PATCH i-g-t 7/8] lib/igt_drm_clients: Enforce client status sort order in the library

From: Tvrtko Ursulin 

Some libdrmclient operations require that inactive clients are last in the
list. Rather than relying on callers of the library sort routine to
implement their comparison callbacks correctly, enforce this order
directly in the library and let callers comparison callbacks concern
themselves only with ordering they are interested in.

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_drm_clients.c | 37 +++-
 lib/igt_drm_clients.h |  2 +-
 tools/intel_gpu_top.c | 81 +++
 3 files changed, 65 insertions(+), 55 deletions(-)

diff --git a/lib/igt_drm_clients.c b/lib/igt_drm_clients.c
index d507c07fec87..b3eda39cd226 100644
--- a/lib/igt_drm_clients.c
+++ b/lib/igt_drm_clients.c
@@ -191,22 +191,38 @@ void igt_drm_client_free(struct igt_drm_client *c, bool 
clear)
memset(c, 0, sizeof(*c));
 }
 
+struct sort_context
+{
+   int (*user_cmp)(const void *, const void *, void *);
+};
+
+static int sort_cmp(const void *_a, const void *_b, void *_ctx)
+{
+   const struct sort_context *ctx = _ctx;
+   const struct igt_drm_client *a = _a;
+   const struct igt_drm_client *b = _b;
+   int cmp = b->status - a->status;
+
+   if (cmp == 0)
+   return ctx->user_cmp(_a, _b, _ctx);
+   else
+   return cmp;
+}
+
 /**
  * igt_drm_clients_sort:
  * @clients: Previously initialised clients object
  * @cmp: Client comparison callback
  *
  * Sort the clients array according to the passed in comparison callback which
- * is compatible with the qsort(3) semantics.
- *
- * Caller has to ensure the callback is putting all active
- * (IGT_DRM_CLIENT_ALIVE) clients in a single group at the head of the array
- * before any other sorting criteria.
+ * is compatible with the qsort(3) semantics, with the third void * argument
+ * being unused.
  */
 struct igt_drm_clients *
 igt_drm_clients_sort(struct igt_drm_clients *clients,
-int (*cmp)(const void *, const void *))
+int (*cmp)(const void *, const void *, void *))
 {
+   struct sort_context ctx = { .user_cmp = cmp };
unsigned int active, free;
struct igt_drm_client *c;
int tmp;
@@ -214,8 +230,13 @@ igt_drm_clients_sort(struct igt_drm_clients *clients,
if (!clients)
return clients;
 
-   qsort(clients->client, clients->num_clients, sizeof(*clients->client),
- cmp);
+   /*
+* Enforce client->status ordering (active followed by free) by running
+* the user provided comparison callback wrapped in the one internal
+* to the library.
+*/
+   qsort_r(clients->client, clients->num_clients, sizeof(*clients->client),
+ sort_cmp, &ctx);
 
/* Trim excessive array space. */
active = 0;
diff --git a/lib/igt_drm_clients.h b/lib/igt_drm_clients.h
index 0a903b431eaa..df8022d42098 100644
--- a/lib/igt_drm_clients.h
+++ b/lib/igt_drm_clients.h
@@ -82,6 +82,6 @@ igt_drm_clients_scan(struct igt_drm_clients *clients,
 
 struct igt_drm_clients *
 igt_drm_clients_sort(struct igt_drm_clients *clients,
-int (*cmp)(const void *, const void *));
+int (*cmp)(const void *, const void *, void *));
 
 #endif /* IGT_DRM_CLIENTS_H */
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index c7af93e1e85e..226ae412479f 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -685,85 +685,74 @@ static void pmu_sample(struct engines *engines)
}
 }
 
-static int client_last_cmp(const void *_a, const void *_b)
+static int
+__client_id_cmp(const struct igt_drm_client *a,
+   const struct igt_drm_client *b)
+{
+   if (a->id > b->id)
+   return 1;
+   else if (a->id < b->id)
+   return -1;
+   else
+   return 0;
+}
+
+static int client_last_cmp(const void *_a, const void *_b, void *unused)
 {
const struct igt_drm_client *a = _a;
const struct igt_drm_client *b = _b;
-   long tot_a, tot_b;
+   long val_a = a->last_runtime, val_b = b->last_runtime;
 
/*
 * Sort clients in descending order of runtime in the previous sampling
-* period for active ones, followed by inactive. Tie-breaker is client
-* id.
+* period. Tie-breaker is client id.
 */
 
-   tot_a = a->status == IGT_DRM_CLIENT_ALIVE ? a->last_runtime : -1;
-   tot_b = b->status == IGT_DRM_CLIENT_ALIVE ? b->last_runtime : -1;
-
-   tot_b -= tot_a;
-   if (tot_b > 0)
+   if (val_a == val_b)
+   return __client_id_cmp(a, b);
+   else if (val_b > val_a)
return 1;
-   if (tot_b < 0)
+   else
return -1;
-
-   return (int)b->id - a->id;
 }
 
-static int client_total_cmp(const void *_a, const void *_b)
+static int client_total_cmp(const void *_a, const void *_b, void *unused)
 {
const struct igt_drm_clien

[Intel-gfx] [PATCH i-g-t 6/8] lib/igt_drm_clients: Decouple hardcoded engine assumptions

From: Tvrtko Ursulin 

Intel_gpu_top gets it's main engine configuration data via PMU probe and
uses that for per client view as well. Furthemore code so far assumed only
clients belonging from a single DRM card would be tracked in a single
clients list.

Break this inter-dependency by moving the engine data to be per client and
also have libdrmclient probe the engine configuration independently using
the previously added libdrmfdinfo facilities.

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_drm_clients.c |  38 +++--
 lib/igt_drm_clients.h |  14 ++---
 tools/intel_gpu_top.c | 127 +++---
 3 files changed, 134 insertions(+), 45 deletions(-)

diff --git a/lib/igt_drm_clients.c b/lib/igt_drm_clients.c
index e11c8b18188f..d507c07fec87 100644
--- a/lib/igt_drm_clients.c
+++ b/lib/igt_drm_clients.c
@@ -97,7 +97,7 @@ igt_drm_client_update(struct igt_drm_client *c, unsigned int 
pid, char *name,
c->last_runtime = 0;
c->total_runtime = 0;
 
-   for (i = 0; i < c->clients->num_classes; i++) {
+   for (i = 0; i <= c->engines->max_engine_id; i++) {
assert(i < ARRAY_SIZE(info->busy));
 
if (info->busy[i] < c->last[i])
@@ -119,6 +119,7 @@ igt_drm_client_add(struct igt_drm_clients *clients,
   unsigned int pid, char *name, unsigned int drm_minor)
 {
struct igt_drm_client *c;
+   unsigned int i;
 
assert(!igt_drm_clients_find(clients, IGT_DRM_CLIENT_ALIVE,
 drm_minor, info->id));
@@ -144,8 +145,28 @@ igt_drm_client_add(struct igt_drm_clients *clients,
c->id = info->id;
c->drm_minor = drm_minor;
c->clients = clients;
-   c->val = calloc(clients->num_classes, sizeof(c->val));
-   c->last = calloc(clients->num_classes, sizeof(c->last));
+   c->engines = malloc(sizeof(*c->engines));
+   assert(c->engines);
+   memset(c->engines, 0, sizeof(*c->engines));
+   c->engines->capacity = calloc(info->last_engine_index + 1,
+ sizeof(*c->engines->capacity));
+   assert(c->engines->capacity);
+   c->engines->names = calloc(info->last_engine_index + 1,
+  sizeof(*c->engines->names));
+   assert(c->engines->names);
+
+   for (i = 0; i <= info->last_engine_index; i++) {
+   if (!info->capacity[i])
+   continue;
+
+   c->engines->capacity[i] = info->capacity[i];
+   c->engines->names[i] = strdup(info->names[i]);
+   assert(c->engines->names[i]);
+   c->engines->num_engines++;
+   c->engines->max_engine_id = i;
+   }
+   c->val = calloc(c->engines->max_engine_id + 1, sizeof(c->val));
+   c->last = calloc(c->engines->max_engine_id + 1, sizeof(c->last));
assert(c->val && c->last);
 
igt_drm_client_update(c, pid, name, info);
@@ -154,6 +175,15 @@ igt_drm_client_add(struct igt_drm_clients *clients,
 static
 void igt_drm_client_free(struct igt_drm_client *c, bool clear)
 {
+   unsigned int i;
+
+   if (c->engines) {
+   for (i = 0; i <= c->engines->max_engine_id; i++)
+   free(c->engines->names[i]);
+   free(c->engines->capacity);
+   free(c->engines->names);
+   }
+   free(c->engines);
free(c->val);
free(c->last);
 
@@ -323,7 +353,7 @@ static bool is_drm_fd(int fd_dir, const char *name, 
unsigned int *minor)
  *
  * If @name_map is not provided engine names will be auto-detected (this is
  * less performant) and indices will correspond with auto-detected names as
- * listed int clients->engine_class[].
+ * listed int clients->engines->names[].
  */
 struct igt_drm_clients *
 igt_drm_clients_scan(struct igt_drm_clients *clients,
diff --git a/lib/igt_drm_clients.h b/lib/igt_drm_clients.h
index ffa219c9c9fd..0a903b431eaa 100644
--- a/lib/igt_drm_clients.h
+++ b/lib/igt_drm_clients.h
@@ -31,10 +31,12 @@ enum igt_drm_client_status {
IGT_DRM_CLIENT_PROBE
 };
 
-struct igt_drm_client_engine_class {
-   unsigned int engine_class;
-   const char *name;
-   unsigned int num_engines;
+struct igt_drm_client_engines {
+   unsigned int num_engines; /* Number of discovered active engines. */
+   unsigned int max_engine_id; /* Largest engine index discovered.
+  (Can differ from num_engines - 1 when 
using the engine map facility.) */
+   unsigned int *capacity; /* Array of engine capacities as parsed from 
fdinfo. */
+   char **names; /* Array of engine names, either auto-detected or from 
the passed in engine map. */
 };
 
 struct igt_drm_clients;
@@ -43,6 +45,7 @@ struct igt_drm_client {
struct igt_drm_clients *clients; /* Owning list. */
 
enum igt_drm_client_status status;
+   struct igt_drm_client_engines *engines; /* Engines used by this client, 
to map with busyn

[Intel-gfx] [PATCH i-g-t 8/8] gputop: Basic vendor agnostic GPU top tool

From: Tvrtko Ursulin 

Rudimentary vendor agnostic example of how lib_igt_drm_clients can be used
to display a sorted by card and usage list of processes using GPUs.

Borrows a bit of code from intel_gpu_top but for now omits the fancy
features like interactive functionality, card selection, client
aggregation, sort modes, JSON output  and pretty engine names. Also no
support for global GPU or system metrics.

On the other hand it shows clients from all DRM cards which
intel_gpu_top does not do.

Signed-off-by: Tvrtko Ursulin 
Cc: Rob Clark 
Cc: Christian König 
Acked-by: Christian König 
Reviewed-by: Rob Clark 
---
 tools/gputop.c| 260 ++
 tools/meson.build |   5 +
 2 files changed, 265 insertions(+)
 create mode 100644 tools/gputop.c

diff --git a/tools/gputop.c b/tools/gputop.c
new file mode 100644
index ..d259cac1ab17
--- /dev/null
+++ b/tools/gputop.c
@@ -0,0 +1,260 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "igt_drm_clients.h"
+#include "igt_drm_fdinfo.h"
+
+static const char *bars[] = { " ", "▏", "▎", "▍", "▌", "▋", "▊", "▉", "█" };
+
+static void n_spaces(const unsigned int n)
+{
+   unsigned int i;
+
+   for (i = 0; i < n; i++)
+   putchar(' ');
+}
+
+static void print_percentage_bar(double percent, int max_len)
+{
+   int bar_len, i, len = max_len - 2;
+   const int w = 8;
+
+   assert(max_len > 0);
+
+   bar_len = ceil(w * percent * len / 100.0);
+   if (bar_len > w * len)
+   bar_len = w * len;
+
+   putchar('|');
+
+   for (i = bar_len; i >= w; i -= w)
+   printf("%s", bars[w]);
+   if (i)
+   printf("%s", bars[i]);
+
+   len -= (bar_len + (w - 1)) / w;
+   n_spaces(len);
+
+   putchar('|');
+}
+
+static int
+print_client_header(struct igt_drm_client *c, int lines, int con_w, int con_h,
+   int *engine_w)
+{
+   const char *pidname = "PID   NAME ";
+   int ret, len = strlen(pidname);
+
+   if (lines++ >= con_h || len >= con_w)
+   return lines;
+   printf("\033[7m");
+   ret = printf("DRM minor %u", c->drm_minor);
+   n_spaces(con_w - ret);
+
+   if (lines++ >= con_h)
+   return lines;
+   printf("\n%s", pidname);
+
+   if (c->engines->num_engines) {
+   unsigned int i;
+   int width;
+
+   *engine_w = width = (con_w - len) / c->engines->num_engines;
+
+   for (i = 0; i <= c->engines->max_engine_id; i++) {
+   const char *name = c->engines->names[i];
+   int name_len = strlen(name);
+   int pad = (width - name_len) / 2;
+   int spaces = width - pad - name_len;
+
+   if (!name)
+   continue;
+
+   if (pad < 0 || spaces < 0)
+   continue;
+
+   n_spaces(pad);
+   printf("%s", name);
+   n_spaces(spaces);
+   len += pad + name_len + spaces;
+   }
+   }
+
+   n_spaces(con_w - len);
+   printf("\033[0m\n");
+
+   return lines;
+}
+
+
+static bool
+newheader(const struct igt_drm_client *c, const struct igt_drm_client *pc)
+{
+   return !pc || c->drm_minor != pc->drm_minor;
+}
+
+static int
+print_client(struct igt_drm_client *c, struct igt_drm_client **prevc,
+double t, int lines, int con_w, int con_h,
+unsigned int period_us, int *engine_w)
+{
+   unsigned int i;
+
+   /* Filter out idle clients. */
+   if (!c->total_runtime || c->samples < 2)
+   return lines;
+
+   /* Print header when moving to a different DRM card. */
+   if (newheader(c, *prevc)) {
+   lines = print_client_header(c, lines, con_w, con_h, engine_w);
+   if (lines >= con_h)
+   return lines;
+   }
+
+   *prevc = c;
+
+   printf("%8u %17s ", c->pid, c->print_name);
+   lines++;
+
+   for (i = 0; c->samples > 1 && i <= c->engines->max_engine_id; i++) {
+   double pct;
+
+   if (!c->engines->capacity[i])
+   continue;
+
+   pct = (double)c->val[i] / period_us / 1e3 * 100 /
+ c->engines->capacity[i];
+
+   /*
+* Guard against fluctuations between our scanning period and
+* GPU times as exported by the kernel in fdinfo.
+*/
+   if (pct > 100.0)
+   pct = 100.0;
+
+   print

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 8/8] gputop: Basic vendor agnostic GPU top tool

2023-04-06 Thread Rob Clark

On Thu, Apr 6, 2023 at 4:08 AM Tvrtko Ursulin
 wrote:
>
>
> On 05/04/2023 18:57, Rob Clark wrote:
> > On Tue, Jan 31, 2023 at 3:33 AM Tvrtko Ursulin
> >  wrote:
> >>
> >> From: Tvrtko Ursulin 
> >>
> >> Rudimentary vendor agnostic example of how lib_igt_drm_clients can be used
> >> to display a sorted by card and usage list of processes using GPUs.
> >>
> >> Borrows a bit of code from intel_gpu_top but for now omits the fancy
> >> features like interactive functionality, card selection, client
> >> aggregation, sort modes, JSON output  and pretty engine names. Also no
> >> support for global GPU or system metrics.
> >>
> >> On the other hand it shows clients from all DRM cards which
> >> intel_gpu_top does not do.
> >>
> >> Signed-off-by: Tvrtko Ursulin 
> >> Cc: Rob Clark 
> >> Cc: Christian König 
> >> Acked-by: Christian König 
> >
> > Reviewed-by: Rob Clark 
>
> Presumably for 8/8 only?
>
> The rest of the series does not apply any more by now. I need to rebase..

I didn't look closely at the rest of the series (was kinda assuming
that was mostly just moving things around).. but I see you rebased it
so I can take a look.

BR,
-R

> Regards,
>
> Tvrtko
>
> >
> >> ---
> >>   tools/gputop.c| 260 ++
> >>   tools/meson.build |   5 +
> >>   2 files changed, 265 insertions(+)
> >>   create mode 100644 tools/gputop.c
> >>
> >> diff --git a/tools/gputop.c b/tools/gputop.c
> >> new file mode 100644
> >> index ..d259cac1ab17
> >> --- /dev/null
> >> +++ b/tools/gputop.c
> >> @@ -0,0 +1,260 @@
> >> +// SPDX-License-Identifier: MIT
> >> +/*
> >> + * Copyright © 2022 Intel Corporation
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include "igt_drm_clients.h"
> >> +#include "igt_drm_fdinfo.h"
> >> +
> >> +static const char *bars[] = { " ", "▏", "▎", "▍", "▌", "▋", "▊", "▉", "█" 
> >> };
> >> +
> >> +static void n_spaces(const unsigned int n)
> >> +{
> >> +   unsigned int i;
> >> +
> >> +   for (i = 0; i < n; i++)
> >> +   putchar(' ');
> >> +}
> >> +
> >> +static void print_percentage_bar(double percent, int max_len)
> >> +{
> >> +   int bar_len, i, len = max_len - 2;
> >> +   const int w = 8;
> >> +
> >> +   assert(max_len > 0);
> >> +
> >> +   bar_len = ceil(w * percent * len / 100.0);
> >> +   if (bar_len > w * len)
> >> +   bar_len = w * len;
> >> +
> >> +   putchar('|');
> >> +
> >> +   for (i = bar_len; i >= w; i -= w)
> >> +   printf("%s", bars[w]);
> >> +   if (i)
> >> +   printf("%s", bars[i]);
> >> +
> >> +   len -= (bar_len + (w - 1)) / w;
> >> +   n_spaces(len);
> >> +
> >> +   putchar('|');
> >> +}
> >> +
> >> +static int
> >> +print_client_header(struct igt_drm_client *c, int lines, int con_w, int 
> >> con_h,
> >> +   int *engine_w)
> >> +{
> >> +   const char *pidname = "PID   NAME ";
> >> +   int ret, len = strlen(pidname);
> >> +
> >> +   if (lines++ >= con_h || len >= con_w)
> >> +   return lines;
> >> +   printf("\033[7m");
> >> +   ret = printf("DRM minor %u", c->drm_minor);
> >> +   n_spaces(con_w - ret);
> >> +
> >> +   if (lines++ >= con_h)
> >> +   return lines;
> >> +   printf("\n%s", pidname);
> >> +
> >> +   if (c->engines->num_engines) {
> >> +   unsigned int i;
> >> +   int width;
> >> +
> >> +   *engine_w = width = (con_w - len) / 
> >> c->engines->num_engines;
> >> +
> >> +   for (i = 0; i <= c->engines->max_engine_id; i++) {
> >> +   const char *name = c->engines->names[i];
> >> +   int name_len = strlen(name);
> >> +   int pad = (width - name_len) / 2;
> >> +   int spaces = width - pad - name_len;
> >> +
> >> +   if (!name)
> >> +   continue;
> >> +
> >> +   if (pad < 0 || spaces < 0)
> >> +   continue;
> >> +
> >> +   n_spaces(pad);
> >> +   printf("%s", name);
> >> +   n_spaces(spaces);
> >> +   len += pad + name_len + spaces;
> >> +   }
> >> +   }
> >> +
> >> +   n_spaces(con_w - len);
> >> +   printf("\033[0m\n");
> >> +
> >> +   return lines;
> >> +}
> >> +
> >> +
> >> +static bool
> >> +newheader(const struct igt_drm_client *c, const struct igt_drm_client *pc)
> >> +{
> >> +   return !pc || c->drm_minor != pc->drm_minor;
> >> +}
> >> +
> >> +static int
> >> +print_client(s

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 8/8] gputop: Basic vendor agnostic GPU top tool




On 06/04/2023 15:21, Rob Clark wrote:

On Thu, Apr 6, 2023 at 4:08 AM Tvrtko Ursulin
 wrote:



On 05/04/2023 18:57, Rob Clark wrote:

On Tue, Jan 31, 2023 at 3:33 AM Tvrtko Ursulin
 wrote:


From: Tvrtko Ursulin 

Rudimentary vendor agnostic example of how lib_igt_drm_clients can be used
to display a sorted by card and usage list of processes using GPUs.

Borrows a bit of code from intel_gpu_top but for now omits the fancy
features like interactive functionality, card selection, client
aggregation, sort modes, JSON output  and pretty engine names. Also no
support for global GPU or system metrics.

On the other hand it shows clients from all DRM cards which
intel_gpu_top does not do.

Signed-off-by: Tvrtko Ursulin 
Cc: Rob Clark 
Cc: Christian König 
Acked-by: Christian König 


Reviewed-by: Rob Clark 


Presumably for 8/8 only?

The rest of the series does not apply any more by now. I need to rebase..


I didn't look closely at the rest of the series (was kinda assuming
that was mostly just moving things around).. but I see you rebased it
so I can take a look.


There's a lot in there - first patch is extracting some code into a 
library, with the corresponding renames, but then there are six patches 
of tweaks and feature additions which finally make gputop possible.


Hopefully you can penetrate the concepts. It was all at least Valgrind 
clean back in the day I first did it.


Regards,

Tvrtko

[Intel-gfx] [PATCH v2 rebased 2/6] drm/i915: Initialize dkl_phy spin lock from display code path

2023-04-06 Thread José Roberto de Souza

Start to move the initialization of some lock from
i915_driver_early_probe().
This will also fix a warning in Xe kmd:

[  201.894839] xe :00:02.0: [drm] [ENCODER:235:DDI A/PHY A] failed to 
retrieve link info, disabling eDP
[  202.136336] xe :00:02.0: [drm] *ERROR* Failed to write source OUI
[  202.175346] INFO: trying to register non-static key.
[  202.175347] irq event stamp: 754060
[  202.175359] hardirqs last  enabled at (754059): [] 
tick_nohz_idle_enter+0x59/0x80
[  202.180294] The code is fine but needs lockdep annotation, or maybe
[  202.183774] hardirqs last disabled at (754060): [] 
do_idle+0x99/0x230
[  202.192734] you didn't initialize this object before use?
[  202.198951] softirqs last  enabled at (753948): [] 
irq_exit_rcu+0xbe/0x130
[  202.206882] turning off the locking correctness validator.
[  202.212236] softirqs last disabled at (753943): [] 
irq_exit_rcu+0xbe/0x130
[  202.220592] CPU: 2 PID: 1415 Comm: modprobe Tainted: GW  
6.3.0-rc4+zeh-xe+ #909
[  202.243002] Hardware name: Intel Corporation Raptor Lake Client 
Platform/RaptorLake-P LP5 RVP, BIOS RPLPFWI1.R00.3361.A14.2211151548 11/15/2022
[  202.255737] Call Trace:
[  202.258179]  
[  202.260275]  dump_stack_lvl+0x58/0xc0
[  202.263922]  register_lock_class+0x756/0x7d0
[  202.268165]  ? find_held_lock+0x2b/0x80
[  202.271975]  __lock_acquire+0x72/0x28b0
[  202.275786]  ? debug_object_free+0xb4/0x160
[  202.279946]  lock_acquire+0xd1/0x2d0
[  202.283503]  ? intel_dkl_phy_read+0x18/0x60 [xe]
[  202.288181]  _raw_spin_lock+0x2a/0x40
[  202.291825]  ? intel_dkl_phy_read+0x18/0x60 [xe]
[  202.296475]  intel_dkl_phy_read+0x18/0x60 [xe]
[  202.300949]  icl_aux_power_well_enable+0x2bd/0x400 [xe]
[  202.306202]  ? intel_display_power_grab_async_put_ref+0x75/0x120 [xe]
[  202.312649]  intel_power_well_enable+0x1c/0x70 [xe]
[  202.317543]  __intel_display_power_get_domain.part.0+0x4d/0x70 [xe]
[  202.323812]  intel_display_power_get+0x43/0x70 [xe]
[  202.328708]  intel_tc_port_init+0x199/0x2a0 [xe]
[  202.63]  intel_ddi_init+0x6ad/0xb00 [xe]
[  202.337678]  intel_modeset_init_nogem+0x536/0x6d0 [xe]
[  202.342838]  xe_display_init_noaccel+0x19/0x40 [xe]
[  202.347743]  xe_device_probe+0x1f5/0x2a0 [xe]
[  202.352127]  xe_pci_probe+0x28c/0x480 [xe]
[  202.356260]  pci_device_probe+0x9d/0x150
[  202.360164]  really_probe+0x19a/0x400
[  202.363809]  ? __pfx___driver_attach+0x10/0x10
[  202.368226]  __driver_probe_device+0x73/0x170
[  202.372558]  driver_probe_device+0x1a/0x90
[  202.376632]  __driver_attach+0xcd/0x1c0
[  202.380442]  bus_for_each_dev+0x72/0xc0
[  202.384253]  bus_add_driver+0x110/0x210
[  202.388063]  driver_register+0x50/0x100
[  202.391873]  ? __pfx_init_module+0x10/0x10 [xe]
[  202.396431]  do_one_initcall+0x55/0x260
[  202.400245]  ? rcu_is_watching+0xd/0x40
[  202.404058]  ? kmalloc_trace+0xa0/0xb0
[  202.407786]  do_init_module+0x45/0x1e0
[  202.411512]  __do_sys_finit_module+0xac/0x120
[  202.415838]  do_syscall_64+0x37/0x90
[  202.419397]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
[  202.424409] RIP: 0033:0x7fd11291ea3d
[  202.427967] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d c3 a3 0f 00 f7 d8 64 89 01 48
[  202.446530] RSP: 002b:7de11368 EFLAGS: 0246 ORIG_RAX: 
0139
[  202.454031] RAX: ffda RBX: 5616a617f210 RCX: 7fd11291ea3d
[  202.461106] RDX:  RSI: 5616a617fe60 RDI: 000e
[  202.468182] RBP: 0004 R08:  R09: 0002
[  202.475250] R10: 000e R11: 0246 R12: 5616a617fe60
[  202.482319] R13: 5616a617f340 R14:  R15: 5616a6180650
[  202.489396]  

Cc: intel-gfx@lists.freedesktop.org
Cc: Rodrigo Vivi 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_display.c | 3 +++
 drivers/gpu/drm/i915/display/intel_dkl_phy.c | 6 ++
 drivers/gpu/drm/i915/display/intel_dkl_phy.h | 2 ++
 drivers/gpu/drm/i915/i915_driver.c   | 1 -
 4 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 2d59330ff5abd..92e1b535b2798 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -85,6 +85,7 @@
 #include "intel_display_debugfs.h"
 #include "intel_display_power.h"
 #include "intel_display_types.h"
+#include "intel_dkl_phy.h"
 #include "intel_dmc.h"
 #include "intel_dp.h"
 #include "intel_dp_link_training.h"
@@ -7890,6 +7891,8 @@ static void intel_setup_outputs(struct drm_i915_private 
*dev_priv)
if (!HAS_DISPLAY(dev_priv))
return;
 
+   intel_dkl_phy_init(dev_priv);
+
if (IS_DG2(dev_priv)) {
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
diff --git a/d

[Intel-gfx] [PATCH v2 rebased 3/6] drm/i915: Only initialize dlk phy lock in display 12 and newer

2023-04-06 Thread José Roberto de Souza

This spin lock will not be used in older display versions, so no need
to initialize it.

Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_dkl_phy.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dkl_phy.c 
b/drivers/gpu/drm/i915/display/intel_dkl_phy.c
index 5bce7b5b27bc7..1c5d410b74e5d 100644
--- a/drivers/gpu/drm/i915/display/intel_dkl_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_dkl_phy.c
@@ -108,5 +108,6 @@ intel_dkl_phy_posting_read(struct drm_i915_private *i915, 
struct intel_dkl_phy_r
 void
 intel_dkl_phy_init(struct drm_i915_private *i915)
 {
-   spin_lock_init(&i915->display.dkl.phy_lock);
+   if (DISPLAY_VER(i915) >= 12)
+   spin_lock_init(&i915->display.dkl.phy_lock);
 }
-- 
2.40.0

[Intel-gfx] [PATCH v2 rebased 1/6] drm/i915: Nuke unused dsparb_lock

2023-04-06 Thread José Roberto de Souza

dsparb_lock it not used anymore, nuke it.

Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_display_core.h | 3 ---
 drivers/gpu/drm/i915/i915_driver.c| 1 -
 2 files changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index cc058eb303ee8..d2346d43d1162 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -266,9 +266,6 @@ struct intel_wm {
 */
struct mutex wm_mutex;
 
-   /* protects DSPARB registers on pre-g4x/vlv/chv */
-   spinlock_t dsparb_lock;
-
bool ipc_enabled;
 };
 
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index 066d79c2069c4..ea2cc56d18a6e 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -214,7 +214,6 @@ static int i915_driver_early_probe(struct drm_i915_private 
*dev_priv)
spin_lock_init(&dev_priv->irq_lock);
spin_lock_init(&dev_priv->gpu_error.lock);
spin_lock_init(&dev_priv->display.fb_tracking.lock);
-   spin_lock_init(&dev_priv->display.wm.dsparb_lock);
mutex_init(&dev_priv->display.backlight.lock);
 
mutex_init(&dev_priv->sb_lock);
-- 
2.40.0

Re: [Intel-gfx] [PATCH 1/7] drm/i915/mtl: Define MOCS and PAT tables for MTL

2023-04-06 Thread Yang, Fei

> On 4/1/2023 8:38 AM, fei.y...@intel.com wrote:
>> From: Fei Yang 
>>
>> On MTL, GT can no longer allocate on LLC - only the CPU can.
>> This, along with addition of support for ADM/L4 cache calls a
>> MOCS/PAT table update.
>> Also add PTE encode functions for MTL as it has different PAT
>> index definition than previous platforms.
>>
>> BSpec: 44509, 45101, 44235
>>
>> Cc: Matt Roper 
>> Cc: Lucas De Marchi 
>> Signed-off-by: Madhumitha Tolakanahalli Pradeep 
>> 
>> Signed-off-by: Aravind Iddamsetty 
>> Signed-off-by: Fei Yang 
>> ---
>>   drivers/gpu/drm/i915/display/intel_dpt.c |  2 +-
>>   drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 43 --
>>   drivers/gpu/drm/i915/gt/gen8_ppgtt.h |  3 +
>>   drivers/gpu/drm/i915/gt/intel_ggtt.c | 36 ++-
>>   drivers/gpu/drm/i915/gt/intel_gtt.c  | 23 ++-
>>   drivers/gpu/drm/i915/gt/intel_gtt.h  | 20 ++-
>>   drivers/gpu/drm/i915/gt/intel_mocs.c | 76 ++--
>>   drivers/gpu/drm/i915/gt/selftest_mocs.c  |  2 +-
>>   drivers/gpu/drm/i915/i915_pci.c  |  1 +
>>   9 files changed, 189 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
>> b/drivers/gpu/drm/i915/display/intel_dpt.c
>> index b8027392144d..c5eacfdba1a5 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
>> @@ -300,7 +300,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
>>vm->vma_ops.bind_vma= dpt_bind_vma;
>>vm->vma_ops.unbind_vma  = dpt_unbind_vma;
>>
>> - vm->pte_encode = gen8_ggtt_pte_encode;
>> + vm->pte_encode = vm->gt->ggtt->vm.pte_encode;
>>
>>dpt->obj = dpt_obj;
>>dpt->obj->is_dpt = true;
>> diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
>> b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
>> index 4daaa6f55668..4197b43150cc 100644
>> --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
>> +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
>> @@ -55,6 +55,34 @@ static u64 gen8_pte_encode(dma_addr_t addr,
>>return pte;
>>   }
>>
>> +static u64 mtl_pte_encode(dma_addr_t addr,
>> +   enum i915_cache_level level,
>> +   u32 flags)
>> +{
>> + gen8_pte_t pte = addr | GEN8_PAGE_PRESENT | GEN8_PAGE_RW;
>> +
>> + if (unlikely(flags & PTE_READ_ONLY))
>> + pte &= ~GEN8_PAGE_RW;
>> +
>> + if (flags & PTE_LM)
>> + pte |= GEN12_PPGTT_PTE_LM | GEN12_PPGTT_PTE_NC;
>> +
>> + switch (level) {
>> + case I915_CACHE_NONE:
>> + pte |= GEN12_PPGTT_PTE_PAT1;
>> + break;
>> + case I915_CACHE_LLC:
>> + case I915_CACHE_L3_LLC:
>> + pte |= GEN12_PPGTT_PTE_PAT0 | GEN12_PPGTT_PTE_PAT1;
>> + break;
>> + case I915_CACHE_WT:
>> + pte |= GEN12_PPGTT_PTE_PAT0;
>> + break;
>> + }
>> +
>> + return pte;
>> +}
>> +
>>   static void gen8_ppgtt_notify_vgt(struct i915_ppgtt *ppgtt, bool create)
>>   {
>>struct drm_i915_private *i915 = ppgtt->vm.i915;
>> @@ -427,7 +455,7 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
>>  u32 flags)
>>   {
>>struct i915_page_directory *pd;
>> - const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
>> + const gen8_pte_t pte_encode = ppgtt->vm.pte_encode(0, cache_level, 
>> flags);
>>gen8_pte_t *vaddr;
>>
>>pd = i915_pd_entry(pdp, gen8_pd_index(idx, 2));
>> @@ -580,7 +608,7 @@ static void gen8_ppgtt_insert_huge(struct 
>> i915_address_space *vm,
>>   enum i915_cache_level cache_level,
>>   u32 flags)
>>   {
>> - const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
>> + const gen8_pte_t pte_encode = vm->pte_encode(0, cache_level, flags);
>>unsigned int rem = sg_dma_len(iter->sg);
>>u64 start = vma_res->start;
>>
>> @@ -743,7 +771,7 @@ static void gen8_ppgtt_insert_entry(struct 
>> i915_address_space *vm,
>>GEM_BUG_ON(pt->is_compact);
>>
>>vaddr = px_vaddr(pt);
>> - vaddr[gen8_pd_index(idx, 0)] = gen8_pte_encode(addr, level, flags);
>> + vaddr[gen8_pd_index(idx, 0)] = vm->pte_encode(addr, level, flags);
>>drm_clflush_virt_range(&vaddr[gen8_pd_index(idx, 0)], sizeof(*vaddr));
>>   }
>>
>> @@ -773,7 +801,7 @@ static void __xehpsdv_ppgtt_insert_entry_lm(struct 
>> i915_address_space *vm,
>>}
>>
>>vaddr = px_vaddr(pt);
>> - vaddr[gen8_pd_index(idx, 0) / 16] = gen8_pte_encode(addr, level, 
>> flags);
>> + vaddr[gen8_pd_index(idx, 0) / 16] = vm->pte_encode(addr, level, flags);
>>   }
>>
>>   static void xehpsdv_ppgtt_insert_entry(struct i915_address_space *vm,
>> @@ -820,7 +848,7 @@ static int gen8_init_scratch(struct i915_address_space 
>> *vm)
>>pte_flags |= PTE_LM;
>>
>>vm->scratch[0]->encode =
>> - gen8_pte_encode(px_dma(vm->scratch[0]),
>> + vm->pte_encode(px_dma(vm

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/mtl: Add Support for C10 phy

== Series Details ==

Series: drm/i915/mtl: Add Support for C10 phy
URL   : https://patchwork.freedesktop.org/series/116191/
State : warning

== Summary ==

Error: dim checkpatch failed
09ec7a640ab5 drm/i915/mtl: Initial DDI port setup
581165ce249c drm/i915/mtl: Add DP rates
bee5f7f012de drm/i915/mtl: Create separate reg file for PICA registers
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:19: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#19: 
new file mode 100644

-:39: WARNING:LONG_LINE: line length of 117 exceeds 100 columns
#39: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:16:
+   
 _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A, \

-:40: WARNING:LONG_LINE: line length of 117 exceeds 100 columns
#40: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:17:
+   
 _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B, \

-:41: WARNING:LONG_LINE: line length of 121 exceeds 100 columns
#41: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:18:
+   
 _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1, \

-:42: WARNING:LONG_LINE: line length of 133 exceeds 100 columns
#42: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:19:
+   
 _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2) + (lane) * 4)

-:45: WARNING:LONG_LINE: line length of 110 exceeds 100 columns
#45: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:22:
+#define   XELPDP_PORT_M2P_COMMAND_WRITE_UNCOMMITTED
REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x1)

-:46: WARNING:LONG_LINE: line length of 110 exceeds 100 columns
#46: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:23:
+#define   XELPDP_PORT_M2P_COMMAND_WRITE_COMMITTED  
REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x2)

-:47: WARNING:LONG_LINE: line length of 110 exceeds 100 columns
#47: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:24:
+#define   XELPDP_PORT_M2P_COMMAND_READ 
REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x3)

-:49: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#49: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:26:
+#define   XELPDP_PORT_M2P_DATA(val)
REG_FIELD_PREP(XELPDP_PORT_M2P_DATA_MASK, val)

-:52: WARNING:LONG_LINE: line length of 105 exceeds 100 columns
#52: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:29:
+#define   XELPDP_PORT_M2P_ADDRESS(val) 
REG_FIELD_PREP(XELPDP_PORT_M2P_ADDRESS_MASK, val)

-:54: WARNING:LONG_LINE: line length of 117 exceeds 100 columns
#54: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:31:
+   
 _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A, \

-:55: WARNING:LONG_LINE: line length of 117 exceeds 100 columns
#55: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:32:
+   
 _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B, \

-:56: WARNING:LONG_LINE: line length of 121 exceeds 100 columns
#56: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:33:
+   
 _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1, \

-:57: WARNING:LONG_LINE: line length of 137 exceeds 100 columns
#57: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:34:
+   
 _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2) + (lane) * 4 + 8)

-:63: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#63: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:40:
+#define   XELPDP_PORT_P2M_DATA(val)
REG_FIELD_PREP(XELPDP_PORT_P2M_DATA_MASK, val)

-:81: WARNING:LONG_LINE: line length of 111 exceeds 100 columns
#81: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:58:
+   
 _XELPDP_PORT_BUF_CTL1_LN0_A, \

-:82: WARNING:LONG_LINE: line length of 111 exceeds 100 columns
#82: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:59:
+   
 _XELPDP_PORT_BUF_CTL1_LN0_B, \

-:83: WARNING:LONG_LINE: line length of 115 exceeds 100 columns
#83: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:60:
+   
 _XELPDP_PORT_BUF_CTL1_LN0_USBC1, \

-:84: WARNING:LONG_LINE: line length of 114 exceeds 100 columns
#84: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:61:
+

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: Add Support for C10 phy

== Series Details ==

Series: drm/i915/mtl: Add Support for C10 phy
URL   : https://patchwork.freedesktop.org/series/116191/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Add Support for C10 phy

== Series Details ==

Series: drm/i915/mtl: Add Support for C10 phy
URL   : https://patchwork.freedesktop.org/series/116191/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12981 -> Patchwork_116191v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116191v1/index.html

Participating hosts (36 -> 35)
--

  Missing(1): fi-snb-2520m 

Known issues


  Here are the changes found in Patchwork_116191v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@gt_lrc:
- bat-rpls-1: [PASS][1] -> [INCOMPLETE][2] ([i915#4983])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12981/bat-rpls-1/igt@i915_selftest@live@gt_lrc.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116191v1/bat-rpls-1/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@migrate:
- bat-adlp-6: [PASS][3] -> [DMESG-FAIL][4] ([i915#7699])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12981/bat-adlp-6/igt@i915_selftest@l...@migrate.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116191v1/bat-adlp-6/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@requests:
- bat-dg2-11: [PASS][5] -> [ABORT][6] ([i915#7913])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12981/bat-dg2-11/igt@i915_selftest@l...@requests.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116191v1/bat-dg2-11/igt@i915_selftest@l...@requests.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-rpls-2: [PASS][7] -> [ABORT][8] ([i915#6687] / [i915#7978])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12981/bat-rpls-2/igt@i915_susp...@basic-s3-without-i915.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116191v1/bat-rpls-2/igt@i915_susp...@basic-s3-without-i915.html

  
 Possible fixes 

  * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1:
- bat-dg2-8:  [FAIL][9] ([i915#7932]) -> [PASS][10] +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12981/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116191v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html

  
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
  [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
  [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978


Build changes
-

  * Linux: CI_DRM_12981 -> Patchwork_116191v1

  CI-20190529: 20190529
  CI_DRM_12981: fbadfcf137737f02425a35bf3ae17a1492301f21 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7243: 402a13477510ab05591839a2bf4586de1158e60c @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_116191v1: fbadfcf137737f02425a35bf3ae17a1492301f21 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

a15c718028e0 drm/i915/mtl/display: Implement DisplayPort sequences
48b0cc7a9a8b drm/i915/display/mtl: Fill port width in 
DDI_BUF_/TRANS_DDI_FUNC_/PORT_BUF_CTL for HDMI
ca934de751cf drm/i915/mtl: MTL PICA hotplug detection
bbdd82623c34 drm/i915/mtl: Add vswing programming for C10 phys
6617faaafef5 drm/i915/mtl: Add Support for C10 PHY message bus and pll 
programming
171d18b5f6d4 drm/i915/mtl: Create separate reg file for PICA registers
3d050f4cc78c drm/i915/mtl: Add DP rates
c1ba98e27739 drm/i915/mtl: Initial DDI port setup

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116191v1/index.html

[Intel-gfx] [PATCH v2 0/7] Move dma-buf mmap() reservation locking down to exporters

This patchset makes dma-buf exporters responisble for taking care of
the reservation lock. I also included patch that moves drm-shmem to use
reservation lock, to let CI test the whole set. I'm going to take all
the patches via the drm-misc tree, please give an ack.

Previous policy stated that dma-buf core takes the lock around mmap()
callback. Which meant that both importers and exporters shouldn't touch
the reservation lock in the mmap() code path. This worked well until
Intel-CI found a deadlock problem in a case of self-imported dma-buf [1].

The problem happens when userpace mmaps a self-imported dma-buf, i.e.
mmaps the dma-buf FD. DRM core treats self-imported dma-bufs as own GEMs
[2]. There is no way to differentiate a prime GEM from a normal GEM for
drm-shmem in drm_gem_shmem_mmap(), which resulted in a deadlock problem
for drm-shmem mmap() code path once it's switched to use reservation lock.

It was difficult to fix the drm-shmem problem without adjusting dma-buf
locking policy. In parctice not much changed from importers perspective
because previosly dma-buf was taking the lock in between of importers
and exporters. Now this lock is shifted down to exporters.

[1]
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114671v2/shard-snb5/igt@prime_vgem@s...@rcs0.html
[2]
https://elixir.bootlin.com/linux/v6.3-rc4/source/drivers/gpu/drm/drm_prime.c#L924

Changelog:

v2: - Added ack from Christian König to the DRM patch.

- Dropped "fixes" tag from the patches, like was requested by
Christian König. The patches don't actually need a backport
and merely improve the locking policy.

- Dropped "reverts" from the patch titles to prevent them from
auto-backporting by the stable bot based on the title.

- Added r-b from Emil Velikov and placed the drm_WARN in the
drm-shmem patch like he suggested in a comment to v1.

- Corrected drm-shmem patch dma_resv_lock(obj->resv) inconsistently
used with dma_resv_unlock(shmem->base.resv). Now shmem->base.resv
variant is used for all locks/unlocks.

Dmitry Osipenko (7):
media: videobuf2: Don't assert held reservation lock for dma-buf
mmapping
dma-buf/heaps: Don't assert held reservation lock for dma-buf mmapping
udmabuf: Don't assert held reservation lock for dma-buf mmapping
fastrpc: Don't assert held reservation lock for dma-buf mmapping
drm: Don't assert held reservation lock for dma-buf mmapping
dma-buf: Change locking policy for mmap()
drm/shmem-helper: Switch to reservation lock

--
2.39.2

[Intel-gfx] [PATCH v2 1/7] media: videobuf2: Don't assert held reservation lock for dma-buf mmapping

Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.

We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
drivers are moved to use reservation lock universally. The problem is
solved by moving the lock down to exporters. This patch prepares videobuf2
for the locking policy update.

Reviewed-by: Emil Velikov 
Signed-off-by: Dmitry Osipenko 
---
 drivers/media/common/videobuf2/videobuf2-dma-contig.c | 3 ---
 drivers/media/common/videobuf2/videobuf2-dma-sg.c | 3 ---
 drivers/media/common/videobuf2/videobuf2-vmalloc.c| 3 ---
 3 files changed, 9 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c 
b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index 205d3cac425c..2fa455d4a048 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -11,7 +11,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -456,8 +455,6 @@ static int vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf, 
struct iosys_map *map)
 static int vb2_dc_dmabuf_ops_mmap(struct dma_buf *dbuf,
struct vm_area_struct *vma)
 {
-   dma_resv_assert_held(dbuf->resv);
-
return vb2_dc_mmap(dbuf->priv, vma);
 }
 
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c 
b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index 183037fb1273..28f3fdfe23a2 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -10,7 +10,6 @@
  * the Free Software Foundation.
  */
 
-#include 
 #include 
 #include 
 #include 
@@ -498,8 +497,6 @@ static int vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf,
 static int vb2_dma_sg_dmabuf_ops_mmap(struct dma_buf *dbuf,
struct vm_area_struct *vma)
 {
-   dma_resv_assert_held(dbuf->resv);
-
return vb2_dma_sg_mmap(dbuf->priv, vma);
 }
 
diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c 
b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
index a6c6d2fcaaa4..7c635e292106 100644
--- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
+++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
@@ -10,7 +10,6 @@
  * the Free Software Foundation.
  */
 
-#include 
 #include 
 #include 
 #include 
@@ -319,8 +318,6 @@ static int vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf,
 static int vb2_vmalloc_dmabuf_ops_mmap(struct dma_buf *dbuf,
struct vm_area_struct *vma)
 {
-   dma_resv_assert_held(dbuf->resv);
-
return vb2_vmalloc_mmap(dbuf->priv, vma);
 }
 
-- 
2.39.2

[Intel-gfx] [PATCH v2 3/7] udmabuf: Don't assert held reservation lock for dma-buf mmapping

Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.

We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
drivers are moved to use reservation lock universally. The problem is
solved by moving the lock down to exporters. This patch prepares udmabuf
for the locking policy update.

Reviewed-by: Emil Velikov 
Signed-off-by: Dmitry Osipenko 
---
 drivers/dma-buf/udmabuf.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 740d6e426ee9..277f1afa9552 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -52,8 +52,6 @@ static int mmap_udmabuf(struct dma_buf *buf, struct 
vm_area_struct *vma)
 {
struct udmabuf *ubuf = buf->priv;
 
-   dma_resv_assert_held(buf->resv);
-
if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0)
return -EINVAL;
 
-- 
2.39.2

[Intel-gfx] [PATCH v2 4/7] fastrpc: Don't assert held reservation lock for dma-buf mmapping

Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.

We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
drivers are moved to use reservation lock universally. The problem is
solved by moving the lock down to exporters. This patch prepares fastrpc
for the locking policy update.

Reviewed-by: Emil Velikov 
Signed-off-by: Dmitry Osipenko 
---
 drivers/misc/fastrpc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index a701132638cf..7e9c9ad37fd9 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -6,7 +6,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -733,8 +732,6 @@ static int fastrpc_mmap(struct dma_buf *dmabuf,
struct fastrpc_buf *buf = dmabuf->priv;
size_t size = vma->vm_end - vma->vm_start;
 
-   dma_resv_assert_held(dmabuf->resv);
-
return dma_mmap_coherent(buf->dev, vma, buf->virt,
 FASTRPC_PHYS(buf->phys), size);
 }
-- 
2.39.2

[Intel-gfx] [PATCH v2 5/7] drm: Don't assert held reservation lock for dma-buf mmapping

Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.

We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
drivers are moved to use reservation lock universally. The problem is
solved by moving the lock down to exporters. This patch prepares DRM
drivers for the locking policy update.

Reviewed-by: Emil Velikov 
Acked-by: Christian König 
Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/drm_prime.c| 2 --
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 --
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  | 2 --
 drivers/gpu/drm/tegra/gem.c| 2 --
 4 files changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 149cd4ff6a3b..cea85e84666f 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -781,8 +781,6 @@ int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct 
vm_area_struct *vma)
struct drm_gem_object *obj = dma_buf->priv;
struct drm_device *dev = obj->dev;
 
-   dma_resv_assert_held(dma_buf->resv);
-
if (!dev->driver->gem_prime_mmap)
return -ENOSYS;
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index fd556a076d05..1df74f7aa3dc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -97,8 +97,6 @@ static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, 
struct vm_area_struct *
struct drm_i915_private *i915 = to_i915(obj->base.dev);
int ret;
 
-   dma_resv_assert_held(dma_buf->resv);
-
if (obj->base.size < vma->vm_end - vma->vm_start)
return -EINVAL;
 
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c 
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index 3abc47521b2c..8e194dbc9506 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -66,8 +66,6 @@ static int omap_gem_dmabuf_mmap(struct dma_buf *buffer,
struct drm_gem_object *obj = buffer->priv;
int ret = 0;
 
-   dma_resv_assert_held(buffer->resv);
-
ret = drm_gem_mmap_obj(obj, omap_gem_mmap_size(obj), vma);
if (ret < 0)
return ret;
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index bce991a2ccc0..871ef5d26523 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -693,8 +693,6 @@ static int tegra_gem_prime_mmap(struct dma_buf *buf, struct 
vm_area_struct *vma)
struct drm_gem_object *gem = buf->priv;
int err;
 
-   dma_resv_assert_held(buf->resv);
-
err = drm_gem_mmap_obj(gem, gem->size, vma);
if (err < 0)
return err;
-- 
2.39.2

[Intel-gfx] [PATCH v2 7/7] drm/shmem-helper: Switch to reservation lock

Replace all drm-shmem locks with a GEM reservation lock. This makes locks
consistent with dma-buf locking convention where importers are responsible
for holding reservation lock for all operations performed over dma-bufs,
preventing deadlock between dma-buf importers and exporters.

Suggested-by: Daniel Vetter 
Acked-by: Thomas Zimmermann 
Reviewed-by: Emil Velikov 
Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/drm_gem_shmem_helper.c| 208 --
 drivers/gpu/drm/lima/lima_gem.c   |   8 +-
 drivers/gpu/drm/panfrost/panfrost_drv.c   |   7 +-
 .../gpu/drm/panfrost/panfrost_gem_shrinker.c  |   6 +-
 drivers/gpu/drm/panfrost/panfrost_mmu.c   |  19 +-
 include/drm/drm_gem_shmem_helper.h|  14 +-
 6 files changed, 114 insertions(+), 148 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 4ea6507a77e5..395942ca36fe 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -88,8 +88,6 @@ __drm_gem_shmem_create(struct drm_device *dev, size_t size, 
bool private)
if (ret)
goto err_release;
 
-   mutex_init(&shmem->pages_lock);
-   mutex_init(&shmem->vmap_lock);
INIT_LIST_HEAD(&shmem->madv_list);
 
if (!private) {
@@ -141,11 +139,13 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object 
*shmem)
 {
struct drm_gem_object *obj = &shmem->base;
 
-   drm_WARN_ON(obj->dev, shmem->vmap_use_count);
-
if (obj->import_attach) {
drm_prime_gem_destroy(obj, shmem->sgt);
} else {
+   dma_resv_lock(shmem->base.resv, NULL);
+
+   drm_WARN_ON(obj->dev, shmem->vmap_use_count);
+
if (shmem->sgt) {
dma_unmap_sgtable(obj->dev->dev, shmem->sgt,
  DMA_BIDIRECTIONAL, 0);
@@ -154,18 +154,18 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object 
*shmem)
}
if (shmem->pages)
drm_gem_shmem_put_pages(shmem);
-   }
 
-   drm_WARN_ON(obj->dev, shmem->pages_use_count);
+   drm_WARN_ON(obj->dev, shmem->pages_use_count);
+
+   dma_resv_unlock(shmem->base.resv);
+   }
 
drm_gem_object_release(obj);
-   mutex_destroy(&shmem->pages_lock);
-   mutex_destroy(&shmem->vmap_lock);
kfree(shmem);
 }
 EXPORT_SYMBOL_GPL(drm_gem_shmem_free);
 
-static int drm_gem_shmem_get_pages_locked(struct drm_gem_shmem_object *shmem)
+static int drm_gem_shmem_get_pages(struct drm_gem_shmem_object *shmem)
 {
struct drm_gem_object *obj = &shmem->base;
struct page **pages;
@@ -197,35 +197,16 @@ static int drm_gem_shmem_get_pages_locked(struct 
drm_gem_shmem_object *shmem)
 }
 
 /*
- * drm_gem_shmem_get_pages - Allocate backing pages for a shmem GEM object
+ * drm_gem_shmem_put_pages - Decrease use count on the backing pages for a 
shmem GEM object
  * @shmem: shmem GEM object
  *
- * This function makes sure that backing pages exists for the shmem GEM object
- * and increases the use count.
- *
- * Returns:
- * 0 on success or a negative error code on failure.
+ * This function decreases the use count and puts the backing pages when use 
drops to zero.
  */
-int drm_gem_shmem_get_pages(struct drm_gem_shmem_object *shmem)
+void drm_gem_shmem_put_pages(struct drm_gem_shmem_object *shmem)
 {
struct drm_gem_object *obj = &shmem->base;
-   int ret;
-
-   drm_WARN_ON(obj->dev, obj->import_attach);
-
-   ret = mutex_lock_interruptible(&shmem->pages_lock);
-   if (ret)
-   return ret;
-   ret = drm_gem_shmem_get_pages_locked(shmem);
-   mutex_unlock(&shmem->pages_lock);
-
-   return ret;
-}
-EXPORT_SYMBOL(drm_gem_shmem_get_pages);
 
-static void drm_gem_shmem_put_pages_locked(struct drm_gem_shmem_object *shmem)
-{
-   struct drm_gem_object *obj = &shmem->base;
+   dma_resv_assert_held(shmem->base.resv);
 
if (drm_WARN_ON_ONCE(obj->dev, !shmem->pages_use_count))
return;
@@ -243,20 +224,25 @@ static void drm_gem_shmem_put_pages_locked(struct 
drm_gem_shmem_object *shmem)
  shmem->pages_mark_accessed_on_put);
shmem->pages = NULL;
 }
+EXPORT_SYMBOL(drm_gem_shmem_put_pages);
 
-/*
- * drm_gem_shmem_put_pages - Decrease use count on the backing pages for a 
shmem GEM object
- * @shmem: shmem GEM object
- *
- * This function decreases the use count and puts the backing pages when use 
drops to zero.
- */
-void drm_gem_shmem_put_pages(struct drm_gem_shmem_object *shmem)
+static int drm_gem_shmem_pin_locked(struct drm_gem_shmem_object *shmem)
+{
+   int ret;
+
+   dma_resv_assert_held(shmem->base.resv);
+
+   ret = drm_gem_shmem_get_pages(shmem);
+
+   return ret;
+}
+
+static void drm_gem_shmem_unpin_locked(struct drm_gem_shmem_object *shmem)
 {
-   mutex_lock(&shmem->pages_lock);
-

[Intel-gfx] [PATCH v2 2/7] dma-buf/heaps: Don't assert held reservation lock for dma-buf mmapping

Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.

We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
drivers are moved to use reservation lock universally. The problem
solved by moving the lock down to exporters. This patch prepares dma-buf
heaps for the locking policy update.

Reviewed-by: Emil Velikov 
Signed-off-by: Dmitry Osipenko 
---
 drivers/dma-buf/heaps/cma_heap.c| 3 ---
 drivers/dma-buf/heaps/system_heap.c | 3 ---
 2 files changed, 6 deletions(-)

diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 1131fb943992..28fb04eccdd0 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -183,8 +182,6 @@ static int cma_heap_mmap(struct dma_buf *dmabuf, struct 
vm_area_struct *vma)
 {
struct cma_heap_buffer *buffer = dmabuf->priv;
 
-   dma_resv_assert_held(dmabuf->resv);
-
if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0)
return -EINVAL;
 
diff --git a/drivers/dma-buf/heaps/system_heap.c 
b/drivers/dma-buf/heaps/system_heap.c
index e8bd10e60998..fcf836ba9c1f 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -202,8 +201,6 @@ static int system_heap_mmap(struct dma_buf *dmabuf, struct 
vm_area_struct *vma)
struct sg_page_iter piter;
int ret;
 
-   dma_resv_assert_held(dmabuf->resv);
-
for_each_sgtable_page(table, &piter, vma->vm_pgoff) {
struct page *page = sg_page_iter_page(&piter);
 
-- 
2.39.2

[Intel-gfx] [PATCH v2 6/7] dma-buf: Change locking policy for mmap()

Change locking policy of mmap() callback, making exporters responsible
for handling dma-buf reservation locking. Previous locking policy stated
that dma-buf is locked for both importers and exporters by the dma-buf
core, which caused a deadlock problem for DRM drivers in a case of
self-imported dma-bufs which required to take the lock from the DRM
exporter side.

Reviewed-by: Emil Velikov 
Signed-off-by: Dmitry Osipenko 
---
 drivers/dma-buf/dma-buf.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index aa4ea8530cb3..21916bba77d5 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -131,7 +131,6 @@ static struct file_system_type dma_buf_fs_type = {
 static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma)
 {
struct dma_buf *dmabuf;
-   int ret;
 
if (!is_dma_buf_file(file))
return -EINVAL;
@@ -147,11 +146,7 @@ static int dma_buf_mmap_internal(struct file *file, struct 
vm_area_struct *vma)
dmabuf->size >> PAGE_SHIFT)
return -EINVAL;
 
-   dma_resv_lock(dmabuf->resv, NULL);
-   ret = dmabuf->ops->mmap(dmabuf, vma);
-   dma_resv_unlock(dmabuf->resv);
-
-   return ret;
+   return dmabuf->ops->mmap(dmabuf, vma);
 }
 
 static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
@@ -850,6 +845,7 @@ static struct sg_table * __map_dma_buf(struct 
dma_buf_attachment *attach,
  * - &dma_buf_ops.release()
  * - &dma_buf_ops.begin_cpu_access()
  * - &dma_buf_ops.end_cpu_access()
+ * - &dma_buf_ops.mmap()
  *
  * 2. These &dma_buf_ops callbacks are invoked with locked dma-buf
  *reservation and exporter can't take the lock:
@@ -858,7 +854,6 @@ static struct sg_table * __map_dma_buf(struct 
dma_buf_attachment *attach,
  * - &dma_buf_ops.unpin()
  * - &dma_buf_ops.map_dma_buf()
  * - &dma_buf_ops.unmap_dma_buf()
- * - &dma_buf_ops.mmap()
  * - &dma_buf_ops.vmap()
  * - &dma_buf_ops.vunmap()
  *
@@ -1463,8 +1458,6 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_end_cpu_access, DMA_BUF);
 int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
 unsigned long pgoff)
 {
-   int ret;
-
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
 
@@ -1485,11 +1478,7 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct 
vm_area_struct *vma,
vma_set_file(vma, dmabuf->file);
vma->vm_pgoff = pgoff;
 
-   dma_resv_lock(dmabuf->resv, NULL);
-   ret = dmabuf->ops->mmap(dmabuf, vma);
-   dma_resv_unlock(dmabuf->resv);
-
-   return ret;
+   return dmabuf->ops->mmap(dmabuf, vma);
 }
 EXPORT_SYMBOL_NS_GPL(dma_buf_mmap, DMA_BUF);
 
-- 
2.39.2

Re: [Intel-gfx] [PULL] drm-intel-next

On Thu, Apr 06, 2023 at 10:03:51AM -0400, Rodrigo Vivi wrote:
> Hi Daniel,
> 
> Here goes drm-intel-next-2023-04-06:
> 
> - Fix DPT+shmem combo and add i915.enable_dpt modparam (Ville)
> - i915.enable_sagv module parameter (Ville)
> - Correction to QGV related register addresses (Vinod)
> - IPS debugfs per-crtc and new file for false_color (Ville)
> - More clean-up and reorganization of Display code (Jani)
> - DP DSC related fixes and improvements (Stanislav, Ankit, Suraj, Swati)
> - Make utility pin asserts more accurate (Ville)
> - Meteor Lake enabling (Daniele)
> - High refresh rate PSR fixes (Jouni)
> - Cursor and Plane chicken register fixes (Ville)
> - Align the ADL-P TypeC sequences with hardware specification (Imre)
> - Documentation build fixes and improvements to catch bugs earlier (Lee, Jani)
> - PL1 power limit hwmon entry changed to use 0 as disabled state (Ashutosh)
> - DP aux sync fix and improvements (Ville)
> - DP MST fixes and w/a (Stanislav)
> - Limit PXP drm-errors or warning on firmware API failures (Alan)
> 
> Thanks,
> Rodrigo.
> 
> The following changes since commit 46f28427f6f824b6cff06fa025a55350b7de454a:
> 
>   Merge tag 'drm-rcar-next-20230325' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/pinchartl/linux into drm-next 
> (2023-03-27 18:20:20 +0200)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2023-04-06
> 
> for you to fetch changes up to b358793c3bf231c455c55e0173256a86483997a8:
> 
>   drm/i915/wakeref: fix kernel-doc comment (2023-04-06 15:39:26 +0300)

Pulled, thanks

> 
> 
> - Fix DPT+shmem combo and add i915.enable_dpt modparam (Ville)
> - i915.enable_sagv module parameter (Ville)
> - Correction to QGV related register addresses (Vinod)
> - IPS debugfs per-crtc and new file for false_color (Ville)
> - More clean-up and reorganization of Display code (Jani)
> - DP DSC related fixes and improvements (Stanislav, Ankit, Suraj, Swati)
> - Make utility pin asserts more accurate (Ville)
> - Meteor Lake enabling (Daniele)
> - High refresh rate PSR fixes (Jouni)
> - Cursor and Plane chicken register fixes (Ville)
> - Align the ADL-P TypeC sequences with hardware specification (Imre)
> - Documentation build fixes and improvements to catch bugs earlier (Lee, Jani)
> - PL1 power limit hwmon entry changed to use 0 as disabled state (Ashutosh)
> - DP aux sync fix and improvements (Ville)
> - DP MST fixes and w/a (Stanislav)
> - Limit PXP drm-errors or warning on firmware API failures (Alan)
> 
> 
> Alan Previn (1):
>   drm/i915/pxp: limit drm-errors or warning on firmware API failures
> 
> Ankit Nautiyal (2):
>   drm/dp_helper: Add helper to check DSC support with given o/p format
>   drm/i915/dp: Check if DSC supports the given output_format
> 
> Ashutosh Dixit (1):
>   drm/i915/hwmon: Use 0 to designate disabled PL1 power limit
> 
> Daniele Ceraolo Spurio (1):
>   drm/i915/mtl: Fix MTL stolen memory GGTT mapping
> 
> Imre Deak (29):
>   drm/i915/tc: Group the TC PHY setup/query functions per platform
>   drm/i915/tc: Use the adlp prefix for ADLP TC PHY functions
>   drm/i915/tc: Rename tc_phy_status_complete() to tc_phy_is_ready()
>   drm/i915/tc: Use the tc_phy prefix for all TC PHY functions
>   drm/i915/tc: Move TC port fields to a new intel_tc_port struct
>   drm/i915/tc: Check for TC PHY explicitly in 
> intel_tc_port_fia_max_lane_count()
>   drm/i915/tc: Move the intel_tc_port struct declaration to intel_tc.c
>   drm/i915/tc: Add TC PHY hook to get the PHY HPD live status
>   drm/i915/tc: Add TC PHY hooks to get the PHY ready/owned state
>   drm/i915/tc: Add TC PHY hook to read out the PHY HW state
>   drm/i915/tc: Add generic TC PHY connect/disconnect handlers
>   drm/i915/tc: Factor out tc_phy_verify_legacy_or_dp_alt_mode()
>   drm/i915/tc: Add TC PHY hooks to connect/disconnect the PHY
>   drm/i915/tc: Fix up the legacy VBT flag only in disconnected mode
>   drm/i915/tc: Check TC mode instead of the VBT legacy flag
>   drm/i915/tc: Block/unblock TC-cold in the PHY connect/disconnect hooks
>   drm/i915/tc: Remove redundant wakeref=0 check from unblock_tc_cold()
>   drm/i915/tc: Drop tc_cold_block()/unblock()'s power domain parameter
>   drm/i915/tc: Add TC PHY hook to get the TC-cold blocking power domain
>   drm/i915/tc: Add asserts in TC PHY hooks that the required power is on
>   drm/i915/tc: Add TC PHY hook to init the PHY
>   drm/i915/adlp/tc: Use the DE HPD ISR register for hotplug detection
>   drm/i915/tc: Get power ref for reading the HPD live status register
>   drm/i915/tc: Don't connect the PHY in intel_tc_port_connected()
>   drm/i915/adlp/tc: Align the connect/disconnect PHY sequence with bspec
>   drm/i915: Move shared DPLL disabling into

Re: [Intel-gfx] [PATCH][next] drm/i915/uapi: Replace fake flex-array with flexible-array member

2023-04-06 Thread Gustavo A. R. Silva





On 3/31/23 01:02, Jani Nikula wrote:

On Thu, 30 Mar 2023, "Gustavo A. R. Silva"  wrote:

Friendly ping: who can take this, please? 😄


It's in drm-intel-gt-next.


Awesome. :) Thank you!

--
Gustavo



commit 02abecdeebfcd3848b26b70778dd7f6eb0db65e1
Author: Gustavo A. R. Silva 
AuthorDate: Fri Mar 17 12:18:01 2023 -0600
Commit: Tvrtko Ursulin 
CommitDate: Tue Mar 21 08:41:18 2023 +

 drm/i915/uapi: Replace fake flex-array with flexible-array member

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/dsc: fix drm_edp_dsc_sink_output_bpp() DPCD high byte usage

== Series Details ==

Series: series starting with [1/2] drm/dsc: fix drm_edp_dsc_sink_output_bpp() 
DPCD high byte usage
URL   : https://patchwork.freedesktop.org/series/116192/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

Re: [Intel-gfx] [PATCH v9 10/25] vfio: Make vfio_device_open() single open for device cdev path

Hi Yi,

On 4/1/23 17:18, Yi Liu wrote:
> VFIO group has historically allowed multi-open of the device FD. This
> was made secure because the "open" was executed via an ioctl to the
> group FD which is itself only single open.
>
> However, no known use of multiple device FDs today. It is kind of a
> strange thing to do because new device FDs can naturally be created
> via dup().
>
> When we implement the new device uAPI (only used in cdev path) there is
> no natural way to allow the device itself from being multi-opened in a
> secure manner. Without the group FD we cannot prove the security context
> of the opener.
>
> Thus, when moving to the new uAPI we block the ability of opening
> a device multiple times. Given old group path still allows it we store
> a vfio_group pointer in struct vfio_device_file to differentiate.
>
> Reviewed-by: Kevin Tian 
> Reviewed-by: Jason Gunthorpe 
> Tested-by: Terrence Xu 
> Tested-by: Nicolin Chen 
> Tested-by: Yanting Jiang 
> Signed-off-by: Yi Liu 
Reviewed-by: Eric Auger 

Thanks

Eric
> ---
>  drivers/vfio/group.c | 2 ++
>  drivers/vfio/vfio.h  | 2 ++
>  drivers/vfio/vfio_main.c | 7 +++
>  3 files changed, 11 insertions(+)
>
> diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
> index d55ce3ca44b7..1af4b9e012a7 100644
> --- a/drivers/vfio/group.c
> +++ b/drivers/vfio/group.c
> @@ -245,6 +245,8 @@ static struct file *vfio_device_open_file(struct 
> vfio_device *device)
>   goto err_out;
>   }
>  
> + df->group = device->group;
> +
>   ret = vfio_device_group_open(df);
>   if (ret)
>   goto err_free;
> diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
> index b2f20b78a707..f1a448f9d067 100644
> --- a/drivers/vfio/vfio.h
> +++ b/drivers/vfio/vfio.h
> @@ -18,6 +18,8 @@ struct vfio_container;
>  
>  struct vfio_device_file {
>   struct vfio_device *device;
> + struct vfio_group *group;
> +
>   bool access_granted;
>   spinlock_t kvm_ref_lock; /* protect kvm field */
>   struct kvm *kvm;
> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> index 6d5d3c2180c8..c8721d5d05fa 100644
> --- a/drivers/vfio/vfio_main.c
> +++ b/drivers/vfio/vfio_main.c
> @@ -477,6 +477,13 @@ int vfio_device_open(struct vfio_device_file *df)
>  
>   lockdep_assert_held(&device->dev_set->lock);
>  
> + /*
> +  * Only the group path allows the device opened multiple times.
> +  * The device cdev path doesn't have a secure way for it.
> +  */
> + if (device->open_count != 0 && !df->group)
> + return -EINVAL;
> +
>   device->open_count++;
>   if (device->open_count == 1) {
>   ret = vfio_device_first_open(df);

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/dsc: fix drm_edp_dsc_sink_output_bpp() DPCD high byte usage