Re: [Intel-gfx] [CI 1/4] drm/i915/dmc: Introduce DMC_FW_MAIN

2021-06-09 Thread Lucas De Marchi

On Fri, Jun 04, 2021 at 12:01:25PM -0700, Anusha Srivatsa wrote:

This is a prep patch for Pipe DMC plugging.

Add dmc_info struct in intel_dmc to have all common fields
shared between all DMC's in the package.
Add DMC_FW_MAIN(dmc_id 0) to refer to the blob.

v2: Remove dmc_offset and start_mmioaddr from dmc_info struct (Jose)

Cc: Souza, Jose 
Signed-off-by: Anusha Srivatsa 
---
drivers/gpu/drm/i915/display/intel_dmc.c | 44 +++-
drivers/gpu/drm/i915/display/intel_dmc.h | 18 +++---
2 files changed, 33 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 97308da28059..b78cb44731fe 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -239,7 +239,7 @@ struct stepping_info {

bool intel_dmc_has_payload(struct drm_i915_private *i915)
{
-   return i915->dmc.dmc_payload;
+   return i915->dmc.dmc_info[DMC_FW_MAIN].payload;
}

static const struct stepping_info skl_stepping_info[] = {
@@ -316,7 +316,8 @@ static void gen9_set_dc_state_debugmask(struct 
drm_i915_private *dev_priv)
 */
void intel_dmc_load_program(struct drm_i915_private *dev_priv)
{
-   u32 *payload = dev_priv->dmc.dmc_payload;
+   struct intel_dmc *dmc = _priv->dmc;
+   struct dmc_fw_info *dmc_info = >dmc_info[DMC_FW_MAIN];
u32 i, fw_size;

if (!HAS_DMC(dev_priv)) {
@@ -325,26 +326,26 @@ void intel_dmc_load_program(struct drm_i915_private 
*dev_priv)
return;
}

-   if (!intel_dmc_has_payload(dev_priv)) {
+   if (!dev_priv->dmc.dmc_info[DMC_FW_MAIN].payload) {
drm_err(_priv->drm,
"Tried to program CSR with empty payload\n");
return;
}

-   fw_size = dev_priv->dmc.dmc_fw_size;
+   fw_size = dmc_info->dmc_fw_size;
assert_rpm_wakelock_held(_priv->runtime_pm);

preempt_disable();

for (i = 0; i < fw_size; i++)
intel_uncore_write_fw(_priv->uncore, DMC_PROGRAM(i),
- payload[i]);
+ dmc_info->payload[i]);

preempt_enable();

-   for (i = 0; i < dev_priv->dmc.mmio_count; i++) {
-   intel_de_write(dev_priv, dev_priv->dmc.mmioaddr[i],
-  dev_priv->dmc.mmiodata[i]);
+   for (i = 0; i < dmc_info->mmio_count; i++) {
+   intel_de_write(dev_priv, dmc_info->mmioaddr[i],
+  dmc_info->mmiodata[i]);
}

dev_priv->dmc.dc_state = 0;
@@ -401,13 +402,14 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
   size_t rem_size)
{
struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc);
+   struct dmc_fw_info *dmc_info = >dmc_info[DMC_FW_MAIN];
unsigned int header_len_bytes, dmc_header_size, payload_size, i;
const u32 *mmioaddr, *mmiodata;
u32 mmio_count, mmio_count_max;
u8 *payload;

-   BUILD_BUG_ON(ARRAY_SIZE(dmc->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
-ARRAY_SIZE(dmc->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);
+   BUILD_BUG_ON(ARRAY_SIZE(dmc_info->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
+ARRAY_SIZE(dmc_info->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);

/*
 * Check if we can access common fields, we will checkc again below
@@ -463,16 +465,10 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
}

for (i = 0; i < mmio_count; i++) {
-   if (mmioaddr[i] < DMC_MMIO_START_RANGE ||
-   mmioaddr[i] > DMC_MMIO_END_RANGE) {
-   drm_err(>drm, "DMC firmware has wrong mmio address 
0x%x\n",
-   mmioaddr[i]);
-   return 0;
-   }


this code here should not be dropped. Yes, after the last patch the
hardcoded value may not make sense, but patches should be split
appropriately.

with this change removed,


Reviewed-by: Lucas De Marchi 

thanks
Lucas De Marchi



-   dmc->mmioaddr[i] = _MMIO(mmioaddr[i]);
-   dmc->mmiodata[i] = mmiodata[i];
+   dmc_info->mmioaddr[i] = _MMIO(mmioaddr[i]);
+   dmc_info->mmiodata[i] = mmiodata[i];
}
-   dmc->mmio_count = mmio_count;
+   dmc_info->mmio_count = mmio_count;

rem_size -= header_len_bytes;

@@ -485,14 +481,14 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
drm_err(>drm, "DMC FW too big (%u bytes)\n", 
payload_size);
return 0;
}
-   dmc->dmc_fw_size = dmc_header->fw_size;
+   dmc_info->dmc_fw_size = dmc_header->fw_size;

-   dmc->dmc_payload = kmalloc(payload_size, GFP_KERNEL);
-   if (!dmc->dmc_payload)
+   dmc_info->payload = kmalloc(payload_size, GFP_KERNEL);
+   if (!dmc_info->payload)
return 0;

payload = (u8 

[Intel-gfx] ✓ Fi.CI.BAT: success for Update firmware to v62.0.0 (rev2)

2021-06-09 Thread Patchwork
== Series Details ==

Series: Update firmware to v62.0.0 (rev2)
URL   : https://patchwork.freedesktop.org/series/91106/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10200 -> Patchwork_20325


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-a:
- {fi-rkl-11500t}:[SKIP][1] ([i915#1849]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10200/fi-rkl-11500t/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20325/fi-rkl-11500t/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html

  
 Warnings 

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

  * igt@runner@aborted:
- fi-cfl-8700k:   [FAIL][5] ([i915#3363]) -> [FAIL][6] ([i915#2426] / 
[i915#3363])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10200/fi-cfl-8700k/igt@run...@aborted.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20325/fi-cfl-8700k/igt@run...@aborted.html
- fi-icl-u2:  [FAIL][7] ([i915#2782] / [i915#3363]) -> [FAIL][8] 
([i915#2426] / [i915#2782] / [i915#3363])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10200/fi-icl-u2/igt@run...@aborted.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20325/fi-icl-u2/igt@run...@aborted.html
- fi-kbl-8809g:   [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_10200/fi-kbl-8809g/igt@run...@aborted.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20325/fi-kbl-8809g/igt@run...@aborted.html
- fi-kbl-r:   [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_10200/fi-kbl-r/igt@run...@aborted.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20325/fi-kbl-r/igt@run...@aborted.html
- fi-kbl-soraka:  [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_10200/fi-kbl-soraka/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20325/fi-kbl-soraka/igt@run...@aborted.html
- fi-bxt-dsi: [FAIL][15] ([i915#2426] / [i915#3363]) -> [FAIL][16] 
([i915#3363])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10200/fi-bxt-dsi/igt@run...@aborted.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20325/fi-bxt-dsi/igt@run...@aborted.html
- fi-cfl-guc: [FAIL][17] ([i915#3363]) -> [FAIL][18] ([i915#2426] / 
[i915#3363])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10200/fi-cfl-guc/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20325/fi-cfl-guc/igt@run...@aborted.html
- fi-kbl-7567u:   [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_10200/fi-kbl-7567u/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20325/fi-kbl-7567u/igt@run...@aborted.html
- fi-skl-guc: [FAIL][21] ([i915#1436] / [i915#3363]) -> [FAIL][22] 
([i915#1436] / [i915#2426] / [i915#3363])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10200/fi-skl-guc/igt@run...@aborted.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20325/fi-skl-guc/igt@run...@aborted.html
- fi-skl-6700k2:  [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_10200/fi-skl-6700k2/igt@run...@aborted.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20325/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).

  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#3180]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Update firmware to v62.0.0 (rev2)

2021-06-09 Thread Patchwork
== Series Details ==

Series: Update firmware to v62.0.0 (rev2)
URL   : https://patchwork.freedesktop.org/series/91106/
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:1893:21:expected struct 
i915_vma *[assigned] vma
+drivers/gpu/drm/i915/display/intel_display.c:1893:21:got void [noderef] 
__iomem *[assigned] iomem
+drivers/gpu/drm/i915/display/intel_display.c:1893: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:1396:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207: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 Update firmware to v62.0.0 (rev2)

2021-06-09 Thread Patchwork
== Series Details ==

Series: Update firmware to v62.0.0 (rev2)
URL   : https://patchwork.freedesktop.org/series/91106/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
e0320873b5c7 drm/i915/guc: Introduce unified HXG messages
06f199146a15 drm/i915/guc: Update MMIO based communication
cd00d5e55cf0 drm/i915/guc: Update CTB response status definition
a1cd56a2cdae drm/i915/guc: Support per context scheduling policies
9f605623e111 drm/i915/guc: Add flag for mark broken CTB
de1419119eea drm/i915/guc: New definition of the CTB descriptor
663d8a99de4c drm/i915/guc: New definition of the CTB registration action
-:83: CHECK:CAMELCASE: Avoid CamelCase: 
#83: FILE: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h:60:
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR  
GUC_HXG_REQUEST_MSG_n_DATAn

total: 0 errors, 0 warnings, 1 checks, 261 lines checked
53ca4a74a19f drm/i915/guc: New CTB based communication
166540a8dca3 drm/i915/doc: Include GuC ABI documentation
2dfe2edc4785 drm/i915/guc: Kill guc_clients.ct_pool
da1704b929c9 drm/i915/guc: Kill ads.client_info
1da38370e4f7 drm/i915/guc: Unified GuC log
261607eceeef drm/i915/guc: Update firmware to v62.0.0
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one

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


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


Re: [Intel-gfx] [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action

2021-06-09 Thread Matthew Brost
On Wed, Jun 09, 2021 at 10:07:21PM +0200, Michal Wajdeczko wrote:
> 
> 
> On 09.06.2021 19:36, John Harrison wrote:
> > On 6/7/2021 18:23, Daniele Ceraolo Spurio wrote:
> >> On 6/7/2021 11:03 AM, Matthew Brost wrote:
> >>> From: Michal Wajdeczko 
> >>>
> >>> Definition of the CTB registration action has changed.
> >>> Add some ABI documentation and implement required changes.
> >>>
> >>> Signed-off-by: Michal Wajdeczko 
> >>> Signed-off-by: Matthew Brost 
> >>> Cc: Piotr Piórkowski  #4
> >>> ---
> >>>   .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  | 107 ++
> >>>   .../gt/uc/abi/guc_communication_ctb_abi.h |   4 -
> >>>   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |  76 -
> >>>   3 files changed, 152 insertions(+), 35 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> >>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> >>> index 90efef8a73e4..6426fc183692 100644
> >>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> >>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> >>> @@ -6,6 +6,113 @@
> >>>   #ifndef _ABI_GUC_ACTIONS_ABI_H
> >>>   #define _ABI_GUC_ACTIONS_ABI_H
> >>>   +/**
> >>> + * DOC: HOST2GUC_REGISTER_CTB
> >>> + *
> >>> + * This message is used as part of the `CTB based communication`_
> >>> setup.
> >>> + *
> >>> + * This message must be sent as `MMIO HXG Message`_.
> >>> + *
> >>> + *
> >>> +---+---+--+
> >>>
> >>> + *  |   | Bits  |
> >>> Description  |
> >>> + *
> >>> +===+===+==+
> >>>
> >>> + *  | 0 |    31 | ORIGIN =
> >>> GUC_HXG_ORIGIN_HOST_    |
> >>> + *  |
> >>> +---+--+
> >>> + *  |   | 30:28 | TYPE =
> >>> GUC_HXG_TYPE_REQUEST_ |
> >>> + *  |
> >>> +---+--+
> >>> + *  |   | 27:16 | DATA0 =
> >>> MBZ  |
> >>> + *  |
> >>> +---+--+
> >>> + *  |   |  15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` =
> >>> 0x5200    |
> >>
> >> Specs says 4505
> >>
> >>> + *
> >>> +---+---+--+
> >>>
> >>> + *  | 1 | 31:12 | RESERVED =
> >>> MBZ   |
> >>> + *  |
> >>> +---+--+
> >>> + *  |   |  11:8 | **TYPE** - type for the `CT
> >>> Buffer`_ |
> >>> + *  |   |
> >>> |  |
> >>> + *  |   |   |   - _`GUC_CTB_TYPE_HOST2GUC` =
> >>> 0 |
> >>> + *  |   |   |   - _`GUC_CTB_TYPE_GUC2HOST` =
> >>> 1 |
> >>> + *  |
> >>> +---+--+
> >>> + *  |   |   7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units
> >>> minus 1  |
> >>> + *
> >>> +---+---+--+
> >>>
> >>> + *  | 2 |  31:0 | **DESC_ADDR** - GGTT address of the `CTB
> >>> Descriptor`_    |
> >>> + *
> >>> +---+---+--+
> >>>
> >>> + *  | 3 |  31:0 | **BUFF_ADDF** - GGTT address of the `CT
> >>> Buffer`_ |
> >>> + *
> >>> +---+---+--+
> >>>
> >>> +*
> >>> + *
> >>> +---+---+--+
> >>>
> >>> + *  |   | Bits  |
> >>> Description  |
> >>> + *
> >>> +===+===+==+
> >>>
> >>> + *  | 0 |    31 | ORIGIN =
> >>> GUC_HXG_ORIGIN_GUC_ |
> >>> + *  |
> >>> +---+--+
> >>> + *  |   | 30:28 | TYPE =
> >>> GUC_HXG_TYPE_RESPONSE_SUCCESS_    |
> >>> + *  |
> >>> +---+--+
> >>> + *  |   |  27:0 | DATA0 =
> >>> MBZ  |
> >>> + *
> >>> +---+---+--+
> >>>
> >>> + */
> >>> +#define GUC_ACTION_HOST2GUC_REGISTER_CTB    0x4505 // FIXME 0x5200
> >>
> >> Why FIXME? AFAICS the specs still says 4505, even if we plan to update
> >> at some point I don;t think this deserves a FIXME since nothing is
> >> incorrect.
> >>
> >>> +
> >>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN
> >>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
> >>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ
> >>> 

Re: [Intel-gfx] [PATCH 00/13] Update firmware to v62.0.0

2021-06-09 Thread Matthew Brost
On Wed, Jun 09, 2021 at 09:36:36PM -0700, Matthew Brost wrote:
> As part of enabling GuC submission [1] we need to update to the latest
> and greatest firmware. This series does that. This is a destructive
> change. e.g. Without all the patches in this series it will break the
> i915 driver. As such, after we review most of these patches they will
> squashed into a single patch for merging.
> 
> v2: Address comments, looking for remaning RBs so patches can be
> squashed and sent for CI
> 

Ugh, forgot to include some RBs in this rev. Just looking for RBs 1-2,
and 6-8 in this rev.

Matt

> Signed-off-by: Matthew Brost 
> 
> [1] https://patchwork.freedesktop.org/series/89844/i
> 
> John Harrison (3):
>   drm/i915/guc: Support per context scheduling policies
>   drm/i915/guc: Unified GuC log
>   drm/i915/guc: Update firmware to v62.0.0
> 
> Michal Wajdeczko (10):
>   drm/i915/guc: Introduce unified HXG messages
>   drm/i915/guc: Update MMIO based communication
>   drm/i915/guc: Update CTB response status definition
>   drm/i915/guc: Add flag for mark broken CTB
>   drm/i915/guc: New definition of the CTB descriptor
>   drm/i915/guc: New definition of the CTB registration action
>   drm/i915/guc: New CTB based communication
>   drm/i915/doc: Include GuC ABI documentation
>   drm/i915/guc: Kill guc_clients.ct_pool
>   drm/i915/guc: Kill ads.client_info
> 
>  Documentation/gpu/i915.rst|   8 +
>  .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  | 107 ++
>  .../gt/uc/abi/guc_communication_ctb_abi.h | 128 +--
>  .../gt/uc/abi/guc_communication_mmio_abi.h|  65 ++--
>  .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 +++
>  drivers/gpu/drm/i915/gt/uc/intel_guc.c| 107 --
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c|  45 +--
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 356 +-
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |   6 +-
>  drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  75 +---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_log.c|  29 +-
>  drivers/gpu/drm/i915/gt/uc/intel_guc_log.h|   6 +-
>  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |  26 +-
>  13 files changed, 750 insertions(+), 421 deletions(-)
> 
> -- 
> 2.28.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 12/13] drm/i915/guc: Unified GuC log

2021-06-09 Thread Matthew Brost
From: John Harrison 

GuC v57 unified the 'DPC' and 'ISR' buffers into a single buffer with
the option for it to be larger.

Signed-off-by: Matthew Brost 
Signed-off-by: John Harrison 
Cc: Alan Previn 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc.c  | 15 ---
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h |  9 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.c  | 29 +++--
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.h  |  6 ++---
 4 files changed, 20 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index b773567cb080..6661dcb02239 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -219,24 +219,19 @@ static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
 
BUILD_BUG_ON(!CRASH_BUFFER_SIZE);
BUILD_BUG_ON(!IS_ALIGNED(CRASH_BUFFER_SIZE, UNIT));
-   BUILD_BUG_ON(!DPC_BUFFER_SIZE);
-   BUILD_BUG_ON(!IS_ALIGNED(DPC_BUFFER_SIZE, UNIT));
-   BUILD_BUG_ON(!ISR_BUFFER_SIZE);
-   BUILD_BUG_ON(!IS_ALIGNED(ISR_BUFFER_SIZE, UNIT));
+   BUILD_BUG_ON(!DEBUG_BUFFER_SIZE);
+   BUILD_BUG_ON(!IS_ALIGNED(DEBUG_BUFFER_SIZE, UNIT));
 
BUILD_BUG_ON((CRASH_BUFFER_SIZE / UNIT - 1) >
(GUC_LOG_CRASH_MASK >> GUC_LOG_CRASH_SHIFT));
-   BUILD_BUG_ON((DPC_BUFFER_SIZE / UNIT - 1) >
-   (GUC_LOG_DPC_MASK >> GUC_LOG_DPC_SHIFT));
-   BUILD_BUG_ON((ISR_BUFFER_SIZE / UNIT - 1) >
-   (GUC_LOG_ISR_MASK >> GUC_LOG_ISR_SHIFT));
+   BUILD_BUG_ON((DEBUG_BUFFER_SIZE / UNIT - 1) >
+   (GUC_LOG_DEBUG_MASK >> GUC_LOG_DEBUG_SHIFT));
 
flags = GUC_LOG_VALID |
GUC_LOG_NOTIFY_ON_HALF_FULL |
FLAG |
((CRASH_BUFFER_SIZE / UNIT - 1) << GUC_LOG_CRASH_SHIFT) |
-   ((DPC_BUFFER_SIZE / UNIT - 1) << GUC_LOG_DPC_SHIFT) |
-   ((ISR_BUFFER_SIZE / UNIT - 1) << GUC_LOG_ISR_SHIFT) |
+   ((DEBUG_BUFFER_SIZE / UNIT - 1) << GUC_LOG_DEBUG_SHIFT) |
(offset << GUC_LOG_BUF_ADDR_SHIFT);
 
#undef UNIT
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index f2df5c11c11d..617ec601648d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -81,10 +81,8 @@
 #define   GUC_LOG_ALLOC_IN_MEGABYTE(1 << 3)
 #define   GUC_LOG_CRASH_SHIFT  4
 #define   GUC_LOG_CRASH_MASK   (0x3 << GUC_LOG_CRASH_SHIFT)
-#define   GUC_LOG_DPC_SHIFT6
-#define   GUC_LOG_DPC_MASK (0x7 << GUC_LOG_DPC_SHIFT)
-#define   GUC_LOG_ISR_SHIFT9
-#define   GUC_LOG_ISR_MASK (0x7 << GUC_LOG_ISR_SHIFT)
+#define   GUC_LOG_DEBUG_SHIFT  6
+#define   GUC_LOG_DEBUG_MASK   (0xF << GUC_LOG_DEBUG_SHIFT)
 #define   GUC_LOG_BUF_ADDR_SHIFT   12
 
 #define GUC_CTL_WA 1
@@ -311,8 +309,7 @@ struct guc_ads {
 /* GuC logging structures */
 
 enum guc_log_buffer_type {
-   GUC_ISR_LOG_BUFFER,
-   GUC_DPC_LOG_BUFFER,
+   GUC_DEBUG_LOG_BUFFER,
GUC_CRASH_DUMP_LOG_BUFFER,
GUC_MAX_LOG_BUFFER
 };
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index c36d5eb5bbb9..ac0931f0374b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -197,10 +197,8 @@ static bool guc_check_log_buf_overflow(struct 
intel_guc_log *log,
 static unsigned int guc_get_log_buffer_size(enum guc_log_buffer_type type)
 {
switch (type) {
-   case GUC_ISR_LOG_BUFFER:
-   return ISR_BUFFER_SIZE;
-   case GUC_DPC_LOG_BUFFER:
-   return DPC_BUFFER_SIZE;
+   case GUC_DEBUG_LOG_BUFFER:
+   return DEBUG_BUFFER_SIZE;
case GUC_CRASH_DUMP_LOG_BUFFER:
return CRASH_BUFFER_SIZE;
default:
@@ -245,7 +243,7 @@ static void guc_read_update_log_buffer(struct intel_guc_log 
*log)
src_data += PAGE_SIZE;
dst_data += PAGE_SIZE;
 
-   for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
+   for (type = GUC_DEBUG_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
/*
 * Make a copy of the state structure, inside GuC log buffer
 * (which is uncached mapped), on the stack to avoid reading
@@ -463,21 +461,16 @@ int intel_guc_log_create(struct intel_guc_log *log)
 *  +===+ 00B
 *  |Crash dump state header|
 *  +---+ 32B
-*  |   DPC state header|
+*  |  Debug state header   |
 *  +---+ 64B
-*  |   ISR state header|
-*  +---+ 96B
 *  |   |
 

[Intel-gfx] [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action

2021-06-09 Thread Matthew Brost
From: Michal Wajdeczko 

Definition of the CTB registration action has changed.
Add some ABI documentation and implement required changes.

v2:
 (Checkpoint)
  - Fix warnings
 (Daniele)
  - Drop FIXME
 (John H)
  - Drop value in kernel doc, just use define

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Cc: Piotr Piórkowski  #4
---
 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  | 107 ++
 .../gt/uc/abi/guc_communication_ctb_abi.h |   4 -
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |  76 -
 3 files changed, 152 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 90efef8a73e4..dfaea0b54370 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -6,6 +6,113 @@
 #ifndef _ABI_GUC_ACTIONS_ABI_H
 #define _ABI_GUC_ACTIONS_ABI_H
 
+/**
+ * DOC: HOST2GUC_REGISTER_CTB
+ *
+ * This message is used as part of the `CTB based communication`_ setup.
+ *
+ * This message must be sent as `MMIO HXG Message`_.
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 |31 | ORIGIN = GUC_HXG_ORIGIN_HOST_
|
+ *  |   
+---+--+
+ *  |   | 30:28 | TYPE = GUC_HXG_TYPE_REQUEST_ 
|
+ *  |   
+---+--+
+ *  |   | 27:16 | DATA0 = MBZ  
|
+ *  |   
+---+--+
+ *  |   |  15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` 
|
+ *  
+---+---+--+
+ *  | 1 | 31:12 | RESERVED = MBZ   
|
+ *  |   
+---+--+
+ *  |   |  11:8 | **TYPE** - type for the `CT Buffer`_ 
|
+ *  |   |   |  
|
+ *  |   |   |   - _`GUC_CTB_TYPE_HOST2GUC` = 0 
|
+ *  |   |   |   - _`GUC_CTB_TYPE_GUC2HOST` = 1 
|
+ *  |   
+---+--+
+ *  |   |   7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units minus 1  
|
+ *  
+---+---+--+
+ *  | 2 |  31:0 | **DESC_ADDR** - GGTT address of the `CTB Descriptor`_
|
+ *  
+---+---+--+
+ *  | 3 |  31:0 | **BUFF_ADDF** - GGTT address of the `CT Buffer`_ 
|
+ *  
+---+---+--+
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 |31 | ORIGIN = GUC_HXG_ORIGIN_GUC_ 
|
+ *  |   
+---+--+
+ *  |   | 30:28 | TYPE = GUC_HXG_TYPE_RESPONSE_SUCCESS_
|
+ *  |   
+---+--+
+ *  |   |  27:0 | DATA0 = MBZ  
|
+ *  
+---+---+--+
+ */
+#define GUC_ACTION_HOST2GUC_REGISTER_CTB   0x4505
+
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN  
(GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ
GUC_HXG_REQUEST_MSG_0_DATA0
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ(0xf << 12)
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE   (0xf << 8)
+#define   GUC_CTB_TYPE_HOST2GUC0u
+#define   GUC_CTB_TYPE_GUC2HOST1u
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE   (0xff << 0)
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR  
GUC_HXG_REQUEST_MSG_n_DATAn
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR  
GUC_HXG_REQUEST_MSG_n_DATAn
+
+#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN 
GUC_HXG_RESPONSE_MSG_MIN_LEN
+#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_0_MBZ   
GUC_HXG_RESPONSE_MSG_0_DATA0
+
+/**
+ * DOC: HOST2GUC_DEREGISTER_CTB
+ *
+ * This message is used as part of the `CTB based communication`_ teardown.
+ *
+ * This message must be sent as `MMIO HXG Message`_.
+ *
+ 

[Intel-gfx] [PATCH 11/13] drm/i915/guc: Kill ads.client_info

2021-06-09 Thread Matthew Brost
From: Michal Wajdeczko 

New GuC does not require it any more.

Reviewed-by: Matthew Brost 
Signed-off-by: Michal Wajdeczko 
Cc: Piotr Piórkowski 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c  | 7 ---
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 8 +---
 2 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 6e26fe04ce92..b82145652d57 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -24,8 +24,6 @@
  *  +---+
  *  | guc_gt_system_info|
  *  +---+
- *  | guc_clients_info  |
- *  +---+
  *  | padding   |
  *  +---+ <== 4K aligned
  *  | private data  |
@@ -37,7 +35,6 @@ struct __guc_ads_blob {
struct guc_ads ads;
struct guc_policies policies;
struct guc_gt_system_info system_info;
-   struct guc_clients_info clients_info;
 } __packed;
 
 static u32 guc_ads_private_data_size(struct intel_guc *guc)
@@ -152,13 +149,9 @@ static void __guc_ads_init(struct intel_guc *guc)
 
base = intel_guc_ggtt_offset(guc, guc->ads_vma);
 
-   /* Clients info  */
-   blob->clients_info.clients_num = 1;
-
/* ADS */
blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
blob->ads.gt_system_info = base + ptr_offset(blob, system_info);
-   blob->ads.clients_info = base + ptr_offset(blob, clients_info);
 
/* Private Data */
blob->ads.private_data = base + guc_ads_private_data_offset(guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index 2266444d074f..f2df5c11c11d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -294,19 +294,13 @@ struct guc_gt_system_info {
u32 generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_MAX];
 } __packed;
 
-/* Clients info */
-struct guc_clients_info {
-   u32 clients_num;
-   u32 reserved[19];
-} __packed;
-
 /* GuC Additional Data Struct */
 struct guc_ads {
struct guc_mmio_reg_set 
reg_state_list[GUC_MAX_ENGINE_CLASSES][GUC_MAX_INSTANCES_PER_CLASS];
u32 reserved0;
u32 scheduler_policies;
u32 gt_system_info;
-   u32 clients_info;
+   u32 reserved1;
u32 control_data;
u32 golden_context_lrca[GUC_MAX_ENGINE_CLASSES];
u32 eng_state_size[GUC_MAX_ENGINE_CLASSES];
-- 
2.28.0

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


[Intel-gfx] [PATCH 10/13] drm/i915/guc: Kill guc_clients.ct_pool

2021-06-09 Thread Matthew Brost
From: Michal Wajdeczko 

CTB pool is now maintained internally by the GuC as part of its
"private data". No need to allocate separate buffer and pass it
to GuC as yet another ADS.

Signed-off-by: Matthew Brost  #v4
Signed-off-by: Michal Wajdeczko 
Cc: Janusz Krzysztofik 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c  | 12 
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 12 +---
 2 files changed, 1 insertion(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 4fcbe4b921f9..6e26fe04ce92 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -26,8 +26,6 @@
  *  +---+
  *  | guc_clients_info  |
  *  +---+
- *  | guc_ct_pool_entry[size]   |
- *  +---+
  *  | padding   |
  *  +---+ <== 4K aligned
  *  | private data  |
@@ -40,7 +38,6 @@ struct __guc_ads_blob {
struct guc_policies policies;
struct guc_gt_system_info system_info;
struct guc_clients_info clients_info;
-   struct guc_ct_pool_entry ct_pool[GUC_CT_POOL_SIZE];
 } __packed;
 
 static u32 guc_ads_private_data_size(struct intel_guc *guc)
@@ -68,11 +65,6 @@ static void guc_policies_init(struct guc_policies *policies)
policies->is_valid = 1;
 }
 
-static void guc_ct_pool_entries_init(struct guc_ct_pool_entry *pool, u32 num)
-{
-   memset(pool, 0, num * sizeof(*pool));
-}
-
 static void guc_mapping_table_init(struct intel_gt *gt,
   struct guc_gt_system_info *system_info)
 {
@@ -161,11 +153,7 @@ static void __guc_ads_init(struct intel_guc *guc)
base = intel_guc_ggtt_offset(guc, guc->ads_vma);
 
/* Clients info  */
-   guc_ct_pool_entries_init(blob->ct_pool, ARRAY_SIZE(blob->ct_pool));
-
blob->clients_info.clients_num = 1;
-   blob->clients_info.ct_pool_addr = base + ptr_offset(blob, ct_pool);
-   blob->clients_info.ct_pool_count = ARRAY_SIZE(blob->ct_pool);
 
/* ADS */
blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index 251c3836bd2c..2266444d074f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -295,19 +295,9 @@ struct guc_gt_system_info {
 } __packed;
 
 /* Clients info */
-struct guc_ct_pool_entry {
-   struct guc_ct_buffer_desc desc;
-   u32 reserved[7];
-} __packed;
-
-#define GUC_CT_POOL_SIZE   2
-
 struct guc_clients_info {
u32 clients_num;
-   u32 reserved0[13];
-   u32 ct_pool_addr;
-   u32 ct_pool_count;
-   u32 reserved[4];
+   u32 reserved[19];
 } __packed;
 
 /* GuC Additional Data Struct */
-- 
2.28.0

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


[Intel-gfx] [PATCH 13/13] drm/i915/guc: Update firmware to v62.0.0

2021-06-09 Thread Matthew Brost
From: John Harrison 

Signed-off-by: John Harrison 
Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 26 
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index df647c9a8d56..9f23e9de3237 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -48,19 +48,19 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
  * firmware as TGL.
  */
 #define INTEL_UC_FIRMWARE_DEFS(fw_def, guc_def, huc_def) \
-   fw_def(ALDERLAKE_S, 0, guc_def(tgl, 49, 0, 1), huc_def(tgl,  7, 5, 0)) \
-   fw_def(ROCKETLAKE,  0, guc_def(tgl, 49, 0, 1), huc_def(tgl,  7, 5, 0)) \
-   fw_def(TIGERLAKE,   0, guc_def(tgl, 49, 0, 1), huc_def(tgl,  7, 5, 0)) \
-   fw_def(JASPERLAKE,  0, guc_def(ehl, 49, 0, 1), huc_def(ehl,  9, 0, 0)) \
-   fw_def(ELKHARTLAKE, 0, guc_def(ehl, 49, 0, 1), huc_def(ehl,  9, 0, 0)) \
-   fw_def(ICELAKE, 0, guc_def(icl, 49, 0, 1), huc_def(icl,  9, 0, 0)) \
-   fw_def(COMETLAKE,   5, guc_def(cml, 49, 0, 1), huc_def(cml,  4, 0, 0)) \
-   fw_def(COMETLAKE,   0, guc_def(kbl, 49, 0, 1), huc_def(kbl,  4, 0, 0)) \
-   fw_def(COFFEELAKE,  0, guc_def(kbl, 49, 0, 1), huc_def(kbl,  4, 0, 0)) \
-   fw_def(GEMINILAKE,  0, guc_def(glk, 49, 0, 1), huc_def(glk,  4, 0, 0)) \
-   fw_def(KABYLAKE,0, guc_def(kbl, 49, 0, 1), huc_def(kbl,  4, 0, 0)) \
-   fw_def(BROXTON, 0, guc_def(bxt, 49, 0, 1), huc_def(bxt,  2, 0, 0)) \
-   fw_def(SKYLAKE, 0, guc_def(skl, 49, 0, 1), huc_def(skl,  2, 0, 0))
+   fw_def(ALDERLAKE_S, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl,  7, 5, 0)) \
+   fw_def(ROCKETLAKE,  0, guc_def(tgl, 62, 0, 0), huc_def(tgl,  7, 5, 0)) \
+   fw_def(TIGERLAKE,   0, guc_def(tgl, 62, 0, 0), huc_def(tgl,  7, 5, 0)) \
+   fw_def(JASPERLAKE,  0, guc_def(ehl, 62, 0, 0), huc_def(ehl,  9, 0, 0)) \
+   fw_def(ELKHARTLAKE, 0, guc_def(ehl, 62, 0, 0), huc_def(ehl,  9, 0, 0)) \
+   fw_def(ICELAKE, 0, guc_def(icl, 62, 0, 0), huc_def(icl,  9, 0, 0)) \
+   fw_def(COMETLAKE,   5, guc_def(cml, 62, 0, 0), huc_def(cml,  4, 0, 0)) \
+   fw_def(COMETLAKE,   0, guc_def(kbl, 62, 0, 0), huc_def(kbl,  4, 0, 0)) \
+   fw_def(COFFEELAKE,  0, guc_def(kbl, 62, 0, 0), huc_def(kbl,  4, 0, 0)) \
+   fw_def(GEMINILAKE,  0, guc_def(glk, 62, 0, 0), huc_def(glk,  4, 0, 0)) \
+   fw_def(KABYLAKE,0, guc_def(kbl, 62, 0, 0), huc_def(kbl,  4, 0, 0)) \
+   fw_def(BROXTON, 0, guc_def(bxt, 62, 0, 0), huc_def(bxt,  2, 0, 0)) \
+   fw_def(SKYLAKE, 0, guc_def(skl, 62, 0, 0), huc_def(skl,  2, 0, 0))
 
 #define __MAKE_UC_FW_PATH(prefix_, name_, major_, minor_, patch_) \
"i915/" \
-- 
2.28.0

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


[Intel-gfx] [PATCH 04/13] drm/i915/guc: Support per context scheduling policies

2021-06-09 Thread Matthew Brost
From: John Harrison 

GuC firmware v53.0.0 introduced per context scheduling policies. This
includes changes to some of the ADS structures which are required to
load the firmware even if not using GuC submission.

Signed-off-by: John Harrison 
Signed-off-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c  | 26 +++--
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 31 +
 2 files changed, 11 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 9abfbc6edbd6..4fcbe4b921f9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -59,30 +59,12 @@ static u32 guc_ads_blob_size(struct intel_guc *guc)
   guc_ads_private_data_size(guc);
 }
 
-static void guc_policy_init(struct guc_policy *policy)
-{
-   policy->execution_quantum = POLICY_DEFAULT_EXECUTION_QUANTUM_US;
-   policy->preemption_time = POLICY_DEFAULT_PREEMPTION_TIME_US;
-   policy->fault_time = POLICY_DEFAULT_FAULT_TIME_US;
-   policy->policy_flags = 0;
-}
-
 static void guc_policies_init(struct guc_policies *policies)
 {
-   struct guc_policy *policy;
-   u32 p, i;
-
-   policies->dpc_promote_time = POLICY_DEFAULT_DPC_PROMOTE_TIME_US;
-   policies->max_num_work_items = POLICY_MAX_NUM_WI;
-
-   for (p = 0; p < GUC_CLIENT_PRIORITY_NUM; p++) {
-   for (i = 0; i < GUC_MAX_ENGINE_CLASSES; i++) {
-   policy = >policy[p][i];
-
-   guc_policy_init(policy);
-   }
-   }
-
+   policies->dpc_promote_time = GLOBAL_POLICY_DEFAULT_DPC_PROMOTE_TIME_US;
+   policies->max_num_work_items = GLOBAL_POLICY_MAX_NUM_WI;
+   /* Disable automatic resets as not yet supported. */
+   policies->global_flags = GLOBAL_POLICY_DISABLE_ENGINE_RESET;
policies->is_valid = 1;
 }
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index fb04e2211b79..251c3836bd2c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -247,32 +247,14 @@ struct guc_stage_desc {
 
 /* Scheduling policy settings */
 
-/* Reset engine upon preempt failure */
-#define POLICY_RESET_ENGINE(1<<0)
-/* Preempt to idle on quantum expiry */
-#define POLICY_PREEMPT_TO_IDLE (1<<1)
-
-#define POLICY_MAX_NUM_WI 15
-#define POLICY_DEFAULT_DPC_PROMOTE_TIME_US 50
-#define POLICY_DEFAULT_EXECUTION_QUANTUM_US 100
-#define POLICY_DEFAULT_PREEMPTION_TIME_US 50
-#define POLICY_DEFAULT_FAULT_TIME_US 25
-
-struct guc_policy {
-   /* Time for one workload to execute. (in micro seconds) */
-   u32 execution_quantum;
-   /* Time to wait for a preemption request to completed before issuing a
-* reset. (in micro seconds). */
-   u32 preemption_time;
-   /* How much time to allow to run after the first fault is observed.
-* Then preempt afterwards. (in micro seconds) */
-   u32 fault_time;
-   u32 policy_flags;
-   u32 reserved[8];
-} __packed;
+#define GLOBAL_POLICY_MAX_NUM_WI 15
+
+/* Don't reset an engine upon preemption failure */
+#define GLOBAL_POLICY_DISABLE_ENGINE_RESET BIT(0)
+
+#define GLOBAL_POLICY_DEFAULT_DPC_PROMOTE_TIME_US 50
 
 struct guc_policies {
-   struct guc_policy 
policy[GUC_CLIENT_PRIORITY_NUM][GUC_MAX_ENGINE_CLASSES];
u32 submission_queue_depth[GUC_MAX_ENGINE_CLASSES];
/* In micro seconds. How much time to allow before DPC processing is
 * called back via interrupt (to prevent DPC queue drain starving).
@@ -286,6 +268,7 @@ struct guc_policies {
 * idle. */
u32 max_num_work_items;
 
+   u32 global_flags;
u32 reserved[4];
 } __packed;
 
-- 
2.28.0

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


[Intel-gfx] [PATCH 09/13] drm/i915/doc: Include GuC ABI documentation

2021-06-09 Thread Matthew Brost
From: Michal Wajdeczko 

GuC ABI documentation is now ready to be included in i915.rst

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Cc: Piotr Piórkowski 
---
 Documentation/gpu/i915.rst | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 42ce0196930a..c7846b1d9293 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -518,6 +518,14 @@ GuC-based command submission
 .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
:doc: GuC-based command submission
 
+GuC ABI
+
+
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+
 HuC
 ---
 .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc.c
-- 
2.28.0

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


[Intel-gfx] [PATCH 06/13] drm/i915/guc: New definition of the CTB descriptor

2021-06-09 Thread Matthew Brost
From: Michal Wajdeczko 

Definition of the CTB descriptor has changed, leaving only
minimal shared fields like HEAD/TAIL/STATUS.

Both HEAD and TAIL are now in dwords.

Add some ABI documentation and implement required changes.

v2:
 (Daniele)
  - Drop GUC_CTB_STATUS_NO_BACKCHANNEL, GUC_CTB_STATUS_NO_BACKCHANNEL

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
---
 .../gt/uc/abi/guc_communication_ctb_abi.h | 68 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 70 +--
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  2 +-
 3 files changed, 83 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
index d38935f47ecf..88f1fc2a19e0 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
@@ -7,6 +7,56 @@
 #define _ABI_GUC_COMMUNICATION_CTB_ABI_H
 
 #include 
+#include 
+
+#include "guc_messages_abi.h"
+
+/**
+ * DOC: CT Buffer
+ *
+ * TBD
+ */
+
+/**
+ * DOC: CTB Descriptor
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 |  31:0 | **HEAD** - offset (in dwords) to the last dword that was 
|
+ *  |   |   | read from the `CT Buffer`_.  
|
+ *  |   |   | It can only be updated by the receiver.  
|
+ *  
+---+---+--+
+ *  | 1 |  31:0 | **TAIL** - offset (in dwords) to the last dword that was 
|
+ *  |   |   | written to the `CT Buffer`_. 
|
+ *  |   |   | It can only be updated by the sender.
|
+ *  
+---+---+--+
+ *  | 2 |  31:0 | **STATUS** - status of the CTB   
|
+ *  |   |   |  
|
+ *  |   |   |   - _`GUC_CTB_STATUS_NO_ERROR` = 0 (normal operation)
|
+ *  |   |   |   - _`GUC_CTB_STATUS_OVERFLOW` = 1 (head/tail too large) 
|
+ *  |   |   |   - _`GUC_CTB_STATUS_UNDERFLOW` = 2 (truncated message)  
|
+ *  |   |   |   - _`GUC_CTB_STATUS_MISMATCH` = 4 (head/tail modified)  
|
+ *  
+---+---+--+
+ *  |...|   | RESERVED = MBZ   
|
+ *  
+---+---+--+
+ *  | 15|  31:0 | RESERVED = MBZ   
|
+ *  
+---+---+--+
+ */
+
+struct guc_ct_buffer_desc {
+   u32 head;
+   u32 tail;
+   u32 status;
+#define GUC_CTB_STATUS_NO_ERROR0
+#define GUC_CTB_STATUS_OVERFLOW(1 << 0)
+#define GUC_CTB_STATUS_UNDERFLOW   (1 << 1)
+#define GUC_CTB_STATUS_MISMATCH(1 << 2)
+#define GUC_CTB_STATUS_NO_BACKCHANNEL  (1 << 3)
+#define GUC_CTB_STATUS_MALFORMED_MSG   (1 << 4)
+   u32 reserved[13];
+} __packed;
+static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
 
 /**
  * DOC: CTB based communication
@@ -60,24 +110,6 @@
  * - **flags**, holds various bits to control message handling
  */
 
-/*
- * Describes single command transport buffer.
- * Used by both guc-master and clients.
- */
-struct guc_ct_buffer_desc {
-   u32 addr;   /* gfx address */
-   u64 host_private;   /* host private data */
-   u32 size;   /* size in bytes */
-   u32 head;   /* offset updated by GuC*/
-   u32 tail;   /* offset updated by owner */
-   u32 is_in_error;/* error indicator */
-   u32 reserved1;
-   u32 reserved2;
-   u32 owner;  /* id of the channel owner */
-   u32 owner_sub_id;   /* owner-defined field for extra tracking */
-   u32 reserved[5];
-} __packed;
-
 /* Type of command transport buffer */
 #define INTEL_GUC_CT_BUFFER_TYPE_SEND  0x0u
 #define INTEL_GUC_CT_BUFFER_TYPE_RECV  0x1u
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 63056ea0631e..3241a477196f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -112,32 +112,28 @@ static inline const char *guc_ct_buffer_type_to_str(u32 
type)
}
 }
 
-static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc,
-   u32 cmds_addr, u32 size)
+static void 

[Intel-gfx] [PATCH 08/13] drm/i915/guc: New CTB based communication

2021-06-09 Thread Matthew Brost
From: Michal Wajdeczko 

Format of the CTB messages has changed:
 - support for multiple formats
 - message fence is now part of the header
 - reuse of unified HXG message formats

v2:
 (Daniele)
  - Better comment in ct_write()

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Cc: Piotr Piórkowski 
---
 .../gt/uc/abi/guc_communication_ctb_abi.h |  56 +
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 195 +++---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |   2 +-
 3 files changed, 136 insertions(+), 117 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
index 6735f1fdaa2a..d3a2e002b6c0 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
@@ -58,6 +58,62 @@ struct guc_ct_buffer_desc {
 } __packed;
 static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
 
+/**
+ * DOC: CTB Message
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 | 31:16 | **FENCE** - message identifier   
|
+ *  |   
+---+--+
+ *  |   | 15:12 | **FORMAT** - format of the CTB message   
|
+ *  |   |   |  - _`GUC_CTB_FORMAT_HXG` = 0 - see `CTB HXG Message`_
|
+ *  |   
+---+--+
+ *  |   |  11:8 | **RESERVED** 
|
+ *  |   
+---+--+
+ *  |   |   7:0 | **NUM_DWORDS** - length of the CTB message (w/o header)  
|
+ *  
+---+---+--+
+ *  | 1 |  31:0 | optional (depends on FORMAT) 
|
+ *  +---+---+  
|
+ *  |...|   |  
|
+ *  +---+---+  
|
+ *  | n |  31:0 |  
|
+ *  
+---+---+--+
+ */
+
+#define GUC_CTB_MSG_MIN_LEN1u
+#define GUC_CTB_MSG_MAX_LEN256u
+#define GUC_CTB_MSG_0_FENCE(0x << 16)
+#define GUC_CTB_MSG_0_FORMAT   (0xf << 12)
+#define   GUC_CTB_FORMAT_HXG   0u
+#define GUC_CTB_MSG_0_RESERVED (0xf << 8)
+#define GUC_CTB_MSG_0_NUM_DWORDS   (0xff << 0)
+
+/**
+ * DOC: CTB HXG Message
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 | 31:16 | FENCE
|
+ *  |   
+---+--+
+ *  |   | 15:12 | FORMAT = GUC_CTB_FORMAT_HXG_ 
|
+ *  |   
+---+--+
+ *  |   |  11:8 | RESERVED = MBZ   
|
+ *  |   
+---+--+
+ *  |   |   7:0 | NUM_DWORDS = length (in dwords) of the embedded HXG message  
|
+ *  
+---+---+--+
+ *  | 1 |  31:0 |  ++  
|
+ *  +---+---+  ||  
|
+ *  |...|   |  |  Embedded `HXG Message`_   |  
|
+ *  +---+---+  ||  
|
+ *  | n |  31:0 |  ++  
|
+ *  
+---+---+--+
+ */
+
+#define GUC_CTB_HXG_MSG_MIN_LEN(GUC_CTB_MSG_MIN_LEN + 
GUC_HXG_MSG_MIN_LEN)
+#define GUC_CTB_HXG_MSG_MAX_LENGUC_CTB_MSG_MAX_LEN
+
 /**
  * DOC: CTB based communication
  *
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 6a29be779cc9..43409044528e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -365,24 +365,6 @@ static void write_barrier(struct intel_guc_ct *ct)
}
 }
 
-/**
- * DOC: CTB Host to GuC request
- *
- * Format of the CTB Host to GuC request message is as 

[Intel-gfx] [PATCH 05/13] drm/i915/guc: Add flag for mark broken CTB

2021-06-09 Thread Matthew Brost
From: Michal Wajdeczko 

Once CTB descriptor is found in error state, either set by GuC
or us, there is no need continue checking descriptor any more,
we can rely on our internal flag.

Signed-off-by: Matthew Brost 
Signed-off-by: Michal Wajdeczko 
Cc: Piotr Piórkowski 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 13 +++--
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  2 ++
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 3f7f48611487..63056ea0631e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -123,6 +123,7 @@ static void guc_ct_buffer_desc_init(struct 
guc_ct_buffer_desc *desc,
 
 static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb, u32 cmds_addr)
 {
+   ctb->broken = false;
guc_ct_buffer_desc_init(ctb->desc, cmds_addr, ctb->size);
 }
 
@@ -387,9 +388,12 @@ static int ct_write(struct intel_guc_ct *ct,
u32 *cmds = ctb->cmds;
unsigned int i;
 
-   if (unlikely(desc->is_in_error))
+   if (unlikely(ctb->broken))
return -EPIPE;
 
+   if (unlikely(desc->is_in_error))
+   goto corrupted;
+
if (unlikely(!IS_ALIGNED(head | tail, 4) ||
 (tail | head) >= size))
goto corrupted;
@@ -451,6 +455,7 @@ static int ct_write(struct intel_guc_ct *ct,
CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
 desc->addr, desc->head, desc->tail, desc->size);
desc->is_in_error = 1;
+   ctb->broken = true;
return -EPIPE;
 }
 
@@ -632,9 +637,12 @@ static int ct_read(struct intel_guc_ct *ct, struct 
ct_incoming_msg **msg)
unsigned int i;
u32 header;
 
-   if (unlikely(desc->is_in_error))
+   if (unlikely(ctb->broken))
return -EPIPE;
 
+   if (unlikely(desc->is_in_error))
+   goto corrupted;
+
if (unlikely(!IS_ALIGNED(head | tail, 4) ||
 (tail | head) >= size))
goto corrupted;
@@ -698,6 +706,7 @@ static int ct_read(struct intel_guc_ct *ct, struct 
ct_incoming_msg **msg)
CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
 desc->addr, desc->head, desc->tail, desc->size);
desc->is_in_error = 1;
+   ctb->broken = true;
return -EPIPE;
 }
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index cb222f202301..7d3cd375d6a7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
@@ -32,12 +32,14 @@ struct intel_guc;
  * @desc: pointer to the buffer descriptor
  * @cmds: pointer to the commands buffer
  * @size: size of the commands buffer
+ * @broken: flag to indicate if descriptor data is broken
  */
 struct intel_guc_ct_buffer {
spinlock_t lock;
struct guc_ct_buffer_desc *desc;
u32 *cmds;
u32 size;
+   bool broken;
 };
 
 
-- 
2.28.0

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


[Intel-gfx] [PATCH 01/13] drm/i915/guc: Introduce unified HXG messages

2021-06-09 Thread Matthew Brost
From: Michal Wajdeczko 

New GuC firmware will unify format of MMIO and CTB H2G messages.
Introduce their definitions now to allow gradual transition of
our code to match new changes.

Signed-off-by: Matthew Brost 
Signed-off-by: Michal Wajdeczko 
Cc: Michał Winiarski 
---
 .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 ++
 1 file changed, 213 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
index 775e21f3058c..29ac823acd4c 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
@@ -6,6 +6,219 @@
 #ifndef _ABI_GUC_MESSAGES_ABI_H
 #define _ABI_GUC_MESSAGES_ABI_H
 
+/**
+ * DOC: HXG Message
+ *
+ * All messages exchanged with GuC are defined using 32 bit dwords.
+ * First dword is treated as a message header. Remaining dwords are optional.
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  |   |   |  
|
+ *  | 0 |31 | **ORIGIN** - originator of the message   
|
+ *  |   |   |   - _`GUC_HXG_ORIGIN_HOST` = 0   
|
+ *  |   |   |   - _`GUC_HXG_ORIGIN_GUC` = 1
|
+ *  |   |   |  
|
+ *  |   
+---+--+
+ *  |   | 30:28 | **TYPE** - message type  
|
+ *  |   |   |   - _`GUC_HXG_TYPE_REQUEST` = 0  
|
+ *  |   |   |   - _`GUC_HXG_TYPE_EVENT` = 1
|
+ *  |   |   |   - _`GUC_HXG_TYPE_NO_RESPONSE_BUSY` = 3 
|
+ *  |   |   |   - _`GUC_HXG_TYPE_NO_RESPONSE_RETRY` = 5
|
+ *  |   |   |   - _`GUC_HXG_TYPE_RESPONSE_FAILURE` = 6 
|
+ *  |   |   |   - _`GUC_HXG_TYPE_RESPONSE_SUCCESS` = 7 
|
+ *  |   
+---+--+
+ *  |   |  27:0 | **AUX** - auxiliary data (depends on TYPE)   
|
+ *  
+---+---+--+
+ *  | 1 |  31:0 |  
|
+ *  +---+---+  
|
+ *  |...|   | **PAYLOAD** - optional payload (depends on TYPE) 
|
+ *  +---+---+  
|
+ *  | n |  31:0 |  
|
+ *  
+---+---+--+
+ */
+
+#define GUC_HXG_MSG_MIN_LEN1u
+#define GUC_HXG_MSG_0_ORIGIN   (0x1 << 31)
+#define   GUC_HXG_ORIGIN_HOST  0u
+#define   GUC_HXG_ORIGIN_GUC   1u
+#define GUC_HXG_MSG_0_TYPE (0x7 << 28)
+#define   GUC_HXG_TYPE_REQUEST 0u
+#define   GUC_HXG_TYPE_EVENT   1u
+#define   GUC_HXG_TYPE_NO_RESPONSE_BUSY3u
+#define   GUC_HXG_TYPE_NO_RESPONSE_RETRY   5u
+#define   GUC_HXG_TYPE_RESPONSE_FAILURE6u
+#define   GUC_HXG_TYPE_RESPONSE_SUCCESS7u
+#define GUC_HXG_MSG_0_AUX  (0xfff << 0)
+#define GUC_HXG_MSG_n_PAYLOAD  (0x << 0)
+
+/**
+ * DOC: HXG Request
+ *
+ * The `HXG Request`_ message should be used to initiate synchronous activity
+ * for which confirmation or return data is expected.
+ *
+ * The recipient of this message shall use `HXG Response`_, `HXG Failure`_
+ * or `HXG Retry`_ message as a definite reply, and may use `HXG Busy`_
+ * message as a intermediate reply.
+ *
+ * Format of @DATA0 and all @DATAn fields depends on the @ACTION code.
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 |31 | ORIGIN   
|
+ *  |   
+---+--+
+ *  |   | 30:28 | TYPE = GUC_HXG_TYPE_REQUEST_ 
|
+ *  |   
+---+--+
+ *  |   | 27:16 | **DATA0** - request data (depends on ACTION) 
|
+ *  |   
+---+--+
+ *  |   |  15:0 | **ACTION** - requested action code   

[Intel-gfx] [PATCH 03/13] drm/i915/guc: Update CTB response status definition

2021-06-09 Thread Matthew Brost
From: Michal Wajdeczko 

Format of the STATUS dword in CTB response message now follows
definition of the HXG header. Update our code and remove any
obsolete legacy definitions.

GuC: 55.0.0
Signed-off-by: Matthew Brost 
Signed-off-by: Michal Wajdeczko 
Acked-by: Piotr Piórkowski 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c   | 14 --
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 17 -
 2 files changed, 8 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 8f7b148fef58..3f7f48611487 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -477,7 +477,9 @@ static int wait_for_ct_request_update(struct ct_request 
*req, u32 *status)
 * up to that length of time, then switch to a slower sleep-wait loop.
 * No GuC command should ever take longer than 10ms.
 */
-#define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
+#define done \
+   (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
+GUC_HXG_ORIGIN_GUC)
err = wait_for_us(done, 10);
if (err)
err = wait_for(done, 10);
@@ -532,21 +534,21 @@ static int ct_send(struct intel_guc_ct *ct,
if (unlikely(err))
goto unlink;
 
-   if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(*status)) {
+   if (FIELD_GET(GUC_HXG_MSG_0_TYPE, *status) != 
GUC_HXG_TYPE_RESPONSE_SUCCESS) {
err = -EIO;
goto unlink;
}
 
if (response_buf) {
/* There shall be no data in the status */
-   WARN_ON(INTEL_GUC_MSG_TO_DATA(request.status));
+   WARN_ON(FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, 
request.status));
/* Return actual response len */
err = request.response_len;
} else {
/* There shall be no response payload */
WARN_ON(request.response_len);
/* Return data decoded from the status dword */
-   err = INTEL_GUC_MSG_TO_DATA(*status);
+   err = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, *status);
}
 
 unlink:
@@ -741,8 +743,8 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
struct ct_incoming_msg *r
status = response->msg[2];
datalen = len - 2;
 
-   /* Format of the status follows RESPONSE message */
-   if (unlikely(!INTEL_GUC_MSG_IS_RESPONSE(status))) {
+   /* Format of the status dword follows HXG header */
+   if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, status) != 
GUC_HXG_ORIGIN_GUC)) {
CT_ERROR(ct, "Corrupted response (status %#x)\n", status);
return -EPROTO;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index e9a9d85e2aa3..fb04e2211b79 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -414,23 +414,6 @@ struct guc_shared_ctx_data {
struct guc_ctx_report preempt_ctx_report[GUC_MAX_ENGINES_NUM];
 } __packed;
 
-#define __INTEL_GUC_MSG_GET(T, m) \
-   (((m) & INTEL_GUC_MSG_ ## T ## _MASK) >> INTEL_GUC_MSG_ ## T ## _SHIFT)
-#define INTEL_GUC_MSG_TO_TYPE(m)   __INTEL_GUC_MSG_GET(TYPE, m)
-#define INTEL_GUC_MSG_TO_DATA(m)   __INTEL_GUC_MSG_GET(DATA, m)
-#define INTEL_GUC_MSG_TO_CODE(m)   __INTEL_GUC_MSG_GET(CODE, m)
-
-#define __INTEL_GUC_MSG_TYPE_IS(T, m) \
-   (INTEL_GUC_MSG_TO_TYPE(m) == INTEL_GUC_MSG_TYPE_ ## T)
-#define INTEL_GUC_MSG_IS_REQUEST(m)__INTEL_GUC_MSG_TYPE_IS(REQUEST, m)
-#define INTEL_GUC_MSG_IS_RESPONSE(m)   __INTEL_GUC_MSG_TYPE_IS(RESPONSE, m)
-
-#define INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(m) \
-(typecheck(u32, (m)) && \
- ((m) & (INTEL_GUC_MSG_TYPE_MASK | INTEL_GUC_MSG_CODE_MASK)) == \
- ((INTEL_GUC_MSG_TYPE_RESPONSE << INTEL_GUC_MSG_TYPE_SHIFT) | \
-  (INTEL_GUC_RESPONSE_STATUS_SUCCESS << INTEL_GUC_MSG_CODE_SHIFT)))
-
 /* This action will be programmed in C1BC - SOFT_SCRATCH_15_REG */
 enum intel_guc_recv_message {
INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED = BIT(1),
-- 
2.28.0

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


[Intel-gfx] [PATCH 02/13] drm/i915/guc: Update MMIO based communication

2021-06-09 Thread Matthew Brost
From: Michal Wajdeczko 

The MMIO based Host-to-GuC communication protocol has been
updated to use unified HXG messages.

Update our intel_guc_send_mmio() function by correctly handle
BUSY, RETRY and FAILURE replies. Also update our documentation.

Since some of the new MMIO actions may use DATA0 from MMIO HXG
response, we must update intel_guc_send_mmio() to copy full response,
including HXG header. There will be no impact to existing users as all
of them are only relying just on return code.

v2:
 (Daniele)
  - preffered -> preferred
  - Max MMIO DW set to 4
  - Update commit message

GuC: 55.0.0
Signed-off-by: Matthew Brost 
Signed-off-by: Michal Wajdeczko 
Cc: Piotr Piórkowski 
Cc: Michal Winiarski  #v3
---
 .../gt/uc/abi/guc_communication_mmio_abi.h| 65 +++--
 drivers/gpu/drm/i915/gt/uc/intel_guc.c| 92 ++-
 2 files changed, 98 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
index be066a62e9e0..bbf1ddb77434 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
@@ -7,46 +7,43 @@
 #define _ABI_GUC_COMMUNICATION_MMIO_ABI_H
 
 /**
- * DOC: MMIO based communication
+ * DOC: GuC MMIO based communication
  *
- * The MMIO based communication between Host and GuC uses software scratch
- * registers, where first register holds data treated as message header,
- * and other registers are used to hold message payload.
+ * The MMIO based communication between Host and GuC relies on special
+ * hardware registers which format could be defined by the software
+ * (so called scratch registers).
  *
- * For Gen9+, GuC uses software scratch registers 0xC180-0xC1B8,
- * but no H2G command takes more than 8 parameters and the GuC FW
- * itself uses an 8-element array to store the H2G message.
+ * Each MMIO based message, both Host to GuC (H2G) and GuC to Host (G2H)
+ * messages, which maximum length depends on number of available scratch
+ * registers, is directly written into those scratch registers.
  *
- *  +---+-+-+-+
- *  |  MMIO[0]  | MMIO[1] |   ...   | MMIO[n] |
- *  +---+-+-+-+
- *  | header|  optional payload   |
- *  +==++=+=+=+
- *  | 31:28|type| | | |
- *  +--++ | | |
- *  | 27:16|data| | | |
- *  +--++ | | |
- *  |  15:0|code| | | |
- *  +--++-+-+-+
+ * For Gen9+, there are 16 software scratch registers 0xC180-0xC1B8,
+ * but no H2G command takes more than 4 parameters and the GuC firmware
+ * itself uses an 4-element array to store the H2G message.
  *
- * The message header consists of:
+ * For Gen11+, there are additional 4 registers 0x190240-0x19024C, which
+ * are, regardless on lower count, preferred over legacy ones.
  *
- * - **type**, indicates message type
- * - **code**, indicates message code, is specific for **type**
- * - **data**, indicates message data, optional, depends on **code**
- *
- * The following message **types** are supported:
- *
- * - **REQUEST**, indicates Host-to-GuC request, requested GuC action code
- *   must be priovided in **code** field. Optional action specific parameters
- *   can be provided in remaining payload registers or **data** field.
- *
- * - **RESPONSE**, indicates GuC-to-Host response from earlier GuC request,
- *   action response status will be provided in **code** field. Optional
- *   response data can be returned in remaining payload registers or **data**
- *   field.
+ * The MMIO based communication is mainly used during driver initialization
+ * phase to setup the `CTB based communication`_ that will be used afterwards.
  */
 
-#define GUC_MAX_MMIO_MSG_LEN   8
+#define GUC_MAX_MMIO_MSG_LEN   4
+
+/**
+ * DOC: MMIO HXG Message
+ *
+ * Format of the MMIO messages follows definitions of `HXG Message`_.
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 |  31:0 |  ++  
|
+ *  +---+---+  ||  
|
+ *  |...|   |  |  Embedded `HXG Message`_   |  
|
+ *  +---+---+  ||  
|
+ *  | n |  31:0 |  ++  
|
+ *  
+---+---+--+
+ */
 
 #endif /* _ABI_GUC_COMMUNICATION_MMIO_ABI_H 

[Intel-gfx] [PATCH 00/13] Update firmware to v62.0.0

2021-06-09 Thread Matthew Brost
As part of enabling GuC submission [1] we need to update to the latest
and greatest firmware. This series does that. This is a destructive
change. e.g. Without all the patches in this series it will break the
i915 driver. As such, after we review most of these patches they will
squashed into a single patch for merging.

v2: Address comments, looking for remaning RBs so patches can be
squashed and sent for CI

Signed-off-by: Matthew Brost 

[1] https://patchwork.freedesktop.org/series/89844/i

John Harrison (3):
  drm/i915/guc: Support per context scheduling policies
  drm/i915/guc: Unified GuC log
  drm/i915/guc: Update firmware to v62.0.0

Michal Wajdeczko (10):
  drm/i915/guc: Introduce unified HXG messages
  drm/i915/guc: Update MMIO based communication
  drm/i915/guc: Update CTB response status definition
  drm/i915/guc: Add flag for mark broken CTB
  drm/i915/guc: New definition of the CTB descriptor
  drm/i915/guc: New definition of the CTB registration action
  drm/i915/guc: New CTB based communication
  drm/i915/doc: Include GuC ABI documentation
  drm/i915/guc: Kill guc_clients.ct_pool
  drm/i915/guc: Kill ads.client_info

 Documentation/gpu/i915.rst|   8 +
 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  | 107 ++
 .../gt/uc/abi/guc_communication_ctb_abi.h | 128 +--
 .../gt/uc/abi/guc_communication_mmio_abi.h|  65 ++--
 .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc.c| 107 --
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c|  45 +--
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 356 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |   6 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  75 +---
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.c|  29 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.h|   6 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |  26 +-
 13 files changed, 750 insertions(+), 421 deletions(-)

-- 
2.28.0

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


Re: [Intel-gfx] [PATCH 08/13] drm/i915/guc: New CTB based communication

2021-06-09 Thread Matthew Brost
On Mon, Jun 07, 2021 at 07:20:01PM -0700, Daniele Ceraolo Spurio wrote:
> 
> 
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
> > From: Michal Wajdeczko 
> > 
> > Format of the CTB messages has changed:
> >   - support for multiple formats
> >   - message fence is now part of the header
> >   - reuse of unified HXG message formats
> > 
> > Signed-off-by: Michal Wajdeczko 
> > Signed-off-by: Matthew Brost 
> > Cc: Piotr Piórkowski 
> > ---
> >   .../gt/uc/abi/guc_communication_ctb_abi.h |  56 +
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 194 +++---
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |   2 +-
> >   3 files changed, 135 insertions(+), 117 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h 
> > b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> > index 127b256a662c..92660726c094 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> > @@ -60,6 +60,62 @@ struct guc_ct_buffer_desc {
> >   } __packed;
> >   static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
> > +/**
> > + * DOC: CTB Message
> > + *
> > + *  
> > +---+---+--+
> > + *  |   | Bits  | Description  
> > |
> > + *  
> > +===+===+==+
> > + *  | 0 | 31:16 | **FENCE** - message identifier   
> > |
> > + *  |   
> > +---+--+
> > + *  |   | 15:12 | **FORMAT** - format of the CTB message   
> > |
> > + *  |   |   |  - _`GUC_CTB_FORMAT_HXG` = 0 - see `CTB HXG Message`_
> > |
> > + *  |   
> > +---+--+
> > + *  |   |  11:8 | **RESERVED** 
> > |
> > + *  |   
> > +---+--+
> > + *  |   |   7:0 | **NUM_DWORDS** - length of the CTB message (w/o header)  
> > |
> > + *  
> > +---+---+--+
> > + *  | 1 |  31:0 | optional (depends on FORMAT) 
> > |
> > + *  +---+---+  
> > |
> > + *  |...|   |  
> > |
> > + *  +---+---+  
> > |
> > + *  | n |  31:0 |  
> > |
> > + *  
> > +---+---+--+
> > + */
> > +
> > +#define GUC_CTB_MSG_MIN_LEN1u
> > +#define GUC_CTB_MSG_MAX_LEN256u
> > +#define GUC_CTB_MSG_0_FENCE(0x << 16)
> > +#define GUC_CTB_MSG_0_FORMAT   (0xf << 12)
> > +#define   GUC_CTB_FORMAT_HXG   0u
> > +#define GUC_CTB_MSG_0_RESERVED (0xf << 8)
> > +#define GUC_CTB_MSG_0_NUM_DWORDS   (0xff << 0)
> > +
> > +/**
> > + * DOC: CTB HXG Message
> > + *
> > + *  
> > +---+---+--+
> > + *  |   | Bits  | Description  
> > |
> > + *  
> > +===+===+==+
> > + *  | 0 | 31:16 | FENCE
> > |
> > + *  |   
> > +---+--+
> > + *  |   | 15:12 | FORMAT = GUC_CTB_FORMAT_HXG_ 
> > |
> > + *  |   
> > +---+--+
> > + *  |   |  11:8 | RESERVED = MBZ   
> > |
> > + *  |   
> > +---+--+
> > + *  |   |   7:0 | NUM_DWORDS = length (in dwords) of the embedded HXG 
> > message  |
> > + *  
> > +---+---+--+
> > + *  | 1 |  31:0 |  
> > ++  |
> > + *  +---+---+  |   
> >  |  |
> > + *  |...|   |  |  Embedded `HXG Message`_  
> >  |  |
> > + *  +---+---+  |   
> >  |  |
> > + *  | n |  31:0 |  
> > ++  |
> > + *  
> > +---+---+--+
> > + */
> > +
> > +#define GUC_CTB_HXG_MSG_MIN_LEN(GUC_CTB_MSG_MIN_LEN + 
> > 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add enable_lttpr param to select between different LTTPR modes

2021-06-09 Thread Patchwork
== Series Details ==

Series: drm/i915: Add enable_lttpr param to select between different LTTPR modes
URL   : https://patchwork.freedesktop.org/series/91303/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10199_full -> Patchwork_20324_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### Piglit changes ###

 Possible regressions 

  * 
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-position-double_dvec2-int_ivec3
 (NEW):
- {pig-icl-1065g7}:   NOTRUN -> [CRASH][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/pig-icl-1065g7/spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-position-double_dvec2-int_ivec3.html

  * 
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-position-float_vec3_array3-double_dvec3_array2
 (NEW):
- {pig-icl-1065g7}:   NOTRUN -> [INCOMPLETE][2] +6 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/pig-icl-1065g7/spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-position-float_vec3_array3-double_dvec3_array2.html

  
New tests
-

  New tests have been introduced between CI_DRM_10199_full and 
Patchwork_20324_full:

### New Piglit tests (8) ###

  * 
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-double_dmat3x4-uint_uvec3_array3-position:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * 
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-double_dmat4-float_mat4x3-position:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * 
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-double_dmat4x2_array5-position-int_ivec2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * 
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-position-double_dmat3x4_array5-uint_uvec2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * 
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-position-double_dmat4x2-uint_uint:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * 
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-position-double_dvec2-int_ivec3:
- Statuses : 1 crash(s)
- Exec time: [0.70] s

  * 
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-position-float_vec3_array3-double_dvec3_array2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * 
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-position-int_ivec2_array3-double_dmat3x4:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@bcs0:
- shard-apl:  NOTRUN -> [DMESG-WARN][3] ([i915#180])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/shard-apl6/igt@gem_ctx_isolation@preservation...@bcs0.html

  * igt@gem_ctx_persistence@engines-persistence:
- shard-snb:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/shard-snb6/igt@gem_ctx_persiste...@engines-persistence.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][5] -> [FAIL][6] ([i915#2842]) +2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][7] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-glk:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/shard-glk5/igt@gem_exec_fair@basic-p...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/shard-glk1/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-kbl:  [PASS][10] -> [SKIP][11] ([fdo#109271])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_whisper@basic-fds-forked-all:
- shard-glk:  [PASS][12] -> [DMESG-WARN][13] ([i915#118] / 
[i915#95])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/shard-glk6/igt@gem_exec_whis...@basic-fds-forked-all.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/shard-glk8/igt@gem_exec_whis...@basic-fds-forked-all.html

  * igt@gem_mmap_gtt@big-copy:
- shard-glk:  [PASS][14] -> [FAIL][15] 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add enable_lttpr param to select between different LTTPR modes

2021-06-09 Thread Patchwork
== Series Details ==

Series: drm/i915: Add enable_lttpr param to select between different LTTPR modes
URL   : https://patchwork.freedesktop.org/series/91303/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10199 -> Patchwork_20324


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


  Here are the changes found in Patchwork_20324 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_10199/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2:  [FAIL][3] ([i915#1888]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [FAIL][5] ([i915#2203]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-kbl-guc/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/fi-kbl-guc/igt@i915_pm_...@module-reload.html

  
 Warnings 

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

  * igt@runner@aborted:
- fi-cfl-8700k:   [FAIL][9] ([i915#2426] / [i915#3363]) -> [FAIL][10] 
([i915#3363])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-cfl-8700k/igt@run...@aborted.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/fi-cfl-8700k/igt@run...@aborted.html
- fi-skl-6600u:   [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_10199/fi-skl-6600u/igt@run...@aborted.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/fi-skl-6600u/igt@run...@aborted.html
- fi-glk-dsi: [FAIL][13] ([i915#2426] / [i915#3363] / 
[k.org#202321]) -> [FAIL][14] ([i915#3363] / [k.org#202321])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-glk-dsi/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/fi-glk-dsi/igt@run...@aborted.html
- fi-kbl-8809g:   [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_10199/fi-kbl-8809g/igt@run...@aborted.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/fi-kbl-8809g/igt@run...@aborted.html
- fi-kbl-r:   [FAIL][17] ([i915#1436] / [i915#3363]) -> [FAIL][18] 
([i915#1436] / [i915#2426] / [i915#3363])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-kbl-r/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/fi-kbl-r/igt@run...@aborted.html
- fi-kbl-soraka:  [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_10199/fi-kbl-soraka/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/fi-kbl-soraka/igt@run...@aborted.html
- fi-cml-u2:  [FAIL][21] ([i915#3363] / [i915#3462]) -> [FAIL][22] 
([i915#2082] / [i915#2426] / [i915#3363] / [i915#3462])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-cml-u2/igt@run...@aborted.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/fi-cml-u2/igt@run...@aborted.html
- fi-skl-guc: [FAIL][23] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][24] ([i915#1436] / [i915#3363])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-skl-guc/igt@run...@aborted.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/fi-skl-guc/igt@run...@aborted.html
- fi-skl-6700k2:  [FAIL][25] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][26] ([i915#1436] / [i915#3363])
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-skl-6700k2/igt@run...@aborted.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/fi-skl-6700k2/igt@run...@aborted.html

  
  {name}: This element is suppressed. This means 

[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915: Add enable_lttpr param to select between different LTTPR modes

2021-06-09 Thread Patchwork
== Series Details ==

Series: drm/i915: Add enable_lttpr param to select between different LTTPR modes
URL   : https://patchwork.freedesktop.org/series/91303/
State : warning

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  MODPOST modules-only.symvers
ERROR: modpost: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:150: recipe for target 'modules-only.symvers' failed
make[1]: *** [modules-only.symvers] Error 1
make[1]: *** Deleting file 'modules-only.symvers'
Makefile:1759: recipe for target 'modules' failed
make: *** [modules] Error 2

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20324/build_32bit.log
___
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: Add enable_lttpr param to select between different LTTPR modes

2021-06-09 Thread Patchwork
== Series Details ==

Series: drm/i915: Add enable_lttpr param to select between different LTTPR modes
URL   : https://patchwork.freedesktop.org/series/91303/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a7a0632aa3ee drm/i915: Add enable_lttpr param to select between different LTTPR 
modes
-:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#7: 
As LTTPR usage increases in newer platforms, and because not all LTTPRs (located

-:58: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#58: FILE: drivers/gpu/drm/i915/i915_params.c:182:
+i915_param_named_unsafe(enable_lttpr, int, 0400,
+   "Enable LTTPR "

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


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


Re: [Intel-gfx] [RFC PATCH 36/97] drm/i915/guc: Add non blocking CTB send function

2021-06-09 Thread Matthew Brost
On Wed, Jun 09, 2021 at 04:14:05PM +0200, Michal Wajdeczko wrote:
> 
> 
> On 07.06.2021 19:31, Matthew Brost wrote:
> > On Thu, May 27, 2021 at 04:11:50PM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 27/05/2021 15:35, Matthew Brost wrote:
> >>> On Thu, May 27, 2021 at 11:02:24AM +0100, Tvrtko Ursulin wrote:
> 
>  On 26/05/2021 19:10, Matthew Brost wrote:
> 
>  [snip]
> 
> > +static int ct_send_nb(struct intel_guc_ct *ct,
> > + const u32 *action,
> > + u32 len,
> > + u32 flags)
> > +{
> > +   struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > +   unsigned long spin_flags;
> > +   u32 fence;
> > +   int ret;
> > +
> > +   spin_lock_irqsave(>lock, spin_flags);
> > +
> > +   ret = ctb_has_room(ctb, len + 1);
> > +   if (unlikely(ret))
> > +   goto out;
> > +
> > +   fence = ct_get_next_fence(ct);
> > +   ret = ct_write(ct, action, len, fence, flags);
> > +   if (unlikely(ret))
> > +   goto out;
> > +
> > +   intel_guc_notify(ct_to_guc(ct));
> > +
> > +out:
> > +   spin_unlock_irqrestore(>lock, spin_flags);
> > +
> > +   return ret;
> > +}
> > +
> >  static int ct_send(struct intel_guc_ct *ct,
> >const u32 *action,
> >u32 len,
> > @@ -473,6 +541,7 @@ static int ct_send(struct intel_guc_ct *ct,
> >u32 response_buf_size,
> >u32 *status)
> >  {
> > +   struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > struct ct_request request;
> > unsigned long flags;
> > u32 fence;
> > @@ -482,8 +551,20 @@ static int ct_send(struct intel_guc_ct *ct,
> > GEM_BUG_ON(!len);
> > GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
> > GEM_BUG_ON(!response_buf && response_buf_size);
> > +   might_sleep();
> 
>  Sleep is just cond_resched below or there is more?
> 
> >>>
> >>> Yes, the cond_resched.
> >>>
> > +   /*
> > +* We use a lazy spin wait loop here as we believe that if the 
> > CT
> > +* buffers are sized correctly the flow control condition 
> > should be
> > +* rare.
> > +*/
> > +retry:
> > spin_lock_irqsave(>ctbs.send.lock, flags);
> > +   if (unlikely(!ctb_has_room(ctb, len + 1))) {
> > +   spin_unlock_irqrestore(>ctbs.send.lock, flags);
> > +   cond_resched();
> > +   goto retry;
> > +   }
> 
>  If this patch is about adding a non-blocking send function, and 
>  below we can
>  see that it creates a fork:
> 
>  intel_guc_ct_send:
>  ...
>   if (flags & INTEL_GUC_SEND_NB)
>   return ct_send_nb(ct, action, len, flags);
> 
>   ret = ct_send(ct, action, len, response_buf, response_buf_size, 
>  );
> 
>  Then why is there a change in ct_send here, which is not the new
>  non-blocking path?
> 
> >>>
> >>> There is not a change to ct_send(), just to intel_guc_ct_send.
> >>
> >> I was doing by the diff which says:
> >>
> >>static int ct_send(struct intel_guc_ct *ct,
> >>   const u32 *action,
> >>   u32 len,
> >> @@ -473,6 +541,7 @@ static int ct_send(struct intel_guc_ct *ct,
> >>   u32 response_buf_size,
> >>   u32 *status)
> >>{
> >> +  struct intel_guc_ct_buffer *ctb = >ctbs.send;
> >>struct ct_request request;
> >>unsigned long flags;
> >>u32 fence;
> >> @@ -482,8 +551,20 @@ static int ct_send(struct intel_guc_ct *ct,
> >>GEM_BUG_ON(!len);
> >>GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
> >>GEM_BUG_ON(!response_buf && response_buf_size);
> >> +  might_sleep();
> >> +  /*
> >> +   * We use a lazy spin wait loop here as we believe that if the 
> >> CT
> >> +   * buffers are sized correctly the flow control condition 
> >> should be
> >> +   * rare.
> >> +   */
> >> +retry:
> >>spin_lock_irqsave(>ctbs.send.lock, flags);
> >> +  if (unlikely(!ctb_has_room(ctb, len + 1))) {
> >> +  spin_unlock_irqrestore(>ctbs.send.lock, flags);
> >> +  cond_resched();
> >> +  goto retry;
> >> +  }
> >>
> >> So it looks like a change to ct_send to me. Is that wrong?
> 
> 

Re: [Intel-gfx] [RFC PATCH 36/97] drm/i915/guc: Add non blocking CTB send function

2021-06-09 Thread Matthew Brost
On Tue, Jun 08, 2021 at 10:46:15AM +0200, Daniel Vetter wrote:
> On Tue, Jun 8, 2021 at 10:39 AM Tvrtko Ursulin
>  wrote:
> >
> >
> > On 07/06/2021 18:31, Matthew Brost wrote:
> > > On Thu, May 27, 2021 at 04:11:50PM +0100, Tvrtko Ursulin wrote:
> > >>
> > >> On 27/05/2021 15:35, Matthew Brost wrote:
> > >>> On Thu, May 27, 2021 at 11:02:24AM +0100, Tvrtko Ursulin wrote:
> > 
> >  On 26/05/2021 19:10, Matthew Brost wrote:
> > 
> >  [snip]
> > 
> > > +static int ct_send_nb(struct intel_guc_ct *ct,
> > > +   const u32 *action,
> > > +   u32 len,
> > > +   u32 flags)
> > > +{
> > > + struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > > + unsigned long spin_flags;
> > > + u32 fence;
> > > + int ret;
> > > +
> > > + spin_lock_irqsave(>lock, spin_flags);
> > > +
> > > + ret = ctb_has_room(ctb, len + 1);
> > > + if (unlikely(ret))
> > > + goto out;
> > > +
> > > + fence = ct_get_next_fence(ct);
> > > + ret = ct_write(ct, action, len, fence, flags);
> > > + if (unlikely(ret))
> > > + goto out;
> > > +
> > > + intel_guc_notify(ct_to_guc(ct));
> > > +
> > > +out:
> > > + spin_unlock_irqrestore(>lock, spin_flags);
> > > +
> > > + return ret;
> > > +}
> > > +
> > >   static int ct_send(struct intel_guc_ct *ct,
> > >  const u32 *action,
> > >  u32 len,
> > > @@ -473,6 +541,7 @@ static int ct_send(struct intel_guc_ct *ct,
> > >  u32 response_buf_size,
> > >  u32 *status)
> > >   {
> > > + struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > >   struct ct_request request;
> > >   unsigned long flags;
> > >   u32 fence;
> > > @@ -482,8 +551,20 @@ static int ct_send(struct intel_guc_ct *ct,
> > >   GEM_BUG_ON(!len);
> > >   GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
> > >   GEM_BUG_ON(!response_buf && response_buf_size);
> > > + might_sleep();
> > 
> >  Sleep is just cond_resched below or there is more?
> > 
> > >>>
> > >>> Yes, the cond_resched.
> > >>>
> > > + /*
> > > +  * We use a lazy spin wait loop here as we believe that if 
> > > the CT
> > > +  * buffers are sized correctly the flow control condition 
> > > should be
> > > +  * rare.
> > > +  */
> > > +retry:
> > >   spin_lock_irqsave(>ctbs.send.lock, flags);
> > > + if (unlikely(!ctb_has_room(ctb, len + 1))) {
> > > + spin_unlock_irqrestore(>ctbs.send.lock, flags);
> > > + cond_resched();
> > > + goto retry;
> > > + }
> > 
> >  If this patch is about adding a non-blocking send function, and 
> >  below we can
> >  see that it creates a fork:
> > 
> >  intel_guc_ct_send:
> >  ...
> > if (flags & INTEL_GUC_SEND_NB)
> > return ct_send_nb(ct, action, len, flags);
> > 
> > ret = ct_send(ct, action, len, response_buf, 
> >  response_buf_size, );
> > 
> >  Then why is there a change in ct_send here, which is not the new
> >  non-blocking path?
> > 
> > >>>
> > >>> There is not a change to ct_send(), just to intel_guc_ct_send.
> > >>
> > >> I was doing by the diff which says:
> > >>
> > >> static int ct_send(struct intel_guc_ct *ct,
> > >> const u32 *action,
> > >> u32 len,
> > >> @@ -473,6 +541,7 @@ static int ct_send(struct intel_guc_ct *ct,
> > >> u32 response_buf_size,
> > >> u32 *status)
> > >> {
> > >> +struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > >>  struct ct_request request;
> > >>  unsigned long flags;
> > >>  u32 fence;
> > >> @@ -482,8 +551,20 @@ static int ct_send(struct intel_guc_ct *ct,
> > >>  GEM_BUG_ON(!len);
> > >>  GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
> > >>  GEM_BUG_ON(!response_buf && response_buf_size);
> > >> +might_sleep();
> > >> +/*
> > >> + * We use a lazy spin wait loop here as we believe that if 
> > >> the CT
> > >> + * buffers are sized correctly the flow control condition 
> > >> should be
> > >> + 

Re: [Intel-gfx] [RFC PATCH 36/97] drm/i915/guc: Add non blocking CTB send function

2021-06-09 Thread Matthew Brost
On Wed, Jun 09, 2021 at 03:58:38PM +0200, Michal Wajdeczko wrote:
> 
> 
> On 08.06.2021 10:39, Tvrtko Ursulin wrote:
> > 
> > On 07/06/2021 18:31, Matthew Brost wrote:
> >> On Thu, May 27, 2021 at 04:11:50PM +0100, Tvrtko Ursulin wrote:
> >>>
> >>> On 27/05/2021 15:35, Matthew Brost wrote:
>  On Thu, May 27, 2021 at 11:02:24AM +0100, Tvrtko Ursulin wrote:
> >
> > On 26/05/2021 19:10, Matthew Brost wrote:
> >
> > [snip]
> >
> >> +static int ct_send_nb(struct intel_guc_ct *ct,
> >> +  const u32 *action,
> >> +  u32 len,
> >> +  u32 flags)
> >> +{
> >> +    struct intel_guc_ct_buffer *ctb = >ctbs.send;
> >> +    unsigned long spin_flags;
> >> +    u32 fence;
> >> +    int ret;
> >> +
> >> +    spin_lock_irqsave(>lock, spin_flags);
> >> +
> >> +    ret = ctb_has_room(ctb, len + 1);
> >> +    if (unlikely(ret))
> >> +    goto out;
> >> +
> >> +    fence = ct_get_next_fence(ct);
> >> +    ret = ct_write(ct, action, len, fence, flags);
> >> +    if (unlikely(ret))
> >> +    goto out;
> >> +
> >> +    intel_guc_notify(ct_to_guc(ct));
> >> +
> >> +out:
> >> +    spin_unlock_irqrestore(>lock, spin_flags);
> >> +
> >> +    return ret;
> >> +}
> >> +
> >>   static int ct_send(struct intel_guc_ct *ct,
> >>  const u32 *action,
> >>  u32 len,
> >> @@ -473,6 +541,7 @@ static int ct_send(struct intel_guc_ct *ct,
> >>  u32 response_buf_size,
> >>  u32 *status)
> >>   {
> >> +    struct intel_guc_ct_buffer *ctb = >ctbs.send;
> >>   struct ct_request request;
> >>   unsigned long flags;
> >>   u32 fence;
> >> @@ -482,8 +551,20 @@ static int ct_send(struct intel_guc_ct *ct,
> >>   GEM_BUG_ON(!len);
> >>   GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
> >>   GEM_BUG_ON(!response_buf && response_buf_size);
> >> +    might_sleep();
> >
> > Sleep is just cond_resched below or there is more?
> >
> 
>  Yes, the cond_resched.
> 
> >> +    /*
> >> + * We use a lazy spin wait loop here as we believe that
> >> if the CT
> >> + * buffers are sized correctly the flow control condition
> >> should be
> >> + * rare.
> >> + */
> >> +retry:
> >>   spin_lock_irqsave(>ctbs.send.lock, flags);
> >> +    if (unlikely(!ctb_has_room(ctb, len + 1))) {
> >> +    spin_unlock_irqrestore(>ctbs.send.lock, flags);
> >> +    cond_resched();
> >> +    goto retry;
> >> +    }
> >
> > If this patch is about adding a non-blocking send function, and
> > below we can
> > see that it creates a fork:
> >
> > intel_guc_ct_send:
> > ...
> > if (flags & INTEL_GUC_SEND_NB)
> >     return ct_send_nb(ct, action, len, flags);
> >
> >  ret = ct_send(ct, action, len, response_buf,
> > response_buf_size, );
> >
> > Then why is there a change in ct_send here, which is not the new
> > non-blocking path?
> >
> 
>  There is not a change to ct_send(), just to intel_guc_ct_send.
> >>>
> >>> I was doing by the diff which says:
> >>>
> >>>     static int ct_send(struct intel_guc_ct *ct,
> >>>    const u32 *action,
> >>>    u32 len,
> >>> @@ -473,6 +541,7 @@ static int ct_send(struct intel_guc_ct *ct,
> >>>    u32 response_buf_size,
> >>>    u32 *status)
> >>>     {
> >>> +    struct intel_guc_ct_buffer *ctb = >ctbs.send;
> >>>     struct ct_request request;
> >>>     unsigned long flags;
> >>>     u32 fence;
> >>> @@ -482,8 +551,20 @@ static int ct_send(struct intel_guc_ct *ct,
> >>>     GEM_BUG_ON(!len);
> >>>     GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
> >>>     GEM_BUG_ON(!response_buf && response_buf_size);
> >>> +    might_sleep();
> >>> +    /*
> >>> + * We use a lazy spin wait loop here as we believe that if
> >>> the CT
> >>> + * buffers are sized correctly the flow control condition
> >>> should be
> >>> + * rare.
> >>> + */
> >>> +retry:
> >>>     spin_lock_irqsave(>ctbs.send.lock, flags);
> >>> +    if (unlikely(!ctb_has_room(ctb, len + 1))) {
> >>> +    spin_unlock_irqrestore(>ctbs.send.lock, flags);
> >>> +    cond_resched();
> >>> +    goto retry;
> >>> +  

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gem: ioctl clean-ups (rev7)

2021-06-09 Thread Patchwork
== Series Details ==

Series: drm/i915/gem: ioctl clean-ups (rev7)
URL   : https://patchwork.freedesktop.org/series/89443/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10199_full -> Patchwork_20322_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20322_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20322_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_20322_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_ctx_engines@execute-allforone:
- shard-snb:  [PASS][1] -> [FAIL][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/shard-snb5/igt@gem_ctx_engi...@execute-allforone.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/shard-snb7/igt@gem_ctx_engi...@execute-allforone.html

  * igt@gem_ctx_engines@independent@rcs0:
- shard-iclb: NOTRUN -> [FAIL][3] +5 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/shard-iclb8/igt@gem_ctx_engines@independ...@rcs0.html

  * igt@gem_ctx_engines@independent@vcs0:
- shard-apl:  NOTRUN -> [FAIL][4] +6 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/shard-apl7/igt@gem_ctx_engines@independ...@vcs0.html

  * igt@gem_ctx_engines@independent@vecs0:
- shard-tglb: [PASS][5] -> [FAIL][6] +14 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/shard-tglb7/igt@gem_ctx_engines@independ...@vecs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/shard-tglb2/igt@gem_ctx_engines@independ...@vecs0.html

  * igt@gem_ctx_engines@invalid-engines:
- shard-iclb: [PASS][7] -> [FAIL][8] +7 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/shard-iclb6/igt@gem_ctx_engi...@invalid-engines.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/shard-iclb3/igt@gem_ctx_engi...@invalid-engines.html
- shard-snb:  NOTRUN -> [FAIL][9]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/shard-snb5/igt@gem_ctx_engi...@invalid-engines.html

  * igt@gem_ctx_engines@none:
- shard-glk:  [PASS][10] -> [FAIL][11] +12 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/shard-glk5/igt@gem_ctx_engi...@none.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/shard-glk7/igt@gem_ctx_engi...@none.html
- shard-apl:  [PASS][12] -> [FAIL][13] +1 similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/shard-apl3/igt@gem_ctx_engi...@none.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/shard-apl6/igt@gem_ctx_engi...@none.html

  * igt@gem_ctx_param@vm:
- shard-tglb: [PASS][14] -> [SKIP][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/shard-tglb3/igt@gem_ctx_pa...@vm.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/shard-tglb6/igt@gem_ctx_pa...@vm.html
- shard-iclb: [PASS][16] -> [SKIP][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/shard-iclb3/igt@gem_ctx_pa...@vm.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/shard-iclb7/igt@gem_ctx_pa...@vm.html

  * igt@gem_ctx_shared@detached-shared-gtt:
- shard-kbl:  [PASS][18] -> [FAIL][19] +12 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/shard-kbl1/igt@gem_ctx_sha...@detached-shared-gtt.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/shard-kbl1/igt@gem_ctx_sha...@detached-shared-gtt.html

  * igt@gem_watchdog@default-virtual:
- shard-skl:  [PASS][20] -> [FAIL][21] +8 similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/shard-skl7/igt@gem_watch...@default-virtual.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/shard-skl2/igt@gem_watch...@default-virtual.html
- shard-kbl:  NOTRUN -> [FAIL][22]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/shard-kbl1/igt@gem_watch...@default-virtual.html

  * igt@kms_vblank@pipe-b-query-busy-hang:
- shard-tglb: [PASS][23] -> [INCOMPLETE][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/shard-tglb8/igt@kms_vbl...@pipe-b-query-busy-hang.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/shard-tglb6/igt@kms_vbl...@pipe-b-query-busy-hang.html

  
New tests
-

  New tests have been introduced between CI_DRM_10199_full and 
Patchwork_20322_full:

### New IGT tests (5) ###

  * 

[Intel-gfx] [PATCH] drm/i915: Add enable_lttpr param to select between different LTTPR modes

2021-06-09 Thread Khaled Almahallawy
As LTTPR usage increases in newer platforms, and because not all LTTPRs (located
on board, Docking, active cables, or Monitors) are created equal. We face
challenges in debugging issues because of it. So we need an easy way to switch
between different LTTPR modes (at least non-LTTPR and non-transparent modes) to
debug. This patch allows us to do that by just setting driver parameters instead
of sending patches to ODMs to switch between LTTPR modes.

Cc: Imre Deak 
Signed-off-by: Khaled Almahallawy 
---
 drivers/gpu/drm/i915/display/intel_dp_link_training.c | 7 +++
 drivers/gpu/drm/i915/i915_params.c| 4 
 drivers/gpu/drm/i915/i915_params.h| 1 +
 3 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 08bceae40aa8..c29c1e005c6f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -92,6 +92,9 @@ static bool intel_dp_read_lttpr_common_caps(struct intel_dp 
*intel_dp)
if (intel_dp_is_edp(intel_dp))
return false;
 
+   if (!i915->params.enable_lttpr)
+   return 0;
+
/*
 * Detecting LTTPRs must be avoided on platforms with an AUX timeout
 * period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
@@ -132,6 +135,7 @@ static int intel_dp_init_lttpr(struct intel_dp *intel_dp)
 {
int lttpr_count;
int i;
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
 
if (!intel_dp_read_lttpr_common_caps(intel_dp))
return 0;
@@ -152,6 +156,9 @@ static int intel_dp_init_lttpr(struct intel_dp *intel_dp)
 */
intel_dp_set_lttpr_transparent_mode(intel_dp, true);
 
+   if (i915->params.enable_lttpr > 0)
+   return 0;
+
/*
 * In case of unsupported number of LTTPRs or failing to switch to
 * non-transparent mode fall-back to transparent link training mode,
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index e07f4cfea63a..67d030774ced 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -178,6 +178,10 @@ i915_param_named_unsafe(dmc_firmware_path, charp, 0400,
 i915_param_named_unsafe(enable_dp_mst, bool, 0400,
"Enable multi-stream transport (MST) for new DisplayPort sinks. 
(default: true)");
 
+i915_param_named_unsafe(enable_lttpr, int, 0400,
+   "Enable LTTPR "
+   "(-1= non-transparent mode [default], 0=Non-LTTPR, 
1=transparent-mode)");
+
 #if IS_ENABLED(CONFIG_DRM_I915_DEBUG)
 i915_param_named_unsafe(inject_probe_failure, uint, 0400,
"Force an error after a number of failure check points (0:disabled 
(default), N:force failure at the Nth failure check point)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index f27eceb82c0f..40f15a6db153 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -61,6 +61,7 @@ struct drm_printer;
param(int, invert_brightness, 0, 0600) \
param(int, enable_guc, -1, 0400) \
param(int, guc_log_level, -1, 0400) \
+   param(int, enable_lttpr, -1, 0600) \
param(char *, guc_firmware_path, NULL, 0400) \
param(char *, huc_firmware_path, NULL, 0400) \
param(char *, dmc_firmware_path, NULL, 0400) \
-- 
2.25.1

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence

2021-06-09 Thread Patchwork
== Series Details ==

Series: dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence
URL   : https://patchwork.freedesktop.org/series/91299/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10199 -> Patchwork_20323


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20323 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20323, 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_20323/index.html

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@dmabuf@all@dma_fence:
- fi-snb-2520m:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-snb-2520m/igt@dmabuf@all@dma_fence.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20323/fi-snb-2520m/igt@dmabuf@all@dma_fence.html
- fi-ilk-650: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-ilk-650/igt@dmabuf@all@dma_fence.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20323/fi-ilk-650/igt@dmabuf@all@dma_fence.html
- fi-ivb-3770:[PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-ivb-3770/igt@dmabuf@all@dma_fence.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20323/fi-ivb-3770/igt@dmabuf@all@dma_fence.html
- fi-elk-e7500:   [PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-elk-e7500/igt@dmabuf@all@dma_fence.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20323/fi-elk-e7500/igt@dmabuf@all@dma_fence.html
- fi-hsw-4770:[PASS][9] -> [INCOMPLETE][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-hsw-4770/igt@dmabuf@all@dma_fence.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20323/fi-hsw-4770/igt@dmabuf@all@dma_fence.html
- fi-bwr-2160:[PASS][11] -> [INCOMPLETE][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-bwr-2160/igt@dmabuf@all@dma_fence.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20323/fi-bwr-2160/igt@dmabuf@all@dma_fence.html

  * igt@runner@aborted:
- fi-ilk-650: NOTRUN -> [FAIL][13]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20323/fi-ilk-650/igt@run...@aborted.html
- fi-snb-2520m:   NOTRUN -> [FAIL][14]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20323/fi-snb-2520m/igt@run...@aborted.html
- fi-ivb-3770:NOTRUN -> [FAIL][15]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20323/fi-ivb-3770/igt@run...@aborted.html
- fi-elk-e7500:   NOTRUN -> [FAIL][16]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20323/fi-elk-e7500/igt@run...@aborted.html

  
 Suppressed 

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

  * igt@dmabuf@all@dma_fence:
- {fi-hsw-gt1}:   [PASS][17] -> [INCOMPLETE][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-hsw-gt1/igt@dmabuf@all@dma_fence.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20323/fi-hsw-gt1/igt@dmabuf@all@dma_fence.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@dmabuf@all@dma_fence:
- fi-pnv-d510:[PASS][19] -> [INCOMPLETE][20] ([i915#299])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-pnv-d510/igt@dmabuf@all@dma_fence.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20323/fi-pnv-d510/igt@dmabuf@all@dma_fence.html

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

  * igt@runner@aborted:
- fi-pnv-d510:NOTRUN -> [FAIL][23] ([i915#2403] / [i915#2505] / 
[i915#2722])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20323/fi-pnv-d510/igt@run...@aborted.html
- fi-bwr-2160:NOTRUN -> [FAIL][24] ([i915#2505] / [i915#2722])
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20323/fi-bwr-2160/igt@run...@aborted.html
- fi-hsw-4770:NOTRUN -> [FAIL][25] ([i915#2505] / [i915#2722])
   [25]: 

[Intel-gfx] ✗ Fi.CI.BUILD: warning for dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence

2021-06-09 Thread Patchwork
== Series Details ==

Series: dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence
URL   : https://patchwork.freedesktop.org/series/91299/
State : warning

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  MODPOST modules-only.symvers
ERROR: modpost: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:150: recipe for target 'modules-only.symvers' failed
make[1]: *** [modules-only.symvers] Error 1
make[1]: *** Deleting file 'modules-only.symvers'
Makefile:1759: recipe for target 'modules' failed
make: *** [modules] Error 2

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence

2021-06-09 Thread Patchwork
== Series Details ==

Series: dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence
URL   : https://patchwork.freedesktop.org/series/91299/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./include/drm/drm_syncobj.h:110:50:expected struct dma_fence *fence
+./include/drm/drm_syncobj.h:110:50:expected struct dma_fence *fence
+./include/drm/drm_syncobj.h:110:50:expected struct dma_fence *fence
+./include/drm/drm_syncobj.h:110:50:expected struct dma_fence *fence
+./include/drm/drm_syncobj.h:110:50:expected struct dma_fence *fence
+./include/drm/drm_syncobj.h:110:50:expected struct dma_fence *fence
+./include/drm/drm_syncobj.h:110:50:got struct dma_fence [noderef] __rcu 
*fence
+./include/drm/drm_syncobj.h:110:50:got struct dma_fence [noderef] __rcu 
*fence
+./include/drm/drm_syncobj.h:110:50:got struct dma_fence [noderef] __rcu 
*fence
+./include/drm/drm_syncobj.h:110:50:got struct dma_fence [noderef] __rcu 
*fence
+./include/drm/drm_syncobj.h:110:50:got struct dma_fence [noderef] __rcu 
*fence
+./include/drm/drm_syncobj.h:110:50:got struct dma_fence [noderef] __rcu 
*fence
+./include/drm/drm_syncobj.h:110:50: warning: incorrect type in argument 1 
(different address spaces)
+./include/drm/drm_syncobj.h:110:50: warning: incorrect type in argument 1 
(different address spaces)
+./include/drm/drm_syncobj.h:110:50: warning: incorrect type in argument 1 
(different address spaces)
+./include/drm/drm_syncobj.h:110:50: warning: incorrect type in argument 1 
(different address spaces)
+./include/drm/drm_syncobj.h:110:50: warning: incorrect type in argument 1 
(different address spaces)
+./include/drm/drm_syncobj.h:110:50: warning: incorrect type in argument 1 
(different address spaces)


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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence

2021-06-09 Thread Patchwork
== Series Details ==

Series: dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence
URL   : https://patchwork.freedesktop.org/series/91299/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
c4dee3b6c2a0 drm/i915: Move intel_engine_free_request_pool to i915_request.c
a566e7614443 drm/i915: Use a simpler scheme for caching i915_request
-:98: WARNING:REPEATED_WORD: Possible repeated word: 'we'
#98: FILE: drivers/gpu/drm/i915/i915_request.c:930:
+* (this can happen when switching to a kernel context), we we want

total: 0 errors, 1 warnings, 0 checks, 84 lines checked
425024c191b4 drm/i915: Stop using SLAB_TYPESAFE_BY_RCU for i915_request
-:9: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 0eafec6d3244 ("drm/i915: Enable 
lockless lookup of request tracking via RCU")'
#9: 
Ever since 0eafec6d3244 ("drm/i915: Enable lockless lookup of request

total: 1 errors, 0 warnings, 0 checks, 109 lines checked
6f5eaff5c611 dma-buf: Stop using SLAB_TYPESAFE_BY_RCU in selftests
3515a69ecbaf DONOTMERGE: dma-buf: Get rid of dma_fence_get_rcu_safe


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


[Intel-gfx] [PATCH 5/5] DONOTMERGE: dma-buf: Get rid of dma_fence_get_rcu_safe

2021-06-09 Thread Jason Ekstrand
This helper existed to handle the weird corner-cases caused by using
SLAB_TYPESAFE_BY_RCU for backing dma_fence.  Now that no one is using
that anymore (i915 was the only real user), dma_fence_get_rcu is
sufficient.  The one slightly annoying thing we have to deal with here
is that dma_fence_get_rcu_safe did an rcu_dereference as well as a
SLAB_TYPESAFE_BY_RCU-safe dma_fence_get_rcu.  This means each call site
ends up being 3 lines instead of 1.

Signed-off-by: Jason Ekstrand 
Cc: Daniel Vetter 
Cc: Christian König 
Cc: Matthew Auld 
Cc: Maarten Lankhorst 
---
 drivers/dma-buf/dma-fence-chain.c |  8 ++--
 drivers/dma-buf/dma-resv.c|  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c |  4 +-
 drivers/gpu/drm/i915/i915_active.h|  4 +-
 drivers/gpu/drm/i915/i915_vma.c   |  4 +-
 include/drm/drm_syncobj.h |  4 +-
 include/linux/dma-fence.h | 50 ---
 include/linux/dma-resv.h  |  4 +-
 8 files changed, 23 insertions(+), 59 deletions(-)

diff --git a/drivers/dma-buf/dma-fence-chain.c 
b/drivers/dma-buf/dma-fence-chain.c
index 7d129e68ac701..46dfc7d94d8ed 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -15,15 +15,17 @@ static bool dma_fence_chain_enable_signaling(struct 
dma_fence *fence);
  * dma_fence_chain_get_prev - use RCU to get a reference to the previous fence
  * @chain: chain node to get the previous node from
  *
- * Use dma_fence_get_rcu_safe to get a reference to the previous fence of the
- * chain node.
+ * Use rcu_dereference and dma_fence_get_rcu to get a reference to the
+ * previous fence of the chain node.
  */
 static struct dma_fence *dma_fence_chain_get_prev(struct dma_fence_chain 
*chain)
 {
struct dma_fence *prev;
 
rcu_read_lock();
-   prev = dma_fence_get_rcu_safe(>prev);
+   prev = rcu_dereference(chain->prev);
+   if (prev)
+   prev = dma_fence_get_rcu(prev);
rcu_read_unlock();
return prev;
 }
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index f26c71747d43a..cfe0db3cca292 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -376,7 +376,9 @@ int dma_resv_copy_fences(struct dma_resv *dst, struct 
dma_resv *src)
dst_list = NULL;
}
 
-   new = dma_fence_get_rcu_safe(>fence_excl);
+   new = rcu_dereference(src->fence_excl);
+   if (new)
+   new = dma_fence_get_rcu(new);
rcu_read_unlock();
 
src_list = dma_resv_shared_list(dst);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 72d9b92b17547..0aeb6117f3893 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -161,7 +161,9 @@ int amdgpu_fence_emit(struct amdgpu_ring *ring, struct 
dma_fence **f,
struct dma_fence *old;
 
rcu_read_lock();
-   old = dma_fence_get_rcu_safe(ptr);
+   old = rcu_dereference(*ptr);
+   if (old)
+   old = dma_fence_get_rcu(old);
rcu_read_unlock();
 
if (old) {
diff --git a/drivers/gpu/drm/i915/i915_active.h 
b/drivers/gpu/drm/i915/i915_active.h
index d0feda68b874f..bd89cfc806ca5 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -103,7 +103,9 @@ i915_active_fence_get(struct i915_active_fence *active)
struct dma_fence *fence;
 
rcu_read_lock();
-   fence = dma_fence_get_rcu_safe(>fence);
+   fence = rcu_dereference(active->fence);
+   if (fence)
+   fence = dma_fence_get_rcu(fence);
rcu_read_unlock();
 
return fence;
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 0f227f28b2802..ed0388d99197e 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -351,7 +351,9 @@ int i915_vma_wait_for_bind(struct i915_vma *vma)
struct dma_fence *fence;
 
rcu_read_lock();
-   fence = dma_fence_get_rcu_safe(>active.excl.fence);
+   fence = rcu_dereference(vma->active.excl.fence);
+   if (fence)
+   fence = dma_fence_get_rcu(fence);
rcu_read_unlock();
if (fence) {
err = dma_fence_wait(fence, MAX_SCHEDULE_TIMEOUT);
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index 6cf7243a1dc5e..6c45d52988bcc 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -105,7 +105,9 @@ drm_syncobj_fence_get(struct drm_syncobj *syncobj)
struct dma_fence *fence;
 
rcu_read_lock();
-   fence = dma_fence_get_rcu_safe(>fence);
+   fence = rcu_dereference(syncobj->fence);
+   if (fence)
+   fence = dma_fence_get_rcu(syncobj->fence);

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

2021-06-09 Thread Rodrigo Vivi
Hi Dave and Daniel,

Here goes the last pull request towards 5.14.
Mostly it is ADL-P enabling related and a few other things.

drm-intel-next-2021-06-09:

Cross-subsystem Changes:

-  x86/gpu: add JasperLake to gen11 early quirks
  (Although the patch lacks the Ack info, it has been Acked by Borislav)

Driver Changes:

- General DMC improves (Anusha)
- More ADL-P enabling (Vandita, Matt, Jose, Mika, Anusha, Imre, Lucas, Jani, 
Manasi, Ville, Stanislav)
- Introduce MBUS relative dbuf offset (Ville)
- PSR fixes and improvements (Gwan, Jose, Ville)
- Re-enable LTTPR non-transparent LT mode for DPCD_REV < 1.4 (Ville)
- Remove duplicated declarations (Shaokun, Wan)
- Check HDMI sink deep color capabilities during .mode_valid (Ville)
- Fix display flicker screan related to console and FBC (Chris)
- Remaining conversions of GRAPHICS_VER (Lucas)
- Drop invalid FIXME (Jose)
- Fix bigjoiner check in dsc_disable (Vandita)

Thanks,
Rodrigo.

The following changes since commit 9a91e5e0af5e03940d0eec72c36364a1701de240:

  Merge tag 'amd-drm-next-5.14-2021-05-21' of 
https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-05-21 15:59:05 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2021-06-09

for you to fetch changes up to 0d6695b112762aa7aad28c46e65561389b6f50d6:

  drm/i915/adl_p: Same slices mask is not same Dbuf state (2021-06-09 17:24:58 
+0300)


Cross-subsystem Changes:

-  x86/gpu: add JasperLake to gen11 early quirks
  (Although the patch lacks the Ack info, it has been Acked by Borislav)

Driver Changes:

- General DMC improves (Anusha)
- More ADL-P enabling (Vandita, Matt, Jose, Mika, Anusha, Imre, Lucas, Jani, 
Manasi, Ville, Stanislav)
- Introduce MBUS relative dbuf offset (Ville)
- PSR fixes and improvements (Gwan, Jose, Ville)
- Re-enable LTTPR non-transparent LT mode for DPCD_REV < 1.4 (Ville)
- Remove duplicated declarations (Shaokun, Wan)
- Check HDMI sink deep color capabilities during .mode_valid (Ville)
- Fix display flicker screan related to console and FBC (Chris)
- Remaining conversions of GRAPHICS_VER (Lucas)
- Drop invalid FIXME (Jose)
- Fix bigjoiner check in dsc_disable (Vandita)


Anusha Srivatsa (13):
  drm/i915/dmc: s/intel_csr/intel_dmc
  drm/i915/dmc: s/HAS_CSR/HAS_DMC
  drm/i915/dmc: Rename macro names containing csr
  drm/i915/dmc: Rename functions names having "csr"
  drm/i915/dmc: s/intel_csr.c/intel_dmc.c and s/intel_csr.h/intel_dmc.h
  drm/i915/adl_p: Setup ports/phys
  drm/i915/adl_p: Add PLL Support
  drm/i915/adlp: Add PIPE_MISC2 programming
  drm/i915/adl_p: Update memory bandwidth parameters
  drm/i915/gvt: Add missing macro name changes
  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

Chris Wilson (1):
  drm/i915/display: relax 2big checking around initial fb

Gwan-gyeong Mun (4):
  drm/i915/display: Replace dc3co_enabled with dc3co_exitline on intel_psr 
struct
  drm/i915/display: Add PSR interrupt error check function
  drm/i915/display: Remove a redundant function argument from 
intel_psr_enable_source()
  drm/i915/display: Introduce new intel_psr_pause/resume function

Imre Deak (9):
  drm/i915/adl_p: Program DP/HDMI link rate to DDI_BUF_CTL
  drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4
  drm/i915/adlp: Require DPT FB CCS color planes to be 2MB aligned
  drm/i915/adlp: Fix GEM VM asserts for DPT VMs
  drm/i915/debugfs: Print remap info for DPT VMAs as well
  drm/i915/adlp: Add missing TBT AUX -> PW#2 power domain dependencies
  drm/i915/ddi: Flush encoder power domain ref puts during driver unload
  drm/i915: Fix incorrect assert about pending power domain async-put work
  drm/i915/adlp: Fix AUX power well -> PHY mapping

Jani Nikula (1):
  drm/i915/adl_p: enable MSO on pipe B

José Roberto de Souza (10):
  drm/i915/adl_p: Implement TC sequences
  drm/i915/adl_p: Don't config MBUS and DBUF during display initialization
  drm/i915/display/adl_p: Drop earlier return in tc_has_modular_fia()
  drm/i915/adl_p: Handle TC cold
  drm/i915: WA for zero memory channel
  drm/i915/display/adl_p: Allow DC3CO in pipe and port B
  drm/i915/display/adl_p: Disable PSR2
  drm/i915/display: Fix fastsets involving PSR
  drm/i915/display: Allow fastsets when DP_SDP_VSC infoframe do not match 
with PSR enabled
  drm/i915/display: Drop FIXME about turn off infoframes

Lucas De Marchi (5):
  drm/i915/display: fix typo when returning table
  drm/i915/gvt: replace IS_GEN and friends with GRAPHICS_VER
  drm/i915/display: replace IS_GEN() in commented code
  drm/i915: replace IS_GEN and friends with GRAPHICS_VER
  

[Intel-gfx] [PATCH 4/5] dma-buf: Stop using SLAB_TYPESAFE_BY_RCU in selftests

2021-06-09 Thread Jason Ekstrand
The only real-world user of SLAB_TYPESAFE_BY_RCU was i915 and it doesn't
use that anymore so there's no need to be testing it in selftests.

Signed-off-by: Jason Ekstrand 
Cc: Daniel Vetter 
Cc: Christian König 
Cc: Matthew Auld 
Cc: Maarten Lankhorst 
---
 drivers/dma-buf/st-dma-fence-chain.c | 24 
 drivers/dma-buf/st-dma-fence.c   | 27 +--
 2 files changed, 9 insertions(+), 42 deletions(-)

diff --git a/drivers/dma-buf/st-dma-fence-chain.c 
b/drivers/dma-buf/st-dma-fence-chain.c
index 9525f7f561194..73010184559fe 100644
--- a/drivers/dma-buf/st-dma-fence-chain.c
+++ b/drivers/dma-buf/st-dma-fence-chain.c
@@ -19,36 +19,27 @@
 
 #define CHAIN_SZ (4 << 10)
 
-static struct kmem_cache *slab_fences;
-
-static inline struct mock_fence {
+struct mock_fence {
struct dma_fence base;
spinlock_t lock;
-} *to_mock_fence(struct dma_fence *f) {
-   return container_of(f, struct mock_fence, base);
-}
+};
 
 static const char *mock_name(struct dma_fence *f)
 {
return "mock";
 }
 
-static void mock_fence_release(struct dma_fence *f)
-{
-   kmem_cache_free(slab_fences, to_mock_fence(f));
-}
-
 static const struct dma_fence_ops mock_ops = {
.get_driver_name = mock_name,
.get_timeline_name = mock_name,
-   .release = mock_fence_release,
+   .release = dma_fence_free,
 };
 
 static struct dma_fence *mock_fence(void)
 {
struct mock_fence *f;
 
-   f = kmem_cache_alloc(slab_fences, GFP_KERNEL);
+   f = kmalloc(sizeof(*f), GFP_KERNEL);
if (!f)
return NULL;
 
@@ -701,14 +692,7 @@ int dma_fence_chain(void)
pr_info("sizeof(dma_fence_chain)=%zu\n",
sizeof(struct dma_fence_chain));
 
-   slab_fences = KMEM_CACHE(mock_fence,
-SLAB_TYPESAFE_BY_RCU |
-SLAB_HWCACHE_ALIGN);
-   if (!slab_fences)
-   return -ENOMEM;
-
ret = subtests(tests, NULL);
 
-   kmem_cache_destroy(slab_fences);
return ret;
 }
diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-fence.c
index c8a12d7ad71ab..ca98cb0b9525b 100644
--- a/drivers/dma-buf/st-dma-fence.c
+++ b/drivers/dma-buf/st-dma-fence.c
@@ -14,25 +14,16 @@
 
 #include "selftest.h"
 
-static struct kmem_cache *slab_fences;
-
-static struct mock_fence {
+struct mock_fence {
struct dma_fence base;
struct spinlock lock;
-} *to_mock_fence(struct dma_fence *f) {
-   return container_of(f, struct mock_fence, base);
-}
+};
 
 static const char *mock_name(struct dma_fence *f)
 {
return "mock";
 }
 
-static void mock_fence_release(struct dma_fence *f)
-{
-   kmem_cache_free(slab_fences, to_mock_fence(f));
-}
-
 struct wait_cb {
struct dma_fence_cb cb;
struct task_struct *task;
@@ -77,14 +68,14 @@ static const struct dma_fence_ops mock_ops = {
.get_driver_name = mock_name,
.get_timeline_name = mock_name,
.wait = mock_wait,
-   .release = mock_fence_release,
+   .release = dma_fence_free,
 };
 
 static struct dma_fence *mock_fence(void)
 {
struct mock_fence *f;
 
-   f = kmem_cache_alloc(slab_fences, GFP_KERNEL);
+   f = kmalloc(sizeof(*f), GFP_KERNEL);
if (!f)
return NULL;
 
@@ -463,7 +454,7 @@ static int thread_signal_callback(void *arg)
 
rcu_read_lock();
do {
-   f2 = dma_fence_get_rcu_safe(>fences[!t->id]);
+   f2 = dma_fence_get_rcu(t->fences[!t->id]);
} while (!f2 && !kthread_should_stop());
rcu_read_unlock();
 
@@ -563,15 +554,7 @@ int dma_fence(void)
 
pr_info("sizeof(dma_fence)=%zu\n", sizeof(struct dma_fence));
 
-   slab_fences = KMEM_CACHE(mock_fence,
-SLAB_TYPESAFE_BY_RCU |
-SLAB_HWCACHE_ALIGN);
-   if (!slab_fences)
-   return -ENOMEM;
-
ret = subtests(tests, NULL);
 
-   kmem_cache_destroy(slab_fences);
-
return ret;
 }
-- 
2.31.1

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


[Intel-gfx] [PATCH 3/5] drm/i915: Stop using SLAB_TYPESAFE_BY_RCU for i915_request

2021-06-09 Thread Jason Ekstrand
Ever since 0eafec6d3244 ("drm/i915: Enable lockless lookup of request
tracking via RCU"), the i915 driver has used SLAB_TYPESAFE_BY_RCU (it
was called SLAB_DESTROY_BY_RCU at the time) in order to allow RCU on
i915_request.  As nifty as SLAB_TYPESAFE_BY_RCU may be, it comes with
some serious disclaimers.  In particular, objects can get recycled while
RCU readers are still in-flight.  This can be ok if everyone who touches
these objects knows about the disclaimers and is careful.  However,
because we've chosen to use SLAB_TYPESAFE_BY_RCU for i915_request and
because i915_request contains a dma_fence, we've leaked
SLAB_TYPESAFE_BY_RCU and its whole pile of disclaimers to every driver
in the kernel which may consume a dma_fence.

We've tried to keep it somewhat contained by doing most of the hard work
to prevent access of recycled objects via dma_fence_get_rcu_safe().
However, a quick grep of kernel sources says that, of the 30 instances
of dma_fence_get_rcu*, only 11 of them use dma_fence_get_rcu_safe().
It's likely there bear traps in DRM and related subsystems just waiting
for someone to accidentally step in them.

This commit gets stops us using SLAB_TYPESAFE_BY_RCU for i915_request
and, instead, does an RCU-safe slab free via rcu_call().  This should
let us keep most of the perf benefits of slab allocation while avoiding
the bear traps inherent in SLAB_TYPESAFE_BY_RCU.

Signed-off-by: Jason Ekstrand 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Christian König 
Cc: Dave Airlie 
Cc: Matthew Auld 
Cc: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_request.c | 76 -
 1 file changed, 43 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index e531c74f0b0e2..55fa938126100 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -111,9 +111,44 @@ void intel_engine_free_request_pool(struct intel_engine_cs 
*engine)
if (!engine->request_pool)
return;
 
+   /*
+* It's safe to free this right away because we always put a fresh
+* i915_request in the cache that's never been touched by an RCU
+* reader.
+*/
kmem_cache_free(global.slab_requests, engine->request_pool);
 }
 
+static void __i915_request_free(struct rcu_head *head)
+{
+   struct i915_request *rq = container_of(head, typeof(*rq), fence.rcu);
+
+   kmem_cache_free(global.slab_requests, rq);
+}
+
+static void i915_request_free_rcu(struct i915_request *rq)
+{
+   /*
+* Because we're on a slab allocator, memory may be re-used the
+* moment we free it.  There is no kfree_rcu() equivalent for
+* slabs.  Instead, we hand-roll it here with call_rcu().  This
+* gives us all the perf benefits to slab allocation while ensuring
+* that we never release a request back to the slab until there are
+* no more readers.
+*
+* We do have to be careful, though, when calling kmem_cache_destroy()
+* as there may be outstanding free requests.  This is solved by
+* inserting an rcu_barrier() before kmem_cache_destroy().  An RCU
+* barrier is sufficient and we don't need synchronize_rcu()
+* because the call_rcu() here will wait on any outstanding RCU
+* readers and the rcu_barrier() will wait on any outstanding
+* call_rcu() callbacks.  So, if there are any readers who once had
+* valid references to a request, rcu_barrier() will end up waiting
+* on them by transitivity.
+*/
+   call_rcu(>fence.rcu, __i915_request_free);
+}
+
 static void i915_fence_release(struct dma_fence *fence)
 {
struct i915_request *rq = to_request(fence);
@@ -127,8 +162,7 @@ static void i915_fence_release(struct dma_fence *fence)
 */
i915_sw_fence_fini(>submit);
i915_sw_fence_fini(>semaphore);
-
-   kmem_cache_free(global.slab_requests, rq);
+   i915_request_free_rcu(rq);
 }
 
 const struct dma_fence_ops i915_fence_ops = {
@@ -933,35 +967,6 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp)
 */
ensure_cached_request(>engine->request_pool, gfp);
 
-   /*
-* Beware: Dragons be flying overhead.
-*
-* We use RCU to look up requests in flight. The lookups may
-* race with the request being allocated from the slab freelist.
-* That is the request we are writing to here, may be in the process
-* of being read by __i915_active_request_get_rcu(). As such,
-* we have to be very careful when overwriting the contents. During
-* the RCU lookup, we change chase the request->engine pointer,
-* read the request->global_seqno and increment the reference count.
-*
-* The reference count is incremented atomically. If it is zero,
-* the lookup knows the request is unallocated and complete. Otherwise,
-* 

[Intel-gfx] [PATCH 1/5] drm/i915: Move intel_engine_free_request_pool to i915_request.c

2021-06-09 Thread Jason Ekstrand
This appears to break encapsulation by moving an intel_engine_cs
function to a i915_request file.  However, this function is
intrinsically tied to the lifetime rules and allocation scheme of
i915_request and having it in intel_engine_cs.c leaks details of
i915_request.  We have an abstraction leak either way.  Since
i915_request's allocation scheme is far more subtle than the simple
pointer that is intel_engine_cs.request_pool, it's probably better to
keep i915_request's details to itself.

Signed-off-by: Jason Ekstrand 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Matthew Auld 
Cc: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 
 drivers/gpu/drm/i915/i915_request.c   | 7 +--
 drivers/gpu/drm/i915/i915_request.h   | 2 --
 3 files changed, 5 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 9ceddfbb1687d..df6b80ec84199 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -422,14 +422,6 @@ void intel_engines_release(struct intel_gt *gt)
}
 }
 
-void intel_engine_free_request_pool(struct intel_engine_cs *engine)
-{
-   if (!engine->request_pool)
-   return;
-
-   kmem_cache_free(i915_request_slab_cache(), engine->request_pool);
-}
-
 void intel_engines_free(struct intel_gt *gt)
 {
struct intel_engine_cs *engine;
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 1014c71cf7f52..48c5f8527854b 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -106,9 +106,12 @@ static signed long i915_fence_wait(struct dma_fence *fence,
 timeout);
 }
 
-struct kmem_cache *i915_request_slab_cache(void)
+void intel_engine_free_request_pool(struct intel_engine_cs *engine)
 {
-   return global.slab_requests;
+   if (!engine->request_pool)
+   return;
+
+   kmem_cache_free(global.slab_requests, engine->request_pool);
 }
 
 static void i915_fence_release(struct dma_fence *fence)
diff --git a/drivers/gpu/drm/i915/i915_request.h 
b/drivers/gpu/drm/i915/i915_request.h
index 270f6cd37650c..f84c38d29f988 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -300,8 +300,6 @@ static inline bool dma_fence_is_i915(const struct dma_fence 
*fence)
return fence->ops == _fence_ops;
 }
 
-struct kmem_cache *i915_request_slab_cache(void);
-
 struct i915_request * __must_check
 __i915_request_create(struct intel_context *ce, gfp_t gfp);
 struct i915_request * __must_check
-- 
2.31.1

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


[Intel-gfx] [PATCH 2/5] drm/i915: Use a simpler scheme for caching i915_request

2021-06-09 Thread Jason Ekstrand
Instead of attempting to recycle a request in to the cache when it
retires, stuff a new one in the cache every time we allocate a request
for some other reason.

Signed-off-by: Jason Ekstrand 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Matthew Auld 
Cc: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_request.c | 66 ++---
 1 file changed, 31 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 48c5f8527854b..e531c74f0b0e2 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -128,41 +128,6 @@ static void i915_fence_release(struct dma_fence *fence)
i915_sw_fence_fini(>submit);
i915_sw_fence_fini(>semaphore);
 
-   /*
-* Keep one request on each engine for reserved use under mempressure
-*
-* We do not hold a reference to the engine here and so have to be
-* very careful in what rq->engine we poke. The virtual engine is
-* referenced via the rq->context and we released that ref during
-* i915_request_retire(), ergo we must not dereference a virtual
-* engine here. Not that we would want to, as the only consumer of
-* the reserved engine->request_pool is the power management parking,
-* which must-not-fail, and that is only run on the physical engines.
-*
-* Since the request must have been executed to be have completed,
-* we know that it will have been processed by the HW and will
-* not be unsubmitted again, so rq->engine and rq->execution_mask
-* at this point is stable. rq->execution_mask will be a single
-* bit if the last and _only_ engine it could execution on was a
-* physical engine, if it's multiple bits then it started on and
-* could still be on a virtual engine. Thus if the mask is not a
-* power-of-two we assume that rq->engine may still be a virtual
-* engine and so a dangling invalid pointer that we cannot dereference
-*
-* For example, consider the flow of a bonded request through a virtual
-* engine. The request is created with a wide engine mask (all engines
-* that we might execute on). On processing the bond, the request mask
-* is reduced to one or more engines. If the request is subsequently
-* bound to a single engine, it will then be constrained to only
-* execute on that engine and never returned to the virtual engine
-* after timeslicing away, see __unwind_incomplete_requests(). Thus we
-* know that if the rq->execution_mask is a single bit, rq->engine
-* can be a physical engine with the exact corresponding mask.
-*/
-   if (is_power_of_2(rq->execution_mask) &&
-   !cmpxchg(>engine->request_pool, NULL, rq))
-   return;
-
kmem_cache_free(global.slab_requests, rq);
 }
 
@@ -869,6 +834,29 @@ static void retire_requests(struct intel_timeline *tl)
break;
 }
 
+static void
+ensure_cached_request(struct i915_request **rsvd, gfp_t gfp)
+{
+   struct i915_request *rq;
+
+   /* Don't try to add to the cache if we don't allow blocking.  That
+* just increases the chance that the actual allocation will fail.
+*/
+   if (gfpflags_allow_blocking(gfp))
+   return;
+
+   if (READ_ONCE(rsvd))
+   return;
+
+   rq = kmem_cache_alloc(global.slab_requests,
+ gfp | __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
+   if (!rq)
+   return; /* Oops but nothing we can do */
+
+   if (cmpxchg(rsvd, NULL, rq))
+   kmem_cache_free(global.slab_requests, rq);
+}
+
 static noinline struct i915_request *
 request_alloc_slow(struct intel_timeline *tl,
   struct i915_request **rsvd,
@@ -937,6 +925,14 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp)
/* Check that the caller provided an already pinned context */
__intel_context_pin(ce);
 
+   /* Before we do anything, try to make sure we have at least one
+* request in the engine's cache.  If we get here with GPF_NOWAIT
+* (this can happen when switching to a kernel context), we we want
+* to try very hard to not fail and we fall back to this cache.
+* Top it off with a fresh request whenever it's empty.
+*/
+   ensure_cached_request(>engine->request_pool, gfp);
+
/*
 * Beware: Dragons be flying overhead.
 *
-- 
2.31.1

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


[Intel-gfx] [PATCH 0/5] dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence

2021-06-09 Thread Jason Ekstrand
Ever since 0eafec6d3244 ("drm/i915: Enable lockless lookup of request
tracking via RCU"), the i915 driver has used SLAB_TYPESAFE_BY_RCU (it
was called SLAB_DESTROY_BY_RCU at the time) in order to allow RCU on
i915_request.  As nifty as SLAB_TYPESAFE_BY_RCU may be, it comes with
some serious disclaimers.  In particular, objects can get recycled while
RCU readers are still in-flight.  This can be ok if everyone who touches
these objects knows about the disclaimers and is careful.  However,
because we've chosen to use SLAB_TYPESAFE_BY_RCU for i915_request and
because i915_request contains a dma_fence, we've leaked
SLAB_TYPESAFE_BY_RCU and its whole pile of disclaimers to every driver
in the kernel which may consume a dma_fence.

We've tried to keep it somewhat contained by doing most of the hard work
to prevent access of recycled objects via dma_fence_get_rcu_safe().
However, a quick grep of kernel sources says that, of the 30 instances
of dma_fence_get_rcu*, only 11 of them use dma_fence_get_rcu_safe().
It's likely there bear traps in DRM and related subsystems just waiting
for someone to accidentally step in them.

This patch series stops us using SLAB_TYPESAFE_BY_RCU for i915_request
and, instead, does an RCU-safe slab free via rcu_call().  This should
let us keep most of the perf benefits of slab allocation while avoiding
the bear traps inherent in SLAB_TYPESAFE_BY_RCU.  It then removes support
for SLAB_TYPESAFE_BY_RCU from dma_fence entirely.

Note: The last patch is labled DONOTMERGE.  This was at Daniel Vetter's
request as we may want to let this bake for a couple releases before we
rip out dma_fence_get_rcu_safe entirely.

Signed-off-by: Jason Ekstrand 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Christian König 
Cc: Dave Airlie 
Cc: Matthew Auld 
Cc: Maarten Lankhorst 

Jason Ekstrand (5):
  drm/i915: Move intel_engine_free_request_pool to i915_request.c
  drm/i915: Use a simpler scheme for caching i915_request
  drm/i915: Stop using SLAB_TYPESAFE_BY_RCU for i915_request
  dma-buf: Stop using SLAB_TYPESAFE_BY_RCU in selftests
  DONOTMERGE: dma-buf: Get rid of dma_fence_get_rcu_safe

 drivers/dma-buf/dma-fence-chain.c |   8 +-
 drivers/dma-buf/dma-resv.c|   4 +-
 drivers/dma-buf/st-dma-fence-chain.c  |  24 +---
 drivers/dma-buf/st-dma-fence.c|  27 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c |   4 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |   8 --
 drivers/gpu/drm/i915/i915_active.h|   4 +-
 drivers/gpu/drm/i915/i915_request.c   | 147 --
 drivers/gpu/drm/i915/i915_request.h   |   2 -
 drivers/gpu/drm/i915/i915_vma.c   |   4 +-
 include/drm/drm_syncobj.h |   4 +-
 include/linux/dma-fence.h |  50 
 include/linux/dma-resv.h  |   4 +-
 13 files changed, 110 insertions(+), 180 deletions(-)

-- 
2.31.1

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


[Intel-gfx] [PATCH v2 2/7] drm/probe-helper: add drm_kms_helper_connector_hotplug_event

2021-06-09 Thread Simon Ser
This function is the same as drm_kms_helper_hotplug_event, but takes
a connector instead of a device.

Signed-off-by: Simon Ser 
---
 drivers/gpu/drm/drm_probe_helper.c | 23 +++
 include/drm/drm_probe_helper.h |  1 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index e7e1ee2aa352..8cc673267cba 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -604,6 +604,9 @@ EXPORT_SYMBOL(drm_helper_probe_single_connector_modes);
  *
  * This function must be called from process context with no mode
  * setting locks held.
+ *
+ * If only a single connector has changed, consider calling
+ * drm_kms_helper_connector_hotplug_event() instead.
  */
 void drm_kms_helper_hotplug_event(struct drm_device *dev)
 {
@@ -616,6 +619,26 @@ void drm_kms_helper_hotplug_event(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_kms_helper_hotplug_event);
 
+/**
+ * drm_kms_helper_connector_hotplug_event - fire off a KMS connector hotplug 
event
+ * @connector: drm_connector which has changed
+ *
+ * This is the same as drm_kms_helper_hotplug_event(), except it fires a more
+ * fine-grained uevent for a single connector.
+ */
+void drm_kms_helper_connector_hotplug_event(struct drm_connector *connector)
+{
+   struct drm_device *dev = connector->dev;
+
+   /* send a uevent + call fbdev */
+   drm_sysfs_connector_hotplug_event(connector);
+   if (dev->mode_config.funcs->output_poll_changed)
+   dev->mode_config.funcs->output_poll_changed(dev);
+
+   drm_client_dev_hotplug(dev);
+}
+EXPORT_SYMBOL(drm_kms_helper_connector_hotplug_event);
+
 static void output_poll_execute(struct work_struct *work)
 {
struct delayed_work *delayed_work = to_delayed_work(work);
diff --git a/include/drm/drm_probe_helper.h b/include/drm/drm_probe_helper.h
index 8d3ed2834d34..733147ea89be 100644
--- a/include/drm/drm_probe_helper.h
+++ b/include/drm/drm_probe_helper.h
@@ -19,6 +19,7 @@ void drm_kms_helper_poll_init(struct drm_device *dev);
 void drm_kms_helper_poll_fini(struct drm_device *dev);
 bool drm_helper_hpd_irq_event(struct drm_device *dev);
 void drm_kms_helper_hotplug_event(struct drm_device *dev);
+void drm_kms_helper_connector_hotplug_event(struct drm_connector *connector);
 
 void drm_kms_helper_poll_disable(struct drm_device *dev);
 void drm_kms_helper_poll_enable(struct drm_device *dev);
-- 
2.31.1


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


[Intel-gfx] [PATCH v2 6/7] i915/display/dp: send a more fine-grained link-status uevent

2021-06-09 Thread Simon Ser
When link-status changes, send a hotplug uevent which contains the
connector and property ID. That way, user-space can more easily
figure out that only the link-status property of this connector has
been updated.

Signed-off-by: Simon Ser 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5c983044..0ce44a97dd14 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5276,6 +5276,8 @@ static void intel_dp_modeset_retry_work_fn(struct 
work_struct *work)
mutex_unlock(>dev->mode_config.mutex);
/* Send Hotplug uevent so userspace can reprobe */
drm_kms_helper_hotplug_event(connector->dev);
+   drm_sysfs_connector_status_event(connector,
+
connector->dev->mode_config.link_status_property);
 }
 
 bool
-- 
2.31.1


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


[Intel-gfx] [PATCH v2 7/7] drm/connector: add ref to drm_connector_get in iter docs

2021-06-09 Thread Simon Ser
Mention that connectors need to be referenced manually if they are
to be accessed after the iteration has progressed or ended.

Signed-off-by: Simon Ser 
---
 include/drm/drm_connector.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 714d1a01c065..c1af1e4ca560 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1735,6 +1735,11 @@ void drm_mode_put_tile_group(struct drm_device *dev,
  * drm_connector_list_iter_begin(), drm_connector_list_iter_end() and
  * drm_connector_list_iter_next() respectively the convenience macro
  * drm_for_each_connector_iter().
+ *
+ * Note that the return value of drm_connector_list_iter_next() is only valid
+ * up to the next drm_connector_list_iter_next() or
+ * drm_connector_list_iter_end() call. If you want to use the connector later,
+ * then you need to grab your own reference first using drm_connector_get().
  */
 struct drm_connector_list_iter {
 /* private: */
-- 
2.31.1


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


[Intel-gfx] [PATCH v2 5/7] drm/probe-helper: use drm_kms_helper_connector_hotplug_event

2021-06-09 Thread Simon Ser
If an hotplug event only updates a single connector, use
drm_kms_helper_connector_hotplug_event instead of
drm_kms_helper_hotplug_event.

Signed-off-by: Simon Ser 
---
 drivers/gpu/drm/drm_probe_helper.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 8cc673267cba..f4130c1a90e2 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -843,7 +843,7 @@ EXPORT_SYMBOL(drm_kms_helper_poll_fini);
  */
 bool drm_helper_hpd_irq_event(struct drm_device *dev)
 {
-   struct drm_connector *connector;
+   struct drm_connector *connector, *changed_connector = NULL;
struct drm_connector_list_iter conn_iter;
enum drm_connector_status old_status;
bool changed = false;
@@ -883,16 +883,27 @@ bool drm_helper_hpd_irq_event(struct drm_device *dev)
 * Check if epoch counter had changed, meaning that we need
 * to send a uevent.
 */
-   if (old_epoch_counter != connector->epoch_counter)
+   if (old_epoch_counter != connector->epoch_counter) {
+   if (changed) {
+   if (changed_connector)
+   drm_connector_put(changed_connector);
+   changed_connector = NULL;
+   } else {
+   drm_connector_get(connector);
+   changed_connector = connector;
+   }
changed = true;
+   }
 
}
drm_connector_list_iter_end(_iter);
mutex_unlock(>mode_config.mutex);
 
-   if (changed) {
+   if (changed_connector) {
+   drm_kms_helper_connector_hotplug_event(changed_connector);
+   drm_connector_put(changed_connector);
+   } else if (changed) {
drm_kms_helper_hotplug_event(dev);
-   DRM_DEBUG_KMS("Sent hotplug event\n");
}
 
return changed;
-- 
2.31.1


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


[Intel-gfx] [PATCH v2 4/7] amdgpu: use drm_kms_helper_connector_hotplug_event

2021-06-09 Thread Simon Ser
When updating a single connector, use
drm_kms_helper_connector_hotplug_event instead of
drm_kms_helper_hotplug_event.

Signed-off-by: Simon Ser 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 3267eb2e35dd..4b91534ff324 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2638,7 +2638,7 @@ static void handle_hpd_irq(void *param)
drm_modeset_unlock_all(dev);
 
if (aconnector->base.force == DRM_FORCE_UNSPECIFIED)
-   drm_kms_helper_hotplug_event(dev);
+   drm_kms_helper_connector_hotplug_event(connector);
 
} else if (dc_link_detect(aconnector->dc_link, DETECT_REASON_HPD)) {
if (new_connection_type == dc_connection_none &&
@@ -2652,7 +2652,7 @@ static void handle_hpd_irq(void *param)
drm_modeset_unlock_all(dev);
 
if (aconnector->base.force == DRM_FORCE_UNSPECIFIED)
-   drm_kms_helper_hotplug_event(dev);
+   drm_kms_helper_connector_hotplug_event(connector);
}
mutex_unlock(>hpd_lock);
 
@@ -2805,7 +2805,7 @@ static void handle_hpd_rx_irq(void *param)
dm_restore_drm_connector_state(dev, connector);
drm_modeset_unlock_all(dev);
 
-   drm_kms_helper_hotplug_event(dev);
+   drm_kms_helper_connector_hotplug_event(connector);
} else if (dc_link_detect(dc_link, DETECT_REASON_HPDRX)) {
 
if (aconnector->fake_enable)
@@ -2818,7 +2818,7 @@ static void handle_hpd_rx_irq(void *param)
dm_restore_drm_connector_state(dev, connector);
drm_modeset_unlock_all(dev);
 
-   drm_kms_helper_hotplug_event(dev);
+   drm_kms_helper_connector_hotplug_event(connector);
}
}
 #ifdef CONFIG_DRM_AMD_DC_HDCP
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 9fbbd0159119..221242b6e528 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -1200,7 +1200,7 @@ static ssize_t trigger_hotplug(struct file *f, const char 
__user *buf,
dm_restore_drm_connector_state(dev, connector);
drm_modeset_unlock_all(dev);
 
-   drm_kms_helper_hotplug_event(dev);
+   drm_kms_helper_connector_hotplug_event(connector);
} else if (param[0] == 0) {
if (!aconnector->dc_link)
goto unlock;
@@ -1222,7 +1222,7 @@ static ssize_t trigger_hotplug(struct file *f, const char 
__user *buf,
dm_restore_drm_connector_state(dev, connector);
drm_modeset_unlock_all(dev);
 
-   drm_kms_helper_hotplug_event(dev);
+   drm_kms_helper_connector_hotplug_event(connector);
}
 
 unlock:
-- 
2.31.1


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


[Intel-gfx] [PATCH v2 3/7] drm/connector: use drm_sysfs_connector_hotplug_event

2021-06-09 Thread Simon Ser
In drm_connector_register, use drm_sysfs_connector_hotplug_event
instead of drm_sysfs_hotplug_event, because the hotplug event
only updates a single connector.

Signed-off-by: Simon Ser 
---
 drivers/gpu/drm/drm_connector.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index da39e7ff6965..76930e0b8949 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -530,7 +530,7 @@ int drm_connector_register(struct drm_connector *connector)
connector->registration_state = DRM_CONNECTOR_REGISTERED;
 
/* Let userspace know we have a new connector */
-   drm_sysfs_hotplug_event(connector->dev);
+   drm_sysfs_connector_hotplug_event(connector);
 
goto unlock;
 
-- 
2.31.1


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


[Intel-gfx] [PATCH v2 1/7] drm/sysfs: introduce drm_sysfs_connector_hotplug_event

2021-06-09 Thread Simon Ser
This function sends a hotplug uevent with a CONNECTOR property.

Signed-off-by: Simon Ser 
---
 drivers/gpu/drm/drm_sysfs.c | 25 +
 include/drm/drm_sysfs.h |  1 +
 2 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 968a9560b4aa..8423e44c3035 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -343,6 +343,31 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_sysfs_hotplug_event);
 
+/**
+ * drm_sysfs_connector_hotplug_event - generate a DRM uevent for any connector
+ * change
+ * @connector: connector which has changed
+ *
+ * Send a uevent for the DRM connector specified by @connector. This will send
+ * a uevent with the properties HOTPLUG=1 and CONNECTOR.
+ */
+void drm_sysfs_connector_hotplug_event(struct drm_connector *connector)
+{
+   struct drm_device *dev = connector->dev;
+   char hotplug_str[] = "HOTPLUG=1", conn_id[21];
+   char *envp[] = { hotplug_str, conn_id, NULL };
+
+   snprintf(conn_id, sizeof(conn_id),
+"CONNECTOR=%u", connector->base.id);
+
+   drm_dbg_kms(connector->dev,
+   "[CONNECTOR:%d:%s] generating connector hotplug event\n",
+   connector->base.id, connector->name);
+
+   kobject_uevent_env(>primary->kdev->kobj, KOBJ_CHANGE, envp);
+}
+EXPORT_SYMBOL(drm_sysfs_connector_hotplug_event);
+
 /**
  * drm_sysfs_connector_status_event - generate a DRM uevent for connector
  * property status change
diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
index d454ef617b2c..6273cac44e47 100644
--- a/include/drm/drm_sysfs.h
+++ b/include/drm/drm_sysfs.h
@@ -11,6 +11,7 @@ int drm_class_device_register(struct device *dev);
 void drm_class_device_unregister(struct device *dev);
 
 void drm_sysfs_hotplug_event(struct drm_device *dev);
+void drm_sysfs_connector_hotplug_event(struct drm_connector *connector);
 void drm_sysfs_connector_status_event(struct drm_connector *connector,
  struct drm_property *property);
 #endif
-- 
2.31.1


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


[Intel-gfx] [PATCH v2 0/7] drm: add per-connector hotplug events

2021-06-09 Thread Simon Ser
When a uevent only updates a single connector, add a CONNECTOR property
to the uevent. This allows user-space to ignore other connectors when
handling the uevent. This is purely an optimization, drivers can still
send a uevent without the CONNECTOR property.

The CONNECTOR property is already set when sending HDCP property update
uevents, see drm_sysfs_connector_status_event.

This has been tested with a wlroots patch [1].

amdgpu and the probe-helper has been updated to use these new fine-grained
uevents.

[1]: https://github.com/swaywm/wlroots/pull/2959

Simon Ser (7):
  drm/sysfs: introduce drm_sysfs_connector_hotplug_event
  drm/probe-helper: add drm_kms_helper_connector_hotplug_event
  drm/connector: use drm_sysfs_connector_hotplug_event
  amdgpu: use drm_kms_helper_connector_hotplug_event
  drm/probe-helper: use drm_kms_helper_connector_hotplug_event
  i915/display/dp: send a more fine-grained link-status uevent
  drm/connector: add ref to drm_connector_get in iter docs

 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  8 ++--
 .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c |  4 +-
 drivers/gpu/drm/drm_connector.c   |  2 +-
 drivers/gpu/drm/drm_probe_helper.c| 42 +--
 drivers/gpu/drm/drm_sysfs.c   | 25 +++
 drivers/gpu/drm/i915/display/intel_dp.c   |  2 +
 include/drm/drm_connector.h   |  5 +++
 include/drm/drm_probe_helper.h|  1 +
 include/drm/drm_sysfs.h   |  1 +
 9 files changed, 79 insertions(+), 11 deletions(-)

-- 
2.31.1


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


Re: [Intel-gfx] [PATCH 5/6] drm/i915: Clean up intel_fbdev_init_bios() a bit

2021-06-09 Thread Rodrigo Vivi
On Wed, Jun 09, 2021 at 07:46:28AM -0400, Rodrigo Vivi wrote:
> On Wed, Jun 09, 2021 at 11:56:31AM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Sort out the mess with the local variables in
> > intel_fbdev_init_bios(). Get rid of all aliasing pointers,
> > use standard naming/types, and introduc a few more locals
> 
>  ^ typo
> 
> > in the loops to avoid the hard to read long struct walks.
> > 
> > While at we also polish the debugs a bit to use the
> > canonical [CRTC:%d:%s] style.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_fbdev.c | 94 +-
> >  1 file changed, 56 insertions(+), 38 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
> > b/drivers/gpu/drm/i915/display/intel_fbdev.c
> > index 4af40229f5ec..df05d285f0bd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> > @@ -335,32 +335,43 @@ static void intel_fbdev_destroy(struct intel_fbdev 
> > *ifbdev)
> >   * fbcon), so we just find the biggest and use that.
> >   */
> >  static bool intel_fbdev_init_bios(struct drm_device *dev,
> > -struct intel_fbdev *ifbdev)
> > + struct intel_fbdev *ifbdev)
> >  {
> > struct drm_i915_private *i915 = to_i915(dev);
> > struct intel_framebuffer *fb = NULL;
> > -   struct drm_crtc *crtc;
> > -   struct intel_crtc *intel_crtc;
> > +   struct intel_crtc *crtc;
> > unsigned int max_size = 0;
> >  
> > /* Find the largest fb */
> > -   for_each_crtc(dev, crtc) {
> > +   for_each_intel_crtc(dev, crtc) {
> > +   struct intel_crtc_state *crtc_state =
> > +   to_intel_crtc_state(crtc->base.state);
> > +   struct intel_plane *plane =
> > +   to_intel_plane(crtc->base.primary);
> > +   struct intel_plane_state *plane_state =
> > +   to_intel_plane_state(plane->base.state);
> > struct drm_i915_gem_object *obj =
> > -   intel_fb_obj(crtc->primary->state->fb);
> > -   intel_crtc = to_intel_crtc(crtc);
> > +   intel_fb_obj(plane_state->uapi.fb);
> 
> oh, here we have again that plane_state uapi change that I don't understand
> and I'm not seeing any mention in any commit msg..

sorry...

Reviewed-by: Rodrigo Vivi 

> 
> >  
> > -   if (!crtc->state->active || !obj) {
> > +   if (!crtc_state->uapi.active) {
> > drm_dbg_kms(>drm,
> > -   "pipe %c not active or no fb, skipping\n",
> > -   pipe_name(intel_crtc->pipe));
> > +   "[CRTC:%d:%s] not active, skipping\n",
> > +   crtc->base.base.id, crtc->base.name);
> > +   continue;
> > +   }
> > +
> > +   if (!obj) {
> > +   drm_dbg_kms(>drm,
> > +   "[PLANE:%d:%s] no fb, skipping\n",
> > +   plane->base.base.id, plane->base.name);
> > continue;
> > }
> >  
> > if (obj->base.size > max_size) {
> > drm_dbg_kms(>drm,
> > -   "found possible fb from plane %c\n",
> > -   pipe_name(intel_crtc->pipe));
> > -   fb = to_intel_framebuffer(crtc->primary->state->fb);
> > +   "found possible fb from [PLANE:%d:%s]\n",
> > +   plane->base.base.id, plane->base.name);
> > +   fb = to_intel_framebuffer(plane_state->uapi.fb);
> > max_size = obj->base.size;
> > }
> > }
> > @@ -372,60 +383,62 @@ static bool intel_fbdev_init_bios(struct drm_device 
> > *dev,
> > }
> >  
> > /* Now make sure all the pipes will fit into it */
> > -   for_each_crtc(dev, crtc) {
> > +   for_each_intel_crtc(dev, crtc) {
> > +   struct intel_crtc_state *crtc_state =
> > +   to_intel_crtc_state(crtc->base.state);
> > +   struct intel_plane *plane =
> > +   to_intel_plane(crtc->base.primary);
> > unsigned int cur_size;
> >  
> > -   intel_crtc = to_intel_crtc(crtc);
> > -
> > -   if (!crtc->state->active) {
> > +   if (!crtc_state->uapi.active) {
> > drm_dbg_kms(>drm,
> > -   "pipe %c not active, skipping\n",
> > -   pipe_name(intel_crtc->pipe));
> > +   "[CRTC:%d:%s] not active, skipping\n",
> > +   crtc->base.base.id, crtc->base.name);
> > continue;
> > }
> >  
> > -   drm_dbg_kms(>drm, "checking plane %c for BIOS fb\n",
> > -   pipe_name(intel_crtc->pipe));
> > +  

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Clean up intel_find_initial_plane_obj() a bit

2021-06-09 Thread Rodrigo Vivi
On Wed, Jun 09, 2021 at 03:15:54PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 09, 2021 at 07:36:01AM -0400, Rodrigo Vivi wrote:
> > On Wed, Jun 09, 2021 at 11:56:29AM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > Sort out the mess with the local variables in
> > > intel_find_initial_plane_obj(). Get rid of all aliasing pointers
> > > and use standard naming/types.
> > > 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_display.c | 113 ++-
> > >  1 file changed, 62 insertions(+), 51 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 78815a1ac0ca..1615501685c9 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -1914,20 +1914,50 @@ static void intel_dpt_unpin(struct 
> > > i915_address_space *vm)
> > >   i915_vma_put(dpt->vma);
> > >  }
> > >  
> > > +static bool
> > > +intel_reuse_initial_plane_obj(struct drm_i915_private *i915,
> > > +   const struct intel_initial_plane_config 
> > > *plane_config,
> > > +   struct drm_framebuffer **fb,
> > > +   struct i915_vma **vma)
> > > +{
> > > + struct intel_crtc *crtc;
> > > +
> > > + for_each_intel_crtc(>drm, crtc) {
> > > + struct intel_crtc_state *crtc_state =
> > > + to_intel_crtc_state(crtc->base.state);
> > > + struct intel_plane *plane =
> > > + to_intel_plane(crtc->base.primary);
> > > + struct intel_plane_state *plane_state =
> > > + to_intel_plane_state(plane->base.state);
> > > +
> > > + if (!crtc_state->uapi.active)
> > > + continue;
> > > +
> > > + if (!plane_state->ggtt_vma)
> > > + continue;
> > > +
> > > + if (intel_plane_ggtt_offset(plane_state) == plane_config->base) 
> > > {
> > > + *fb = plane_state->hw.fb;
> > > + *vma = plane_state->ggtt_vma;
> > > + return true;
> > > + }
> > > + }
> > > +
> > > + return false;
> > > +}
> > > +
> > >  static void
> > > -intel_find_initial_plane_obj(struct intel_crtc *intel_crtc,
> > > +intel_find_initial_plane_obj(struct intel_crtc *crtc,
> > >struct intel_initial_plane_config *plane_config)
> > >  {
> > > - struct drm_device *dev = intel_crtc->base.dev;
> > > + struct drm_device *dev = crtc->base.dev;
> > >   struct drm_i915_private *dev_priv = to_i915(dev);
> > > - struct drm_crtc *c;
> > > - struct drm_plane *primary = intel_crtc->base.primary;
> > > - struct drm_plane_state *plane_state = primary->state;
> > > - struct intel_plane *intel_plane = to_intel_plane(primary);
> > > - struct intel_plane_state *intel_state =
> > > - to_intel_plane_state(plane_state);
> > >   struct intel_crtc_state *crtc_state =
> > > - to_intel_crtc_state(intel_crtc->base.state);
> > > + to_intel_crtc_state(crtc->base.state);
> > > + struct intel_plane *plane =
> > > + to_intel_plane(crtc->base.primary);
> > > + struct intel_plane_state *plane_state =
> > > + to_intel_plane_state(plane->base.state);
> > >   struct drm_framebuffer *fb;
> > >   struct i915_vma *vma;
> > >  
> > > @@ -1939,7 +1969,7 @@ intel_find_initial_plane_obj(struct intel_crtc 
> > > *intel_crtc,
> > >   if (!plane_config->fb)
> > >   return;
> > >  
> > > - if (intel_alloc_initial_plane_obj(intel_crtc, plane_config)) {
> > > + if (intel_alloc_initial_plane_obj(crtc, plane_config)) {
> > >   fb = _config->fb->base;
> > >   vma = plane_config->vma;
> > >   goto valid_fb;
> > > @@ -1949,25 +1979,8 @@ intel_find_initial_plane_obj(struct intel_crtc 
> > > *intel_crtc,
> > >* Failed to alloc the obj, check to see if we should share
> > >* an fb with another CRTC instead
> > >*/
> > > - for_each_crtc(dev, c) {
> > > - struct intel_plane_state *state;
> > > -
> > > - if (c == _crtc->base)
> > > - continue;
> > > -
> > > - if (!to_intel_crtc_state(c->state)->uapi.active)
> > > - continue;
> > > -
> > > - state = to_intel_plane_state(c->primary->state);
> > > - if (!state->ggtt_vma)
> > > - continue;
> > > -
> > > - if (intel_plane_ggtt_offset(state) == plane_config->base) {
> > > - fb = state->hw.fb;
> > > - vma = state->ggtt_vma;
> > > - goto valid_fb;
> > > - }
> > > - }
> > > + if (intel_reuse_initial_plane_obj(dev_priv, plane_config, , ))
> > > + goto valid_fb;
> > >  
> > >   /*
> > >* We've failed to reconstruct the BIOS FB.  Current display state
> > > @@ -1976,7 +1989,7 @@ intel_find_initial_plane_obj(struct intel_crtc 
> > > *intel_crtc,
> > >* simplest solution is to just disable the primary plane 

[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915/gem: ioctl clean-ups (rev7)

2021-06-09 Thread Patchwork
== Series Details ==

Series: drm/i915/gem: ioctl clean-ups (rev7)
URL   : https://patchwork.freedesktop.org/series/89443/
State : warning

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  MODPOST modules-only.symvers
ERROR: modpost: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:150: recipe for target 'modules-only.symvers' failed
make[1]: *** [modules-only.symvers] Error 1
make[1]: *** Deleting file 'modules-only.symvers'
Makefile:1759: recipe for target 'modules' failed
make: *** [modules] Error 2

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/build_32bit.log
___
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/gem: ioctl clean-ups (rev7)

2021-06-09 Thread Patchwork
== Series Details ==

Series: drm/i915/gem: ioctl clean-ups (rev7)
URL   : https://patchwork.freedesktop.org/series/89443/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10199 -> Patchwork_20322


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_exec_fence@nb-await:
- {fi-rkl-11500t}:[SKIP][1] ([i915#3539]) -> [FAIL][2] +3 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-rkl-11500t/igt@gem_exec_fe...@nb-await.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/fi-rkl-11500t/igt@gem_exec_fe...@nb-await.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * 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_10199/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/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_10199/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2:  [FAIL][7] ([i915#1888]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [FAIL][9] ([i915#2203]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-kbl-guc/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/fi-kbl-guc/igt@i915_pm_...@module-reload.html

  
 Warnings 

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

  * igt@runner@aborted:
- fi-cfl-8700k:   [FAIL][13] ([i915#2426] / [i915#3363]) -> [FAIL][14] 
([i915#3363])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-cfl-8700k/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/fi-cfl-8700k/igt@run...@aborted.html
- fi-icl-u2:  [FAIL][15] ([i915#2426] / [i915#2782] / [i915#3363]) 
-> [FAIL][16] ([i915#2782] / [i915#3363])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-icl-u2/igt@run...@aborted.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/fi-icl-u2/igt@run...@aborted.html
- fi-glk-dsi: [FAIL][17] ([i915#2426] / [i915#3363] / 
[k.org#202321]) -> [FAIL][18] ([i915#3363] / [k.org#202321])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-glk-dsi/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/fi-glk-dsi/igt@run...@aborted.html
- fi-kbl-8809g:   [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_10199/fi-kbl-8809g/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/fi-kbl-8809g/igt@run...@aborted.html
- fi-bdw-5557u:   [FAIL][21] ([i915#3462]) -> [FAIL][22] ([i915#1602] / 
[i915#2029])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-bdw-5557u/igt@run...@aborted.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/fi-bdw-5557u/igt@run...@aborted.html
- fi-bxt-dsi: [FAIL][23] ([i915#3363]) -> [FAIL][24] ([i915#2426] / 
[i915#3363])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10199/fi-bxt-dsi/igt@run...@aborted.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20322/fi-bxt-dsi/igt@run...@aborted.html
- fi-cml-s:   [FAIL][25] ([i915#2082] / [i915#2426] / [i915#3363] / 
[i915#3462]) -> [FAIL][26] ([i915#3363] / [i915#3462])
   [25]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gem: ioctl clean-ups (rev7)

2021-06-09 Thread Patchwork
== Series Details ==

Series: drm/i915/gem: ioctl clean-ups (rev7)
URL   : https://patchwork.freedesktop.org/series/89443/
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:1893:21:expected struct 
i915_vma *[assigned] vma
+drivers/gpu/drm/i915/display/intel_display.c:1893:21:got void [noderef] 
__iomem *[assigned] iomem
+drivers/gpu/drm/i915/display/intel_display.c:1893:21: warning: incorrect type 
in assignment (different address spaces)
+drivers/gpu/drm/i915/gem/i915_gem_context.c:1412:34:expected struct 
i915_address_space *vm
+drivers/gpu/drm/i915/gem/i915_gem_context.c:1412:34:got struct 
i915_address_space [noderef] __rcu *vm
+drivers/gpu/drm/i915/gem/i915_gem_context.c:1412:34: warning: incorrect type 
in argument 1 (different address spaces)
+drivers/gpu/drm/i915/gem/selftests/mock_context.c:43:25:expected struct 
i915_address_space [noderef] __rcu *vm
+drivers/gpu/drm/i915/gem/selftests/mock_context.c:43:25:got struct 
i915_address_space *
+drivers/gpu/drm/i915/gem/selftests/mock_context.c:43:25: warning: incorrect 
type in assignment (different address spaces)
+drivers/gpu/drm/i915/gem/selftests/mock_context.c:60:34:expected struct 
i915_address_space *vm
+drivers/gpu/drm/i915/gem/selftests/mock_context.c:60:34:got struct 
i915_address_space [noderef] __rcu *vm
+drivers/gpu/drm/i915/gem/selftests/mock_context.c:60:34: warning: incorrect 
type in argument 1 (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:1396:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207: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
+drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y
+./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 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: ioctl clean-ups (rev7)

2021-06-09 Thread Patchwork
== Series Details ==

Series: drm/i915/gem: ioctl clean-ups (rev7)
URL   : https://patchwork.freedesktop.org/series/89443/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
100d73aa9252 drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE
-:177: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#177: 
deleted file mode 100644

total: 0 errors, 1 warnings, 0 checks, 159 lines checked
c3f6a0807a27 drm/i915: Stop storing the ring size in the ring pointer (v2)
a9718291830e drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP
ec5522a9644b drm/i915/gem: Set the watchdog timeout directly in 
intel_context_set_gem (v2)
203766899755 drm/i915/gem: Return void from context_apply_all
835c8348dc42 drm/i915: Drop the CONTEXT_CLONE API (v2)
2dad231d92fb drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)
07f876e84333 drm/i915: Drop getparam support for I915_CONTEXT_PARAM_ENGINES
46e86a5d9e0e drm/i915/gem: Disallow bonding of virtual engines (v3)
30fdc9fcedba drm/i915/gem: Remove engine auto-magic with FENCE_SUBMIT (v2)
969b77513f32 drm/i915/request: Remove the hook from await_execution
3d0a4c060233 drm/i915/gem: Disallow creating contexts with too many engines
79c699205313 drm/i915: Stop manually RCU banging in reset_stats_ioctl (v2)
587a7f034af2 drm/i915/gem: Add a separate validate_priority helper
d102d0429864 drm/i915: Add gem/i915_gem_context.h to the docs
3602847dade8 drm/i915/gem: Add an intermediate proto_context struct (v5)
-:281: WARNING:REPEATED_WORD: Possible repeated word: 'See'
#281: FILE: drivers/gpu/drm/i915/gem/i915_gem_context_types.h:87:
+   /** @single_timeline: See See _gem_context.syncobj */

total: 0 errors, 1 warnings, 0 checks, 260 lines checked
f6e071ec8bae drm/i915/gem: Rework error handling in default_engines
051bed0b2983 drm/i915/gem: Optionally set SSEU in intel_context_set_gem
f4cebc831245 drm/i915: Add an i915_gem_vm_lookup helper
b0db512b3247 drm/i915/gem: Make an alignment check more sensible
ff8c4049d11e drm/i915/gem: Use the proto-context to handle create parameters 
(v4)
-:99: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#99: FILE: drivers/gpu/drm/i915/gem/i915_gem_context.c:310:
+   unsigned num_engines;

-:280: ERROR:CODE_INDENT: code indent should use tabs where possible
#280: FILE: drivers/gpu/drm/i915/gem/i915_gem_context.c:491:
+^I^I^I struct i915_gem_proto_context *pc,$

-:280: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#280: FILE: drivers/gpu/drm/i915/gem/i915_gem_context.c:491:
+static int set_proto_ctx_engines(struct drm_i915_file_private *fpriv,
+struct i915_gem_proto_context *pc,

-:281: ERROR:CODE_INDENT: code indent should use tabs where possible
#281: FILE: drivers/gpu/drm/i915/gem/i915_gem_context.c:492:
+^I^I^I const struct drm_i915_gem_context_param *args)$

-:384: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#384: FILE: drivers/gpu/drm/i915/gem/i915_gem_context.c:595:
+   if (!!(user_sseu.flags & I915_CONTEXT_SSEU_FLAG_ENGINE_INDEX) != 
(pc->num_user_engines >= 0))

-:384: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 
'pc->num_user_engines >= 0'
#384: FILE: drivers/gpu/drm/i915/gem/i915_gem_context.c:595:
+   if (!!(user_sseu.flags & I915_CONTEXT_SSEU_FLAG_ENGINE_INDEX) != 
(pc->num_user_engines >= 0))

total: 2 errors, 2 warnings, 2 checks, 688 lines checked
5d4b208bfccf drm/i915/gem: Return an error ptr from context_lookup
-:60: WARNING:LIKELY_MISUSE: nested (un)?likely() calls, IS_ERR already uses 
unlikely() internally
#60: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:742:
+   if (unlikely(IS_ERR(ctx)))

total: 0 errors, 1 warnings, 0 checks, 60 lines checked
a7f403d3da97 drm/i915/gt: Drop i915_address_space::file (v2)
-:9: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 2bfa996e031b ("drm/i915: Store 
owning file on the i915_address_space")'
#9: 
It was added in 2bfa996e031b ("drm/i915: Store owning file on the

-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit f6e8aa387171 ("drm/i915: Report 
the number of closed vma held by each context in debugfs")'
#11: 
the difference between the global GTT and a PPGTT.  In f6e8aa387171

-:15: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit db80a1294c23 ("drm/i915/gem: 
Remove per-client stats from debugfs/i915_gem_objects")'
#15: 
were entirely nuked in db80a1294c23 ("drm/i915/gem: Remove per-client

total: 3 errors, 0 warnings, 0 checks, 55 lines checked
0d52b049e5f2 drm/i915/gem: Delay context creation (v3)
b9b1b45bf4fc drm/i915/gem: Don't allow changing the VM on running contexts (v4)
77127cea6b1b drm/i915/gem: Don't allow changing the engine set on running 
contexts (v3)
-:25: WARNING:TYPO_SPELLING: 'mesage' may be misspelled - 

Re: [Intel-gfx] [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action

2021-06-09 Thread Michal Wajdeczko


On 09.06.2021 19:36, John Harrison wrote:
> On 6/7/2021 18:23, Daniele Ceraolo Spurio wrote:
>> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>>> From: Michal Wajdeczko 
>>>
>>> Definition of the CTB registration action has changed.
>>> Add some ABI documentation and implement required changes.
>>>
>>> Signed-off-by: Michal Wajdeczko 
>>> Signed-off-by: Matthew Brost 
>>> Cc: Piotr Piórkowski  #4
>>> ---
>>>   .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  | 107 ++
>>>   .../gt/uc/abi/guc_communication_ctb_abi.h |   4 -
>>>   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |  76 -
>>>   3 files changed, 152 insertions(+), 35 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
>>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
>>> index 90efef8a73e4..6426fc183692 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
>>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
>>> @@ -6,6 +6,113 @@
>>>   #ifndef _ABI_GUC_ACTIONS_ABI_H
>>>   #define _ABI_GUC_ACTIONS_ABI_H
>>>   +/**
>>> + * DOC: HOST2GUC_REGISTER_CTB
>>> + *
>>> + * This message is used as part of the `CTB based communication`_
>>> setup.
>>> + *
>>> + * This message must be sent as `MMIO HXG Message`_.
>>> + *
>>> + *
>>> +---+---+--+
>>>
>>> + *  |   | Bits  |
>>> Description  |
>>> + *
>>> +===+===+==+
>>>
>>> + *  | 0 |    31 | ORIGIN =
>>> GUC_HXG_ORIGIN_HOST_    |
>>> + *  |
>>> +---+--+
>>> + *  |   | 30:28 | TYPE =
>>> GUC_HXG_TYPE_REQUEST_ |
>>> + *  |
>>> +---+--+
>>> + *  |   | 27:16 | DATA0 =
>>> MBZ  |
>>> + *  |
>>> +---+--+
>>> + *  |   |  15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` =
>>> 0x5200    |
>>
>> Specs says 4505
>>
>>> + *
>>> +---+---+--+
>>>
>>> + *  | 1 | 31:12 | RESERVED =
>>> MBZ   |
>>> + *  |
>>> +---+--+
>>> + *  |   |  11:8 | **TYPE** - type for the `CT
>>> Buffer`_ |
>>> + *  |   |
>>> |  |
>>> + *  |   |   |   - _`GUC_CTB_TYPE_HOST2GUC` =
>>> 0 |
>>> + *  |   |   |   - _`GUC_CTB_TYPE_GUC2HOST` =
>>> 1 |
>>> + *  |
>>> +---+--+
>>> + *  |   |   7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units
>>> minus 1  |
>>> + *
>>> +---+---+--+
>>>
>>> + *  | 2 |  31:0 | **DESC_ADDR** - GGTT address of the `CTB
>>> Descriptor`_    |
>>> + *
>>> +---+---+--+
>>>
>>> + *  | 3 |  31:0 | **BUFF_ADDF** - GGTT address of the `CT
>>> Buffer`_ |
>>> + *
>>> +---+---+--+
>>>
>>> +*
>>> + *
>>> +---+---+--+
>>>
>>> + *  |   | Bits  |
>>> Description  |
>>> + *
>>> +===+===+==+
>>>
>>> + *  | 0 |    31 | ORIGIN =
>>> GUC_HXG_ORIGIN_GUC_ |
>>> + *  |
>>> +---+--+
>>> + *  |   | 30:28 | TYPE =
>>> GUC_HXG_TYPE_RESPONSE_SUCCESS_    |
>>> + *  |
>>> +---+--+
>>> + *  |   |  27:0 | DATA0 =
>>> MBZ  |
>>> + *
>>> +---+---+--+
>>>
>>> + */
>>> +#define GUC_ACTION_HOST2GUC_REGISTER_CTB    0x4505 // FIXME 0x5200
>>
>> Why FIXME? AFAICS the specs still says 4505, even if we plan to update
>> at some point I don;t think this deserves a FIXME since nothing is
>> incorrect.
>>
>>> +
>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN
>>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ
>>> GUC_HXG_REQUEST_MSG_0_DATA0
>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ    (0xf << 12)
>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE    (0xf << 8)
>>> +#define   GUC_CTB_TYPE_HOST2GUC    0u
>>> +#define   GUC_CTB_TYPE_GUC2HOST    1u
>>> +#define 

Re: [Intel-gfx] [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action

2021-06-09 Thread Michal Wajdeczko


On 08.06.2021 03:23, Daniele Ceraolo Spurio wrote:
> 
> 
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko 
>>
>> Definition of the CTB registration action has changed.
>> Add some ABI documentation and implement required changes.
>>
>> Signed-off-by: Michal Wajdeczko 
>> Signed-off-by: Matthew Brost 
>> Cc: Piotr Piórkowski  #4
>> ---
>>   .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  | 107 ++
>>   .../gt/uc/abi/guc_communication_ctb_abi.h |   4 -
>>   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |  76 -
>>   3 files changed, 152 insertions(+), 35 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
>> index 90efef8a73e4..6426fc183692 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
>> @@ -6,6 +6,113 @@
>>   #ifndef _ABI_GUC_ACTIONS_ABI_H
>>   #define _ABI_GUC_ACTIONS_ABI_H
>>   +/**
>> + * DOC: HOST2GUC_REGISTER_CTB
>> + *
>> + * This message is used as part of the `CTB based communication`_ setup.
>> + *
>> + * This message must be sent as `MMIO HXG Message`_.
>> + *
>> + * 
>> +---+---+--+
>>
>> + *  |   | Bits  |
>> Description  |
>> + * 
>> +===+===+==+
>>
>> + *  | 0 |    31 | ORIGIN =
>> GUC_HXG_ORIGIN_HOST_    |
>> + *  |  
>> +---+--+
>> + *  |   | 30:28 | TYPE =
>> GUC_HXG_TYPE_REQUEST_ |
>> + *  |  
>> +---+--+
>> + *  |   | 27:16 | DATA0 =
>> MBZ  |
>> + *  |  
>> +---+--+
>> + *  |   |  15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` =
>> 0x5200    |
> 
> Specs says 4505

but draft was saying 5200 ;)

> 
>> + * 
>> +---+---+--+
>>
>> + *  | 1 | 31:12 | RESERVED =
>> MBZ   |
>> + *  |  
>> +---+--+
>> + *  |   |  11:8 | **TYPE** - type for the `CT
>> Buffer`_ |
>> + *  |   |  
>> |  |
>> + *  |   |   |   - _`GUC_CTB_TYPE_HOST2GUC` =
>> 0 |
>> + *  |   |   |   - _`GUC_CTB_TYPE_GUC2HOST` =
>> 1 |
>> + *  |  
>> +---+--+
>> + *  |   |   7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units
>> minus 1  |
>> + * 
>> +---+---+--+
>>
>> + *  | 2 |  31:0 | **DESC_ADDR** - GGTT address of the `CTB
>> Descriptor`_    |
>> + * 
>> +---+---+--+
>>
>> + *  | 3 |  31:0 | **BUFF_ADDF** - GGTT address of the `CT
>> Buffer`_ |
>> + * 
>> +---+---+--+
>>
>> +*
>> + * 
>> +---+---+--+
>>
>> + *  |   | Bits  |
>> Description  |
>> + * 
>> +===+===+==+
>>
>> + *  | 0 |    31 | ORIGIN =
>> GUC_HXG_ORIGIN_GUC_ |
>> + *  |  
>> +---+--+
>> + *  |   | 30:28 | TYPE =
>> GUC_HXG_TYPE_RESPONSE_SUCCESS_    |
>> + *  |  
>> +---+--+
>> + *  |   |  27:0 | DATA0 =
>> MBZ  |
>> + * 
>> +---+---+--+
>>
>> + */
>> +#define GUC_ACTION_HOST2GUC_REGISTER_CTB    0x4505 // FIXME 0x5200
> 
> Why FIXME? AFAICS the specs still says 4505, even if we plan to update
> at some point I don;t think this deserves a FIXME since nothing is
> incorrect.

patch was prepared based on draft spec and this FIXME was added just as
head-up since we were expecting GuC to make this change soon, but since
we are going with GuC 62 that uses 4505, agree, we need drop this FIXME

> 
>> +
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN   
>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ   
>> GUC_HXG_REQUEST_MSG_0_DATA0
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ    (0xf << 12)
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE    (0xf << 8)
>> +#define   

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/display: Drop FIXME about turn off infoframes

2021-06-09 Thread Souza, Jose
On Tue, 2021-06-08 at 10:26 +0300, Ville Syrjälä wrote:
> On Fri, May 14, 2021 at 04:22:47PM -0700, José Roberto de Souza wrote:
> > intel_dp_set_infoframes() call in intel_ddi_post_disable_dp() will
> > take care to disable all enabled infoframes.
> > 
> > Cc: Ville Syrjälä 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/display/intel_ddi.c | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 5bc5528f3091..d3bc5a1a936a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -2762,7 +2762,6 @@ static void intel_ddi_pre_enable(struct 
> > intel_atomic_state *state,
> > conn_state);
> >  
> > /* FIXME precompute everything properly */
> > -   /* FIXME how do we turn infoframes off again? */
> 
> The FIXME was there for LSPCON and shouldn't have been removed.
> No one has yet figured out how to do this.

intel_ddi_post_disable_dp()->intel_dp_set_infoframes() will be executed for 
LSPCON, or am I missing something?

> 
> > if (dig_port->lspcon.active && dig_port->dp.has_hdmi_sink)
> > dig_port->set_infoframes(encoder, true, crtc_state,
> >  conn_state);
> > -- 
> > 2.31.1
> 

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


Re: [Intel-gfx] [PATCH 1/1] drm/i915/uc: Use platform specific defaults for GuC/HuC enabling

2021-06-09 Thread Daniele Ceraolo Spurio




On 6/3/2021 9:48 AM, Matthew Brost wrote:

From: John Harrison 

The meaning of 'default' for the enable_guc module parameter has been
updated to accurately reflect what is supported on current platforms.
So start using the defaults instead of forcing everything off.
Although, note that right now, the default is for everything to be off
anyway. So this is not a change for current platforms.

Signed-off-by: John Harrison 
Signed-off-by: Matthew Brost 
Reviewed-by: Daniele Ceraolo Spurio 


Double checked the CI results and the 2 errors are unrelated.
Pushed to gt-next.

Daniele


---
  drivers/gpu/drm/i915/i915_params.c | 2 +-
  drivers/gpu/drm/i915/i915_params.h | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 0320878d96b0..e07f4cfea63a 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -160,7 +160,7 @@ i915_param_named_unsafe(edp_vswing, int, 0400,
  i915_param_named_unsafe(enable_guc, int, 0400,
"Enable GuC load for GuC submission and/or HuC load. "
"Required functionality can be selected using bitmask values. "
-   "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)");
+   "(-1=auto [default], 0=disable, 1=GuC submission, 2=HuC load)");
  
  i915_param_named(guc_log_level, int, 0400,

"GuC firmware logging level. Requires GuC to be loaded. "
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 4a114a5ad000..f27eceb82c0f 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -59,7 +59,7 @@ struct drm_printer;
param(int, disable_power_well, -1, 0400) \
param(int, enable_ips, 1, 0600) \
param(int, invert_brightness, 0, 0600) \
-   param(int, enable_guc, 0, 0400) \
+   param(int, enable_guc, -1, 0400) \
param(int, guc_log_level, -1, 0400) \
param(char *, guc_firmware_path, NULL, 0400) \
param(char *, huc_firmware_path, NULL, 0400) \


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


Re: [Intel-gfx] [PATCH 06/13] drm/i915/guc: New definition of the CTB descriptor

2021-06-09 Thread Michal Wajdeczko


On 08.06.2021 02:59, Daniele Ceraolo Spurio wrote:
> 
> 
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko 
>>
>> Definition of the CTB descriptor has changed, leaving only
>> minimal shared fields like HEAD/TAIL/STATUS.
>>
>> Both HEAD and TAIL are now in dwords.
>>
>> Add some ABI documentation and implement required changes.
>>
>> Signed-off-by: Michal Wajdeczko 
>> Signed-off-by: Matthew Brost 
>> ---
>>   .../gt/uc/abi/guc_communication_ctb_abi.h | 70 ++-
>>   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 70 +--
>>   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  2 +-
>>   3 files changed, 85 insertions(+), 57 deletions(-)
>>
>> diff --git
>> a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> index d38935f47ecf..c2a069a78e01 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> @@ -7,6 +7,58 @@
>>   #define _ABI_GUC_COMMUNICATION_CTB_ABI_H
>>     #include 
>> +#include 
>> +
>> +#include "guc_messages_abi.h"
>> +
>> +/**
>> + * DOC: CT Buffer
>> + *
>> + * TBD
> 
> What's the plan with this TBD here?

Plan was to add some updated text based on old "DOC: CTB based
communication" section

> 
>> + */
>> +
>> +/**
>> + * DOC: CTB Descriptor
>> + *
>> + * 
>> +---+---+--+
>>
>> + *  |   | Bits  |
>> Description  |
>> + * 
>> +===+===+==+
>>
>> + *  | 0 |  31:0 | **HEAD** - offset (in dwords) to the last dword
>> that was |
>> + *  |   |   | read from the `CT
>> Buffer`_.  |
>> + *  |   |   | It can only be updated by the
>> receiver.  |
>> + * 
>> +---+---+--+
>>
>> + *  | 1 |  31:0 | **TAIL** - offset (in dwords) to the last dword
>> that was |
>> + *  |   |   | written to the `CT
>> Buffer`_. |
>> + *  |   |   | It can only be updated by the
>> sender.    |
>> + * 
>> +---+---+--+
>>
>> + *  | 2 |  31:0 | **STATUS** - status of the
>> CTB   |
>> + *  |   |  
>> |  |
>> + *  |   |   |   - _`GUC_CTB_STATUS_NO_ERROR` = 0 (normal
>> operation)    |
>> + *  |   |   |   - _`GUC_CTB_STATUS_OVERFLOW` = 1 (head/tail too
>> large) |
>> + *  |   |   |   - _`GUC_CTB_STATUS_UNDERFLOW` = 2 (truncated
>> message)  |
>> + *  |   |   |   - _`GUC_CTB_STATUS_MISMATCH` = 4 (head/tail
>> modified)  |
>> + *  |   |   |   - _`GUC_CTB_STATUS_NO_BACKCHANNEL` =
>> 8 |
>> + *  |   |   |   - _`GUC_CTB_STATUS_MALFORMED_MSG` =
>> 16 |
> 
> I don't see the last 2 error (8 & 16) in the 62.0.0 specs. Where is the
> reference for them?

both were discussed on various meetings but likely didn't make into
final spec 62, so for now we can drop them both

> 
>> + * 
>> +---+---+--+
>>
>> + *  |...|   | RESERVED =
>> MBZ   |
>> + * 
>> +---+---+--+
>>
>> + *  | 15|  31:0 | RESERVED =
>> MBZ   |
>> + * 
>> +---+---+--+
>>
>> + */
>> +
>> +struct guc_ct_buffer_desc {
>> +    u32 head;
>> +    u32 tail;
>> +    u32 status;
>> +#define GUC_CTB_STATUS_NO_ERROR    0
>> +#define GUC_CTB_STATUS_OVERFLOW    (1 << 0)
>> +#define GUC_CTB_STATUS_UNDERFLOW    (1 << 1)
>> +#define GUC_CTB_STATUS_MISMATCH    (1 << 2)
>> +#define GUC_CTB_STATUS_NO_BACKCHANNEL    (1 << 3)
>> +#define GUC_CTB_STATUS_MALFORMED_MSG    (1 << 4)
> 
> use BIT() ?

as explained before, on ABI headers we didn't want any dependency and
just use plain C

> 
>> +    u32 reserved[13];
>> +} __packed;
>> +static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
>>     /**
>>    * DOC: CTB based communication
>> @@ -60,24 +112,6 @@
>>    * - **flags**, holds various bits to control message handling
>>    */
>>   -/*
>> - * Describes single command transport buffer.
>> - * Used by both guc-master and clients.
>> - */
>> -struct guc_ct_buffer_desc {
>> -    u32 addr;    /* gfx address */
>> -    u64 host_private;    /* host private data */
>> -    u32 size;    /* size in bytes */
>> -    u32 head;    /* offset updated by GuC*/
>> -    u32 tail;    /* offset updated by owner */
>> -    u32 is_in_error;    /* error 

[Intel-gfx] [PATCH 31/31] HACK: Always finalize contexts

2021-06-09 Thread Jason Ekstrand
Only for verifying the previous patch with I-G-T.  DO NOT MERGE!
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 7d6f52d8a8012..9395d9d7f9530 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1996,7 +1996,7 @@ int i915_gem_context_create_ioctl(struct drm_device *dev, 
void *data,
goto err_pc;
}
 
-   if (GRAPHICS_VER(i915) > 12) {
+   if (1 || (GRAPHICS_VER(i915) > 12)) {
struct i915_gem_context *ctx;
 
/* Get ourselves a context ID */
-- 
2.31.1

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


[Intel-gfx] [PATCH 30/31] drm/i915: Finalize contexts in GEM_CONTEXT_CREATE on version 13+

2021-06-09 Thread Jason Ekstrand
All the proto-context stuff for context creation exists to allow older
userspace drivers to set VMs and engine sets via SET_CONTEXT_PARAM.
Drivers need to update to use CONTEXT_CREATE_EXT_* for this going
forward.  Force the issue by blocking the old mechanism on any future
hardware generations.

Signed-off-by: Jason Ekstrand 
Cc: Jon Bloomfield 
Cc: Carl Zhang 
Cc: Michal Mrozek 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 39 -
 1 file changed, 30 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c67e305f5bc74..7d6f52d8a8012 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1996,9 +1996,28 @@ int i915_gem_context_create_ioctl(struct drm_device 
*dev, void *data,
goto err_pc;
}
 
-   ret = proto_context_register(ext_data.fpriv, ext_data.pc, );
-   if (ret < 0)
-   goto err_pc;
+   if (GRAPHICS_VER(i915) > 12) {
+   struct i915_gem_context *ctx;
+
+   /* Get ourselves a context ID */
+   ret = xa_alloc(_data.fpriv->context_xa, , NULL,
+  xa_limit_32b, GFP_KERNEL);
+   if (ret)
+   goto err_pc;
+
+   ctx = i915_gem_create_context(i915, ext_data.pc);
+   if (IS_ERR(ctx)) {
+   ret = PTR_ERR(ctx);
+   goto err_pc;
+   }
+
+   proto_context_close(ext_data.pc);
+   gem_context_register(ctx, ext_data.fpriv, id);
+   } else {
+   ret = proto_context_register(ext_data.fpriv, ext_data.pc, );
+   if (ret < 0)
+   goto err_pc;
+   }
 
args->ctx_id = id;
drm_dbg(>drm, "HW context %d created\n", args->ctx_id);
@@ -2181,15 +2200,17 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
mutex_lock(_priv->proto_context_lock);
ctx = __context_lookup(file_priv, args->ctx_id);
if (!ctx) {
-   /* FIXME: We should consider disallowing SET_CONTEXT_PARAM
-* for most things on future platforms.  Clients should be
-* using CONTEXT_CREATE_EXT_PARAM instead.
-*/
pc = xa_load(_priv->proto_context_xa, args->ctx_id);
-   if (pc)
+   if (pc) {
+   /* Contexts should be finalized inside
+* GEM_CONTEXT_CREATE starting with graphics
+* version 13.
+*/
+   WARN_ON(GRAPHICS_VER(file_priv->dev_priv) > 12);
ret = set_proto_ctx_param(file_priv, pc, args);
-   else
+   } else {
ret = -ENOENT;
+   }
}
mutex_unlock(_priv->proto_context_lock);
 
-- 
2.31.1

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


[Intel-gfx] [PATCH 28/31] i915/gem/selftests: Assign the VM at context creation in igt_shared_ctx_exec

2021-06-09 Thread Jason Ekstrand
We want to delete __assign_ppgtt and, generally, stop setting the VM
after context creation.  This is the one place I could find in the
selftests where we set a VM after the fact.

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index 3e59746afdc82..8eb5050f8cb3e 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -813,16 +813,12 @@ static int igt_shared_ctx_exec(void *arg)
struct i915_gem_context *ctx;
struct intel_context *ce;
 
-   ctx = kernel_context(i915, NULL);
+   ctx = kernel_context(i915, ctx_vm(parent));
if (IS_ERR(ctx)) {
err = PTR_ERR(ctx);
goto out_test;
}
 
-   mutex_lock(>mutex);
-   __assign_ppgtt(ctx, ctx_vm(parent));
-   mutex_unlock(>mutex);
-
ce = i915_gem_context_get_engine(ctx, 
engine->legacy_idx);
GEM_BUG_ON(IS_ERR(ce));
 
-- 
2.31.1

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


[Intel-gfx] [PATCH 29/31] drm/i915/gem: Roll all of context creation together

2021-06-09 Thread Jason Ekstrand
Now that we have the whole engine set and VM at context creation time,
we can just assign those fields instead of creating first and handling
the VM and engines later.  This lets us avoid creating useless VMs and
engine sets and lets us get rid of the complex VM setting code.

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 176 ++
 .../gpu/drm/i915/gem/selftests/mock_context.c |  33 ++--
 2 files changed, 73 insertions(+), 136 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 5f5375b15c530..c67e305f5bc74 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1279,56 +1279,6 @@ static int __context_set_persistence(struct 
i915_gem_context *ctx, bool state)
return 0;
 }
 
-static struct i915_gem_context *
-__create_context(struct drm_i915_private *i915,
-const struct i915_gem_proto_context *pc)
-{
-   struct i915_gem_context *ctx;
-   struct i915_gem_engines *e;
-   int err;
-   int i;
-
-   ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
-   if (!ctx)
-   return ERR_PTR(-ENOMEM);
-
-   kref_init(>ref);
-   ctx->i915 = i915;
-   ctx->sched = pc->sched;
-   mutex_init(>mutex);
-   INIT_LIST_HEAD(>link);
-
-   spin_lock_init(>stale.lock);
-   INIT_LIST_HEAD(>stale.engines);
-
-   mutex_init(>engines_mutex);
-   e = default_engines(ctx, pc->legacy_rcs_sseu);
-   if (IS_ERR(e)) {
-   err = PTR_ERR(e);
-   goto err_free;
-   }
-   RCU_INIT_POINTER(ctx->engines, e);
-
-   INIT_RADIX_TREE(>handles_vma, GFP_KERNEL);
-   mutex_init(>lut_mutex);
-
-   /* NB: Mark all slices as needing a remap so that when the context first
-* loads it will restore whatever remap state already exists. If there
-* is no remap info, it will be a NOP. */
-   ctx->remap_slice = ALL_L3_SLICES(i915);
-
-   ctx->user_flags = pc->user_flags;
-
-   for (i = 0; i < ARRAY_SIZE(ctx->hang_timestamp); i++)
-   ctx->hang_timestamp[i] = jiffies - CONTEXT_FAST_HANG_JIFFIES;
-
-   return ctx;
-
-err_free:
-   kfree(ctx);
-   return ERR_PTR(err);
-}
-
 static inline struct i915_gem_engines *
 __context_engines_await(const struct i915_gem_context *ctx,
bool *user_engines)
@@ -1372,54 +1322,31 @@ context_apply_all(struct i915_gem_context *ctx,
i915_sw_fence_complete(>fence);
 }
 
-static void __apply_ppgtt(struct intel_context *ce, void *vm)
-{
-   i915_vm_put(ce->vm);
-   ce->vm = i915_vm_get(vm);
-}
-
-static struct i915_address_space *
-__set_ppgtt(struct i915_gem_context *ctx, struct i915_address_space *vm)
-{
-   struct i915_address_space *old;
-
-   old = rcu_replace_pointer(ctx->vm,
- i915_vm_open(vm),
- lockdep_is_held(>mutex));
-   GEM_BUG_ON(old && i915_vm_is_4lvl(vm) != i915_vm_is_4lvl(old));
-
-   context_apply_all(ctx, __apply_ppgtt, vm);
-
-   return old;
-}
-
-static void __assign_ppgtt(struct i915_gem_context *ctx,
-  struct i915_address_space *vm)
-{
-   if (vm == rcu_access_pointer(ctx->vm))
-   return;
-
-   vm = __set_ppgtt(ctx, vm);
-   if (vm)
-   i915_vm_close(vm);
-}
-
 static struct i915_gem_context *
 i915_gem_create_context(struct drm_i915_private *i915,
const struct i915_gem_proto_context *pc)
 {
struct i915_gem_context *ctx;
-   int ret;
+   struct i915_address_space *vm = NULL;
+   struct i915_gem_engines *e;
+   int err;
+   int i;
 
-   ctx = __create_context(i915, pc);
-   if (IS_ERR(ctx))
-   return ctx;
+   ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+   if (!ctx)
+   return ERR_PTR(-ENOMEM);
+
+   kref_init(>ref);
+   ctx->i915 = i915;
+   ctx->sched = pc->sched;
+   mutex_init(>mutex);
+   INIT_LIST_HEAD(>link);
+
+   spin_lock_init(>stale.lock);
+   INIT_LIST_HEAD(>stale.engines);
 
if (pc->vm) {
-   /* __assign_ppgtt() requires this mutex to be held */
-   mutex_lock(>mutex);
-   __assign_ppgtt(ctx, pc->vm);
-   mutex_unlock(>mutex);
+   vm = i915_vm_get(pc->vm);
} else if (HAS_FULL_PPGTT(i915)) {
struct i915_ppgtt *ppgtt;
 
@@ -1427,50 +1354,65 @@ i915_gem_create_context(struct drm_i915_private *i915,
if (IS_ERR(ppgtt)) {
drm_dbg(>drm, "PPGTT setup failed (%ld)\n",
PTR_ERR(ppgtt));
-   context_close(ctx);
-   return ERR_CAST(ppgtt);
+   err = PTR_ERR(ppgtt);
+   goto err_ctx;
   

[Intel-gfx] [PATCH 26/31] drm/i915/gem: Don't allow changing the engine set on running contexts (v3)

2021-06-09 Thread Jason Ekstrand
When the APIs were added to manage the engine set on a GEM context
directly from userspace, the questionable choice was made to allow
changing the engine set on a context at any time.  This is horribly racy
and there's absolutely no reason why any userspace would want to do this
outside of trying to exercise interesting race conditions.  By removing
support for CONTEXT_PARAM_ENGINES from ctx_setparam, we make it
impossible to change the engine set after the context has been fully
created.

This doesn't yet let us delete all the deferred engine clean-up code as
that's still used for handling the case where the client dies or calls
GEM_CONTEXT_DESTROY while work is in flight.  However, moving to an API
where the engine set is effectively immutable gives us more options to
potentially clean that code up a bit going forward.  It also removes a
whole class of ways in which a client can hurt itself or try to get
around kernel context banning.

v2 (Jason Ekstrand):
 - Expand the commit mesage

v3 (Jason Ekstrand):
 - Make it more obvious that I915_CONTEXT_PARAM_ENGINES returns -EINVAL

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 304 +---
 1 file changed, 1 insertion(+), 303 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 40acecfbbe5b5..5f5375b15c530 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1819,305 +1819,6 @@ static int set_sseu(struct i915_gem_context *ctx,
return ret;
 }
 
-struct set_engines {
-   struct i915_gem_context *ctx;
-   struct i915_gem_engines *engines;
-};
-
-static int
-set_engines__load_balance(struct i915_user_extension __user *base, void *data)
-{
-   struct i915_context_engines_load_balance __user *ext =
-   container_of_user(base, typeof(*ext), base);
-   const struct set_engines *set = data;
-   struct drm_i915_private *i915 = set->ctx->i915;
-   struct intel_engine_cs *stack[16];
-   struct intel_engine_cs **siblings;
-   struct intel_context *ce;
-   struct intel_sseu null_sseu = {};
-   u16 num_siblings, idx;
-   unsigned int n;
-   int err;
-
-   if (!HAS_EXECLISTS(i915))
-   return -ENODEV;
-
-   if (intel_uc_uses_guc_submission(>gt.uc))
-   return -ENODEV; /* not implement yet */
-
-   if (get_user(idx, >engine_index))
-   return -EFAULT;
-
-   if (idx >= set->engines->num_engines) {
-   drm_dbg(>drm, "Invalid placement value, %d >= %d\n",
-   idx, set->engines->num_engines);
-   return -EINVAL;
-   }
-
-   idx = array_index_nospec(idx, set->engines->num_engines);
-   if (set->engines->engines[idx]) {
-   drm_dbg(>drm,
-   "Invalid placement[%d], already occupied\n", idx);
-   return -EEXIST;
-   }
-
-   if (get_user(num_siblings, >num_siblings))
-   return -EFAULT;
-
-   err = check_user_mbz(>flags);
-   if (err)
-   return err;
-
-   err = check_user_mbz(>mbz64);
-   if (err)
-   return err;
-
-   siblings = stack;
-   if (num_siblings > ARRAY_SIZE(stack)) {
-   siblings = kmalloc_array(num_siblings,
-sizeof(*siblings),
-GFP_KERNEL);
-   if (!siblings)
-   return -ENOMEM;
-   }
-
-   for (n = 0; n < num_siblings; n++) {
-   struct i915_engine_class_instance ci;
-
-   if (copy_from_user(, >engines[n], sizeof(ci))) {
-   err = -EFAULT;
-   goto out_siblings;
-   }
-
-   siblings[n] = intel_engine_lookup_user(i915,
-  ci.engine_class,
-  ci.engine_instance);
-   if (!siblings[n]) {
-   drm_dbg(>drm,
-   "Invalid sibling[%d]: { class:%d, inst:%d }\n",
-   n, ci.engine_class, ci.engine_instance);
-   err = -EINVAL;
-   goto out_siblings;
-   }
-   }
-
-   ce = intel_execlists_create_virtual(siblings, n);
-   if (IS_ERR(ce)) {
-   err = PTR_ERR(ce);
-   goto out_siblings;
-   }
-
-   intel_context_set_gem(ce, set->ctx, null_sseu);
-
-   if (cmpxchg(>engines->engines[idx], NULL, ce)) {
-   intel_context_put(ce);
-   err = -EEXIST;
-   goto out_siblings;
-   }
-
-out_siblings:
-   if (siblings != stack)
-   kfree(siblings);
-
-   return err;
-}
-
-static int
-set_engines__bond(struct i915_user_extension __user *base, void 

[Intel-gfx] [PATCH 27/31] drm/i915/selftests: Take a VM in kernel_context()

2021-06-09 Thread Jason Ekstrand
This better models where we want to go with contexts in general where
things like the VM and engine set are create parameters instead of being
set after the fact.

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 .../drm/i915/gem/selftests/i915_gem_context.c |  4 ++--
 .../gpu/drm/i915/gem/selftests/mock_context.c |  9 -
 .../gpu/drm/i915/gem/selftests/mock_context.h |  4 +++-
 drivers/gpu/drm/i915/gt/selftest_execlists.c  | 20 +--
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c  |  2 +-
 5 files changed, 24 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index 92544a174cc9a..3e59746afdc82 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -680,7 +680,7 @@ static int igt_ctx_exec(void *arg)
struct i915_gem_context *ctx;
struct intel_context *ce;
 
-   ctx = kernel_context(i915);
+   ctx = kernel_context(i915, NULL);
if (IS_ERR(ctx)) {
err = PTR_ERR(ctx);
goto out_file;
@@ -813,7 +813,7 @@ static int igt_shared_ctx_exec(void *arg)
struct i915_gem_context *ctx;
struct intel_context *ce;
 
-   ctx = kernel_context(i915);
+   ctx = kernel_context(i915, NULL);
if (IS_ERR(ctx)) {
err = PTR_ERR(ctx);
goto out_test;
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.c 
b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
index 61aaac4a334cf..500ef27ba4771 100644
--- a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
@@ -150,7 +150,8 @@ live_context_for_engine(struct intel_engine_cs *engine, 
struct file *file)
 }
 
 struct i915_gem_context *
-kernel_context(struct drm_i915_private *i915)
+kernel_context(struct drm_i915_private *i915,
+  struct i915_address_space *vm)
 {
struct i915_gem_context *ctx;
struct i915_gem_proto_context *pc;
@@ -159,6 +160,12 @@ kernel_context(struct drm_i915_private *i915)
if (IS_ERR(pc))
return ERR_CAST(pc);
 
+   if (vm) {
+   if (pc->vm)
+   i915_vm_put(pc->vm);
+   pc->vm = i915_vm_get(vm);
+   }
+
ctx = i915_gem_create_context(i915, pc);
proto_context_close(pc);
if (IS_ERR(ctx))
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.h 
b/drivers/gpu/drm/i915/gem/selftests/mock_context.h
index 2a6121d33352d..7a02fd9b5866a 100644
--- a/drivers/gpu/drm/i915/gem/selftests/mock_context.h
+++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.h
@@ -10,6 +10,7 @@
 struct file;
 struct drm_i915_private;
 struct intel_engine_cs;
+struct i915_address_space;
 
 void mock_init_contexts(struct drm_i915_private *i915);
 
@@ -25,7 +26,8 @@ live_context(struct drm_i915_private *i915, struct file 
*file);
 struct i915_gem_context *
 live_context_for_engine(struct intel_engine_cs *engine, struct file *file);
 
-struct i915_gem_context *kernel_context(struct drm_i915_private *i915);
+struct i915_gem_context *kernel_context(struct drm_i915_private *i915,
+   struct i915_address_space *vm);
 void kernel_context_close(struct i915_gem_context *ctx);
 
 #endif /* !__MOCK_CONTEXT_H */
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c 
b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index 780939005554f..5eedb9b2e08f3 100644
--- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
+++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
@@ -1522,12 +1522,12 @@ static int live_busywait_preempt(void *arg)
 * preempt the busywaits used to synchronise between rings.
 */
 
-   ctx_hi = kernel_context(gt->i915);
+   ctx_hi = kernel_context(gt->i915, NULL);
if (!ctx_hi)
return -ENOMEM;
ctx_hi->sched.priority = I915_CONTEXT_MAX_USER_PRIORITY;
 
-   ctx_lo = kernel_context(gt->i915);
+   ctx_lo = kernel_context(gt->i915, NULL);
if (!ctx_lo)
goto err_ctx_hi;
ctx_lo->sched.priority = I915_CONTEXT_MIN_USER_PRIORITY;
@@ -1724,12 +1724,12 @@ static int live_preempt(void *arg)
if (igt_spinner_init(_lo, gt))
goto err_spin_hi;
 
-   ctx_hi = kernel_context(gt->i915);
+   ctx_hi = kernel_context(gt->i915, NULL);
if (!ctx_hi)
goto err_spin_lo;
ctx_hi->sched.priority = I915_CONTEXT_MAX_USER_PRIORITY;
 
-   ctx_lo = kernel_context(gt->i915);
+   ctx_lo = kernel_context(gt->i915, NULL);
if (!ctx_lo)
goto err_ctx_hi;
ctx_lo->sched.priority = 

[Intel-gfx] [PATCH 23/31] drm/i915/gt: Drop i915_address_space::file (v2)

2021-06-09 Thread Jason Ekstrand
There's a big comment saying how useful it is but no one is using this
for anything anymore.

It was added in 2bfa996e031b ("drm/i915: Store owning file on the
i915_address_space") and used for debugfs at the time as well as telling
the difference between the global GTT and a PPGTT.  In f6e8aa387171
("drm/i915: Report the number of closed vma held by each context in
debugfs") we removed one use of it by switching to a context walk and
comparing with the VM in the context.  Finally, VM stats for debugfs
were entirely nuked in db80a1294c23 ("drm/i915/gem: Remove per-client
stats from debugfs/i915_gem_objects")

v2 (Daniel Vetter):
 - Delete a struct drm_i915_file_private pre-declaration
 - Add a comment to the commit message about history

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c |  9 -
 drivers/gpu/drm/i915/gt/intel_gtt.h | 11 ---
 drivers/gpu/drm/i915/selftests/mock_gtt.c   |  1 -
 3 files changed, 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 7045e3afa7113..5a1402544d48d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1453,17 +1453,10 @@ static int gem_context_register(struct i915_gem_context 
*ctx,
u32 *id)
 {
struct drm_i915_private *i915 = ctx->i915;
-   struct i915_address_space *vm;
int ret;
 
ctx->file_priv = fpriv;
 
-   mutex_lock(>mutex);
-   vm = i915_gem_context_vm(ctx);
-   if (vm)
-   WRITE_ONCE(vm->file, fpriv); /* XXX */
-   mutex_unlock(>mutex);
-
ctx->pid = get_task_pid(current, PIDTYPE_PID);
snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
 current->comm, pid_nr(ctx->pid));
@@ -1562,8 +1555,6 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void 
*data,
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
 
-   ppgtt->vm.file = file_priv;
-
if (args->extensions) {
err = i915_user_extensions(u64_to_user_ptr(args->extensions),
   NULL, 0,
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index edea95b97c36e..474eae483ab0e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -140,7 +140,6 @@ typedef u64 gen8_pte_t;
 
 enum i915_cache_level;
 
-struct drm_i915_file_private;
 struct drm_i915_gem_object;
 struct i915_fence_reg;
 struct i915_vma;
@@ -220,16 +219,6 @@ struct i915_address_space {
struct intel_gt *gt;
struct drm_i915_private *i915;
struct device *dma;
-   /*
-* Every address space belongs to a struct file - except for the global
-* GTT that is owned by the driver (and so @file is set to NULL). In
-* principle, no information should leak from one context to another
-* (or between files/processes etc) unless explicitly shared by the
-* owner. Tracking the owner is important in order to free up per-file
-* objects along with the file, to aide resource tracking, and to
-* assign blame.
-*/
-   struct drm_i915_file_private *file;
u64 total;  /* size addr space maps (ex. 2GB for ggtt) */
u64 reserved;   /* size addr space reserved */
 
diff --git a/drivers/gpu/drm/i915/selftests/mock_gtt.c 
b/drivers/gpu/drm/i915/selftests/mock_gtt.c
index 5c7ae40bba634..cc047ec594f93 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gtt.c
@@ -73,7 +73,6 @@ struct i915_ppgtt *mock_ppgtt(struct drm_i915_private *i915, 
const char *name)
ppgtt->vm.gt = >gt;
ppgtt->vm.i915 = i915;
ppgtt->vm.total = round_down(U64_MAX, PAGE_SIZE);
-   ppgtt->vm.file = ERR_PTR(-ENODEV);
ppgtt->vm.dma = i915->drm.dev;
 
i915_address_space_init(>vm, VM_CLASS_PPGTT);
-- 
2.31.1

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


[Intel-gfx] [PATCH 25/31] drm/i915/gem: Don't allow changing the VM on running contexts (v4)

2021-06-09 Thread Jason Ekstrand
When the APIs were added to manage VMs more directly from userspace, the
questionable choice was made to allow changing out the VM on a context
at any time.  This is horribly racy and there's absolutely no reason why
any userspace would want to do this outside of testing that exact race.
By removing support for CONTEXT_PARAM_VM from ctx_setparam, we make it
impossible to change out the VM after the context has been fully
created.  This lets us delete a bunch of deferred task code as well as a
duplicated (and slightly different) copy of the code which programs the
PPGTT registers.

v2 (Jason Ekstrand):
 - Expand the commit message

v3 (Daniel Vetter):
 - Don't drop the __rcu on the vm pointer

v4 (Jason Ekstrand):
 - Make it more obvious that I915_CONTEXT_PARAM_VM returns -EINVAL

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 263 +-
 .../drm/i915/gem/selftests/i915_gem_context.c | 119 
 .../drm/i915/selftests/i915_mock_selftests.h  |   1 -
 3 files changed, 1 insertion(+), 382 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c4f89e4b1665f..40acecfbbe5b5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1633,120 +1633,6 @@ int i915_gem_vm_destroy_ioctl(struct drm_device *dev, 
void *data,
return 0;
 }
 
-struct context_barrier_task {
-   struct i915_active base;
-   void (*task)(void *data);
-   void *data;
-};
-
-static void cb_retire(struct i915_active *base)
-{
-   struct context_barrier_task *cb = container_of(base, typeof(*cb), base);
-
-   if (cb->task)
-   cb->task(cb->data);
-
-   i915_active_fini(>base);
-   kfree(cb);
-}
-
-I915_SELFTEST_DECLARE(static intel_engine_mask_t context_barrier_inject_fault);
-static int context_barrier_task(struct i915_gem_context *ctx,
-   intel_engine_mask_t engines,
-   bool (*skip)(struct intel_context *ce, void 
*data),
-   int (*pin)(struct intel_context *ce, struct 
i915_gem_ww_ctx *ww, void *data),
-   int (*emit)(struct i915_request *rq, void 
*data),
-   void (*task)(void *data),
-   void *data)
-{
-   struct context_barrier_task *cb;
-   struct i915_gem_engines_iter it;
-   struct i915_gem_engines *e;
-   struct i915_gem_ww_ctx ww;
-   struct intel_context *ce;
-   int err = 0;
-
-   GEM_BUG_ON(!task);
-
-   cb = kmalloc(sizeof(*cb), GFP_KERNEL);
-   if (!cb)
-   return -ENOMEM;
-
-   i915_active_init(>base, NULL, cb_retire, 0);
-   err = i915_active_acquire(>base);
-   if (err) {
-   kfree(cb);
-   return err;
-   }
-
-   e = __context_engines_await(ctx, NULL);
-   if (!e) {
-   i915_active_release(>base);
-   return -ENOENT;
-   }
-
-   for_each_gem_engine(ce, e, it) {
-   struct i915_request *rq;
-
-   if (I915_SELFTEST_ONLY(context_barrier_inject_fault &
-  ce->engine->mask)) {
-   err = -ENXIO;
-   break;
-   }
-
-   if (!(ce->engine->mask & engines))
-   continue;
-
-   if (skip && skip(ce, data))
-   continue;
-
-   i915_gem_ww_ctx_init(, true);
-retry:
-   err = intel_context_pin_ww(ce, );
-   if (err)
-   goto err;
-
-   if (pin)
-   err = pin(ce, , data);
-   if (err)
-   goto err_unpin;
-
-   rq = i915_request_create(ce);
-   if (IS_ERR(rq)) {
-   err = PTR_ERR(rq);
-   goto err_unpin;
-   }
-
-   err = 0;
-   if (emit)
-   err = emit(rq, data);
-   if (err == 0)
-   err = i915_active_add_request(>base, rq);
-
-   i915_request_add(rq);
-err_unpin:
-   intel_context_unpin(ce);
-err:
-   if (err == -EDEADLK) {
-   err = i915_gem_ww_ctx_backoff();
-   if (!err)
-   goto retry;
-   }
-   i915_gem_ww_ctx_fini();
-
-   if (err)
-   break;
-   }
-   i915_sw_fence_complete(>fence);
-
-   cb->task = err ? NULL : task; /* caller needs to unwind instead */
-   cb->data = data;
-
-   i915_active_release(>base);
-
-   return err;
-}
-
 static int get_ppgtt(struct drm_i915_file_private *file_priv,
 struct i915_gem_context *ctx,
 struct 

[Intel-gfx] [PATCH 24/31] drm/i915/gem: Delay context creation (v3)

2021-06-09 Thread Jason Ekstrand
The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM.  The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE.  Currently, everything settable via one is
settable via the other.  While some params are fairly simple and setting
them on a live context is harmless such as the context priority, others
are far trickier such as the VM or the set of engines.  In order to swap
out the VM, for instance, we have to delay until all current in-flight
work is complete, swap in the new VM, and then continue.  This leads to
a plethora of potential race conditions we'd really rather avoid.

In previous patches, we added a i915_gem_proto_context struct which is
capable of storing and tracking all such create parameters.  This commit
delays the creation of the actual context until after the client is done
configuring it with SET_CONTEXT_PARAM.  From the perspective of the
client, it has the same u32 context ID the whole time.  From the
perspective of i915, however, it's an i915_gem_proto_context right up
until the point where we attempt to do something which the proto-context
can't handle.  Then the real context gets created.

This is accomplished via a little xarray dance.  When GEM_CONTEXT_CREATE
is called, we create a proto-context, reserve a slot in context_xa but
leave it NULL, the proto-context in the corresponding slot in
proto_context_xa.  Then, whenever we go to look up a context, we first
check context_xa.  If it's there, we return the i915_gem_context and
we're done.  If it's not, we look in proto_context_xa and, if we find it
there, we create the actual context and kill the proto-context.

In order for this dance to work properly, everything which ever touches
a proto-context is guarded by drm_i915_file_private::proto_context_lock,
including context creation.  Yes, this means context creation now takes
a giant global lock but it can't really be helped and that should never
be on any driver's fast-path anyway.

v2 (Daniel Vetter):
 - Commit message grammatical fixes.
 - Use WARN_ON instead of GEM_BUG_ON
 - Rename lazy_create_context_locked to finalize_create_context_locked
 - Rework the control-flow logic in the setparam ioctl
 - Better documentation all around

v3 (kernel test robot):
 - Make finalize_create_context_locked static

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 203 ++
 drivers/gpu/drm/i915/gem/i915_gem_context.h   |   3 +
 .../gpu/drm/i915/gem/i915_gem_context_types.h |  54 +
 .../gpu/drm/i915/gem/selftests/mock_context.c |   5 +-
 drivers/gpu/drm/i915/i915_drv.h   |  76 +--
 5 files changed, 283 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 5a1402544d48d..c4f89e4b1665f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -278,6 +278,42 @@ proto_context_create(struct drm_i915_private *i915, 
unsigned int flags)
return err;
 }
 
+static int proto_context_register_locked(struct drm_i915_file_private *fpriv,
+struct i915_gem_proto_context *pc,
+u32 *id)
+{
+   int ret;
+   void *old;
+
+   lockdep_assert_held(>proto_context_lock);
+
+   ret = xa_alloc(>context_xa, id, NULL, xa_limit_32b, GFP_KERNEL);
+   if (ret)
+   return ret;
+
+   old = xa_store(>proto_context_xa, *id, pc, GFP_KERNEL);
+   if (xa_is_err(old)) {
+   xa_erase(>context_xa, *id);
+   return xa_err(old);
+   }
+   WARN_ON(old);
+
+   return 0;
+}
+
+static int proto_context_register(struct drm_i915_file_private *fpriv,
+ struct i915_gem_proto_context *pc,
+ u32 *id)
+{
+   int ret;
+
+   mutex_lock(>proto_context_lock);
+   ret = proto_context_register_locked(fpriv, pc, id);
+   mutex_unlock(>proto_context_lock);
+
+   return ret;
+}
+
 static int set_proto_ctx_vm(struct drm_i915_file_private *fpriv,
struct i915_gem_proto_context *pc,
const struct drm_i915_gem_context_param *args)
@@ -1448,12 +1484,12 @@ void i915_gem_init__contexts(struct drm_i915_private 
*i915)
init_contexts(>gem.contexts);
 }
 
-static int gem_context_register(struct i915_gem_context *ctx,
-   struct drm_i915_file_private *fpriv,
-   u32 *id)
+static void gem_context_register(struct i915_gem_context *ctx,
+struct drm_i915_file_private *fpriv,
+u32 id)
 {
struct drm_i915_private *i915 = ctx->i915;
-   int ret;
+   void *old;
 
ctx->file_priv = 

[Intel-gfx] [PATCH 22/31] drm/i915/gem: Return an error ptr from context_lookup

2021-06-09 Thread Jason Ekstrand
We're about to start doing lazy context creation which means contexts
get created in i915_gem_context_lookup and we may start having more
errors than -ENOENT.

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c| 12 ++--
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h|  2 +-
 drivers/gpu/drm/i915/i915_perf.c   |  4 ++--
 4 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 4972b8c91d942..7045e3afa7113 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -2636,8 +2636,8 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
int ret = 0;
 
ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
-   if (!ctx)
-   return -ENOENT;
+   if (IS_ERR(ctx))
+   return PTR_ERR(ctx);
 
switch (args->param) {
case I915_CONTEXT_PARAM_GTT_SIZE:
@@ -2705,8 +2705,8 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
int ret;
 
ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
-   if (!ctx)
-   return -ENOENT;
+   if (IS_ERR(ctx))
+   return PTR_ERR(ctx);
 
ret = ctx_setparam(file_priv, ctx, args);
 
@@ -2725,8 +2725,8 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device 
*dev,
return -EINVAL;
 
ctx = i915_gem_context_lookup(file->driver_priv, args->ctx_id);
-   if (!ctx)
-   return -ENOENT;
+   if (IS_ERR(ctx))
+   return PTR_ERR(ctx);
 
/*
 * We opt for unserialised reads here. This may result in tearing
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 720487ad6a5a4..4b4d3de61a157 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -739,8 +739,8 @@ static int eb_select_context(struct i915_execbuffer *eb)
struct i915_gem_context *ctx;
 
ctx = i915_gem_context_lookup(eb->file->driver_priv, eb->args->rsvd1);
-   if (unlikely(!ctx))
-   return -ENOENT;
+   if (unlikely(IS_ERR(ctx)))
+   return PTR_ERR(ctx);
 
eb->gem_context = ctx;
if (rcu_access_pointer(ctx->vm))
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b191946229746..6aa91b795784c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1861,7 +1861,7 @@ i915_gem_context_lookup(struct drm_i915_file_private 
*file_priv, u32 id)
ctx = NULL;
rcu_read_unlock();
 
-   return ctx;
+   return ctx ? ctx : ERR_PTR(-ENOENT);
 }
 
 static inline struct i915_address_space *
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 9f94914958c39..b4ec114a4698b 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3414,10 +3414,10 @@ i915_perf_open_ioctl_locked(struct i915_perf *perf,
struct drm_i915_file_private *file_priv = file->driver_priv;
 
specific_ctx = i915_gem_context_lookup(file_priv, ctx_handle);
-   if (!specific_ctx) {
+   if (IS_ERR(specific_ctx)) {
DRM_DEBUG("Failed to look up context with ID %u for 
opening perf stream\n",
  ctx_handle);
-   ret = -ENOENT;
+   ret = PTR_ERR(specific_ctx);
goto err;
}
}
-- 
2.31.1

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


[Intel-gfx] [PATCH 21/31] drm/i915/gem: Use the proto-context to handle create parameters (v4)

2021-06-09 Thread Jason Ekstrand
This means that the proto-context needs to grow support for engine
configuration information as well as setparam logic.  Fortunately, we'll
be deleting a lot of setparam logic on the primary context shortly so it
will hopefully balance out.

There's an extra bit of fun here when it comes to setting SSEU and the
way it interacts with PARAM_ENGINES.  Unfortunately, thanks to
SET_CONTEXT_PARAM and not being allowed to pick the order in which we
handle certain parameters, we have think about those interactions.

v2 (Daniel Vetter):
 - Add a proto_context_free_user_engines helper
 - Comment on SSEU in the commit message
 - Use proto_context_set_persistence in set_proto_ctx_param

v3 (Daniel Vetter):
 - Fix a doc comment
 - Do an explicit HAS_FULL_PPGTT check in set_proto_ctx_vm instead of
   relying on pc->vm != NULL.
 - Handle errors for CONTEXT_PARAM_PERSISTENCE
 - Don't allow more resetting user engines
 - Rework initialization of UCONTEXT_PERSISTENCE

v4 (Jason Ekstrand):
 - Move hand-rolled initialization of UCONTEXT_PERSISTENCE to an
   earlier patch

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 536 +-
 .../gpu/drm/i915/gem/i915_gem_context_types.h |  58 ++
 2 files changed, 577 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c9bae1a1726e1..4972b8c91d942 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -193,8 +193,15 @@ static int validate_priority(struct drm_i915_private *i915,
 
 static void proto_context_close(struct i915_gem_proto_context *pc)
 {
+   int i;
+
if (pc->vm)
i915_vm_put(pc->vm);
+   if (pc->user_engines) {
+   for (i = 0; i < pc->num_user_engines; i++)
+   kfree(pc->user_engines[i].siblings);
+   kfree(pc->user_engines);
+   }
kfree(pc);
 }
 
@@ -248,6 +255,8 @@ proto_context_create(struct drm_i915_private *i915, 
unsigned int flags)
if (!pc)
return ERR_PTR(-ENOMEM);
 
+   pc->num_user_engines = -1;
+   pc->user_engines = NULL;
pc->user_flags = BIT(UCONTEXT_BANNABLE) |
 BIT(UCONTEXT_RECOVERABLE);
if (i915->params.enable_hangcheck)
@@ -269,6 +278,430 @@ proto_context_create(struct drm_i915_private *i915, 
unsigned int flags)
return err;
 }
 
+static int set_proto_ctx_vm(struct drm_i915_file_private *fpriv,
+   struct i915_gem_proto_context *pc,
+   const struct drm_i915_gem_context_param *args)
+{
+   struct drm_i915_private *i915 = fpriv->dev_priv;
+   struct i915_address_space *vm;
+
+   if (args->size)
+   return -EINVAL;
+
+   if (!HAS_FULL_PPGTT(i915))
+   return -ENODEV;
+
+   if (upper_32_bits(args->value))
+   return -ENOENT;
+
+   vm = i915_gem_vm_lookup(fpriv, args->value);
+   if (!vm)
+   return -ENOENT;
+
+   if (pc->vm)
+   i915_vm_put(pc->vm);
+   pc->vm = vm;
+
+   return 0;
+}
+
+struct set_proto_ctx_engines {
+   struct drm_i915_private *i915;
+   unsigned num_engines;
+   struct i915_gem_proto_engine *engines;
+};
+
+static int
+set_proto_ctx_engines_balance(struct i915_user_extension __user *base,
+ void *data)
+{
+   struct i915_context_engines_load_balance __user *ext =
+   container_of_user(base, typeof(*ext), base);
+   const struct set_proto_ctx_engines *set = data;
+   struct drm_i915_private *i915 = set->i915;
+   struct intel_engine_cs **siblings;
+   u16 num_siblings, idx;
+   unsigned int n;
+   int err;
+
+   if (!HAS_EXECLISTS(i915))
+   return -ENODEV;
+
+   if (intel_uc_uses_guc_submission(>gt.uc))
+   return -ENODEV; /* not implement yet */
+
+   if (get_user(idx, >engine_index))
+   return -EFAULT;
+
+   if (idx >= set->num_engines) {
+   drm_dbg(>drm, "Invalid placement value, %d >= %d\n",
+   idx, set->num_engines);
+   return -EINVAL;
+   }
+
+   idx = array_index_nospec(idx, set->num_engines);
+   if (set->engines[idx].type != I915_GEM_ENGINE_TYPE_INVALID) {
+   drm_dbg(>drm,
+   "Invalid placement[%d], already occupied\n", idx);
+   return -EEXIST;
+   }
+
+   if (get_user(num_siblings, >num_siblings))
+   return -EFAULT;
+
+   err = check_user_mbz(>flags);
+   if (err)
+   return err;
+
+   err = check_user_mbz(>mbz64);
+   if (err)
+   return err;
+
+   if (num_siblings == 0)
+   return 0;
+
+   siblings = kmalloc_array(num_siblings, sizeof(*siblings), GFP_KERNEL);
+   if (!siblings)
+ 

[Intel-gfx] [PATCH 20/31] drm/i915/gem: Make an alignment check more sensible

2021-06-09 Thread Jason Ekstrand
What we really want to check is that size of the engines array, i.e.
args->size - sizeof(*user) is divisible by the element size, i.e.
sizeof(*user->engines) because that's what's required for computing the
array length right below the check.  However, we're currently not doing
this and instead doing a compile-time check that sizeof(*user) is
divisible by sizeof(*user->engines) and avoiding the subtraction.  As
far as I can tell, the only reason for the more confusing pair of checks
is to avoid a single subtraction of a constant.

The other thing the BUILD_BUG_ON might be trying to implicitly check is
that offsetof(user->engines) == sizeof(*user) and we don't have any
weird padding throwing us off.  However, that's not the check it's doing
and it's not even a reliable way to do that check.

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 +--
 1 file changed, 1 insertion(+), 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 8e7c0e3f070ed..c9bae1a1726e1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1764,9 +1764,8 @@ set_engines(struct i915_gem_context *ctx,
goto replace;
}
 
-   BUILD_BUG_ON(!IS_ALIGNED(sizeof(*user), sizeof(*user->engines)));
if (args->size < sizeof(*user) ||
-   !IS_ALIGNED(args->size, sizeof(*user->engines))) {
+   !IS_ALIGNED(args->size -  sizeof(*user), sizeof(*user->engines))) {
drm_dbg(>drm, "Invalid size for engine array: %d\n",
args->size);
return -EINVAL;
-- 
2.31.1

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


[Intel-gfx] [PATCH 17/31] drm/i915/gem: Rework error handling in default_engines

2021-06-09 Thread Jason Ekstrand
Since free_engines works for partially constructed engine sets, we can
use the usual goto pattern.

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index f44faad296249..93579fa0324d1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -407,7 +407,7 @@ static struct i915_gem_engines *default_engines(struct 
i915_gem_context *ctx)
 {
const struct intel_gt *gt = >i915->gt;
struct intel_engine_cs *engine;
-   struct i915_gem_engines *e;
+   struct i915_gem_engines *e, *err;
enum intel_engine_id id;
 
e = alloc_engines(I915_NUM_ENGINES);
@@ -425,18 +425,21 @@ static struct i915_gem_engines *default_engines(struct 
i915_gem_context *ctx)
 
ce = intel_context_create(engine);
if (IS_ERR(ce)) {
-   __free_engines(e, e->num_engines + 1);
-   return ERR_CAST(ce);
+   err = ERR_CAST(ce);
+   goto free_engines;
}
 
intel_context_set_gem(ce, ctx);
 
e->engines[engine->legacy_idx] = ce;
-   e->num_engines = max(e->num_engines, engine->legacy_idx);
+   e->num_engines = max(e->num_engines, engine->legacy_idx + 1);
}
-   e->num_engines++;
 
return e;
+
+free_engines:
+   free_engines(e);
+   return err;
 }
 
 void i915_gem_context_release(struct kref *ref)
-- 
2.31.1

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


[Intel-gfx] [PATCH 19/31] drm/i915: Add an i915_gem_vm_lookup helper

2021-06-09 Thread Jason Ekstrand
This is the VM equivalent of i915_gem_context_lookup.  It's only used
once in this patch but future patches will need to duplicate this lookup
code so it's better to have it in a helper.

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c |  6 +-
 drivers/gpu/drm/i915/i915_drv.h | 14 ++
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index e62482477c771..8e7c0e3f070ed 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1352,11 +1352,7 @@ static int set_ppgtt(struct drm_i915_file_private 
*file_priv,
if (upper_32_bits(args->value))
return -ENOENT;
 
-   rcu_read_lock();
-   vm = xa_load(_priv->vm_xa, args->value);
-   if (vm && !kref_get_unless_zero(>ref))
-   vm = NULL;
-   rcu_read_unlock();
+   vm = i915_gem_vm_lookup(file_priv, args->value);
if (!vm)
return -ENOENT;
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fed14ffc52437..b191946229746 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1864,6 +1864,20 @@ i915_gem_context_lookup(struct drm_i915_file_private 
*file_priv, u32 id)
return ctx;
 }
 
+static inline struct i915_address_space *
+i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id)
+{
+   struct i915_address_space *vm;
+
+   rcu_read_lock();
+   vm = xa_load(_priv->vm_xa, id);
+   if (vm && !kref_get_unless_zero(>ref))
+   vm = NULL;
+   rcu_read_unlock();
+
+   return vm;
+}
+
 /* i915_gem_evict.c */
 int __must_check i915_gem_evict_something(struct i915_address_space *vm,
  u64 min_size, u64 alignment,
-- 
2.31.1

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


[Intel-gfx] [PATCH 18/31] drm/i915/gem: Optionally set SSEU in intel_context_set_gem

2021-06-09 Thread Jason Ekstrand
For now this is a no-op because everyone passes in a null SSEU but it
lets us get some of the error handling and selftest refactoring plumbed
through.

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 41 +++
 .../gpu/drm/i915/gem/selftests/mock_context.c |  6 ++-
 2 files changed, 36 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 93579fa0324d1..e62482477c771 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -307,9 +307,12 @@ context_get_vm_rcu(struct i915_gem_context *ctx)
} while (1);
 }
 
-static void intel_context_set_gem(struct intel_context *ce,
- struct i915_gem_context *ctx)
+static int intel_context_set_gem(struct intel_context *ce,
+struct i915_gem_context *ctx,
+struct intel_sseu sseu)
 {
+   int ret = 0;
+
GEM_BUG_ON(rcu_access_pointer(ce->gem_context));
RCU_INIT_POINTER(ce->gem_context, ctx);
 
@@ -336,6 +339,12 @@ static void intel_context_set_gem(struct intel_context *ce,
 
intel_context_set_watchdog_us(ce, (u64)timeout_ms * 1000);
}
+
+   /* A valid SSEU has no zero fields */
+   if (sseu.slice_mask && !WARN_ON(ce->engine->class != RENDER_CLASS))
+   ret = intel_context_reconfigure_sseu(ce, sseu);
+
+   return ret;
 }
 
 static void __free_engines(struct i915_gem_engines *e, unsigned int count)
@@ -403,7 +412,8 @@ static struct i915_gem_engines *alloc_engines(unsigned int 
count)
return e;
 }
 
-static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx)
+static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx,
+   struct intel_sseu rcs_sseu)
 {
const struct intel_gt *gt = >i915->gt;
struct intel_engine_cs *engine;
@@ -416,6 +426,8 @@ static struct i915_gem_engines *default_engines(struct 
i915_gem_context *ctx)
 
for_each_engine(engine, gt, id) {
struct intel_context *ce;
+   struct intel_sseu sseu = {};
+   int ret;
 
if (engine->legacy_idx == INVALID_ENGINE)
continue;
@@ -429,10 +441,18 @@ static struct i915_gem_engines *default_engines(struct 
i915_gem_context *ctx)
goto free_engines;
}
 
-   intel_context_set_gem(ce, ctx);
-
e->engines[engine->legacy_idx] = ce;
e->num_engines = max(e->num_engines, engine->legacy_idx + 1);
+
+   if (engine->class == RENDER_CLASS)
+   sseu = rcs_sseu;
+
+   ret = intel_context_set_gem(ce, ctx, sseu);
+   if (ret) {
+   err = ERR_PTR(ret);
+   goto free_engines;
+   }
+
}
 
return e;
@@ -746,6 +766,7 @@ __create_context(struct drm_i915_private *i915,
 {
struct i915_gem_context *ctx;
struct i915_gem_engines *e;
+   struct intel_sseu null_sseu = {};
int err;
int i;
 
@@ -763,7 +784,7 @@ __create_context(struct drm_i915_private *i915,
INIT_LIST_HEAD(>stale.engines);
 
mutex_init(>engines_mutex);
-   e = default_engines(ctx);
+   e = default_engines(ctx, null_sseu);
if (IS_ERR(e)) {
err = PTR_ERR(e);
goto err_free;
@@ -1549,6 +1570,7 @@ set_engines__load_balance(struct i915_user_extension 
__user *base, void *data)
struct intel_engine_cs *stack[16];
struct intel_engine_cs **siblings;
struct intel_context *ce;
+   struct intel_sseu null_sseu = {};
u16 num_siblings, idx;
unsigned int n;
int err;
@@ -1621,7 +1643,7 @@ set_engines__load_balance(struct i915_user_extension 
__user *base, void *data)
goto out_siblings;
}
 
-   intel_context_set_gem(ce, set->ctx);
+   intel_context_set_gem(ce, set->ctx, null_sseu);
 
if (cmpxchg(>engines->engines[idx], NULL, ce)) {
intel_context_put(ce);
@@ -1729,6 +1751,7 @@ set_engines(struct i915_gem_context *ctx,
struct drm_i915_private *i915 = ctx->i915;
struct i915_context_param_engines __user *user =
u64_to_user_ptr(args->value);
+   struct intel_sseu null_sseu = {};
struct set_engines set = { .ctx = ctx };
unsigned int num_engines, n;
u64 extensions;
@@ -1738,7 +1761,7 @@ set_engines(struct i915_gem_context *ctx,
if (!i915_gem_context_user_engines(ctx))
return 0;
 
-   set.engines = default_engines(ctx);
+   set.engines = default_engines(ctx, null_sseu);
if (IS_ERR(set.engines))
 

[Intel-gfx] [PATCH 16/31] drm/i915/gem: Add an intermediate proto_context struct (v5)

2021-06-09 Thread Jason Ekstrand
The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM.  The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE.  Currently, everything settable via one is
settable via the other.  While some params are fairly simple and setting
them on a live context is harmless such the context priority, others are
far trickier such as the VM or the set of engines.  In order to swap out
the VM, for instance, we have to delay until all current in-flight work
is complete, swap in the new VM, and then continue.  This leads to a
plethora of potential race conditions we'd really rather avoid.

Unfortunately, both methods of setting the VM and the engine set are in
active use today so we can't simply disallow setting the VM or engine
set vial SET_CONTEXT_PARAM.  In order to work around this wart, this
commit adds a proto-context struct which contains all the context create
parameters.

v2 (Daniel Vetter):
 - Better commit message
 - Use __set/clear_bit instead of set/clear_bit because there's no race
   and we don't need the atomics

v3 (Daniel Vetter):
 - Use manual bitops and BIT() instead of __set_bit

v4 (Daniel Vetter):
 - Add a changelog to the commit message
 - Better hyperlinking in docs
 - Create the default PPGTT in i915_gem_create_context

v5 (Daniel Vetter):
 - Hand-roll the initialization of UCONTEXT_PERSISTENCE

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 125 +++---
 .../gpu/drm/i915/gem/i915_gem_context_types.h |  22 +++
 .../gpu/drm/i915/gem/selftests/mock_context.c |  16 ++-
 3 files changed, 146 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index f9a6eac78c0ae..f44faad296249 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -191,6 +191,84 @@ static int validate_priority(struct drm_i915_private *i915,
return 0;
 }
 
+static void proto_context_close(struct i915_gem_proto_context *pc)
+{
+   if (pc->vm)
+   i915_vm_put(pc->vm);
+   kfree(pc);
+}
+
+static int proto_context_set_persistence(struct drm_i915_private *i915,
+struct i915_gem_proto_context *pc,
+bool persist)
+{
+   if (persist) {
+   /*
+* Only contexts that are short-lived [that will expire or be
+* reset] are allowed to survive past termination. We require
+* hangcheck to ensure that the persistent requests are healthy.
+*/
+   if (!i915->params.enable_hangcheck)
+   return -EINVAL;
+
+   pc->user_flags |= BIT(UCONTEXT_PERSISTENCE);
+   } else {
+   /* To cancel a context we use "preempt-to-idle" */
+   if (!(i915->caps.scheduler & I915_SCHEDULER_CAP_PREEMPTION))
+   return -ENODEV;
+
+   /*
+* If the cancel fails, we then need to reset, cleanly!
+*
+* If the per-engine reset fails, all hope is lost! We resort
+* to a full GPU reset in that unlikely case, but realistically
+* if the engine could not reset, the full reset does not fare
+* much better. The damage has been done.
+*
+* However, if we cannot reset an engine by itself, we cannot
+* cleanup a hanging persistent context without causing
+* colateral damage, and we should not pretend we can by
+* exposing the interface.
+*/
+   if (!intel_has_reset_engine(>gt))
+   return -ENODEV;
+
+   pc->user_flags &= ~BIT(UCONTEXT_PERSISTENCE);
+   }
+
+   return 0;
+}
+
+static struct i915_gem_proto_context *
+proto_context_create(struct drm_i915_private *i915, unsigned int flags)
+{
+   struct i915_gem_proto_context *pc, *err;
+
+   pc = kzalloc(sizeof(*pc), GFP_KERNEL);
+   if (!pc)
+   return ERR_PTR(-ENOMEM);
+
+   pc->user_flags = BIT(UCONTEXT_BANNABLE) |
+BIT(UCONTEXT_RECOVERABLE);
+   if (i915->params.enable_hangcheck)
+   pc->user_flags |= BIT(UCONTEXT_PERSISTENCE);
+   pc->sched.priority = I915_PRIORITY_NORMAL;
+
+   if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
+   if (!HAS_EXECLISTS(i915)) {
+   err = ERR_PTR(-EINVAL);
+   goto proto_close;
+   }
+   pc->single_timeline = true;
+   }
+
+   return pc;
+
+proto_close:
+   proto_context_close(pc);
+   return err;
+}
+
 static struct i915_address_space *
 context_get_vm_rcu(struct i915_gem_context 

[Intel-gfx] [PATCH 15/31] drm/i915: Add gem/i915_gem_context.h to the docs

2021-06-09 Thread Jason Ekstrand
In order to prevent kernel doc warnings, also fill out docs for any
missing fields and fix those that forgot the "@".

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 Documentation/gpu/i915.rst|  2 +
 .../gpu/drm/i915/gem/i915_gem_context_types.h | 43 ---
 2 files changed, 38 insertions(+), 7 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 42ce0196930a1..b452f84c9ef2b 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -422,6 +422,8 @@ Batchbuffer Parsing
 User Batchbuffer Execution
 --
 
+.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+
 .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
:doc: User command execution
 
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 df76767f0c41b..5f0673a2129f9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -30,19 +30,39 @@ struct i915_address_space;
 struct intel_timeline;
 struct intel_ring;
 
+/**
+ * struct i915_gem_engines - A set of engines
+ */
 struct i915_gem_engines {
union {
+   /** @link: Link in i915_gem_context::stale::engines */
struct list_head link;
+
+   /** @rcu: RCU to use when freeing */
struct rcu_head rcu;
};
+
+   /** @fence: Fence used for delayed destruction of engines */
struct i915_sw_fence fence;
+
+   /** @ctx: i915_gem_context backpointer */
struct i915_gem_context *ctx;
+
+   /** @num_engines: Number of engines in this set */
unsigned int num_engines;
+
+   /** @engines: Array of engines */
struct intel_context *engines[];
 };
 
+/**
+ * struct i915_gem_engines_iter - Iterator for an i915_gem_engines set
+ */
 struct i915_gem_engines_iter {
+   /** @idx: Index into i915_gem_engines::engines */
unsigned int idx;
+
+   /** @engines: Engine set being iterated */
const struct i915_gem_engines *engines;
 };
 
@@ -53,10 +73,10 @@ struct i915_gem_engines_iter {
  * logical hardware state for a particular client.
  */
 struct i915_gem_context {
-   /** i915: i915 device backpointer */
+   /** @i915: i915 device backpointer */
struct drm_i915_private *i915;
 
-   /** file_priv: owning file descriptor */
+   /** @file_priv: owning file descriptor */
struct drm_i915_file_private *file_priv;
 
/**
@@ -81,7 +101,9 @@ struct i915_gem_context {
 * CONTEXT_USER_ENGINES flag is set).
 */
struct i915_gem_engines __rcu *engines;
-   struct mutex engines_mutex; /* guards writes to engines */
+
+   /** @engines_mutex: guards writes to engines */
+   struct mutex engines_mutex;
 
/**
 * @syncobj: Shared timeline syncobj
@@ -118,7 +140,7 @@ struct i915_gem_context {
 */
struct pid *pid;
 
-   /** link: place with _i915_private.context_list */
+   /** @link: place with _i915_private.context_list */
struct list_head link;
 
/**
@@ -153,11 +175,13 @@ struct i915_gem_context {
 #define CONTEXT_CLOSED 0
 #define CONTEXT_USER_ENGINES   1
 
+   /** @mutex: guards everything that isn't engines or handles_vma */
struct mutex mutex;
 
+   /** @sched: scheduler parameters */
struct i915_sched_attr sched;
 
-   /** guilty_count: How many times this context has caused a GPU hang. */
+   /** @guilty_count: How many times this context has caused a GPU hang. */
atomic_t guilty_count;
/**
 * @active_count: How many times this context was active during a GPU
@@ -171,15 +195,17 @@ struct i915_gem_context {
unsigned long hang_timestamp[2];
 #define CONTEXT_FAST_HANG_JIFFIES (120 * HZ) /* 3 hangs within 120s? Banned! */
 
-   /** remap_slice: Bitmask of cache lines that need remapping */
+   /** @remap_slice: Bitmask of cache lines that need remapping */
u8 remap_slice;
 
/**
-* handles_vma: rbtree to look up our context specific obj/vma for
+* @handles_vma: rbtree to look up our context specific obj/vma for
 * the user handle. (user handles are per fd, but the binding is
 * per vm, which may be one per context or shared with the global GTT)
 */
struct radix_tree_root handles_vma;
+
+   /** @lut_mutex: Locks handles_vma */
struct mutex lut_mutex;
 
/**
@@ -191,8 +217,11 @@ struct i915_gem_context {
 */
char name[TASK_COMM_LEN + 8];
 
+   /** @stale: tracks stale engines to be destroyed */
struct {
+   /** @lock: guards engines */
spinlock_t lock;
+   /** @engines: list of stale engines */
struct list_head engines;
} stale;
 };

[Intel-gfx] [PATCH 14/31] drm/i915/gem: Add a separate validate_priority helper

2021-06-09 Thread Jason Ekstrand
With the proto-context stuff added later in this series, we end up
having to duplicate set_priority.  This lets us avoid duplicating the
validation logic.

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 +
 1 file changed, 27 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 61fe6d18d4068..f9a6eac78c0ae 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -169,6 +169,28 @@ lookup_user_engine(struct i915_gem_context *ctx,
return i915_gem_context_get_engine(ctx, idx);
 }
 
+static int validate_priority(struct drm_i915_private *i915,
+const struct drm_i915_gem_context_param *args)
+{
+   s64 priority = args->value;
+
+   if (args->size)
+   return -EINVAL;
+
+   if (!(i915->caps.scheduler & I915_SCHEDULER_CAP_PRIORITY))
+   return -ENODEV;
+
+   if (priority > I915_CONTEXT_MAX_USER_PRIORITY ||
+   priority < I915_CONTEXT_MIN_USER_PRIORITY)
+   return -EINVAL;
+
+   if (priority > I915_CONTEXT_DEFAULT_PRIORITY &&
+   !capable(CAP_SYS_NICE))
+   return -EPERM;
+
+   return 0;
+}
+
 static struct i915_address_space *
 context_get_vm_rcu(struct i915_gem_context *ctx)
 {
@@ -1744,23 +1766,13 @@ static void __apply_priority(struct intel_context *ce, 
void *arg)
 static int set_priority(struct i915_gem_context *ctx,
const struct drm_i915_gem_context_param *args)
 {
-   s64 priority = args->value;
-
-   if (args->size)
-   return -EINVAL;
-
-   if (!(ctx->i915->caps.scheduler & I915_SCHEDULER_CAP_PRIORITY))
-   return -ENODEV;
-
-   if (priority > I915_CONTEXT_MAX_USER_PRIORITY ||
-   priority < I915_CONTEXT_MIN_USER_PRIORITY)
-   return -EINVAL;
+   int err;
 
-   if (priority > I915_CONTEXT_DEFAULT_PRIORITY &&
-   !capable(CAP_SYS_NICE))
-   return -EPERM;
+   err = validate_priority(ctx->i915, args);
+   if (err)
+   return err;
 
-   ctx->sched.priority = priority;
+   ctx->sched.priority = args->value;
context_apply_all(ctx, __apply_priority, ctx);
 
return 0;
-- 
2.31.1

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


[Intel-gfx] [PATCH 12/31] drm/i915/gem: Disallow creating contexts with too many engines

2021-06-09 Thread Jason Ekstrand
There's no sense in allowing userspace to create more engines than it
can possibly access via execbuf.

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 5eca91ded3423..0ba8506fb966f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1639,11 +1639,11 @@ set_engines(struct i915_gem_context *ctx,
return -EINVAL;
}
 
-   /*
-* Note that I915_EXEC_RING_MASK limits execbuf to only using the
-* first 64 engines defined here.
-*/
num_engines = (args->size - sizeof(*user)) / sizeof(*user->engines);
+   /* RING_MASK has no shift so we can use it directly here */
+   if (num_engines > I915_EXEC_RING_MASK + 1)
+   return -EINVAL;
+
set.engines = alloc_engines(num_engines);
if (!set.engines)
return -ENOMEM;
-- 
2.31.1

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


[Intel-gfx] [PATCH 13/31] drm/i915: Stop manually RCU banging in reset_stats_ioctl (v2)

2021-06-09 Thread Jason Ekstrand
As far as I can tell, the only real reason for this is to avoid taking a
reference to the i915_gem_context.  The cost of those two atomics
probably pales in comparison to the cost of the ioctl itself so we're
really not buying ourselves anything here.  We're about to make context
lookup a tiny bit more complicated, so let's get rid of the one hand-
rolled case.

Some usermode drivers such as our Vulkan driver call GET_RESET_STATS on
every execbuf so the perf here could theoretically be an issue.  If this
ever does become a performance issue for any such userspace drivers,
they can use set CONTEXT_PARAM_RECOVERABLE to false and look for -EIO
coming from execbuf to check for hangs instead.

v2 (Daniel Vetter):
 - Add a comment in the commit message about recoverable contexts

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
 drivers/gpu/drm/i915/i915_drv.h |  8 +---
 2 files changed, 5 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 0ba8506fb966f..61fe6d18d4068 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -2090,16 +2090,13 @@ int i915_gem_context_reset_stats_ioctl(struct 
drm_device *dev,
struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_reset_stats *args = data;
struct i915_gem_context *ctx;
-   int ret;
 
if (args->flags || args->pad)
return -EINVAL;
 
-   ret = -ENOENT;
-   rcu_read_lock();
-   ctx = __i915_gem_context_lookup_rcu(file->driver_priv, args->ctx_id);
+   ctx = i915_gem_context_lookup(file->driver_priv, args->ctx_id);
if (!ctx)
-   goto out;
+   return -ENOENT;
 
/*
 * We opt for unserialised reads here. This may result in tearing
@@ -2116,10 +2113,8 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device 
*dev,
args->batch_active = atomic_read(>guilty_count);
args->batch_pending = atomic_read(>active_count);
 
-   ret = 0;
-out:
-   rcu_read_unlock();
-   return ret;
+   i915_gem_context_put(ctx);
+   return 0;
 }
 
 /* GEM context-engines iterator: for_each_gem_engine() */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 38ff2fb897443..fed14ffc52437 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1850,19 +1850,13 @@ struct drm_gem_object *i915_gem_prime_import(struct 
drm_device *dev,
 
 struct dma_buf *i915_gem_prime_export(struct drm_gem_object *gem_obj, int 
flags);
 
-static inline struct i915_gem_context *
-__i915_gem_context_lookup_rcu(struct drm_i915_file_private *file_priv, u32 id)
-{
-   return xa_load(_priv->context_xa, id);
-}
-
 static inline struct i915_gem_context *
 i915_gem_context_lookup(struct drm_i915_file_private *file_priv, u32 id)
 {
struct i915_gem_context *ctx;
 
rcu_read_lock();
-   ctx = __i915_gem_context_lookup_rcu(file_priv, id);
+   ctx = xa_load(_priv->context_xa, id);
if (ctx && !kref_get_unless_zero(>ref))
ctx = NULL;
rcu_read_unlock();
-- 
2.31.1

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


[Intel-gfx] [PATCH 11/31] drm/i915/request: Remove the hook from await_execution

2021-06-09 Thread Jason Ekstrand
This was only ever used for FENCE_SUBMIT automatic engine selection
which was removed in the previous commit.

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  3 +-
 drivers/gpu/drm/i915/i915_request.c   | 42 ---
 drivers/gpu/drm/i915/i915_request.h   |  4 +-
 3 files changed, 9 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 88e7cbf8fc5f8..720487ad6a5a4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -3473,8 +3473,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (in_fence) {
if (args->flags & I915_EXEC_FENCE_SUBMIT)
err = i915_request_await_execution(eb.request,
-  in_fence,
-  NULL);
+  in_fence);
else
err = i915_request_await_dma_fence(eb.request,
   in_fence);
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 1014c71cf7f52..bb142f944f550 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -49,7 +49,6 @@
 struct execute_cb {
struct irq_work work;
struct i915_sw_fence *fence;
-   void (*hook)(struct i915_request *rq, struct dma_fence *signal);
struct i915_request *signal;
 };
 
@@ -180,17 +179,6 @@ static void irq_execute_cb(struct irq_work *wrk)
kmem_cache_free(global.slab_execute_cbs, cb);
 }
 
-static void irq_execute_cb_hook(struct irq_work *wrk)
-{
-   struct execute_cb *cb = container_of(wrk, typeof(*cb), work);
-
-   cb->hook(container_of(cb->fence, struct i915_request, submit),
->signal->fence);
-   i915_request_put(cb->signal);
-
-   irq_execute_cb(wrk);
-}
-
 static __always_inline void
 __notify_execute_cb(struct i915_request *rq, bool (*fn)(struct irq_work *wrk))
 {
@@ -517,17 +505,12 @@ static bool __request_in_flight(const struct i915_request 
*signal)
 static int
 __await_execution(struct i915_request *rq,
  struct i915_request *signal,
- void (*hook)(struct i915_request *rq,
-  struct dma_fence *signal),
  gfp_t gfp)
 {
struct execute_cb *cb;
 
-   if (i915_request_is_active(signal)) {
-   if (hook)
-   hook(rq, >fence);
+   if (i915_request_is_active(signal))
return 0;
-   }
 
cb = kmem_cache_alloc(global.slab_execute_cbs, gfp);
if (!cb)
@@ -537,12 +520,6 @@ __await_execution(struct i915_request *rq,
i915_sw_fence_await(cb->fence);
init_irq_work(>work, irq_execute_cb);
 
-   if (hook) {
-   cb->hook = hook;
-   cb->signal = i915_request_get(signal);
-   cb->work.func = irq_execute_cb_hook;
-   }
-
/*
 * Register the callback first, then see if the signaler is already
 * active. This ensures that if we race with the
@@ -1253,7 +1230,7 @@ emit_semaphore_wait(struct i915_request *to,
goto await_fence;
 
/* Only submit our spinner after the signaler is running! */
-   if (__await_execution(to, from, NULL, gfp))
+   if (__await_execution(to, from, gfp))
goto await_fence;
 
if (__emit_semaphore_wait(to, from, from->fence.seqno))
@@ -1284,16 +1261,14 @@ static int intel_timeline_sync_set_start(struct 
intel_timeline *tl,
 
 static int
 __i915_request_await_execution(struct i915_request *to,
-  struct i915_request *from,
-  void (*hook)(struct i915_request *rq,
-   struct dma_fence *signal))
+  struct i915_request *from)
 {
int err;
 
GEM_BUG_ON(intel_context_is_barrier(from->context));
 
/* Submit both requests at the same time */
-   err = __await_execution(to, from, hook, I915_FENCE_GFP);
+   err = __await_execution(to, from, I915_FENCE_GFP);
if (err)
return err;
 
@@ -1406,9 +1381,7 @@ i915_request_await_external(struct i915_request *rq, 
struct dma_fence *fence)
 
 int
 i915_request_await_execution(struct i915_request *rq,
-struct dma_fence *fence,
-void (*hook)(struct i915_request *rq,
- struct dma_fence *signal))
+struct dma_fence *fence)
 {
struct dma_fence **child = 
unsigned int nchild = 1;
@@ -1441,8 +1414,7 @@ i915_request_await_execution(struct 

[Intel-gfx] [PATCH 10/31] drm/i915/gem: Remove engine auto-magic with FENCE_SUBMIT (v2)

2021-06-09 Thread Jason Ekstrand
Even though FENCE_SUBMIT is only documented to wait until the request in
the in-fence starts instead of waiting until it completes, it has a bit
more magic than that.  If FENCE_SUBMIT is used to submit something to a
balanced engine, we would wait to assign engines until the primary
request was ready to start and then attempt to assign it to a different
engine than the primary.  There is an IGT test (the bonded-slice subtest
of gem_exec_balancer) which exercises this by submitting a primary batch
to a specific VCS and then using FENCE_SUBMIT to submit a secondary
which can run on any VCS and have i915 figure out which VCS to run it on
such that they can run in parallel.

However, this functionality has never been used in the real world.  The
media driver (the only user of FENCE_SUBMIT) always picks exactly two
physical engines to bond and never asks us to pick which to use.

v2 (Daniel Vetter):
 - Mention the exact IGT test this breaks

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c  |  2 +-
 drivers/gpu/drm/i915/gt/intel_engine_types.h|  7 ---
 .../drm/i915/gt/intel_execlists_submission.c| 17 -
 3 files changed, 1 insertion(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index a6a3b67aa0019..88e7cbf8fc5f8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -3474,7 +3474,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (args->flags & I915_EXEC_FENCE_SUBMIT)
err = i915_request_await_execution(eb.request,
   in_fence,
-  
eb.engine->bond_execute);
+  NULL);
else
err = i915_request_await_dma_fence(eb.request,
   in_fence);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index e113f93b32745..eeedb2f457ae5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -447,13 +447,6 @@ struct intel_engine_cs {
 */
void(*submit_request)(struct i915_request *rq);
 
-   /*
-* Called on signaling of a SUBMIT_FENCE, passing along the signaling
-* request down to the bonded pairs.
-*/
-   void(*bond_execute)(struct i915_request *rq,
-   struct dma_fence *signal);
-
/*
 * Call when the priority on a request has changed and it and its
 * dependencies may need rescheduling. Note the request itself may
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 38fe91205c77d..01e77ba397372 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3587,22 +3587,6 @@ static void virtual_submit_request(struct i915_request 
*rq)
spin_unlock_irqrestore(>base.active.lock, flags);
 }
 
-static void
-virtual_bond_execute(struct i915_request *rq, struct dma_fence *signal)
-{
-   intel_engine_mask_t allowed, exec;
-
-   allowed = ~to_request(signal)->engine->mask;
-
-   /* Restrict the bonded request to run on only the available engines */
-   exec = READ_ONCE(rq->execution_mask);
-   while (!try_cmpxchg(>execution_mask, , exec & allowed))
-   ;
-
-   /* Prevent the master from being re-run on the bonded engines */
-   to_request(signal)->execution_mask &= ~allowed;
-}
-
 struct intel_context *
 intel_execlists_create_virtual(struct intel_engine_cs **siblings,
   unsigned int count)
@@ -3656,7 +3640,6 @@ intel_execlists_create_virtual(struct intel_engine_cs 
**siblings,
 
ve->base.schedule = i915_schedule;
ve->base.submit_request = virtual_submit_request;
-   ve->base.bond_execute = virtual_bond_execute;
 
INIT_LIST_HEAD(virtual_queue(ve));
ve->base.execlists.queue_priority_hint = INT_MIN;
-- 
2.31.1

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


[Intel-gfx] [PATCH 09/31] drm/i915/gem: Disallow bonding of virtual engines (v3)

2021-06-09 Thread Jason Ekstrand
This adds a bunch of complexity which the media driver has never
actually used.  The media driver does technically bond a balanced engine
to another engine but the balanced engine only has one engine in the
sibling set.  This doesn't actually result in a virtual engine.

This functionality was originally added to handle cases where we may
have more than two video engines and media might want to load-balance
their bonded submits by, for instance, submitting to a balanced vcs0-1
as the primary and then vcs2-3 as the secondary.  However, no such
hardware has shipped thus far and, if we ever want to enable such
use-cases in the future, we'll use the up-and-coming parallel submit API
which targets GuC submission.

This makes I915_CONTEXT_ENGINES_EXT_BOND a total no-op.  We leave the
validation code in place in case we ever decide we want to do something
interesting with the bonding information.

v2 (Jason Ekstrand):
 - Don't delete quite as much code.

v3 (Tvrtko Ursulin):
 - Add some history to the commit message

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |  18 +-
 .../drm/i915/gt/intel_execlists_submission.c  |  69 --
 .../drm/i915/gt/intel_execlists_submission.h  |   5 +-
 drivers/gpu/drm/i915/gt/selftest_execlists.c  | 229 --
 4 files changed, 8 insertions(+), 313 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index e36e3b1ae14e4..5eca91ded3423 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1552,6 +1552,12 @@ set_engines__bond(struct i915_user_extension __user 
*base, void *data)
}
virtual = set->engines->engines[idx]->engine;
 
+   if (intel_engine_is_virtual(virtual)) {
+   drm_dbg(>drm,
+   "Bonding with virtual engines not allowed\n");
+   return -EINVAL;
+   }
+
err = check_user_mbz(>flags);
if (err)
return err;
@@ -1592,18 +1598,6 @@ set_engines__bond(struct i915_user_extension __user 
*base, void *data)
n, ci.engine_class, ci.engine_instance);
return -EINVAL;
}
-
-   /*
-* A non-virtual engine has no siblings to choose between; and
-* a submit fence will always be directed to the one engine.
-*/
-   if (intel_engine_is_virtual(virtual)) {
-   err = intel_virtual_engine_attach_bond(virtual,
-  master,
-  bond);
-   if (err)
-   return err;
-   }
}
 
return 0;
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index f9ffaece12213..38fe91205c77d 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -182,18 +182,6 @@ struct virtual_engine {
int prio;
} nodes[I915_NUM_ENGINES];
 
-   /*
-* Keep track of bonded pairs -- restrictions upon on our selection
-* of physical engines any particular request may be submitted to.
-* If we receive a submit-fence from a master engine, we will only
-* use one of sibling_mask physical engines.
-*/
-   struct ve_bond {
-   const struct intel_engine_cs *master;
-   intel_engine_mask_t sibling_mask;
-   } *bonds;
-   unsigned int num_bonds;
-
/* And finally, which physical engines this virtual engine maps onto. */
unsigned int num_siblings;
struct intel_engine_cs *siblings[];
@@ -3347,7 +3335,6 @@ static void rcu_virtual_context_destroy(struct 
work_struct *wrk)
intel_breadcrumbs_free(ve->base.breadcrumbs);
intel_engine_free_request_pool(>base);
 
-   kfree(ve->bonds);
kfree(ve);
 }
 
@@ -3600,33 +3587,13 @@ static void virtual_submit_request(struct i915_request 
*rq)
spin_unlock_irqrestore(>base.active.lock, flags);
 }
 
-static struct ve_bond *
-virtual_find_bond(struct virtual_engine *ve,
- const struct intel_engine_cs *master)
-{
-   int i;
-
-   for (i = 0; i < ve->num_bonds; i++) {
-   if (ve->bonds[i].master == master)
-   return >bonds[i];
-   }
-
-   return NULL;
-}
-
 static void
 virtual_bond_execute(struct i915_request *rq, struct dma_fence *signal)
 {
-   struct virtual_engine *ve = to_virtual_engine(rq->engine);
intel_engine_mask_t allowed, exec;
-   struct ve_bond *bond;
 
allowed = ~to_request(signal)->engine->mask;
 
-   bond = virtual_find_bond(ve, to_request(signal)->engine);
-   if 

[Intel-gfx] [PATCH 07/31] drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)

2021-06-09 Thread Jason Ekstrand
This API is entirely unnecessary and I'd love to get rid of it.  If
userspace wants a single timeline across multiple contexts, they can
either use implicit synchronization or a syncobj, both of which existed
at the time this feature landed.  The justification given at the time
was that it would help GL drivers which are inherently single-timeline.
However, neither of our GL drivers actually wanted the feature.  i965
was already in maintenance mode at the time and iris uses syncobj for
everything.

Unfortunately, as much as I'd love to get rid of it, it is used by the
media driver so we can't do that.  We can, however, do the next-best
thing which is to embed a syncobj in the context and do exactly what
we'd expect from userspace internally.  This isn't an entirely identical
implementation because it's no longer atomic if userspace races with
itself by calling execbuffer2 twice simultaneously from different
threads.  It won't crash in that case; it just doesn't guarantee any
ordering between those two submits.  It also means that sync files
exported from different engines on a SINGLE_TIMELINE context will have
different fence contexts.  This is visible to userspace if it looks at
the obj_name field of sync_fence_info.

Moving SINGLE_TIMELINE to a syncobj emulation has a couple of technical
advantages beyond mere annoyance.  One is that intel_timeline is no
longer an api-visible object and can remain entirely an implementation
detail.  This may be advantageous as we make scheduler changes going
forward.  Second is that, together with deleting the CLONE_CONTEXT API,
we should now have a 1:1 mapping between intel_context and
intel_timeline which may help us reduce locking.

v2 (Tvrtko Ursulin):
 - Update the comment on i915_gem_context::syncobj to mention that it's
   an emulation and the possible race if userspace calls execbuffer2
   twice on the same context concurrently.
v2 (Jason Ekstrand):
 - Wrap the checks for eb.gem_context->syncobj in unlikely()
 - Drop the dma_fence reference
 - Improved commit message

v3 (Jason Ekstrand):
 - Move the dma_fence_put() to before the error exit

v4 (Tvrtko Ursulin):
 - Add a comment about fence contexts to the commit message

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 49 +--
 .../gpu/drm/i915/gem/i915_gem_context_types.h | 14 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 16 ++
 3 files changed, 40 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 9f9369d3c0004..249bd36f14019 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -67,6 +67,8 @@
 #include 
 #include 
 
+#include 
+
 #include "gt/gen6_ppgtt.h"
 #include "gt/intel_context.h"
 #include "gt/intel_context_param.h"
@@ -224,10 +226,6 @@ static void intel_context_set_gem(struct intel_context *ce,
ce->vm = vm;
}
 
-   GEM_BUG_ON(ce->timeline);
-   if (ctx->timeline)
-   ce->timeline = intel_timeline_get(ctx->timeline);
-
if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
intel_engine_has_timeslices(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, >flags);
@@ -351,9 +349,6 @@ void i915_gem_context_release(struct kref *ref)
mutex_destroy(>engines_mutex);
mutex_destroy(>lut_mutex);
 
-   if (ctx->timeline)
-   intel_timeline_put(ctx->timeline);
-
put_pid(ctx->pid);
mutex_destroy(>mutex);
 
@@ -570,6 +565,9 @@ static void context_close(struct i915_gem_context *ctx)
if (vm)
i915_vm_close(vm);
 
+   if (ctx->syncobj)
+   drm_syncobj_put(ctx->syncobj);
+
ctx->file_priv = ERR_PTR(-EBADF);
 
/*
@@ -765,33 +763,11 @@ static void __assign_ppgtt(struct i915_gem_context *ctx,
i915_vm_close(vm);
 }
 
-static void __set_timeline(struct intel_timeline **dst,
-  struct intel_timeline *src)
-{
-   struct intel_timeline *old = *dst;
-
-   *dst = src ? intel_timeline_get(src) : NULL;
-
-   if (old)
-   intel_timeline_put(old);
-}
-
-static void __apply_timeline(struct intel_context *ce, void *timeline)
-{
-   __set_timeline(>timeline, timeline);
-}
-
-static void __assign_timeline(struct i915_gem_context *ctx,
- struct intel_timeline *timeline)
-{
-   __set_timeline(>timeline, timeline);
-   context_apply_all(ctx, __apply_timeline, timeline);
-}
-
 static struct i915_gem_context *
 i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
 {
struct i915_gem_context *ctx;
+   int ret;
 
if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
!HAS_EXECLISTS(i915))
@@ -820,16 +796,13 @@ i915_gem_create_context(struct drm_i915_private *i915, 
unsigned int flags)
 

[Intel-gfx] [PATCH 08/31] drm/i915: Drop getparam support for I915_CONTEXT_PARAM_ENGINES

2021-06-09 Thread Jason Ekstrand
This has never been used by any userspace except IGT and provides no
real functionality beyond parroting back parameters userspace passed in
as part of context creation or via setparam.  If the context is in
legacy mode (where you use I915_EXEC_RENDER and friends), it returns
success with zero data so it's not useful for discovering what engines
are in the context.  It's also not a replacement for the recently
removed I915_CONTEXT_CLONE_ENGINES because it doesn't return any of the
balancing or bonding information.

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 77 +
 1 file changed, 1 insertion(+), 76 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 249bd36f14019..e36e3b1ae14e4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1724,78 +1724,6 @@ set_engines(struct i915_gem_context *ctx,
return 0;
 }
 
-static int
-get_engines(struct i915_gem_context *ctx,
-   struct drm_i915_gem_context_param *args)
-{
-   struct i915_context_param_engines __user *user;
-   struct i915_gem_engines *e;
-   size_t n, count, size;
-   bool user_engines;
-   int err = 0;
-
-   e = __context_engines_await(ctx, _engines);
-   if (!e)
-   return -ENOENT;
-
-   if (!user_engines) {
-   i915_sw_fence_complete(>fence);
-   args->size = 0;
-   return 0;
-   }
-
-   count = e->num_engines;
-
-   /* Be paranoid in case we have an impedance mismatch */
-   if (!check_struct_size(user, engines, count, )) {
-   err = -EINVAL;
-   goto err_free;
-   }
-   if (overflows_type(size, args->size)) {
-   err = -EINVAL;
-   goto err_free;
-   }
-
-   if (!args->size) {
-   args->size = size;
-   goto err_free;
-   }
-
-   if (args->size < size) {
-   err = -EINVAL;
-   goto err_free;
-   }
-
-   user = u64_to_user_ptr(args->value);
-   if (put_user(0, >extensions)) {
-   err = -EFAULT;
-   goto err_free;
-   }
-
-   for (n = 0; n < count; n++) {
-   struct i915_engine_class_instance ci = {
-   .engine_class = I915_ENGINE_CLASS_INVALID,
-   .engine_instance = I915_ENGINE_CLASS_INVALID_NONE,
-   };
-
-   if (e->engines[n]) {
-   ci.engine_class = e->engines[n]->engine->uabi_class;
-   ci.engine_instance = 
e->engines[n]->engine->uabi_instance;
-   }
-
-   if (copy_to_user(>engines[n], , sizeof(ci))) {
-   err = -EFAULT;
-   goto err_free;
-   }
-   }
-
-   args->size = size;
-
-err_free:
-   i915_sw_fence_complete(>fence);
-   return err;
-}
-
 static int
 set_persistence(struct i915_gem_context *ctx,
const struct drm_i915_gem_context_param *args)
@@ -2126,10 +2054,6 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
ret = get_ppgtt(file_priv, ctx, args);
break;
 
-   case I915_CONTEXT_PARAM_ENGINES:
-   ret = get_engines(ctx, args);
-   break;
-
case I915_CONTEXT_PARAM_PERSISTENCE:
args->size = 0;
args->value = i915_gem_context_is_persistent(ctx);
@@ -2137,6 +2061,7 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
 
case I915_CONTEXT_PARAM_NO_ZEROMAP:
case I915_CONTEXT_PARAM_BAN_PERIOD:
+   case I915_CONTEXT_PARAM_ENGINES:
case I915_CONTEXT_PARAM_RINGSIZE:
default:
ret = -EINVAL;
-- 
2.31.1

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


[Intel-gfx] [PATCH 06/31] drm/i915: Drop the CONTEXT_CLONE API (v2)

2021-06-09 Thread Jason Ekstrand
This API allows one context to grab bits out of another context upon
creation.  It can be used as a short-cut for setparam(getparam()) for
things like I915_CONTEXT_PARAM_VM.  However, it's never been used by any
real userspace.  It's used by a few IGT tests and that's it.  Since it
doesn't add any real value (most of the stuff you can CLONE you can copy
in other ways), drop it.

There is one thing that this API allows you to clone which you cannot
clone via getparam/setparam: timelines.  However, timelines are an
implementation detail of i915 and not really something that needs to be
exposed to userspace.  Also, sharing timelines between contexts isn't
obviously useful and supporting it has the potential to complicate i915
internally.  It also doesn't add any functionality that the client can't
get in other ways.  If a client really wants a shared timeline, they can
use a syncobj and set it as an in and out fence on every submit.

v2 (Jason Ekstrand):
 - More detailed commit message

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 199 +-
 .../drm/i915/gt/intel_execlists_submission.c  |  28 ---
 .../drm/i915/gt/intel_execlists_submission.h  |   3 -
 include/uapi/drm/i915_drm.h   |  16 +-
 4 files changed, 6 insertions(+), 240 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 3503d46c88cbf..9f9369d3c0004 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1957,207 +1957,14 @@ static int create_setparam(struct i915_user_extension 
__user *ext, void *data)
return ctx_setparam(arg->fpriv, arg->ctx, );
 }
 
-static int clone_engines(struct i915_gem_context *dst,
-struct i915_gem_context *src)
+static int invalid_ext(struct i915_user_extension __user *ext, void *data)
 {
-   struct i915_gem_engines *clone, *e;
-   bool user_engines;
-   unsigned long n;
-
-   e = __context_engines_await(src, _engines);
-   if (!e)
-   return -ENOENT;
-
-   clone = alloc_engines(e->num_engines);
-   if (!clone)
-   goto err_unlock;
-
-   for (n = 0; n < e->num_engines; n++) {
-   struct intel_engine_cs *engine;
-
-   if (!e->engines[n]) {
-   clone->engines[n] = NULL;
-   continue;
-   }
-   engine = e->engines[n]->engine;
-
-   /*
-* Virtual engines are singletons; they can only exist
-* inside a single context, because they embed their
-* HW context... As each virtual context implies a single
-* timeline (each engine can only dequeue a single request
-* at any time), it would be surprising for two contexts
-* to use the same engine. So let's create a copy of
-* the virtual engine instead.
-*/
-   if (intel_engine_is_virtual(engine))
-   clone->engines[n] =
-   intel_execlists_clone_virtual(engine);
-   else
-   clone->engines[n] = intel_context_create(engine);
-   if (IS_ERR_OR_NULL(clone->engines[n])) {
-   __free_engines(clone, n);
-   goto err_unlock;
-   }
-
-   intel_context_set_gem(clone->engines[n], dst);
-   }
-   clone->num_engines = n;
-   i915_sw_fence_complete(>fence);
-
-   /* Serialised by constructor */
-   engines_idle_release(dst, rcu_replace_pointer(dst->engines, clone, 1));
-   if (user_engines)
-   i915_gem_context_set_user_engines(dst);
-   else
-   i915_gem_context_clear_user_engines(dst);
-   return 0;
-
-err_unlock:
-   i915_sw_fence_complete(>fence);
-   return -ENOMEM;
-}
-
-static int clone_flags(struct i915_gem_context *dst,
-  struct i915_gem_context *src)
-{
-   dst->user_flags = src->user_flags;
-   return 0;
-}
-
-static int clone_schedattr(struct i915_gem_context *dst,
-  struct i915_gem_context *src)
-{
-   dst->sched = src->sched;
-   return 0;
-}
-
-static int clone_sseu(struct i915_gem_context *dst,
- struct i915_gem_context *src)
-{
-   struct i915_gem_engines *e = i915_gem_context_lock_engines(src);
-   struct i915_gem_engines *clone;
-   unsigned long n;
-   int err;
-
-   /* no locking required; sole access under constructor*/
-   clone = __context_engines_static(dst);
-   if (e->num_engines != clone->num_engines) {
-   err = -EINVAL;
-   goto unlock;
-   }
-
-   for (n = 0; n < e->num_engines; n++) {
-   struct intel_context *ce = e->engines[n];
-
-   if 

[Intel-gfx] [PATCH 05/31] drm/i915/gem: Return void from context_apply_all

2021-06-09 Thread Jason Ekstrand
None of the callbacks we use with it return an error code anymore; they
all return 0 unconditionally.

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 26 +++--
 1 file changed, 8 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 9750a1ac7023e..3503d46c88cbf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -718,32 +718,25 @@ __context_engines_await(const struct i915_gem_context 
*ctx,
return engines;
 }
 
-static int
+static void
 context_apply_all(struct i915_gem_context *ctx,
- int (*fn)(struct intel_context *ce, void *data),
+ void (*fn)(struct intel_context *ce, void *data),
  void *data)
 {
struct i915_gem_engines_iter it;
struct i915_gem_engines *e;
struct intel_context *ce;
-   int err = 0;
 
e = __context_engines_await(ctx, NULL);
-   for_each_gem_engine(ce, e, it) {
-   err = fn(ce, data);
-   if (err)
-   break;
-   }
+   for_each_gem_engine(ce, e, it)
+   fn(ce, data);
i915_sw_fence_complete(>fence);
-
-   return err;
 }
 
-static int __apply_ppgtt(struct intel_context *ce, void *vm)
+static void __apply_ppgtt(struct intel_context *ce, void *vm)
 {
i915_vm_put(ce->vm);
ce->vm = i915_vm_get(vm);
-   return 0;
 }
 
 static struct i915_address_space *
@@ -783,10 +776,9 @@ static void __set_timeline(struct intel_timeline **dst,
intel_timeline_put(old);
 }
 
-static int __apply_timeline(struct intel_context *ce, void *timeline)
+static void __apply_timeline(struct intel_context *ce, void *timeline)
 {
__set_timeline(>timeline, timeline);
-   return 0;
 }
 
 static void __assign_timeline(struct i915_gem_context *ctx,
@@ -1841,19 +1833,17 @@ set_persistence(struct i915_gem_context *ctx,
return __context_set_persistence(ctx, args->value);
 }
 
-static int __apply_priority(struct intel_context *ce, void *arg)
+static void __apply_priority(struct intel_context *ce, void *arg)
 {
struct i915_gem_context *ctx = arg;
 
if (!intel_engine_has_timeslices(ce->engine))
-   return 0;
+   return;
 
if (ctx->sched.priority >= I915_PRIORITY_NORMAL)
intel_context_set_use_semaphores(ce);
else
intel_context_clear_use_semaphores(ce);
-
-   return 0;
 }
 
 static int set_priority(struct i915_gem_context *ctx,
-- 
2.31.1

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


[Intel-gfx] [PATCH 03/31] drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP

2021-06-09 Thread Jason Ekstrand
The idea behind this param is to support OpenCL drivers with relocations
because OpenCL reserves 0x0 for NULL and, if we placed memory there, it
would confuse CL kernels.  It was originally sent out as part of a patch
series including libdrm [1] and Beignet [2] support.  However, the
libdrm and Beignet patches never landed in their respective upstream
projects so this API has never been used.  It's never been used in Mesa
or any other driver, either.

Dropping this API allows us to delete a small bit of code.

[1]: https://lists.freedesktop.org/archives/intel-gfx/2015-May/067030.html
[2]: https://lists.freedesktop.org/archives/intel-gfx/2015-May/067031.html

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c  | 16 ++--
 .../gpu/drm/i915/gem/i915_gem_context_types.h|  1 -
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c   |  8 
 include/uapi/drm/i915_drm.h  |  4 
 4 files changed, 6 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index a4faf06022d5a..5fc0eb4beeeae 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1920,15 +1920,6 @@ static int ctx_setparam(struct drm_i915_file_private 
*fpriv,
int ret = 0;
 
switch (args->param) {
-   case I915_CONTEXT_PARAM_NO_ZEROMAP:
-   if (args->size)
-   ret = -EINVAL;
-   else if (args->value)
-   set_bit(UCONTEXT_NO_ZEROMAP, >user_flags);
-   else
-   clear_bit(UCONTEXT_NO_ZEROMAP, >user_flags);
-   break;
-
case I915_CONTEXT_PARAM_NO_ERROR_CAPTURE:
if (args->size)
ret = -EINVAL;
@@ -1978,6 +1969,7 @@ static int ctx_setparam(struct drm_i915_file_private 
*fpriv,
ret = set_persistence(ctx, args);
break;
 
+   case I915_CONTEXT_PARAM_NO_ZEROMAP:
case I915_CONTEXT_PARAM_BAN_PERIOD:
case I915_CONTEXT_PARAM_RINGSIZE:
default:
@@ -2358,11 +2350,6 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
return -ENOENT;
 
switch (args->param) {
-   case I915_CONTEXT_PARAM_NO_ZEROMAP:
-   args->size = 0;
-   args->value = test_bit(UCONTEXT_NO_ZEROMAP, >user_flags);
-   break;
-
case I915_CONTEXT_PARAM_GTT_SIZE:
args->size = 0;
rcu_read_lock();
@@ -2410,6 +2397,7 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
args->value = i915_gem_context_is_persistent(ctx);
break;
 
+   case I915_CONTEXT_PARAM_NO_ZEROMAP:
case I915_CONTEXT_PARAM_BAN_PERIOD:
case I915_CONTEXT_PARAM_RINGSIZE:
default:
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 340473aa70de0..5ae71ec936f7c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -129,7 +129,6 @@ struct i915_gem_context {
 * @user_flags: small set of booleans controlled by the user
 */
unsigned long user_flags;
-#define UCONTEXT_NO_ZEROMAP0
 #define UCONTEXT_NO_ERROR_CAPTURE  1
 #define UCONTEXT_BANNABLE  2
 #define UCONTEXT_RECOVERABLE   3
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index a8abc9af5ff47..19a453bb170a1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -290,7 +290,6 @@ struct i915_execbuffer {
struct intel_context *reloc_context;
 
u64 invalid_flags; /** Set of execobj.flags that are invalid */
-   u32 context_flags; /** Set of execobj.flags to insert from the ctx */
 
u64 batch_len; /** Length of batch within object */
u32 batch_start_offset; /** Location within object of batch */
@@ -541,9 +540,6 @@ eb_validate_vma(struct i915_execbuffer *eb,
entry->flags |= EXEC_OBJECT_NEEDS_GTT | 
__EXEC_OBJECT_NEEDS_MAP;
}
 
-   if (!(entry->flags & EXEC_OBJECT_PINNED))
-   entry->flags |= eb->context_flags;
-
return 0;
 }
 
@@ -750,10 +746,6 @@ static int eb_select_context(struct i915_execbuffer *eb)
if (rcu_access_pointer(ctx->vm))
eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
 
-   eb->context_flags = 0;
-   if (test_bit(UCONTEXT_NO_ZEROMAP, >user_flags))
-   eb->context_flags |= __EXEC_OBJECT_NEEDS_BIAS;
-
return 0;
 }
 
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index ad8f1a0f587f6..e527f5f7e0dea 100644
--- a/include/uapi/drm/i915_drm.h
+++ 

[Intel-gfx] [PATCH 04/31] drm/i915/gem: Set the watchdog timeout directly in intel_context_set_gem (v2)

2021-06-09 Thread Jason Ekstrand
Instead of handling it like a context param, unconditionally set it when
intel_contexts are created.  For years we've had the idea of a watchdog
uAPI floating about. The aim was for media, so that they could set very
tight deadlines for their transcodes jobs, so that if you have a corrupt
bitstream (especially for decoding) you don't hang your desktop too
hard.  But it's been stuck in limbo since forever, and this simplifies
things a bit in preparation for the proto-context work.  If we decide to
actually make said uAPI a reality, we can do it through the proto-
context easily enough.

This does mean that we move from reading the request_timeout_ms param
once per engine when engines are created instead of once at context
creation.  If someone changes request_timeout_ms between creating a
context and setting engines, it will mean that they get the new timeout.
If someone races setting request_timeout_ms and context creation, they
can theoretically end up with different timeouts.  However, since both
of these are fairly harmless and require changing kernel params, we
don't care.

v2 (Tvrtko Ursulin):
 - Add a comment about races with request_timeout_ms

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 44 +++
 .../gpu/drm/i915/gem/i915_gem_context_types.h |  4 --
 drivers/gpu/drm/i915/gt/intel_context_param.h |  3 +-
 3 files changed, 7 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 5fc0eb4beeeae..9750a1ac7023e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -232,7 +232,12 @@ static void intel_context_set_gem(struct intel_context *ce,
intel_engine_has_timeslices(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, >flags);
 
-   intel_context_set_watchdog_us(ce, ctx->watchdog.timeout_us);
+   if (IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT) &&
+   ctx->i915->params.request_timeout_ms) {
+   unsigned int timeout_ms = ctx->i915->params.request_timeout_ms;
+
+   intel_context_set_watchdog_us(ce, (u64)timeout_ms * 1000);
+   }
 }
 
 static void __free_engines(struct i915_gem_engines *e, unsigned int count)
@@ -791,41 +796,6 @@ static void __assign_timeline(struct i915_gem_context *ctx,
context_apply_all(ctx, __apply_timeline, timeline);
 }
 
-static int __apply_watchdog(struct intel_context *ce, void *timeout_us)
-{
-   return intel_context_set_watchdog_us(ce, (uintptr_t)timeout_us);
-}
-
-static int
-__set_watchdog(struct i915_gem_context *ctx, unsigned long timeout_us)
-{
-   int ret;
-
-   ret = context_apply_all(ctx, __apply_watchdog,
-   (void *)(uintptr_t)timeout_us);
-   if (!ret)
-   ctx->watchdog.timeout_us = timeout_us;
-
-   return ret;
-}
-
-static void __set_default_fence_expiry(struct i915_gem_context *ctx)
-{
-   struct drm_i915_private *i915 = ctx->i915;
-   int ret;
-
-   if (!IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT) ||
-   !i915->params.request_timeout_ms)
-   return;
-
-   /* Default expiry for user fences. */
-   ret = __set_watchdog(ctx, i915->params.request_timeout_ms * 1000);
-   if (ret)
-   drm_notice(>drm,
-  "Failed to configure default fence expiry! (%d)",
-  ret);
-}
-
 static struct i915_gem_context *
 i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
 {
@@ -870,8 +840,6 @@ i915_gem_create_context(struct drm_i915_private *i915, 
unsigned int flags)
intel_timeline_put(timeline);
}
 
-   __set_default_fence_expiry(ctx);
-
trace_i915_context_create(ctx);
 
return ctx;
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 5ae71ec936f7c..676592e27e7d2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -153,10 +153,6 @@ struct i915_gem_context {
 */
atomic_t active_count;
 
-   struct {
-   u64 timeout_us;
-   } watchdog;
-
/**
 * @hang_timestamp: The last time(s) this context caused a GPU hang
 */
diff --git a/drivers/gpu/drm/i915/gt/intel_context_param.h 
b/drivers/gpu/drm/i915/gt/intel_context_param.h
index dffedd983693d..0c69cb42d075c 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_param.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_param.h
@@ -10,11 +10,10 @@
 
 #include "intel_context.h"
 
-static inline int
+static inline void
 intel_context_set_watchdog_us(struct intel_context *ce, u64 timeout_us)
 {
ce->watchdog.timeout_us = timeout_us;
-   return 0;
 }
 
 #endif /* INTEL_CONTEXT_PARAM_H */
-- 
2.31.1


[Intel-gfx] [PATCH 02/31] drm/i915: Stop storing the ring size in the ring pointer (v2)

2021-06-09 Thread Jason Ekstrand
Previously, we were storing the ring size in the ring pointer before it
was actually allocated.  We would then guard setting the ring size on
checking for CONTEXT_ALLOC_BIT.  This is error-prone at best and really
only saves us a few bytes on something that already burns at least 4K.
Instead, this patch adds a new ring_size field and makes everything use
that.

v2 (Daniel Vetter):
 - Replace 512 * SZ_4K with SZ_2M

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 3 +--
 drivers/gpu/drm/i915/gt/intel_context.c   | 3 ++-
 drivers/gpu/drm/i915/gt/intel_context.h   | 5 -
 drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 2 +-
 drivers/gpu/drm/i915/gt/selftest_execlists.c  | 2 +-
 drivers/gpu/drm/i915/gt/selftest_mocs.c   | 2 +-
 drivers/gpu/drm/i915/gt/selftest_timeline.c   | 2 +-
 drivers/gpu/drm/i915/gvt/scheduler.c  | 7 ++-
 9 files changed, 10 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ddc3cc3f8f092..a4faf06022d5a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -211,8 +211,7 @@ static void intel_context_set_gem(struct intel_context *ce,
GEM_BUG_ON(rcu_access_pointer(ce->gem_context));
RCU_INIT_POINTER(ce->gem_context, ctx);
 
-   if (!test_bit(CONTEXT_ALLOC_BIT, >flags))
-   ce->ring = __intel_context_ring_size(SZ_16K);
+   ce->ring_size = SZ_16K;
 
if (rcu_access_pointer(ctx->vm)) {
struct i915_address_space *vm;
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 4033184f13b9f..bd63813c8a802 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -371,7 +371,8 @@ intel_context_init(struct intel_context *ce, struct 
intel_engine_cs *engine)
ce->engine = engine;
ce->ops = engine->cops;
ce->sseu = engine->sseu;
-   ce->ring = __intel_context_ring_size(SZ_4K);
+   ce->ring = NULL;
+   ce->ring_size = SZ_4K;
 
ewma_runtime_init(>runtime.avg);
 
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h 
b/drivers/gpu/drm/i915/gt/intel_context.h
index f83a73a2b39fc..b10cbe8fee992 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -175,11 +175,6 @@ int intel_context_prepare_remote_request(struct 
intel_context *ce,
 
 struct i915_request *intel_context_create_request(struct intel_context *ce);
 
-static inline struct intel_ring *__intel_context_ring_size(u64 sz)
-{
-   return u64_to_ptr(struct intel_ring, sz);
-}
-
 static inline bool intel_context_is_barrier(const struct intel_context *ce)
 {
return test_bit(CONTEXT_BARRIER_BIT, >flags);
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index ed8c447a7346b..90026c1771055 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -82,6 +82,7 @@ struct intel_context {
spinlock_t signal_lock; /* protects signals, the list of requests */
 
struct i915_vma *state;
+   u32 ring_size;
struct intel_ring *ring;
struct intel_timeline *timeline;
 
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index a27bac0a4bfb8..8ada1afe3d229 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -845,7 +845,7 @@ int lrc_alloc(struct intel_context *ce, struct 
intel_engine_cs *engine)
if (IS_ERR(vma))
return PTR_ERR(vma);
 
-   ring = intel_engine_create_ring(engine, (unsigned long)ce->ring);
+   ring = intel_engine_create_ring(engine, ce->ring_size);
if (IS_ERR(ring)) {
err = PTR_ERR(ring);
goto err_vma;
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c 
b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index ea2203af0764d..ed5a8142c543d 100644
--- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
+++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
@@ -2793,7 +2793,7 @@ static int __live_preempt_ring(struct intel_engine_cs 
*engine,
goto err_ce;
}
 
-   tmp->ring = __intel_context_ring_size(ring_sz);
+   tmp->ring_size = ring_sz;
 
err = intel_context_pin(tmp);
if (err) {
diff --git a/drivers/gpu/drm/i915/gt/selftest_mocs.c 
b/drivers/gpu/drm/i915/gt/selftest_mocs.c
index b9bb0e6e97f7f..8763bbeca0f77 100644
--- a/drivers/gpu/drm/i915/gt/selftest_mocs.c
+++ b/drivers/gpu/drm/i915/gt/selftest_mocs.c
@@ -28,7 +28,7 @@ static struct intel_context *mocs_context_create(struct 
intel_engine_cs *engine)
return ce;
 
/* We build 

[Intel-gfx] [PATCH 01/31] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE

2021-06-09 Thread Jason Ekstrand
This reverts commit 88be76cdafc7 ("drm/i915: Allow userspace to specify
ringsize on construction").  This API was originally added for OpenCL
but the compute-runtime PR has sat open for a year without action so we
can still pull it out if we want.  I argue we should drop it for three
reasons:

 1. If the compute-runtime PR has sat open for a year, this clearly
isn't that important.

 2. It's a very leaky API.  Ring size is an implementation detail of the
current execlist scheduler and really only makes sense there.  It
can't apply to the older ring-buffer scheduler on pre-execlist
hardware because that's shared across all contexts and it won't
apply to the GuC scheduler that's in the pipeline.

 3. Having userspace set a ring size in bytes is a bad solution to the
problem of having too small a ring.  There is no way that userspace
has the information to know how to properly set the ring size so
it's just going to detect the feature and always set it to the
maximum of 512K.  This is what the compute-runtime PR does.  The
scheduler in i915, on the other hand, does have the information to
make an informed choice.  It could detect if the ring size is a
problem and grow it itself.  Or, if that's too hard, we could just
increase the default size from 16K to 32K or even 64K instead of
relying on userspace to do it.

Let's drop this API for now and, if someone decides they really care
about solving this problem, they can do it properly.

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/Makefile |  1 -
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 85 +--
 drivers/gpu/drm/i915/gt/intel_context_param.c | 63 --
 drivers/gpu/drm/i915/gt/intel_context_param.h |  3 -
 include/uapi/drm/i915_drm.h   | 20 +
 5 files changed, 4 insertions(+), 168 deletions(-)
 delete mode 100644 drivers/gpu/drm/i915/gt/intel_context_param.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4f22cac1c49be..0a3e8c85da9f2 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -89,7 +89,6 @@ gt-y += \
gt/gen8_ppgtt.o \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
-   gt/intel_context_param.o \
gt/intel_context_sseu.o \
gt/intel_engine_cs.o \
gt/intel_engine_heartbeat.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 7720b8c22c816..ddc3cc3f8f092 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1334,63 +1334,6 @@ static int set_ppgtt(struct drm_i915_file_private 
*file_priv,
return err;
 }
 
-static int __apply_ringsize(struct intel_context *ce, void *sz)
-{
-   return intel_context_set_ring_size(ce, (unsigned long)sz);
-}
-
-static int set_ringsize(struct i915_gem_context *ctx,
-   struct drm_i915_gem_context_param *args)
-{
-   if (!HAS_LOGICAL_RING_CONTEXTS(ctx->i915))
-   return -ENODEV;
-
-   if (args->size)
-   return -EINVAL;
-
-   if (!IS_ALIGNED(args->value, I915_GTT_PAGE_SIZE))
-   return -EINVAL;
-
-   if (args->value < I915_GTT_PAGE_SIZE)
-   return -EINVAL;
-
-   if (args->value > 128 * I915_GTT_PAGE_SIZE)
-   return -EINVAL;
-
-   return context_apply_all(ctx,
-__apply_ringsize,
-__intel_context_ring_size(args->value));
-}
-
-static int __get_ringsize(struct intel_context *ce, void *arg)
-{
-   long sz;
-
-   sz = intel_context_get_ring_size(ce);
-   GEM_BUG_ON(sz > INT_MAX);
-
-   return sz; /* stop on first engine */
-}
-
-static int get_ringsize(struct i915_gem_context *ctx,
-   struct drm_i915_gem_context_param *args)
-{
-   int sz;
-
-   if (!HAS_LOGICAL_RING_CONTEXTS(ctx->i915))
-   return -ENODEV;
-
-   if (args->size)
-   return -EINVAL;
-
-   sz = context_apply_all(ctx, __get_ringsize, NULL);
-   if (sz < 0)
-   return sz;
-
-   args->value = sz;
-   return 0;
-}
-
 int
 i915_gem_user_to_context_sseu(struct intel_gt *gt,
  const struct drm_i915_gem_context_param_sseu 
*user,
@@ -2036,11 +1979,8 @@ static int ctx_setparam(struct drm_i915_file_private 
*fpriv,
ret = set_persistence(ctx, args);
break;
 
-   case I915_CONTEXT_PARAM_RINGSIZE:
-   ret = set_ringsize(ctx, args);
-   break;
-
case I915_CONTEXT_PARAM_BAN_PERIOD:
+   case I915_CONTEXT_PARAM_RINGSIZE:
default:
ret = -EINVAL;
break;
@@ -2068,18 +2008,6 @@ static int create_setparam(struct i915_user_extension 
__user *ext, void *data)
return 

[Intel-gfx] [PATCH 00/31] drm/i915/gem: ioctl clean-ups (v6)

2021-06-09 Thread Jason Ekstrand
Overview:
-

This patch series attempts to clean up some of the IOCTL mess we've created
over the last few years.  The most egregious bit being context mutability.
In summary, this series:

 1. Drops two never-used context params: RINGSIZE and NO_ZEROMAP
 2. Drops the entire CONTEXT_CLONE API
 3. Implements SINGLE_TIMELINE with a syncobj instead of actually sharing
intel_timeline between engines.
 4. Adds a few sanity restrictions to the balancing/bonding API.
 5. Implements a proto-ctx mechanism so that the engine set and VM can only
be set early on in the lifetime of a context, before anything ever
executes on it.  This effectively makes the VM and engine set
immutable.

This series has been tested with IGT as well as the Iris, ANV, and the
Intel media driver doing an 8K decode (this uses bonding/balancing).  I've
also done quite a bit of git archeology to ensure that nothing in here will
break anything that's already shipped at some point in history.  It's
possible I've missed something, but I've dug quite a bit.


Details and motivation:
---

In very broad strokes, there's an effort going on right now within Intel to
try and clean up and simplify i915 anywhere we can.  We obviously don't
want to break any shipping userspace but, as can be seen by this series,
there's a lot i915 theoretically supports which userspace doesn't actually
need.  Some of this, like the two context params used here, were simply
oversights where we went through the usual API review process and merged
the i915 bits but the userspace bits never landed for some reason.

Not all are so innocent, however.  For instance, there's an entire context
cloning API which allows one to create a context with certain parameters
"cloned" from some other context.  This entire API has never been used by
any userspace except IGT and there were never patches to any other
userspace to use it.  It never should have landed.  Also, when we added
support for setting explicit engine sets and sharing VMs across contexts,
people decided to do so via SET_CONTEXT_PARAM.  While this allowed them to
re-use existing API, it did so at the cost of making those states mutable
which leads to a plethora of potential race conditions.  There were even
IGT tests merged to cover some of theses:

 - gem_vm_create@async-destroy and gem_vm_create@destroy-race which test
   swapping out the VM on a running context.

 - gem_ctx_persistence@replace* which test whether a client can escape a
   non-persistent context by submitting a hanging batch and then swapping
   out the engine set before the hang is detected.

 - api_intel_bb@bb-with-vm which tests the that intel_bb_assign_vm works
   properly.  This API is never used by any other IGT test.

There is also an entire deferred flush and set state framework in
i915_gem_cotnext.c which exists for safely swapping out the VM while there
is work in-flight on a context.

So, clearly people knew that this API was inherently racy and difficult to
implement but they landed it anyway.  Why?  The best explanation I've been
given is because it makes the API more "unified" or "symmetric" for this
stuff to go through SET_CONTEXT_PARAM.  It's not because any userspace
actually wants to be able to swap out the VM or the set of engines on a
running context.  That would be utterly insane.

This patch series cleans up this particular mess by introducing the concept
of a i915_gem_proto_context data structure which contains context creation
information.  When you initially call GEM_CONTEXT_CREATE, a proto-context
in created instead of an actual context.  Then, the first time something is
done on the context besides SET_CONTEXT_PARAM, an actual context is
created.  This allows us to keep the old drivers which use
SET_CONTEXT_PARAM to set up the engine set (see also media) while ensuring
that, once you have an i915_gem_context, the VM and the engine set are
immutable state.

Eventually, there are more clean-ups I'd like to do on top of this which
should make working with contexts inside i915 simpler and safer:

 1. Move the GEM handle -> vma LUT from i915_gem_context into either
i915_ppgtt or drm_i915_file_private depending on whether or not the
hardware has a full PPGTT.

 2. Move the delayed context destruction code into intel_context or a
per-engine wrapper struct rather than i915_gem_context.

 3. Get rid of the separation between context close and context destroy

 4. Get rid of the RCU on i915_gem_context

However, these should probably be done as a separate patch series as this
one is already starting to get longish, especially if you consider the 89
IGT patches that go along with it.

Test-with: 20210609173632.248880-1-ja...@jlekstrand.net

Jason Ekstrand (31):
  drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE
  drm/i915: Stop storing the ring size in the ring pointer (v2)
  drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP
  drm/i915/gem: Set the watchdog timeout directly in

Re: [Intel-gfx] [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action

2021-06-09 Thread John Harrison

On 6/7/2021 18:23, Daniele Ceraolo Spurio wrote:

On 6/7/2021 11:03 AM, Matthew Brost wrote:

From: Michal Wajdeczko 

Definition of the CTB registration action has changed.
Add some ABI documentation and implement required changes.

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Matthew Brost 
Cc: Piotr Piórkowski  #4
---
  .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  | 107 ++
  .../gt/uc/abi/guc_communication_ctb_abi.h |   4 -
  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |  76 -
  3 files changed, 152 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h

index 90efef8a73e4..6426fc183692 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -6,6 +6,113 @@
  #ifndef _ABI_GUC_ACTIONS_ABI_H
  #define _ABI_GUC_ACTIONS_ABI_H
  +/**
+ * DOC: HOST2GUC_REGISTER_CTB
+ *
+ * This message is used as part of the `CTB based communication`_ 
setup.

+ *
+ * This message must be sent as `MMIO HXG Message`_.
+ *
+ * 
+---+---+--+
+ *  |   | Bits  | 
Description  |
+ * 
+===+===+==+
+ *  | 0 |    31 | ORIGIN = 
GUC_HXG_ORIGIN_HOST_    |
+ *  | 
+---+--+
+ *  |   | 30:28 | TYPE = 
GUC_HXG_TYPE_REQUEST_ |
+ *  | 
+---+--+
+ *  |   | 27:16 | DATA0 = 
MBZ  |
+ *  | 
+---+--+
+ *  |   |  15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` = 
0x5200    |


Specs says 4505

+ * 
+---+---+--+
+ *  | 1 | 31:12 | RESERVED = 
MBZ   |
+ *  | 
+---+--+
+ *  |   |  11:8 | **TYPE** - type for the `CT 
Buffer`_ |
+ *  |   | 
|  |
+ *  |   |   |   - _`GUC_CTB_TYPE_HOST2GUC` = 
0 |
+ *  |   |   |   - _`GUC_CTB_TYPE_GUC2HOST` = 
1 |
+ *  | 
+---+--+
+ *  |   |   7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units 
minus 1  |
+ * 
+---+---+--+
+ *  | 2 |  31:0 | **DESC_ADDR** - GGTT address of the `CTB 
Descriptor`_    |
+ * 
+---+---+--+
+ *  | 3 |  31:0 | **BUFF_ADDF** - GGTT address of the `CT 
Buffer`_ |
+ * 
+---+---+--+

+*
+ * 
+---+---+--+
+ *  |   | Bits  | 
Description  |
+ * 
+===+===+==+
+ *  | 0 |    31 | ORIGIN = 
GUC_HXG_ORIGIN_GUC_ |
+ *  | 
+---+--+
+ *  |   | 30:28 | TYPE = 
GUC_HXG_TYPE_RESPONSE_SUCCESS_    |
+ *  | 
+---+--+
+ *  |   |  27:0 | DATA0 = 
MBZ  |
+ * 
+---+---+--+

+ */
+#define GUC_ACTION_HOST2GUC_REGISTER_CTB    0x4505 // FIXME 0x5200


Why FIXME? AFAICS the specs still says 4505, even if we plan to update 
at some point I don;t think this deserves a FIXME since nothing is 
incorrect.



+
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN 
(GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ 
GUC_HXG_REQUEST_MSG_0_DATA0

+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ    (0xf << 12)
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE    (0xf << 8)
+#define   GUC_CTB_TYPE_HOST2GUC    0u
+#define   GUC_CTB_TYPE_GUC2HOST    1u
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE    (0xff << 0)
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR 
GUC_HXG_REQUEST_MSG_n_DATAn
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR 
GUC_HXG_REQUEST_MSG_n_DATAn


The full mask still seems like overkill to me and I still think we 
should use BIT()/GENMASK() and a _MASK prefix, but not going to block 
on it.



+
+#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN 
GUC_HXG_RESPONSE_MSG_MIN_LEN
+#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_0_MBZ 

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dsc: use crtc index for bigjoiner primary/secondary crtc

2021-06-09 Thread Jani Nikula
On Wed, 09 Jun 2021, Jani Nikula  wrote:
> On Thu, 03 Jun 2021, Jani Nikula  wrote:
>> Pipe numbering isn't guaranteed to be contiguous; there may be fused off
>> pipes in the middle. The current bigjoiner primary/secondary crtc lookup
>> with pipe +/- 1 does not take this into account, and may fail
>> unexpectedly. Fixing this while using pipe numbering gets complicated.
>
> This is broken; pipes need to be contiguous for big joiner regardless of
> whether pipes have been fused off.

Really meant "adjacent", but you get the point.

>
> BR,
> Jani.
>
>>
>> Switch to using crtc index +/- 1 instead. They are contiguous, and the
>> crtc lookup neatly handles overflows and underflows. The performance
>> penalty from the crtc list lookup is neglible.
>>
>> Fixes: 8a029c113b17 ("drm/i915/dp: Modify VDSC helpers to configure DSC for 
>> Bigjoiner slave")
>> Fixes: d961eb20adb6 ("drm/i915/bigjoiner: atomic commit changes for 
>> uncompressed joiner")
>> Cc: Animesh Manna 
>> Cc: Manasi Navare 
>> Cc: Vandita Kulkarni 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/i915/display/intel_vdsc.c | 31 +++
>>  1 file changed, 15 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
>> b/drivers/gpu/drm/i915/display/intel_vdsc.c
>> index 1fd81bd3ea09..1d757b040bce 100644
>> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
>> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
>> @@ -1106,30 +1106,29 @@ static i915_reg_t dss_ctl2_reg(const struct 
>> intel_crtc_state *crtc_state)
>>  return is_pipe_dsc(crtc_state) ? ICL_PIPE_DSS_CTL2(pipe) : DSS_CTL2;
>>  }
>>  
>> -struct intel_crtc *
>> -intel_dsc_get_bigjoiner_secondary(const struct intel_crtc *primary_crtc)
>> +static struct intel_crtc *
>> +get_linked_crtc(const struct intel_crtc *crtc, int index)
>>  {
>> -struct drm_i915_private *i915 = to_i915(primary_crtc->base.dev);
>> -enum pipe pipe = primary_crtc->pipe + 1;
>> +struct drm_i915_private *i915 = to_i915(crtc->base.dev);
>> +struct intel_crtc *linked_crtc;
>>  
>> -if (drm_WARN_ON(>drm, pipe >= I915_MAX_PIPES ||
>> -!(INTEL_INFO(i915)->pipe_mask & BIT(pipe
>> -return NULL;
>> +linked_crtc = to_intel_crtc(drm_crtc_from_index(>drm, index));
>>  
>> -return intel_get_crtc_for_pipe(i915, pipe);
>> +drm_WARN_ON(>drm, !linked_crtc);
>> +
>> +return linked_crtc;
>>  }
>>  
>>  struct intel_crtc *
>> -intel_dsc_get_bigjoiner_primary(const struct intel_crtc *secondary_crtc)
>> +intel_dsc_get_bigjoiner_secondary(const struct intel_crtc *primary_crtc)
>>  {
>> -struct drm_i915_private *i915 = to_i915(secondary_crtc->base.dev);
>> -enum pipe pipe = secondary_crtc->pipe - 1;
>> -
>> -if (drm_WARN_ON(>drm, pipe <= INVALID_PIPE ||
>> -!(INTEL_INFO(i915)->pipe_mask & BIT(pipe
>> -return NULL;
>> +return get_linked_crtc(primary_crtc, primary_crtc->base.index + 1);
>> +}
>>  
>> -return intel_get_crtc_for_pipe(i915, pipe);
>> +struct intel_crtc *
>> +intel_dsc_get_bigjoiner_primary(const struct intel_crtc *secondary_crtc)
>> +{
>> +return get_linked_crtc(secondary_crtc, secondary_crtc->base.index - 1);
>>  }
>>  
>>  void intel_uncompressed_joiner_enable(const struct intel_crtc_state 
>> *crtc_state)

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


Re: [Intel-gfx] [PATCH 2/2] drm/i915/dsc: use crtc index for bigjoiner primary/secondary crtc

2021-06-09 Thread Jani Nikula
On Thu, 03 Jun 2021, Jani Nikula  wrote:
> Pipe numbering isn't guaranteed to be contiguous; there may be fused off
> pipes in the middle. The current bigjoiner primary/secondary crtc lookup
> with pipe +/- 1 does not take this into account, and may fail
> unexpectedly. Fixing this while using pipe numbering gets complicated.

This is broken; pipes need to be contiguous for big joiner regardless of
whether pipes have been fused off.

BR,
Jani.

>
> Switch to using crtc index +/- 1 instead. They are contiguous, and the
> crtc lookup neatly handles overflows and underflows. The performance
> penalty from the crtc list lookup is neglible.
>
> Fixes: 8a029c113b17 ("drm/i915/dp: Modify VDSC helpers to configure DSC for 
> Bigjoiner slave")
> Fixes: d961eb20adb6 ("drm/i915/bigjoiner: atomic commit changes for 
> uncompressed joiner")
> Cc: Animesh Manna 
> Cc: Manasi Navare 
> Cc: Vandita Kulkarni 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 31 +++
>  1 file changed, 15 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 1fd81bd3ea09..1d757b040bce 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -1106,30 +1106,29 @@ static i915_reg_t dss_ctl2_reg(const struct 
> intel_crtc_state *crtc_state)
>   return is_pipe_dsc(crtc_state) ? ICL_PIPE_DSS_CTL2(pipe) : DSS_CTL2;
>  }
>  
> -struct intel_crtc *
> -intel_dsc_get_bigjoiner_secondary(const struct intel_crtc *primary_crtc)
> +static struct intel_crtc *
> +get_linked_crtc(const struct intel_crtc *crtc, int index)
>  {
> - struct drm_i915_private *i915 = to_i915(primary_crtc->base.dev);
> - enum pipe pipe = primary_crtc->pipe + 1;
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> + struct intel_crtc *linked_crtc;
>  
> - if (drm_WARN_ON(>drm, pipe >= I915_MAX_PIPES ||
> - !(INTEL_INFO(i915)->pipe_mask & BIT(pipe
> - return NULL;
> + linked_crtc = to_intel_crtc(drm_crtc_from_index(>drm, index));
>  
> - return intel_get_crtc_for_pipe(i915, pipe);
> + drm_WARN_ON(>drm, !linked_crtc);
> +
> + return linked_crtc;
>  }
>  
>  struct intel_crtc *
> -intel_dsc_get_bigjoiner_primary(const struct intel_crtc *secondary_crtc)
> +intel_dsc_get_bigjoiner_secondary(const struct intel_crtc *primary_crtc)
>  {
> - struct drm_i915_private *i915 = to_i915(secondary_crtc->base.dev);
> - enum pipe pipe = secondary_crtc->pipe - 1;
> -
> - if (drm_WARN_ON(>drm, pipe <= INVALID_PIPE ||
> - !(INTEL_INFO(i915)->pipe_mask & BIT(pipe
> - return NULL;
> + return get_linked_crtc(primary_crtc, primary_crtc->base.index + 1);
> +}
>  
> - return intel_get_crtc_for_pipe(i915, pipe);
> +struct intel_crtc *
> +intel_dsc_get_bigjoiner_primary(const struct intel_crtc *secondary_crtc)
> +{
> + return get_linked_crtc(secondary_crtc, secondary_crtc->base.index - 1);
>  }
>  
>  void intel_uncompressed_joiner_enable(const struct intel_crtc_state 
> *crtc_state)

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


Re: [Intel-gfx] [PATCH 31/31] drm/i915: Drop some RCU usage around context VMs

2021-06-09 Thread Jason Ekstrand
On Wed, Jun 9, 2021 at 6:41 AM Daniel Vetter  wrote:
>
> On Tue, Jun 08, 2021 at 11:36:13PM -0500, Jason Ekstrand wrote:
> > This instance now only happens during context creation so there's no way
> > we can race with a context close/destroy.  We don't need to bother with
> > the RCU and can access the pointer directly.
> >
> > Signed-off-by: Jason Ekstrand 
>
> There's another one in execbuf.c, and the real crux is that we need to
> fully audit the lifetimes of everything. I think it's better to do this
> all together in a seperate patch series, which entirely removes the rcu
> barrier on the i915_address_space cleanup, and also removes the rcu
> protection from everywhere else.
>
> Otherwise we just have an inconsistent mess that happens to work,
> sometimes.

Ok, let's drop this for now.

--Jason

> -Daniel
>
> > ---
> >  drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 +
> >  1 file changed, 5 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 5312142daa0c0..ffdfed536ce9a 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -787,15 +787,12 @@ static int intel_context_set_gem(struct intel_context 
> > *ce,
> >
> >   ce->ring_size = SZ_16K;
> >
> > - if (rcu_access_pointer(ctx->vm)) {
> > - struct i915_address_space *vm;
> > -
> > - rcu_read_lock();
> > - vm = context_get_vm_rcu(ctx); /* hmm */
> > - rcu_read_unlock();
> > -
> > + if (ctx->vm) {
> > + /* This only happens during context creation so no need to
> > +  * bother with any RCU nonsense.
> > +  */
> >   i915_vm_put(ce->vm);
> > - ce->vm = vm;
> > + ce->vm = i915_vm_get(ctx->vm);
> >   }
> >
> >   if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
> > --
> > 2.31.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> 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 25/31] drm/i915/gem: Don't allow changing the VM on running contexts (v2)

2021-06-09 Thread Jason Ekstrand
On Wed, Jun 9, 2021 at 6:34 AM Daniel Vetter  wrote:
>
> On Tue, Jun 08, 2021 at 11:36:07PM -0500, Jason Ekstrand wrote:
> > When the APIs were added to manage VMs more directly from userspace, the
> > questionable choice was made to allow changing out the VM on a context
> > at any time.  This is horribly racy and there's absolutely no reason why
> > any userspace would want to do this outside of testing that exact race.
> > By removing support for CONTEXT_PARAM_VM from ctx_setparam, we make it
> > impossible to change out the VM after the context has been fully
> > created.  This lets us delete a bunch of deferred task code as well as a
> > duplicated (and slightly different) copy of the code which programs the
> > PPGTT registers.
> >
> > v2 (Jason Ekstrand):
> >  - Expand the commit message
> >
> > Signed-off-by: Jason Ekstrand 
> > Reviewed-by: Daniel Vetter 
>
> Need to retract this r-b here until the issue below is fixed.
>
> > ---
> >  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 262 --
> >  .../gpu/drm/i915/gem/i915_gem_context_types.h |   2 +-
> >  .../drm/i915/gem/selftests/i915_gem_context.c | 119 
> >  .../drm/i915/selftests/i915_mock_selftests.h  |   1 -
> >  4 files changed, 1 insertion(+), 383 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index f74c22dc506ec..2f3d92224d2fe 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -1633,120 +1633,6 @@ int i915_gem_vm_destroy_ioctl(struct drm_device 
> > *dev, void *data,
> >   return 0;
> >  }
> >
> > -struct context_barrier_task {
> > - struct i915_active base;
> > - void (*task)(void *data);
> > - void *data;
> > -};
> > -
> > -static void cb_retire(struct i915_active *base)
> > -{
> > - struct context_barrier_task *cb = container_of(base, typeof(*cb), 
> > base);
> > -
> > - if (cb->task)
> > - cb->task(cb->data);
> > -
> > - i915_active_fini(>base);
> > - kfree(cb);
> > -}
> > -
> > -I915_SELFTEST_DECLARE(static intel_engine_mask_t 
> > context_barrier_inject_fault);
> > -static int context_barrier_task(struct i915_gem_context *ctx,
> > - intel_engine_mask_t engines,
> > - bool (*skip)(struct intel_context *ce, void 
> > *data),
> > - int (*pin)(struct intel_context *ce, struct 
> > i915_gem_ww_ctx *ww, void *data),
> > - int (*emit)(struct i915_request *rq, void 
> > *data),
> > - void (*task)(void *data),
> > - void *data)
> > -{
> > - struct context_barrier_task *cb;
> > - struct i915_gem_engines_iter it;
> > - struct i915_gem_engines *e;
> > - struct i915_gem_ww_ctx ww;
> > - struct intel_context *ce;
> > - int err = 0;
> > -
> > - GEM_BUG_ON(!task);
> > -
> > - cb = kmalloc(sizeof(*cb), GFP_KERNEL);
> > - if (!cb)
> > - return -ENOMEM;
> > -
> > - i915_active_init(>base, NULL, cb_retire, 0);
> > - err = i915_active_acquire(>base);
> > - if (err) {
> > - kfree(cb);
> > - return err;
> > - }
> > -
> > - e = __context_engines_await(ctx, NULL);
> > - if (!e) {
> > - i915_active_release(>base);
> > - return -ENOENT;
> > - }
> > -
> > - for_each_gem_engine(ce, e, it) {
> > - struct i915_request *rq;
> > -
> > - if (I915_SELFTEST_ONLY(context_barrier_inject_fault &
> > -ce->engine->mask)) {
> > - err = -ENXIO;
> > - break;
> > - }
> > -
> > - if (!(ce->engine->mask & engines))
> > - continue;
> > -
> > - if (skip && skip(ce, data))
> > - continue;
> > -
> > - i915_gem_ww_ctx_init(, true);
> > -retry:
> > - err = intel_context_pin_ww(ce, );
> > - if (err)
> > - goto err;
> > -
> > - if (pin)
> > - err = pin(ce, , data);
> > - if (err)
> > - goto err_unpin;
> > -
> > - rq = i915_request_create(ce);
> > - if (IS_ERR(rq)) {
> > - err = PTR_ERR(rq);
> > - goto err_unpin;
> > - }
> > -
> > - err = 0;
> > - if (emit)
> > - err = emit(rq, data);
> > - if (err == 0)
> > - err = i915_active_add_request(>base, rq);
> > -
> > - i915_request_add(rq);
> > -err_unpin:
> > - intel_context_unpin(ce);
> > -err:
> > - if (err == -EDEADLK) {
> > - err = i915_gem_ww_ctx_backoff();
> > - if (!err)
> > - goto 

Re: [Intel-gfx] [PATCH 16/31] drm/i915/gem: Add an intermediate proto_context struct (v4)

2021-06-09 Thread Jason Ekstrand
On Wed, Jun 9, 2021 at 6:28 AM Daniel Vetter  wrote:
>
> On Tue, Jun 08, 2021 at 11:35:58PM -0500, Jason Ekstrand wrote:
> > The current context uAPI allows for two methods of setting context
> > parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM.  The
> > former is allowed to be called at any time while the later happens as
> > part of GEM_CONTEXT_CREATE.  Currently, everything settable via one is
> > settable via the other.  While some params are fairly simple and setting
> > them on a live context is harmless such the context priority, others are
> > far trickier such as the VM or the set of engines.  In order to swap out
> > the VM, for instance, we have to delay until all current in-flight work
> > is complete, swap in the new VM, and then continue.  This leads to a
> > plethora of potential race conditions we'd really rather avoid.
> >
> > Unfortunately, both methods of setting the VM and the engine set are in
> > active use today so we can't simply disallow setting the VM or engine
> > set vial SET_CONTEXT_PARAM.  In order to work around this wart, this
> > commit adds a proto-context struct which contains all the context create
> > parameters.
> >
> > v2 (Daniel Vetter):
> >  - Better commit message
> >  - Use __set/clear_bit instead of set/clear_bit because there's no race
> >and we don't need the atomics
> >
> > v3 (Daniel Vetter):
> >  - Use manual bitops and BIT() instead of __set_bit
> >
> > v4 (Daniel Vetter):
> >  - Add a changelog to the commit message
> >  - Better hyperlinking in docs
> >  - Create the default PPGTT in i915_gem_create_context
> >
> > Signed-off-by: Jason Ekstrand 
> > ---
> >  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 124 +++---
> >  .../gpu/drm/i915/gem/i915_gem_context_types.h |  22 
> >  .../gpu/drm/i915/gem/selftests/mock_context.c |  16 ++-
> >  3 files changed, 145 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index f9a6eac78c0ae..b5d8c1ff5d7b3 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -191,6 +191,83 @@ static int validate_priority(struct drm_i915_private 
> > *i915,
> >   return 0;
> >  }
> >
> > +static void proto_context_close(struct i915_gem_proto_context *pc)
> > +{
> > + if (pc->vm)
> > + i915_vm_put(pc->vm);
> > + kfree(pc);
> > +}
> > +
> > +static int proto_context_set_persistence(struct drm_i915_private *i915,
> > +  struct i915_gem_proto_context *pc,
> > +  bool persist)
> > +{
> > + if (persist) {
> > + /*
> > +  * Only contexts that are short-lived [that will expire or be
> > +  * reset] are allowed to survive past termination. We require
> > +  * hangcheck to ensure that the persistent requests are 
> > healthy.
> > +  */
> > + if (!i915->params.enable_hangcheck)
> > + return -EINVAL;
> > +
> > + pc->user_flags |= BIT(UCONTEXT_PERSISTENCE);
> > + } else {
> > + /* To cancel a context we use "preempt-to-idle" */
> > + if (!(i915->caps.scheduler & I915_SCHEDULER_CAP_PREEMPTION))
> > + return -ENODEV;
> > +
> > + /*
> > +  * If the cancel fails, we then need to reset, cleanly!
> > +  *
> > +  * If the per-engine reset fails, all hope is lost! We resort
> > +  * to a full GPU reset in that unlikely case, but 
> > realistically
> > +  * if the engine could not reset, the full reset does not fare
> > +  * much better. The damage has been done.
> > +  *
> > +  * However, if we cannot reset an engine by itself, we cannot
> > +  * cleanup a hanging persistent context without causing
> > +  * colateral damage, and we should not pretend we can by
> > +  * exposing the interface.
> > +  */
> > + if (!intel_has_reset_engine(>gt))
> > + return -ENODEV;
> > +
> > + pc->user_flags &= ~BIT(UCONTEXT_PERSISTENCE);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static struct i915_gem_proto_context *
> > +proto_context_create(struct drm_i915_private *i915, unsigned int flags)
> > +{
> > + struct i915_gem_proto_context *pc, *err;
> > +
> > + pc = kzalloc(sizeof(*pc), GFP_KERNEL);
> > + if (!pc)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + pc->user_flags = BIT(UCONTEXT_BANNABLE) |
> > +  BIT(UCONTEXT_RECOVERABLE);
> > + proto_context_set_persistence(i915, pc, true);
>
> I think we're down to the bikeshed here that I think should be open-coded
> for clarity of what exactly is going on. But maybe better in a distinct
> patch.

Nope.  I just failed at 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsc: Fix bigjoiner check in dsc_disable (rev4)

2021-06-09 Thread Vudum, Lakshminarayana
@Kulkarni, Vandita We have rev5 now, so do 
you want me to re-report rev4 results? if we are re-testing as part of rev 5, 
re-reporting is needed.
https://patchwork.freedesktop.org/series/91006/#rev5

Lakshmi.
From: Kulkarni, Vandita 
Sent: Wednesday, June 9, 2021 12:08 AM
To: intel-gfx@lists.freedesktop.org; Navare, Manasi D 
; Vudum, Lakshminarayana 

Cc: Gupta, Anshuman 
Subject: RE: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsc: Fix bigjoiner 
check in dsc_disable (rev4)

This issue doesn’t seem to be related to the patch.
@Vudum, Lakshminarayana can you report 
the results.

From: Intel-gfx 
mailto:intel-gfx-boun...@lists.freedesktop.org>>
 On Behalf Of Patchwork
Sent: Tuesday, June 8, 2021 4:08 PM
To: Navare, Manasi D 
mailto:manasi.d.nav...@intel.com>>
Cc: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsc: Fix bigjoiner check 
in dsc_disable (rev4)

Patch Details
Series:

drm/i915/dsc: Fix bigjoiner check in dsc_disable (rev4)

URL:

https://patchwork.freedesktop.org/series/91006/

State:

failure

Details:

https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20303/index.html

CI Bug Log - changes from CI_DRM_10188_full -> Patchwork_20303_full
Summary

FAILURE

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

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20303_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_20303_full:

IGT changes
Possible regressions

  *   igt@kms_plane@plane-position-hole@pipe-b-planes:

 *   shard-tglb: 
PASS
 -> 
INCOMPLETE

Known issues

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

IGT changes
Issues hit

  *   igt@feature_discovery@display-2x:

 *   shard-iclb: NOTRUN -> 
SKIP
 ([i915#1839])

  *   igt@feature_discovery@psr2:

 *   shard-iclb: 
PASS
 -> 
SKIP
 ([i915#658])

  *   igt@gem_create@create-massive:

 *   shard-snb: NOTRUN -> 
DMESG-WARN
 ([i915#3002])
 *   shard-apl: NOTRUN -> 
DMESG-WARN
 ([i915#3002])

  *   igt@gem_ctx_persistence@clone:

 *   shard-snb: NOTRUN -> 
SKIP
 ([fdo#109271] / [i915#1099]) +4 similar issues

  *   igt@gem_exec_fair@basic-deadline:

 *   shard-kbl: NOTRUN -> 
FAIL
 ([i915#2846])

  *   igt@gem_exec_fair@basic-none-share@rcs0:

 *   shard-apl: 
PASS
 -> 
SKIP
 ([fdo#109271])

  *   igt@gem_exec_fair@basic-none@vcs0:

 *   shard-kbl: 
PASS
 -> 
FAIL
 ([i915#2842])

  *   igt@gem_exec_fair@basic-pace@rcs0:

 *   shard-tglb: 
PASS
 -> 
FAIL
 ([i915#2842])

  *   igt@gem_exec_fair@basic-pace@vecs0:

 *   shard-glk: NOTRUN -> 
FAIL
 ([i915#2842]) +2 similar issues

  *   igt@gem_exec_reloc@basic-wide-active@rcs0:

 *   shard-kbl: NOTRUN -> 
FAIL
 ([i915#2389]) +4 similar issues

  *   igt@gem_huc_copy@huc-copy:

 *   

Re: [Intel-gfx] [PATCH v2 0/9] Prereqs for TTM accelerated migration

2021-06-09 Thread Daniel Vetter
On Wed, Jun 09, 2021 at 04:35:57PM +0200, Thomas Hellström wrote:
> 
> On 6/9/21 3:08 PM, Thomas Hellström wrote:
> > 
> > On 6/9/21 2:20 PM, Matthew Auld wrote:
> > > On 09/06/2021 13:16, Thomas Hellström wrote:
> > > > 
> > > > On 6/9/21 1:48 PM, Daniel Vetter wrote:
> > > > > On Wed, Jun 09, 2021 at 08:34:27AM +0200, Thomas Hellström wrote:
> > > > > > A couple of patches from Chris which implement pipelined
> > > > > > migration and
> > > > > > clears by atomically writing the PTEs in place before performing the
> > > > > > actual blit.
> > > > > > 
> > > > > > Some ww utilities mainly for the accompanying selftests
> > > > > > added by Thomas,
> > > > > > as well as modified the above patches for ww locking-
> > > > > > and lmem support.
> > > > > > 
> > > > > > The actual hook up to the i915 ttm backend is being worked on and 
> > > > > > not
> > > > > > included yet, so this is considered to be an early
> > > > > > review opportunity.
> > > > > > 
> > > > > > v2:
> > > > > > - A couple of minor style fixes pointed out by Matthew Auld
> > > > > > - Export and use intel_engine_destroy_pinned_context() to address a
> > > > > > ls   CI warning / failure.
> > > > > Just to check my understanding of the plan: These are the new windowed
> > > > > clear/blt functions which we plan to use everywhere, because
> > > > > less nasty
> > > > > locking implications? And the clear/blt we currently have in
> > > > > upstream will
> > > > > be replaced?
> > > > 
> > > > Yes. These are for LMEM clearing and migration. It looks to me
> > > > like the other ones we have in upstream are actually unused
> > > > except for selftests. We're actually using CPU clearing for now.
> > > > 
> > > > > 
> > > > > If so would be nice if this patch set includes that
> > > > > replacement work (I
> > > > > think right now all we have is the clear for lmem),
> > > > > including updating of
> > > > > selftests and stuff like that. Just to avoid having two ways to do the
> > > > > same thing in the driver.
> > > > 
> > > > OK, I'll have a look at stripping the existing code. If we need
> > > > it moving forward, we can always re-add.
> > > 
> > > Some low hanging fruit would be all the client_blt stuff which can
> > > for sure be deleted now.
> > 
> > What has the client_blt stuff been used for?
> > 
> > In any case, I need 25 commits for commit access to be granted.
> > 
> > /Thomas
> > 
> > 
> Series on trybot now. It's the dg1 live memory_region selftest that changes
> sligthly to use the new migration fill blt.

Thanks a lot for taking care of this!
-Daniel
-- 
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


  1   2   >