[Intel-gfx] [PATCH i-g-t] tests/drm_read: drm_read fails for subtest invalid-buffer on chrome

[Vidya Srinivas]

Chrome platforms is unable to handle reading from -1.
It terminates the test after reporting buffer overflow.
Hence, changed the address for invalid buffer to NULL instead of -1.
With this change, errno becomes EINTR when reading from NULL
location. To accomodate, also changing the check of errno to EINTR
instead of EFAULT

Change-Id: I5f844af087c9826fcbcfbe301f0df5f727cb013b
Signed-off-by: Vidya Srinivas 
---
 tests/drm_read.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/drm_read.c b/tests/drm_read.c
index ccf9d822fd8d..a8816bc1e587 100644
--- a/tests/drm_read.c
+++ b/tests/drm_read.c
@@ -106,8 +106,8 @@ static void test_invalid_buffer(int in)
 
alarm(1);
 
-   igt_assert_eq(read(fd, (void *)-1, 4096), -1);
-   igt_assert_eq(errno, EFAULT);
+   igt_assert_eq(read(fd, (void *)NULL, 4096), -1);
+   igt_assert_eq(errno, EINTR);
 
teardown(fd);
 }
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] tests/kms_big_fb: Wait for vblank before collecting CRC

[Vidya Srinivas]

Without wait for vblank, CRC mismatch is seen
between big and small CRC on few systems

Change-Id: I3bec931aa901130997e693ac1cacf389e2a8100f
Signed-off-by: Vidya Srinivas 
---
 tests/kms_big_fb.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tests/kms_big_fb.c b/tests/kms_big_fb.c
index b2027b6b9d1b..7d78ff829d41 100644
--- a/tests/kms_big_fb.c
+++ b/tests/kms_big_fb.c
@@ -254,6 +254,7 @@ static void unset_lut(data_t *data)
 static bool test_plane(data_t *data)
 {
igt_plane_t *plane = data->plane;
+   igt_display_t *display = >display;
struct igt_fb *small_fb = >small_fb;
struct igt_fb *big_fb = >big_fb;
int w = data->big_fb_width - small_fb->width;
@@ -337,16 +338,17 @@ static bool test_plane(data_t *data)
igt_display_commit2(>display, data->display.is_atomic ?
COMMIT_ATOMIC : COMMIT_UNIVERSAL);
 
-
+   igt_wait_for_vblank(data->drm_fd, 
display->pipes[data->pipe].crtc_offset);
igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
 
igt_plane_set_fb(plane, big_fb);
igt_fb_set_position(big_fb, plane, x, y);
igt_fb_set_size(big_fb, plane, small_fb->width, 
small_fb->height);
+
igt_plane_set_size(plane, data->width, data->height);
igt_display_commit2(>display, data->display.is_atomic ?
COMMIT_ATOMIC : COMMIT_UNIVERSAL);
-
+   igt_wait_for_vblank(data->drm_fd, 
display->pipes[data->pipe].crtc_offset);
igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
 
igt_plane_set_fb(plane, NULL);
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] NVIDIA GPU fallen off the bus after exiting s2idle

[Chris Chiu]

On Thu, May 6, 2021 at 5:46 PM Rafael J. Wysocki  wrote:
>
> On Tue, May 4, 2021 at 10:08 AM Chris Chiu  wrote:
> >
> > Hi,
> > We have some Intel laptops (11th generation CPU) with NVIDIA GPU
> > suffering the same GPU falling off the bus problem while exiting
> > s2idle with external display connected. These laptops connect the
> > external display via the HDMI/DisplayPort on a USB Type-C interfaced
> > dock. If we enter and exit s2idle with the dock connected, the NVIDIA
> > GPU (confirmed on 10de:24b6 and 10de:25b8) and the PCIe port can come
> > back to D0 w/o problem. If we enter the s2idle, disconnect the dock,
> > then exit the s2idle, both external display and the panel will remain
> > with no output. The dmesg as follows shows the "nvidia :01:00.0:
> > can't change power state from D3cold to D0 (config space
> > inaccessible)" due to the following ACPI error
> > [ 154.446781]
> > [ 154.446783]
> > [ 154.446783] Initialized Local Variables for Method [IPCS]:
> > [ 154.446784] Local0: 9863e365  Integer 09C5
> > [ 154.446790]
> > [ 154.446791] Initialized Arguments for Method [IPCS]: (7 arguments
> > defined for method invocation)
> > [ 154.446792] Arg0: 25568fbd  Integer 00AC
> > [ 154.446795] Arg1: 9ef30e76  Integer 
> > [ 154.446798] Arg2: fdf820f0  Integer 0010
> > [ 154.446801] Arg3: 9fc2a088  Integer 0001
> > [ 154.446804] Arg4: 3a3418f7  Integer 0001
> > [ 154.446807] Arg5: 20c4b87c  Integer 
> > [ 154.446810] Arg6: 8b965a8a  Integer 
> > [ 154.446813]
> > [ 154.446815] ACPI Error: Aborting method \IPCS due to previous error
> > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529)
> > [ 154.446824] ACPI Error: Aborting method \MCUI due to previous error
> > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529)
> > [ 154.446829] ACPI Error: Aborting method \SPCX due to previous error
> > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529)
> > [ 154.446835] ACPI Error: Aborting method \_SB.PC00.PGSC due to
> > previous error (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529)
> > [ 154.446841] ACPI Error: Aborting method \_SB.PC00.PGON due to
> > previous error (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529)
> > [ 154.446846] ACPI Error: Aborting method \_SB.PC00.PEG1.NPON due to
> > previous error (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529)
> > [ 154.446852] ACPI Error: Aborting method \_SB.PC00.PEG1.PG01._ON due
> > to previous error (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529)
> > [ 154.446860] acpi device:02: Failed to change power state to D0
> > [ 154.690760] video LNXVIDEO:00: Cannot transition to power state D0
> > for parent in (unknown)
>
> If I were to guess, I would say that AML tries to access memory that
> is not accessible while suspended, probably PCI config space.
>
> > The IPCS is the last function called from \_SB.PC00.PEG1.PG01._ON
> > which we expect it to prepare everything before bringing back the
> > NVIDIA GPU but it's stuck in the infinite loop as described below.
> > Please refer to
> > https://gist.github.com/mschiu77/fa4f5a97297749d0d66fe60c1d421c44 for
> > the full DSDT.dsl.
>
> The DSDT alone may not be sufficient.
>
> Can you please create a bug entry at bugzilla.kernel.org for this
> issue and attach the full output of acpidump from one of the affected
> machines to it?  And please let me know the number of the bug.
>
> Also please attach the output of dmesg including a suspend-resume
> cycle including dock disconnection while suspended and the ACPI
> messages quoted below.
>
> >While (One)
> > {
> > If ((!IBSY || (IERR == One)))
> > {
> > Break
> > }
> >
> > If ((Local0 > TMOV))
> > {
> > RPKG [Zero] = 0x03
> > Return (RPKG) /* \IPCS.RPKG */
> > }
> >
> > Sleep (One)
> > Local0++
> > }
> >
> > And the upstream PCIe port of NVIDIA seems to become inaccessible due
> > to the messages as follows.
> > [ 292.746508] pcieport :00:01.0: waiting 100 ms for downstream
> > link, after activation
> > [ 292.882296] pci :01:00.0: waiting additional 100 ms to become 
> > accessible
> > [ 316.876997] pci :01:00.0: can't change power state from D3cold
> > to D0 (config space inaccessible)
> >
> > Since the IPCS is the Intel Reference Code and we don't really know
> > why the never-end loop happens just because we unplug the dock while
> > the system still stays in s2idle. Can anyone from Intel suggest what
> > happens here?
>
> This list is not the right channel for inquiries related to Intel
> support, we can only help you as Linux kernel developers in this
> venue.
>
> > And one thing also worth mentioning, if we unplug the display cable
> > from the dock before entering the s2idle, NVIDIA GPU can 

[Intel-gfx] linux-next: build failure after merge of the drm-intel tree

[Stephen Rothwell]

Hi all,

After merging the drm-intel tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/i915/gvt/handlers.c: In function 'init_skl_mmio_info':
drivers/gpu/drm/i915/gvt/handlers.c:3345:9: error: 'CSR_SSP_BASE' undeclared 
(first use in this function); did you mean 'DMC_SSP_BASE'?
 3345 |  MMIO_D(CSR_SSP_BASE, D_SKL_PLUS);
  | ^~~~
drivers/gpu/drm/i915/gvt/handlers.c:2120:48: note: in definition of macro 
'MMIO_F'
 2120 |  ret = new_mmio_info(gvt, i915_mmio_reg_offset(reg), \
  |^~~
drivers/gpu/drm/i915/gvt/handlers.c:3345:2: note: in expansion of macro 'MMIO_D'
 3345 |  MMIO_D(CSR_SSP_BASE, D_SKL_PLUS);
  |  ^~
drivers/gpu/drm/i915/gvt/handlers.c:3345:9: note: each undeclared identifier is 
reported only once for each function it appears in
 3345 |  MMIO_D(CSR_SSP_BASE, D_SKL_PLUS);
  | ^~~~
drivers/gpu/drm/i915/gvt/handlers.c:2120:48: note: in definition of macro 
'MMIO_F'
 2120 |  ret = new_mmio_info(gvt, i915_mmio_reg_offset(reg), \
  |^~~
drivers/gpu/drm/i915/gvt/handlers.c:3345:2: note: in expansion of macro 'MMIO_D'
 3345 |  MMIO_D(CSR_SSP_BASE, D_SKL_PLUS);
  |  ^~
drivers/gpu/drm/i915/gvt/handlers.c:3346:9: error: 'CSR_HTP_SKL' undeclared 
(first use in this function); did you mean 'DMC_HTP_SKL'?
 3346 |  MMIO_D(CSR_HTP_SKL, D_SKL_PLUS);
  | ^~~
drivers/gpu/drm/i915/gvt/handlers.c:2120:48: note: in definition of macro 
'MMIO_F'
 2120 |  ret = new_mmio_info(gvt, i915_mmio_reg_offset(reg), \
  |^~~
drivers/gpu/drm/i915/gvt/handlers.c:3346:2: note: in expansion of macro 'MMIO_D'
 3346 |  MMIO_D(CSR_HTP_SKL, D_SKL_PLUS);
  |  ^~
drivers/gpu/drm/i915/gvt/handlers.c:3347:9: error: 'CSR_LAST_WRITE' undeclared 
(first use in this function); did you mean 'DMC_LAST_WRITE'?
 3347 |  MMIO_D(CSR_LAST_WRITE, D_SKL_PLUS);
  | ^~
drivers/gpu/drm/i915/gvt/handlers.c:2120:48: note: in definition of macro 
'MMIO_F'
 2120 |  ret = new_mmio_info(gvt, i915_mmio_reg_offset(reg), \
  |^~~
drivers/gpu/drm/i915/gvt/handlers.c:3347:2: note: in expansion of macro 'MMIO_D'
 3347 |  MMIO_D(CSR_LAST_WRITE, D_SKL_PLUS);
  |  ^~
In file included from drivers/gpu/drm/i915/i915_drv.h:64,
 from drivers/gpu/drm/i915/gvt/handlers.c:39:
drivers/gpu/drm/i915/gvt/handlers.c: At top level:
drivers/gpu/drm/i915/gvt/handlers.c:3658:21: error: 'CSR_MMIO_START_RANGE' 
undeclared here (not in a function); did you mean 'DMC_MMIO_START_RANGE'?
 3658 |  {D_SKL_PLUS, _MMIO(CSR_MMIO_START_RANGE), 0x3000, NULL, NULL},
  | ^~~~
drivers/gpu/drm/i915/i915_reg.h:185:47: note: in definition of macro '_MMIO'
  185 | #define _MMIO(r) ((const i915_reg_t){ .reg = (r) })
  |   ^

Caused by commit

  0633cdcbaa77 ("drm/i915/dmc: Rename macro names containing csr")

I have used the drm-intel tree from next-20210520 for today.

-- 
Cheers,
Stephen Rothwell


pgpevIrKne_Fd.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree

[Stephen Rothwell]

Hi all,

On Thu, 20 May 2021 10:19:10 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
> 
>   drivers/gpu/drm/i915/i915_mm.c
> 
> between commit:
> 
>   293837b9ac8d ("Revert "i915: fix remap_io_sg to verify the pgprot"")
> 
> from Linus' tree and commit:
> 
>   ec279384c6a0 ("drm/i915: Initialize err in remap_io_sg()")
> 
> from the drm-intel tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> 
> diff --cc drivers/gpu/drm/i915/i915_mm.c
> index 9a777b0ff59b,25576fa73ff0..
> --- a/drivers/gpu/drm/i915/i915_mm.c
> +++ b/drivers/gpu/drm/i915/i915_mm.c
> @@@ -82,13 -46,8 +82,13 @@@ int remap_io_sg(struct vm_area_struct *
>   unsigned long addr, unsigned long size,
>   struct scatterlist *sgl, resource_size_t iobase)
>   {
>  -unsigned long pfn, len, remapped = 0;
>  +struct remap_pfn r = {
>  +.mm = vma->vm_mm,
>  +.prot = vma->vm_page_prot,
>  +.sgt = __sgt_iter(sgl, use_dma(iobase)),
>  +.iobase = iobase,
>  +};
> - int err;
> + int err = 0;
>   
>   /* We rely on prevalidation of the io-mapping to skip track_pfn(). */
>   GEM_BUG_ON((vma->vm_flags & EXPECTED_FLAGS) != EXPECTED_FLAGS);

This is now a conflict between the drm tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell


pgp9fOXoQ9Kcg.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] linux-next: manual merge of the amdgpu tree with the drm-misc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the amdgpu tree got a conflict in:

  drivers/gpu/drm/amd/amdkfd/kfd_device.c

between commit:

  e9669fb78262 ("drm/amdgpu: Add early fini callback")

from the drm-misc tree and commit:

  814ab9930cfd ("drm/amdkfd: register HMM device private zone")

from the amdgpu tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/amd/amdkfd/kfd_device.c
index b066aa009b6f,80015e866498..
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@@ -861,6 -891,8 +891,7 @@@ out
  void kgd2kfd_device_exit(struct kfd_dev *kfd)
  {
if (kfd->init_complete) {
 -  kgd2kfd_suspend(kfd, false);
+   svm_migrate_fini((struct amdgpu_device *)kfd->kgd);
device_queue_manager_uninit(kfd->dqm);
kfd_interrupt_exit(kfd);
kfd_topology_remove_device(kfd);


pgp81qK3tAp2A.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] linux-next: manual merge of the amdgpu tree with the drm-misc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the amdgpu tree got a conflict in:

  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c

between commit:

  35bba8313b95 ("drm/amdgpu: Convert driver sysfs attributes to static 
attributes")

from the drm-misc tree and commit:

  589939d40116 ("drm/amdgpu: fix coding style and documentation in 
amdgpu_vram_mgr.c")

from the amdgpu tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index a99d196b05df,a52e17ed3df6..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@@ -162,74 -181,6 +181,10 @@@ static struct attribute *amdgpu_vram_mg
NULL
  };
  
 +const struct attribute_group amdgpu_vram_mgr_attr_group = {
 +  .attrs = amdgpu_vram_mgr_attributes
 +};
 +
- static const struct ttm_resource_manager_func amdgpu_vram_mgr_func;
- 
- /**
-  * amdgpu_vram_mgr_init - init VRAM manager and DRM MM
-  *
-  * @adev: amdgpu_device pointer
-  *
-  * Allocate and initialize the VRAM manager.
-  */
- int amdgpu_vram_mgr_init(struct amdgpu_device *adev)
- {
-   struct amdgpu_vram_mgr *mgr = >mman.vram_mgr;
-   struct ttm_resource_manager *man = >manager;
- 
-   ttm_resource_manager_init(man, adev->gmc.real_vram_size >> PAGE_SHIFT);
- 
-   man->func = _vram_mgr_func;
- 
-   drm_mm_init(>mm, 0, man->size);
-   spin_lock_init(>lock);
-   INIT_LIST_HEAD(>reservations_pending);
-   INIT_LIST_HEAD(>reserved_pages);
- 
-   ttm_set_driver_manager(>mman.bdev, TTM_PL_VRAM, >manager);
-   ttm_resource_manager_set_used(man, true);
-   return 0;
- }
- 
- /**
-  * amdgpu_vram_mgr_fini - free and destroy VRAM manager
-  *
-  * @adev: amdgpu_device pointer
-  *
-  * Destroy and free the VRAM manager, returns -EBUSY if ranges are still
-  * allocated inside it.
-  */
- void amdgpu_vram_mgr_fini(struct amdgpu_device *adev)
- {
-   struct amdgpu_vram_mgr *mgr = >mman.vram_mgr;
-   struct ttm_resource_manager *man = >manager;
-   int ret;
-   struct amdgpu_vram_reservation *rsv, *temp;
- 
-   ttm_resource_manager_set_used(man, false);
- 
-   ret = ttm_resource_manager_evict_all(>mman.bdev, man);
-   if (ret)
-   return;
- 
-   spin_lock(>lock);
-   list_for_each_entry_safe(rsv, temp, >reservations_pending, node)
-   kfree(rsv);
- 
-   list_for_each_entry_safe(rsv, temp, >reserved_pages, node) {
-   drm_mm_remove_node(>mm_node);
-   kfree(rsv);
-   }
-   drm_mm_takedown(>mm);
-   spin_unlock(>lock);
- 
-   ttm_resource_manager_cleanup(man);
-   ttm_set_driver_manager(>mman.bdev, TTM_PL_VRAM, NULL);
- }
- 
  /**
   * amdgpu_vram_mgr_vis_size - Calculate visible node size
   *
@@@ -444,10 -396,10 +400,10 @@@ static int amdgpu_vram_mgr_new(struct t
pages_per_node = HPAGE_PMD_NR;
  #else
/* default to 2MB */
-   pages_per_node = (2UL << (20UL - PAGE_SHIFT));
+   pages_per_node = 2UL << (20UL - PAGE_SHIFT);
  #endif
-   pages_per_node = max((uint32_t)pages_per_node,
-tbo->page_alignment);
+   pages_per_node = max_t(uint32_t, pages_per_node,
 - mem->page_alignment);
++ tbo->page_alignment);
num_nodes = DIV_ROUND_UP(mem->num_pages, pages_per_node);
}
  
@@@ -465,38 -417,29 +421,29 @@@
mem->start = 0;
pages_left = mem->num_pages;
  
-   spin_lock(>lock);
-   for (i = 0; pages_left >= pages_per_node; ++i) {
-   unsigned long pages = rounddown_pow_of_two(pages_left);
- 
-   /* Limit maximum size to 2GB due to SG table limitations */
-   pages = min(pages, (2UL << (30 - PAGE_SHIFT)));
- 
-   r = drm_mm_insert_node_in_range(mm, [i], pages,
-   pages_per_node, 0,
-   place->fpfn, lpfn,
-   mode);
-   if (unlikely(r))
-   break;
- 
-   vis_usage += amdgpu_vram_mgr_vis_size(adev, [i]);
-   amdgpu_vram_mgr_virt_start(mem, [i]);
-   pages_left -= pages;
-   }
+   /* Limit maximum size to 2GB due to SG table limitations */
+   pages = min(pages_left, 2UL << (30 - PAGE_SHIFT));
  
-   for (; pages_left; ++i) {
-   unsigned long pages = min(pages_left, pages_per_node);
+   i = 0;
+   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: fix typo when returning table

[Patchwork]

== Series Details ==

Series: drm/i915/display: fix typo when returning table
URL   : https://patchwork.freedesktop.org/series/90385/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10116 -> Patchwork_20166


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20166/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][2] ([i915#2782]) -> [PASS][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10116/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20166/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  [FAIL][4] ([i915#49]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10116/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20166/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  
 Warnings 

  * igt@runner@aborted:
- fi-cfl-8700k:   [FAIL][6] ([i915#3363]) -> [FAIL][7] ([i915#2426] / 
[i915#3363])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10116/fi-cfl-8700k/igt@run...@aborted.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20166/fi-cfl-8700k/igt@run...@aborted.html
- fi-glk-dsi: [FAIL][8] ([i915#2426] / [i915#3363] / 
[k.org#202321]) -> [FAIL][9] ([i915#3363] / [k.org#202321])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10116/fi-glk-dsi/igt@run...@aborted.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20166/fi-glk-dsi/igt@run...@aborted.html
- fi-kbl-soraka:  [FAIL][10] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][11] ([i915#1436] / [i915#3363])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10116/fi-kbl-soraka/igt@run...@aborted.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20166/fi-kbl-soraka/igt@run...@aborted.html
- fi-cml-u2:  [FAIL][12] ([i915#2082] / [i915#2426] / [i915#3363]) 
-> [FAIL][13] ([i915#3363])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10116/fi-cml-u2/igt@run...@aborted.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20166/fi-cml-u2/igt@run...@aborted.html
- fi-skl-6700k2:  [FAIL][14] ([i915#1436] / [i915#3363]) -> [FAIL][15] 
([i915#1436] / [i915#2426] / [i915#3363])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10116/fi-skl-6700k2/igt@run...@aborted.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20166/fi-skl-6700k2/igt@run...@aborted.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#2082]: https://gitlab.freedesktop.org/drm/intel/issues/2082
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
  [k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321


Participating hosts (41 -> 39)
--

  Missing(2): fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_10116 -> Patchwork_20166

  CI-20190529: 20190529
  CI_DRM_10116: beca532f1c9f49044e5080e547d72548ff50136d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6090: 8eeb9c130e75d4063d0dc2ed69c8acde66b6b5d0 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_20166: 88e8d46ff0784b3df88878eff653cb57e142019d @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

88e8d46ff078 drm/i915/display: fix typo when returning table

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20166/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] linux-next: manual merge of the amdgpu tree with the drm-misc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the amdgpu tree got a conflict in:

  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

between commit:

  f89f8c6bafd0 ("drm/amdgpu: Guard against write accesses after device removal")

from the drm-misc tree and commit:

  0ccc3ccf5b3a ("drm/amdgpu: re-apply "use the new cursor in the VM code" v2")

from the amdgpu tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 90c34491f85d,57a6ad04118c..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@@ -1594,23 -1618,21 +1620,24 @@@ static int amdgpu_vm_update_ptes(struc
   * Returns:
   * 0 for success, -EINVAL for failure.
   */
- static int amdgpu_vm_bo_update_mapping(struct amdgpu_device *adev,
-  struct amdgpu_device *bo_adev,
-  struct amdgpu_vm *vm, bool immediate,
-  bool unlocked, struct dma_resv *resv,
-  uint64_t start, uint64_t last,
-  uint64_t flags, uint64_t offset,
-  struct drm_mm_node *nodes,
-  dma_addr_t *pages_addr,
-  struct dma_fence **fence)
+ int amdgpu_vm_bo_update_mapping(struct amdgpu_device *adev,
+   struct amdgpu_device *bo_adev,
+   struct amdgpu_vm *vm, bool immediate,
+   bool unlocked, struct dma_resv *resv,
+   uint64_t start, uint64_t last,
+   uint64_t flags, uint64_t offset,
+   struct ttm_resource *res,
+   dma_addr_t *pages_addr,
+   struct dma_fence **fence,
+   bool *table_freed)
  {
struct amdgpu_vm_update_params params;
+   struct amdgpu_res_cursor cursor;
enum amdgpu_sync_mode sync_mode;
-   uint64_t pfn;
 -  int r;
 +  int r, idx;
 +
 +  if (!drm_dev_enter(>ddev, ))
 +  return -ENODEV;
  
memset(, 0, sizeof(params));
params.adev = adev;
@@@ -1717,9 -1722,11 +1727,12 @@@
  
r = vm->update_funcs->commit(, fence);
  
+   if (table_freed)
+   *table_freed = params.table_freed;
+ 
  error_unlock:
amdgpu_vm_eviction_unlock(vm);
 +  drm_dev_exit(idx);
return r;
  }
  


pgpjBqd7eqqpq.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] linux-next: manual merge of the amdgpu tree with the drm-misc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the amdgpu tree got a conflict in:

  drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c

between commit:

  35bba8313b95 ("drm/amdgpu: Convert driver sysfs attributes to static 
attributes")

from the drm-misc tree and commit:

  a614b336f1c1 ("drm/amdgpu: fix coding style and documentation in 
amdgpu_gtt_mgr.c")

from the amdgpu tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index a4404da8ca6d,8860545344c7..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@@ -75,75 -80,6 +80,16 @@@ static DEVICE_ATTR(mem_info_gtt_total, 
  static DEVICE_ATTR(mem_info_gtt_used, S_IRUGO,
   amdgpu_mem_info_gtt_used_show, NULL);
  
 +static struct attribute *amdgpu_gtt_mgr_attributes[] = {
 +  _attr_mem_info_gtt_total.attr,
 +  _attr_mem_info_gtt_used.attr,
 +  NULL
 +};
 +
 +const struct attribute_group amdgpu_gtt_mgr_attr_group = {
 +  .attrs = amdgpu_gtt_mgr_attributes
 +};
 +
- static const struct ttm_resource_manager_func amdgpu_gtt_mgr_func;
- /**
-  * amdgpu_gtt_mgr_init - init GTT manager and DRM MM
-  *
-  * @adev: amdgpu_device pointer
-  * @gtt_size: maximum size of GTT
-  *
-  * Allocate and initialize the GTT manager.
-  */
- int amdgpu_gtt_mgr_init(struct amdgpu_device *adev, uint64_t gtt_size)
- {
-   struct amdgpu_gtt_mgr *mgr = >mman.gtt_mgr;
-   struct ttm_resource_manager *man = >manager;
-   uint64_t start, size;
- 
-   man->use_tt = true;
-   man->func = _gtt_mgr_func;
- 
-   ttm_resource_manager_init(man, gtt_size >> PAGE_SHIFT);
- 
-   start = AMDGPU_GTT_MAX_TRANSFER_SIZE * AMDGPU_GTT_NUM_TRANSFER_WINDOWS;
-   size = (adev->gmc.gart_size >> PAGE_SHIFT) - start;
-   drm_mm_init(>mm, start, size);
-   spin_lock_init(>lock);
-   atomic64_set(>available, gtt_size >> PAGE_SHIFT);
- 
-   ttm_set_driver_manager(>mman.bdev, TTM_PL_TT, >manager);
-   ttm_resource_manager_set_used(man, true);
-   return 0;
- }
- 
- /**
-  * amdgpu_gtt_mgr_fini - free and destroy GTT manager
-  *
-  * @adev: amdgpu_device pointer
-  *
-  * Destroy and free the GTT manager, returns -EBUSY if ranges are still
-  * allocated inside it.
-  */
- void amdgpu_gtt_mgr_fini(struct amdgpu_device *adev)
- {
-   struct amdgpu_gtt_mgr *mgr = >mman.gtt_mgr;
-   struct ttm_resource_manager *man = >manager;
-   int ret;
- 
-   ttm_resource_manager_set_used(man, false);
- 
-   ret = ttm_resource_manager_evict_all(>mman.bdev, man);
-   if (ret)
-   return;
- 
-   spin_lock(>lock);
-   drm_mm_takedown(>mm);
-   spin_unlock(>lock);
- 
-   ttm_resource_manager_cleanup(man);
-   ttm_set_driver_manager(>mman.bdev, TTM_PL_TT, NULL);
- }
- 
  /**
   * amdgpu_gtt_mgr_has_gart_addr - Check if mem has address space
   *
@@@ -306,3 -249,76 +259,61 @@@ static const struct ttm_resource_manage
.free = amdgpu_gtt_mgr_del,
.debug = amdgpu_gtt_mgr_debug
  };
+ 
+ /**
+  * amdgpu_gtt_mgr_init - init GTT manager and DRM MM
+  *
+  * @adev: amdgpu_device pointer
+  * @gtt_size: maximum size of GTT
+  *
+  * Allocate and initialize the GTT manager.
+  */
+ int amdgpu_gtt_mgr_init(struct amdgpu_device *adev, uint64_t gtt_size)
+ {
+   struct amdgpu_gtt_mgr *mgr = >mman.gtt_mgr;
+   struct ttm_resource_manager *man = >manager;
+   uint64_t start, size;
 -  int ret;
+ 
+   man->use_tt = true;
+   man->func = _gtt_mgr_func;
+ 
+   ttm_resource_manager_init(man, gtt_size >> PAGE_SHIFT);
+ 
+   start = AMDGPU_GTT_MAX_TRANSFER_SIZE * AMDGPU_GTT_NUM_TRANSFER_WINDOWS;
+   size = (adev->gmc.gart_size >> PAGE_SHIFT) - start;
+   drm_mm_init(>mm, start, size);
+   spin_lock_init(>lock);
+   atomic64_set(>available, gtt_size >> PAGE_SHIFT);
+ 
 -  ret = device_create_file(adev->dev, _attr_mem_info_gtt_total);
 -  if (ret) {
 -  DRM_ERROR("Failed to create device file mem_info_gtt_total\n");
 -  return ret;
 -  }
 -  ret = device_create_file(adev->dev, _attr_mem_info_gtt_used);
 -  if (ret) {
 -  DRM_ERROR("Failed to create device file mem_info_gtt_used\n");
 -  return ret;
 -  }
 -
+   ttm_set_driver_manager(>mman.bdev, TTM_PL_TT, >manager);
+   ttm_resource_manager_set_used(man, true);
+   return 0;
+ }
+ 
+ /**
+  * amdgpu_gtt_mgr_fini - free and destroy GTT manager
+  *
+  * @adev: amdgpu_device pointer
+  *
+  * Destroy and free the GTT manager, returns -EBUSY if ranges are still
+  * 

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/cmdparser: No-op failed batches on all platforms (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/cmdparser: No-op failed batches on 
all platforms (rev2)
URL   : https://patchwork.freedesktop.org/series/90310/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10102_full -> Patchwork_20154_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_ppgtt@blt-vs-render-ctx0:
- shard-apl:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20154/shard-apl7/igt@gem_pp...@blt-vs-render-ctx0.html

  * igt@gen9_exec_parse@batch-without-end:
- shard-skl:  NOTRUN -> [FAIL][2] +2 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20154/shard-skl3/igt@gen9_exec_pa...@batch-without-end.html
- shard-kbl:  [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10102/shard-kbl7/igt@gen9_exec_pa...@batch-without-end.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20154/shard-kbl4/igt@gen9_exec_pa...@batch-without-end.html

  * igt@gen9_exec_parse@bb-start-param:
- shard-skl:  [PASS][5] -> [FAIL][6] +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10102/shard-skl1/igt@gen9_exec_pa...@bb-start-param.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20154/shard-skl1/igt@gen9_exec_pa...@bb-start-param.html

  * igt@gen9_exec_parse@unaligned-jump:
- shard-apl:  [PASS][7] -> [FAIL][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10102/shard-apl7/igt@gen9_exec_pa...@unaligned-jump.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20154/shard-apl7/igt@gen9_exec_pa...@unaligned-jump.html
- shard-glk:  [PASS][9] -> [FAIL][10] +4 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10102/shard-glk7/igt@gen9_exec_pa...@unaligned-jump.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20154/shard-glk6/igt@gen9_exec_pa...@unaligned-jump.html
- shard-kbl:  NOTRUN -> [FAIL][11]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20154/shard-kbl2/igt@gen9_exec_pa...@unaligned-jump.html

  * igt@kms_cursor_legacy@all-pipes-forked-bo:
- shard-tglb: [PASS][12] -> [INCOMPLETE][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10102/shard-tglb1/igt@kms_cursor_leg...@all-pipes-forked-bo.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20154/shard-tglb6/igt@kms_cursor_leg...@all-pipes-forked-bo.html

  
 Warnings 

  * igt@gem_render_copy@y-tiled-ccs-to-yf-tiled-ccs:
- shard-glk:  [INCOMPLETE][14] ([i915#3468]) -> [INCOMPLETE][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10102/shard-glk8/igt@gem_render_c...@y-tiled-ccs-to-yf-tiled-ccs.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20154/shard-glk7/igt@gem_render_c...@y-tiled-ccs-to-yf-tiled-ccs.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@drm_read@fault-buffer:
- shard-apl:  NOTRUN -> [DMESG-WARN][16] ([i915#3457]) +2 similar 
issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20154/shard-apl7/igt@drm_r...@fault-buffer.html

  * igt@gem_create@create-clear:
- shard-glk:  [PASS][17] -> [FAIL][18] ([i915#1888] / [i915#3160])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10102/shard-glk7/igt@gem_cre...@create-clear.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20154/shard-glk3/igt@gem_cre...@create-clear.html

  * igt@gem_create@create-massive:
- shard-snb:  NOTRUN -> [DMESG-WARN][19] ([i915#3002]) +1 similar 
issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20154/shard-snb2/igt@gem_cre...@create-massive.html
- shard-skl:  NOTRUN -> [DMESG-WARN][20] ([i915#3002])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20154/shard-skl1/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-kbl:  NOTRUN -> [DMESG-WARN][21] ([i915#180] / [i915#3457]) 
+1 similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20154/shard-kbl2/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_ctx_persistence@heartbeat-many:
- shard-glk:  [PASS][22] -> [FAIL][23] 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: fix typo when returning table

[Patchwork]

== Series Details ==

Series: drm/i915/display: fix typo when returning table
URL   : https://patchwork.freedesktop.org/series/90385/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
88e8d46ff078 drm/i915/display: fix typo when returning table
-:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#9: 
static const struct tgl_dkl_phy_ddi_buf_trans 
adlp_dkl_phy_dp_ddi_trans_hbr2_hbr3[] = {

total: 0 errors, 1 warnings, 0 checks, 8 lines checked


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for More DMC cleanup (rev2)

[Patchwork]

== Series Details ==

Series: More DMC cleanup (rev2)
URL   : https://patchwork.freedesktop.org/series/90379/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10116 -> Patchwork_20165


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  [PASS][1] -> [DMESG-WARN][2] ([i915#2868])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10116/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20165/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Possible fixes 

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  [FAIL][3] ([i915#49]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10116/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20165/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  
 Warnings 

  * igt@i915_selftest@live@execlists:
- fi-bsw-kefka:   [INCOMPLETE][5] ([i915#2782] / [i915#2940] / 
[i915#3462]) -> [DMESG-FAIL][6] ([i915#3462])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10116/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20165/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html

  * igt@runner@aborted:
- fi-kbl-r:   [FAIL][7] ([i915#1436] / [i915#3363]) -> [FAIL][8] 
([i915#1436] / [i915#2426] / [i915#3363])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10116/fi-kbl-r/igt@run...@aborted.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20165/fi-kbl-r/igt@run...@aborted.html
- fi-cml-u2:  [FAIL][9] ([i915#2082] / [i915#2426] / [i915#3363]) 
-> [FAIL][10] ([i915#3363])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10116/fi-cml-u2/igt@run...@aborted.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20165/fi-cml-u2/igt@run...@aborted.html
- fi-kbl-7567u:   [FAIL][11] ([i915#1436] / [i915#3363]) -> [FAIL][12] 
([i915#1436] / [i915#2426] / [i915#3363])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10116/fi-kbl-7567u/igt@run...@aborted.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20165/fi-kbl-7567u/igt@run...@aborted.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#2082]: https://gitlab.freedesktop.org/drm/intel/issues/2082
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#2868]: https://gitlab.freedesktop.org/drm/intel/issues/2868
  [i915#2932]: https://gitlab.freedesktop.org/drm/intel/issues/2932
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#2966]: https://gitlab.freedesktop.org/drm/intel/issues/2966
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462
  [i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49


Participating hosts (41 -> 38)
--

  Missing(3): fi-hsw-4200u fi-bdw-samus fi-snb-2600 


Build changes
-

  * Linux: CI_DRM_10116 -> Patchwork_20165

  CI-20190529: 20190529
  CI_DRM_10116: beca532f1c9f49044e5080e547d72548ff50136d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6090: 8eeb9c130e75d4063d0dc2ed69c8acde66b6b5d0 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_20165: 249c6b8f711ed9bad3027c7d0b6ccd8e6815e092 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

249c6b8f711e drm/i915/dmc: Move struct intel_dmc to intel_dmc.h
6da878e7a905 drm/i915/dmc: Add intel_dmc_has_payload() helper
06268e3a934f drm/i915/dmc: s/DRM_ERROR/drm_err

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20165/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/display: fix typo when returning table

[Lucas De Marchi]

Fix table returned when port_clock > 27:

drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c:752:47: error: 
variable 'adlp_dkl_phy_dp_ddi_trans_hbr2_hbr3' is not needed and will not be 
emitted [-Werror,-Wunneeded-internal-declaration]
static const struct tgl_dkl_phy_ddi_buf_trans 
adlp_dkl_phy_dp_ddi_trans_hbr2_hbr3[] = {

Initial version of the patch had it in a single table, but on second
version the table got split, but we continued to reference just one of
them.

Fixes: ca962882268a ("drm/i915/adl_p: Define and use ADL-P specific DP 
translation tables")
Reported-by: kernel test robot 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c 
b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
index ce5d5d13b7c1..8bfd00f49f2a 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
@@ -1383,7 +1383,7 @@ adlp_get_dkl_buf_trans_dp(struct intel_encoder *encoder,
 {
if (crtc_state->port_clock > 27) {
*n_entries = ARRAY_SIZE(adlp_dkl_phy_dp_ddi_trans_hbr2_hbr3);
-   return adlp_dkl_phy_dp_ddi_trans_hbr;
+   return adlp_dkl_phy_dp_ddi_trans_hbr2_hbr3;
}
 
*n_entries = ARRAY_SIZE(adlp_dkl_phy_dp_ddi_trans_hbr);
-- 
2.31.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for More DMC cleanup (rev2)

[Patchwork]

== Series Details ==

Series: More DMC cleanup (rev2)
URL   : https://patchwork.freedesktop.org/series/90379/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
06268e3a934f drm/i915/dmc: s/DRM_ERROR/drm_err
-:79: WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message
#79: FILE: drivers/gpu/drm/i915/display/intel_dmc.c:488:
if (!dmc->dmc_payload) {
+   drm_err(>drm, "Memory allocation failed for dmc 
payload\n");

total: 0 errors, 1 warnings, 0 checks, 130 lines checked
6da878e7a905 drm/i915/dmc: Add intel_dmc_has_payload() helper
249c6b8f711e drm/i915/dmc: Move struct intel_dmc to intel_dmc.h


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/3] drm/i915/dmc: Move struct intel_dmc to intel_dmc.h

[Anusha Srivatsa]

Move struct intel_dmc from i915_drv.h to intel_dmc.h.

Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_dmc.h | 17 +
 drivers/gpu/drm/i915/i915_drv.h  | 18 +-
 2 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dmc.h 
b/drivers/gpu/drm/i915/display/intel_dmc.h
index a928172459e3..8baeb85cf8db 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.h
+++ b/drivers/gpu/drm/i915/display/intel_dmc.h
@@ -16,6 +16,23 @@ struct drm_i915_private;
 #define DMC_VERSION_MAJOR(version) ((version) >> 16)
 #define DMC_VERSION_MINOR(version) ((version) & 0x)
 
+struct intel_dmc {
+   struct work_struct work;
+   const char *fw_path;
+   u32 required_version;
+   u32 max_fw_size; /* bytes */
+   u32 *dmc_payload;
+   u32 dmc_fw_size; /* dwords */
+   u32 version;
+   u32 mmio_count;
+   i915_reg_t mmioaddr[20];
+   u32 mmiodata[20];
+   u32 dc_state;
+   u32 target_dc_state;
+   u32 allowed_dc_mask;
+   intel_wakeref_t wakeref;
+};
+
 void intel_dmc_ucode_init(struct drm_i915_private *i915);
 void intel_dmc_load_program(struct drm_i915_private *i915);
 void intel_dmc_ucode_fini(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9cb02618ba15..b5962768a1f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -67,6 +67,7 @@
 #include "display/intel_bios.h"
 #include "display/intel_display.h"
 #include "display/intel_display_power.h"
+#include "display/intel_dmc.h"
 #include "display/intel_dpll_mgr.h"
 #include "display/intel_dsb.h"
 #include "display/intel_frontbuffer.h"
@@ -328,23 +329,6 @@ struct drm_i915_display_funcs {
void (*read_luts)(struct intel_crtc_state *crtc_state);
 };
 
-struct intel_dmc {
-   struct work_struct work;
-   const char *fw_path;
-   u32 required_version;
-   u32 max_fw_size; /* bytes */
-   u32 *dmc_payload;
-   u32 dmc_fw_size; /* dwords */
-   u32 version;
-   u32 mmio_count;
-   i915_reg_t mmioaddr[20];
-   u32 mmiodata[20];
-   u32 dc_state;
-   u32 target_dc_state;
-   u32 allowed_dc_mask;
-   intel_wakeref_t wakeref;
-};
-
 enum i915_cache_level {
I915_CACHE_NONE = 0,
I915_CACHE_LLC, /* also used for snoopable memory on non-LLC */
-- 
2.25.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/3] drm/i915/dmc: s/DRM_ERROR/drm_err

[Anusha Srivatsa]

Use new format of debug messages across intel_csr.

While at it, change some function definitions which now
need dev_priv for drm_err and drm_info etc.

v2: use container_of() (Jani)

Cc: Jani Nikula 
Suggested-by: Lucas De Marchi 
Signed-off-by: Anusha Srivatsa 
Reviewed-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_dmc.c | 42 ++--
 1 file changed, 24 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 560574dd929a..71ef6022d4af 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -400,6 +400,8 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
u32 mmio_count, mmio_count_max;
u8 *payload;
 
+   struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc);
+
BUILD_BUG_ON(ARRAY_SIZE(dmc->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
 ARRAY_SIZE(dmc->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);
 
@@ -439,28 +441,28 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
header_len_bytes = dmc_header->header_len;
dmc_header_size = sizeof(*v1);
} else {
-   DRM_ERROR("Unknown DMC fw header version: %u\n",
- dmc_header->header_ver);
+   drm_err(>drm, "Unknown DMC fw header version: %u\n",
+   dmc_header->header_ver);
return 0;
}
 
if (header_len_bytes != dmc_header_size) {
-   DRM_ERROR("DMC firmware has wrong dmc header length "
+   drm_err(>drm, "DMC firmware has wrong dmc header length "
  "(%u bytes)\n", header_len_bytes);
return 0;
}
 
/* Cache the dmc header info. */
if (mmio_count > mmio_count_max) {
-   DRM_ERROR("DMC firmware has wrong mmio count %u\n", mmio_count);
+   drm_err(>drm, "DMC firmware has wrong mmio count %u\n", 
mmio_count);
return 0;
}
 
for (i = 0; i < mmio_count; i++) {
if (mmioaddr[i] < DMC_MMIO_START_RANGE ||
mmioaddr[i] > DMC_MMIO_END_RANGE) {
-   DRM_ERROR("DMC firmware has wrong mmio address 0x%x\n",
- mmioaddr[i]);
+   drm_err(>drm, "DMC firmware has wrong mmio 
address 0x%x\n",
+   mmioaddr[i]);
return 0;
}
dmc->mmioaddr[i] = _MMIO(mmioaddr[i]);
@@ -476,14 +478,14 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
goto error_truncated;
 
if (payload_size > dmc->max_fw_size) {
-   DRM_ERROR("DMC FW too big (%u bytes)\n", payload_size);
+   drm_err(>drm, "DMC FW too big (%u bytes)\n", 
payload_size);
return 0;
}
dmc->dmc_fw_size = dmc_header->fw_size;
 
dmc->dmc_payload = kmalloc(payload_size, GFP_KERNEL);
if (!dmc->dmc_payload) {
-   DRM_ERROR("Memory allocation failed for dmc payload\n");
+   drm_err(>drm, "Memory allocation failed for dmc 
payload\n");
return 0;
}
 
@@ -493,7 +495,7 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
return header_len_bytes + payload_size;
 
 error_truncated:
-   DRM_ERROR("Truncated DMC firmware, refusing.\n");
+   drm_err(>drm, "Truncated DMC firmware, refusing.\n");
return 0;
 }
 
@@ -507,6 +509,8 @@ parse_dmc_fw_package(struct intel_dmc *dmc,
u32 num_entries, max_entries, dmc_offset;
const struct intel_fw_info *fw_info;
 
+   struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc);
+
if (rem_size < package_size)
goto error_truncated;
 
@@ -515,8 +519,8 @@ parse_dmc_fw_package(struct intel_dmc *dmc,
} else if (package_header->header_ver == 2) {
max_entries = PACKAGE_V2_MAX_FW_INFO_ENTRIES;
} else {
-   DRM_ERROR("DMC firmware has unknown header version %u\n",
- package_header->header_ver);
+   drm_err(>drm, "DMC firmware has unknown header version 
%u\n",
+   package_header->header_ver);
return 0;
}
 
@@ -529,8 +533,8 @@ parse_dmc_fw_package(struct intel_dmc *dmc,
goto error_truncated;
 
if (package_header->header_len * 4 != package_size) {
-   DRM_ERROR("DMC firmware has wrong package header length "
- "(%u bytes)\n", package_size);
+   drm_err(>drm, "DMC firmware has wrong package header 
length "
+   "(%u bytes)\n", package_size);
return 0;
}
 
@@ -543,8 +547,8 @@ parse_dmc_fw_package(struct intel_dmc *dmc,
dmc_offset = find_dmc_fw_offset(fw_info, num_entries, si,

[Intel-gfx] [PATCH 2/3] drm/i915/dmc: Add intel_dmc_has_payload() helper

[Anusha Srivatsa]

We check for dmc_payload being there at various points in the driver.
Replace it with the helper.

v2: rebased.
v3: Move intel_dmc to intel_dmc.h in another patch (Lucas)

Cc: Lucas De Marchi 
Signed-off-by: Anusha Srivatsa 
Reviewed-by: Lucas De Marchi 
---
 .../gpu/drm/i915/display/intel_display_debugfs.c |  4 ++--
 .../gpu/drm/i915/display/intel_display_power.c   | 16 
 drivers/gpu/drm/i915/display/intel_dmc.c | 13 +
 drivers/gpu/drm/i915/display/intel_dmc.h |  5 +
 drivers/gpu/drm/i915/i915_gpu_error.c|  2 +-
 5 files changed, 25 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 94e5cbd86e77..88bb05d5c483 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -542,10 +542,10 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
 
wakeref = intel_runtime_pm_get(_priv->runtime_pm);
 
-   seq_printf(m, "fw loaded: %s\n", yesno(dmc->dmc_payload));
+   seq_printf(m, "fw loaded: %s\n", 
yesno(intel_dmc_has_payload(dev_priv)));
seq_printf(m, "path: %s\n", dmc->fw_path);
 
-   if (!dmc->dmc_payload)
+   if (!intel_dmc_has_payload(dev_priv))
goto out;
 
seq_printf(m, "version: %d.%d\n", DMC_VERSION_MAJOR(dmc->version),
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 991ceea06a07..b546672c9b00 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -1220,7 +1220,7 @@ static void gen9_dc_off_power_well_enable(struct 
drm_i915_private *dev_priv,
 static void gen9_dc_off_power_well_disable(struct drm_i915_private *dev_priv,
   struct i915_power_well *power_well)
 {
-   if (!dev_priv->dmc.dmc_payload)
+   if (!intel_dmc_has_payload(dev_priv))
return;
 
switch (dev_priv->dmc.target_dc_state) {
@@ -5579,7 +5579,7 @@ static void skl_display_core_init(struct drm_i915_private 
*dev_priv,
 
gen9_dbuf_enable(dev_priv);
 
-   if (resume && dev_priv->dmc.dmc_payload)
+   if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
 }
 
@@ -5646,7 +5646,7 @@ static void bxt_display_core_init(struct drm_i915_private 
*dev_priv, bool resume
 
gen9_dbuf_enable(dev_priv);
 
-   if (resume && dev_priv->dmc.dmc_payload)
+   if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
 }
 
@@ -5712,7 +5712,7 @@ static void cnl_display_core_init(struct drm_i915_private 
*dev_priv, bool resume
/* 6. Enable DBUF */
gen9_dbuf_enable(dev_priv);
 
-   if (resume && dev_priv->dmc.dmc_payload)
+   if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
 }
 
@@ -5869,7 +5869,7 @@ static void icl_display_core_init(struct drm_i915_private 
*dev_priv,
if (DISPLAY_VER(dev_priv) >= 12)
tgl_bw_buddy_init(dev_priv);
 
-   if (resume && dev_priv->dmc.dmc_payload)
+   if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
 
/* Wa_14011508470 */
@@ -6230,7 +6230,7 @@ void intel_power_domains_suspend(struct drm_i915_private 
*i915,
 */
if (!(i915->dmc.allowed_dc_mask & DC_STATE_EN_DC9) &&
suspend_mode == I915_DRM_SUSPEND_IDLE &&
-   i915->dmc.dmc_payload) {
+   intel_dmc_has_payload(i915)) {
intel_display_power_flush_work(i915);
intel_power_domains_verify_state(i915);
return;
@@ -6420,7 +6420,7 @@ void intel_display_power_resume(struct drm_i915_private 
*i915)
if (DISPLAY_VER(i915) >= 11) {
bxt_disable_dc9(i915);
icl_display_core_init(i915, true);
-   if (i915->dmc.dmc_payload) {
+   if (intel_dmc_has_payload(i915)) {
if (i915->dmc.allowed_dc_mask &
DC_STATE_EN_UPTO_DC6)
skl_enable_dc6(i915);
@@ -6431,7 +6431,7 @@ void intel_display_power_resume(struct drm_i915_private 
*i915)
} else if (IS_GEMINILAKE(i915) || IS_BROXTON(i915)) {
bxt_disable_dc9(i915);
bxt_display_core_init(i915, true);
-   if (i915->dmc.dmc_payload &&
+   if (intel_dmc_has_payload(i915) &&
(i915->dmc.allowed_dc_mask & DC_STATE_EN_UPTO_DC5))
gen9_enable_dc5(i915);
} else if (IS_HASWELL(i915) || IS_BROADWELL(i915)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 71ef6022d4af..14282e5fdf8b 100644
--- 

[Intel-gfx] [PATCH 0/3] More DMC cleanup

[Anusha Srivatsa]

Last of prep patches before Pipe DMC patches
can land.

v2: Add struct intel_dmc to intel_dmc.h in a separate
patch

Anusha Srivatsa (3):
  drm/i915/dmc: s/DRM_ERROR/drm_err
  drm/i915/dmc: Add intel_dmc_has_payload() helper
  drm/i915/dmc: Move struct intel_dmc to intel_dmc.h

 .../drm/i915/display/intel_display_debugfs.c  |  4 +-
 .../drm/i915/display/intel_display_power.c| 16 +++---
 drivers/gpu/drm/i915/display/intel_dmc.c  | 55 +++
 drivers/gpu/drm/i915/display/intel_dmc.h  | 22 
 drivers/gpu/drm/i915/i915_drv.h   | 18 +-
 drivers/gpu/drm/i915/i915_gpu_error.c |  2 +-
 6 files changed, 67 insertions(+), 50 deletions(-)

-- 
2.25.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Mesa-dev] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan

[Jason Ekstrand]

On Thu, May 20, 2021 at 10:46 AM Matthew Brost  wrote:
>
> On Thu, May 20, 2021 at 01:11:59PM +0200, Christian König wrote:
> > Am 19.05.21 um 18:51 schrieb Matthew Brost:
> > > On Wed, May 19, 2021 at 01:45:39PM +0200, Christian König wrote:
> > > > Oh, yeah we call that gang submit on the AMD side.
> > > >
> > > > Had already some internal discussions how to implement this, but so far
> > > > couldn't figure out how to cleanly introduce that into the DRM 
> > > > scheduler.
> > > >
> > > > Can you briefly describe in a few words how that is supposed to work on 
> > > > the
> > > > Intel side?

On Intel, we actually have two cases which don't fit the current
drm/scheduler model well: balanced and bonded.

In the balanced model, we want to submit a batch which can go to any
one of some set of engines and we don't care which.  It's up to the
kernel to pick an engine.  Imagine you had 64 identical HW compute
queues, for instance.  This could be done by making all the identical
engines share a single drm_gpu_scheduler and round-robin around the HW
queues or something.  I don't know that we strictly need drm/scheduler
to be aware of it but it might be nice if it grew support for this
mode so we could maintain a 1:1 relationship between HW queues and
drm_gpu_schedulers.  That said, I'm not sure how this would play with
GuC queues so maybe it doesn't help?

The bonded model is like your ganged, I think.  We want to submit N
batches to run in parallel.  And they actually have to be executing on
the GPU simultaneously and not just sort-of at similar times.  We need
this for video.  There are also potential use-cases in Vulkan or even
GL that might be able to use this.  One difference with the balanced
mode is that bonds don't, strictly speaking, need to be on the same
type of engine.  Imagine, for instance, a 3D batch with a parallel
compute batch doing vertex pre-processing.

I'm pretty sure the bonded case is something that the mobile drivers
(panfrost, etc.) would like as well for doing Vulkan on tilers where
you often have to have two command buffers running in parallel.
They're currently doing it by submitting a giant pile of batches where
they split the batch and add sync primitives every time some GL call
requires them to sync between fragment and vertex pipes.

So, to sum up, I think there's likely some good collaboration to be
had here for everyone. :-)

--Jason

> > > Sure, I've done a quick PoC internally and have been able to hook this
> > > into the DRM scheduler.
> > >
> > > Basically each BB still maps to a single job as each job is somewhat
> > > unique (e.g. each job has its own ring, lrc, seqno, etc...). However all
> > > the jobs configured to run in parallel map to a single sched_entity
> > > which maintains the order each job was generated from the execbuf IOCTL
> > > (1 - N). When the backend receives jobs 1 to N - 1 it basically just
> > > updates some internal state. When the backend sees job N (last job) it
> > > actually does the submit for jobs 1 - N which with GuC submission is a
> > > simple command moving the LRC tail of the N jobs.
> > >
> > > Daniel has suggested that we create a single job for the NN BBs but that
> > > would be huge rework to the internals of the i915 and likely won't
> > > happen by the time this code first lands.
> > >
> > > Also worth noting one way a job isn't really a treated individually is
> > > the excl slot with dma-resv. In that case we create a composite fence of
> > > all jobs (dma_fence_array).
> >
> > Yeah, that's something we have discussed as well.
> >
> > How do you prevent the scheduler from over committing to a single ring
> > buffer in this scenario?
> >
>
> Each job has its own ring, the execbuf IOCTL throttles itself for each
> job if there isn't space in the ring. This is exactly the same as
> non-parallel submits.
>
> I think this is what you were asking? If not, maybe try explaining the
> question a bit more.
>
> Matt
>
> > Christian.
> >
> > >
> > > Matt
> > >
> > > > Thanks,
> > > > Christian.
> > > >
> > > > Am 19.05.21 um 01:58 schrieb Matthew Brost:
> > > > > Add entry fpr i915 new parallel submission uAPI plan.
> > > > >
> > > > > v2:
> > > > >(Daniel Vetter):
> > > > > - Expand logical order explaination
> > > > > - Add dummy header
> > > > > - Only allow N BBs in execbuf IOCTL
> > > > > - Configure parallel submission per slot not per gem context
> > > > >
> > > > > Cc: Tvrtko Ursulin 
> > > > > Cc: Tony Ye 
> > > > > CC: Carl Zhang 
> > > > > Cc: Daniel Vetter 
> > > > > Cc: Jason Ekstrand 
> > > > > Signed-off-by: Matthew Brost 
> > > > > ---
> > > > >Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 
> > > > > ++
> > > > >Documentation/gpu/rfc/i915_scheduler.rst  |  53 ++-
> > > > >2 files changed, 196 insertions(+), 1 deletion(-)
> > > > >create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > >
> > > > > diff --git 

Re: [Intel-gfx] (subset) [PATCH 1/3] gpu: drm: replace occurrences of invalid character

[Mark Brown]

On Wed, 19 May 2021 10:15:35 +0200, Mauro Carvalho Chehab wrote:
> There are some places at drm that ended receiving a
> REPLACEMENT CHARACTER U+fffd ('�'), probably because of
> some bad charset conversion.
> 
> Fix them by using what it seems   to be the proper
> character.

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[2/3] spi: fix some invalid char occurrences
  commit: 6328caf043208556e782a53a284c9acfcf6be3b0

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dmc: Add intel_dmc_has_payload() helper

[Lucas De Marchi]

On Thu, May 20, 2021 at 11:36:08AM -0700, Anusha Srivatsa wrote:

We check for dmc_payload being there at various points in the driver.
Replace it with the helper.

v2: rebased.

Cc: Lucas De Marchi 
Signed-off-by: Anusha Srivatsa 
---
.../drm/i915/display/intel_display_debugfs.c  |  4 ++--
.../drm/i915/display/intel_display_power.c| 16 +++---
drivers/gpu/drm/i915/display/intel_dmc.c  | 13 +++
drivers/gpu/drm/i915/display/intel_dmc.h  | 22 +++
drivers/gpu/drm/i915/i915_drv.h   | 18 +--
drivers/gpu/drm/i915/i915_gpu_error.c |  2 +-
6 files changed, 43 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 94e5cbd86e77..88bb05d5c483 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -542,10 +542,10 @@ static int i915_dmc_info(struct seq_file *m, void *unused)

wakeref = intel_runtime_pm_get(_priv->runtime_pm);

-   seq_printf(m, "fw loaded: %s\n", yesno(dmc->dmc_payload));
+   seq_printf(m, "fw loaded: %s\n", 
yesno(intel_dmc_has_payload(dev_priv)));
seq_printf(m, "path: %s\n", dmc->fw_path);

-   if (!dmc->dmc_payload)
+   if (!intel_dmc_has_payload(dev_priv))
goto out;

seq_printf(m, "version: %d.%d\n", DMC_VERSION_MAJOR(dmc->version),
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 991ceea06a07..b546672c9b00 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -1220,7 +1220,7 @@ static void gen9_dc_off_power_well_enable(struct 
drm_i915_private *dev_priv,
static void gen9_dc_off_power_well_disable(struct drm_i915_private *dev_priv,
   struct i915_power_well *power_well)
{
-   if (!dev_priv->dmc.dmc_payload)
+   if (!intel_dmc_has_payload(dev_priv))
return;

switch (dev_priv->dmc.target_dc_state) {
@@ -5579,7 +5579,7 @@ static void skl_display_core_init(struct drm_i915_private 
*dev_priv,

gen9_dbuf_enable(dev_priv);

-   if (resume && dev_priv->dmc.dmc_payload)
+   if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
}

@@ -5646,7 +5646,7 @@ static void bxt_display_core_init(struct drm_i915_private 
*dev_priv, bool resume

gen9_dbuf_enable(dev_priv);

-   if (resume && dev_priv->dmc.dmc_payload)
+   if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
}

@@ -5712,7 +5712,7 @@ static void cnl_display_core_init(struct drm_i915_private 
*dev_priv, bool resume
/* 6. Enable DBUF */
gen9_dbuf_enable(dev_priv);

-   if (resume && dev_priv->dmc.dmc_payload)
+   if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
}

@@ -5869,7 +5869,7 @@ static void icl_display_core_init(struct drm_i915_private 
*dev_priv,
if (DISPLAY_VER(dev_priv) >= 12)
tgl_bw_buddy_init(dev_priv);

-   if (resume && dev_priv->dmc.dmc_payload)
+   if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);

/* Wa_14011508470 */
@@ -6230,7 +6230,7 @@ void intel_power_domains_suspend(struct drm_i915_private 
*i915,
 */
if (!(i915->dmc.allowed_dc_mask & DC_STATE_EN_DC9) &&
suspend_mode == I915_DRM_SUSPEND_IDLE &&
-   i915->dmc.dmc_payload) {
+   intel_dmc_has_payload(i915)) {
intel_display_power_flush_work(i915);
intel_power_domains_verify_state(i915);
return;
@@ -6420,7 +6420,7 @@ void intel_display_power_resume(struct drm_i915_private 
*i915)
if (DISPLAY_VER(i915) >= 11) {
bxt_disable_dc9(i915);
icl_display_core_init(i915, true);
-   if (i915->dmc.dmc_payload) {
+   if (intel_dmc_has_payload(i915)) {
if (i915->dmc.allowed_dc_mask &
DC_STATE_EN_UPTO_DC6)
skl_enable_dc6(i915);
@@ -6431,7 +6431,7 @@ void intel_display_power_resume(struct drm_i915_private 
*i915)
} else if (IS_GEMINILAKE(i915) || IS_BROXTON(i915)) {
bxt_disable_dc9(i915);
bxt_display_core_init(i915, true);
-   if (i915->dmc.dmc_payload &&
+   if (intel_dmc_has_payload(i915) &&
(i915->dmc.allowed_dc_mask & DC_STATE_EN_UPTO_DC5))
gen9_enable_dc5(i915);
} else if (IS_HASWELL(i915) || IS_BROADWELL(i915)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index d71758cd0b18..a663d1df8962 100644
--- 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/dmc: s/DRM_ERROR/drm_err

[Lucas De Marchi]

On Thu, May 20, 2021 at 11:36:07AM -0700, Anusha Srivatsa wrote:

Use new format of debug messages across intel_csr.

While at it, change some function definitions which now
need dev_priv for drm_err and drm_info etc.

v2: use container_of() (Jani)

Cc: Jani Nikula 
Suggested-by: Lucas De Marchi 
Signed-off-by: Anusha Srivatsa 


`git show -U0 --word-diff=color`  + `git grep`  say you covered them
all, but you also need to fix checkpatch (it's a great idea to run it
locally when doing changes like this:

dim checkpatch origin/drm-tip

With checkpatch fixed,


Reviewed-by: Lucas De Marchi 

Lucas De Marchi


---
drivers/gpu/drm/i915/display/intel_dmc.c | 39 ++--
1 file changed, 23 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 560574dd929a..d71758cd0b18 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -400,6 +400,8 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
u32 mmio_count, mmio_count_max;
u8 *payload;

+   struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc);
+
BUILD_BUG_ON(ARRAY_SIZE(dmc->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
 ARRAY_SIZE(dmc->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);

@@ -439,28 +441,28 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
header_len_bytes = dmc_header->header_len;
dmc_header_size = sizeof(*v1);
} else {
-   DRM_ERROR("Unknown DMC fw header version: %u\n",
+   drm_err(>drm, "Unknown DMC fw header version: %u\n",
  dmc_header->header_ver);
return 0;
}

if (header_len_bytes != dmc_header_size) {
-   DRM_ERROR("DMC firmware has wrong dmc header length "
+   drm_err(>drm, "DMC firmware has wrong dmc header length "
  "(%u bytes)\n", header_len_bytes);
return 0;
}

/* Cache the dmc header info. */
if (mmio_count > mmio_count_max) {
-   DRM_ERROR("DMC firmware has wrong mmio count %u\n", mmio_count);
+   drm_err(>drm, "DMC firmware has wrong mmio count %u\n", 
mmio_count);
return 0;
}

for (i = 0; i < mmio_count; i++) {
if (mmioaddr[i] < DMC_MMIO_START_RANGE ||
mmioaddr[i] > DMC_MMIO_END_RANGE) {
-   DRM_ERROR("DMC firmware has wrong mmio address 0x%x\n",
- mmioaddr[i]);
+   drm_err(>drm, "DMC firmware has wrong mmio address 
0x%x\n",
+   mmioaddr[i]);
return 0;
}
dmc->mmioaddr[i] = _MMIO(mmioaddr[i]);
@@ -476,14 +478,14 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
goto error_truncated;

if (payload_size > dmc->max_fw_size) {
-   DRM_ERROR("DMC FW too big (%u bytes)\n", payload_size);
+   drm_err(>drm, "DMC FW too big (%u bytes)\n", 
payload_size);
return 0;
}
dmc->dmc_fw_size = dmc_header->fw_size;

dmc->dmc_payload = kmalloc(payload_size, GFP_KERNEL);
if (!dmc->dmc_payload) {
-   DRM_ERROR("Memory allocation failed for dmc payload\n");
+   drm_err(>drm, "Memory allocation failed for dmc 
payload\n");
return 0;
}

@@ -493,7 +495,7 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
return header_len_bytes + payload_size;

error_truncated:
-   DRM_ERROR("Truncated DMC firmware, refusing.\n");
+   drm_err(>drm, "Truncated DMC firmware, refusing.\n");
return 0;
}

@@ -507,6 +509,8 @@ parse_dmc_fw_package(struct intel_dmc *dmc,
u32 num_entries, max_entries, dmc_offset;
const struct intel_fw_info *fw_info;

+   struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc);
+
if (rem_size < package_size)
goto error_truncated;

@@ -515,7 +519,7 @@ parse_dmc_fw_package(struct intel_dmc *dmc,
} else if (package_header->header_ver == 2) {
max_entries = PACKAGE_V2_MAX_FW_INFO_ENTRIES;
} else {
-   DRM_ERROR("DMC firmware has unknown header version %u\n",
+   drm_err(>drm, "DMC firmware has unknown header version 
%u\n",
  package_header->header_ver);
return 0;
}
@@ -529,8 +533,8 @@ parse_dmc_fw_package(struct intel_dmc *dmc,
goto error_truncated;

if (package_header->header_len * 4 != package_size) {
-   DRM_ERROR("DMC firmware has wrong package header length "
- "(%u bytes)\n", package_size);
+   drm_err(>drm, "DMC firmware has wrong package header length 
"
+   "(%u 

Re: [Intel-gfx] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan

[Daniel Vetter]

On Thu, May 20, 2021 at 08:10:59AM -0700, Matthew Brost wrote:
> On Thu, May 20, 2021 at 11:54:25AM +0200, Daniel Vetter wrote:
> > On Wed, May 19, 2021 at 7:19 PM Matthew Brost  
> > wrote:
> > >
> > > On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wrote:
> > > > On Tue, May 18, 2021 at 04:58:30PM -0700, Matthew Brost wrote:
> > > > > Add entry fpr i915 new parallel submission uAPI plan.
> > > > >
> > > > > v2:
> > > > >  (Daniel Vetter):
> > > > >   - Expand logical order explaination
> > > > >   - Add dummy header
> > > > >   - Only allow N BBs in execbuf IOCTL
> > > > >   - Configure parallel submission per slot not per gem context
> > > > >
> > > > > Cc: Tvrtko Ursulin 
> > > > > Cc: Tony Ye 
> > > > > CC: Carl Zhang 
> > > > > Cc: Daniel Vetter 
> > > > > Cc: Jason Ekstrand 
> > > > > Signed-off-by: Matthew Brost 
> > > > > ---
> > > > >  Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 
> > > > > ++
> > > > >  Documentation/gpu/rfc/i915_scheduler.rst  |  53 ++-
> > > > >  2 files changed, 196 insertions(+), 1 deletion(-)
> > > > >  create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > >
> > > > > diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h 
> > > > > b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > > new file mode 100644
> > > > > index ..8c64b983ccad
> > > > > --- /dev/null
> > > > > +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > > @@ -0,0 +1,144 @@
> > > > > +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see 
> > > > > i915_context_engines_parallel_submit */
> > > > > +
> > > > > +/*
> > > > > + * i915_context_engines_parallel_submit:
> > > > > + *
> > > > > + * Setup a slot to allow multiple BBs to be submitted in a single 
> > > > > execbuf IOCTL.
> > > > > + * Those BBs will then be scheduled to run on the GPU in parallel. 
> > > > > Multiple
> > > > > + * hardware contexts are created internally in the i915 run these 
> > > > > BBs. Once a
> > > > > + * slot is configured for N BBs only N BBs can be submitted in each 
> > > > > execbuf
> > > > > + * IOCTL and this is implict behavior (e.g. the user doesn't tell 
> > > > > the execbuf
> > > > > + * IOCTL there are N BBs, the execbuf IOCTL know how many BBs there 
> > > > > are based on
> > > > > + * the slots configuration).
> > > > > + *
> > > > > + * Their are two currently defined ways to control the placement of 
> > > > > the
> > > > > + * hardware contexts on physical engines: default behavior (no 
> > > > > flags) and
> > > > > + * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the 
> > > > > in the
> > > > > + * future as new hardware / use cases arise. Details of how to use 
> > > > > this
> > > > > + * interface below above the flags.
> > > > > + *
> > > > > + * Returns -EINVAL if hardware context placement configuration 
> > > > > invalid or if the
> > > > > + * placement configuration isn't supported on the platform / 
> > > > > submission
> > > > > + * interface.
> > > > > + * Returns -ENODEV if extension isn't supported on the platform / 
> > > > > submission
> > > > > + * inteface.
> > > > > + */
> > > > > +struct i915_context_engines_parallel_submit {
> > > > > +   struct i915_user_extension base;
> > > > > +
> > > > > +   __u16 engine_index; /* slot for parallel engine */
> > > > > +   __u16 width;/* number of contexts per parallel engine 
> > > > > */
> > > > > +   __u16 num_siblings; /* number of siblings per context */
> > > > > +   __u16 mbz16;
> > > >
> > > > Ok the big picture looks reasonable now, the flags still confuse me.
> > > >
> > >
> > > Yea, it is a bit confusing.
> > >
> > > > > +/*
> > > > > + * Default placement behvavior (currently unsupported):
> > > > > + *
> > > > > + * Rather than restricting parallel submission to a single class 
> > > > > with a
> > > > > + * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS), add 
> > > > > a mode that
> > > > > + * enables parallel submission across multiple engine classes. In 
> > > > > this case each
> > > > > + * context's logical engine mask indicates where that context can 
> > > > > placed. It is
> > > > > + * implied in this mode that all contexts have mutual exclusive 
> > > > > placement (e.g.
> > > > > + * if one context is running CS0 no other contexts can run on CS0).
> > > > > + *
> > > > > + * Example 1 pseudo code:
> > > > > + * CSX[Y] = engine class X, logical instance Y
> > > > > + * INVALID = I915_ENGINE_CLASS_INVALID, 
> > > > > I915_ENGINE_CLASS_INVALID_NONE
> > > > > + * set_engines(INVALID)
> > > > > + * set_parallel(engine_index=0, width=2, num_siblings=2,
> > > > > + * engines=CS0[0],CS0[1],CS1[0],CS1[1])
> > > > > + *
> > > > > + * Results in the following valid placements:
> > > > > + * CS0[0], CS1[0]
> > > > > + * CS0[0], CS1[1]
> > > > > + * CS0[1], CS1[0]
> > > > > + * CS0[1], CS1[1]
> > > > > + *
> > > > > + * This can also be though of as 2 virtual engines:
> > > > > + * VE[0] 

Re: [Intel-gfx] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan

[Daniel Vetter]

On Thu, May 20, 2021 at 11:57:44AM +0100, Tvrtko Ursulin wrote:
> 
> On 20/05/2021 10:54, Daniel Vetter wrote:
> > On Wed, May 19, 2021 at 7:19 PM Matthew Brost  
> > wrote:
> > > 
> > > On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wrote:
> > > > On Tue, May 18, 2021 at 04:58:30PM -0700, Matthew Brost wrote:
> > > > > Add entry fpr i915 new parallel submission uAPI plan.
> > > > > 
> > > > > v2:
> > > > >   (Daniel Vetter):
> > > > >- Expand logical order explaination
> > > > >- Add dummy header
> > > > >- Only allow N BBs in execbuf IOCTL
> > > > >- Configure parallel submission per slot not per gem context
> > > > > 
> > > > > Cc: Tvrtko Ursulin 
> > > > > Cc: Tony Ye 
> > > > > CC: Carl Zhang 
> > > > > Cc: Daniel Vetter 
> > > > > Cc: Jason Ekstrand 
> > > > > Signed-off-by: Matthew Brost 
> > > > > ---
> > > > >   Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 
> > > > > ++
> > > > >   Documentation/gpu/rfc/i915_scheduler.rst  |  53 ++-
> > > > >   2 files changed, 196 insertions(+), 1 deletion(-)
> > > > >   create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > > 
> > > > > diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h 
> > > > > b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > > new file mode 100644
> > > > > index ..8c64b983ccad
> > > > > --- /dev/null
> > > > > +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > > @@ -0,0 +1,144 @@
> > > > > +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see 
> > > > > i915_context_engines_parallel_submit */
> > > > > +
> > > > > +/*
> > > > > + * i915_context_engines_parallel_submit:
> > > > > + *
> > > > > + * Setup a slot to allow multiple BBs to be submitted in a single 
> > > > > execbuf IOCTL.
> > > > > + * Those BBs will then be scheduled to run on the GPU in parallel. 
> > > > > Multiple
> > > > > + * hardware contexts are created internally in the i915 run these 
> > > > > BBs. Once a
> > > > > + * slot is configured for N BBs only N BBs can be submitted in each 
> > > > > execbuf
> > > > > + * IOCTL and this is implict behavior (e.g. the user doesn't tell 
> > > > > the execbuf
> > > > > + * IOCTL there are N BBs, the execbuf IOCTL know how many BBs there 
> > > > > are based on
> > > > > + * the slots configuration).
> > > > > + *
> > > > > + * Their are two currently defined ways to control the placement of 
> > > > > the
> > > > > + * hardware contexts on physical engines: default behavior (no 
> > > > > flags) and
> > > > > + * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the 
> > > > > in the
> > > > > + * future as new hardware / use cases arise. Details of how to use 
> > > > > this
> > > > > + * interface below above the flags.
> > > > > + *
> > > > > + * Returns -EINVAL if hardware context placement configuration 
> > > > > invalid or if the
> > > > > + * placement configuration isn't supported on the platform / 
> > > > > submission
> > > > > + * interface.
> > > > > + * Returns -ENODEV if extension isn't supported on the platform / 
> > > > > submission
> > > > > + * inteface.
> > > > > + */
> > > > > +struct i915_context_engines_parallel_submit {
> > > > > +   struct i915_user_extension base;
> > > > > +
> > > > > +   __u16 engine_index; /* slot for parallel engine */
> > > > > +   __u16 width;/* number of contexts per parallel engine 
> > > > > */
> > > > > +   __u16 num_siblings; /* number of siblings per context */
> > > > > +   __u16 mbz16;
> > > > 
> > > > Ok the big picture looks reasonable now, the flags still confuse me.
> > > > 
> > > 
> > > Yea, it is a bit confusing.
> > > 
> > > > > +/*
> > > > > + * Default placement behvavior (currently unsupported):
> > > > > + *
> > > > > + * Rather than restricting parallel submission to a single class 
> > > > > with a
> > > > > + * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS), add 
> > > > > a mode that
> > > > > + * enables parallel submission across multiple engine classes. In 
> > > > > this case each
> > > > > + * context's logical engine mask indicates where that context can 
> > > > > placed. It is
> > > > > + * implied in this mode that all contexts have mutual exclusive 
> > > > > placement (e.g.
> > > > > + * if one context is running CS0 no other contexts can run on CS0).
> > > > > + *
> > > > > + * Example 1 pseudo code:
> > > > > + * CSX[Y] = engine class X, logical instance Y
> > > > > + * INVALID = I915_ENGINE_CLASS_INVALID, 
> > > > > I915_ENGINE_CLASS_INVALID_NONE
> > > > > + * set_engines(INVALID)
> > > > > + * set_parallel(engine_index=0, width=2, num_siblings=2,
> > > > > + * engines=CS0[0],CS0[1],CS1[0],CS1[1])
> > > > > + *
> > > > > + * Results in the following valid placements:
> > > > > + * CS0[0], CS1[0]
> > > > > + * CS0[0], CS1[1]
> > > > > + * CS0[1], CS1[0]
> > > > > + * CS0[1], CS1[1]
> > > > > + *
> > > > > + * This can also be though of as 2 virtual engines:
> > > > > + * VE[0] 

[Intel-gfx] ✓ Fi.CI.BAT: success for More DMC cleanup

[Patchwork]

== Series Details ==

Series: More DMC cleanup
URL   : https://patchwork.freedesktop.org/series/90379/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10113 -> Patchwork_20164


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][1] -> [INCOMPLETE][2] ([i915#2782])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20164/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-bdw-5557u:   NOTRUN -> [SKIP][3] ([fdo#109271]) +3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20164/fi-bdw-5557u/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u:   NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20164/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}:   [DMESG-WARN][5] ([i915#3303]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20164/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-icl-u2:  [DMESG-WARN][7] ([i915#2868]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20164/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html

  
 Warnings 

  * igt@runner@aborted:
- fi-skl-6600u:   [FAIL][9] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][10] ([i915#1436] / [i915#3363])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-skl-6600u/igt@run...@aborted.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20164/fi-skl-6600u/igt@run...@aborted.html
- fi-glk-dsi: [FAIL][11] ([i915#2426] / [i915#3363] / 
[k.org#202321]) -> [FAIL][12] ([i915#3363] / [k.org#202321])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-glk-dsi/igt@run...@aborted.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20164/fi-glk-dsi/igt@run...@aborted.html
- fi-kbl-soraka:  [FAIL][13] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][14] ([i915#1436] / [i915#3363])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-kbl-soraka/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20164/fi-kbl-soraka/igt@run...@aborted.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#2868]: https://gitlab.freedesktop.org/drm/intel/issues/2868
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321


Participating hosts (42 -> 39)
--

  Missing(3): fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_10113 -> Patchwork_20164

  CI-20190529: 20190529
  CI_DRM_10113: 7a90018e59889ff846d0b9ec9fa4cad75ef978d7 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6089: 698613116728db5000759e69c074ce6ab2131765 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_20164: 141fc1f5685d30522a896a1f08a96ddfdef37204 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

141fc1f5685d drm/i915/dmc: Add intel_dmc_has_payload() helper
a52e01980968 drm/i915/dmc: s/DRM_ERROR/drm_err

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20164/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for More DMC cleanup

[Patchwork]

== Series Details ==

Series: More DMC cleanup
URL   : https://patchwork.freedesktop.org/series/90379/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a52e01980968 drm/i915/dmc: s/DRM_ERROR/drm_err
-:36: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#36: FILE: drivers/gpu/drm/i915/display/intel_dmc.c:445:
+   drm_err(>drm, "Unknown DMC fw header version: %u\n",
  dmc_header->header_ver);

-:77: WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message
#77: FILE: drivers/gpu/drm/i915/display/intel_dmc.c:488:
if (!dmc->dmc_payload) {
+   drm_err(>drm, "Memory allocation failed for dmc 
payload\n");

-:105: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#105: FILE: drivers/gpu/drm/i915/display/intel_dmc.c:523:
+   drm_err(>drm, "DMC firmware has unknown header version 
%u\n",
  package_header->header_ver);

-:143: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#143: FILE: drivers/gpu/drm/i915/display/intel_dmc.c:568:
 {
+

total: 0 errors, 1 warnings, 3 checks, 128 lines checked
141fc1f5685d drm/i915/dmc: Add intel_dmc_has_payload() helper


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp_mst: Use kHz as link rate units when settig source max link caps at init (rev2)

[Patchwork]

== Series Details ==

Series: drm/dp_mst: Use kHz as link rate units when settig source max link caps 
at init (rev2)
URL   : https://patchwork.freedesktop.org/series/90099/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10113 -> Patchwork_20163


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u:   NOTRUN -> [WARN][1] ([i915#2283])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_selftest@live@execlists:
- fi-bdw-5557u:   NOTRUN -> [DMESG-FAIL][2] ([i915#3462])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][3] -> [INCOMPLETE][4] ([i915#2782])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [PASS][5] -> [FAIL][6] ([i915#1372])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
- fi-bdw-5557u:   NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u:   NOTRUN -> [SKIP][8] ([fdo#109271]) +9 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}:   [DMESG-WARN][9] ([i915#3303]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-icl-u2:  [DMESG-WARN][11] ([i915#2868]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html

  
 Warnings 

  * igt@i915_selftest@live@execlists:
- fi-icl-u2:  [DMESG-FAIL][13] ([i915#3462]) -> [INCOMPLETE][14] 
([i915#2782] / [i915#3462])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-icl-u2/igt@i915_selftest@l...@execlists.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/fi-icl-u2/igt@i915_selftest@l...@execlists.html

  * igt@runner@aborted:
- fi-skl-6600u:   [FAIL][15] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][16] ([i915#1436] / [i915#3363])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-skl-6600u/igt@run...@aborted.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/fi-skl-6600u/igt@run...@aborted.html
- fi-icl-u2:  [FAIL][17] ([i915#2426] / [i915#2782] / [i915#3363]) 
-> [FAIL][18] ([i915#2782] / [i915#3363])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-icl-u2/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/fi-icl-u2/igt@run...@aborted.html
- fi-bdw-5557u:   [FAIL][19] ([i915#1602] / [i915#2029]) -> [FAIL][20] 
([i915#3462])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-bdw-5557u/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/fi-bdw-5557u/igt@run...@aborted.html
- fi-kbl-soraka:  [FAIL][21] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][22] ([i915#1436] / [i915#3363])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-kbl-soraka/igt@run...@aborted.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/fi-kbl-soraka/igt@run...@aborted.html
- fi-kbl-7567u:   [FAIL][23] ([i915#1436] / [i915#3363]) -> [FAIL][24] 
([i915#1436] / [i915#2426] / [i915#3363])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-kbl-7567u/igt@run...@aborted.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20163/fi-kbl-7567u/igt@run...@aborted.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the 

[Intel-gfx] [PATCH 2/2] drm/i915/dmc: Add intel_dmc_has_payload() helper

[Anusha Srivatsa]

We check for dmc_payload being there at various points in the driver.
Replace it with the helper.

v2: rebased.

Cc: Lucas De Marchi 
Signed-off-by: Anusha Srivatsa 
---
 .../drm/i915/display/intel_display_debugfs.c  |  4 ++--
 .../drm/i915/display/intel_display_power.c| 16 +++---
 drivers/gpu/drm/i915/display/intel_dmc.c  | 13 +++
 drivers/gpu/drm/i915/display/intel_dmc.h  | 22 +++
 drivers/gpu/drm/i915/i915_drv.h   | 18 +--
 drivers/gpu/drm/i915/i915_gpu_error.c |  2 +-
 6 files changed, 43 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 94e5cbd86e77..88bb05d5c483 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -542,10 +542,10 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
 
wakeref = intel_runtime_pm_get(_priv->runtime_pm);
 
-   seq_printf(m, "fw loaded: %s\n", yesno(dmc->dmc_payload));
+   seq_printf(m, "fw loaded: %s\n", 
yesno(intel_dmc_has_payload(dev_priv)));
seq_printf(m, "path: %s\n", dmc->fw_path);
 
-   if (!dmc->dmc_payload)
+   if (!intel_dmc_has_payload(dev_priv))
goto out;
 
seq_printf(m, "version: %d.%d\n", DMC_VERSION_MAJOR(dmc->version),
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 991ceea06a07..b546672c9b00 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -1220,7 +1220,7 @@ static void gen9_dc_off_power_well_enable(struct 
drm_i915_private *dev_priv,
 static void gen9_dc_off_power_well_disable(struct drm_i915_private *dev_priv,
   struct i915_power_well *power_well)
 {
-   if (!dev_priv->dmc.dmc_payload)
+   if (!intel_dmc_has_payload(dev_priv))
return;
 
switch (dev_priv->dmc.target_dc_state) {
@@ -5579,7 +5579,7 @@ static void skl_display_core_init(struct drm_i915_private 
*dev_priv,
 
gen9_dbuf_enable(dev_priv);
 
-   if (resume && dev_priv->dmc.dmc_payload)
+   if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
 }
 
@@ -5646,7 +5646,7 @@ static void bxt_display_core_init(struct drm_i915_private 
*dev_priv, bool resume
 
gen9_dbuf_enable(dev_priv);
 
-   if (resume && dev_priv->dmc.dmc_payload)
+   if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
 }
 
@@ -5712,7 +5712,7 @@ static void cnl_display_core_init(struct drm_i915_private 
*dev_priv, bool resume
/* 6. Enable DBUF */
gen9_dbuf_enable(dev_priv);
 
-   if (resume && dev_priv->dmc.dmc_payload)
+   if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
 }
 
@@ -5869,7 +5869,7 @@ static void icl_display_core_init(struct drm_i915_private 
*dev_priv,
if (DISPLAY_VER(dev_priv) >= 12)
tgl_bw_buddy_init(dev_priv);
 
-   if (resume && dev_priv->dmc.dmc_payload)
+   if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
 
/* Wa_14011508470 */
@@ -6230,7 +6230,7 @@ void intel_power_domains_suspend(struct drm_i915_private 
*i915,
 */
if (!(i915->dmc.allowed_dc_mask & DC_STATE_EN_DC9) &&
suspend_mode == I915_DRM_SUSPEND_IDLE &&
-   i915->dmc.dmc_payload) {
+   intel_dmc_has_payload(i915)) {
intel_display_power_flush_work(i915);
intel_power_domains_verify_state(i915);
return;
@@ -6420,7 +6420,7 @@ void intel_display_power_resume(struct drm_i915_private 
*i915)
if (DISPLAY_VER(i915) >= 11) {
bxt_disable_dc9(i915);
icl_display_core_init(i915, true);
-   if (i915->dmc.dmc_payload) {
+   if (intel_dmc_has_payload(i915)) {
if (i915->dmc.allowed_dc_mask &
DC_STATE_EN_UPTO_DC6)
skl_enable_dc6(i915);
@@ -6431,7 +6431,7 @@ void intel_display_power_resume(struct drm_i915_private 
*i915)
} else if (IS_GEMINILAKE(i915) || IS_BROXTON(i915)) {
bxt_disable_dc9(i915);
bxt_display_core_init(i915, true);
-   if (i915->dmc.dmc_payload &&
+   if (intel_dmc_has_payload(i915) &&
(i915->dmc.allowed_dc_mask & DC_STATE_EN_UPTO_DC5))
gen9_enable_dc5(i915);
} else if (IS_HASWELL(i915) || IS_BROADWELL(i915)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index d71758cd0b18..a663d1df8962 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ 

[Intel-gfx] [PATCH 1/2] drm/i915/dmc: s/DRM_ERROR/drm_err

[Anusha Srivatsa]

Use new format of debug messages across intel_csr.

While at it, change some function definitions which now
need dev_priv for drm_err and drm_info etc.

v2: use container_of() (Jani)

Cc: Jani Nikula 
Suggested-by: Lucas De Marchi 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_dmc.c | 39 ++--
 1 file changed, 23 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 560574dd929a..d71758cd0b18 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -400,6 +400,8 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
u32 mmio_count, mmio_count_max;
u8 *payload;
 
+   struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc);
+
BUILD_BUG_ON(ARRAY_SIZE(dmc->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
 ARRAY_SIZE(dmc->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);
 
@@ -439,28 +441,28 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
header_len_bytes = dmc_header->header_len;
dmc_header_size = sizeof(*v1);
} else {
-   DRM_ERROR("Unknown DMC fw header version: %u\n",
+   drm_err(>drm, "Unknown DMC fw header version: %u\n",
  dmc_header->header_ver);
return 0;
}
 
if (header_len_bytes != dmc_header_size) {
-   DRM_ERROR("DMC firmware has wrong dmc header length "
+   drm_err(>drm, "DMC firmware has wrong dmc header length "
  "(%u bytes)\n", header_len_bytes);
return 0;
}
 
/* Cache the dmc header info. */
if (mmio_count > mmio_count_max) {
-   DRM_ERROR("DMC firmware has wrong mmio count %u\n", mmio_count);
+   drm_err(>drm, "DMC firmware has wrong mmio count %u\n", 
mmio_count);
return 0;
}
 
for (i = 0; i < mmio_count; i++) {
if (mmioaddr[i] < DMC_MMIO_START_RANGE ||
mmioaddr[i] > DMC_MMIO_END_RANGE) {
-   DRM_ERROR("DMC firmware has wrong mmio address 0x%x\n",
- mmioaddr[i]);
+   drm_err(>drm, "DMC firmware has wrong mmio 
address 0x%x\n",
+   mmioaddr[i]);
return 0;
}
dmc->mmioaddr[i] = _MMIO(mmioaddr[i]);
@@ -476,14 +478,14 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
goto error_truncated;
 
if (payload_size > dmc->max_fw_size) {
-   DRM_ERROR("DMC FW too big (%u bytes)\n", payload_size);
+   drm_err(>drm, "DMC FW too big (%u bytes)\n", 
payload_size);
return 0;
}
dmc->dmc_fw_size = dmc_header->fw_size;
 
dmc->dmc_payload = kmalloc(payload_size, GFP_KERNEL);
if (!dmc->dmc_payload) {
-   DRM_ERROR("Memory allocation failed for dmc payload\n");
+   drm_err(>drm, "Memory allocation failed for dmc 
payload\n");
return 0;
}
 
@@ -493,7 +495,7 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
return header_len_bytes + payload_size;
 
 error_truncated:
-   DRM_ERROR("Truncated DMC firmware, refusing.\n");
+   drm_err(>drm, "Truncated DMC firmware, refusing.\n");
return 0;
 }
 
@@ -507,6 +509,8 @@ parse_dmc_fw_package(struct intel_dmc *dmc,
u32 num_entries, max_entries, dmc_offset;
const struct intel_fw_info *fw_info;
 
+   struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc);
+
if (rem_size < package_size)
goto error_truncated;
 
@@ -515,7 +519,7 @@ parse_dmc_fw_package(struct intel_dmc *dmc,
} else if (package_header->header_ver == 2) {
max_entries = PACKAGE_V2_MAX_FW_INFO_ENTRIES;
} else {
-   DRM_ERROR("DMC firmware has unknown header version %u\n",
+   drm_err(>drm, "DMC firmware has unknown header version 
%u\n",
  package_header->header_ver);
return 0;
}
@@ -529,8 +533,8 @@ parse_dmc_fw_package(struct intel_dmc *dmc,
goto error_truncated;
 
if (package_header->header_len * 4 != package_size) {
-   DRM_ERROR("DMC firmware has wrong package header length "
- "(%u bytes)\n", package_size);
+   drm_err(>drm, "DMC firmware has wrong package header 
length "
+   "(%u bytes)\n", package_size);
return 0;
}
 
@@ -543,8 +547,8 @@ parse_dmc_fw_package(struct intel_dmc *dmc,
dmc_offset = find_dmc_fw_offset(fw_info, num_entries, si,
package_header->header_ver);
if (dmc_offset == DMC_DEFAULT_FW_OFFSET) {
-   DRM_ERROR("DMC 

[Intel-gfx] [PATCH 0/2] More DMC cleanup

[Anusha Srivatsa]

Last of prep patches before Pipe DMC patches
can land.

Anusha Srivatsa (2):
  drm/i915/dmc: s/DRM_ERROR/drm_err
  drm/i915/dmc: Add intel_dmc_has_payload() helper

 .../drm/i915/display/intel_display_debugfs.c  |  4 +-
 .../drm/i915/display/intel_display_power.c| 16 +++---
 drivers/gpu/drm/i915/display/intel_dmc.c  | 52 ---
 drivers/gpu/drm/i915/display/intel_dmc.h  | 22 
 drivers/gpu/drm/i915/i915_drv.h   | 18 +--
 drivers/gpu/drm/i915/i915_gpu_error.c |  2 +-
 6 files changed, 66 insertions(+), 48 deletions(-)

-- 
2.25.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/dp_mst: Use kHz as link rate units when settig source max link caps at init (rev2)

[Patchwork]

== Series Details ==

Series: drm/dp_mst: Use kHz as link rate units when settig source max link caps 
at init (rev2)
URL   : https://patchwork.freedesktop.org/series/90099/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
2bc1c0fbd55e drm/dp_mst: Use kHz as link rate units when settig source max link 
caps at init
-:45: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#45: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:3725:
+   link_rate = min_t(int, 
drm_dp_bw_code_to_link_rate(mgr->dpcd[1]), mgr->max_link_rate);

total: 0 errors, 1 warnings, 0 checks, 88 lines checked


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 7/7] drm/i915: Expose client engine utilisation via fdinfo

[Daniel Vetter]

On Thu, May 20, 2021 at 6:31 PM Christian König
 wrote:
>
> Yeah, having the timestamp is a good idea as well.
>
>   drm-driver: i915
>
> I think we should rather add something like printing 
> file_operations->owner->name to the common fdinfo code.
>
> This way we would have something common for all drivers in the system. I'm 
> just not sure if that also works if they are compiled into the kernel.

Yeah common code could print driver name, busid and all that stuff. I
think the common code should also provide some helpers for the key:
value pair formatting (and maybe check for all lower-case and stuff
like that) because if we don't then this is going to be a complete
mess that's not parseable.

And value should be real semantic stuff, not "here's a string". So
accumulated time as a struct ktime as the example.
-Daniel

> Regards,
> Christian.
>
> Am 20.05.21 um 18:26 schrieb Nieto, David M:
>
> [AMD Official Use Only]
>
>
> i would like to add a unit marker for the stats that we monitor in the fd, as 
> we discussed currently we are displaying the usage percentage, because we 
> wanted to to provide single query percentages, but this may evolve with time.
>
> May I suggest to add two new fields
>
> drm-stat-interval: <64 bit> ns
> drm-stat-timestamp: <64 bit> ns
>
> If interval is set, engine utilization is calculated by doing  = 
> 100*/
> if interval is not set, two reads are needed :  = 
> 100* /  drm-stat-timestamp0>
>
>
> Regards,
>
> David
>
>
> 
> From: Tvrtko Ursulin 
> Sent: Thursday, May 20, 2021 8:12 AM
> To: Intel-gfx@lists.freedesktop.org 
> Cc: dri-de...@lists.freedesktop.org ; Tvrtko 
> Ursulin ; Nieto, David M ; 
> Koenig, Christian ; Daniel Vetter 
> Subject: [RFC 7/7] drm/i915: Expose client engine utilisation via fdinfo
>
> From: Tvrtko Ursulin 
>
> Similar to AMD commit
> 874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
> infrastructure added in previous patches, we add basic client info
> and GPU engine utilisation for i915.
>
> Example of the output:
>
>   pos:0
>   flags:  012
>   mnt_id: 21
>   drm-driver: i915
>   drm-pdev:   :00:02.0
>   drm-client-id:  7
>   drm-engine-render:  9288864723 ns
>   drm-engine-copy:2035071108 ns
>   drm-engine-video:   0 ns
>   drm-engine-video-enhance:   0 ns
>
> DRM related fields are appropriately prefixed for easy parsing and
> separation from generic fdinfo fields.
>
> Idea is for some fields to become either fully or partially standardised
> in order to enable writting of generic top-like tools.
>
> Initial proposal for fully standardised common fields:
>
>  drm-driver: 
>  drm-pdev: 
>
> Optional fully standardised:
>
>  drm-client-id: 
>
> Optional partially standardised:
>
>  engine-:  ns
>  memory-:  KiB
>
> Once agreed the format would need to go to some README or kerneldoc in
> DRM core.
>
> Signed-off-by: Tvrtko Ursulin 
> Cc: David M Nieto 
> Cc: Christian König 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_drm_client.c | 68 ++
>  drivers/gpu/drm/i915/i915_drm_client.h |  4 ++
>  drivers/gpu/drm/i915/i915_drv.c|  3 ++
>  3 files changed, 75 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
> b/drivers/gpu/drm/i915/i915_drm_client.c
> index 1e5db7753276..5e9cfba1116b 100644
> --- a/drivers/gpu/drm/i915/i915_drm_client.c
> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> @@ -9,6 +9,11 @@
>
>  #include 
>
> +#include 
> +
> +#include "gem/i915_gem_context.h"
> +#include "gt/intel_engine_user.h"
> +
>  #include "i915_drm_client.h"
>  #include "i915_drv.h"
>  #include "i915_gem.h"
> @@ -168,3 +173,66 @@ void i915_drm_clients_fini(struct i915_drm_clients 
> *clients)
>
>  xa_destroy(>xarray);
>  }
> +
> +#ifdef CONFIG_PROC_FS
> +static const char * const uabi_class_names[] = {
> +   [I915_ENGINE_CLASS_RENDER] = "render",
> +   [I915_ENGINE_CLASS_COPY] = "copy",
> +   [I915_ENGINE_CLASS_VIDEO] = "video",
> +   [I915_ENGINE_CLASS_VIDEO_ENHANCE] = "video-enhance",
> +};
> +
> +static u64 busy_add(struct i915_gem_context *ctx, unsigned int class)
> +{
> +   struct i915_gem_engines_iter it;
> +   struct intel_context *ce;
> +   u64 total = 0;
> +
> +   for_each_gem_engine(ce, rcu_dereference(ctx->engines), it) {
> +   if (ce->engine->uabi_class != class)
> +   continue;
> +
> +   total += intel_context_get_total_runtime_ns(ce);
> +   }
> +
> +   return total;
> +}
> +
> +static void
> +show_client_class(struct seq_file *m,
> + struct i915_drm_client *client,
> + unsigned int class)
> +{
> +   const struct list_head *list = >ctx_list;
> +   u64 total = atomic64_read(>past_runtime[class]);
> +   struct i915_gem_context *ctx;
> +
> +   rcu_read_lock();
> +   list_for_each_entry_rcu(ctx, list, client_link)
> +   total += busy_add(ctx, class);
> +   

Re: [Intel-gfx] [RFC PATCH 04/97] drm/i915/guc: skip disabling CTBs before sanitizing the GuC

[Matthew Brost]

On Thu, May 06, 2021 at 12:13:18PM -0700, Matthew Brost wrote:
> From: Daniele Ceraolo Spurio 
> 
> If we're about to sanitize the GuC, something might have going wrong
> beforehand, so we should avoid trying to talk to it. Even if GuC is
> still running fine, the sanitize will reset its internal state and clear
> the CTB registration, so there is still no need to explicitly do so.
> 
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/2469
> Signed-off-by: Daniele Ceraolo Spurio 
> Signed-off-by: Matthew Brost 
> Cc: Michal Wajdeczko 
> Cc: John Harrison 

Reviewed-by: Matthew Brost 

> ---
>  drivers/gpu/drm/i915/gt/uc/intel_uc.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> index 6abb8f2dc33d..892c1315ce49 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> @@ -504,7 +504,7 @@ static int __uc_init_hw(struct intel_uc *uc)
>  
>   ret = intel_guc_sample_forcewake(guc);
>   if (ret)
> - goto err_communication;
> + goto err_log_capture;
>  
>   if (intel_uc_uses_guc_submission(uc))
>   intel_guc_submission_enable(guc);
> @@ -529,8 +529,6 @@ static int __uc_init_hw(struct intel_uc *uc)
>   /*
>* We've failed to load the firmware :(
>*/
> -err_communication:
> - guc_disable_communication(guc);
>  err_log_capture:
>   __uc_capture_load_err_log(uc);
>  err_out:
> @@ -558,9 +556,6 @@ static void __uc_fini_hw(struct intel_uc *uc)
>   if (intel_uc_uses_guc_submission(uc))
>   intel_guc_submission_disable(guc);
>  
> - if (guc_communication_enabled(guc))
> - guc_disable_communication(guc);
> -
>   __uc_sanitize(uc);
>  }
>  
> @@ -577,7 +572,6 @@ void intel_uc_reset_prepare(struct intel_uc *uc)
>   if (!intel_guc_is_ready(guc))
>   return;
>  
> - guc_disable_communication(guc);
>   __uc_sanitize(uc);
>  }
>  
> -- 
> 2.28.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 7/7] drm/i915: Expose client engine utilisation via fdinfo

[Christian König]

Yeah, having the timestamp is a good idea as well.

  drm-driver: i915

I think we should rather add something like printing 
file_operations->owner->name to the common fdinfo code.


This way we would have something common for all drivers in the system. 
I'm just not sure if that also works if they are compiled into the kernel.


Regards,
Christian.

Am 20.05.21 um 18:26 schrieb Nieto, David M:


[AMD Official Use Only]


i would like to add a unit marker for the stats that we monitor in the 
fd, as we discussed currently we are displaying the usage percentage, 
because we wanted to to provide single query percentages, but this may 
evolve with time.


May I suggest to add two new fields

drm-stat-interval: <64 bit> ns
drm-stat-timestamp: <64 bit> ns

If interval is set, engine utilization is calculated by doing render> = 100*/
if interval is not set, two reads are needed :  = 
100* / drm-stat-timestamp0>



Regards,

David



*From:* Tvrtko Ursulin 
*Sent:* Thursday, May 20, 2021 8:12 AM
*To:* Intel-gfx@lists.freedesktop.org 
*Cc:* dri-de...@lists.freedesktop.org 
; Tvrtko Ursulin 
; Nieto, David M ; 
Koenig, Christian ; Daniel Vetter 

*Subject:* [RFC 7/7] drm/i915: Expose client engine utilisation via 
fdinfo

From: Tvrtko Ursulin 

Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for i915.

Example of the output:

  pos:    0
  flags:  012
  mnt_id: 21
  drm-driver: i915
  drm-pdev:   :00:02.0
  drm-client-id:  7
  drm-engine-render:  9288864723 ns
  drm-engine-copy:    2035071108 ns
  drm-engine-video:   0 ns
  drm-engine-video-enhance:   0 ns

DRM related fields are appropriately prefixed for easy parsing and
separation from generic fdinfo fields.

Idea is for some fields to become either fully or partially standardised
in order to enable writting of generic top-like tools.

Initial proposal for fully standardised common fields:

 drm-driver: 
 drm-pdev: 

Optional fully standardised:

 drm-client-id: 

Optional partially standardised:

 engine-:  ns
 memory-:  KiB

Once agreed the format would need to go to some README or kerneldoc in
DRM core.

Signed-off-by: Tvrtko Ursulin 
Cc: David M Nieto 
Cc: Christian König 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drm_client.c | 68 ++
 drivers/gpu/drm/i915/i915_drm_client.h |  4 ++
 drivers/gpu/drm/i915/i915_drv.c    |  3 ++
 3 files changed, 75 insertions(+)

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

index 1e5db7753276..5e9cfba1116b 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -9,6 +9,11 @@

 #include 

+#include 
+
+#include "gem/i915_gem_context.h"
+#include "gt/intel_engine_user.h"
+
 #include "i915_drm_client.h"
 #include "i915_drv.h"
 #include "i915_gem.h"
@@ -168,3 +173,66 @@ void i915_drm_clients_fini(struct 
i915_drm_clients *clients)


 xa_destroy(>xarray);
 }
+
+#ifdef CONFIG_PROC_FS
+static const char * const uabi_class_names[] = {
+   [I915_ENGINE_CLASS_RENDER] = "render",
+   [I915_ENGINE_CLASS_COPY] = "copy",
+   [I915_ENGINE_CLASS_VIDEO] = "video",
+   [I915_ENGINE_CLASS_VIDEO_ENHANCE] = "video-enhance",
+};
+
+static u64 busy_add(struct i915_gem_context *ctx, unsigned int class)
+{
+   struct i915_gem_engines_iter it;
+   struct intel_context *ce;
+   u64 total = 0;
+
+   for_each_gem_engine(ce, rcu_dereference(ctx->engines), it) {
+   if (ce->engine->uabi_class != class)
+   continue;
+
+   total += intel_context_get_total_runtime_ns(ce);
+   }
+
+   return total;
+}
+
+static void
+show_client_class(struct seq_file *m,
+ struct i915_drm_client *client,
+ unsigned int class)
+{
+   const struct list_head *list = >ctx_list;
+   u64 total = atomic64_read(>past_runtime[class]);
+   struct i915_gem_context *ctx;
+
+   rcu_read_lock();
+   list_for_each_entry_rcu(ctx, list, client_link)
+   total += busy_add(ctx, class);
+   rcu_read_unlock();
+
+   return seq_printf(m, "drm-engine-%s:\t%llu ns\n",
+ uabi_class_names[class], total);
+}
+
+void i915_drm_client_fdinfo(struct seq_file *m, struct file *f)
+{
+   struct drm_file *file = f->private_data;
+   struct drm_i915_file_private *file_priv = file->driver_priv;
+   struct drm_i915_private *i915 = file_priv->dev_priv;
+   struct i915_drm_client *client = file_priv->client;
+   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
+   unsigned int i;
+
+   seq_printf(m, "drm-driver:\ti915\n");
+   seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n",
+  pci_domain_nr(pdev->bus), pdev->bus->number,
+ 

[Intel-gfx] ✓ Fi.CI.BAT: success for Per client engine busyness

[Patchwork]

== Series Details ==

Series: Per client engine busyness
URL   : https://patchwork.freedesktop.org/series/90375/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10113 -> Patchwork_20162


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@mman:
- {fi-tgl-dsi}:   [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-tgl-dsi/igt@i915_selftest@l...@mman.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/fi-tgl-dsi/igt@i915_selftest@l...@mman.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u:   NOTRUN -> [WARN][3] ([i915#2283])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_selftest@live@execlists:
- fi-bdw-5557u:   NOTRUN -> [DMESG-FAIL][4] ([i915#3462])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u:   NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u:   NOTRUN -> [SKIP][6] ([fdo#109271]) +9 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- {fi-jsl-1}: [DMESG-WARN][7] ([i915#1222]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-jsl-1/igt@i915_selftest@live@gt_heartbeat.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/fi-jsl-1/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}:   [DMESG-WARN][9] ([i915#3303]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-icl-u2:  [DMESG-WARN][11] ([i915#2868]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html

  
 Warnings 

  * igt@runner@aborted:
- fi-skl-6600u:   [FAIL][13] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][14] ([i915#1436] / [i915#3363])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-skl-6600u/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/fi-skl-6600u/igt@run...@aborted.html
- fi-glk-dsi: [FAIL][15] ([i915#2426] / [i915#3363] / 
[k.org#202321]) -> [FAIL][16] ([i915#3363] / [k.org#202321])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-glk-dsi/igt@run...@aborted.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/fi-glk-dsi/igt@run...@aborted.html
- fi-bdw-5557u:   [FAIL][17] ([i915#1602] / [i915#2029]) -> [FAIL][18] 
([i915#3462])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-bdw-5557u/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/fi-bdw-5557u/igt@run...@aborted.html
- fi-kbl-soraka:  [FAIL][19] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][20] ([i915#1436] / [i915#3363])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-kbl-soraka/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20162/fi-kbl-soraka/igt@run...@aborted.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1222]: https://gitlab.freedesktop.org/drm/intel/issues/1222
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
  [i915#2029]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Per client engine busyness

[Patchwork]

== Series Details ==

Series: Per client engine busyness
URL   : https://patchwork.freedesktop.org/series/90375/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/intel_display.c:1887:21:expected struct 
i915_vma *[assigned] vma
+drivers/gpu/drm/i915/display/intel_display.c:1887:21:got void [noderef] 
__iomem *[assigned] iomem
+drivers/gpu/drm/i915/display/intel_display.c:1887:21: warning: incorrect type 
in assignment (different address spaces)
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1329:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1203:24: warning: Using plain 
integer as NULL pointer
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 
16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Per client engine busyness

[Patchwork]

== Series Details ==

Series: Per client engine busyness
URL   : https://patchwork.freedesktop.org/series/90375/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
1455dee675ac drm/i915: Explicitly track DRM clients
-:84: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#84: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 287 lines checked
bfb2b185e63f drm/i915: Update client name on context create
8b3d87efebae drm/i915: Make GEM contexts track DRM clients
bc02e5505f79 drm/i915: Track runtime spent in closed and unreachable GEM 
contexts
f7fcc7b31e1a drm/i915: Track all user contexts per client
2b0b1913bd6c drm/i915: Track context current active time
-:136: WARNING:LINE_SPACING: Missing a blank line after declarations
#136: FILE: drivers/gpu/drm/i915/gt/intel_context_types.h:125:
+   u32 last;
+   I915_SELFTEST_DECLARE(u32 num_underflow);

total: 0 errors, 1 warnings, 0 checks, 296 lines checked
d5123f923671 drm/i915: Expose client engine utilisation via fdinfo
-:10: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 874442541133 ("drm/amdgpu: Add 
show_fdinfo() interface")'
#10: 
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the

-:31: WARNING:TYPO_SPELLING: 'writting' may be misspelled - perhaps 'writing'?
#31: 
in order to enable writting of generic top-like tools.
   

-:127: WARNING:PREFER_SEQ_PUTS: Prefer seq_puts to seq_printf
#127: FILE: drivers/gpu/drm/i915/i915_drm_client.c:228:
+   seq_printf(m, "drm-driver:\ti915\n");

total: 1 errors, 2 warnings, 0 checks, 96 lines checked


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for Core TTM changes for i915 TTM enabling

[Patchwork]

== Series Details ==

Series: Core TTM changes for i915 TTM enabling
URL   : https://patchwork.freedesktop.org/series/90373/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10113 -> Patchwork_20161


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][1] -> [INCOMPLETE][2] ([i915#2782])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}:   [DMESG-WARN][3] ([i915#3303]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-icl-u2:  [DMESG-WARN][5] ([i915#2868]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html

  
 Warnings 

  * igt@i915_selftest@live@execlists:
- fi-icl-u2:  [DMESG-FAIL][7] ([i915#3462]) -> [INCOMPLETE][8] 
([i915#2782] / [i915#3462])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-icl-u2/igt@i915_selftest@l...@execlists.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/fi-icl-u2/igt@i915_selftest@l...@execlists.html

  * igt@runner@aborted:
- fi-skl-6600u:   [FAIL][9] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][10] ([i915#1436] / [i915#3363])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-skl-6600u/igt@run...@aborted.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/fi-skl-6600u/igt@run...@aborted.html
- fi-icl-u2:  [FAIL][11] ([i915#2426] / [i915#2782] / [i915#3363]) 
-> [FAIL][12] ([i915#2782] / [i915#3363])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-icl-u2/igt@run...@aborted.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/fi-icl-u2/igt@run...@aborted.html
- fi-kbl-r:   [FAIL][13] ([i915#1436] / [i915#3363]) -> [FAIL][14] 
([i915#1436] / [i915#2426] / [i915#3363])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-kbl-r/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/fi-kbl-r/igt@run...@aborted.html
- fi-kbl-soraka:  [FAIL][15] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][16] ([i915#1436] / [i915#3363])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-kbl-soraka/igt@run...@aborted.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/fi-kbl-soraka/igt@run...@aborted.html
- fi-cml-u2:  [FAIL][17] ([i915#3363]) -> [FAIL][18] ([i915#2082] / 
[i915#2426] / [i915#3363])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-cml-u2/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/fi-cml-u2/igt@run...@aborted.html
- fi-kbl-7567u:   [FAIL][19] ([i915#1436] / [i915#3363]) -> [FAIL][20] 
([i915#1436] / [i915#2426] / [i915#3363])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10113/fi-kbl-7567u/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20161/fi-kbl-7567u/igt@run...@aborted.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#2082]: https://gitlab.freedesktop.org/drm/intel/issues/2082
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#2868]: https://gitlab.freedesktop.org/drm/intel/issues/2868
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462


Participating hosts (42 -> 39)
--

  Missing(3): fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_10113 -> Patchwork_20161

  CI-20190529: 20190529
  CI_DRM_10113: 7a90018e59889ff846d0b9ec9fa4cad75ef978d7 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  

Re: [Intel-gfx] [Mesa-dev] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan

[Matthew Brost]

On Thu, May 20, 2021 at 01:11:59PM +0200, Christian König wrote:
> Am 19.05.21 um 18:51 schrieb Matthew Brost:
> > On Wed, May 19, 2021 at 01:45:39PM +0200, Christian König wrote:
> > > Oh, yeah we call that gang submit on the AMD side.
> > > 
> > > Had already some internal discussions how to implement this, but so far
> > > couldn't figure out how to cleanly introduce that into the DRM scheduler.
> > > 
> > > Can you briefly describe in a few words how that is supposed to work on 
> > > the
> > > Intel side?
> > > 
> > Sure, I've done a quick PoC internally and have been able to hook this
> > into the DRM scheduler.
> > 
> > Basically each BB still maps to a single job as each job is somewhat
> > unique (e.g. each job has its own ring, lrc, seqno, etc...). However all
> > the jobs configured to run in parallel map to a single sched_entity
> > which maintains the order each job was generated from the execbuf IOCTL
> > (1 - N). When the backend receives jobs 1 to N - 1 it basically just
> > updates some internal state. When the backend sees job N (last job) it
> > actually does the submit for jobs 1 - N which with GuC submission is a
> > simple command moving the LRC tail of the N jobs.
> > 
> > Daniel has suggested that we create a single job for the NN BBs but that
> > would be huge rework to the internals of the i915 and likely won't
> > happen by the time this code first lands.
> > 
> > Also worth noting one way a job isn't really a treated individually is
> > the excl slot with dma-resv. In that case we create a composite fence of
> > all jobs (dma_fence_array).
> 
> Yeah, that's something we have discussed as well.
> 
> How do you prevent the scheduler from over committing to a single ring
> buffer in this scenario?
> 

Each job has its own ring, the execbuf IOCTL throttles itself for each
job if there isn't space in the ring. This is exactly the same as
non-parallel submits.

I think this is what you were asking? If not, maybe try explaining the
question a bit more.

Matt

> Christian.
> 
> > 
> > Matt
> > 
> > > Thanks,
> > > Christian.
> > > 
> > > Am 19.05.21 um 01:58 schrieb Matthew Brost:
> > > > Add entry fpr i915 new parallel submission uAPI plan.
> > > > 
> > > > v2:
> > > >(Daniel Vetter):
> > > > - Expand logical order explaination
> > > > - Add dummy header
> > > > - Only allow N BBs in execbuf IOCTL
> > > > - Configure parallel submission per slot not per gem context
> > > > 
> > > > Cc: Tvrtko Ursulin 
> > > > Cc: Tony Ye 
> > > > CC: Carl Zhang 
> > > > Cc: Daniel Vetter 
> > > > Cc: Jason Ekstrand 
> > > > Signed-off-by: Matthew Brost 
> > > > ---
> > > >Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 
> > > > ++
> > > >Documentation/gpu/rfc/i915_scheduler.rst  |  53 ++-
> > > >2 files changed, 196 insertions(+), 1 deletion(-)
> > > >create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > 
> > > > diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h 
> > > > b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > new file mode 100644
> > > > index ..8c64b983ccad
> > > > --- /dev/null
> > > > +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > @@ -0,0 +1,144 @@
> > > > +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see 
> > > > i915_context_engines_parallel_submit */
> > > > +
> > > > +/*
> > > > + * i915_context_engines_parallel_submit:
> > > > + *
> > > > + * Setup a slot to allow multiple BBs to be submitted in a single 
> > > > execbuf IOCTL.
> > > > + * Those BBs will then be scheduled to run on the GPU in parallel. 
> > > > Multiple
> > > > + * hardware contexts are created internally in the i915 run these BBs. 
> > > > Once a
> > > > + * slot is configured for N BBs only N BBs can be submitted in each 
> > > > execbuf
> > > > + * IOCTL and this is implict behavior (e.g. the user doesn't tell the 
> > > > execbuf
> > > > + * IOCTL there are N BBs, the execbuf IOCTL know how many BBs there 
> > > > are based on
> > > > + * the slots configuration).
> > > > + *
> > > > + * Their are two currently defined ways to control the placement of the
> > > > + * hardware contexts on physical engines: default behavior (no flags) 
> > > > and
> > > > + * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the 
> > > > in the
> > > > + * future as new hardware / use cases arise. Details of how to use this
> > > > + * interface below above the flags.
> > > > + *
> > > > + * Returns -EINVAL if hardware context placement configuration invalid 
> > > > or if the
> > > > + * placement configuration isn't supported on the platform / submission
> > > > + * interface.
> > > > + * Returns -ENODEV if extension isn't supported on the platform / 
> > > > submission
> > > > + * inteface.
> > > > + */
> > > > +struct i915_context_engines_parallel_submit {
> > > > +   struct i915_user_extension base;
> > > > +
> > > > +   __u16 engine_index; /* slot for parallel engine */
> 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Core TTM changes for i915 TTM enabling

[Patchwork]

== Series Details ==

Series: Core TTM changes for i915 TTM enabling
URL   : https://patchwork.freedesktop.org/series/90373/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Core TTM changes for i915 TTM enabling

[Patchwork]

== Series Details ==

Series: Core TTM changes for i915 TTM enabling
URL   : https://patchwork.freedesktop.org/series/90373/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
6eeb4e1f8ab7 drm/ttm: Add a generic TTM memcpy move for page-based iomem
-:70: CHECK:ARCH_DEFINES: architecture specific defines should be avoided
#70: FILE: drivers/gpu/drm/ttm/ttm_bo_util.c:83:
+#if defined(__i386__) || defined(__x86_64__)

total: 0 errors, 0 warnings, 1 checks, 639 lines checked
369fe8e04f41 drm, drm/i915: Move the memcpy_from_wc functionality to core drm
-:54: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#54: 
rename from drivers/gpu/drm/i915/i915_memcpy.c

total: 0 errors, 1 warnings, 0 checks, 372 lines checked
884af268552d drm/ttm: Use drm_memcpy_from_wc for TTM bo moves
71cc65c1ff0f drm/ttm: Document and optimize ttm_bo_pipeline_gutting()
76e47a2ed2d1 drm/ttm, drm/amdgpu: Allow the driver some control over swapping


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan

[Matthew Brost]

On Thu, May 20, 2021 at 11:54:25AM +0200, Daniel Vetter wrote:
> On Wed, May 19, 2021 at 7:19 PM Matthew Brost  wrote:
> >
> > On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wrote:
> > > On Tue, May 18, 2021 at 04:58:30PM -0700, Matthew Brost wrote:
> > > > Add entry fpr i915 new parallel submission uAPI plan.
> > > >
> > > > v2:
> > > >  (Daniel Vetter):
> > > >   - Expand logical order explaination
> > > >   - Add dummy header
> > > >   - Only allow N BBs in execbuf IOCTL
> > > >   - Configure parallel submission per slot not per gem context
> > > >
> > > > Cc: Tvrtko Ursulin 
> > > > Cc: Tony Ye 
> > > > CC: Carl Zhang 
> > > > Cc: Daniel Vetter 
> > > > Cc: Jason Ekstrand 
> > > > Signed-off-by: Matthew Brost 
> > > > ---
> > > >  Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 ++
> > > >  Documentation/gpu/rfc/i915_scheduler.rst  |  53 ++-
> > > >  2 files changed, 196 insertions(+), 1 deletion(-)
> > > >  create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > >
> > > > diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h 
> > > > b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > new file mode 100644
> > > > index ..8c64b983ccad
> > > > --- /dev/null
> > > > +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > > @@ -0,0 +1,144 @@
> > > > +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see 
> > > > i915_context_engines_parallel_submit */
> > > > +
> > > > +/*
> > > > + * i915_context_engines_parallel_submit:
> > > > + *
> > > > + * Setup a slot to allow multiple BBs to be submitted in a single 
> > > > execbuf IOCTL.
> > > > + * Those BBs will then be scheduled to run on the GPU in parallel. 
> > > > Multiple
> > > > + * hardware contexts are created internally in the i915 run these BBs. 
> > > > Once a
> > > > + * slot is configured for N BBs only N BBs can be submitted in each 
> > > > execbuf
> > > > + * IOCTL and this is implict behavior (e.g. the user doesn't tell the 
> > > > execbuf
> > > > + * IOCTL there are N BBs, the execbuf IOCTL know how many BBs there 
> > > > are based on
> > > > + * the slots configuration).
> > > > + *
> > > > + * Their are two currently defined ways to control the placement of the
> > > > + * hardware contexts on physical engines: default behavior (no flags) 
> > > > and
> > > > + * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the 
> > > > in the
> > > > + * future as new hardware / use cases arise. Details of how to use this
> > > > + * interface below above the flags.
> > > > + *
> > > > + * Returns -EINVAL if hardware context placement configuration invalid 
> > > > or if the
> > > > + * placement configuration isn't supported on the platform / submission
> > > > + * interface.
> > > > + * Returns -ENODEV if extension isn't supported on the platform / 
> > > > submission
> > > > + * inteface.
> > > > + */
> > > > +struct i915_context_engines_parallel_submit {
> > > > +   struct i915_user_extension base;
> > > > +
> > > > +   __u16 engine_index; /* slot for parallel engine */
> > > > +   __u16 width;/* number of contexts per parallel engine */
> > > > +   __u16 num_siblings; /* number of siblings per context */
> > > > +   __u16 mbz16;
> > >
> > > Ok the big picture looks reasonable now, the flags still confuse me.
> > >
> >
> > Yea, it is a bit confusing.
> >
> > > > +/*
> > > > + * Default placement behvavior (currently unsupported):
> > > > + *
> > > > + * Rather than restricting parallel submission to a single class with a
> > > > + * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS), add a 
> > > > mode that
> > > > + * enables parallel submission across multiple engine classes. In this 
> > > > case each
> > > > + * context's logical engine mask indicates where that context can 
> > > > placed. It is
> > > > + * implied in this mode that all contexts have mutual exclusive 
> > > > placement (e.g.
> > > > + * if one context is running CS0 no other contexts can run on CS0).
> > > > + *
> > > > + * Example 1 pseudo code:
> > > > + * CSX[Y] = engine class X, logical instance Y
> > > > + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
> > > > + * set_engines(INVALID)
> > > > + * set_parallel(engine_index=0, width=2, num_siblings=2,
> > > > + * engines=CS0[0],CS0[1],CS1[0],CS1[1])
> > > > + *
> > > > + * Results in the following valid placements:
> > > > + * CS0[0], CS1[0]
> > > > + * CS0[0], CS1[1]
> > > > + * CS0[1], CS1[0]
> > > > + * CS0[1], CS1[1]
> > > > + *
> > > > + * This can also be though of as 2 virtual engines:
> > > > + * VE[0] = CS0[0], CS0[1]
> > > > + * VE[1] = CS1[0], CS1[1]
> > > > + *
> > > > + * Example 2 pseudo code:
> > > > + * CS[X] = generic engine of same class, logical instance X
> > > > + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
> > > > + * set_engines(INVALID)
> > > > + * set_parallel(engine_index=0, width=2, num_siblings=3,
> > > > + * 

Re: [Intel-gfx] [RFC PATCH 5/5] drm/ttm, drm/amdgpu: Allow the driver some control over swapping

[Thomas Hellström]

On Thu, 2021-05-20 at 17:09 +0200, Thomas Hellström wrote:
> 
> +EXPORT_SYMBOL(ttm_tt_unpopulate);

Oh, this one was a leftover. It's not meant to be included anymore.

/Thomas


>  
>  #ifdef CONFIG_DEBUG_FS
>  


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC 0/7] Per client engine busyness

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Continuing on the identically named thread. First six patches are i915 specific
so please mostly look at the last one only which discusses the common options
for DRM drivers.

I haven't updated intel_gpu_top to use this yet so can't report any performance
numbers.

Tvrtko Ursulin (7):
  drm/i915: Explicitly track DRM clients
  drm/i915: Update client name on context create
  drm/i915: Make GEM contexts track DRM clients
  drm/i915: Track runtime spent in closed and unreachable GEM contexts
  drm/i915: Track all user contexts per client
  drm/i915: Track context current active time
  drm/i915: Expose client engine utilisation via fdinfo

 drivers/gpu/drm/i915/Makefile |   5 +-
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |  61 -
 .../gpu/drm/i915/gem/i915_gem_context_types.h |  16 +-
 drivers/gpu/drm/i915/gt/intel_context.c   |  27 +-
 drivers/gpu/drm/i915/gt/intel_context.h   |  15 +-
 drivers/gpu/drm/i915/gt/intel_context_types.h |  24 +-
 .../drm/i915/gt/intel_execlists_submission.c  |  23 +-
 .../gpu/drm/i915/gt/intel_gt_clock_utils.c|   4 +
 drivers/gpu/drm/i915/gt/intel_lrc.c   |  27 +-
 drivers/gpu/drm/i915/gt/intel_lrc.h   |  24 ++
 drivers/gpu/drm/i915/gt/selftest_lrc.c|  10 +-
 drivers/gpu/drm/i915/i915_drm_client.c| 238 ++
 drivers/gpu/drm/i915/i915_drm_client.h| 107 
 drivers/gpu/drm/i915/i915_drv.c   |   9 +
 drivers/gpu/drm/i915/i915_drv.h   |   5 +
 drivers/gpu/drm/i915/i915_gem.c   |  21 +-
 drivers/gpu/drm/i915/i915_gpu_error.c |  31 +--
 drivers/gpu/drm/i915/i915_gpu_error.h |   2 +-
 18 files changed, 568 insertions(+), 81 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c
 create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h

-- 
2.30.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC 7/7] drm/i915: Expose client engine utilisation via fdinfo

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for i915.

Example of the output:

  pos:0
  flags:  012
  mnt_id: 21
  drm-driver: i915
  drm-pdev:   :00:02.0
  drm-client-id:  7
  drm-engine-render:  9288864723 ns
  drm-engine-copy:2035071108 ns
  drm-engine-video:   0 ns
  drm-engine-video-enhance:   0 ns

DRM related fields are appropriately prefixed for easy parsing and
separation from generic fdinfo fields.

Idea is for some fields to become either fully or partially standardised
in order to enable writting of generic top-like tools.

Initial proposal for fully standardised common fields:

 drm-driver: 
 drm-pdev: 

Optional fully standardised:

 drm-client-id: 

Optional partially standardised:

 engine-:  ns
 memory-:  KiB

Once agreed the format would need to go to some README or kerneldoc in
DRM core.

Signed-off-by: Tvrtko Ursulin 
Cc: David M Nieto 
Cc: Christian König 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drm_client.c | 68 ++
 drivers/gpu/drm/i915/i915_drm_client.h |  4 ++
 drivers/gpu/drm/i915/i915_drv.c|  3 ++
 3 files changed, 75 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
b/drivers/gpu/drm/i915/i915_drm_client.c
index 1e5db7753276..5e9cfba1116b 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -9,6 +9,11 @@
 
 #include 
 
+#include 
+
+#include "gem/i915_gem_context.h"
+#include "gt/intel_engine_user.h"
+
 #include "i915_drm_client.h"
 #include "i915_drv.h"
 #include "i915_gem.h"
@@ -168,3 +173,66 @@ void i915_drm_clients_fini(struct i915_drm_clients 
*clients)
 
xa_destroy(>xarray);
 }
+
+#ifdef CONFIG_PROC_FS
+static const char * const uabi_class_names[] = {
+   [I915_ENGINE_CLASS_RENDER] = "render",
+   [I915_ENGINE_CLASS_COPY] = "copy",
+   [I915_ENGINE_CLASS_VIDEO] = "video",
+   [I915_ENGINE_CLASS_VIDEO_ENHANCE] = "video-enhance",
+};
+
+static u64 busy_add(struct i915_gem_context *ctx, unsigned int class)
+{
+   struct i915_gem_engines_iter it;
+   struct intel_context *ce;
+   u64 total = 0;
+
+   for_each_gem_engine(ce, rcu_dereference(ctx->engines), it) {
+   if (ce->engine->uabi_class != class)
+   continue;
+
+   total += intel_context_get_total_runtime_ns(ce);
+   }
+
+   return total;
+}
+
+static void
+show_client_class(struct seq_file *m,
+ struct i915_drm_client *client,
+ unsigned int class)
+{
+   const struct list_head *list = >ctx_list;
+   u64 total = atomic64_read(>past_runtime[class]);
+   struct i915_gem_context *ctx;
+
+   rcu_read_lock();
+   list_for_each_entry_rcu(ctx, list, client_link)
+   total += busy_add(ctx, class);
+   rcu_read_unlock();
+
+   return seq_printf(m, "drm-engine-%s:\t%llu ns\n",
+ uabi_class_names[class], total);
+}
+
+void i915_drm_client_fdinfo(struct seq_file *m, struct file *f)
+{
+   struct drm_file *file = f->private_data;
+   struct drm_i915_file_private *file_priv = file->driver_priv;
+   struct drm_i915_private *i915 = file_priv->dev_priv;
+   struct i915_drm_client *client = file_priv->client;
+   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
+   unsigned int i;
+
+   seq_printf(m, "drm-driver:\ti915\n");
+   seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n",
+  pci_domain_nr(pdev->bus), pdev->bus->number,
+  PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
+
+   seq_printf(m, "drm-client-id:\t%u\n", client->id);
+
+   for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
+   show_client_class(m, client, i);
+}
+#endif
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h 
b/drivers/gpu/drm/i915/i915_drm_client.h
index b2b69d6985e4..9885002433a0 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -98,6 +98,10 @@ i915_drm_client_pid(const struct i915_drm_client *client)
return __i915_drm_client_name(client)->pid;
 }
 
+#ifdef CONFIG_PROC_FS
+void i915_drm_client_fdinfo(struct seq_file *m, struct file *f);
+#endif
+
 void i915_drm_clients_fini(struct i915_drm_clients *clients);
 
 #endif /* !__I915_DRM_CLIENT_H__ */
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 33eb7b52b58b..6b63fe4b3c26 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1694,6 +1694,9 @@ static const struct file_operations i915_driver_fops = {
.read = drm_read,
.compat_ioctl = i915_ioc32_compat_ioctl,
.llseek = noop_llseek,
+#ifdef CONFIG_PROC_FS
+   .show_fdinfo = i915_drm_client_fdinfo,
+#endif
 };
 
 static int
-- 
2.30.2

[Intel-gfx] [RFC 6/7] drm/i915: Track context current active time

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Track context active (on hardware) status together with the start
timestamp.

This will be used to provide better granularity of context
runtime reporting in conjunction with already tracked pphwsp accumulated
runtime.

The latter is only updated on context save so does not give us visibility
to any currently executing work.

As part of the patch the existing runtime tracking data is moved under the
new ce->stats member and updated under the seqlock. This provides the
ability to atomically read out accumulated plus active runtime.

v2:
 * Rename and make __intel_context_get_active_time unlocked.

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Aravind Iddamsetty  #  v1
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_context.c   | 27 ++-
 drivers/gpu/drm/i915/gt/intel_context.h   | 15 ---
 drivers/gpu/drm/i915/gt/intel_context_types.h | 24 +++--
 .../drm/i915/gt/intel_execlists_submission.c  | 23 
 .../gpu/drm/i915/gt/intel_gt_clock_utils.c|  4 +++
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 27 ++-
 drivers/gpu/drm/i915/gt/intel_lrc.h   | 24 +
 drivers/gpu/drm/i915/gt/selftest_lrc.c| 10 +++
 drivers/gpu/drm/i915/i915_gpu_error.c |  9 +++
 drivers/gpu/drm/i915/i915_gpu_error.h |  2 +-
 10 files changed, 116 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 4033184f13b9..bc021244c3b2 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -373,7 +373,7 @@ intel_context_init(struct intel_context *ce, struct 
intel_engine_cs *engine)
ce->sseu = engine->sseu;
ce->ring = __intel_context_ring_size(SZ_4K);
 
-   ewma_runtime_init(>runtime.avg);
+   ewma_runtime_init(>stats.runtime.avg);
 
ce->vm = i915_vm_get(engine->gt->vm);
 
@@ -499,6 +499,31 @@ struct i915_request *intel_context_create_request(struct 
intel_context *ce)
return rq;
 }
 
+u64 intel_context_get_total_runtime_ns(const struct intel_context *ce)
+{
+   u64 total, active;
+
+   total = ce->stats.runtime.total;
+   if (ce->ops->flags & COPS_RUNTIME_CYCLES)
+   total *= ce->engine->gt->clock_period_ns;
+
+   active = READ_ONCE(ce->stats.active);
+   if (active)
+   active = intel_context_clock() - active;
+
+   return total + active;
+}
+
+u64 intel_context_get_avg_runtime_ns(struct intel_context *ce)
+{
+   u64 avg = ewma_runtime_read(>stats.runtime.avg);
+
+   if (ce->ops->flags & COPS_RUNTIME_CYCLES)
+   avg *= ce->engine->gt->clock_period_ns;
+
+   return avg;
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftest_context.c"
 #endif
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h 
b/drivers/gpu/drm/i915/gt/intel_context.h
index f83a73a2b39f..a9125768b1b4 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -250,18 +250,13 @@ intel_context_clear_nopreempt(struct intel_context *ce)
clear_bit(CONTEXT_NOPREEMPT, >flags);
 }
 
-static inline u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
-{
-   const u32 period = ce->engine->gt->clock_period_ns;
-
-   return READ_ONCE(ce->runtime.total) * period;
-}
+u64 intel_context_get_total_runtime_ns(const struct intel_context *ce);
+u64 intel_context_get_avg_runtime_ns(struct intel_context *ce);
 
-static inline u64 intel_context_get_avg_runtime_ns(struct intel_context *ce)
+static inline u64 intel_context_clock(void)
 {
-   const u32 period = ce->engine->gt->clock_period_ns;
-
-   return mul_u32_u32(ewma_runtime_read(>runtime.avg), period);
+   /* As we mix CS cycles with CPU clocks, use the raw monotonic clock. */
+   return ktime_get_raw_fast_ns();
 }
 
 #endif /* __INTEL_CONTEXT_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index ed8c447a7346..65a5730a4f5b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -33,6 +33,9 @@ struct intel_context_ops {
 #define COPS_HAS_INFLIGHT_BIT 0
 #define COPS_HAS_INFLIGHT BIT(COPS_HAS_INFLIGHT_BIT)
 
+#define COPS_RUNTIME_CYCLES_BIT 1
+#define COPS_RUNTIME_CYCLES BIT(COPS_RUNTIME_CYCLES_BIT)
+
int (*alloc)(struct intel_context *ce);
 
int (*pre_pin)(struct intel_context *ce, struct i915_gem_ww_ctx *ww, 
void **vaddr);
@@ -110,14 +113,19 @@ struct intel_context {
} lrc;
u32 tag; /* cookie passed to HW to track this context on submission */
 
-   /* Time on GPU as tracked by the hw. */
-   struct {
-   struct ewma_runtime avg;
-   u64 total;
-   u32 last;
-   I915_SELFTEST_DECLARE(u32 num_underflow);
-   

[Intel-gfx] [RFC 5/7] drm/i915: Track all user contexts per client

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.

To enable this we start tracking all context belonging to a client on a
separate list.

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Aravind Iddamsetty 
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 12 
 drivers/gpu/drm/i915/gem/i915_gem_context_types.h |  3 +++
 drivers/gpu/drm/i915/i915_drm_client.c|  3 +++
 drivers/gpu/drm/i915/i915_drm_client.h|  5 +
 4 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index b8d8366a2cce..1595a608de92 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -573,6 +573,7 @@ static void set_closed_name(struct i915_gem_context *ctx)
 static void context_close(struct i915_gem_context *ctx)
 {
struct i915_address_space *vm;
+   struct i915_drm_client *client;
 
/* Flush any concurrent set_engines() */
mutex_lock(>engines_mutex);
@@ -601,6 +602,13 @@ static void context_close(struct i915_gem_context *ctx)
list_del(>link);
spin_unlock(>i915->gem.contexts.lock);
 
+   client = ctx->client;
+   if (client) {
+   spin_lock(>ctx_lock);
+   list_del_rcu(>client_link);
+   spin_unlock(>ctx_lock);
+   }
+
mutex_unlock(>mutex);
 
/*
@@ -943,6 +951,10 @@ static int gem_context_register(struct i915_gem_context 
*ctx,
 
ctx->client = client;
 
+   spin_lock(>ctx_lock);
+   list_add_tail_rcu(>client_link, >ctx_list);
+   spin_unlock(>ctx_lock);
+
spin_lock(>gem.contexts.lock);
list_add_tail(>link, >gem.contexts.list);
spin_unlock(>gem.contexts.lock);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index eb098f2896c5..8ea3fe3e7414 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -102,6 +102,9 @@ struct i915_gem_context {
/** client: struct i915_drm_client */
struct i915_drm_client *client;
 
+   /** link: _client.context_list */
+   struct list_head client_link;
+
/**
 * @ref: reference count
 *
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
b/drivers/gpu/drm/i915/i915_drm_client.c
index 0b7a70ed61d0..1e5db7753276 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -100,6 +100,9 @@ i915_drm_client_add(struct i915_drm_clients *clients, 
struct task_struct *task)
 
kref_init(>kref);
mutex_init(>update_lock);
+   spin_lock_init(>ctx_lock);
+   INIT_LIST_HEAD(>ctx_list);
+
client->clients = clients;
INIT_RCU_WORK(>rcu, __rcu_i915_drm_client_free);
 
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h 
b/drivers/gpu/drm/i915/i915_drm_client.h
index db82180f5859..b2b69d6985e4 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -7,10 +7,12 @@
 #define __I915_DRM_CLIENT_H__
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "gt/intel_engine_types.h"
@@ -42,6 +44,9 @@ struct i915_drm_client {
struct i915_drm_client_name __rcu *name;
bool closed;
 
+   spinlock_t ctx_lock; /* For add/remove from ctx_list. */
+   struct list_head ctx_list; /* List of contexts belonging to client. */
+
struct i915_drm_clients *clients;
 
/**
-- 
2.30.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC 3/7] drm/i915: Make GEM contexts track DRM clients

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

If we make GEM contexts keep a reference to i915_drm_client for the whole
of their lifetime, we can consolidate the current task pid and name usage
by getting it from the client.

v2: Don't bother supporting selftests contexts from debugfs. (Chris)
v3 (Lucas): Finish constructing ctx before adding it to the list
v4 (Ram): Rebase.

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 
Reviewed-by: Aravind Iddamsetty 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 20 -
 .../gpu/drm/i915/gem/i915_gem_context_types.h | 13 +++
 drivers/gpu/drm/i915/i915_gpu_error.c | 22 +++
 3 files changed, 30 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index e5f8d94666e8..5ea42d5b0b1a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -345,13 +345,14 @@ void i915_gem_context_release(struct kref *ref)
trace_i915_context_free(ctx);
GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
 
-   mutex_destroy(>engines_mutex);
-   mutex_destroy(>lut_mutex);
+   if (ctx->client)
+   i915_drm_client_put(ctx->client);
 
if (ctx->timeline)
intel_timeline_put(ctx->timeline);
 
-   put_pid(ctx->pid);
+   mutex_destroy(>engines_mutex);
+   mutex_destroy(>lut_mutex);
mutex_destroy(>mutex);
 
kfree_rcu(ctx, rcu);
@@ -895,6 +896,7 @@ static int gem_context_register(struct i915_gem_context 
*ctx,
u32 *id)
 {
struct drm_i915_private *i915 = ctx->i915;
+   struct i915_drm_client *client;
struct i915_address_space *vm;
int ret;
 
@@ -906,15 +908,21 @@ static int gem_context_register(struct i915_gem_context 
*ctx,
WRITE_ONCE(vm->file, fpriv); /* XXX */
mutex_unlock(>mutex);
 
-   ctx->pid = get_task_pid(current, PIDTYPE_PID);
+   client = i915_drm_client_get(fpriv->client);
+
+   rcu_read_lock();
snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
-current->comm, pid_nr(ctx->pid));
+i915_drm_client_name(client),
+pid_nr(i915_drm_client_pid(client)));
+   rcu_read_unlock();
 
/* And finally expose ourselves to userspace via the idr */
ret = xa_alloc(>context_xa, id, ctx, xa_limit_32b, GFP_KERNEL);
if (ret)
goto err_pid;
 
+   ctx->client = client;
+
spin_lock(>gem.contexts.lock);
list_add_tail(>link, >gem.contexts.list);
spin_unlock(>gem.contexts.lock);
@@ -922,7 +930,7 @@ static int gem_context_register(struct i915_gem_context 
*ctx,
return 0;
 
 err_pid:
-   put_pid(fetch_and_zero(>pid));
+   i915_drm_client_put(client);
return ret;
 }
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 340473aa70de..eb098f2896c5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -96,19 +96,12 @@ struct i915_gem_context {
 */
struct i915_address_space __rcu *vm;
 
-   /**
-* @pid: process id of creator
-*
-* Note that who created the context may not be the principle user,
-* as the context may be shared across a local socket. However,
-* that should only affect the default context, all contexts created
-* explicitly by the client are expected to be isolated.
-*/
-   struct pid *pid;
-
/** link: place with _i915_private.context_list */
struct list_head link;
 
+   /** client: struct i915_drm_client */
+   struct i915_drm_client *client;
+
/**
 * @ref: reference count
 *
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 8b964e355cb5..f5dfc15f5f76 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1235,7 +1235,9 @@ static void record_request(const struct i915_request 
*request,
 
ctx = rcu_dereference(request->context->gem_context);
if (ctx)
-   erq->pid = pid_nr(ctx->pid);
+   erq->pid = I915_SELFTEST_ONLY(!ctx->client) ?
+  0 :
+  pid_nr(i915_drm_client_pid(ctx->client));
}
rcu_read_unlock();
 }
@@ -1256,23 +1258,25 @@ static bool record_context(struct 
i915_gem_context_coredump *e,
   const struct i915_request *rq)
 {
struct i915_gem_context *ctx;
-   struct task_struct *task;
bool simulated;
 
rcu_read_lock();
+
ctx = rcu_dereference(rq->context->gem_context);
if (ctx && !kref_get_unless_zero(>ref))
 

[Intel-gfx] [RFC 2/7] drm/i915: Update client name on context create

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Some clients have the DRM fd passed to them over a socket by the X server.

Grab the real client and pid when they create their first context and
update the exposed data for more useful enumeration.

To enable lockless access to client name and pid data from the following
patches, we also make these fields rcu protected. In this way asynchronous
code paths where both contexts which remain after the client exit, and
access to client name and pid as they are getting updated due context
creation running in parallel with name/pid queries.

v2:
 * Do not leak the pid reference and borrow context idr_lock. (Chris)

v3:
 * More avoiding leaks. (Chris)

v4:
 * Move update completely to drm client. (Chris)
 * Do not lose previous client data on failure to re-register and simplify
   update to only touch what it needs.

v5:
 * Reuse ext_data local. (Chris)

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 
Reviewed-by: Aravind Iddamsetty 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c |  5 ++
 drivers/gpu/drm/i915/i915_drm_client.c  | 66 +++--
 drivers/gpu/drm/i915/i915_drm_client.h  | 34 ++-
 3 files changed, 97 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 188dee13e017..e5f8d94666e8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -76,6 +76,7 @@
 #include "gt/intel_gpu_commands.h"
 #include "gt/intel_ring.h"
 
+#include "i915_drm_client.h"
 #include "i915_gem_context.h"
 #include "i915_globals.h"
 #include "i915_trace.h"
@@ -2321,6 +2322,10 @@ int i915_gem_context_create_ioctl(struct drm_device 
*dev, void *data,
return -EIO;
}
 
+   ret = i915_drm_client_update(ext_data.fpriv->client, current);
+   if (ret)
+   return ret;
+
ext_data.ctx = i915_gem_create_context(i915, args->flags);
if (IS_ERR(ext_data.ctx))
return PTR_ERR(ext_data.ctx);
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
b/drivers/gpu/drm/i915/i915_drm_client.c
index 83080d9836b0..0b7a70ed61d0 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -7,7 +7,10 @@
 #include 
 #include 
 
+#include 
+
 #include "i915_drm_client.h"
+#include "i915_drv.h"
 #include "i915_gem.h"
 #include "i915_utils.h"
 
@@ -20,26 +23,57 @@ void i915_drm_clients_init(struct i915_drm_clients *clients,
xa_init_flags(>xarray, XA_FLAGS_ALLOC);
 }
 
+static struct i915_drm_client_name *get_name(struct i915_drm_client *client,
+struct task_struct *task)
+{
+   struct i915_drm_client_name *name;
+   int len = strlen(task->comm);
+
+   name = kmalloc(struct_size(name, name, len + 1), GFP_KERNEL);
+   if (!name)
+   return NULL;
+
+   init_rcu_head(>rcu);
+   name->client = client;
+   name->pid = get_task_pid(task, PIDTYPE_PID);
+   memcpy(name->name, task->comm, len + 1);
+
+   return name;
+}
+
+static void free_name(struct rcu_head *rcu)
+{
+   struct i915_drm_client_name *name =
+   container_of(rcu, typeof(*name), rcu);
+
+   put_pid(name->pid);
+   kfree(name);
+}
+
 static int
 __i915_drm_client_register(struct i915_drm_client *client,
   struct task_struct *task)
 {
-   char *name;
+   struct i915_drm_client_name *name;
 
-   name = kstrdup(task->comm, GFP_KERNEL);
+   name = get_name(client, task);
if (!name)
return -ENOMEM;
 
-   client->pid = get_task_pid(task, PIDTYPE_PID);
-   client->name = name;
+   RCU_INIT_POINTER(client->name, name);
 
return 0;
 }
 
 static void __i915_drm_client_unregister(struct i915_drm_client *client)
 {
-   put_pid(fetch_and_zero(>pid));
-   kfree(fetch_and_zero(>name));
+   struct i915_drm_client_name *name;
+
+   mutex_lock(>update_lock);
+   name = rcu_replace_pointer(client->name, NULL, true);
+   mutex_unlock(>update_lock);
+
+   call_rcu(>rcu, free_name);
 }
 
 static void __rcu_i915_drm_client_free(struct work_struct *wrk)
@@ -65,6 +99,7 @@ i915_drm_client_add(struct i915_drm_clients *clients, struct 
task_struct *task)
return ERR_PTR(-ENOMEM);
 
kref_init(>kref);
+   mutex_init(>update_lock);
client->clients = clients;
INIT_RCU_WORK(>rcu, __rcu_i915_drm_client_free);
 
@@ -102,6 +137,25 @@ void i915_drm_client_close(struct i915_drm_client *client)
i915_drm_client_put(client);
 }
 
+int
+i915_drm_client_update(struct i915_drm_client *client,
+  struct task_struct *task)
+{
+   struct i915_drm_client_name *name;
+
+   name = get_name(client, task);
+   if (!name)
+   return -ENOMEM;
+
+   mutex_lock(>update_lock);
+   if 

Re: [Intel-gfx] i915 and swiotlb_max_segment

[Konrad Rzeszutek Wilk]

On Mon, May 10, 2021 at 05:25:25PM +0200, Christoph Hellwig wrote:
> Hi all,
> 
> swiotlb_max_segment is a rather strange "API" export by swiotlb.c,
> and i915 is the only (remaining) user.
> 
> swiotlb_max_segment returns 0 if swiotlb is not in use, 1 if
> SWIOTLB_FORCE is set or swiotlb-zen is set, and the swiotlb segment
> size when swiotlb is otherwise enabled.
> 
> i915 then uses it to:
> 
>  a) decided on the max order in i915_gem_object_get_pages_internal
>  b) decide on a max segment size in i915_sg_segment_size
> 
> for a) it really seems i915 should switch to dma_alloc_noncoherent
> or dma_alloc_noncontigous ASAP instead of using alloc_page and
> streaming DMA mappings.  Any chance I could trick one of the i915
> maintaines into doing just that given that the callchain is not
> exactly trivial?
> 
> For b) I'm not sure swiotlb and i915 really agree on the meaning
> of the value.  swiotlb_set_max_segment basically returns the entire
> size of the swiotlb buffer, while i915 seems to use it to limit
> the size each scatterlist entry.  It seems like dma_max_mapping_size
> might be the best value to use here.

Yes. The background behind that was SWIOTLB would fail because well, the
size of the sg was too large. And some way to limit it to max size
was needed - the dma_max_mapping_size "should" be just fine.

> 
> Once that is fixed I'd like to kill off swiotlb_max_segment as it is
> a horribly confusing API.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC 4/7] drm/i915: Track runtime spent in closed and unreachable GEM contexts

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.

As GEM contexts are closed we want to have the DRM client remember how
much GPU time they used (per class) so later we can used it for smarter
purposes.

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Aravind Iddamsetty 
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++--
 drivers/gpu/drm/i915/i915_drm_client.h  |  7 ++
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 5ea42d5b0b1a..b8d8366a2cce 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -262,23 +262,43 @@ static void free_engines_rcu(struct rcu_head *rcu)
free_engines(engines);
 }
 
+static void accumulate_runtime(struct i915_drm_client *client,
+  struct i915_gem_engines *engines)
+{
+   struct i915_gem_engines_iter it;
+   struct intel_context *ce;
+
+   if (!client)
+   return;
+
+   /* Transfer accumulated runtime to the parent GEM context. */
+   for_each_gem_engine(ce, engines, it) {
+   unsigned int class = ce->engine->uabi_class;
+
+   GEM_BUG_ON(class >= ARRAY_SIZE(client->past_runtime));
+   atomic64_add(intel_context_get_total_runtime_ns(ce),
+>past_runtime[class]);
+   }
+}
+
 static int __i915_sw_fence_call
 engines_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
 {
struct i915_gem_engines *engines =
container_of(fence, typeof(*engines), fence);
+   struct i915_gem_context *ctx = engines->ctx;
 
switch (state) {
case FENCE_COMPLETE:
if (!list_empty(>link)) {
-   struct i915_gem_context *ctx = engines->ctx;
unsigned long flags;
 
spin_lock_irqsave(>stale.lock, flags);
list_del(>link);
spin_unlock_irqrestore(>stale.lock, flags);
}
-   i915_gem_context_put(engines->ctx);
+   accumulate_runtime(ctx->client, engines);
+   i915_gem_context_put(ctx);
break;
 
case FENCE_FREE:
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h 
b/drivers/gpu/drm/i915/i915_drm_client.h
index 6d55f77a08f1..db82180f5859 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -13,6 +13,8 @@
 #include 
 #include 
 
+#include "gt/intel_engine_types.h"
+
 struct drm_i915_private;
 
 struct i915_drm_clients {
@@ -41,6 +43,11 @@ struct i915_drm_client {
bool closed;
 
struct i915_drm_clients *clients;
+
+   /**
+* @past_runtime: Accumulation of pphwsp runtimes from closed contexts.
+*/
+   atomic64_t past_runtime[MAX_ENGINE_CLASS + 1];
 };
 
 void i915_drm_clients_init(struct i915_drm_clients *clients,
-- 
2.30.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC 1/7] drm/i915: Explicitly track DRM clients

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Tracking DRM clients more explicitly will allow later patches to
accumulate past and current GPU usage in a centralised place and also
consolidate access to owning task pid/name.

Unique client id is also assigned for the purpose of distinguishing/
consolidating between multiple file descriptors owned by the same process.

v2:
 Chris Wilson:
 * Enclose new members into dedicated structs.
 * Protect against failed sysfs registration.

v3:
 * sysfs_attr_init.

v4:
 * Fix for internal clients.

v5:
 * Use cyclic ida for client id. (Chris)
 * Do not leak pid reference. (Chris)
 * Tidy code with some locals.

v6:
 * Use xa_alloc_cyclic to simplify locking. (Chris)
 * No need to unregister individial sysfs files. (Chris)
 * Rebase on top of fpriv kref.
 * Track client closed status and reflect in sysfs.

v7:
 * Make drm_client more standalone concept.

v8:
 * Simplify sysfs show. (Chris)
 * Always track name and pid.

v9:
 * Fix cyclic id assignment.

v10:
 * No need for a mutex around xa_alloc_cyclic.
 * Refactor sysfs into own function.
 * Unregister sysfs before freeing pid and name.
 * Move clients setup into own function.

v11:
 * Call clients init directly from driver init. (Chris)

v12:
 * Do not fail client add on id wrap. (Maciej)

v13 (Lucas): Rebase.

v14:
 * Dropped sysfs bits.

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson  # v11
Reviewed-by: Aravind Iddamsetty  # v11
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/Makefile  |   5 +-
 drivers/gpu/drm/i915/i915_drm_client.c | 113 +
 drivers/gpu/drm/i915/i915_drm_client.h |  61 +
 drivers/gpu/drm/i915/i915_drv.c|   6 ++
 drivers/gpu/drm/i915/i915_drv.h|   5 ++
 drivers/gpu/drm/i915/i915_gem.c|  21 -
 6 files changed, 206 insertions(+), 5 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c
 create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6947495bf34b..f3f5c4571623 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -33,8 +33,9 @@ subdir-ccflags-y += -I$(srctree)/$(src)
 # Please keep these build lists sorted!
 
 # core driver code
-i915-y += i915_drv.o \
- i915_config.o \
+i915-y += i915_config.o \
+ i915_drm_client.o \
+ i915_drv.o \
  i915_irq.o \
  i915_getparam.o \
  i915_mitigations.o \
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
b/drivers/gpu/drm/i915/i915_drm_client.c
new file mode 100644
index ..83080d9836b0
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -0,0 +1,113 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+
+#include "i915_drm_client.h"
+#include "i915_gem.h"
+#include "i915_utils.h"
+
+void i915_drm_clients_init(struct i915_drm_clients *clients,
+  struct drm_i915_private *i915)
+{
+   clients->i915 = i915;
+
+   clients->next_id = 0;
+   xa_init_flags(>xarray, XA_FLAGS_ALLOC);
+}
+
+static int
+__i915_drm_client_register(struct i915_drm_client *client,
+  struct task_struct *task)
+{
+   char *name;
+
+   name = kstrdup(task->comm, GFP_KERNEL);
+   if (!name)
+   return -ENOMEM;
+
+   client->pid = get_task_pid(task, PIDTYPE_PID);
+   client->name = name;
+
+   return 0;
+}
+
+static void __i915_drm_client_unregister(struct i915_drm_client *client)
+{
+   put_pid(fetch_and_zero(>pid));
+   kfree(fetch_and_zero(>name));
+}
+
+static void __rcu_i915_drm_client_free(struct work_struct *wrk)
+{
+   struct i915_drm_client *client =
+   container_of(wrk, typeof(*client), rcu.work);
+
+   xa_erase(>clients->xarray, client->id);
+
+   __i915_drm_client_unregister(client);
+
+   kfree(client);
+}
+
+struct i915_drm_client *
+i915_drm_client_add(struct i915_drm_clients *clients, struct task_struct *task)
+{
+   struct i915_drm_client *client;
+   int ret;
+
+   client = kzalloc(sizeof(*client), GFP_KERNEL);
+   if (!client)
+   return ERR_PTR(-ENOMEM);
+
+   kref_init(>kref);
+   client->clients = clients;
+   INIT_RCU_WORK(>rcu, __rcu_i915_drm_client_free);
+
+   ret = xa_alloc_cyclic(>xarray, >id, client,
+ xa_limit_32b, >next_id, GFP_KERNEL);
+   if (ret < 0)
+   goto err_id;
+
+   ret = __i915_drm_client_register(client, task);
+   if (ret)
+   goto err_register;
+
+   return client;
+
+err_register:
+   xa_erase(>xarray, client->id);
+err_id:
+   kfree(client);
+
+   return ERR_PTR(ret);
+}
+
+void __i915_drm_client_free(struct kref *kref)
+{
+   struct i915_drm_client *client =
+   container_of(kref, typeof(*client), kref);
+
+   queue_rcu_work(system_wq, >rcu);
+}

[Intel-gfx] [RFC PATCH 4/5] drm/ttm: Document and optimize ttm_bo_pipeline_gutting()

[Thomas Hellström]

If the bo is idle when calling ttm_bo_pipeline_gutting(), we unnecessarily
create a ghost object and push it out to delayed destroy.
Fix this by adding a path for idle, and document the function.

Also avoid having the bo end up in a bad state vulnerable to user-space
triggered kernel BUGs if the call to ttm_tt_create() fails.

Finally reuse ttm_bo_pipeline_gutting() in ttm_bo_evict().

Cc: Christian König 
Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/ttm/ttm_bo.c  | 20 +-
 drivers/gpu/drm/ttm/ttm_bo_util.c | 63 ---
 drivers/gpu/drm/ttm/ttm_tt.c  |  5 +++
 include/drm/ttm/ttm_tt.h  | 10 +
 4 files changed, 75 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index ca1b098b6a56..a8fa3375b8aa 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -501,10 +501,15 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
bdev->funcs->evict_flags(bo, );
 
if (!placement.num_placement && !placement.num_busy_placement) {
-   ttm_bo_wait(bo, false, false);
+   ret = ttm_bo_wait(bo, true, false);
+   if (ret)
+   return ret;
 
-   ttm_bo_cleanup_memtype_use(bo);
-   return ttm_tt_create(bo, false);
+   /*
+* Since we've already synced, this frees backing store
+* immediately.
+*/
+   return ttm_bo_pipeline_gutting(bo);
}
 
ret = ttm_bo_mem_space(bo, , _mem, ctx);
@@ -974,13 +979,8 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
/*
 * Remove the backing store if no placement is given.
 */
-   if (!placement->num_placement && !placement->num_busy_placement) {
-   ret = ttm_bo_pipeline_gutting(bo);
-   if (ret)
-   return ret;
-
-   return ttm_tt_create(bo, false);
-   }
+   if (!placement->num_placement && !placement->num_busy_placement)
+   return ttm_bo_pipeline_gutting(bo);
 
/*
 * Check whether we need to move buffer.
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 919ee03f7eb3..1860e2e7563f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -479,7 +479,8 @@ static void ttm_transfered_destroy(struct ttm_buffer_object 
*bo)
  */
 
 static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo,
- struct ttm_buffer_object **new_obj)
+ struct ttm_buffer_object **new_obj,
+ bool realloc_tt)
 {
struct ttm_transfer_obj *fbo;
int ret;
@@ -493,6 +494,17 @@ static int ttm_buffer_object_transfer(struct 
ttm_buffer_object *bo,
ttm_bo_get(bo);
fbo->bo = bo;
 
+   if (realloc_tt) {
+   bo->ttm = NULL;
+   ret = ttm_tt_create(bo, true);
+   if (ret) {
+   bo->ttm = fbo->base.ttm;
+   kfree(fbo);
+   ttm_bo_put(bo);
+   return ret;
+   }
+   }
+
/**
 * Fix up members that we shouldn't copy directly:
 * TODO: Explicit member copy would probably be better here.
@@ -763,7 +775,7 @@ static int ttm_bo_move_to_ghost(struct ttm_buffer_object 
*bo,
dma_fence_put(bo->moving);
bo->moving = dma_fence_get(fence);
 
-   ret = ttm_buffer_object_transfer(bo, _obj);
+   ret = ttm_buffer_object_transfer(bo, _obj, false);
if (ret)
return ret;
 
@@ -836,26 +848,51 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object 
*bo,
 }
 EXPORT_SYMBOL(ttm_bo_move_accel_cleanup);
 
+/**
+ * ttm_bo_pipeline_gutting - purge the contents of a bo
+ * @bo: The buffer object
+ *
+ * Purge the contents of a bo, async if the bo is not idle.
+ * After a successful call, the bo is left unpopulated in
+ * system placement. The function may wait uninterruptible
+ * for idle on OOM.
+ *
+ * Return: 0 if successful, negative error code on failure.
+ */
 int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
 {
static const struct ttm_place sys_mem = { .mem_type = TTM_PL_SYSTEM };
struct ttm_buffer_object *ghost;
int ret;
 
-   ret = ttm_buffer_object_transfer(bo, );
-   if (ret)
-   return ret;
+   /* If already idle, no need for ghost object dance. */
+   ret = ttm_bo_wait(bo, false, true);
+   if (ret == -EBUSY) {
+   ret = ttm_buffer_object_transfer(bo, , true);
+   if (ret)
+   return ret;
 
-   ret = dma_resv_copy_fences(>base._resv, bo->base.resv);
-   /* Last resort, wait for the BO to be idle when we are OOM */
-   if (ret)
-   ttm_bo_wait(bo, false, false);
+   

[Intel-gfx] [RFC PATCH 5/5] drm/ttm, drm/amdgpu: Allow the driver some control over swapping

[Thomas Hellström]

We are calling the eviction_valuable driver callback at eviction time to
determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for swapout,
and that might actually be beneficial to other drivers as well.

Add an eviction_valuable call also in the swapout path. Try to keep the
current behaviour for all drivers by returning true if the buffer object
is already in the TTM_PL_SYSTEM placement. We change behaviour for the
case where a buffer object is in a TT backed placement when swapped out,
in which case the drivers normal eviction_valuable path is run.

Finally make sure we don't try to swapout a bo that was recently purged
and therefore unpopulated.

Cc: Christian König 
Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  4 +++
 drivers/gpu/drm/ttm/ttm_bo.c| 41 +++--
 drivers/gpu/drm/ttm/ttm_tt.c|  4 +++
 3 files changed, 33 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 8c7ec09eb1a4..d5a9d7a88315 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1399,6 +1399,10 @@ static bool amdgpu_ttm_bo_eviction_valuable(struct 
ttm_buffer_object *bo,
struct dma_fence *f;
int i;
 
+   /* Swapout? */
+   if (bo->mem.mem_type == TTM_PL_SYSTEM)
+   return true;
+
if (bo->type == ttm_bo_type_kernel &&
!amdgpu_vm_evictable(ttm_to_amdgpu_bo(bo)))
return false;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index a8fa3375b8aa..3f7c64a1cda1 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -536,6 +536,10 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
 bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
  const struct ttm_place *place)
 {
+   dma_resv_assert_held(bo->base.resv);
+   if (bo->mem.mem_type == TTM_PL_SYSTEM)
+   return true;
+
/* Don't evict this BO if it's outside of the
 * requested placement range
 */
@@ -558,7 +562,9 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
  * b. Otherwise, trylock it.
  */
 static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
-   struct ttm_operation_ctx *ctx, bool *locked, bool *busy)
+  struct ttm_operation_ctx *ctx,
+  const struct ttm_place *place,
+  bool *locked, bool *busy)
 {
bool ret = false;
 
@@ -576,6 +582,12 @@ static bool ttm_bo_evict_swapout_allowable(struct 
ttm_buffer_object *bo,
*busy = !ret;
}
 
+   if (ret && place && !bo->bdev->funcs->eviction_valuable(bo, place)) {
+   ret = false;
+   if (locked)
+   dma_resv_unlock(bo->base.resv);
+   }
+
return ret;
 }
 
@@ -630,20 +642,14 @@ int ttm_mem_evict_first(struct ttm_device *bdev,
list_for_each_entry(bo, >lru[i], lru) {
bool busy;
 
-   if (!ttm_bo_evict_swapout_allowable(bo, ctx, ,
-   )) {
+   if (!ttm_bo_evict_swapout_allowable(bo, ctx, place,
+   , )) {
if (busy && !busy_bo && ticket !=
dma_resv_locking_ctx(bo->base.resv))
busy_bo = bo;
continue;
}
 
-   if (place && !bdev->funcs->eviction_valuable(bo,
- place)) {
-   if (locked)
-   dma_resv_unlock(bo->base.resv);
-   continue;
-   }
if (!ttm_bo_get_unless_zero(bo)) {
if (locked)
dma_resv_unlock(bo->base.resv);
@@ -1138,10 +1144,18 @@ EXPORT_SYMBOL(ttm_bo_wait);
 int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx,
   gfp_t gfp_flags)
 {
+   struct ttm_place place = {};
bool locked;
int ret;
 
-   if (!ttm_bo_evict_swapout_allowable(bo, ctx, , NULL))
+   /*
+* While the bo may already reside in SYSTEM placement, set
+* SYSTEM as new placement to cover also the move further below.
+* The driver may use the fact that we're moving from SYSTEM
+* as an indication that we're about to swap out.
+*/
+   place.mem_type = TTM_PL_SYSTEM;
+   if (!ttm_bo_evict_swapout_allowable(bo, 

[Intel-gfx] [RFC PATCH 0/5] Core TTM changes for i915 TTM enabling

[Thomas Hellström]

This is mainly a pre-check that the core TTM changes for the initial
i915 TTM patch series look reasonably ok.

Main thing is we add the new page-based iomem memcpy util to TTM, and
for some speed the copy-from-wc-x86-only prefetching memcpy to core drm.
Note that the legacy memcpy path is largely untested. Perhaps can give
it some testing on vmwgfx.

A bugfix and some minor optimization for the ttm_bo_pipeline_gutting()
idle case

Finally allow the frequently-pinning i915 driver to block swapping of
pinned memory that is still on the LRU.

If OK, I'd like to include these as a part of the i915 series.

Cc: Christian König 
Cc: Dave Airlie 
Cc: Daniel Vetter 

Thomas Hellström (5):
  drm/ttm: Add a generic TTM memcpy move for page-based iomem
  drm, drm/i915: Move the memcpy_from_wc functionality to core drm
  drm/ttm: Use drm_memcpy_from_wc for TTM bo moves
  drm/ttm: Document and optimize ttm_bo_pipeline_gutting()
  drm/ttm, drm/amdgpu: Allow the driver some control over swapping

 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |   4 +
 drivers/gpu/drm/drm_drv.c |   2 +
 .../drm/{i915/i915_memcpy.c => drm_memcpy.c}  |  31 +-
 drivers/gpu/drm/i915/Makefile |   1 -
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|   4 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.c|   5 +-
 drivers/gpu/drm/i915/gt/selftest_reset.c  |   7 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.c|  11 +-
 drivers/gpu/drm/i915/i915_cmd_parser.c|   4 +-
 drivers/gpu/drm/i915/i915_drv.c   |   2 -
 drivers/gpu/drm/i915/i915_gpu_error.c |   8 +-
 drivers/gpu/drm/i915/i915_memcpy.h|  34 --
 .../drm/i915/selftests/intel_memory_region.c  |   7 +-
 drivers/gpu/drm/ttm/ttm_bo.c  |  61 +-
 drivers/gpu/drm/ttm/ttm_bo_util.c | 547 --
 drivers/gpu/drm/ttm/ttm_tt.c  |   9 +
 include/drm/drm_memcpy.h  |  41 ++
 include/drm/ttm/ttm_bo_driver.h   |  94 +++
 include/drm/ttm/ttm_tt.h  |  10 +
 20 files changed, 614 insertions(+), 270 deletions(-)
 rename drivers/gpu/drm/{i915/i915_memcpy.c => drm_memcpy.c} (84%)
 delete mode 100644 drivers/gpu/drm/i915/i915_memcpy.h
 create mode 100644 include/drm/drm_memcpy.h

-- 
2.31.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC PATCH 3/5] drm/ttm: Use drm_memcpy_from_wc for TTM bo moves

[Thomas Hellström]

Use fast wc memcpy for reading out of wc memory for TTM bo moves.

Cc: Dave Airlie 
Cc: Christian König 
Cc: Daniel Vetter 
Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index bad9b16e96ba..919ee03f7eb3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -31,6 +31,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -185,6 +186,7 @@ void ttm_move_memcpy(struct ttm_buffer_object *bo,
struct ttm_resource *old_mem = >mem;
struct ttm_resource_manager *old_man = ttm_manager_type(bdev, 
old_mem->mem_type);
struct dma_buf_map old_map, new_map;
+   bool wc_memcpy;
pgoff_t i;
 
/* Single TTM move. NOP */
@@ -208,11 +210,25 @@ void ttm_move_memcpy(struct ttm_buffer_object *bo,
return;
}
 
+   wc_memcpy = ((!old_man->use_tt || bo->ttm->caching != ttm_cached) &&
+drm_has_memcpy_from_wc());
+
+   /*
+* We use some nasty aliasing for drm_memcpy_from_wc, but assuming
+* that we can move to memremapping in the not too distant future,
+* reduce the fragility for now with a build assert.
+*/
+   BUILD_BUG_ON(offsetof(typeof(old_map), vaddr) !=
+offsetof(typeof(old_map), vaddr_iomem));
+
for (i = 0; i < new_mem->num_pages; ++i) {
new_iter->ops->kmap_local(new_iter, _map, i);
old_iter->ops->kmap_local(old_iter, _map, i);
 
-   if (!old_map.is_iomem && !new_map.is_iomem) {
+   if (wc_memcpy) {
+   drm_memcpy_from_wc(new_map.vaddr, old_map.vaddr,
+  PAGE_SIZE);
+   } else if (!old_map.is_iomem && !new_map.is_iomem) {
memcpy(new_map.vaddr, old_map.vaddr, PAGE_SIZE);
} else if (!old_map.is_iomem) {
dma_buf_map_memcpy_to(_map, old_map.vaddr,
-- 
2.31.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC PATCH 2/5] drm, drm/i915: Move the memcpy_from_wc functionality to core drm

[Thomas Hellström]

Memcpy from wc will be used as well by TTM memcpy.
Move it to core drm, and make the interface do the right thing
even on !X86.

Cc: Christian König 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/Makefile  |  2 +-
 drivers/gpu/drm/drm_drv.c |  2 +
 .../drm/{i915/i915_memcpy.c => drm_memcpy.c}  | 31 +++---
 drivers/gpu/drm/i915/Makefile |  1 -
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  4 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  5 ++-
 drivers/gpu/drm/i915/gt/selftest_reset.c  |  7 ++--
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 11 ++---
 drivers/gpu/drm/i915/i915_cmd_parser.c|  4 +-
 drivers/gpu/drm/i915/i915_drv.c   |  2 -
 drivers/gpu/drm/i915/i915_gpu_error.c |  8 ++--
 drivers/gpu/drm/i915/i915_memcpy.h| 34 ---
 .../drm/i915/selftests/intel_memory_region.c  |  7 ++--
 include/drm/drm_memcpy.h  | 41 +++
 14 files changed, 83 insertions(+), 76 deletions(-)
 rename drivers/gpu/drm/{i915/i915_memcpy.c => drm_memcpy.c} (84%)
 delete mode 100644 drivers/gpu/drm/i915/i915_memcpy.h
 create mode 100644 include/drm/drm_memcpy.h

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a91cc7684904..f3ab8586c3d7 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,7 +18,7 @@ drm-y   :=drm_aperture.o drm_auth.o drm_cache.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o \
-   drm_managed.o drm_vblank_work.o
+   drm_managed.o drm_vblank_work.o drm_memcpy.o \
 
 drm-$(CONFIG_DRM_LEGACY) += drm_agpsupport.o drm_bufs.o drm_context.o 
drm_dma.o \
drm_legacy_misc.o drm_lock.o drm_memory.o 
drm_scatter.o \
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 3d8d68a98b95..351cc2900cf1 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1041,6 +1042,7 @@ static int __init drm_core_init(void)
 
drm_connector_ida_init();
idr_init(_minors_idr);
+   drm_memcpy_init_early();
 
ret = drm_sysfs_init();
if (ret < 0) {
diff --git a/drivers/gpu/drm/i915/i915_memcpy.c b/drivers/gpu/drm/drm_memcpy.c
similarity index 84%
rename from drivers/gpu/drm/i915/i915_memcpy.c
rename to drivers/gpu/drm/drm_memcpy.c
index 1b021a4902de..03688425a096 100644
--- a/drivers/gpu/drm/i915/i915_memcpy.c
+++ b/drivers/gpu/drm/drm_memcpy.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: MIT
 /*
  * Copyright © 2016 Intel Corporation
  *
@@ -22,16 +23,11 @@
  *
  */
 
+#ifdef CONFIG_X86
 #include 
 #include 
 
-#include "i915_memcpy.h"
-
-#if IS_ENABLED(CONFIG_DRM_I915_DEBUG)
-#define CI_BUG_ON(expr) BUG_ON(expr)
-#else
-#define CI_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
-#endif
+#include "drm/drm_memcpy.h"
 
 static DEFINE_STATIC_KEY_FALSE(has_movntdqa);
 
@@ -94,23 +90,23 @@ static void __memcpy_ntdqu(void *dst, const void *src, 
unsigned long len)
 }
 
 /**
- * i915_memcpy_from_wc: perform an accelerated *aligned* read from WC
+ * drm_memcpy_from_wc: perform an accelerated *aligned* read from WC
  * @dst: destination pointer
  * @src: source pointer
  * @len: how many bytes to copy
  *
- * i915_memcpy_from_wc copies @len bytes from @src to @dst using
+ * drm_memcpy_from_wc copies @len bytes from @src to @dst using
  * non-temporal instructions where available. Note that all arguments
  * (@src, @dst) must be aligned to 16 bytes and @len must be a multiple
  * of 16.
  *
  * To test whether accelerated reads from WC are supported, use
- * i915_memcpy_from_wc(NULL, NULL, 0);
+ * drm_memcpy_from_wc(NULL, NULL, 0);
  *
  * Returns true if the copy was successful, false if the preconditions
  * are not met.
  */
-bool i915_memcpy_from_wc(void *dst, const void *src, unsigned long len)
+bool drm_memcpy_from_wc(void *dst, const void *src, unsigned long len)
 {
if (unlikely(((unsigned long)dst | (unsigned long)src | len) & 15))
return false;
@@ -123,24 +119,23 @@ bool i915_memcpy_from_wc(void *dst, const void *src, 
unsigned long len)
 
return false;
 }
+EXPORT_SYMBOL(drm_memcpy_from_wc);
 
 /**
- * i915_unaligned_memcpy_from_wc: perform a mostly accelerated read from WC
+ * drm_unaligned_memcpy_from_wc: perform a mostly accelerated read from WC
  * @dst: destination pointer
  * @src: source pointer
  * @len: how many bytes to copy
  *
- * Like i915_memcpy_from_wc(), the unaligned variant copies @len bytes from
+ * Like drm_memcpy_from_wc(), the unaligned variant copies @len bytes from
  * @src to @dst using * non-temporal instructions where available, but
  * accepts that its arguments may not 

[Intel-gfx] [RFC PATCH 1/5] drm/ttm: Add a generic TTM memcpy move for page-based iomem

[Thomas Hellström]

The internal ttm_bo_util memcpy uses ioremap functionality, and while it
probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() / io_mem_free()
callbacks, that would cause problems with fault().
Instead, implement a method mapping page-by-page using kmap_local()
semantics. As an additional benefit we then avoid the occasional global
TLB flushes of ioremap() and consuming ioremap space, elimination of a
critical point of failure and with a slight change of semantics we could
also push the memcpy out async for testing and async driver development
purposes.

A special linear iomem iterator is introduced internally to mimic the
old ioremap behaviour for code-paths that can't immediately be ported
over. This adds to the code size and should be considered a temporary
solution.

Looking at the code we have a lot of checks for iomap tagged pointers.
Ideally we should extend the core memremap functions to also accept
uncached memory and kmap_local functionality. Then we could strip a
lot of code.

Cc: Christian König 
Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 468 --
 include/drm/ttm/ttm_bo_driver.h   |  94 ++
 2 files changed, 407 insertions(+), 155 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index ae8b61460724..bad9b16e96ba 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -35,11 +35,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 struct ttm_transfer_obj {
struct ttm_buffer_object base;
@@ -72,190 +74,366 @@ void ttm_mem_io_free(struct ttm_device *bdev,
mem->bus.addr = NULL;
 }
 
-static int ttm_resource_ioremap(struct ttm_device *bdev,
-  struct ttm_resource *mem,
-  void **virtual)
+static pgprot_t ttm_prot_from_caching(enum ttm_caching caching, pgprot_t tmp)
 {
-   int ret;
-   void *addr;
+   /* Cached mappings need no adjustment */
+   if (caching == ttm_cached)
+   return tmp;
 
-   *virtual = NULL;
-   ret = ttm_mem_io_reserve(bdev, mem);
-   if (ret || !mem->bus.is_iomem)
-   return ret;
+#if defined(__i386__) || defined(__x86_64__)
+   if (caching == ttm_write_combined)
+   tmp = pgprot_writecombine(tmp);
+   else if (boot_cpu_data.x86 > 3)
+   tmp = pgprot_noncached(tmp);
+#endif
+#if defined(__ia64__) || defined(__arm__) || defined(__aarch64__) || \
+   defined(__powerpc__) || defined(__mips__)
+   if (caching == ttm_write_combined)
+   tmp = pgprot_writecombine(tmp);
+   else
+   tmp = pgprot_noncached(tmp);
+#endif
+#if defined(__sparc__)
+   tmp = pgprot_noncached(tmp);
+#endif
+   return tmp;
+}
 
-   if (mem->bus.addr) {
-   addr = mem->bus.addr;
-   } else {
-   size_t bus_size = (size_t)mem->num_pages << PAGE_SHIFT;
+static void ttm_kmap_iter_tt_kmap_local(struct ttm_kmap_iter *iter,
+   struct dma_buf_map *dmap,
+   pgoff_t i)
+{
+   struct ttm_kmap_iter_tt *iter_tt =
+   container_of(iter, typeof(*iter_tt), base);
 
-   if (mem->bus.caching == ttm_write_combined)
-   addr = ioremap_wc(mem->bus.offset, bus_size);
-#ifdef CONFIG_X86
-   else if (mem->bus.caching == ttm_cached)
-   addr = ioremap_cache(mem->bus.offset, bus_size);
-#endif
-   else
-   addr = ioremap(mem->bus.offset, bus_size);
-   if (!addr) {
-   ttm_mem_io_free(bdev, mem);
-   return -ENOMEM;
-   }
+   dma_buf_map_set_vaddr(dmap, kmap_local_page_prot(iter_tt->tt->pages[i],
+iter_tt->prot));
+}
+
+static void ttm_kmap_iter_iomap_kmap_local(struct ttm_kmap_iter *iter,
+  struct dma_buf_map *dmap,
+  pgoff_t i)
+{
+   struct ttm_kmap_iter_iomap *iter_io =
+   container_of(iter, typeof(*iter_io), base);
+   void __iomem *addr;
+
+retry:
+   while (i >= iter_io->cache.end) {
+   iter_io->cache.sg = iter_io->cache.sg ?
+   sg_next(iter_io->cache.sg) : iter_io->st->sgl;
+   iter_io->cache.i = iter_io->cache.end;
+   iter_io->cache.end += sg_dma_len(iter_io->cache.sg) >>
+   PAGE_SHIFT;
+   iter_io->cache.offs = sg_dma_address(iter_io->cache.sg) -
+   iter_io->start;
}
-   *virtual = addr;
-   return 0;
+
+   if (i < iter_io->cache.i) {
+   iter_io->cache.end = 0;
+   

Re: [Intel-gfx] [PATCH] drm/i915: Use DRIVER_NAME for tracing unattached requests

[Daniel Vetter]

On Thu, May 20, 2021 at 08:35:14AM +0100, Matthew Auld wrote:
> From: Chris Wilson 
> 
> The first tracepoint for a request is trace_dma_fence_init called before
> we have associated the request with a device. The tracepoint uses
> fence->ops->get_driver_name() as a pretty name, and as we try to report
> the device name this oopses as it is then NULL. Support the early
> tracepoint by reporting the DRIVER_NAME instead of the actual device
> name.
> 
> Note that rq->engine remains during the course of request recycling
> (SLAB_TYPESAFE_BY_RCU). For the physical engines, the pointer remains
> valid, however a virtual engine may be destroyed after the request is
> retired. If we process a preempt-to-busy completed request along the
> virtual engine, we should make sure we mark the request as no longer
> belonging to the virtual engine to remove the dangling pointers from the
> tracepoint.

Why can't we assign the request beforehand? The idea behind these
tracepoints is that they actually match up, if trace_dma_fence_init is
different, then we're breaking that.
-Daniel

> 
> Fixes: 855e39e65cfc ("drm/i915: Initialise basic fence before acquiring 
> seqno")
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Chintan M Patel 
> Cc: Andi Shyti 
> Cc:  # v5.7+
> Signed-off-by: Matthew Auld 
> ---
>  .../drm/i915/gt/intel_execlists_submission.c  | 20 ++-
>  drivers/gpu/drm/i915/i915_request.c   |  7 ++-
>  2 files changed, 21 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index de124870af44..75604e927d34 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -3249,6 +3249,18 @@ static struct list_head *virtual_queue(struct 
> virtual_engine *ve)
>   return >base.execlists.default_priolist.requests;
>  }
>  
> +static void
> +virtual_submit_completed(struct virtual_engine *ve, struct i915_request *rq)
> +{
> + GEM_BUG_ON(!__i915_request_is_complete(rq));
> + GEM_BUG_ON(rq->engine != >base);
> +
> + __i915_request_submit(rq);
> +
> + /* Remove the dangling pointer to the stale virtual engine */
> + WRITE_ONCE(rq->engine, ve->siblings[0]);
> +}
> +
>  static void rcu_virtual_context_destroy(struct work_struct *wrk)
>  {
>   struct virtual_engine *ve =
> @@ -3265,8 +3277,7 @@ static void rcu_virtual_context_destroy(struct 
> work_struct *wrk)
>  
>   old = fetch_and_zero(>request);
>   if (old) {
> - GEM_BUG_ON(!__i915_request_is_complete(old));
> - __i915_request_submit(old);
> + virtual_submit_completed(ve, old);
>   i915_request_put(old);
>   }
>  
> @@ -3538,13 +3549,12 @@ static void virtual_submit_request(struct 
> i915_request *rq)
>  
>   /* By the time we resubmit a request, it may be completed */
>   if (__i915_request_is_complete(rq)) {
> - __i915_request_submit(rq);
> + virtual_submit_completed(ve, rq);
>   goto unlock;
>   }
>  
>   if (ve->request) { /* background completion from preempt-to-busy */
> - GEM_BUG_ON(!__i915_request_is_complete(ve->request));
> - __i915_request_submit(ve->request);
> + virtual_submit_completed(ve, ve->request);
>   i915_request_put(ve->request);
>   }
>  
> diff --git a/drivers/gpu/drm/i915/i915_request.c 
> b/drivers/gpu/drm/i915/i915_request.c
> index 970d8f4986bb..aa124adb1051 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -61,7 +61,12 @@ static struct i915_global_request {
>  
>  static const char *i915_fence_get_driver_name(struct dma_fence *fence)
>  {
> - return dev_name(to_request(fence)->engine->i915->drm.dev);
> + struct i915_request *rq = to_request(fence);
> +
> + if (unlikely(!rq->engine)) /* not yet attached to any device */
> + return DRIVER_NAME;
> +
> + return dev_name(rq->engine->i915->drm.dev);
>  }
>  
>  static const char *i915_fence_get_timeline_name(struct dma_fence *fence)
> -- 
> 2.26.3
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness

[Christian König]

Am 20.05.21 um 16:11 schrieb Daniel Vetter:

On Wed, May 19, 2021 at 11:17:24PM +, Nieto, David M wrote:

[AMD Official Use Only]

Parsing over 550 processes for fdinfo is taking between 40-100ms single
threaded in a 2GHz skylake IBRS within a VM using simple string
comparisons and DIRent parsing. And that is pretty much the worst case
scenario with some more optimized implementations.

I think this is plenty ok, and if it's not you could probably make this
massively faster with io_uring for all the fs operations and whack a
parser-generator on top for real parsing speed.


Well if it becomes a problem fixing the debugfs "clients" file and 
making it sysfs shouldn't be much of a problem later on.


Christian.



So imo we shouldn't worry about algorithmic inefficiency of the fdinfo
approach at all, and focuse more on trying to reasonably (but not too
much, this is still drm render stuff after all) standardize how it works
and how we'll extend it all. I think there's tons of good suggestions in
this thread on this topic already.

/me out
-Daniel


David

From: Daniel Vetter 
Sent: Wednesday, May 19, 2021 11:23 AM
To: Tvrtko Ursulin 
Cc: Daniel Stone ; jhubb...@nvidia.com ; nouv...@lists.freedesktop.org 
; Intel Graphics Development ; Maling list - DRI 
developers ; Simon Ser ; Koenig, Christian 
; arit...@nvidia.com ; Nieto, David M 
Subject: Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness

On Wed, May 19, 2021 at 6:16 PM Tvrtko Ursulin
 wrote:


On 18/05/2021 10:40, Tvrtko Ursulin wrote:

On 18/05/2021 10:16, Daniel Stone wrote:

Hi,

On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin
 wrote:

I was just wondering if stat(2) and a chrdev major check would be a
solid criteria to more efficiently (compared to parsing the text
content) detect drm files while walking procfs.

Maybe I'm missing something, but is the per-PID walk actually a
measurable performance issue rather than just a bit unpleasant?

Per pid and per each open fd.

As said in the other thread what bothers me a bit in this scheme is that
the cost of obtaining GPU usage scales based on non-GPU criteria.

For use case of a top-like tool which shows all processes this is a
smaller additional cost, but then for a gpu-top like tool it is somewhat
higher.

To further expand, not only cost would scale per pid multiplies per open
fd, but to detect which of the fds are DRM I see these three options:

1) Open and parse fdinfo.
2) Name based matching ie /dev/dri/.. something.
3) Stat the symlink target and check for DRM major.

stat with symlink following should be plenty fast.


All sound quite sub-optimal to me.

Name based matching is probably the least evil on system resource usage
(Keeping the dentry cache too hot? Too many syscalls?), even though
fundamentally I don't it is the right approach.

What happens with dup(2) is another question.

We need benchmark numbers showing that on anything remotely realistic
it's an actual problem. Until we've demonstrated it's a real problem
we don't need to solve it.

E.g. top with any sorting enabled also parses way more than it
displays on every update. It seems to be doing Just Fine (tm).


Does anyone have any feedback on the /proc//gpu idea at all?

When we know we have a problem to solve we can take a look at solutions.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.ffwll.ch%2Fdata=04%7C01%7CChristian.Koenig%40amd.com%7Ced2eccaa081d4cd336d408d91b991ee0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637571166744508313%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ZihrnanU70nJAM6bHYCjRnURDDCIdwGI85imjGd%2FNgs%3Dreserved=0


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness

[Daniel Vetter]

On Wed, May 19, 2021 at 11:17:24PM +, Nieto, David M wrote:
> [AMD Official Use Only]
> 
> Parsing over 550 processes for fdinfo is taking between 40-100ms single
> threaded in a 2GHz skylake IBRS within a VM using simple string
> comparisons and DIRent parsing. And that is pretty much the worst case
> scenario with some more optimized implementations.

I think this is plenty ok, and if it's not you could probably make this
massively faster with io_uring for all the fs operations and whack a
parser-generator on top for real parsing speed.

So imo we shouldn't worry about algorithmic inefficiency of the fdinfo
approach at all, and focuse more on trying to reasonably (but not too
much, this is still drm render stuff after all) standardize how it works
and how we'll extend it all. I think there's tons of good suggestions in
this thread on this topic already.

/me out
-Daniel

> 
> David
> 
> From: Daniel Vetter 
> Sent: Wednesday, May 19, 2021 11:23 AM
> To: Tvrtko Ursulin 
> Cc: Daniel Stone ; jhubb...@nvidia.com 
> ; nouv...@lists.freedesktop.org 
> ; Intel Graphics Development 
> ; Maling list - DRI developers 
> ; Simon Ser ; Koenig, 
> Christian ; arit...@nvidia.com 
> ; Nieto, David M 
> Subject: Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness
> 
> On Wed, May 19, 2021 at 6:16 PM Tvrtko Ursulin
>  wrote:
> >
> >
> > On 18/05/2021 10:40, Tvrtko Ursulin wrote:
> > >
> > > On 18/05/2021 10:16, Daniel Stone wrote:
> > >> Hi,
> > >>
> > >> On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin
> > >>  wrote:
> > >>> I was just wondering if stat(2) and a chrdev major check would be a
> > >>> solid criteria to more efficiently (compared to parsing the text
> > >>> content) detect drm files while walking procfs.
> > >>
> > >> Maybe I'm missing something, but is the per-PID walk actually a
> > >> measurable performance issue rather than just a bit unpleasant?
> > >
> > > Per pid and per each open fd.
> > >
> > > As said in the other thread what bothers me a bit in this scheme is that
> > > the cost of obtaining GPU usage scales based on non-GPU criteria.
> > >
> > > For use case of a top-like tool which shows all processes this is a
> > > smaller additional cost, but then for a gpu-top like tool it is somewhat
> > > higher.
> >
> > To further expand, not only cost would scale per pid multiplies per open
> > fd, but to detect which of the fds are DRM I see these three options:
> >
> > 1) Open and parse fdinfo.
> > 2) Name based matching ie /dev/dri/.. something.
> > 3) Stat the symlink target and check for DRM major.
> 
> stat with symlink following should be plenty fast.
> 
> > All sound quite sub-optimal to me.
> >
> > Name based matching is probably the least evil on system resource usage
> > (Keeping the dentry cache too hot? Too many syscalls?), even though
> > fundamentally I don't it is the right approach.
> >
> > What happens with dup(2) is another question.
> 
> We need benchmark numbers showing that on anything remotely realistic
> it's an actual problem. Until we've demonstrated it's a real problem
> we don't need to solve it.
> 
> E.g. top with any sorting enabled also parses way more than it
> displays on every update. It seems to be doing Just Fine (tm).
> 
> > Does anyone have any feedback on the /proc//gpu idea at all?
> 
> When we know we have a problem to solve we can take a look at solutions.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.ffwll.ch%2Fdata=04%7C01%7CDavid.Nieto%40amd.com%7Cf6aea97532cf41f916de08d91af32cc1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637570453997158377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=4CFrY9qWbJREcIcSzeO9KIn2P%2Fw6k%2BYdNlh6rdS%2BEh4%3Dreserved=0

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-misc-fixes

[Maxime Ripard]

Hi Dave, Daniel,

Here's this week fix for drm-misc-fixes

Maxime

drm-misc-fixes-2021-05-20:
Just a single fix for a dma-buf related WARN
The following changes since commit c55b44c9386f3ee1b08752638559f19deaf6040d:

  Merge drm/drm-fixes into drm-misc-fixes (2021-05-11 13:35:52 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-05-20

for you to fetch changes up to 7e008b02557ccece4d2c31fb0eaf6243cbc87121:

  dma-buf: fix unintended pin/unpin warnings (2021-05-20 14:02:27 +0200)


Just a single fix for a dma-buf related WARN


Christian König (1):
  dma-buf: fix unintended pin/unpin warnings

 drivers/dma-buf/dma-buf.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gt: fix typo issue

[Matthew Auld]

On Thu, 20 May 2021 at 09:23, samirweng1979  wrote:
>
> From: wengjianfeng 
>
> change 'freqency' to 'frequency'.
>
> Signed-off-by: wengjianfeng 

Pushed to intel-gt-next. Thanks.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: fix typo issue

[Patchwork]

== Series Details ==

Series: drm/i915/gt: fix typo issue
URL   : https://patchwork.freedesktop.org/series/90364/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10112 -> Patchwork_20160


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u:   NOTRUN -> [WARN][1] ([i915#2283])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-soraka:  [PASS][2] -> [INCOMPLETE][3] ([i915#155])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10112/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_selftest@live@execlists:
- fi-bdw-5557u:   NOTRUN -> [DMESG-FAIL][4] ([i915#3462])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][5] -> [INCOMPLETE][6] ([i915#2782])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10112/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u:   NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u:   NOTRUN -> [SKIP][8] ([fdo#109271]) +9 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html

  
 Possible fixes 

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [FAIL][9] ([i915#1372]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10112/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  [FAIL][11] ([i915#49]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10112/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  
 Warnings 

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[DMESG-FAIL][13] ([i915#3462]) -> [INCOMPLETE][14] 
([i915#2782] / [i915#2940] / [i915#3462])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10112/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
- fi-icl-u2:  [INCOMPLETE][15] ([i915#2782] / [i915#3462]) -> 
[DMESG-FAIL][16] ([i915#3462])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10112/fi-icl-u2/igt@i915_selftest@l...@execlists.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/fi-icl-u2/igt@i915_selftest@l...@execlists.html

  * igt@runner@aborted:
- fi-skl-6600u:   [FAIL][17] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][18] ([i915#1436] / [i915#3363])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10112/fi-skl-6600u/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/fi-skl-6600u/igt@run...@aborted.html
- fi-icl-u2:  [FAIL][19] ([i915#2782] / [i915#3363]) -> [FAIL][20] 
([i915#2426] / [i915#2782] / [i915#3363])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10112/fi-icl-u2/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/fi-icl-u2/igt@run...@aborted.html
- fi-bdw-5557u:   [FAIL][21] ([i915#1602] / [i915#2029]) -> [FAIL][22] 
([i915#3462])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10112/fi-bdw-5557u/igt@run...@aborted.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/fi-bdw-5557u/igt@run...@aborted.html
- fi-cfl-guc: [FAIL][23] ([i915#2426] / [i915#3363]) -> [FAIL][24] 
([i915#3363])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10112/fi-cfl-guc/igt@run...@aborted.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20160/fi-cfl-guc/igt@run...@aborted.html
- fi-skl-6700k2:  [FAIL][25] ([i915#1436] / [i915#3363]) -> [FAIL][26] 
([i915#1436] / [i915#2426] / [i915#3363])
   [25]: 

Re: [Intel-gfx] [PATCH v6 1/3] gpu: drm: separate panel orientation property creating and value setting

[Sean Paul]

On Thu, Apr 29, 2021 at 12:28 AM Hsin-Yi Wang  wrote:
>
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in following
> warning.
>
> Add a function to create panel orientation property and set default value
> to UNKNOWN, so drivers can call this function to init the property earlier
> , and let the panel set the real value later.
>
> [4.480976] [ cut here ]
> [4.485603] WARNING: CPU: 5 PID: 369 at 
> drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
> 
> [4.609772] Call trace:
> [4.612208]  __drm_mode_object_add+0xb4/0xbc
> [4.616466]  drm_mode_object_add+0x20/0x2c
> [4.620552]  drm_property_create+0xdc/0x174
> [4.624723]  drm_property_create_enum+0x34/0x98
> [4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
> [4.634716]  boe_panel_get_modes+0x88/0xd8
> [4.638802]  drm_panel_get_modes+0x2c/0x48
> [4.642887]  panel_bridge_get_modes+0x1c/0x28
> [4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
> [4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
> [4.658266]  drm_mode_getconnector+0x1b4/0x45c
> [4.662699]  drm_ioctl_kernel+0xac/0x128
> [4.11]  drm_ioctl+0x268/0x410
> [4.670002]  drm_compat_ioctl+0xdc/0xf0
> [4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
> [4.678436]  el0_svc_common+0xf4/0x1c0
> [4.682174]  do_el0_svc_compat+0x28/0x3c
> [4.686088]  el0_svc_compat+0x10/0x1c
> [4.689738]  el0_sync_compat_handler+0xa8/0xcc
> [4.694171]  el0_sync_compat+0x178/0x180
> [4.698082] ---[ end trace b4f2db9d9c88610b ]---
> [4.702721] [ cut here ]
> [4.707329] WARNING: CPU: 5 PID: 369 at 
> drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
> 
> [4.833830] Call trace:
> [4.836266]  drm_object_attach_property+0x48/0xb8
> [4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
> [4.846432]  boe_panel_get_modes+0x88/0xd8
> [4.850516]  drm_panel_get_modes+0x2c/0x48
> [4.854600]  panel_bridge_get_modes+0x1c/0x28
> [4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
> [4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
> [4.869978]  drm_mode_getconnector+0x1b4/0x45c
> [4.874410]  drm_ioctl_kernel+0xac/0x128
> [4.878320]  drm_ioctl+0x268/0x410
> [4.881711]  drm_compat_ioctl+0xdc/0xf0
> [4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
> [4.890142]  el0_svc_common+0xf4/0x1c0
> [4.893879]  do_el0_svc_compat+0x28/0x3c
> [4.897791]  el0_svc_compat+0x10/0x1c
> [4.901441]  el0_sync_compat_handler+0xa8/0xcc
> [4.905873]  el0_sync_compat+0x178/0x180
> [4.909783] ---[ end trace b4f2db9d9c88610c ]---
>

+intel-gfx for i915 changes

Reviewed-by: Sean Paul 

> Signed-off-by: Hsin-Yi Wang 
> ---
> v6, v5:
> don't create property in set_panel_orientation.
>
> v4, v3:
> create property in dsi driver and set value in panel.
>
> v2:
> create property in connector init
> https://patchwork.kernel.org/project/linux-mediatek/patch/20210426051848.2600890-1-hsi...@chromium.org/
>
> v1:
> set panel orientation in dsi driver
> https://patchwork.kernel.org/project/linux-mediatek/patch/20210409045314.3420733-1-hsi...@chromium.org/
> ---
>  drivers/gpu/drm/drm_connector.c | 58 ++---
>  drivers/gpu/drm/i915/display/icl_dsi.c  |  1 +
>  drivers/gpu/drm/i915/display/intel_dp.c |  1 +
>  drivers/gpu/drm/i915/display/vlv_dsi.c  |  1 +
>  include/drm/drm_connector.h |  2 +
>  5 files changed, 47 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 7631f76e7f34..7189baaabf41 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1210,7 +1210,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] 
> = {
>   * INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
>   * coordinates, so if userspace rotates the picture to adjust for
>   * the orientation it must also apply the same transformation to the
> - * touchscreen input coordinates. This property is initialized by calling
> + * touchscreen input coordinates. This property value is set by calling
>   * drm_connector_set_panel_orientation() or
>   * drm_connector_set_panel_orientation_with_quirk()
>   *
> @@ -2173,8 +2173,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
>   * @connector: connector for which to set the panel-orientation property.
>   * @panel_orientation: drm_panel_orientation value to set
>   *
> - * This function sets the connector's panel_orientation and attaches
> - * a "panel orientation" property to the connector.
> + * This function sets the connector's panel_orientation value. If the 
> 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Implement PSF GV point support

[Patchwork]

== Series Details ==

Series: drm/i915: Implement PSF GV point support
URL   : https://patchwork.freedesktop.org/series/90361/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10111 -> Patchwork_20159


Summary
---

  **FAILURE**

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

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@reload:
- fi-icl-u2:  [PASS][1] -> [DMESG-WARN][2] +2 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10111/fi-icl-u2/igt@i915_module_l...@reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20159/fi-icl-u2/igt@i915_module_l...@reload.html

  * igt@i915_pm_rpm@module-reload:
- fi-icl-y:   [PASS][3] -> [DMESG-WARN][4] +2 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10111/fi-icl-y/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20159/fi-icl-y/igt@i915_pm_...@module-reload.html

  
 Suppressed 

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

  * igt@i915_module_load@reload:
- {fi-rkl-11500t}:[FAIL][5] ([i915#3277]) -> [DMESG-FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10111/fi-rkl-11500t/igt@i915_module_l...@reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20159/fi-rkl-11500t/igt@i915_module_l...@reload.html

  * igt@i915_pm_rpm@module-reload:
- {fi-rkl-11500t}:[PASS][7] -> [DMESG-WARN][8] +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10111/fi-rkl-11500t/igt@i915_pm_...@module-reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20159/fi-rkl-11500t/igt@i915_pm_...@module-reload.html

  * igt@kms_busy@basic@modeset:
- {fi-rkl-11500t}:[FAIL][9] ([i915#3276]) -> [DMESG-FAIL][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10111/fi-rkl-11500t/igt@kms_busy@ba...@modeset.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20159/fi-rkl-11500t/igt@kms_busy@ba...@modeset.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][11] -> [INCOMPLETE][12] ([i915#2782])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10111/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20159/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  [PASS][13] -> [FAIL][14] ([i915#49])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10111/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20159/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  
 Warnings 

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][15] ([i915#2782] / [i915#2940] / 
[i915#3462]) -> [DMESG-FAIL][16] ([i915#3462])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10111/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20159/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * igt@runner@aborted:
- fi-bsw-kefka:   [FAIL][17] ([i915#1436]) -> [FAIL][18] ([i915#1436] / 
[i915#2722])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10111/fi-bsw-kefka/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20159/fi-bsw-kefka/igt@run...@aborted.html
- fi-cfl-8700k:   [FAIL][19] ([i915#3363]) -> [FAIL][20] ([i915#2426] / 
[i915#3363])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10111/fi-cfl-8700k/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20159/fi-cfl-8700k/igt@run...@aborted.html
- fi-kbl-r:   [FAIL][21] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][22] ([i915#1436] / [i915#3363])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10111/fi-kbl-r/igt@run...@aborted.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20159/fi-kbl-r/igt@run...@aborted.html
- fi-kbl-soraka:  [FAIL][23] ([i915#1436] / [i915#3363]) -> [FAIL][24] 
([i915#1436] / [i915#2426] / [i915#3363])
   [23]: 

[Intel-gfx] [PATCH] drm/i915/gt: fix typo issue

[samirweng1979]

From: wengjianfeng 

change 'freqency' to 'frequency'.

Signed-off-by: wengjianfeng 
---
 drivers/gpu/drm/i915/gt/selftest_rps.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_rps.c 
b/drivers/gpu/drm/i915/gt/selftest_rps.c
index 967641f..71e6658 100644
--- a/drivers/gpu/drm/i915/gt/selftest_rps.c
+++ b/drivers/gpu/drm/i915/gt/selftest_rps.c
@@ -606,7 +606,7 @@ int live_rps_frequency_cs(void *arg)
int err = 0;
 
/*
-* The premise is that the GPU does change freqency at our behest.
+* The premise is that the GPU does change frequency at our behest.
 * Let's check there is a correspondence between the requested
 * frequency, the actual frequency, and the observed clock rate.
 */
@@ -747,7 +747,7 @@ int live_rps_frequency_srm(void *arg)
int err = 0;
 
/*
-* The premise is that the GPU does change freqency at our behest.
+* The premise is that the GPU does change frequency at our behest.
 * Let's check there is a correspondence between the requested
 * frequency, the actual frequency, and the observed clock rate.
 */
-- 
1.9.1


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Requests For Proposals for hosting XDC 2022 are now open

[Samuel Iglesias Gonsálvez]

Hello everyone!

The X.org board is soliciting proposals to host XDC in 2022. Since
XDC 2021 is being held in Europe this year (although virtually), we've
decided to host in North America. However, the board is open to other
locations, especially if there's an interesting co-location with
another conference.

Of course though, due to the ongoing COVID-19 pandemic it's not yet
clear whether or not it will be possible to host XDC 2022 in person,
although is seems very likely. Because of this, we would like to
make it clear that sponsors should prepare for both the possibility
of an in person conference, and the possibility of a virtual
conference. We will work with organizers on coming up with a
deadline for deciding whether or not we'll be going virtual, likely
sometime around July 2022.

If you're considering hosting XDC, we've assembled a wiki page with
what's generally expected and needed:

https://www.x.org/wiki/Events/RFP/

When submitting your proposal, please make sure to include at least the
key information about the potential location in question, possible
dates along with estimated costs. Proposals can be submitted to board
at foundation.x.org until the deadline of *September 1st, 2021*. 

Additionally, an quirk early heads-up to the board if you're
considering hosting would be appreciated, in case we need to adjust the
schedule a bit. Also, earlier is better since there generally will be a
bit of Q with organizers.

And if you just have some questions about what organizing XDC entails,
please feel free to chat with previous organizers, or someone from the
board.

Thanks,

Sam



signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness

[Nieto, David M]

[AMD Official Use Only]

Parsing over 550 processes for fdinfo is taking between 40-100ms single 
threaded in a 2GHz skylake IBRS within a VM using simple string comparisons and 
DIRent parsing. And that is pretty much the worst case scenario with some more 
optimized implementations.

David

From: Daniel Vetter 
Sent: Wednesday, May 19, 2021 11:23 AM
To: Tvrtko Ursulin 
Cc: Daniel Stone ; jhubb...@nvidia.com 
; nouv...@lists.freedesktop.org 
; Intel Graphics Development 
; Maling list - DRI developers 
; Simon Ser ; Koenig, 
Christian ; arit...@nvidia.com ; 
Nieto, David M 
Subject: Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness

On Wed, May 19, 2021 at 6:16 PM Tvrtko Ursulin
 wrote:
>
>
> On 18/05/2021 10:40, Tvrtko Ursulin wrote:
> >
> > On 18/05/2021 10:16, Daniel Stone wrote:
> >> Hi,
> >>
> >> On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin
> >>  wrote:
> >>> I was just wondering if stat(2) and a chrdev major check would be a
> >>> solid criteria to more efficiently (compared to parsing the text
> >>> content) detect drm files while walking procfs.
> >>
> >> Maybe I'm missing something, but is the per-PID walk actually a
> >> measurable performance issue rather than just a bit unpleasant?
> >
> > Per pid and per each open fd.
> >
> > As said in the other thread what bothers me a bit in this scheme is that
> > the cost of obtaining GPU usage scales based on non-GPU criteria.
> >
> > For use case of a top-like tool which shows all processes this is a
> > smaller additional cost, but then for a gpu-top like tool it is somewhat
> > higher.
>
> To further expand, not only cost would scale per pid multiplies per open
> fd, but to detect which of the fds are DRM I see these three options:
>
> 1) Open and parse fdinfo.
> 2) Name based matching ie /dev/dri/.. something.
> 3) Stat the symlink target and check for DRM major.

stat with symlink following should be plenty fast.

> All sound quite sub-optimal to me.
>
> Name based matching is probably the least evil on system resource usage
> (Keeping the dentry cache too hot? Too many syscalls?), even though
> fundamentally I don't it is the right approach.
>
> What happens with dup(2) is another question.

We need benchmark numbers showing that on anything remotely realistic
it's an actual problem. Until we've demonstrated it's a real problem
we don't need to solve it.

E.g. top with any sorting enabled also parses way more than it
displays on every update. It seems to be doing Just Fine (tm).

> Does anyone have any feedback on the /proc//gpu idea at all?

When we know we have a problem to solve we can take a look at solutions.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.ffwll.ch%2Fdata=04%7C01%7CDavid.Nieto%40amd.com%7Cf6aea97532cf41f916de08d91af32cc1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637570453997158377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=4CFrY9qWbJREcIcSzeO9KIn2P%2Fw6k%2BYdNlh6rdS%2BEh4%3Dreserved=0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Jani Nikula]

Hi Dave & Daniel -

drm-intel-fixes-2021-05-20:
drm/i915 fixes for v5.13-rc3:
- Pin the L-shape quirked object as unshrinkable to fix crashes
- Disable HiZ Raw Stall Optimization on broken gen7 to fix glitches, gfx 
corruption
- GVT: Move mdev attribute groups into kvmgt module to fix kconfig deps issue

BR,
Jani.

The following changes since commit d07f6ca923ea0927a1024dfccafc5b53b61cfecc:

  Linux 5.13-rc2 (2021-05-16 15:27:44 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2021-05-20

for you to fetch changes up to eddd1b8f467f82b8e9e137ef9dbaa842ecca6a2c:

  Merge tag 'gvt-fixes-2021-05-19' of https://github.com/intel/gvt-linux into 
drm-intel-fixes (2021-05-19 11:22:24 +0300)


drm/i915 fixes for v5.13-rc3:
- Pin the L-shape quirked object as unshrinkable to fix crashes
- Disable HiZ Raw Stall Optimization on broken gen7 to fix glitches, gfx 
corruption
- GVT: Move mdev attribute groups into kvmgt module to fix kconfig deps issue


Chris Wilson (1):
  drm/i915/gem: Pin the L-shape quirked object as unshrinkable

Jani Nikula (1):
  Merge tag 'gvt-fixes-2021-05-19' of https://github.com/intel/gvt-linux 
into drm-intel-fixes

Simon Rettberg (1):
  drm/i915/gt: Disable HiZ Raw Stall Optimization on broken gen7

Zhenyu Wang (1):
  drm/i915/gvt: Move mdev attribute groups into kvmgt module

 drivers/gpu/drm/i915/Kconfig   |   1 -
 drivers/gpu/drm/i915/gem/i915_gem_pages.c  |   2 +
 drivers/gpu/drm/i915/gt/gen7_renderclear.c |   5 +-
 drivers/gpu/drm/i915/gvt/gvt.c | 124 +
 drivers/gpu/drm/i915/gvt/gvt.h |   3 -
 drivers/gpu/drm/i915/gvt/hypercall.h   |   2 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c   | 122 +---
 drivers/gpu/drm/i915/gvt/mpt.h |   4 +-
 drivers/gpu/drm/i915/i915_gem.c|  11 ++-
 9 files changed, 129 insertions(+), 145 deletions(-)

-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Implement PSF GV point support

[Patchwork]

== Series Details ==

Series: drm/i915: Implement PSF GV point support
URL   : https://patchwork.freedesktop.org/series/90361/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
3c2cdfef9cf5 drm/i915: Implement PSF GV point support
-:50: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#50: FILE: drivers/gpu/drm/i915/display/intel_bw.c:59:
+static int adls_pcode_read_psf_gv_point_info(struct drm_i915_private *dev_priv,
+   struct intel_psf_gv_point *points)

-:95: WARNING:QUOTED_WHITESPACE_BEFORE_NEWLINE: unnecessary whitespace before a 
quoted newline
#95: FILE: drivers/gpu/drm/i915/display/intel_bw.c:150:
+   "PSF GV %d: CLK=%d \n",

total: 0 errors, 1 warnings, 1 checks, 222 lines checked


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Implement PSF GV point support

[Stanislav Lisovskiy]

PSF GV points are an additional factor that can limit the
bandwidth available to display, separate from the traditional
QGV points.  Whereas traditional QGV points represent possible
memory clock frequencies, PSF GV points reflect possible
frequencies of the memory fabric.

Switching between PSF GV points has the advantage of incurring
almost no memory access block time and thus does not need to be
accounted for in watermark calculations.

This patch adds support for those on top of regular QGV points.
Those are supposed to be used simultaneously, i.e we are always
at some QGV and some PSF GV point, based on the current video
mode requirements.
Bspec: 64631, 53998

Signed-off-by: Stanislav Lisovskiy 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/display/intel_bw.c | 100 +++-
 drivers/gpu/drm/i915/i915_drv.h |   7 ++
 drivers/gpu/drm/i915/i915_reg.h |   3 +
 drivers/gpu/drm/i915/intel_dram.c   |   1 +
 4 files changed, 108 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index 3a1ba52266a7..891e2f3c9739 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -17,9 +17,15 @@ struct intel_qgv_point {
u16 dclk, t_rp, t_rdpre, t_rc, t_ras, t_rcd;
 };
 
+struct intel_psf_gv_point {
+   u8 clk; /* clock in multiples of 16. MHz */
+};
+
 struct intel_qgv_info {
struct intel_qgv_point points[I915_NUM_QGV_POINTS];
+   struct intel_psf_gv_point psf_points[I915_NUM_PSF_GV_POINTS];
u8 num_points;
+   u8 num_psf_points;
u8 t_bl;
 };
 
@@ -49,6 +55,28 @@ static int icl_pcode_read_qgv_point_info(struct 
drm_i915_private *dev_priv,
return 0;
 }
 
+static int adls_pcode_read_psf_gv_point_info(struct drm_i915_private *dev_priv,
+   struct intel_psf_gv_point *points)
+{
+   u32 val = 0, val2 = 0;
+   int ret;
+   int i;
+
+   ret = sandybridge_pcode_read(dev_priv,
+ICL_PCODE_MEM_SUBSYSYSTEM_INFO |
+ADL_PCODE_MEM_SS_READ_PSF_GV_INFO,
+, );
+   if (ret)
+   return ret;
+
+   for (i = 0; i < I915_NUM_PSF_GV_POINTS; i++) {
+   points[i].clk = val & 0xff;
+   val >>= 8;
+   }
+
+   return 0;
+}
+
 int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
  u32 points_mask)
 {
@@ -76,6 +104,7 @@ static int icl_get_qgv_points(struct drm_i915_private 
*dev_priv,
int i, ret;
 
qi->num_points = dram_info->num_qgv_points;
+   qi->num_psf_points = dram_info->num_psf_gv_points;
 
if (DISPLAY_VER(dev_priv) == 12)
switch (dram_info->type) {
@@ -109,6 +138,19 @@ static int icl_get_qgv_points(struct drm_i915_private 
*dev_priv,
sp->t_rcd, sp->t_rc);
}
 
+   if (qi->num_psf_points > 0) {
+   ret = adls_pcode_read_psf_gv_point_info(dev_priv, 
qi->psf_points);
+   if (ret) {
+   drm_err(_priv->drm, "Failed to read PSF point data; 
PSF points will not be considered in bandwidth calculations.\n");
+   qi->num_psf_points = 0;
+   }
+
+   for (i = 0; i < qi->num_psf_points; i++)
+   drm_dbg_kms(_priv->drm,
+   "PSF GV %d: CLK=%d \n",
+   i, qi->psf_points[i].clk);
+   }
+
return 0;
 }
 
@@ -118,6 +160,16 @@ static int icl_calc_bw(int dclk, int num, int den)
return DIV_ROUND_CLOSEST(num * dclk * 100, den * 6);
 }
 
+static int adl_calc_psf_bw(int clk)
+{
+   /*
+* clk is multiples of 16.666MHz (100/6)
+* According to BSpec PSF GV bandwidth is
+* calculated as BW = 64 * clk * 16.666Mhz
+*/
+   return DIV_ROUND_CLOSEST(64 * clk * 100, 6);
+}
+
 static int icl_sagv_max_dclk(const struct intel_qgv_info *qi)
 {
u16 dclk = 0;
@@ -194,6 +246,7 @@ static int icl_get_bw_info(struct drm_i915_private 
*dev_priv, const struct intel
bi->num_planes = (ipqdepth - clpchgroup) / clpchgroup + 1;
 
bi->num_qgv_points = qi.num_points;
+   bi->num_psf_gv_points = qi.num_psf_points;
 
for (j = 0; j < qi.num_points; j++) {
const struct intel_qgv_point *sp = [j];
@@ -217,6 +270,16 @@ static int icl_get_bw_info(struct drm_i915_private 
*dev_priv, const struct intel
i, j, bi->num_planes, bi->deratedbw[j]);
}
 
+   for (j = 0; j < qi.num_psf_points; j++) {
+   const struct intel_psf_gv_point *sp = _points[j];
+
+   bi->psf_bw[j] = adl_calc_psf_bw(sp->clk);
+
+   drm_dbg_kms(_priv->drm,
+  

Re: [Intel-gfx] [Mesa-dev] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan

[Christian König]

Am 19.05.21 um 18:51 schrieb Matthew Brost:

On Wed, May 19, 2021 at 01:45:39PM +0200, Christian König wrote:

Oh, yeah we call that gang submit on the AMD side.

Had already some internal discussions how to implement this, but so far
couldn't figure out how to cleanly introduce that into the DRM scheduler.

Can you briefly describe in a few words how that is supposed to work on the
Intel side?


Sure, I've done a quick PoC internally and have been able to hook this
into the DRM scheduler.

Basically each BB still maps to a single job as each job is somewhat
unique (e.g. each job has its own ring, lrc, seqno, etc...). However all
the jobs configured to run in parallel map to a single sched_entity
which maintains the order each job was generated from the execbuf IOCTL
(1 - N). When the backend receives jobs 1 to N - 1 it basically just
updates some internal state. When the backend sees job N (last job) it
actually does the submit for jobs 1 - N which with GuC submission is a
simple command moving the LRC tail of the N jobs.

Daniel has suggested that we create a single job for the NN BBs but that
would be huge rework to the internals of the i915 and likely won't
happen by the time this code first lands.

Also worth noting one way a job isn't really a treated individually is
the excl slot with dma-resv. In that case we create a composite fence of
all jobs (dma_fence_array).


Yeah, that's something we have discussed as well.

How do you prevent the scheduler from over committing to a single ring 
buffer in this scenario?


Christian.



Matt


Thanks,
Christian.

Am 19.05.21 um 01:58 schrieb Matthew Brost:

Add entry fpr i915 new parallel submission uAPI plan.

v2:
   (Daniel Vetter):
- Expand logical order explaination
- Add dummy header
- Only allow N BBs in execbuf IOCTL
- Configure parallel submission per slot not per gem context

Cc: Tvrtko Ursulin 
Cc: Tony Ye 
CC: Carl Zhang 
Cc: Daniel Vetter 
Cc: Jason Ekstrand 
Signed-off-by: Matthew Brost 
---
   Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 ++
   Documentation/gpu/rfc/i915_scheduler.rst  |  53 ++-
   2 files changed, 196 insertions(+), 1 deletion(-)
   create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h

diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h 
b/Documentation/gpu/rfc/i915_parallel_execbuf.h
new file mode 100644
index ..8c64b983ccad
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
@@ -0,0 +1,144 @@
+#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see 
i915_context_engines_parallel_submit */
+
+/*
+ * i915_context_engines_parallel_submit:
+ *
+ * Setup a slot to allow multiple BBs to be submitted in a single execbuf 
IOCTL.
+ * Those BBs will then be scheduled to run on the GPU in parallel. Multiple
+ * hardware contexts are created internally in the i915 run these BBs. Once a
+ * slot is configured for N BBs only N BBs can be submitted in each execbuf
+ * IOCTL and this is implict behavior (e.g. the user doesn't tell the execbuf
+ * IOCTL there are N BBs, the execbuf IOCTL know how many BBs there are based 
on
+ * the slots configuration).
+ *
+ * Their are two currently defined ways to control the placement of the
+ * hardware contexts on physical engines: default behavior (no flags) and
+ * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the in the
+ * future as new hardware / use cases arise. Details of how to use this
+ * interface below above the flags.
+ *
+ * Returns -EINVAL if hardware context placement configuration invalid or if 
the
+ * placement configuration isn't supported on the platform / submission
+ * interface.
+ * Returns -ENODEV if extension isn't supported on the platform / submission
+ * inteface.
+ */
+struct i915_context_engines_parallel_submit {
+   struct i915_user_extension base;
+
+   __u16 engine_index; /* slot for parallel engine */
+   __u16 width;/* number of contexts per parallel engine */
+   __u16 num_siblings; /* number of siblings per context */
+   __u16 mbz16;
+/*
+ * Default placement behvavior (currently unsupported):
+ *
+ * Rather than restricting parallel submission to a single class with a
+ * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS), add a mode 
that
+ * enables parallel submission across multiple engine classes. In this case 
each
+ * context's logical engine mask indicates where that context can placed. It is
+ * implied in this mode that all contexts have mutual exclusive placement (e.g.
+ * if one context is running CS0 no other contexts can run on CS0).
+ *
+ * Example 1 pseudo code:
+ * CSX[Y] = engine class X, logical instance Y
+ * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
+ * set_engines(INVALID)
+ * set_parallel(engine_index=0, width=2, num_siblings=2,
+ * engines=CS0[0],CS0[1],CS1[0],CS1[1])
+ *
+ * Results in the following valid placements:
+ * CS0[0], CS1[0]
+ * 

Re: [Intel-gfx] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan

[Tvrtko Ursulin]

On 20/05/2021 10:54, Daniel Vetter wrote:

On Wed, May 19, 2021 at 7:19 PM Matthew Brost  wrote:


On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wrote:

On Tue, May 18, 2021 at 04:58:30PM -0700, Matthew Brost wrote:

Add entry fpr i915 new parallel submission uAPI plan.

v2:
  (Daniel Vetter):
   - Expand logical order explaination
   - Add dummy header
   - Only allow N BBs in execbuf IOCTL
   - Configure parallel submission per slot not per gem context

Cc: Tvrtko Ursulin 
Cc: Tony Ye 
CC: Carl Zhang 
Cc: Daniel Vetter 
Cc: Jason Ekstrand 
Signed-off-by: Matthew Brost 
---
  Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 ++
  Documentation/gpu/rfc/i915_scheduler.rst  |  53 ++-
  2 files changed, 196 insertions(+), 1 deletion(-)
  create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h

diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h 
b/Documentation/gpu/rfc/i915_parallel_execbuf.h
new file mode 100644
index ..8c64b983ccad
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
@@ -0,0 +1,144 @@
+#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see 
i915_context_engines_parallel_submit */
+
+/*
+ * i915_context_engines_parallel_submit:
+ *
+ * Setup a slot to allow multiple BBs to be submitted in a single execbuf 
IOCTL.
+ * Those BBs will then be scheduled to run on the GPU in parallel. Multiple
+ * hardware contexts are created internally in the i915 run these BBs. Once a
+ * slot is configured for N BBs only N BBs can be submitted in each execbuf
+ * IOCTL and this is implict behavior (e.g. the user doesn't tell the execbuf
+ * IOCTL there are N BBs, the execbuf IOCTL know how many BBs there are based 
on
+ * the slots configuration).
+ *
+ * Their are two currently defined ways to control the placement of the
+ * hardware contexts on physical engines: default behavior (no flags) and
+ * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the in the
+ * future as new hardware / use cases arise. Details of how to use this
+ * interface below above the flags.
+ *
+ * Returns -EINVAL if hardware context placement configuration invalid or if 
the
+ * placement configuration isn't supported on the platform / submission
+ * interface.
+ * Returns -ENODEV if extension isn't supported on the platform / submission
+ * inteface.
+ */
+struct i915_context_engines_parallel_submit {
+   struct i915_user_extension base;
+
+   __u16 engine_index; /* slot for parallel engine */
+   __u16 width;/* number of contexts per parallel engine */
+   __u16 num_siblings; /* number of siblings per context */
+   __u16 mbz16;


Ok the big picture looks reasonable now, the flags still confuse me.



Yea, it is a bit confusing.


+/*
+ * Default placement behvavior (currently unsupported):
+ *
+ * Rather than restricting parallel submission to a single class with a
+ * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS), add a mode 
that
+ * enables parallel submission across multiple engine classes. In this case 
each
+ * context's logical engine mask indicates where that context can placed. It is
+ * implied in this mode that all contexts have mutual exclusive placement (e.g.
+ * if one context is running CS0 no other contexts can run on CS0).
+ *
+ * Example 1 pseudo code:
+ * CSX[Y] = engine class X, logical instance Y
+ * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
+ * set_engines(INVALID)
+ * set_parallel(engine_index=0, width=2, num_siblings=2,
+ * engines=CS0[0],CS0[1],CS1[0],CS1[1])
+ *
+ * Results in the following valid placements:
+ * CS0[0], CS1[0]
+ * CS0[0], CS1[1]
+ * CS0[1], CS1[0]
+ * CS0[1], CS1[1]
+ *
+ * This can also be though of as 2 virtual engines:
+ * VE[0] = CS0[0], CS0[1]
+ * VE[1] = CS1[0], CS1[1]
+ *
+ * Example 2 pseudo code:
+ * CS[X] = generic engine of same class, logical instance X
+ * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
+ * set_engines(INVALID)
+ * set_parallel(engine_index=0, width=2, num_siblings=3,
+ * engines=CS[0],CS[1],CS[2],CS[0],CS[1],CS[2])
+ *
+ * Results in the following valid placements:
+ * CS[0], CS[1]
+ * CS[0], CS[2]
+ * CS[1], CS[0]
+ * CS[1], CS[2]
+ * CS[2], CS[0]
+ * CS[2], CS[1]
+ *
+ *
+ * This can also be though of as 2 virtual engines:
+ * VE[0] = CS[0], CS[1], CS[2]
+ * VE[1] = CS[0], CS[1], CS[2]
+
+ * This enables a use case where all engines are created equally, we don't care
+ * where they are scheduled, we just want a certain number of resources, for
+ * those resources to be scheduled in parallel, and possibly across multiple
+ * engine classes.
+ */


So I don't really get what this does compared to setting the flag below.
Is this just about running the batchbuffers the wrong way round, i.e. if
you have (simplest case)

width=2, num_sibglings=1, engines=CS[0], CS[1]

Then both
CS[0], CS[1]
and
CS[1], CS[0]
are possible options for running 2 batches? Iow, the backend is 

[Intel-gfx] ✗ Fi.CI.BUILD: failure for ADL-P: more reviewed patches (rev2)

[Patchwork]

== Series Details ==

Series: ADL-P: more reviewed patches (rev2)
URL   : https://patchwork.freedesktop.org/series/90305/
State : failure

== Summary ==

Applying: drm/i915/xelpd: Calculate VDSC RC parameters
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/display/intel_vdsc.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/display/intel_vdsc.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/display/intel_vdsc.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/i915/xelpd: Calculate VDSC RC parameters
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] XDC 2021: Registration & Call for Proposals now open!

[Szwichtenberg, Radoslaw]

Hello!

Registration & Call for Proposals are now open for XDC 2021, which will
take place on September 15-17, 2021. This year we will repeat as
virtual event.

https://indico.freedesktop.org/event/1/

As usual, the conference is free of charge and open to the general
public. If you plan on attending, please make sure to register as early
as possible!

In order to register as attendee, you will therefore need to register
via the XDC website. As XDC moved to a new Indico infrastructure, if
you previously registered on the XDC website, you need to create a new
account again.

https://indico.freedesktop.org/event/1/registrations/1/

In addition to registration, the CfP is now open for talks, workshops
and demos at XDC 2021. While any serious proposal will be gratefully
considered, topics of interest to X.Org and freedesktop.org developers
are encouraged. The program focus is on new development, ongoing
challenges and anything else that will spark discussions among
attendees in the hallway track.

We are open to talks across all layers of the graphics stack, from the
kernel to desktop environments / graphical applications and about how
to make things better for the developers who build them. Head to the
CfP page to learn more:

https://indico.freedesktop.org/event/1/abstracts/

The deadline for submissions is Sunday, 4 July 2021.

Last year we modified our Reimbursement Policy to accept speaker
expenses for X.Org virtual events like XDC 2021. Check it out here:

https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/

If you have any questions, please send me an email to
radoslaw.szwichtenb...@intel.com,  
adding on CC the X.org board (board
at foundation.x.org).

And don't forget, you can follow us on Twitter for all the latest
updates and to stay connected:


https://twitter.com/XOrgDevConf

Best,

Radek

P.S: a DNS redirection (xdc2021.x.org) is work in progress. Please use
the mentioned links for the moment.


Radosław Szwichtenberg
-
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173, 80-298 Gdansk
KRS 101882 - NIP 957-07-52-316

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan

[Daniel Vetter]

On Wed, May 19, 2021 at 7:19 PM Matthew Brost  wrote:
>
> On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wrote:
> > On Tue, May 18, 2021 at 04:58:30PM -0700, Matthew Brost wrote:
> > > Add entry fpr i915 new parallel submission uAPI plan.
> > >
> > > v2:
> > >  (Daniel Vetter):
> > >   - Expand logical order explaination
> > >   - Add dummy header
> > >   - Only allow N BBs in execbuf IOCTL
> > >   - Configure parallel submission per slot not per gem context
> > >
> > > Cc: Tvrtko Ursulin 
> > > Cc: Tony Ye 
> > > CC: Carl Zhang 
> > > Cc: Daniel Vetter 
> > > Cc: Jason Ekstrand 
> > > Signed-off-by: Matthew Brost 
> > > ---
> > >  Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 ++
> > >  Documentation/gpu/rfc/i915_scheduler.rst  |  53 ++-
> > >  2 files changed, 196 insertions(+), 1 deletion(-)
> > >  create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
> > >
> > > diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h 
> > > b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > new file mode 100644
> > > index ..8c64b983ccad
> > > --- /dev/null
> > > +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > > @@ -0,0 +1,144 @@
> > > +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see 
> > > i915_context_engines_parallel_submit */
> > > +
> > > +/*
> > > + * i915_context_engines_parallel_submit:
> > > + *
> > > + * Setup a slot to allow multiple BBs to be submitted in a single 
> > > execbuf IOCTL.
> > > + * Those BBs will then be scheduled to run on the GPU in parallel. 
> > > Multiple
> > > + * hardware contexts are created internally in the i915 run these BBs. 
> > > Once a
> > > + * slot is configured for N BBs only N BBs can be submitted in each 
> > > execbuf
> > > + * IOCTL and this is implict behavior (e.g. the user doesn't tell the 
> > > execbuf
> > > + * IOCTL there are N BBs, the execbuf IOCTL know how many BBs there are 
> > > based on
> > > + * the slots configuration).
> > > + *
> > > + * Their are two currently defined ways to control the placement of the
> > > + * hardware contexts on physical engines: default behavior (no flags) and
> > > + * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the in 
> > > the
> > > + * future as new hardware / use cases arise. Details of how to use this
> > > + * interface below above the flags.
> > > + *
> > > + * Returns -EINVAL if hardware context placement configuration invalid 
> > > or if the
> > > + * placement configuration isn't supported on the platform / submission
> > > + * interface.
> > > + * Returns -ENODEV if extension isn't supported on the platform / 
> > > submission
> > > + * inteface.
> > > + */
> > > +struct i915_context_engines_parallel_submit {
> > > +   struct i915_user_extension base;
> > > +
> > > +   __u16 engine_index; /* slot for parallel engine */
> > > +   __u16 width;/* number of contexts per parallel engine */
> > > +   __u16 num_siblings; /* number of siblings per context */
> > > +   __u16 mbz16;
> >
> > Ok the big picture looks reasonable now, the flags still confuse me.
> >
>
> Yea, it is a bit confusing.
>
> > > +/*
> > > + * Default placement behvavior (currently unsupported):
> > > + *
> > > + * Rather than restricting parallel submission to a single class with a
> > > + * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS), add a 
> > > mode that
> > > + * enables parallel submission across multiple engine classes. In this 
> > > case each
> > > + * context's logical engine mask indicates where that context can 
> > > placed. It is
> > > + * implied in this mode that all contexts have mutual exclusive 
> > > placement (e.g.
> > > + * if one context is running CS0 no other contexts can run on CS0).
> > > + *
> > > + * Example 1 pseudo code:
> > > + * CSX[Y] = engine class X, logical instance Y
> > > + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
> > > + * set_engines(INVALID)
> > > + * set_parallel(engine_index=0, width=2, num_siblings=2,
> > > + * engines=CS0[0],CS0[1],CS1[0],CS1[1])
> > > + *
> > > + * Results in the following valid placements:
> > > + * CS0[0], CS1[0]
> > > + * CS0[0], CS1[1]
> > > + * CS0[1], CS1[0]
> > > + * CS0[1], CS1[1]
> > > + *
> > > + * This can also be though of as 2 virtual engines:
> > > + * VE[0] = CS0[0], CS0[1]
> > > + * VE[1] = CS1[0], CS1[1]
> > > + *
> > > + * Example 2 pseudo code:
> > > + * CS[X] = generic engine of same class, logical instance X
> > > + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
> > > + * set_engines(INVALID)
> > > + * set_parallel(engine_index=0, width=2, num_siblings=3,
> > > + * engines=CS[0],CS[1],CS[2],CS[0],CS[1],CS[2])
> > > + *
> > > + * Results in the following valid placements:
> > > + * CS[0], CS[1]
> > > + * CS[0], CS[2]
> > > + * CS[1], CS[0]
> > > + * CS[1], CS[2]
> > > + * CS[2], CS[0]
> > > + * CS[2], CS[1]
> > > + *
> > > + *
> > > + * This can also be though of as 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use DRIVER_NAME for tracing unattached requests

[Patchwork]

== Series Details ==

Series: drm/i915: Use DRIVER_NAME for tracing unattached requests
URL   : https://patchwork.freedesktop.org/series/90351/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10110 -> Patchwork_20157


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][2] ([i915#2782]) -> [PASS][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10110/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  [FAIL][4] ([i915#49]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10110/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  
 Warnings 

  * igt@runner@aborted:
- fi-cml-u2:  [FAIL][6] ([i915#2082] / [i915#2426] / [i915#3363]) 
-> [FAIL][7] ([i915#3363])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10110/fi-cml-u2/igt@run...@aborted.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/fi-cml-u2/igt@run...@aborted.html
- fi-cfl-guc: [FAIL][8] ([i915#2426] / [i915#3363]) -> [FAIL][9] 
([i915#3363])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10110/fi-cfl-guc/igt@run...@aborted.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/fi-cfl-guc/igt@run...@aborted.html
- fi-skl-6700k2:  [FAIL][10] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][11] ([i915#1436] / [i915#3363])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10110/fi-skl-6700k2/igt@run...@aborted.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/fi-skl-6700k2/igt@run...@aborted.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1222]: https://gitlab.freedesktop.org/drm/intel/issues/1222
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#2082]: https://gitlab.freedesktop.org/drm/intel/issues/2082
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49


Participating hosts (42 -> 38)
--

  Missing(4): fi-kbl-soraka fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_10110 -> Patchwork_20157

  CI-20190529: 20190529
  CI_DRM_10110: 9a93475b2ef77cbd4ea83aebf145fbe89dd01ced @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6089: 698613116728db5000759e69c074ce6ab2131765 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_20157: 212f1a752c55f2a2cdb441f1e36e000448f57245 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

212f1a752c55 drm/i915: Use DRIVER_NAME for tracing unattached requests

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness

[Tvrtko Ursulin]

On 19/05/2021 19:23, Daniel Vetter wrote:

On Wed, May 19, 2021 at 6:16 PM Tvrtko Ursulin
 wrote:



On 18/05/2021 10:40, Tvrtko Ursulin wrote:


On 18/05/2021 10:16, Daniel Stone wrote:

Hi,

On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin
 wrote:

I was just wondering if stat(2) and a chrdev major check would be a
solid criteria to more efficiently (compared to parsing the text
content) detect drm files while walking procfs.


Maybe I'm missing something, but is the per-PID walk actually a
measurable performance issue rather than just a bit unpleasant?


Per pid and per each open fd.

As said in the other thread what bothers me a bit in this scheme is that
the cost of obtaining GPU usage scales based on non-GPU criteria.

For use case of a top-like tool which shows all processes this is a
smaller additional cost, but then for a gpu-top like tool it is somewhat
higher.


To further expand, not only cost would scale per pid multiplies per open
fd, but to detect which of the fds are DRM I see these three options:

1) Open and parse fdinfo.
2) Name based matching ie /dev/dri/.. something.
3) Stat the symlink target and check for DRM major.


stat with symlink following should be plenty fast.


Maybe. I don't think my point about keeping the dentry cache needlessly 
hot is getting through at all. On my lightly loaded desktop:


 $ sudo lsof | wc -l
 599551

 $ sudo lsof | grep "/dev/dri/" | wc -l
 1965

It's going to look up ~600k pointless dentries in every iteration. Just 
to find a handful of DRM ones. Hard to say if that is better or worse 
than just parsing fdinfo text for all files. Will see.



All sound quite sub-optimal to me.

Name based matching is probably the least evil on system resource usage
(Keeping the dentry cache too hot? Too many syscalls?), even though
fundamentally I don't it is the right approach.

What happens with dup(2) is another question.


We need benchmark numbers showing that on anything remotely realistic
it's an actual problem. Until we've demonstrated it's a real problem
we don't need to solve it.


Point about dup(2) is whether it is possible to distinguish the 
duplicated fds in fdinfo. If a DRM client dupes, and we found two 
fdinfos each saying client is using 20% GPU, we don't want to add it up 
to 40%.



E.g. top with any sorting enabled also parses way more than it
displays on every update. It seems to be doing Just Fine (tm).


Ha, perceptions differ. I see it using 4-5% while building the kernel on 
a Xeon server which I find quite a lot. :)



Does anyone have any feedback on the /proc//gpu idea at all?


When we know we have a problem to solve we can take a look at solutions.


Yes I don't think the problem would be to add a better solution later, 
so happy to try the fdinfo first. I am simply pointing out a fundamental 
design inefficiency. Even if machines are getting faster and faster I 
don't think that should be an excuse to waste more and more under the 
hood, when a more efficient solution can be designed from the start.


Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] New uAPI for color management proposal and feedback request

[Pekka Paalanen]

On Wed, 19 May 2021 16:49:35 +0300
Ville Syrjälä  wrote:

> On Wed, May 19, 2021 at 12:34:05PM +0300, Pekka Paalanen wrote:
> > On Wed, 12 May 2021 16:04:16 +0300
> > Ville Syrjälä  wrote:
> >   
> > > On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote:  
> > > > Hello,
> > > > 
> > > > In addition to the existing "max bpc", and "Broadcast RGB/output_csc" 
> > > > drm properties I propose 4 new properties:
> > > > "preferred pixel encoding", "active color depth", "active color range", 
> > > > and "active pixel encoding"
> > > > 
> > > > 
> > > > Motivation:
> > > > 
> > > > Current monitors have a variety pixel encodings available: RGB, YCbCr 
> > > > 4:4:4, YCbCr 4:2:2, YCbCr 4:2:0.
> > > > 
> > > > In addition they might be full or limited RGB range and the monitors 
> > > > accept different bit depths.
> > > > 
> > > > Currently the kernel driver for AMD and Intel GPUs automatically 
> > > > configure the color settings automatically with little
> > > > to no influence of the user. However there are several real world 
> > > > scenarios where the user might disagree with the
> > > > default chosen by the drivers and wants to set his or her own 
> > > > preference.
> > > > 
> > > > Some examples:
> > > > 
> > > > 1. While RGB and YCbCr 4:4:4 in theory carry the same amount of color 
> > > > information, some screens might look better on one
> > > > than the other because of bad internal conversion. The driver currently 
> > > > however has a fixed default that is chosen if
> > > > available (RGB for Intel and YCbCr 4:4:4 for AMD). The only way to 
> > > > change this currently is by editing and overloading
> > > > the edid reported by the monitor to the kernel.
> > > > 
> > > > 2. RGB and YCbCr 4:4:4 need a higher port clock then YCbCr 4:2:0. Some 
> > > > hardware might report that it supports the higher
> > > > port clock, but because of bad shielding on the PC, the cable, or the 
> > > > monitor the screen cuts out every few seconds when
> > > > RGB or YCbCr 4:4:4 encoding is used, while YCbCr 4:2:0 might just work 
> > > > fine without changing hardware. The drivers
> > > > currently however always default to the "best available" option even if 
> > > > it might be broken.
> > > > 
> > > > 3. Some screens natively only supporting 8-bit color, simulate 10-Bit 
> > > > color by rapidly switching between 2 adjacent
> > > > colors. They advertise themselves to the kernel as 10-bit monitors but 
> > > > the user might not like the "fake" 10-bit effect
> > > > and prefer running at the native 8-bit per color.
> > > > 
> > > > 4. Some screens are falsely classified as full RGB range wile they 
> > > > actually use limited RGB range. This results in
> > > > washed out colors in dark and bright scenes. A user override can be 
> > > > helpful to manually fix this issue when it occurs.
> > > > 
> > > > There already exist several requests, discussion, and patches regarding 
> > > > the thematic:
> > > > 
> > > > - https://gitlab.freedesktop.org/drm/amd/-/issues/476
> > > > 
> > > > - https://gitlab.freedesktop.org/drm/amd/-/issues/1548
> > > > 
> > > > - https://lkml.org/lkml/2021/5/7/695
> > > > 
> > > > - https://lkml.org/lkml/2021/5/11/416
> > > >   
> > 
> > ...
> >   
> > > > Adoption:
> > > > 
> > > > A KDE dev wants to implement the settings in the KDE settings GUI:
> > > > https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_912370
> > > > 
> > > > Tuxedo Computers (my employer) wants to implement the settings desktop 
> > > > environment agnostic in Tuxedo Control Center. I
> > > > will start work on this in parallel to implementing the new kernel 
> > > > code.
> > > 
> > > I suspect everyone would be happier to accept new uapi if we had
> > > multiple compositors signed up to implement it.  
> > 
> > I think having Weston support for these would be good, but for now it
> > won't be much of an UI: just weston.ini to set, and the log to see what
> > happened.
> > 
> > However, knowing what happened is going to be important for color
> > calibration auditing:
> > https://gitlab.freedesktop.org/wayland/weston/-/issues/467
> > 
> > Yes, please, very much for read-only properties for the feedback part.
> > Properties that both userspace and kernel will write are hard to deal
> > with in general.
> > 
> > Btw. "max bpc" I can kind of guess that conversion from framebuffer
> > format to the wire bpc happens automatically and only as the final
> > step,  
> 
> Well, there could be dithering and whatnot also involved. So it's
> not super well specified atm either.

I tend to forget that dithering is a thing. I guess it could be
temporal and/or spatial depending on hardware?

> > but "Broadcast RGB" is more complicated: is the output from the
> > abstract pixel pipeline sent as-is and "Broadcast RGB" is just another
> > inforframe bit to the monitor, or does "Broadcast RGB" setting actually
> > change what happens in the pixel pipeline *and* set infoframe bits?  
> 
> It does indeed 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops 
(rev2)
URL   : https://patchwork.freedesktop.org/series/89503/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10109 -> Patchwork_20156


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u:   NOTRUN -> [WARN][2] ([i915#2283])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6700k2:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/fi-skl-6700k2/igt@gem_huc_c...@huc-copy.html

  * igt@i915_selftest@live@execlists:
- fi-skl-6700k2:  NOTRUN -> [DMESG-FAIL][4] ([i915#3462])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/fi-skl-6700k2/igt@i915_selftest@l...@execlists.html
- fi-bdw-5557u:   NOTRUN -> [DMESG-FAIL][5] ([i915#3462])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u:   NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_chamelium@dp-hpd-fast:
- fi-skl-6700k2:  NOTRUN -> [SKIP][7] ([fdo#109271]) +11 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/fi-skl-6700k2/igt@kms_chamel...@dp-hpd-fast.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6700k2:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#533])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/fi-skl-6700k2/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u:   NOTRUN -> [SKIP][9] ([fdo#109271]) +9 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html

  * igt@runner@aborted:
- fi-skl-6700k2:  NOTRUN -> [FAIL][10] ([i915#1436] / [i915#3363])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/fi-skl-6700k2/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-skl-6700k2:  [INCOMPLETE][11] ([i915#198]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/fi-skl-6700k2/igt@gem_exec_susp...@basic-s3.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/fi-skl-6700k2/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][13] ([i915#2782]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  
 Warnings 

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[DMESG-FAIL][15] ([i915#3462]) -> [INCOMPLETE][16] 
([i915#2782] / [i915#2940] / [i915#3462])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
- fi-bsw-kefka:   [INCOMPLETE][17] ([i915#2782] / [i915#2940]) -> 
[INCOMPLETE][18] ([i915#2782] / [i915#2940] / [i915#3462])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html

  * igt@runner@aborted:
- fi-cfl-8700k:   [FAIL][19] ([i915#3363]) -> [FAIL][20] ([i915#2426] / 
[i915#3363])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/fi-cfl-8700k/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/fi-cfl-8700k/igt@run...@aborted.html
- fi-glk-dsi: [FAIL][21] ([i915#3363] / [k.org#202321]) -> 
[FAIL][22] ([i915#2426] / [i915#3363] / [k.org#202321])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/fi-glk-dsi/igt@run...@aborted.html
   [22]: 

[Intel-gfx] [PATCH] drm/i915: Use DRIVER_NAME for tracing unattached requests

[Matthew Auld]

From: Chris Wilson 

The first tracepoint for a request is trace_dma_fence_init called before
we have associated the request with a device. The tracepoint uses
fence->ops->get_driver_name() as a pretty name, and as we try to report
the device name this oopses as it is then NULL. Support the early
tracepoint by reporting the DRIVER_NAME instead of the actual device
name.

Note that rq->engine remains during the course of request recycling
(SLAB_TYPESAFE_BY_RCU). For the physical engines, the pointer remains
valid, however a virtual engine may be destroyed after the request is
retired. If we process a preempt-to-busy completed request along the
virtual engine, we should make sure we mark the request as no longer
belonging to the virtual engine to remove the dangling pointers from the
tracepoint.

Fixes: 855e39e65cfc ("drm/i915: Initialise basic fence before acquiring seqno")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Chintan M Patel 
Cc: Andi Shyti 
Cc:  # v5.7+
Signed-off-by: Matthew Auld 
---
 .../drm/i915/gt/intel_execlists_submission.c  | 20 ++-
 drivers/gpu/drm/i915/i915_request.c   |  7 ++-
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index de124870af44..75604e927d34 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3249,6 +3249,18 @@ static struct list_head *virtual_queue(struct 
virtual_engine *ve)
return >base.execlists.default_priolist.requests;
 }
 
+static void
+virtual_submit_completed(struct virtual_engine *ve, struct i915_request *rq)
+{
+   GEM_BUG_ON(!__i915_request_is_complete(rq));
+   GEM_BUG_ON(rq->engine != >base);
+
+   __i915_request_submit(rq);
+
+   /* Remove the dangling pointer to the stale virtual engine */
+   WRITE_ONCE(rq->engine, ve->siblings[0]);
+}
+
 static void rcu_virtual_context_destroy(struct work_struct *wrk)
 {
struct virtual_engine *ve =
@@ -3265,8 +3277,7 @@ static void rcu_virtual_context_destroy(struct 
work_struct *wrk)
 
old = fetch_and_zero(>request);
if (old) {
-   GEM_BUG_ON(!__i915_request_is_complete(old));
-   __i915_request_submit(old);
+   virtual_submit_completed(ve, old);
i915_request_put(old);
}
 
@@ -3538,13 +3549,12 @@ static void virtual_submit_request(struct i915_request 
*rq)
 
/* By the time we resubmit a request, it may be completed */
if (__i915_request_is_complete(rq)) {
-   __i915_request_submit(rq);
+   virtual_submit_completed(ve, rq);
goto unlock;
}
 
if (ve->request) { /* background completion from preempt-to-busy */
-   GEM_BUG_ON(!__i915_request_is_complete(ve->request));
-   __i915_request_submit(ve->request);
+   virtual_submit_completed(ve, ve->request);
i915_request_put(ve->request);
}
 
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 970d8f4986bb..aa124adb1051 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -61,7 +61,12 @@ static struct i915_global_request {
 
 static const char *i915_fence_get_driver_name(struct dma_fence *fence)
 {
-   return dev_name(to_request(fence)->engine->i915->drm.dev);
+   struct i915_request *rq = to_request(fence);
+
+   if (unlikely(!rq->engine)) /* not yet attached to any device */
+   return DRIVER_NAME;
+
+   return dev_name(rq->engine->i915->drm.dev);
 }
 
 static const char *i915_fence_get_timeline_name(struct dma_fence *fence)
-- 
2.26.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops 
(rev2)
URL   : https://patchwork.freedesktop.org/series/89503/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
dcae1309b1dc drm/i915: Invoke another _DSM to enable MUX on HP Workstation 
laptops
-:35: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#35: 
References: 
https://lore.kernel.org/intel-gfx/1460040732-31417-4-git-send-email-animesh.ma...@intel.com/

total: 0 errors, 1 warnings, 0 checks, 54 lines checked


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4] drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops

[Kai-Heng Feng]

On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
to discrete GFX after S3. This is not desirable, because userspace will
treat connected display as a new one, losing display settings.

The expected behavior is to let discrete GFX drives all external
displays.

The platform in question uses ACPI method \_SB.PCI0.HGME to enable MUX.
The method is inside the another _DSM, so add the _DSM and call it
accordingly.

I also tested some MUX-less and iGPU only laptops with that _DSM, no
regression was found.

v4:
 - Rebase.
 - Change the DSM name to avoid confusion.
 - Move the function call to intel_opregion.

v3:
 - Remove BXT from names.
 - Change the parameter type.
 - Fold the function into intel_modeset_init_hw().

v2:
 - Forward declare struct pci_dev.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3113
References: 
https://lore.kernel.org/intel-gfx/1460040732-31417-4-git-send-email-animesh.ma...@intel.com/
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/i915/display/intel_acpi.c | 19 +++
 drivers/gpu/drm/i915/display/intel_acpi.h |  3 +++
 drivers/gpu/drm/i915/display/intel_opregion.c |  3 +++
 3 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c 
b/drivers/gpu/drm/i915/display/intel_acpi.c
index 833d0c1be4f1..7cfe91fc05f2 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -19,6 +19,12 @@ static const guid_t intel_dsm_guid =
GUID_INIT(0x7ed873d3, 0xc2d0, 0x4e4f,
  0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
 
+#define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */
+
+static const guid_t intel_dsm_guid2 =
+   GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260,
+ 0x9d, 0x15, 0xc7, 0x1f, 0xba, 0xda, 0xe4, 0x14);
+
 static char *intel_dsm_port_name(u8 id)
 {
switch (id) {
@@ -176,6 +182,19 @@ void intel_unregister_dsm_handler(void)
 {
 }
 
+void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915)
+{
+   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
+   acpi_handle dhandle;
+
+   dhandle = ACPI_HANDLE(>dev);
+   if (!dhandle)
+   return;
+
+   acpi_evaluate_dsm(dhandle, _dsm_guid2, INTEL_DSM_REVISION_ID,
+ INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED, NULL);
+}
+
 /*
  * ACPI Specification, Revision 5.0, Appendix B.3.2 _DOD (Enumerate All Devices
  * Attached to the Display Adapter).
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.h 
b/drivers/gpu/drm/i915/display/intel_acpi.h
index e8b068661d22..9f197401c313 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.h
+++ b/drivers/gpu/drm/i915/display/intel_acpi.h
@@ -11,11 +11,14 @@ struct drm_i915_private;
 #ifdef CONFIG_ACPI
 void intel_register_dsm_handler(void);
 void intel_unregister_dsm_handler(void);
+void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915);
 void intel_acpi_device_id_update(struct drm_i915_private *i915);
 #else
 static inline void intel_register_dsm_handler(void) { return; }
 static inline void intel_unregister_dsm_handler(void) { return; }
 static inline
+void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915) { 
return; }
+static inline
 void intel_acpi_device_id_update(struct drm_i915_private *i915) { return; }
 #endif /* CONFIG_ACPI */
 
diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c 
b/drivers/gpu/drm/i915/display/intel_opregion.c
index dfd724e506b5..3855fba70980 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.c
+++ b/drivers/gpu/drm/i915/display/intel_opregion.c
@@ -1078,6 +1078,9 @@ void intel_opregion_resume(struct drm_i915_private *i915)
opregion->asle->ardy = ASLE_ARDY_READY;
}
 
+   /* Some platforms abuse the _DSM to enable MUX */
+   intel_dsm_get_bios_data_funcs_supported(i915);
+
intel_opregion_notify_adapter(i915, PCI_D0);
 }
 
-- 
2.31.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for ADL-P: more reviewed patches

[Lucas De Marchi]

On Thu, May 20, 2021 at 06:26:17AM +, Patchwork wrote:

== Series Details ==

Series: ADL-P: more reviewed patches
URL   : https://patchwork.freedesktop.org/series/90305/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10100_full -> Patchwork_20151_full


Summary
---

 **FAILURE**

 Serious unknown changes coming with Patchwork_20151_full absolutely need to be
 verified manually.

 If you think the reported changes have nothing to do with the changes
 introduced in Patchwork_20151_full, please notify your bug team to allow them
 to document this new failure mode, which will reduce false positives in CI.



Possible new issues
---

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

### IGT changes ###

 Possible regressions 

 * igt@api_intel_bb@render@render-none-1024:
   - shard-glk:  [PASS][1] -> [WARN][2]
  [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/shard-glk8/igt@api_intel_bb@ren...@render-none-1024.html
  [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-glk7/igt@api_intel_bb@ren...@render-none-1024.html


like this: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10097/shard-glk8/igt@api_intel_bb@ren...@render-none-1024.html
or this: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10096/shard-glk2/igt@api_intel_bb@ren...@render-none-1024.html



 * igt@api_intel_bb@render@render-y-reloc-1024:
   - shard-glk:  [PASS][3] -> [FAIL][4] +2 similar issues
  [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/shard-glk8/igt@api_intel_bb@ren...@render-y-reloc-1024.html
  [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-glk7/igt@api_intel_bb@ren...@render-y-reloc-1024.html



ditto, failing in recent runs too.

Lucas De Marchi


 * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd:
   - shard-snb:  NOTRUN -> [INCOMPLETE][5]
  [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-snb2/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html


 Warnings 

 * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd:
   - shard-glk:  [INCOMPLETE][6] ([i915#3468]) -> [INCOMPLETE][7] +1 
similar issue
  [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/shard-glk3/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html
  [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-glk6/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html


 Suppressed 

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

 * {igt@kms_plane@plane-position-covered@pipe-b-planes}:
   - shard-glk:  [FAIL][8] ([i915#3457]) -> [FAIL][9]
  [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/shard-glk4/igt@kms_plane@plane-position-cove...@pipe-b-planes.html
  [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-glk4/igt@kms_plane@plane-position-cove...@pipe-b-planes.html


Known issues


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

### IGT changes ###

 Issues hit 

 * igt@api_intel_allocator@execbuf-with-allocator:
   - shard-iclb: NOTRUN -> [DMESG-WARN][10] ([i915#3457]) +1 similar 
issue
  [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-iclb8/igt@api_intel_alloca...@execbuf-with-allocator.html

 * igt@api_intel_bb@blit-noreloc-purge-cache-random:
   - shard-tglb: NOTRUN -> [DMESG-WARN][11] ([i915#3457]) +1 similar 
issue
  [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-tglb3/igt@api_intel...@blit-noreloc-purge-cache-random.html

 * igt@api_intel_bb@offset-control:
   - shard-snb:  NOTRUN -> [DMESG-WARN][12] ([i915#3457]) +1 similar 
issue
  [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-snb5/igt@api_intel...@offset-control.html

 * igt@gem_create@create-massive:
   - shard-snb:  NOTRUN -> [DMESG-WARN][13] ([i915#3002])
  [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-snb5/igt@gem_cre...@create-massive.html

 * igt@gem_ctx_persistence@legacy-engines-persistence:
   - shard-snb:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#1099]) +2 
similar issues
  [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-persistence.html

 * igt@gem_ctx_persistence@many-contexts:
   - shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2410] / [i915#3457])
  [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/shard-tglb7/igt@gem_ctx_persiste...@many-contexts.html
  [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html

 * igt@gem_ctx_ringsize@idle@bcs0:
   - shard-skl:  NOTRUN -> [INCOMPLETE][17] ([i915#3316] / [i915#3457])
  [17]: 

Re: [Intel-gfx] [PATCH v7 01/15] swiotlb: Refactor swiotlb init functions

[Claire Chang]

On Thu, May 20, 2021 at 2:50 AM Florian Fainelli  wrote:
>
>
>
> On 5/17/2021 11:42 PM, Claire Chang wrote:
> > Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
> > initialization to make the code reusable.
> >
> > Note that we now also call set_memory_decrypted in swiotlb_init_with_tbl.
> >
> > Signed-off-by: Claire Chang 
> > ---
> >  kernel/dma/swiotlb.c | 51 ++--
> >  1 file changed, 25 insertions(+), 26 deletions(-)
> >
> > diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> > index 8ca7d505d61c..d3232fc19385 100644
> > --- a/kernel/dma/swiotlb.c
> > +++ b/kernel/dma/swiotlb.c
> > @@ -168,9 +168,30 @@ void __init swiotlb_update_mem_attributes(void)
> >   memset(vaddr, 0, bytes);
> >  }
> >
> > -int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int 
> > verbose)
> > +static void swiotlb_init_io_tlb_mem(struct io_tlb_mem *mem, phys_addr_t 
> > start,
> > + unsigned long nslabs, bool late_alloc)
> >  {
> > + void *vaddr = phys_to_virt(start);
> >   unsigned long bytes = nslabs << IO_TLB_SHIFT, i;
> > +
> > + mem->nslabs = nslabs;
> > + mem->start = start;
> > + mem->end = mem->start + bytes;
> > + mem->index = 0;
> > + mem->late_alloc = late_alloc;
> > + spin_lock_init(>lock);
> > + for (i = 0; i < mem->nslabs; i++) {
> > + mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
> > + mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
> > + mem->slots[i].alloc_size = 0;
> > + }
> > +
> > + set_memory_decrypted((unsigned long)vaddr, bytes >> PAGE_SHIFT);
> > + memset(vaddr, 0, bytes);
>
> You are doing an unconditional set_memory_decrypted() followed by a
> memset here, and then:
>
> > +}
> > +
> > +int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int 
> > verbose)
> > +{
> >   struct io_tlb_mem *mem;
> >   size_t alloc_size;
> >
> > @@ -186,16 +207,8 @@ int __init swiotlb_init_with_tbl(char *tlb, unsigned 
> > long nslabs, int verbose)
> >   if (!mem)
> >   panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> > __func__, alloc_size, PAGE_SIZE);
> > - mem->nslabs = nslabs;
> > - mem->start = __pa(tlb);
> > - mem->end = mem->start + bytes;
> > - mem->index = 0;
> > - spin_lock_init(>lock);
> > - for (i = 0; i < mem->nslabs; i++) {
> > - mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
> > - mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
> > - mem->slots[i].alloc_size = 0;
> > - }
> > +
> > + swiotlb_init_io_tlb_mem(mem, __pa(tlb), nslabs, false);
>
> You convert this call site with swiotlb_init_io_tlb_mem() which did not
> do the set_memory_decrypted()+memset(). Is this okay or should
> swiotlb_init_io_tlb_mem() add an additional argument to do this
> conditionally?

I'm actually not sure if this it okay. If not, will add an additional
argument for it.

> --
> Florian
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v7 04/15] swiotlb: Add restricted DMA pool initialization

[Claire Chang]

On Thu, May 20, 2021 at 2:54 AM Florian Fainelli  wrote:
>
>
>
> On 5/17/2021 11:42 PM, Claire Chang wrote:
> > Add the initialization function to create restricted DMA pools from
> > matching reserved-memory nodes.
> >
> > Signed-off-by: Claire Chang 
> > ---
> >  include/linux/device.h  |  4 +++
> >  include/linux/swiotlb.h |  3 +-
> >  kernel/dma/swiotlb.c| 76 +
> >  3 files changed, 82 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index 38a2071cf776..4987608ea4ff 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -416,6 +416,7 @@ struct dev_links_info {
> >   * @dma_pools:   Dma pools (if dma'ble device).
> >   * @dma_mem: Internal for coherent mem override.
> >   * @cma_area:Contiguous memory area for dma allocations
> > + * @dma_io_tlb_mem: Internal for swiotlb io_tlb_mem override.
> >   * @archdata:For arch-specific additions.
> >   * @of_node: Associated device tree node.
> >   * @fwnode:  Associated device node supplied by platform firmware.
> > @@ -521,6 +522,9 @@ struct device {
> >  #ifdef CONFIG_DMA_CMA
> >   struct cma *cma_area;   /* contiguous memory area for dma
> >  allocations */
> > +#endif
> > +#ifdef CONFIG_DMA_RESTRICTED_POOL
> > + struct io_tlb_mem *dma_io_tlb_mem;
> >  #endif
> >   /* arch specific additions */
> >   struct dev_archdata archdata;
> > diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
> > index 216854a5e513..03ad6e3b4056 100644
> > --- a/include/linux/swiotlb.h
> > +++ b/include/linux/swiotlb.h
> > @@ -72,7 +72,8 @@ extern enum swiotlb_force swiotlb_force;
> >   *   range check to see if the memory was in fact allocated by this
> >   *   API.
> >   * @nslabs:  The number of IO TLB blocks (in groups of 64) between @start 
> > and
> > - *   @end. This is command line adjustable via setup_io_tlb_npages.
> > + *   @end. For default swiotlb, this is command line adjustable via
> > + *   setup_io_tlb_npages.
> >   * @used:The number of used IO TLB block.
> >   * @list:The free list describing the number of free entries available
> >   *   from each index.
> > diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> > index b849b01a446f..1d8eb4de0d01 100644
> > --- a/kernel/dma/swiotlb.c
> > +++ b/kernel/dma/swiotlb.c
> > @@ -39,6 +39,13 @@
> >  #ifdef CONFIG_DEBUG_FS
> >  #include 
> >  #endif
> > +#ifdef CONFIG_DMA_RESTRICTED_POOL
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#endif
> >
> >  #include 
> >  #include 
> > @@ -690,3 +697,72 @@ static int __init swiotlb_create_default_debugfs(void)
> >  late_initcall(swiotlb_create_default_debugfs);
> >
> >  #endif
> > +
> > +#ifdef CONFIG_DMA_RESTRICTED_POOL
> > +static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
> > + struct device *dev)
> > +{
> > + struct io_tlb_mem *mem = rmem->priv;
> > + unsigned long nslabs = rmem->size >> IO_TLB_SHIFT;
> > +
> > + if (dev->dma_io_tlb_mem)
> > + return 0;
> > +
> > + /*
> > +  * Since multiple devices can share the same pool, the private data,
> > +  * io_tlb_mem struct, will be initialized by the first device attached
> > +  * to it.
> > +  */
> > + if (!mem) {
> > + mem = kzalloc(struct_size(mem, slots, nslabs), GFP_KERNEL);
> > + if (!mem)
> > + return -ENOMEM;
> > +
> > + if (PageHighMem(pfn_to_page(PHYS_PFN(rmem->base {
> > + kfree(mem);
> > + return -EINVAL;
>
> This could probably deserve a warning here to indicate that the reserved
> area must be accessible within the linear mapping as I would expect a
> lot of people to trip over that.

Ok. Will add it.

>
> Reviewed-by: Florian Fainelli 
> --
> Florian
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for ADL-P: more reviewed patches

[Patchwork]

== Series Details ==

Series: ADL-P: more reviewed patches
URL   : https://patchwork.freedesktop.org/series/90305/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10100_full -> Patchwork_20151_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@api_intel_bb@render@render-none-1024:
- shard-glk:  [PASS][1] -> [WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/shard-glk8/igt@api_intel_bb@ren...@render-none-1024.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-glk7/igt@api_intel_bb@ren...@render-none-1024.html

  * igt@api_intel_bb@render@render-y-reloc-1024:
- shard-glk:  [PASS][3] -> [FAIL][4] +2 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/shard-glk8/igt@api_intel_bb@ren...@render-y-reloc-1024.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-glk7/igt@api_intel_bb@ren...@render-y-reloc-1024.html

  * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd:
- shard-snb:  NOTRUN -> [INCOMPLETE][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-snb2/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html

  
 Warnings 

  * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd:
- shard-glk:  [INCOMPLETE][6] ([i915#3468]) -> [INCOMPLETE][7] +1 
similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/shard-glk3/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-glk6/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html

  
 Suppressed 

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

  * {igt@kms_plane@plane-position-covered@pipe-b-planes}:
- shard-glk:  [FAIL][8] ([i915#3457]) -> [FAIL][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/shard-glk4/igt@kms_plane@plane-position-cove...@pipe-b-planes.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-glk4/igt@kms_plane@plane-position-cove...@pipe-b-planes.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@api_intel_allocator@execbuf-with-allocator:
- shard-iclb: NOTRUN -> [DMESG-WARN][10] ([i915#3457]) +1 similar 
issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-iclb8/igt@api_intel_alloca...@execbuf-with-allocator.html

  * igt@api_intel_bb@blit-noreloc-purge-cache-random:
- shard-tglb: NOTRUN -> [DMESG-WARN][11] ([i915#3457]) +1 similar 
issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-tglb3/igt@api_intel...@blit-noreloc-purge-cache-random.html

  * igt@api_intel_bb@offset-control:
- shard-snb:  NOTRUN -> [DMESG-WARN][12] ([i915#3457]) +1 similar 
issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-snb5/igt@api_intel...@offset-control.html

  * igt@gem_create@create-massive:
- shard-snb:  NOTRUN -> [DMESG-WARN][13] ([i915#3002])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-snb5/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_persistence@legacy-engines-persistence:
- shard-snb:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#1099]) +2 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-persistence.html

  * igt@gem_ctx_persistence@many-contexts:
- shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2410] / [i915#3457])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/shard-tglb7/igt@gem_ctx_persiste...@many-contexts.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html

  * igt@gem_ctx_ringsize@idle@bcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][17] ([i915#3316] / [i915#3457])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-skl3/igt@gem_ctx_ringsize@i...@bcs0.html

  * igt@gem_ctx_shared@q-in-order:
- shard-snb:  NOTRUN -> [SKIP][18] ([fdo#109271]) +125 similar 
issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/shard-snb7/igt@gem_ctx_sha...@q-in-order.html

  *