date:20220929

[Intel-gfx] [PATCH 0/3] drm/i915: Improve register state context init

2022-09-29 Thread Lucas De Marchi

Some small improvements to future-proof the initialization around the
register state context.

Lucas De Marchi (3):
  drm/i915: Fix __gen125_emit_bb_start() without WA
  drm/i915/gt: Document function to decode register state context
  drm/i915/gt: Fix platform prefix

 drivers/gpu/drm/i915/gt/gen8_engine_cs.c  | 26 +--
 drivers/gpu/drm/i915/gt/gen8_engine_cs.h  | 12 +++---
 .../drm/i915/gt/intel_execlists_submission.c  |  4 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 43 ++-
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  2 +-
 5 files changed, 56 insertions(+), 31 deletions(-)

-- 
2.37.3

[Intel-gfx] [PATCH 1/3] drm/i915: Fix __gen125_emit_bb_start() without WA

2022-09-29 Thread Lucas De Marchi

ce->wa_bb_page is allocated only for graphics version 12. However
__gen125_emit_bb_start() is used for any graphics version >= 12.50. For
the currently supported platforms this is not an issue, but for future
ones there's a mismatch causing the jump to
`wa_offset + DG2_PREDICATE_RESULT_BB` to be invalid since wa_offset is
not correct.

As in other places in the driver, check for graphics version "greater or
equal" to future-proof the support for new platforms.

Cc: Matt Roper 
Cc: Matthew Auld 
Cc: Chris Wilson 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c |  2 ++
 drivers/gpu/drm/i915/gt/intel_lrc.c  | 19 +--
 2 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 31a2fbd8c4a8..e000eaf8abed 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -405,6 +405,8 @@ static int __gen125_emit_bb_start(struct i915_request *rq,
u32 wa_offset = lrc_indirect_bb(ce);
u32 *cs;
 
+   GEM_BUG_ON(!ce->wa_bb_page);
+
cs = intel_ring_begin(rq, 12);
if (IS_ERR(cs))
return PTR_ERR(cs);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e84ef3859934..3515882a91fb 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -825,19 +825,18 @@ static int lrc_ring_cmd_buf_cctl(const struct 
intel_engine_cs *engine)
 static u32
 lrc_ring_indirect_offset_default(const struct intel_engine_cs *engine)
 {
-   switch (GRAPHICS_VER(engine->i915)) {
-   default:
-   MISSING_CASE(GRAPHICS_VER(engine->i915));
-   fallthrough;
-   case 12:
+   if (GRAPHICS_VER(engine->i915) >= 12)
return GEN12_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT;
-   case 11:
+   else if (GRAPHICS_VER(engine->i915) >= 11)
return GEN11_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT;
-   case 9:
+   else if (GRAPHICS_VER(engine->i915) >= 9)
return GEN9_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT;
-   case 8:
+   else if (GRAPHICS_VER(engine->i915) >= 8)
return GEN8_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT;
-   }
+
+   GEM_BUG_ON(GRAPHICS_VER(engine->i915) < 8);
+
+   return 0;
 }
 
 static void
@@ -1092,7 +1091,7 @@ __lrc_alloc_state(struct intel_context *ce, struct 
intel_engine_cs *engine)
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
context_size += I915_GTT_PAGE_SIZE; /* for redzone */
 
-   if (GRAPHICS_VER(engine->i915) == 12) {
+   if (GRAPHICS_VER(engine->i915) >= 12) {
ce->wa_bb_page = context_size / PAGE_SIZE;
context_size += PAGE_SIZE;
}
-- 
2.37.3

[Intel-gfx] [PATCH 3/3] drm/i915/gt: Fix platform prefix

2022-09-29 Thread Lucas De Marchi

Different handling for XeHP and later platforms should be using the
xehp prefix, not gen125. Rename them.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c  | 24 +--
 drivers/gpu/drm/i915/gt/gen8_engine_cs.h  | 12 +-
 .../drm/i915/gt/intel_execlists_submission.c  |  4 ++--
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  2 +-
 4 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index e000eaf8abed..e1c76e5bfa82 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -396,10 +396,10 @@ int gen8_emit_init_breadcrumb(struct i915_request *rq)
return 0;
 }
 
-static int __gen125_emit_bb_start(struct i915_request *rq,
- u64 offset, u32 len,
- const unsigned int flags,
- u32 arb)
+static int __xehp_emit_bb_start(struct i915_request *rq,
+   u64 offset, u32 len,
+   const unsigned int flags,
+   u32 arb)
 {
struct intel_context *ce = rq->context;
u32 wa_offset = lrc_indirect_bb(ce);
@@ -437,18 +437,18 @@ static int __gen125_emit_bb_start(struct i915_request *rq,
return 0;
 }
 
-int gen125_emit_bb_start_noarb(struct i915_request *rq,
-  u64 offset, u32 len,
-  const unsigned int flags)
+int xehp_emit_bb_start_noarb(struct i915_request *rq,
+u64 offset, u32 len,
+const unsigned int flags)
 {
-   return __gen125_emit_bb_start(rq, offset, len, flags, MI_ARB_DISABLE);
+   return __xehp_emit_bb_start(rq, offset, len, flags, MI_ARB_DISABLE);
 }
 
-int gen125_emit_bb_start(struct i915_request *rq,
-u64 offset, u32 len,
-const unsigned int flags)
+int xehp_emit_bb_start(struct i915_request *rq,
+  u64 offset, u32 len,
+  const unsigned int flags)
 {
-   return __gen125_emit_bb_start(rq, offset, len, flags, MI_ARB_ENABLE);
+   return __xehp_emit_bb_start(rq, offset, len, flags, MI_ARB_ENABLE);
 }
 
 int gen8_emit_bb_start_noarb(struct i915_request *rq,
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
index e4d24c811dd6..655e5c00ddc2 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
@@ -32,12 +32,12 @@ int gen8_emit_bb_start(struct i915_request *rq,
   u64 offset, u32 len,
   const unsigned int flags);
 
-int gen125_emit_bb_start_noarb(struct i915_request *rq,
-  u64 offset, u32 len,
-  const unsigned int flags);
-int gen125_emit_bb_start(struct i915_request *rq,
-u64 offset, u32 len,
-const unsigned int flags);
+int xehp_emit_bb_start_noarb(struct i915_request *rq,
+u64 offset, u32 len,
+const unsigned int flags);
+int xehp_emit_bb_start(struct i915_request *rq,
+  u64 offset, u32 len,
+  const unsigned int flags);
 
 u32 *gen8_emit_fini_breadcrumb_xcs(struct i915_request *rq, u32 *cs);
 u32 *gen12_emit_fini_breadcrumb_xcs(struct i915_request *rq, u32 *cs);
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index c718e6dc40b5..0187bc72310d 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3471,9 +3471,9 @@ logical_ring_default_vfuncs(struct intel_engine_cs 
*engine)
 
if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50)) {
if (intel_engine_has_preemption(engine))
-   engine->emit_bb_start = gen125_emit_bb_start;
+   engine->emit_bb_start = xehp_emit_bb_start;
else
-   engine->emit_bb_start = gen125_emit_bb_start_noarb;
+   engine->emit_bb_start = xehp_emit_bb_start_noarb;
} else {
if (intel_engine_has_preemption(engine))
engine->emit_bb_start = gen8_emit_bb_start;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0ef295a94060..d81f68fef9a8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4094,7 +4094,7 @@ static void guc_default_vfuncs(struct intel_engine_cs 
*engine)
 
engine->emit_bb_start = gen8_emit_bb_start;
if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
-

[Intel-gfx] [PATCH 2/3] drm/i915/gt: Document function to decode register state context

2022-09-29 Thread Lucas De Marchi

It's no obviously clear how the encode/decode of the per platform tables
is done. Document it so while adding tables for new platforms people can
be confident they right things is being done.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/gt/intel_lrc.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 3515882a91fb..7771a19008c6 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -20,6 +20,30 @@
 #include "intel_ring.h"
 #include "shmem_utils.h"
 
+/*
+ * The per-platform tables are u8-encoded in @data. Decode @data and set the
+ * addresses' offset and commands in @regs. The following encoding is used
+ * for each byte. There are 2 steps: decoding commands and decoding addresses.
+ *
+ * Commands:
+ * [7]: create NOPs - number of NOPs are set in lower bits
+ * [6]: When creating MI_LOAD_REGISTER_IMM command, allow to set
+ *  MI_LRI_FORCE_POSTED
+ * [5:0]: Number of NOPs or registers to set values to in case of
+ *MI_LOAD_REGISTER_IMM
+ *
+ * Addresses: these are decoded after a MI_LOAD_REGISTER_IMM command by "count"
+ * number of registers. They are set by using the REG/REG16 macros: the former
+ * is used for offsets smaller than 0x200 while the latter is for values bigger
+ * than that. Those macros already set all the bits documented below correctly:
+ *
+ * [7]: When a register offset needs more than 6 bits, use additional bytes, to
+ *  follow, for the lower bits
+ * [6:0]: Register offset, without considering the engine base.
+ *
+ * This function only tweaks the commands and register offsets. Values are not
+ * filled out.
+ */
 static void set_offsets(u32 *regs,
const u8 *data,
const struct intel_engine_cs *engine,
-- 
2.37.3

Re: [Intel-gfx] [PATCH 05/16] drm/i915/vm_bind: Implement bind and unbind of object

2022-09-29 Thread kernel test robot

Hi Niranjana,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm/drm-next 
drm-exynos/exynos-drm-next drm-misc/drm-misc-next linus/master v6.0-rc7 
next-20220927]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Niranjana-Vishwanathapura/drm-i915-vm_bind-Add-VM_BIND-functionality/20220928-142242
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-a013-20220926
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project 
f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/087e1b7e812c6983f49cdc0102baa8fcc67c48b3
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Niranjana-Vishwanathapura/drm-i915-vm_bind-Add-VM_BIND-functionality/20220928-142242
git checkout 087e1b7e812c6983f49cdc0102baa8fcc67c48b3
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/gpu/drm/i915/

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c:18:1: error: unused 
>> function 'i915_vm_bind_it_iter_next' [-Werror,-Wunused-function]
   INTERVAL_TREE_DEFINE(struct i915_vma, rb, u64, __subtree_last,
   ^
   include/linux/interval_tree_generic.h:151:33: note: expanded from macro 
'INTERVAL_TREE_DEFINE'
   ITSTATIC ITSTRUCT *  
 \

 ^
   :13:1: note: expanded from here
   i915_vm_bind_it_iter_next
   ^
   1 error generated.


vim +/i915_vm_bind_it_iter_next +18 
drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

17  
  > 18  INTERVAL_TREE_DEFINE(struct i915_vma, rb, u64, __subtree_last,
19   START, LAST, static inline, i915_vm_bind_it)
20  

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 6.0.0-rc7 Kernel Configuration
#
CONFIG_CC_VERSION_TEXT="clang version 14.0.6 (git://gitmirror/llvm_project 
f28c006a5895fc0e329fe15fead81e37457cb1d1)"
CONFIG_GCC_VERSION=0
CONFIG_CC_IS_CLANG=y
CONFIG_CLANG_VERSION=140006
CONFIG_AS_IS_LLVM=y
CONFIG_AS_VERSION=140006
CONFIG_LD_VERSION=0
CONFIG_LD_IS_LLD=y
CONFIG_LLD_VERSION=140006
CONFIG_CC_CAN_LINK=y
CONFIG_CC_CAN_LINK_STATIC=y
CONFIG_CC_HAS_ASM_GOTO_OUTPUT=y
CONFIG_TOOLS_SUPPORT_RELR=y
CONFIG_CC_HAS_ASM_INLINE=y
CONFIG_CC_HAS_NO_PROFILE_FN_ATTR=y
CONFIG_PAHOLE_VERSION=123
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_TABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
# CONFIG_WERROR is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_HAVE_KERNEL_ZSTD=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
# CONFIG_KERNEL_ZSTD is not set
CONFIG_DEFAULT_INIT=""
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_SYSVIPC_COMPAT=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_WATCH_QUEUE=y
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_SIM=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_IRQ_MSI_IOMMU=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
# end of IRQ subsystem

CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_INIT=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add HWMON support (rev8)

2022-09-29 Thread Patchwork

== Series Details ==

Series: drm/i915: Add HWMON support (rev8)
URL   : https://patchwork.freedesktop.org/series/104278/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12185_full -> Patchwork_104278v8_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 9)
--

  Missing(3): shard-rkl shard-dg1 shard-tglu 


Changes
---

  No changes found


Build changes
-

  * CI: CI-20190529 -> None
  * IGT: IGT_6663 -> IGTPW_7800
  * Linux: CI_DRM_12185 -> Patchwork_104278v8

  CI-20190529: 20190529
  CI_DRM_12185: ae6a4bb62f9524823ef5b00552e27231f7936da3 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_7800: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_7800/index.html
  IGT_6663: 5e232c77cd762147e0882c337a984121fabb1c75 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_104278v8: ae6a4bb62f9524823ef5b00552e27231f7936da3 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Fix Guc-Err-Capture sizing warning

2022-09-29 Thread Patchwork

== Series Details ==

Series: Fix Guc-Err-Capture sizing warning
URL   : https://patchwork.freedesktop.org/series/109276/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12202 -> Patchwork_109276v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (47 -> 43)
--

  Missing(4): fi-ctg-p8600 bat-dg2-9 fi-bdw-samus fi-hsw-4200u 

Known issues


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

### IGT changes ###

 Issues hit 

  * 
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka:   [PASS][1] -> [FAIL][2] ([i915#6298])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_pm:
- {bat-rpls-2}:   [DMESG-FAIL][3] ([i915#4258]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12202/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109276v1/bat-rpls-2/igt@i915_selftest@live@gt_pm.html

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

  [i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298


Build changes
-

  * Linux: CI_DRM_12202 -> Patchwork_109276v1

  CI-20190529: 20190529
  CI_DRM_12202: 0b9f0501c9541cf79fdfb43a7760360a81453d88 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6670: d618e9865fe5cbaf511ca43503abad442605d0a5 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_109276v1: 0b9f0501c9541cf79fdfb43a7760360a81453d88 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

aa3aa2f83b0c drm/i915/guc: Fix GuC error capture sizing estimation and reporting

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for Improve anti-pre-emption w/a for compute workloads (rev7)

2022-09-29 Thread Patchwork

== Series Details ==

Series: Improve anti-pre-emption w/a for compute workloads (rev7)
URL   : https://patchwork.freedesktop.org/series/100428/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12197_full -> Patchwork_100428v7_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 12)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_module_load@resize-bar:
- {shard-dg1}:[FAIL][1] ([i915#6458]) -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-dg1-19/igt@i915_module_l...@resize-bar.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100428v7/shard-dg1-18/igt@i915_module_l...@resize-bar.html

  * igt@kms_cursor_legacy@single-move@pipe-c:
- {shard-rkl}:[PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-rkl-4/igt@kms_cursor_legacy@single-m...@pipe-c.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100428v7/shard-rkl-3/igt@kms_cursor_legacy@single-m...@pipe-c.html

  * {igt@kms_plane_alpha_blend@alpha-transparent-fb}:
- {shard-rkl}:NOTRUN -> [SKIP][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100428v7/shard-rkl-3/igt@kms_plane_alpha_bl...@alpha-transparent-fb.html

  * igt@kms_rotation_crc@primary-rotation-270:
- {shard-rkl}:[SKIP][6] ([i915#1845] / [i915#4098]) -> 
[INCOMPLETE][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-rkl-2/igt@kms_rotation_...@primary-rotation-270.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100428v7/shard-rkl-6/igt@kms_rotation_...@primary-rotation-270.html

  * igt@sysfs_preempt_timeout@idempotent@rcs0:
- {shard-dg1}:[PASS][8] -> [FAIL][9] +4 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-dg1-16/igt@sysfs_preempt_timeout@idempot...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100428v7/shard-dg1-15/igt@sysfs_preempt_timeout@idempot...@rcs0.html

  
New tests
-

  New tests have been introduced between CI_DRM_12197_full and 
Patchwork_100428v7_full:

### New IGT tests (4) ###

  * igt@kms_plane_alpha_blend@constant-alpha-max@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [2.85] s

  * igt@kms_plane_alpha_blend@constant-alpha-max@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [2.86] s

  * igt@kms_plane_alpha_blend@constant-alpha-max@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [2.88] s

  * igt@kms_plane_alpha_blend@constant-alpha-max@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [2.86] s

  

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-snb:  ([PASS][10], [PASS][11], [PASS][12], [PASS][13], 
[PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], 
[PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], 
[PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], 
[PASS][32], [PASS][33], [PASS][34]) -> ([PASS][35], [PASS][36], [PASS][37], 
[PASS][38], [PASS][39], [PASS][40], [PASS][41], [FAIL][42], [FAIL][43], 
[PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], 
[PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54], [PASS][55], 
[PASS][56], [PASS][57], [PASS][58], [PASS][59]) ([i915#4338])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-snb7/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-snb7/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-snb7/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-snb7/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-snb6/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-snb6/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-snb6/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-snb6/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-snb6/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-snb6/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-snb5/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-snb5/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-snb5/boot.html
   [23]:

Re: [Intel-gfx] [PATCH v4 15/15] vfio: Add struct device to vfio_device

2022-09-29 Thread Tian, Kevin

> From: Alex Williamson 
> Sent: Friday, September 30, 2022 2:24 AM
> 
> On Thu, 29 Sep 2022 14:49:56 -0300
> Jason Gunthorpe  wrote:
> 
> > On Thu, Sep 29, 2022 at 10:55:19AM -0600, Alex Williamson wrote:
> > > Hi Kevin,
> > >
> > > This introduced the regression discovered here:
> > >
> > >
> https://lore.kernel.org/all/20220928125650.0a2ea297.alex.williamson@redh
> at.com/
> > >
> > > Seems we're not releasing the resources when removing an mdev.  This is
> > > a regression, so it needs to be fixed or reverted before the merge
> > > window.  Thanks,
> >
> > My guess at the fix for this:
> >
> > https://lore.kernel.org/r/0-v1-013609965fe8+9d-
> vfio_gvt_unregister_...@nvidia.com
> 
> Indeed this seems to work  I'll look for acks and further reviews from
> Intel folks. Thanks!
> 

Thanks Jason for baking a quick fix! I've acked it.

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Add missing vfio_unregister_group_dev() call

2022-09-29 Thread Tian, Kevin

> From: Jason Gunthorpe
> Sent: Friday, September 30, 2022 1:49 AM
> 
> When converting to directly create the vfio_device the mdev driver has to
> put a vfio_register_emulated_iommu_dev() in the probe() and a pairing
> vfio_unregister_group_dev() in the remove.
> 
> This was missed for gvt, add it.
> 
> Cc: sta...@vger.kernel.org
> Fixes: 978cf586ac35 ("drm/i915/gvt: convert to use
> vfio_register_emulated_iommu_dev")
> Reported-by: Alex Williamson 
> Signed-off-by: Jason Gunthorpe 

Reviewed-by: Kevin Tian

[Intel-gfx] [PATCH 0/1] Fix Guc-Err-Capture sizing warning

2022-09-29 Thread Alan Previn

GuC Error capture initialization calculates an estimation
buffer size for worst case scenario of all engines getting
reset. Fix the calculation change from drm_warn to drm_dbg
since its a corner case

Alan Previn (1):
  drm/i915/guc: Fix GuC error capture sizing estimation and reporting

 .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 31 ---
 1 file changed, 19 insertions(+), 12 deletions(-)


base-commit: 0b9f0501c9541cf79fdfb43a7760360a81453d88
-- 
2.34.1

[Intel-gfx] [PATCH 1/1] drm/i915/guc: Fix GuC error capture sizing estimation and reporting

2022-09-29 Thread Alan Previn

During GuC error capture initialization, we estimate the amount of size
we need for the error-capture-region of the shared GuC-log-buffer.
This calculation was incorrect so fix that. Additionally, if the size
was insufficient, don't drm_warn or drm_notice, just drm_debug since
actually running out based on that estimation is a corner case. It
can only occur if all engine instances get reset all at once and i915
isn't able extract the capture data fast enough within G2H handler
worker.

Fixes d7c15d76a5547: drm/i915/guc: Check sizing of guc_capture output

Signed-off-by: Alan Previn 
---
 .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 31 ---
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 8f1165146013..cb62507c91ce 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -502,8 +502,9 @@ intel_guc_capture_getlistsize(struct intel_guc *guc, u32 
owner, u32 type, u32 cl
if (!num_regs)
return -ENODATA;
 
-   *size = PAGE_ALIGN((sizeof(struct guc_debug_capture_list)) +
-  (num_regs * sizeof(struct guc_mmio_reg)));
+   if (size)
+   *size = PAGE_ALIGN((sizeof(struct guc_debug_capture_list)) +
+  (num_regs * sizeof(struct guc_mmio_reg)));
 
return 0;
 }
@@ -606,7 +607,7 @@ guc_capture_output_min_size_est(struct intel_guc *guc)
struct intel_gt *gt = guc_to_gt(guc);
struct intel_engine_cs *engine;
enum intel_engine_id id;
-   int worst_min_size = 0, num_regs = 0;
+   int worst_min_size = 0;
size_t tmp = 0;
 
if (!guc->capture)
@@ -628,20 +629,18 @@ guc_capture_output_min_size_est(struct intel_guc *guc)
 (3 * sizeof(struct 
guc_state_capture_header_t));
 
if (!intel_guc_capture_getlistsize(guc, 0, 
GUC_CAPTURE_LIST_TYPE_GLOBAL, 0, ))
-   num_regs += tmp;
+   worst_min_size += tmp;
 
if (!intel_guc_capture_getlistsize(guc, 0, 
GUC_CAPTURE_LIST_TYPE_ENGINE_CLASS,
   engine->class, )) {
-   num_regs += tmp;
+   worst_min_size += tmp;
}
if (!intel_guc_capture_getlistsize(guc, 0, 
GUC_CAPTURE_LIST_TYPE_ENGINE_INSTANCE,
   engine->class, )) {
-   num_regs += tmp;
+   worst_min_size += tmp;
}
}
 
-   worst_min_size += (num_regs * sizeof(struct guc_mmio_reg));
-
return worst_min_size;
 }
 
@@ -658,15 +657,23 @@ static void check_guc_capture_size(struct intel_guc *guc)
int spare_size = min_size * GUC_CAPTURE_OVERBUFFER_MULTIPLIER;
u32 buffer_size = intel_guc_log_section_size_capture(>log);
 
+   /*
+* Don't drm_warn or drm_error here on "possible" insufficient size 
because we only run out
+* of space if all engines were to suffer resets all at once AND the 
driver is not able to
+* extract that data fast enough in the interrupt handler worker 
(moving them to the
+* larger pool of pre-allocated capture nodes. If GuC does run out of 
space, we will
+* print an error when processing the G2H event capture-notification 
(search for
+* "INTEL_GUC_STATE_CAPTURE_EVENT_STATUS_NOSPACE").
+*/
if (min_size < 0)
drm_warn(>drm, "Failed to calculate GuC error state 
capture buffer minimum size: %d!\n",
 min_size);
else if (min_size > buffer_size)
-   drm_warn(>drm, "GuC error state capture buffer is too 
small: %d < %d\n",
-buffer_size, min_size);
+   drm_dbg(>drm, "GuC error state capture buffer maybe 
small: %d < %d\n",
+   buffer_size, min_size);
else if (spare_size > buffer_size)
-   drm_notice(>drm, "GuC error state capture buffer maybe 
too small: %d < %d (min = %d)\n",
-  buffer_size, spare_size, min_size);
+   drm_dbg(>drm, "GuC error state capture buffer lacks spare 
size: %d < %d (min = %d)\n",
+   buffer_size, spare_size, min_size);
 }
 
 /*
-- 
2.34.1

[Intel-gfx] ✓ Fi.CI.IGT: success for Move all drivers to a common dma-buf locking convention

2022-09-29 Thread Patchwork

== Series Details ==

Series: Move all drivers to a common dma-buf locking convention
URL   : https://patchwork.freedesktop.org/series/109205/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12197_full -> Patchwork_109205v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 12)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * {igt@kms_plane_alpha_blend@alpha-transparent-fb}:
- {shard-rkl}:NOTRUN -> [SKIP][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109205v1/shard-rkl-4/igt@kms_plane_alpha_bl...@alpha-transparent-fb.html

  
New tests
-

  New tests have been introduced between CI_DRM_12197_full and 
Patchwork_109205v1_full:

### New IGT tests (14) ###

  * igt@kms_color@gamma@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.42] s

  * igt@kms_lease@lease_invalid_plane@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * igt@kms_lease@lease_invalid_plane@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_plane@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_plane@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@page_flip_implicit_plane@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.33] s

  * igt@kms_lease@page_flip_implicit_plane@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.16] s

  * igt@kms_lease@page_flip_implicit_plane@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.17] s

  * igt@kms_lease@page_flip_implicit_plane@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.16] s

  * igt@kms_plane_alpha_blend@coverage-7efc@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [1.22] s

  * igt@kms_plane_alpha_blend@coverage-7efc@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [1.24] s

  * igt@kms_plane_alpha_blend@coverage-7efc@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [1.24] s

  * igt@kms_plane_alpha_blend@coverage-7efc@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [1.23] s

  * igt@kms_rmfb@close-fd@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.20] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-out-fence:
- shard-iclb: [PASS][2] -> [SKIP][3] ([i915#4525])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-iclb2/igt@gem_exec_balan...@parallel-out-fence.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109205v1/shard-iclb3/igt@gem_exec_balan...@parallel-out-fence.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][4] -> [FAIL][5] ([i915#2842])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109205v1/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
- shard-apl:  [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-apl8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109205v1/shard-apl6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109205v1/shard-iclb2/igt@gem_exec_fair@basic-throt...@rcs0.html

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

  * igt@gem_mmap_offset@clear@smem0:
- shard-snb:  [PASS][11] -> [FAIL][12] ([i915#6973])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12197/shard-snb4/igt@gem_mmap_offset@cl...@smem0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109205v1/shard-snb2/igt@gem_mmap_offset@cl...@smem0.html

  * igt@gem_softpin@evict-single-offset:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#4171])
   [13]:

Re: [Intel-gfx] [PATCH v4.1] drm/i915/mtl: Define engine context layouts

2022-09-29 Thread Lucas De Marchi


On Wed, Sep 28, 2022 at 08:55:11AM -0700, Radhakrishna Sripada wrote:

From: Matt Roper 

The part of the media and blitter engine contexts that we care about for
setting up an initial state on MTL are nearly similar to DG2 (and PVC).
The difference being PRT_BB_STATE being replaced with NOP.

For render/compute engines, the part of the context images are nearly
the same, although the layout had a very slight change --- one POSH
register was removed and the placement of some LRI/noops adjusted
slightly to compensate.

v2:
- Dg2, mtl xcs offsets slightly vary. Use a separate offsets array(Bala)
- Add missing nop in xcs offsets(Bala)
v3:
- Fix the spacing for nop in xcs offset(MattR)
v4:
- Fix rcs register offset(MattR)
v4.1:
- Fix commit message(Lucas)

Bspec: 46261, 46260, 45585
Cc: Balasubramani Vivekanandan 
Cc: Licas De Marchi 
Signed-off-by: Matt Roper 
Signed-off-by: Radhakrishna Sripada 



Reviewed-by: Lucas De Marchi 

Lucas De Marchi

Re: [Intel-gfx] [PATCH] drm/i915: Fix CFI violations in gt_sysfs

2022-09-29 Thread Nathan Chancellor

On Fri, Sep 30, 2022 at 12:34:41AM +0200, Andrzej Hajda wrote:
> On 22.09.2022 21:51, Nathan Chancellor wrote:
> > When booting with clang's kernel control flow integrity series [1],
> > there are numerous violations when accessing the files under
> > /sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0:
> > 
> >$ cd /sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0
> > 
> >$ grep . *
> >id:0
> >punit_req_freq_mhz:350
> >rc6_enable:1
> >rc6_residency_ms:214934
> >rps_act_freq_mhz:1300
> >rps_boost_freq_mhz:1300
> >rps_cur_freq_mhz:350
> >rps_max_freq_mhz:1300
> >rps_min_freq_mhz:350
> >rps_RP0_freq_mhz:1300
> >rps_RP1_freq_mhz:350
> >rps_RPn_freq_mhz:350
> >throttle_reason_pl1:0
> >throttle_reason_pl2:0
> >throttle_reason_pl4:0
> >throttle_reason_prochot:0
> >throttle_reason_ratl:0
> >throttle_reason_status:0
> >throttle_reason_thermal:0
> >throttle_reason_vr_tdc:0
> >throttle_reason_vr_thermalert:0
> > 
> >$ sudo dmesg &| grep "CFI failure at"
> >[  214.595903] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > id_show+0x0/0x70 [i915]; expected type: 0xc527b809)
> >[  214.596064] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > punit_req_freq_mhz_show+0x0/0x40 [i915]; expected type: 0xc527b809)
> >[  214.596407] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > rc6_enable_show+0x0/0x40 [i915]; expected type: 0xc527b809)
> >[  214.596528] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > rc6_residency_ms_show+0x0/0x270 [i915]; expected type: 0xc527b809)
> >[  214.596682] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > act_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
> >[  214.596792] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > boost_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
> >[  214.596893] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > cur_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
> >[  214.596996] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > max_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
> >[  214.597099] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > min_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
> >[  214.597198] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > RP0_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
> >[  214.597301] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > RP1_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
> >[  214.597405] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > RPn_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
> >[  214.597538] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
> >[  214.597701] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
> >[  214.597836] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
> >[  214.597952] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
> >[  214.598071] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
> >[  214.598177] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
> >[  214.598307] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
> >[  214.598439] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
> >[  214.598542] CFI failure at kobj_attr_show+0x19/0x30 (target: 
> > throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
> > 
> > With kCFI, indirect calls are validated against their expected type
> > versus actual type and failures occur when the two types do not match.
> 
> Have you tried this tool with drm subsytem, IIRC there are also similar
> cases with callbacks expecting ptr to different struct than actually passed.

Yes, I have also run a kCFI kernel on an AMD system that I have and I
have not seen any failures from them. I only have AMD and Intel systems
with graphics so there could be other problems lurking in other drivers.

> > The ultimate issue is that these sysfs functions are expecting to be
> > called via dev_attr_show() but they may also be called via
> > kobj_attr_show(), as certain files are created under two different
> > kobjects that have two different sysfs_ops in intel_gt_sysfs_register(),
> > hence the warnings above. When accessing the gt_ files under
> > /sys/devices/pci:00/:00:02.0/drm/card0, which are using the same
> > sysfs

Re: [Intel-gfx] [PATCH] drm/i915: Fix CFI violations in gt_sysfs

2022-09-29 Thread Andrzej Hajda


On 22.09.2022 21:51, Nathan Chancellor wrote:

When booting with clang's kernel control flow integrity series [1],
there are numerous violations when accessing the files under
/sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0:

   $ cd /sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0

   $ grep . *
   id:0
   punit_req_freq_mhz:350
   rc6_enable:1
   rc6_residency_ms:214934
   rps_act_freq_mhz:1300
   rps_boost_freq_mhz:1300
   rps_cur_freq_mhz:350
   rps_max_freq_mhz:1300
   rps_min_freq_mhz:350
   rps_RP0_freq_mhz:1300
   rps_RP1_freq_mhz:350
   rps_RPn_freq_mhz:350
   throttle_reason_pl1:0
   throttle_reason_pl2:0
   throttle_reason_pl4:0
   throttle_reason_prochot:0
   throttle_reason_ratl:0
   throttle_reason_status:0
   throttle_reason_thermal:0
   throttle_reason_vr_tdc:0
   throttle_reason_vr_thermalert:0

   $ sudo dmesg &| grep "CFI failure at"
   [  214.595903] CFI failure at kobj_attr_show+0x19/0x30 (target: 
id_show+0x0/0x70 [i915]; expected type: 0xc527b809)
   [  214.596064] CFI failure at kobj_attr_show+0x19/0x30 (target: 
punit_req_freq_mhz_show+0x0/0x40 [i915]; expected type: 0xc527b809)
   [  214.596407] CFI failure at kobj_attr_show+0x19/0x30 (target: 
rc6_enable_show+0x0/0x40 [i915]; expected type: 0xc527b809)
   [  214.596528] CFI failure at kobj_attr_show+0x19/0x30 (target: 
rc6_residency_ms_show+0x0/0x270 [i915]; expected type: 0xc527b809)
   [  214.596682] CFI failure at kobj_attr_show+0x19/0x30 (target: 
act_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
   [  214.596792] CFI failure at kobj_attr_show+0x19/0x30 (target: 
boost_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
   [  214.596893] CFI failure at kobj_attr_show+0x19/0x30 (target: 
cur_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
   [  214.596996] CFI failure at kobj_attr_show+0x19/0x30 (target: 
max_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
   [  214.597099] CFI failure at kobj_attr_show+0x19/0x30 (target: 
min_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
   [  214.597198] CFI failure at kobj_attr_show+0x19/0x30 (target: 
RP0_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
   [  214.597301] CFI failure at kobj_attr_show+0x19/0x30 (target: 
RP1_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
   [  214.597405] CFI failure at kobj_attr_show+0x19/0x30 (target: 
RPn_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
   [  214.597538] CFI failure at kobj_attr_show+0x19/0x30 (target: 
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
   [  214.597701] CFI failure at kobj_attr_show+0x19/0x30 (target: 
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
   [  214.597836] CFI failure at kobj_attr_show+0x19/0x30 (target: 
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
   [  214.597952] CFI failure at kobj_attr_show+0x19/0x30 (target: 
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
   [  214.598071] CFI failure at kobj_attr_show+0x19/0x30 (target: 
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
   [  214.598177] CFI failure at kobj_attr_show+0x19/0x30 (target: 
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
   [  214.598307] CFI failure at kobj_attr_show+0x19/0x30 (target: 
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
   [  214.598439] CFI failure at kobj_attr_show+0x19/0x30 (target: 
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
   [  214.598542] CFI failure at kobj_attr_show+0x19/0x30 (target: 
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)

With kCFI, indirect calls are validated against their expected type
versus actual type and failures occur when the two types do not match.


Have you tried this tool with drm subsytem, IIRC there are also similar
cases with callbacks expecting ptr to different struct than actually passed.


The ultimate issue is that these sysfs functions are expecting to be
called via dev_attr_show() but they may also be called via
kobj_attr_show(), as certain files are created under two different
kobjects that have two different sysfs_ops in intel_gt_sysfs_register(),
hence the warnings above. When accessing the gt_ files under
/sys/devices/pci:00/:00:02.0/drm/card0, which are using the same
sysfs functions, there are no violations, meaning the functions are
being called with the proper type.

To make everything work properly, adjust certain functions to match the
type of the ->show() and ->store() members in 'struct kobj_attribute'.
Add a macro to generate functions for that can be called via both
dev_attr_{show,store}() or kobj_attr_{show,store}() so that they can be
called through both kobject locations without violating kCFI and adjust
the attribute groups to account for this.

[1]: https://lore.kernel.org/20220908215504.3686827-1-samitolva...@google.com/

Link:

Re: [Intel-gfx] [PATCH v5] drm/i915/mtl: enable local stolen memory

2022-09-29 Thread Matt Roper

On Thu, Sep 29, 2022 at 05:16:58PM +0530, Aravind Iddamsetty wrote:
> As an integrated GPU, MTL does not have local memory and HAS_LMEM()
> returns false.  However the platform's stolen memory is presented via
> BAR2 (i.e., the BAR we traditionally consider to be the GMADR on IGFX)
> and should be managed by the driver the same way that local memory is
> on dgpu platforms (which includes setting the "lmem" bit on page table
> entries).  We use the term "local stolen memory" to refer to this
> model.
> 
> The major difference from the traditional BAR2 (GMADR) is that
> the stolen area is mapped via the BAR2 while in the former BAR2 is an
> aperture into the GTT VA through which access are made into stolen area.
> 
> BSPEC: 53098, 63830
> 
> v2:
> 1. dropped is_dsm_invalid, updated valid_stolen_size check from Lucas
> (Jani, Lucas)
> 2. drop lmembar_is_igpu_stolen
> 3. revert to referring GFXMEM_BAR as GEN12_LMEM_BAR (Lucas)
> 
> v3:(Jani)
> 1. rename get_mtl_gms_size to mtl_get_gms_size
> 2. define register for MMIO address
> 
> v4:(Matt)
> 1. Use REG_FIELD_GET to read GMS value
> 2. replace the calculations with SZ_256M/SZ_8M
> 
> v5: Include more details to commit message on how it is different from
> earlier platforms (Anshuman)
> 
> Cc: Matt Roper 
> Cc: Lucas De Marchi 
> Cc: Jani Nikula 
> 
> Signed-off-by: CQ Tang 
> Signed-off-by: Aravind Iddamsetty 
> Original-author: CQ Tang

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 83 ++
>  drivers/gpu/drm/i915/gt/intel_ggtt.c   |  2 +-
>  drivers/gpu/drm/i915/i915_drv.h|  3 +
>  drivers/gpu/drm/i915/i915_reg.h|  4 ++
>  4 files changed, 76 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index c5a4035c99cd..910086974454 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -77,9 +77,9 @@ void i915_gem_stolen_remove_node(struct drm_i915_private 
> *i915,
>   mutex_unlock(>mm.stolen_lock);
>  }
>  
> -static bool valid_stolen_size(struct resource *dsm)
> +static bool valid_stolen_size(struct drm_i915_private *i915, struct resource 
> *dsm)
>  {
> - return dsm->start != 0 && dsm->end > dsm->start;
> + return (dsm->start != 0 || HAS_BAR2_SMEM_STOLEN(i915)) && dsm->end > 
> dsm->start;
>  }
>  
>  static int adjust_stolen(struct drm_i915_private *i915,
> @@ -88,7 +88,7 @@ static int adjust_stolen(struct drm_i915_private *i915,
>   struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
>   struct intel_uncore *uncore = ggtt->vm.gt->uncore;
>  
> - if (!valid_stolen_size(dsm))
> + if (!valid_stolen_size(i915, dsm))
>   return -EINVAL;
>  
>   /*
> @@ -135,7 +135,7 @@ static int adjust_stolen(struct drm_i915_private *i915,
>   }
>   }
>  
> - if (!valid_stolen_size(dsm))
> + if (!valid_stolen_size(i915, dsm))
>   return -EINVAL;
>  
>   return 0;
> @@ -149,8 +149,11 @@ static int request_smem_stolen(struct drm_i915_private 
> *i915,
>   /*
>* With stolen lmem, we don't need to request system memory for the
>* address range since it's local to the gpu.
> +  *
> +  * Starting MTL, in IGFX devices the stolen memory is exposed via
> +  * BAR2 and shall be considered similar to stolen lmem.
>*/
> - if (HAS_LMEM(i915))
> + if (HAS_LMEM(i915) || HAS_BAR2_SMEM_STOLEN(i915))
>   return 0;
>  
>   /*
> @@ -385,8 +388,6 @@ static void icl_get_stolen_reserved(struct 
> drm_i915_private *i915,
>  
>   drm_dbg(>drm, "GEN6_STOLEN_RESERVED = 0x%016llx\n", reg_val);
>  
> - *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
> -
>   switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
>   case GEN8_STOLEN_RESERVED_1M:
>   *size = 1024 * 1024;
> @@ -404,6 +405,12 @@ static void icl_get_stolen_reserved(struct 
> drm_i915_private *i915,
>   *size = 8 * 1024 * 1024;
>   MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
>   }
> +
> + if (HAS_BAR2_SMEM_STOLEN(i915))
> + /* the base is initialized to stolen top so subtract size to 
> get base */
> + *base -= *size;
> + else
> + *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
>  }
>  
>  /*
> @@ -833,6 +840,29 @@ static const struct intel_memory_region_ops 
> i915_region_stolen_lmem_ops = {
>   .init_object = _i915_gem_object_stolen_init,
>  };
>  
> +static int mtl_get_gms_size(struct intel_uncore *uncore)
> +{
> + u16 ggc, gms;
> +
> + ggc = intel_uncore_read16(uncore, GGC);
> +
> + /* check GGMS, should be fixed 0x3 (8MB) */
> + if ((ggc & GGMS_MASK) != GGMS_MASK)
> + return -EIO;
> +
> + /* return valid GMS value, -EIO if invalid */
> + gms = REG_FIELD_GET(GMS_MASK, ggc);
> + switch (gms) {
> + case 0x0 ... 0x04:
> +

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

2022-09-29 Thread Patchwork

== Series Details ==

Series: drm/i915/mtl: Add C10 phy support
URL   : https://patchwork.freedesktop.org/series/109248/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12199 -> Patchwork_109248v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (49 -> 44)
--

  Missing(5): fi-hsw-4200u bat-dg1-5 fi-ctg-p8600 fi-hsw-4770 fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@slpc:
- {bat-rpls-2}:   [DMESG-FAIL][1] ([i915#6367]) -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12199/bat-rpls-2/igt@i915_selftest@l...@slpc.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109248v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html
- {bat-adln-1}:   [PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12199/bat-adln-1/igt@i915_selftest@l...@slpc.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109248v1/bat-adln-1/igt@i915_selftest@l...@slpc.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@gem_contexts:
- fi-icl-u2:  [PASS][5] -> [INCOMPLETE][6] ([i915#4890])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12199/fi-icl-u2/igt@i915_selftest@live@gem_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109248v1/fi-icl-u2/igt@i915_selftest@live@gem_contexts.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-snb-2600:NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109248v1/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@runner@aborted:
- fi-icl-u2:  NOTRUN -> [FAIL][8] ([i915#4312])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109248v1/fi-icl-u2/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-adlm-1}:   [DMESG-WARN][9] ([i915#2867]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12199/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109248v1/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html

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

  * 
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka:   [FAIL][13] ([i915#6298]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12199/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109248v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4890]: https://gitlab.freedesktop.org/drm/intel/issues/4890
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6471]: https://gitlab.freedesktop.org/drm/intel/issues/6471
  [i915#6818]: https://gitlab.freedesktop.org/drm/intel/issues/6818
  [i915#6992]: https://gitlab.freedesktop.org/drm/intel/issues/6992


Build changes
-

  * Linux: CI_DRM_12199 -> Patchwork_109248v1

  CI-20190529: 20190529
  CI_DRM_12199: 6fa6bc62d3b91e5a70b8e4869436a0b03083abf5 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6669: 3d2df081c14c251e0269e3510ddc4e9d26ffe925 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_109248v1: 6fa6bc62d3b91e5a70b8e4869436a0b03083abf5 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

4d575208d033 drm/i915/mtl: Add vswing programming

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gvt: Add missing vfio_unregister_group_dev() call

2022-09-29 Thread Patchwork

== Series Details ==

Series: drm/i915/gvt: Add missing vfio_unregister_group_dev() call
URL   : https://patchwork.freedesktop.org/series/109264/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/109264/revisions/1/mbox/ not 
applied
Applying: drm/i915/gvt: Add missing vfio_unregister_group_dev() call
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/gvt/kvmgt.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/gvt/kvmgt.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gvt/kvmgt.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/i915/gvt: Add missing vfio_unregister_group_dev() call
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: Analog TV Improvements (rev3)

2022-09-29 Thread Patchwork

== Series Details ==

Series: drm: Analog TV Improvements (rev3)
URL   : https://patchwork.freedesktop.org/series/107892/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/107892/revisions/3/mbox/ not 
applied
Applying: drm/docs: Remove unused TV Standard property
Applying: drm/tests: Order Kunit tests in Makefile
Applying: drm/tests: Add Kunit Helpers
Applying: drm/atomic-helper: Rename drm_atomic_helper_connector_tv_reset to 
avoid ambiguity
Applying: drm/connector: Rename subconnector state variable
Applying: drm/atomic: Add TV subconnector property to get/set_property
Applying: drm/connector: Rename legacy TV property
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/display/intel_tv.c
M   include/drm/drm_connector.h
Falling back to patching base and 3-way merge...
Auto-merging include/drm/drm_connector.h
Auto-merging drivers/gpu/drm/i915/display/intel_tv.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/display/intel_tv.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0007 drm/connector: Rename legacy TV property
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

2022-09-29 Thread Patchwork

== Series Details ==

Series: drm/i915/mtl: Add C10 phy support
URL   : https://patchwork.freedesktop.org/series/109248/
State : warning

== Summary ==

Error: dim checkpatch failed
7a245d0165a3 drm/i915/mtl: Add Support for C10, C20 PHY Message Bus
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:19: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#19: 
new file mode 100644

-:44: WARNING:QUOTED_WHITESPACE_BEFORE_NEWLINE: unnecessary whitespace before a 
quoted newline
#44: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:21:
+   drm_err_once(>drm, "Failed to bring PHY %c to idle. \n", 
phy_name(phy));

-:50: WARNING:RETURN_VOID: void function return statements are not generally 
useful
#50: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:27:
+   return;
+}

-:61: WARNING:LONG_LINE: line length of 142 exceeds 100 columns
#61: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:38:
+   drm_err_once(>drm, "PHY %c Read %04x failed after %d 
retries. Status: 0x%x\n", phy_name(phy), addr, attempts, val ?: 0);

-:69: WARNING:LONG_LINE: line length of 142 exceeds 100 columns
#69: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:46:
+   drm_dbg(>drm, "PHY %c Timeout waiting for previous 
transaction to complete. Reset the bus and retry.\n", phy_name(phy));

-:88: WARNING:LONG_LINE: line length of 120 exceeds 100 columns
#88: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:65:
+   drm_dbg(>drm, "PHY %c Timeout waiting for Read response 
ACK. Status: 0x%x\n", phy_name(phy), val);

-:96: WARNING:LONG_LINE: line length of 117 exceeds 100 columns
#96: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:73:
+   drm_dbg(>drm, "PHY %c Error occurred during read command. 
Status: 0x%x\n", phy_name(phy), val);

-:105: WARNING:LONG_LINE: line length of 110 exceeds 100 columns
#105: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:82:
+   drm_dbg(>drm, "PHY %c Not a Read response. MSGBUS Status: 
0x%x.\n", phy_name(phy), val);

-:117: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#117: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:94:
+static int intel_cx0_wait_cwrite_ack(struct drm_i915_private *i915,
+ enum port port, int lane)

-:129: WARNING:LONG_LINE: line length of 124 exceeds 100 columns
#129: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:106:
+   drm_dbg(>drm, "PHY %c Timeout waiting for Committed 
message ACK. Status: 0x%x\n", phy_name(phy), val);

-:135: WARNING:LONG_LINE: line length of 114 exceeds 100 columns
#135: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:112:
+   drm_dbg(>drm, "PHY %c Unexpected ACK received. MSGBUS 
STATUS: 0x%x.\n", phy_name(phy), val);

-:150: WARNING:LONG_LINE: line length of 120 exceeds 100 columns
#150: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:127:
+   drm_err_once(>drm, "PHY %c Write %04x failed after %d 
retries.\n", phy_name(phy), addr, attempts);

-:158: WARNING:LONG_LINE: line length of 142 exceeds 100 columns
#158: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:135:
+   drm_dbg(>drm, "PHY %c Timeout waiting for previous 
transaction to complete. Reset the bus and retry.\n", phy_name(phy));

-:190: WARNING:RETURN_VOID: void function return statements are not generally 
useful
#190: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:167:
+   return;
+}

total: 0 errors, 13 warnings, 1 checks, 179 lines checked
afd046f59d87 drm/i915/mtl: Add PLL programming support for C10 phy
-:444: ERROR:CODE_INDENT: code indent should use tabs where possible
#444: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:558:
+^I^IC10_VDR_CTRL_MSGBUS_ACCESS, MB_WRITE_COMMITTED);$

-:444: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#444: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:558:
+   intel_cx0_write(i915, encoder->port, INTEL_CX0_BOTH_LANES, 
PHY_C10_VDR_CONTROL(1),
+   C10_VDR_CTRL_MSGBUS_ACCESS, MB_WRITE_COMMITTED);

-:459: WARNING:LONG_LINE: line length of 104 exceeds 100 columns
#459: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:573:
+   intel_cx0_write(i915, encoder->port, master_lane, PHY_C10_VDR_CMN(0), 
cmn0, MB_WRITE_COMMITTED);

-:460: WARNING:LONG_LINE: line length of 110 exceeds 100 columns
#460: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:574:
+   intel_cx0_write(i915, encoder->port, master_lane, PHY_C10_VDR_TX(0), 
C10_TX0_VAL, MB_WRITE_COMMITTED);

-:496: CHECK:SPACING: spaces preferred around that '+' (ctx:VxW)
#496: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:610:
+   i, hw_state->pll[i], i + 1, hw_state->pll[i+ 1],
   ^

-:573:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry (rev3)

2022-09-29 Thread Patchwork

== Series Details ==

Series: drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry (rev3)
URL   : https://patchwork.freedesktop.org/series/108732/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12199 -> Patchwork_108732v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (49 -> 43)
--

  Missing(6): fi-rkl-11600 fi-hsw-4200u fi-icl-u2 fi-ctg-p8600 fi-pnv-d510 
fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@slpc:
- {bat-rpls-2}:   [DMESG-FAIL][1] ([i915#6367]) -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12199/bat-rpls-2/igt@i915_selftest@l...@slpc.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108732v3/bat-rpls-2/igt@i915_selftest@l...@slpc.html
- {bat-adln-1}:   [PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12199/bat-adln-1/igt@i915_selftest@l...@slpc.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108732v3/bat-adln-1/igt@i915_selftest@l...@slpc.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_suspend@basic-s3-without-i915:
- fi-bdw-5557u:   [PASS][5] -> [INCOMPLETE][6] ([i915#146] / 
[i915#6712])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12199/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108732v3/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-snb-2600:NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108732v3/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-adlm-1}:   [DMESG-WARN][8] ([i915#2867]) -> [PASS][9] +1 similar 
issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12199/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108732v3/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html

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

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#5278]: https://gitlab.freedesktop.org/drm/intel/issues/5278
  [i915#5537]: https://gitlab.freedesktop.org/drm/intel/issues/5537
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#6559]: https://gitlab.freedesktop.org/drm/intel/issues/6559
  [i915#6712]: https://gitlab.freedesktop.org/drm/intel/issues/6712
  [i915#6818]: https://gitlab.freedesktop.org/drm/intel/issues/6818
  [i915#6992]: https://gitlab.freedesktop.org/drm/intel/issues/6992


Build changes
-

  * Linux: CI_DRM_12199 -> Patchwork_108732v3

  CI-20190529: 20190529
  CI_DRM_12199: 6fa6bc62d3b91e5a70b8e4869436a0b03083abf5 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6669: 3d2df081c14c251e0269e3510ddc4e9d26ffe925 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_108732v3: 6fa6bc62d3b91e5a70b8e4869436a0b03083abf5 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

490039dffc70 drm/i915/gvt: fix double free bug in split_2MB_gtt_entry

== Logs ==

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

Re: [Intel-gfx] [PATCH v4 15/15] vfio: Add struct device to vfio_device

2022-09-29 Thread Alex Williamson

On Thu, 29 Sep 2022 14:49:56 -0300
Jason Gunthorpe  wrote:

> On Thu, Sep 29, 2022 at 10:55:19AM -0600, Alex Williamson wrote:
> > Hi Kevin,
> > 
> > This introduced the regression discovered here:
> > 
> > https://lore.kernel.org/all/20220928125650.0a2ea297.alex.william...@redhat.com/
> > 
> > Seems we're not releasing the resources when removing an mdev.  This is
> > a regression, so it needs to be fixed or reverted before the merge
> > window.  Thanks,  
> 
> My guess at the fix for this:
> 
> https://lore.kernel.org/r/0-v1-013609965fe8+9d-vfio_gvt_unregister_...@nvidia.com

Indeed this seems to work  I'll look for acks and further reviews from
Intel folks. Thanks!

Alex

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry (rev3)

2022-09-29 Thread Patchwork

== Series Details ==

Series: drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry (rev3)
URL   : https://patchwork.freedesktop.org/series/108732/
State : warning

== Summary ==

Error: dim checkpatch failed
4b8a44dfb06a drm/i915/gvt: fix double free bug in split_2MB_gtt_entry
-:54: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#54: FILE: drivers/gpu/drm/i915/gvt/gtt.c:1064:
+   trace_spt_change(spt->vgpu->id, "release", spt,
 spt->guest_page.gfn, spt->shadow_page.type);

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: enable local stolen memory (rev5)

2022-09-29 Thread Patchwork

== Series Details ==

Series: drm/i915/mtl: enable local stolen memory (rev5)
URL   : https://patchwork.freedesktop.org/series/109066/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12199 -> Patchwork_109066v5


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (49 -> 45)
--

  Missing(4): fi-ctg-p8600 fi-bdw-5557u fi-bdw-samus fi-hsw-4200u 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@slpc:
- {bat-adln-1}:   [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12199/bat-adln-1/igt@i915_selftest@l...@slpc.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109066v5/bat-adln-1/igt@i915_selftest@l...@slpc.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258:   [PASS][3] -> [INCOMPLETE][4] ([i915#3303] / 
[i915#4785])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12199/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109066v5/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-snb-2600:NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109066v5/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka:   [PASS][6] -> [FAIL][7] ([i915#6298])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12199/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109066v5/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html

  * igt@runner@aborted:
- fi-hsw-g3258:   NOTRUN -> [FAIL][8] ([fdo#109271] / [i915#4312])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109066v5/fi-hsw-g3258/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- {bat-adlm-1}:   [DMESG-WARN][9] ([i915#2867]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12199/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109066v5/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html

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

  * 
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka:   [FAIL][13] ([i915#6298]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12199/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109066v5/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
  [i915#5278]: https://gitlab.freedesktop.org/drm/intel/issues/5278
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6818]: https://gitlab.freedesktop.org/drm/intel/issues/6818
  [i915#6992]: https://gitlab.freedesktop.org/drm/intel/issues/6992


Build changes
-

  * Linux: CI_DRM_12199 -> Patchwork_109066v5

  CI-20190529: 20190529
  CI_DRM_12199: 6fa6bc62d3b91e5a70b8e4869436a0b03083abf5 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6669:

Re: [Intel-gfx] [PATCH 05/16] drm/i915/vm_bind: Implement bind and unbind of object

2022-09-29 Thread Niranjana Vishwanathapura


On Thu, Sep 29, 2022 at 06:28:39PM +0100, Matthew Auld wrote:

On 29/09/2022 17:38, Niranjana Vishwanathapura wrote:

On Thu, Sep 29, 2022 at 11:49:30AM +0100, Matthew Auld wrote:

On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:

Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.

The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be supported only in the newer execbuf3 ioctl.

Signed-off-by: Niranjana Vishwanathapura 


Signed-off-by: Prathap Kumar Valsan 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c    |   5 +
 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |  26 ++
 .../drm/i915/gem/i915_gem_vm_bind_object.c    | 306 ++
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  10 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  17 +
 drivers/gpu/drm/i915/i915_driver.c    |   3 +
 drivers/gpu/drm/i915/i915_vma.c   |   1 +
 drivers/gpu/drm/i915/i915_vma_types.h |  14 +
 include/uapi/drm/i915_drm.h   | 112 +++
 10 files changed, 495 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

diff --git a/drivers/gpu/drm/i915/Makefile 
b/drivers/gpu/drm/i915/Makefile

index a26edcdadc21..9bf939ef18ea 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -166,6 +166,7 @@ gem-y += \
 gem/i915_gem_ttm_move.o \
 gem/i915_gem_ttm_pm.o \
 gem/i915_gem_userptr.o \
+    gem/i915_gem_vm_bind_object.o \
 gem/i915_gem_wait.o \
 gem/i915_gemfs.o
 i915-y += \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c

index cd75b0ca2555..f85f10cf9c34 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -781,6 +781,11 @@ static int eb_select_context(struct 
i915_execbuffer *eb)

 if (unlikely(IS_ERR(ctx)))
 return PTR_ERR(ctx);
+    if (ctx->vm->vm_bind_mode) {
+    i915_gem_context_put(ctx);
+    return -EOPNOTSUPP;
+    }
+
 eb->gem_context = ctx;
 if (i915_gem_context_has_full_ppgtt(ctx))
 eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h

new file mode 100644
index ..36262a6357b5
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __I915_GEM_VM_BIND_H
+#define __I915_GEM_VM_BIND_H
+
+#include 
+
+struct drm_device;
+struct drm_file;
+struct i915_address_space;
+struct i915_vma;
+
+struct i915_vma *
+i915_gem_vm_bind_lookup_vma(struct i915_address_space *vm, u64 va);
+
+int i915_gem_vm_bind_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *file);
+int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file);
+
+void i915_gem_vm_unbind_all(struct i915_address_space *vm);
+
+#endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

new file mode 100644
index ..e529162abd2c
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+
+#include 
+
+#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_vm_bind.h"
+
+#include "gt/intel_gpu_commands.h"
+
+#define START(node) ((node)->start)
+#define LAST(node) ((node)->last)
+
+INTERVAL_TREE_DEFINE(struct i915_vma, rb, u64, __subtree_last,
+ START, LAST, static inline, i915_vm_bind_it)
+
+#undef START
+#undef LAST
+
+/**
+ * DOC: VM_BIND/UNBIND ioctls
+ *
+ * DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind 
GEM buffer
+ * objects (BOs) or sections of a BOs at specified GPU virtual 
addresses on a
+ * specified address space (VM). Multiple mappings can map to 
the same physical
+ * pages of an object (aliasing). These mappings (also referred 
to as persistent
+ * mappings) will be persistent across multiple GPU submissions 
(execbuf calls)
+ * issued by the UMD, without user having to provide a list of 
all required

+ * mappings during each submission (as required by older execbuf mode).
+ *
+ * The VM_BIND/UNBIND calls allow UMDs to request a timeline 
out fence for

+ * signaling the completion of bind/unbind operation.
+ *
+ * VM_BIND feature is advertised to user via 
I915_PARAM_VM_BIND_VERSION.
+ * User has to opt-in for VM_BIND mode of binding for an 
address space (VM)
+ * during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND 
extension.

+ *
+ * VM_BIND/UNBIND ioctl calls executed on different CPU threads

[Intel-gfx] [PATCH] drm/i915/gvt: Add missing vfio_unregister_group_dev() call

2022-09-29 Thread Jason Gunthorpe

When converting to directly create the vfio_device the mdev driver has to
put a vfio_register_emulated_iommu_dev() in the probe() and a pairing
vfio_unregister_group_dev() in the remove.

This was missed for gvt, add it.

Cc: sta...@vger.kernel.org
Fixes: 978cf586ac35 ("drm/i915/gvt: convert to use 
vfio_register_emulated_iommu_dev")
Reported-by: Alex Williamson 
Signed-off-by: Jason Gunthorpe 
---
 drivers/gpu/drm/i915/gvt/kvmgt.c | 1 +
 1 file changed, 1 insertion(+)

Should go through Alex's tree.

diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 41bba40feef8f4..9003145adb5a93 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1615,6 +1615,7 @@ static void intel_vgpu_remove(struct mdev_device *mdev)
if (WARN_ON_ONCE(vgpu->attached))
return;
 
+   vfio_unregister_group_dev(>vfio_device);
vfio_put_device(>vfio_device);
 }
 

base-commit: c72e0034e6d4c36322d958b997d11d2627c6056c
-- 
2.37.3

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: enable local stolen memory (rev5)

2022-09-29 Thread Patchwork

== Series Details ==

Series: drm/i915/mtl: enable local stolen memory (rev5)
URL   : https://patchwork.freedesktop.org/series/109066/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/mtl: enable local stolen memory (rev5)

2022-09-29 Thread Patchwork

== Series Details ==

Series: drm/i915/mtl: enable local stolen memory (rev5)
URL   : https://patchwork.freedesktop.org/series/109066/
State : warning

== Summary ==

Error: dim checkpatch failed
7e639baeef13 drm/i915/mtl: enable local stolen memory
-:230: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible 
side-effects?
#230: FILE: drivers/gpu/drm/i915/i915_drv.h:977:
+#define HAS_BAR2_SMEM_STOLEN(i915) (!HAS_LMEM(i915) && \
+   GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))

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

Re: [Intel-gfx] [PATCH 05/16] drm/i915/vm_bind: Implement bind and unbind of object

2022-09-29 Thread Matthew Auld


On 29/09/2022 17:38, Niranjana Vishwanathapura wrote:

On Thu, Sep 29, 2022 at 11:49:30AM +0100, Matthew Auld wrote:

On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:

Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.

The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be supported only in the newer execbuf3 ioctl.

Signed-off-by: Niranjana Vishwanathapura 


Signed-off-by: Prathap Kumar Valsan 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c    |   5 +
 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |  26 ++
 .../drm/i915/gem/i915_gem_vm_bind_object.c    | 306 ++
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  10 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  17 +
 drivers/gpu/drm/i915/i915_driver.c    |   3 +
 drivers/gpu/drm/i915/i915_vma.c   |   1 +
 drivers/gpu/drm/i915/i915_vma_types.h |  14 +
 include/uapi/drm/i915_drm.h   | 112 +++
 10 files changed, 495 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

diff --git a/drivers/gpu/drm/i915/Makefile 
b/drivers/gpu/drm/i915/Makefile

index a26edcdadc21..9bf939ef18ea 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -166,6 +166,7 @@ gem-y += \
 gem/i915_gem_ttm_move.o \
 gem/i915_gem_ttm_pm.o \
 gem/i915_gem_userptr.o \
+    gem/i915_gem_vm_bind_object.o \
 gem/i915_gem_wait.o \
 gem/i915_gemfs.o
 i915-y += \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c

index cd75b0ca2555..f85f10cf9c34 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -781,6 +781,11 @@ static int eb_select_context(struct 
i915_execbuffer *eb)

 if (unlikely(IS_ERR(ctx)))
 return PTR_ERR(ctx);
+    if (ctx->vm->vm_bind_mode) {
+    i915_gem_context_put(ctx);
+    return -EOPNOTSUPP;
+    }
+
 eb->gem_context = ctx;
 if (i915_gem_context_has_full_ppgtt(ctx))
 eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h

new file mode 100644
index ..36262a6357b5
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __I915_GEM_VM_BIND_H
+#define __I915_GEM_VM_BIND_H
+
+#include 
+
+struct drm_device;
+struct drm_file;
+struct i915_address_space;
+struct i915_vma;
+
+struct i915_vma *
+i915_gem_vm_bind_lookup_vma(struct i915_address_space *vm, u64 va);
+
+int i915_gem_vm_bind_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *file);
+int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file);
+
+void i915_gem_vm_unbind_all(struct i915_address_space *vm);
+
+#endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

new file mode 100644
index ..e529162abd2c
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+
+#include 
+
+#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_vm_bind.h"
+
+#include "gt/intel_gpu_commands.h"
+
+#define START(node) ((node)->start)
+#define LAST(node) ((node)->last)
+
+INTERVAL_TREE_DEFINE(struct i915_vma, rb, u64, __subtree_last,
+ START, LAST, static inline, i915_vm_bind_it)
+
+#undef START
+#undef LAST
+
+/**
+ * DOC: VM_BIND/UNBIND ioctls
+ *
+ * DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM 
buffer
+ * objects (BOs) or sections of a BOs at specified GPU virtual 
addresses on a
+ * specified address space (VM). Multiple mappings can map to the 
same physical
+ * pages of an object (aliasing). These mappings (also referred to 
as persistent
+ * mappings) will be persistent across multiple GPU submissions 
(execbuf calls)
+ * issued by the UMD, without user having to provide a list of all 
required

+ * mappings during each submission (as required by older execbuf mode).
+ *
+ * The VM_BIND/UNBIND calls allow UMDs to request a timeline out 
fence for

+ * signaling the completion of bind/unbind operation.
+ *
+ * VM_BIND feature is advertised to user via 
I915_PARAM_VM_BIND_VERSION.
+ * User has to opt-in for VM_BIND mode of binding for an address 
space (VM)
+ * during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND 
extension.

+ *
+ * VM_BIND/UNBIND ioctl calls executed on different CPU threads 
concurrently
+ * are not ordered. Furthermore, parts of the

Re: [Intel-gfx] [PATCH 07/16] drm/i915/vm_bind: Add support to handle object evictions

2022-09-29 Thread Matthew Auld


On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:

Support eviction by maintaining a list of evicted persistent vmas
for rebinding during next submission. Ensure the list do not
include persistent vmas that are being purged.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 


Acked-by: Matthew Auld 


---
  .../drm/i915/gem/i915_gem_vm_bind_object.c|  6 ++
  drivers/gpu/drm/i915/gt/intel_gtt.c   |  2 ++
  drivers/gpu/drm/i915/gt/intel_gtt.h   |  4 
  drivers/gpu/drm/i915/i915_vma.c   | 19 +++
  drivers/gpu/drm/i915/i915_vma.h   | 10 ++
  drivers/gpu/drm/i915/i915_vma_types.h | 10 ++
  6 files changed, 51 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 809c78455d2e..958139ed6da3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -85,6 +85,12 @@ static void i915_gem_vm_bind_remove(struct i915_vma *vma, 
bool release_obj)
  {
lockdep_assert_held(>vm->vm_bind_lock);
  
+	spin_lock(>vm->vm_rebind_lock);

+   if (!list_empty(>vm_rebind_link))
+   list_del_init(>vm_rebind_link);
+   i915_vma_set_purged(vma);
+   spin_unlock(>vm->vm_rebind_lock);
+
list_del_init(>vm_bind_link);
list_del_init(>non_priv_vm_bind_link);
i915_vm_bind_it_remove(vma, >vm->va);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index da4f9dee0397..6db31197fa87 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -296,6 +296,8 @@ void i915_address_space_init(struct i915_address_space *vm, 
int subclass)
INIT_LIST_HEAD(>non_priv_vm_bind_list);
vm->root_obj = i915_gem_object_create_internal(vm->i915, PAGE_SIZE);
GEM_BUG_ON(IS_ERR(vm->root_obj));
+   INIT_LIST_HEAD(>vm_rebind_list);
+   spin_lock_init(>vm_rebind_lock);
  }
  
  void *__px_vaddr(struct drm_i915_gem_object *p)

diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 3f2e87d3bf34..b73d35b4e05d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -273,6 +273,10 @@ struct i915_address_space {
struct list_head vm_bind_list;
/** @vm_bound_list: List of vm_binding completed */
struct list_head vm_bound_list;
+   /* @vm_rebind_list: list of vmas to be rebinded */
+   struct list_head vm_rebind_list;
+   /* @vm_rebind_lock: protects vm_rebound_list */
+   spinlock_t vm_rebind_lock;
/* @va: tree of persistent vmas */
struct rb_root_cached va;
struct list_head non_priv_vm_bind_list;
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 89c276163916..84ed3d1a17a6 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -241,6 +241,7 @@ vma_create(struct drm_i915_gem_object *obj,
  
  	INIT_LIST_HEAD(>vm_bind_link);

INIT_LIST_HEAD(>non_priv_vm_bind_link);
+   INIT_LIST_HEAD(>vm_rebind_link);
return vma;
  
  err_unlock:

@@ -1686,6 +1687,14 @@ static void force_unbind(struct i915_vma *vma)
if (!drm_mm_node_allocated(>node))
return;
  
+	/*

+* Persistent vma should have been purged by now.
+* If not, issue a warning and purge it.
+*/
+   if (GEM_WARN_ON(i915_vma_is_persistent(vma) &&
+   !i915_vma_is_purged(vma)))
+   i915_vma_set_purged(vma);
+
atomic_and(~I915_VMA_PIN_MASK, >flags);
WARN_ON(__i915_vma_unbind(vma));
GEM_BUG_ON(drm_mm_node_allocated(>node));
@@ -2048,6 +2057,16 @@ int __i915_vma_unbind(struct i915_vma *vma)
__i915_vma_evict(vma, false);
  
  	drm_mm_remove_node(>node); /* pairs with i915_vma_release() */

+
+   if (i915_vma_is_persistent(vma)) {
+   spin_lock(>vm->vm_rebind_lock);
+   if (list_empty(>vm_rebind_link) &&
+   !i915_vma_is_purged(vma))
+   list_add_tail(>vm_rebind_link,
+ >vm->vm_rebind_list);
+   spin_unlock(>vm->vm_rebind_lock);
+   }
+
return 0;
  }
  
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h

index 51e712de380a..48731855b5b0 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -152,6 +152,16 @@ static inline void i915_vma_set_persistent(struct i915_vma 
*vma)
set_bit(I915_VMA_PERSISTENT_BIT, __i915_vma_flags(vma));
  }
  
+static inline bool i915_vma_is_purged(const struct i915_vma *vma)

+{
+   return test_bit(I915_VMA_PURGED_BIT, __i915_vma_flags(vma));
+}
+
+static inline void i915_vma_set_purged(struct i915_vma *vma)
+{
+   set_bit(I915_VMA_PURGED_BIT,

Re: [Intel-gfx] [PATCH 04/16] drm/i915/vm_bind: Add support to create persistent vma

2022-09-29 Thread Matthew Auld


On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:

Add i915_vma_instance_persistent() to create persistent vmas.
Persistent vmas will use i915_gtt_view to support partial binding.

vma_lookup is tied to segment of the object instead of section
of VA space. Hence, it do not support aliasing. ie., multiple
mappings (at different VA) point to the same gtt_view of object.
Skip vma_lookup for persistent vmas to support aliasing.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 


Acked-by: Matthew Auld

[Intel-gfx] ✓ Fi.CI.IGT: success for iommu: Remove iova cpu hotplugging flushing (rev2)

2022-09-29 Thread Patchwork

== Series Details ==

Series: iommu: Remove iova cpu hotplugging flushing (rev2)
URL   : https://patchwork.freedesktop.org/series/108880/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_108880v2_full


Summary
---

  **WARNING**

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

  

Participating hosts (10 -> 12)
--

  Additional (2): shard-dg1 shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * {igt@kms_color@ctm-0-75@pipe-b-hdmi-a-3} (NEW):
- {shard-dg1}:NOTRUN -> [FAIL][1] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v2/shard-dg1-19/igt@kms_color@ctm-0...@pipe-b-hdmi-a-3.html

  
 Warnings 

  * igt@runner@aborted:
- shard-skl:  ([FAIL][2], [FAIL][3], [FAIL][4], [FAIL][5], 
[FAIL][6], [FAIL][7], [FAIL][8], [FAIL][9], [FAIL][10], [FAIL][11], [FAIL][12], 
[FAIL][13], [FAIL][14], [FAIL][15], [FAIL][16], [FAIL][17], [FAIL][18], 
[FAIL][19], [FAIL][20], [FAIL][21], [FAIL][22]) ([i915#6641]) -> ([FAIL][23], 
[FAIL][24]) ([i915#3002] / [i915#4312])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl3/igt@run...@aborted.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl9/igt@run...@aborted.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl9/igt@run...@aborted.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl10/igt@run...@aborted.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl4/igt@run...@aborted.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl1/igt@run...@aborted.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl7/igt@run...@aborted.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl10/igt@run...@aborted.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl9/igt@run...@aborted.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl4/igt@run...@aborted.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl4/igt@run...@aborted.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl6/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl7/igt@run...@aborted.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl7/igt@run...@aborted.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl10/igt@run...@aborted.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl7/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl10/igt@run...@aborted.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl2/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl4/igt@run...@aborted.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl10/igt@run...@aborted.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl3/igt@run...@aborted.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v2/shard-skl10/igt@run...@aborted.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v2/shard-skl4/igt@run...@aborted.html

  
 Suppressed 

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

  * igt@kms_atomic_transition@plane-all-transition-nonblocking-fencing:
- {shard-tglu}:   NOTRUN -> [SKIP][25] +72 similar issues
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v2/shard-tglu-8/igt@kms_atomic_transit...@plane-all-transition-nonblocking-fencing.html

  
New tests
-

  New tests have been introduced between CI_DRM_12193_full and 
Patchwork_108880v2_full:

### New IGT tests (27) ###

  * igt@gem_mmap_offset@ptrace@lmem0-fixed:
- Statuses : 1 fail(s)
- Exec time: [0.02] s

  * igt@gem_mmap_offset@ptrace@smem0-fixed:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_color@ctm-0-75@pipe-b-hdmi-a-3:
- Statuses : 1 fail(s)
- Exec time: [2.63] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  *

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Flush to global observation point before breadcrumb write (rev2)

2022-09-29 Thread Patchwork

== Series Details ==

Series: drm/i915/gt: Flush to global observation point before breadcrumb write 
(rev2)
URL   : https://patchwork.freedesktop.org/series/109133/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12199 -> Patchwork_109133v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (49 -> 45)
--

  Missing(4): fi-ctg-p8600 fi-icl-u2 fi-bdw-samus fi-hsw-4200u 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@slpc:
- {bat-adln-1}:   [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12199/bat-adln-1/igt@i915_selftest@l...@slpc.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109133v2/bat-adln-1/igt@i915_selftest@l...@slpc.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_suspend@basic-s3-without-i915:
- fi-bdw-5557u:   [PASS][3] -> [INCOMPLETE][4] ([i915#146] / 
[i915#6712])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12199/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109133v2/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-snb-2600:NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109133v2/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-adlm-1}:   [DMESG-WARN][6] ([i915#2867]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12199/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109133v2/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][8] -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12199/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109133v2/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * 
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka:   [FAIL][10] ([i915#6298]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12199/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109133v2/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6712]: https://gitlab.freedesktop.org/drm/intel/issues/6712


Build changes
-

  * Linux: CI_DRM_12199 -> Patchwork_109133v2

  CI-20190529: 20190529
  CI_DRM_12199: 6fa6bc62d3b91e5a70b8e4869436a0b03083abf5 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6669: 3d2df081c14c251e0269e3510ddc4e9d26ffe925 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_109133v2: 6fa6bc62d3b91e5a70b8e4869436a0b03083abf5 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/mtl: Add C10 support

2022-09-29 Thread Patchwork

== Series Details ==

Series: drm/i915/mtl: Add C10 support
URL   : https://patchwork.freedesktop.org/series/109241/
State : failure

== Summary ==

Error: make failed
  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND objtool
  CHK include/generated/compile.h
make[4]: *** No rule to make target 'drivers/gpu/drm/i915/intel_pm.o', needed 
by 'drivers/gpu/drm/i915/i915.o'.  Stop.
scripts/Makefile.build:465: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:465: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:465: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1852: recipe for target 'drivers' failed
make: *** [drivers] Error 2

Re: [Intel-gfx] [PATCH v4 15/15] vfio: Add struct device to vfio_device

2022-09-29 Thread Alex Williamson

Hi Kevin,

This introduced the regression discovered here:

https://lore.kernel.org/all/20220928125650.0a2ea297.alex.william...@redhat.com/

Seems we're not releasing the resources when removing an mdev.  This is
a regression, so it needs to be fixed or reverted before the merge
window.  Thanks,

Alex

On Wed, 21 Sep 2022 18:44:01 +0800
Kevin Tian  wrote:

> From: Yi Liu 
> 
> and replace kref. With it a 'vfio-dev/vfioX' node is created under the
> sysfs path of the parent, indicating the device is bound to a vfio
> driver, e.g.:
> 
> /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0
> 
> It is also a preparatory step toward adding cdev for supporting future
> device-oriented uAPI.
> 
> Add Documentation/ABI/testing/sysfs-devices-vfio-dev.
> 
> Suggested-by: Jason Gunthorpe 
> Signed-off-by: Yi Liu 
> Signed-off-by: Kevin Tian 
> Reviewed-by: Jason Gunthorpe 
> ---
>  .../ABI/testing/sysfs-devices-vfio-dev|  8 +++
>  MAINTAINERS   |  1 +
>  drivers/vfio/vfio_main.c  | 64 +++
>  include/linux/vfio.h  |  6 +-
>  4 files changed, 65 insertions(+), 14 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-devices-vfio-dev
> 
> diff --git a/Documentation/ABI/testing/sysfs-devices-vfio-dev 
> b/Documentation/ABI/testing/sysfs-devices-vfio-dev
> new file mode 100644
> index ..e21424fd9666
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-devices-vfio-dev
> @@ -0,0 +1,8 @@
> +What: /sys/...//vfio-dev/vfioX/
> +Date: September 2022
> +Contact:  Yi Liu 
> +Description:
> +  This directory is created when the device is bound to a
> +  vfio driver. The layout under this directory matches what
> +  exists for a standard 'struct device'. 'X' is a unique
> +  index marking this device in vfio.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d30f26e07cd3..02c8f11b1c17 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -21312,6 +21312,7 @@ R:Cornelia Huck 
>  L:   k...@vger.kernel.org
>  S:   Maintained
>  T:   git git://github.com/awilliam/linux-vfio.git
> +F:   Documentation/ABI/testing/sysfs-devices-vfio-dev
>  F:   Documentation/driver-api/vfio.rst
>  F:   drivers/vfio/
>  F:   include/linux/vfio.h
> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> index c27449613a1d..f9d10dbcf3e6 100644
> --- a/drivers/vfio/vfio_main.c
> +++ b/drivers/vfio/vfio_main.c
> @@ -49,6 +49,8 @@ static struct vfio {
>   struct mutexgroup_lock; /* locks group_list */
>   struct ida  group_ida;
>   dev_t   group_devt;
> + struct class*device_class;
> + struct ida  device_ida;
>  } vfio;
>  
>  struct vfio_iommu_driver {
> @@ -485,12 +487,13 @@ static struct vfio_device *vfio_group_get_device(struct 
> vfio_group *group,
>   * VFIO driver API
>   */
>  /* Release helper called by vfio_put_device() */
> -void vfio_device_release(struct kref *kref)
> +static void vfio_device_release(struct device *dev)
>  {
>   struct vfio_device *device =
> - container_of(kref, struct vfio_device, kref);
> + container_of(dev, struct vfio_device, device);
>  
>   vfio_release_device_set(device);
> + ida_free(_ida, device->index);
>  
>   /*
>* kvfree() cannot be done here due to a life cycle mess in
> @@ -500,7 +503,6 @@ void vfio_device_release(struct kref *kref)
>*/
>   device->ops->release(device);
>  }
> -EXPORT_SYMBOL_GPL(vfio_device_release);
>  
>  /*
>   * Allocate and initialize vfio_device so it can be registered to vfio
> @@ -548,6 +550,13 @@ int vfio_init_device(struct vfio_device *device, struct 
> device *dev,
>  {
>   int ret;
>  
> + ret = ida_alloc_max(_ida, MINORMASK, GFP_KERNEL);
> + if (ret < 0) {
> + dev_dbg(dev, "Error to alloc index\n");
> + return ret;
> + }
> +
> + device->index = ret;
>   init_completion(>comp);
>   device->dev = dev;
>   device->ops = ops;
> @@ -558,11 +567,15 @@ int vfio_init_device(struct vfio_device *device, struct 
> device *dev,
>   goto out_uninit;
>   }
>  
> - kref_init(>kref);
> + device_initialize(>device);
> + device->device.release = vfio_device_release;
> + device->device.class = vfio.device_class;
> + device->device.parent = device->dev;
>   return 0;
>  
>  out_uninit:
>   vfio_release_device_set(device);
> + ida_free(_ida, device->index);
>   return ret;
>  }
>  EXPORT_SYMBOL_GPL(vfio_init_device);
> @@ -659,6 +672,7 @@ static int __vfio_register_dev(struct vfio_device *device,
>   struct vfio_group *group)
>  {
>   struct vfio_device *existing_device;
> + int ret;
>  
>   if (IS_ERR(group))
>   return PTR_ERR(group);
>

Re: [Intel-gfx] [PATCH] drm/i915: Fix CFI violations in gt_sysfs

2022-09-29 Thread Nathan Chancellor

On Thu, Sep 29, 2022 at 06:46:34PM +0200, Andi Shyti wrote:
> Hi Nathan,
> 
> thanks for this refactoring... looks good even though i would
> have split it in more patches as this is doing quite many things.

Right, sorry about that :/ I initially thought the problem was much
simpler and the diff was more reasonable before I truly saw what was
happening and by that point, trying to break things apart felt like
navigating a mine field. I will definitely keep that in mind for the
future though.

> But I will not be stubborn, I understand that it's not trivial to
> have things split. I will give my r-b for now but I will check it
> again before applying it as it's very easy to get tangled-up in
> between all those defines:
> 
> Reviewed-by: Andi Shyti 

Appreciate it! I don't have access to some of the hardware that is
special cased in this code so I definitely would not mind some
additional eyes and testing for this change.

> For now I'm quite surprised to see how easily our CI gives green
> lights :-P
> 
> On Sat, Sep 24, 2022 at 09:39:30PM -0700, Nathan Chancellor wrote:
> > On Fri, Sep 23, 2022 at 09:57:47PM -0700, Kees Cook wrote:
> > > On Thu, Sep 22, 2022 at 12:51:27PM -0700, Nathan Chancellor wrote:
> > > > [...]
> > > > To make everything work properly, adjust certain functions to match the
> > > > type of the ->show() and ->store() members in 'struct kobj_attribute'.
> > > > Add a macro to generate functions for that can be called via both
> > > > dev_attr_{show,store}() or kobj_attr_{show,store}() so that they can be
> > > > called through both kobject locations without violating kCFI and adjust
> > > > the attribute groups to account for this.
> > > 
> > > This was quite a roller coaster! I think the solution looks good, even
> > > if I'm suspicious of the original design that has the same stuff
> > > available twice in different places. (I have a dim memory of rdma
> > > needing a refactoring like this too?)
> > 
> > Right, I noticed this comment in intel_gt_sysfs_register() once I fully
> > saw what was going on:
> > 
> > /*
> >  * We need to make things right with the
> >  * ABI compatibility. The files were originally
> >  * generated under the parent directory.
> >  *
> >  * We generate the files only for gt 0
> >  * to avoid duplicates.
> >  */
> > 
> > Makes it seem like there will be userspace breakage if these files do
> > not exist? I figured this was the cleanest solution within those
> > parameters.
> 
> i915 went multi-gt (multitile) so that some interfaces, like the
> power management files, have effect only on one of the tiles.
> This means that we needed to move some of the files inside the
> newly created gt0/gt1 directory.
> 
> But, because some of those files are part of an ABI
> specification, we can't simply transfer them from the original
> position so that we needed to make a "hard" copy (actually the
> original files now take the role of affecting all the GTs instead
> of only one).
> 
> The complexity of this file comes from the necessity of
> minimizing code duplication, otherwise we could have had two
> perfectly identical files (which looking at the final result it
> wouldn't have been a completely bad idea after all).
> 
> Thanks again, will let you know when I will get this into our
> branch.

Ah, that all makes sense, good to know that this solution will allow all
of that to continue to work.

If there are any issues or further comments, I am happy to follow up in
whatever way I need to. Thanks again for the review and tentative
acceptance!

Cheers,
Nathan

Re: [Intel-gfx] [PATCH] drm/i915/guc: do not capture error state on exiting context

2022-09-29 Thread John Harrison


On 9/29/2022 01:22, Tvrtko Ursulin wrote:

On 28/09/2022 19:27, John Harrison wrote:

On 9/28/2022 00:19, Tvrtko Ursulin wrote:

On 27/09/2022 22:36, Ceraolo Spurio, Daniele wrote:

On 9/27/2022 12:45 AM, Tvrtko Ursulin wrote:

On 27/09/2022 07:49, Andrzej Hajda wrote:

On 27.09.2022 01:34, Ceraolo Spurio, Daniele wrote:

On 9/26/2022 3:44 PM, Andi Shyti wrote:

Hi Andrzej,

On Mon, Sep 26, 2022 at 11:54:09PM +0200, Andrzej Hajda wrote:
Capturing error state is time consuming (up to 350ms on DG2), 
so it should
be avoided if possible. Context reset triggered by context 
removal is a

good example.
With this patch multiple igt tests will not timeout and should 
run faster.


Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1551
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3952
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5891
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6268
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6281
Signed-off-by: Andrzej Hajda 

fine for me:

Reviewed-by: Andi Shyti 

Just to be on the safe side, can we also have the ack from any of
the GuC folks? Daniele, John?

Andi



---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c

index 22ba66e48a9b01..cb58029208afe1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4425,7 +4425,8 @@ static void 
guc_handle_context_reset(struct intel_guc *guc,

  trace_intel_context_reset(ce);
    if (likely(!intel_context_is_banned(ce))) {
-    capture_error_state(guc, ce);
+    if (!intel_context_is_exiting(ce))
+    capture_error_state(guc, ce);


I am not sure here - if we have a persistent context which caused 
a GPU hang I'd expect we'd still want error capture.


What causes the reset in the affected IGTs? Always preemption 
timeout?



guc_context_replay(ce);


You definitely don't want to replay requests of a context that 
is going away.


My intention was to just avoid error capture, but that's even 
better, only condition change:

-        if (likely(!intel_context_is_banned(ce))) {
+       if (likely(intel_context_is_schedulable(ce)))  {


Yes that helper was intended to be used for contexts which should 
not be scheduled post exit or ban.


Daniele - you say there are some misses in the GuC backend. Should 
most, or even all in intel_guc_submission.c be converted to use 
intel_context_is_schedulable? My idea indeed was that "ban" should 
be a level up from the backends. Backend should only distinguish 
between "should I run this or not", and not the reason.


I think that all of them should be updated, but I'd like Matt B to 
confirm as he's more familiar with the code than me.


Right, that sounds plausible to me as well.

One thing I forgot to mention - the only place where backend can 
care between "schedulable" and "banned" is when it picks the preempt 
timeout for non-schedulable contexts. This is to only apply the 
strict 1ms to banned (so bad or naught contexts), while the ones 
which are exiting cleanly get the full preempt timeout as otherwise 
configured. This solves the ugly user experience quirk where GPU 
resets/errors were logged upon exit/Ctrl-C of a well behaving 
application (using non-persistent contexts). Hopefully GuC can match 
that behaviour so customers stay happy.


Regards,

Tvrtko


The whole revoke vs ban thing seems broken to me.

First of all, if the user hits Ctrl+C we need to kill the context off 
immediately. That is a fundamental customer requirement. Render and 
compute engines have a 7.5s pre-emption timeout. The user should not 
have to wait 7.5s for a context to be removed from the system when 
they have explicitly killed it themselves. Even the regular timeout 
of 640ms is borderline a long time to wait. And note that there is an 
ongoing request/requirement to increase that to 1900ms.


Under what circumstances would a user expect anything sensible to 
happen after a Ctrl+C in terms of things finishing their rendering 
and display nice pretty images? They killed the app. They want it 
dead. We should be getting it off the hardware as quickly as 
possible. If you are really concerned about resets causing collateral 
damage then maybe bump the termination timeout from 1ms up to 10ms, 
maybe at most 100ms. If an app is 'well behaved' then it should 
cleanly exit within 10ms. But if it is bad (which is almost certainly 
the case if the user is manually and explicitly killing it) then it 
needs to be killed because it is not going to gracefully exit.


Right.. I had it like that initially (lower timeout - I think 20ms or 
so, patch history on the mailing list would know for sure), but then 
simplified it after review feedback to avoid adding another timeout 
value.


So it's not

Re: [Intel-gfx] [PATCH] drm/i915: Fix CFI violations in gt_sysfs

2022-09-29 Thread Andi Shyti

Hi Nathan,

thanks for this refactoring... looks good even though i would
have split it in more patches as this is doing quite many things.

But I will not be stubborn, I understand that it's not trivial to
have things split. I will give my r-b for now but I will check it
again before applying it as it's very easy to get tangled-up in
between all those defines:

Reviewed-by: Andi Shyti 

For now I'm quite surprised to see how easily our CI gives green
lights :-P

On Sat, Sep 24, 2022 at 09:39:30PM -0700, Nathan Chancellor wrote:
> On Fri, Sep 23, 2022 at 09:57:47PM -0700, Kees Cook wrote:
> > On Thu, Sep 22, 2022 at 12:51:27PM -0700, Nathan Chancellor wrote:
> > > [...]
> > > To make everything work properly, adjust certain functions to match the
> > > type of the ->show() and ->store() members in 'struct kobj_attribute'.
> > > Add a macro to generate functions for that can be called via both
> > > dev_attr_{show,store}() or kobj_attr_{show,store}() so that they can be
> > > called through both kobject locations without violating kCFI and adjust
> > > the attribute groups to account for this.
> > 
> > This was quite a roller coaster! I think the solution looks good, even
> > if I'm suspicious of the original design that has the same stuff
> > available twice in different places. (I have a dim memory of rdma
> > needing a refactoring like this too?)
> 
> Right, I noticed this comment in intel_gt_sysfs_register() once I fully
> saw what was going on:
> 
>   /*
>* We need to make things right with the
>* ABI compatibility. The files were originally
>* generated under the parent directory.
>*
>* We generate the files only for gt 0
>* to avoid duplicates.
>*/
> 
> Makes it seem like there will be userspace breakage if these files do
> not exist? I figured this was the cleanest solution within those
> parameters.

i915 went multi-gt (multitile) so that some interfaces, like the
power management files, have effect only on one of the tiles.
This means that we needed to move some of the files inside the
newly created gt0/gt1 directory.

But, because some of those files are part of an ABI
specification, we can't simply transfer them from the original
position so that we needed to make a "hard" copy (actually the
original files now take the role of affecting all the GTs instead
of only one).

The complexity of this file comes from the necessity of
minimizing code duplication, otherwise we could have had two
perfectly identical files (which looking at the final result it
wouldn't have been a completely bad idea after all).

Thanks again, will let you know when I will get this into our
branch.

Andi

> > Reviewed-by: Kees Cook 
> 
> Thanks for looking it over!
> 
> Cheers,
> Nathan

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: Flush to global observation point before breadcrumb write (rev2)

2022-09-29 Thread Patchwork

== Series Details ==

Series: drm/i915/gt: Flush to global observation point before breadcrumb write 
(rev2)
URL   : https://patchwork.freedesktop.org/series/109133/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2

Re: [Intel-gfx] [PATCH 05/16] drm/i915/vm_bind: Implement bind and unbind of object

2022-09-29 Thread Niranjana Vishwanathapura


On Thu, Sep 29, 2022 at 11:49:30AM +0100, Matthew Auld wrote:

On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:

Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.

The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be supported only in the newer execbuf3 ioctl.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Prathap Kumar Valsan 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|   5 +
 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |  26 ++
 .../drm/i915/gem/i915_gem_vm_bind_object.c| 306 ++
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  10 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  17 +
 drivers/gpu/drm/i915/i915_driver.c|   3 +
 drivers/gpu/drm/i915/i915_vma.c   |   1 +
 drivers/gpu/drm/i915/i915_vma_types.h |  14 +
 include/uapi/drm/i915_drm.h   | 112 +++
 10 files changed, 495 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a26edcdadc21..9bf939ef18ea 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -166,6 +166,7 @@ gem-y += \
gem/i915_gem_ttm_move.o \
gem/i915_gem_ttm_pm.o \
gem/i915_gem_userptr.o \
+   gem/i915_gem_vm_bind_object.o \
gem/i915_gem_wait.o \
gem/i915_gemfs.o
 i915-y += \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index cd75b0ca2555..f85f10cf9c34 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -781,6 +781,11 @@ static int eb_select_context(struct i915_execbuffer *eb)
if (unlikely(IS_ERR(ctx)))
return PTR_ERR(ctx);
+   if (ctx->vm->vm_bind_mode) {
+   i915_gem_context_put(ctx);
+   return -EOPNOTSUPP;
+   }
+
eb->gem_context = ctx;
if (i915_gem_context_has_full_ppgtt(ctx))
eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
new file mode 100644
index ..36262a6357b5
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __I915_GEM_VM_BIND_H
+#define __I915_GEM_VM_BIND_H
+
+#include 
+
+struct drm_device;
+struct drm_file;
+struct i915_address_space;
+struct i915_vma;
+
+struct i915_vma *
+i915_gem_vm_bind_lookup_vma(struct i915_address_space *vm, u64 va);
+
+int i915_gem_vm_bind_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file);
+int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file);
+
+void i915_gem_vm_unbind_all(struct i915_address_space *vm);
+
+#endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
new file mode 100644
index ..e529162abd2c
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+
+#include 
+
+#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_vm_bind.h"
+
+#include "gt/intel_gpu_commands.h"
+
+#define START(node) ((node)->start)
+#define LAST(node) ((node)->last)
+
+INTERVAL_TREE_DEFINE(struct i915_vma, rb, u64, __subtree_last,
+START, LAST, static inline, i915_vm_bind_it)
+
+#undef START
+#undef LAST
+
+/**
+ * DOC: VM_BIND/UNBIND ioctls
+ *
+ * DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer
+ * objects (BOs) or sections of a BOs at specified GPU virtual addresses on a
+ * specified address space (VM). Multiple mappings can map to the same physical
+ * pages of an object (aliasing). These mappings (also referred to as 
persistent
+ * mappings) will be persistent across multiple GPU submissions (execbuf calls)
+ * issued by the UMD, without user having to provide a list of all required
+ * mappings during each submission (as required by older execbuf mode).
+ *
+ * The VM_BIND/UNBIND calls allow UMDs to request a timeline out fence for
+ * signaling the completion of bind/unbind operation.
+ *
+ * VM_BIND feature is advertised to user via I915_PARAM_VM_BIND_VERSION.
+ * User has to opt-in for VM_BIND mode of binding for an address space (VM)
+ * during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension.
+ *
+ * VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently
+ * are not ordered. Furthermore,

[Intel-gfx] [PATCH v4 17/30] drm/modes: Fill drm_cmdline mode from named modes

2022-09-29 Thread Maxime Ripard

The current code to deal with named modes will only set the mode name, and
then it's up to drivers to try to match that name to whatever mode or
configuration they see fit.

The plan is to remove that need and move the named mode handling out of
drivers and into the core, and only rely on modes and properties. Let's
start by properly filling drm_cmdline_mode from a named mode.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_modes.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 7ed3fb839db7..99453aca9a83 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2226,11 +2226,22 @@ static int drm_mode_parse_cmdline_options(const char 
*str,
 
 struct drm_named_mode {
const char *name;
+   unsigned int xres;
+   unsigned int yres;
+   unsigned int flags;
 };
 
+#define NAMED_MODE(_name, _x, _y, _flags)  \
+   {   \
+   .name = _name,  \
+   .xres = _x, \
+   .yres = _y, \
+   .flags = _flags,\
+   }
+
 static const struct drm_named_mode drm_named_modes[] = {
-   { "NTSC", },
-   { "PAL", },
+   NAMED_MODE("NTSC", 720, 480, DRM_MODE_FLAG_INTERLACE),
+   NAMED_MODE("PAL", 720, 576, DRM_MODE_FLAG_INTERLACE),
 };
 
 static int drm_mode_parse_cmdline_named_mode(const char *name,
@@ -2275,6 +2286,9 @@ static int drm_mode_parse_cmdline_named_mode(const char 
*name,
continue;
 
strcpy(cmdline_mode->name, mode->name);
+   cmdline_mode->xres = mode->xres;
+   cmdline_mode->yres = mode->yres;
+   cmdline_mode->interlace = !!(mode->flags & 
DRM_MODE_FLAG_INTERLACE);
cmdline_mode->specified = true;
 
return 1;

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 24/30] drm/atomic-helper: Add an analog TV atomic_check implementation

2022-09-29 Thread Maxime Ripard

The analog TV connector drivers share some atomic_check logic, and the new
TV standard property have created some boilerplate that can be be shared
across drivers too.

Let's create an atomic_check helper for those use cases.

Reviewed-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_atomic_state_helper.c | 49 +++
 include/drm/drm_atomic_state_helper.h |  3 ++
 2 files changed, 52 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 0373c3dc824b..e88c57a4f7be 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -556,6 +556,55 @@ void drm_atomic_helper_connector_tv_reset(struct 
drm_connector *connector)
 }
 EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
 
+/**
+ * @drm_atomic_helper_connector_tv_check: Validate an analog TV connector state
+ * @connector: DRM Connector
+ * @state: the DRM State object
+ *
+ * Checks the state object to see if the requested state is valid for an
+ * analog TV connector.
+ *
+ * Returns:
+ * Zero for success, a negative error code on error.
+ */
+int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
+struct drm_atomic_state *state)
+{
+   struct drm_connector_state *old_conn_state =
+   drm_atomic_get_old_connector_state(state, connector);
+   struct drm_connector_state *new_conn_state =
+   drm_atomic_get_new_connector_state(state, connector);
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc *crtc;
+
+   crtc = new_conn_state->crtc;
+   if (!crtc)
+   return 0;
+
+   crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+   if (!crtc_state)
+   return -EINVAL;
+
+   if (old_conn_state->tv.mode != new_conn_state->tv.mode)
+   crtc_state->mode_changed = true;
+
+   if ((old_conn_state->tv.margins.left != 
new_conn_state->tv.margins.left) ||
+   (old_conn_state->tv.margins.right != 
new_conn_state->tv.margins.right) ||
+   (old_conn_state->tv.margins.top != new_conn_state->tv.margins.top) 
||
+   (old_conn_state->tv.margins.bottom != 
new_conn_state->tv.margins.bottom) ||
+   (old_conn_state->tv.mode != new_conn_state->tv.mode) ||
+   (old_conn_state->tv.brightness != new_conn_state->tv.brightness) ||
+   (old_conn_state->tv.contrast != new_conn_state->tv.contrast) ||
+   (old_conn_state->tv.flicker_reduction != 
new_conn_state->tv.flicker_reduction) ||
+   (old_conn_state->tv.overscan != new_conn_state->tv.overscan) ||
+   (old_conn_state->tv.saturation != new_conn_state->tv.saturation) ||
+   (old_conn_state->tv.hue != new_conn_state->tv.hue))
+   crtc_state->connectors_changed = true;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_atomic_helper_connector_tv_check);
+
 /**
  * __drm_atomic_helper_connector_duplicate_state - copy atomic connector state
  * @connector: connector object
diff --git a/include/drm/drm_atomic_state_helper.h 
b/include/drm/drm_atomic_state_helper.h
index c8fbce795ee7..b9740edb2658 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -26,6 +26,7 @@
 
 #include 
 
+struct drm_atomic_state;
 struct drm_bridge;
 struct drm_bridge_state;
 struct drm_crtc;
@@ -71,6 +72,8 @@ void __drm_atomic_helper_connector_reset(struct drm_connector 
*connector,
 struct drm_connector_state 
*conn_state);
 void drm_atomic_helper_connector_reset(struct drm_connector *connector);
 void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
+int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
+struct drm_atomic_state *state);
 void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector 
*connector);
 void
 __drm_atomic_helper_connector_duplicate_state(struct drm_connector *connector,

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 27/30] drm/vc4: vec: Check for VEC output constraints

2022-09-29 Thread Maxime Ripard

From: Mateusz Kwiatkowski 

The VEC can accept pretty much any relatively reasonable mode, but still
has a bunch of constraints to meet.

Let's create an atomic_check() implementation that will make sure we
don't end up accepting a non-functional mode.

Acked-by: Noralf Trønnes 
Signed-off-by: Mateusz Kwiatkowski 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_vec.c | 48 +++
 1 file changed, 48 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index 90e375a8a8f9..1fcb7baf874e 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -453,6 +453,7 @@ static int vc4_vec_encoder_atomic_check(struct drm_encoder 
*encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
 {
+   const struct drm_display_mode *mode = _state->adjusted_mode;
const struct vc4_vec_tv_mode *vec_mode;
 
vec_mode = _vec_tv_modes[conn_state->tv.legacy_mode];
@@ -461,6 +462,53 @@ static int vc4_vec_encoder_atomic_check(struct drm_encoder 
*encoder,
!drm_mode_equal(vec_mode->mode, _state->adjusted_mode))
return -EINVAL;
 
+   if (mode->crtc_hdisplay % 4)
+   return -EINVAL;
+
+   if (!(mode->crtc_hsync_end - mode->crtc_hsync_start))
+   return -EINVAL;
+
+   switch (mode->vtotal) {
+   case 525:
+   if (mode->crtc_vtotal > 262)
+   return -EINVAL;
+
+   if (mode->crtc_vdisplay < 1 || mode->crtc_vdisplay > 253)
+   return -EINVAL;
+
+   if (!(mode->crtc_vsync_start - mode->crtc_vdisplay))
+   return -EINVAL;
+
+   if ((mode->crtc_vsync_end - mode->crtc_vsync_start) != 3)
+   return -EINVAL;
+
+   if ((mode->crtc_vtotal - mode->crtc_vsync_end) < 4)
+   return -EINVAL;
+
+   break;
+
+   case 625:
+   if (mode->crtc_vtotal > 312)
+   return -EINVAL;
+
+   if (mode->crtc_vdisplay < 1 || mode->crtc_vdisplay > 305)
+   return -EINVAL;
+
+   if (!(mode->crtc_vsync_start - mode->crtc_vdisplay))
+   return -EINVAL;
+
+   if ((mode->crtc_vsync_end - mode->crtc_vsync_start) != 3)
+   return -EINVAL;
+
+   if ((mode->crtc_vtotal - mode->crtc_vsync_end) < 2)
+   return -EINVAL;
+
+   break;
+
+   default:
+   return -EINVAL;
+   }
+
return 0;
 }
 

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 30/30] drm/sun4i: tv: Convert to the new TV mode property

2022-09-29 Thread Maxime Ripard

Now that the core can deal fine with analog TV modes, let's convert the
sun4i TV driver to leverage those new features.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_tv.c | 148 ++-
 drivers/gpu/drm/vc4/vc4_vec.c|   5 +-
 2 files changed, 54 insertions(+), 99 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index c65f0a89b6b0..1a8f5b986a95 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -141,23 +141,14 @@ struct resync_parameters {
 struct tv_mode {
char*name;
 
+   unsigned inttv_mode;
+
u32 mode;
u32 chroma_freq;
u16 back_porch;
u16 front_porch;
-   u16 line_number;
u16 vblank_level;
 
-   u32 hdisplay;
-   u16 hfront_porch;
-   u16 hsync_len;
-   u16 hback_porch;
-
-   u32 vdisplay;
-   u16 vfront_porch;
-   u16 vsync_len;
-   u16 vback_porch;
-
boolyc_en;
booldac3_en;
booldac_bit25_en;
@@ -213,7 +204,7 @@ static const struct resync_parameters pal_resync_parameters 
= {
 
 static const struct tv_mode tv_modes[] = {
{
-   .name   = "NTSC",
+   .tv_mode= DRM_MODE_TV_MODE_NTSC,
.mode   = SUN4I_TVE_CFG0_RES_480i,
.chroma_freq= 0x21f07c1f,
.yc_en  = true,
@@ -222,17 +213,6 @@ static const struct tv_mode tv_modes[] = {
 
.back_porch = 118,
.front_porch= 32,
-   .line_number= 525,
-
-   .hdisplay   = 720,
-   .hfront_porch   = 18,
-   .hsync_len  = 2,
-   .hback_porch= 118,
-
-   .vdisplay   = 480,
-   .vfront_porch   = 26,
-   .vsync_len  = 2,
-   .vback_porch= 17,
 
.vblank_level   = 240,
 
@@ -242,23 +222,12 @@ static const struct tv_mode tv_modes[] = {
.resync_params  = _resync_parameters,
},
{
-   .name   = "PAL",
+   .tv_mode= DRM_MODE_TV_MODE_PAL,
.mode   = SUN4I_TVE_CFG0_RES_576i,
.chroma_freq= 0x2a098acb,
 
.back_porch = 138,
.front_porch= 24,
-   .line_number= 625,
-
-   .hdisplay   = 720,
-   .hfront_porch   = 3,
-   .hsync_len  = 2,
-   .hback_porch= 139,
-
-   .vdisplay   = 576,
-   .vfront_porch   = 28,
-   .vsync_len  = 2,
-   .vback_porch= 19,
 
.vblank_level   = 252,
 
@@ -276,63 +245,21 @@ drm_encoder_to_sun4i_tv(struct drm_encoder *encoder)
encoder);
 }
 
-/*
- * FIXME: If only the drm_display_mode private field was usable, this
- * could go away...
- *
- * So far, it doesn't seem to be preserved when the mode is passed by
- * to mode_set for some reason.
- */
-static const struct tv_mode *sun4i_tv_find_tv_by_mode(const struct 
drm_display_mode *mode)
+static const struct tv_mode *
+sun4i_tv_find_tv_by_mode(unsigned int mode)
 {
int i;
 
-   /* First try to identify the mode by name */
for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
const struct tv_mode *tv_mode = _modes[i];
 
-   DRM_DEBUG_DRIVER("Comparing mode %s vs %s",
-mode->name, tv_mode->name);
-
-   if (!strcmp(mode->name, tv_mode->name))
-   return tv_mode;
-   }
-
-   /* Then by number of lines */
-   for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
-   const struct tv_mode *tv_mode = _modes[i];
-
-   DRM_DEBUG_DRIVER("Comparing mode %s vs %s (X: %d vs %d)",
-mode->name, tv_mode->name,
-mode->vdisplay, tv_mode->vdisplay);
-
-   if (mode->vdisplay == tv_mode->vdisplay)
+   if (tv_mode->tv_mode == mode)
return tv_mode;
}
 
return NULL;
 }
 
-static void sun4i_tv_mode_to_drm_mode(const struct tv_mode *tv_mode,
- struct drm_display_mode *mode)
-{
-   DRM_DEBUG_DRIVER("Creating mode %s\n", mode->name);
-
-   mode->type = DRM_MODE_TYPE_DRIVER;
-   mode->clock = 13500;
-   mode->flags = DRM_MODE_FLAG_INTERLACE;
-
-   mode->hdisplay = tv_mode->hdisplay;
-   mode->hsync_start = mode->hdisplay + tv_mode->hfront_porch;
-   mode->hsync_end = mode->hsync_start + tv_mode->hsync_len;
-   mode->htotal =

[Intel-gfx] [PATCH v4 22/30] drm/modes: Introduce more named modes

2022-09-29 Thread Maxime Ripard

Now that we can easily extend the named modes list, let's add a few more
analog TV modes that were used in the wild, and some unit tests to make
sure it works as intended.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_modes.c |  2 +
 drivers/gpu/drm/tests/drm_client_modeset_test.c | 54 +
 2 files changed, 56 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index fe818252cd8f..e3307662d6da 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2271,7 +2271,9 @@ struct drm_named_mode {
 
 static const struct drm_named_mode drm_named_modes[] = {
NAMED_MODE("NTSC", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE, 
DRM_MODE_TV_MODE_NTSC),
+   NAMED_MODE("NTSC-J", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE, 
DRM_MODE_TV_MODE_NTSC_J),
NAMED_MODE("PAL", 13500, 720, 576, DRM_MODE_FLAG_INTERLACE, 
DRM_MODE_TV_MODE_PAL),
+   NAMED_MODE("PAL-M", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE, 
DRM_MODE_TV_MODE_PAL_M),
 };
 
 static int drm_mode_parse_cmdline_named_mode(const char *name,
diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c 
b/drivers/gpu/drm/tests/drm_client_modeset_test.c
index b59029b49201..b72433a0216a 100644
--- a/drivers/gpu/drm/tests/drm_client_modeset_test.c
+++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
@@ -134,6 +134,32 @@ static void drm_pick_cmdline_named_ntsc(struct kunit *test)
KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_ntsc_480i(drm), 
mode));
 }
 
+static void drm_pick_cmdline_named_ntsc_j(struct kunit *test)
+{
+   struct drm_client_modeset_test_priv *priv = test->priv;
+   struct drm_device *drm = priv->drm;
+   struct drm_connector *connector = >connector;
+   struct drm_cmdline_mode *cmdline_mode = >cmdline_mode;
+   struct drm_display_mode *mode;
+   const char *cmdline = "NTSC-J";
+   int ret;
+
+   KUNIT_ASSERT_TRUE(test,
+ drm_mode_parse_command_line_for_connector(cmdline,
+   connector,
+   
cmdline_mode));
+
+   mutex_lock(>mode_config.mutex);
+   ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+   mutex_unlock(>mode_config.mutex);
+   KUNIT_ASSERT_GT(test, ret, 0);
+
+   mode = drm_connector_pick_cmdline_mode(connector);
+   KUNIT_ASSERT_PTR_NE(test, mode, NULL);
+
+   KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_ntsc_480i(drm), 
mode));
+}
+
 static void drm_pick_cmdline_named_pal(struct kunit *test)
 {
struct drm_client_modeset_test_priv *priv = test->priv;
@@ -160,10 +186,38 @@ static void drm_pick_cmdline_named_pal(struct kunit *test)
KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_pal_576i(drm), 
mode));
 }
 
+static void drm_pick_cmdline_named_pal_m(struct kunit *test)
+{
+   struct drm_client_modeset_test_priv *priv = test->priv;
+   struct drm_device *drm = priv->drm;
+   struct drm_connector *connector = >connector;
+   struct drm_cmdline_mode *cmdline_mode = >cmdline_mode;
+   struct drm_display_mode *mode;
+   const char *cmdline = "PAL-M";
+   int ret;
+
+   KUNIT_ASSERT_TRUE(test,
+ drm_mode_parse_command_line_for_connector(cmdline,
+   connector,
+   
cmdline_mode));
+
+   mutex_lock(>mode_config.mutex);
+   ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+   mutex_unlock(>mode_config.mutex);
+   KUNIT_ASSERT_GT(test, ret, 0);
+
+   mode = drm_connector_pick_cmdline_mode(connector);
+   KUNIT_ASSERT_PTR_NE(test, mode, NULL);
+
+   KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_ntsc_480i(drm), 
mode));
+}
+
 static struct kunit_case drm_pick_cmdline_tests[] = {
KUNIT_CASE(drm_pick_cmdline_res_1920_1080_60),
KUNIT_CASE(drm_pick_cmdline_named_ntsc),
+   KUNIT_CASE(drm_pick_cmdline_named_ntsc_j),
KUNIT_CASE(drm_pick_cmdline_named_pal),
+   KUNIT_CASE(drm_pick_cmdline_named_pal_m),
{}
 };
 

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 23/30] drm/atomic-helper: Add a TV properties reset helper

2022-09-29 Thread Maxime Ripard

The drm_tv_create_properties() function will create a bunch of properties,
but it's up to each and every driver using that function to properly reset
the state of these properties leading to inconsistent behaviours.

Let's create a helper that will take care of it.

Reviewed-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_atomic_state_helper.c | 75 +++
 include/drm/drm_atomic_state_helper.h |  1 +
 2 files changed, 76 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
b/drivers/gpu/drm/drm_atomic_state_helper.c
index dfb57217253b..0373c3dc824b 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -481,6 +481,81 @@ void drm_atomic_helper_connector_tv_margins_reset(struct 
drm_connector *connecto
 }
 EXPORT_SYMBOL(drm_atomic_helper_connector_tv_margins_reset);
 
+/**
+ * drm_atomic_helper_connector_tv_reset - Resets Analog TV connector properties
+ * @connector: DRM connector
+ *
+ * Resets the analog TV properties attached to a connector
+ */
+void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_cmdline_mode *cmdline = >cmdline_mode;
+   struct drm_connector_state *state = connector->state;
+   struct drm_property *prop;
+   uint64_t val;
+
+   prop = dev->mode_config.tv_mode_property;
+   if (prop)
+   if (!drm_object_property_get_default_value(>base,
+  prop, ))
+   state->tv.mode = val;
+
+   if (cmdline->tv_mode)
+   state->tv.mode = cmdline->tv_mode;
+
+   prop = dev->mode_config.tv_select_subconnector_property;
+   if (prop)
+   if (!drm_object_property_get_default_value(>base,
+  prop, ))
+   state->tv.select_subconnector = val;
+
+   prop = dev->mode_config.tv_subconnector_property;
+   if (prop)
+   if (!drm_object_property_get_default_value(>base,
+  prop, ))
+   state->tv.subconnector = val;
+
+   prop = dev->mode_config.tv_brightness_property;
+   if (prop)
+   if (!drm_object_property_get_default_value(>base,
+  prop, ))
+   state->tv.brightness = val;
+
+   prop = dev->mode_config.tv_contrast_property;
+   if (prop)
+   if (!drm_object_property_get_default_value(>base,
+  prop, ))
+   state->tv.contrast = val;
+
+   prop = dev->mode_config.tv_flicker_reduction_property;
+   if (prop)
+   if (!drm_object_property_get_default_value(>base,
+  prop, ))
+   state->tv.flicker_reduction = val;
+
+   prop = dev->mode_config.tv_overscan_property;
+   if (prop)
+   if (!drm_object_property_get_default_value(>base,
+  prop, ))
+   state->tv.overscan = val;
+
+   prop = dev->mode_config.tv_saturation_property;
+   if (prop)
+   if (!drm_object_property_get_default_value(>base,
+  prop, ))
+   state->tv.saturation = val;
+
+   prop = dev->mode_config.tv_hue_property;
+   if (prop)
+   if (!drm_object_property_get_default_value(>base,
+  prop, ))
+   state->tv.hue = val;
+
+   drm_atomic_helper_connector_tv_margins_reset(connector);
+}
+EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
+
 /**
  * __drm_atomic_helper_connector_duplicate_state - copy atomic connector state
  * @connector: connector object
diff --git a/include/drm/drm_atomic_state_helper.h 
b/include/drm/drm_atomic_state_helper.h
index 192766656b88..c8fbce795ee7 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -70,6 +70,7 @@ void __drm_atomic_helper_connector_state_reset(struct 
drm_connector_state *conn_
 void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
 struct drm_connector_state 
*conn_state);
 void drm_atomic_helper_connector_reset(struct drm_connector *connector);
+void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
 void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector 
*connector);
 void
 __drm_atomic_helper_connector_duplicate_state(struct drm_connector *connector,

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 21/30] drm/modes: Properly generate a drm_display_mode from a named mode

2022-09-29 Thread Maxime Ripard

The framework will get the drm_display_mode from the drm_cmdline_mode it
got by parsing the video command line argument by calling
drm_connector_pick_cmdline_mode().

The heavy lifting will then be done by the drm_mode_create_from_cmdline_mode()
function.

In the case of the named modes though, there's no real code to make that
translation and we rely on the drivers to guess which actual display mode
we meant.

Let's modify drm_mode_create_from_cmdline_mode() to properly generate the
drm_display_mode we mean when passing a named mode.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_modes.c | 34 +++-
 drivers/gpu/drm/tests/drm_client_modeset_test.c | 71 +
 2 files changed, 104 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index c9b62e30e303..fe818252cd8f 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2500,6 +2500,36 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
 }
 EXPORT_SYMBOL(drm_mode_parse_command_line_for_connector);
 
+static struct drm_display_mode *drm_named_mode(struct drm_device *dev,
+  struct drm_cmdline_mode *cmd)
+{
+   struct drm_display_mode *mode;
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(drm_named_modes); i++) {
+   const struct drm_named_mode *named_mode = _named_modes[i];
+
+   if (strcmp(cmd->name, named_mode->name))
+   continue;
+
+   if (!named_mode->tv_mode)
+   continue;
+
+   mode = drm_analog_tv_mode(dev,
+ named_mode->tv_mode,
+ named_mode->pixel_clock_khz * 1000,
+ named_mode->xres,
+ named_mode->yres,
+ named_mode->flags & 
DRM_MODE_FLAG_INTERLACE);
+   if (!mode)
+   return NULL;
+
+   return mode;
+   }
+
+   return NULL;
+}
+
 /**
  * drm_mode_create_from_cmdline_mode - convert a command line modeline into a 
DRM display mode
  * @dev: DRM device to create the new mode for
@@ -2517,7 +2547,9 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
if (cmd->xres == 0 || cmd->yres == 0)
return NULL;
 
-   if (cmd->cvt)
+   if (strlen(cmd->name))
+   mode = drm_named_mode(dev, cmd);
+   else if (cmd->cvt)
mode = drm_cvt_mode(dev,
cmd->xres, cmd->yres,
cmd->refresh_specified ? cmd->refresh : 60,
diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c 
b/drivers/gpu/drm/tests/drm_client_modeset_test.c
index 09dc5acbbc42..b59029b49201 100644
--- a/drivers/gpu/drm/tests/drm_client_modeset_test.c
+++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
@@ -26,6 +26,20 @@ static int drm_client_modeset_connector_get_modes(struct 
drm_connector *connecto
 
count = drm_add_modes_noedid(connector, 1920, 1200);
 
+   mode = drm_mode_analog_ntsc_480i(connector->dev);
+   if (!mode)
+   return -ENOMEM;
+
+   drm_mode_probed_add(connector, mode);
+   count += 1;
+
+   mode = drm_mode_analog_pal_576i(connector->dev);
+   if (!mode)
+   return -ENOMEM;
+
+   drm_mode_probed_add(connector, mode);
+   count += 1;
+
return count;
 }
 
@@ -58,6 +72,9 @@ static int drm_client_modeset_test_init(struct kunit *test)
return ret;
drm_connector_helper_add(>connector, 
_client_modeset_connector_helper_funcs);
 
+   priv->connector.interlace_allowed = true;
+   priv->connector.doublescan_allowed = true;
+
return 0;
 
 }
@@ -91,8 +108,62 @@ static void drm_pick_cmdline_res_1920_1080_60(struct kunit 
*test)
KUNIT_EXPECT_TRUE(test, drm_mode_equal(expected_mode, mode));
 }
 
+static void drm_pick_cmdline_named_ntsc(struct kunit *test)
+{
+   struct drm_client_modeset_test_priv *priv = test->priv;
+   struct drm_device *drm = priv->drm;
+   struct drm_connector *connector = >connector;
+   struct drm_cmdline_mode *cmdline_mode = >cmdline_mode;
+   struct drm_display_mode *mode;
+   const char *cmdline = "NTSC";
+   int ret;
+
+   KUNIT_ASSERT_TRUE(test,
+ drm_mode_parse_command_line_for_connector(cmdline,
+   connector,
+   
cmdline_mode));
+
+   mutex_lock(>mode_config.mutex);
+   ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+   mutex_unlock(>mode_config.mutex);
+   KUNIT_ASSERT_GT(test, ret, 0);
+
+   mode = drm_connector_pick_cmdline_mode(connector);
+

[Intel-gfx] [PATCH v4 20/30] drm/modes: Introduce the tv_mode property as a command-line option

2022-09-29 Thread Maxime Ripard

Our new tv mode option allows to specify the TV mode from a property.
However, it can still be useful, for example to avoid any boot time
artifact, to set that property directly from the kernel command line.

Let's add some code to allow it, and some unit tests to exercise that code.

Signed-off-by: Maxime Ripard 

---
Changes in v4:
- Add Documentation of the command-line option to modedb.rst
---
 Documentation/fb/modedb.rst |  2 +
 drivers/gpu/drm/drm_modes.c | 35 +++--
 drivers/gpu/drm/tests/drm_cmdline_parser_test.c | 67 +
 include/drm/drm_connector.h |  5 ++
 4 files changed, 106 insertions(+), 3 deletions(-)

diff --git a/Documentation/fb/modedb.rst b/Documentation/fb/modedb.rst
index 4d2411e32ebb..5d6361a77f3c 100644
--- a/Documentation/fb/modedb.rst
+++ b/Documentation/fb/modedb.rst
@@ -65,6 +65,8 @@ Valid options are::
   - reflect_y (boolean): Perform an axial symmetry on the Y axis
   - rotate (integer): Rotate the initial framebuffer by x
 degrees. Valid values are 0, 90, 180 and 270.
+  - tv_mode: Analog TV mode. One of "NTSC", "NTSC-443", "NTSC-J", "PAL",
+"PAL-M", "PAL-N", or "SECAM".
   - panel_orientation, one of "normal", "upside_down", "left_side_up", or
 "right_side_up". For KMS drivers only, this sets the "panel orientation"
 property on the kms connector as hint for kms users.
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 068c78d54db2..c9b62e30e303 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2133,6 +2133,29 @@ static int drm_mode_parse_panel_orientation(const char 
*delim,
return 0;
 }
 
+static int drm_mode_parse_tv_mode(const char *delim,
+ struct drm_cmdline_mode *mode)
+{
+   const char *value;
+   int ret;
+
+   if (*delim != '=')
+   return -EINVAL;
+
+   value = delim + 1;
+   delim = strchr(value, ',');
+   if (!delim)
+   delim = value + strlen(value);
+
+   ret = drm_get_tv_mode_from_name(value, delim - value);
+   if (ret < 0)
+   return ret;
+
+   mode->tv_mode = ret;
+
+   return 0;
+}
+
 static int drm_mode_parse_cmdline_options(const char *str,
  bool freestanding,
  const struct drm_connector *connector,
@@ -2202,6 +2225,9 @@ static int drm_mode_parse_cmdline_options(const char *str,
} else if (!strncmp(option, "panel_orientation", delim - 
option)) {
if (drm_mode_parse_panel_orientation(delim, mode))
return -EINVAL;
+   } else if (!strncmp(option, "tv_mode", delim - option)) {
+   if (drm_mode_parse_tv_mode(delim, mode))
+   return -EINVAL;
} else {
return -EINVAL;
}
@@ -2230,20 +2256,22 @@ struct drm_named_mode {
unsigned int xres;
unsigned int yres;
unsigned int flags;
+   unsigned int tv_mode;
 };
 
-#define NAMED_MODE(_name, _pclk, _x, _y, _flags)   \
+#define NAMED_MODE(_name, _pclk, _x, _y, _flags, _mode)\
{   \
.name = _name,  \
.pixel_clock_khz = _pclk,   \
.xres = _x, \
.yres = _y, \
.flags = _flags,\
+   .tv_mode = _mode,   \
}
 
 static const struct drm_named_mode drm_named_modes[] = {
-   NAMED_MODE("NTSC", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE),
-   NAMED_MODE("PAL", 13500, 720, 576, DRM_MODE_FLAG_INTERLACE),
+   NAMED_MODE("NTSC", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE, 
DRM_MODE_TV_MODE_NTSC),
+   NAMED_MODE("PAL", 13500, 720, 576, DRM_MODE_FLAG_INTERLACE, 
DRM_MODE_TV_MODE_PAL),
 };
 
 static int drm_mode_parse_cmdline_named_mode(const char *name,
@@ -2292,6 +2320,7 @@ static int drm_mode_parse_cmdline_named_mode(const char 
*name,
cmdline_mode->xres = mode->xres;
cmdline_mode->yres = mode->yres;
cmdline_mode->interlace = !!(mode->flags & 
DRM_MODE_FLAG_INTERLACE);
+   cmdline_mode->tv_mode = mode->tv_mode;
cmdline_mode->specified = true;
 
return 1;
diff --git a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c 
b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
index 34790e7a3760..3e711b83b823 100644
--- a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
+++ b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
@@ -927,6 +927,14 @@ static const struct drm_cmdline_invalid_test 
drm_cmdline_invalid_tests[] = {
.name = "invalid_option",
.cmdline =

[Intel-gfx] [PATCH v4 29/30] drm/vc4: vec: Add support for more analog TV standards

2022-09-29 Thread Maxime Ripard

From: Mateusz Kwiatkowski 

Add support for the following composite output modes (all of them are
somewhat more obscure than the previously defined ones):

- NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
  4.43361875 MHz (the PAL subcarrier frequency). Never used for
  broadcasting, but sometimes used as a hack to play NTSC content in PAL
  regions (e.g. on VCRs).
- PAL_N - PAL with alternative chroma subcarrier frequency,
  3.58205625 MHz. Used as a broadcast standard in Argentina, Paraguay
  and Uruguay to fit 576i50 with colour in 6 MHz channel raster.
- PAL60 - 480i60 signal with PAL-style color at normal European PAL
  frequency. Another non-standard, non-broadcast mode, used in similar
  contexts as NTSC_443. Some displays support one but not the other.
- SECAM - French frequency-modulated analog color standard; also have
  been broadcast in Eastern Europe and various parts of Africa and Asia.
  Uses the same 576i50 timings as PAL.

Also added some comments explaining color subcarrier frequency
registers.

Acked-by: Noralf Trønnes 
Signed-off-by: Mateusz Kwiatkowski 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_vec.c | 84 ++-
 1 file changed, 83 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index b342dc9cf69c..8d37d7ba9b2a 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -46,6 +46,7 @@
 #define VEC_CONFIG0_YDEL(x)((x) << 26)
 #define VEC_CONFIG0_CDEL_MASK  GENMASK(25, 24)
 #define VEC_CONFIG0_CDEL(x)((x) << 24)
+#define VEC_CONFIG0_SECAM_STD  BIT(21)
 #define VEC_CONFIG0_PBPR_FIL   BIT(18)
 #define VEC_CONFIG0_CHROMA_GAIN_MASK   GENMASK(17, 16)
 #define VEC_CONFIG0_CHROMA_GAIN_UNITY  (0 << 16)
@@ -76,6 +77,27 @@
 #define VEC_SOFT_RESET 0x10c
 #define VEC_CLMP0_START0x144
 #define VEC_CLMP0_END  0x148
+
+/*
+ * These set the color subcarrier frequency
+ * if VEC_CONFIG1_CUSTOM_FREQ is enabled.
+ *
+ * VEC_FREQ1_0 contains the most significant 16-bit half-word,
+ * VEC_FREQ3_2 contains the least significant 16-bit half-word.
+ * 0x8000 seems to be equivalent to the pixel clock
+ * (which itself is the VEC clock divided by 8).
+ *
+ * Reference values (with the default pixel clock of 13.5 MHz):
+ *
+ * NTSC  (3579545.[45] Hz) - 0x21F07C1F
+ * PAL   (4433618.75 Hz)   - 0x2A098ACB
+ * PAL-M (3575611.[888111] Hz) - 0x21E6EFE3
+ * PAL-N (3582056.25 Hz)   - 0x21F69446
+ *
+ * NOTE: For SECAM, it is used as the Dr center frequency,
+ * regardless of whether VEC_CONFIG1_CUSTOM_FREQ is enabled or not;
+ * that is specified as 4406250 Hz, which corresponds to 0x29C71C72.
+ */
 #define VEC_FREQ3_20x180
 #define VEC_FREQ1_00x184
 
@@ -118,6 +140,14 @@
 
 #define VEC_INTERRUPT_CONTROL  0x190
 #define VEC_INTERRUPT_STATUS   0x194
+
+/*
+ * Db center frequency for SECAM; the clock for this is the same as for
+ * VEC_FREQ3_2/VEC_FREQ1_0, which is used for Dr center frequency.
+ *
+ * This is specified as 425 Hz, which corresponds to 0x284BDA13.
+ * That is also the default value, so no need to set it explicitly.
+ */
 #define VEC_FCW_SECAM_B0x198
 #define VEC_SECAM_GAIN_VAL 0x19c
 
@@ -197,6 +227,10 @@ enum vc4_vec_tv_mode_id {
VC4_VEC_TV_MODE_NTSC_J,
VC4_VEC_TV_MODE_PAL,
VC4_VEC_TV_MODE_PAL_M,
+   VC4_VEC_TV_MODE_NTSC_443,
+   VC4_VEC_TV_MODE_PAL_60,
+   VC4_VEC_TV_MODE_PAL_N,
+   VC4_VEC_TV_MODE_SECAM,
 };
 
 struct vc4_vec_tv_mode {
@@ -239,6 +273,12 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
.config0 = VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
+   {
+   .mode = DRM_MODE_TV_MODE_NTSC_443,
+   .config0 = VEC_CONFIG0_NTSC_STD,
+   .config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
+   .custom_freq = 0x2a098acb,
+   },
{
.mode = DRM_MODE_TV_MODE_NTSC_J,
.config0 = VEC_CONFIG0_NTSC_STD,
@@ -254,6 +294,17 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
.config0 = VEC_CONFIG0_PAL_M_STD,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
+   {
+   .mode = DRM_MODE_TV_MODE_PAL_N,
+   .config0 = VEC_CONFIG0_PAL_N_STD,
+   .config1 = VEC_CONFIG1_C_CVBS_CVBS,
+   },
+   {
+   .mode = DRM_MODE_TV_MODE_SECAM,
+   .config0 = VEC_CONFIG0_SECAM_STD,
+   .config1 = VEC_CONFIG1_C_CVBS_CVBS,
+   .custom_freq = 0x29c71c72,
+   },
 };
 
 static inline const struct vc4_vec_tv_mode *
@@ -273,9 +324,13 @@ vc4_vec_tv_mode_lookup(unsigned int mode)
 
 static const struct

[Intel-gfx] [PATCH v4 28/30] drm/vc4: vec: Convert to the new TV mode property

2022-09-29 Thread Maxime Ripard

Now that the core can deal fine with analog TV modes, let's convert the vc4
VEC driver to leverage those new features.

We've added some backward compatibility to support the old TV mode property
and translate it into the new TV norm property. We're also making use of
the new analog TV atomic_check helper to make sure we trigger a modeset
whenever the TV mode is updated.

Acked-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 

---
Changes in v4:
- Removed the count variable in .get_modes
---
 drivers/gpu/drm/vc4/vc4_vec.c | 192 +++---
 1 file changed, 144 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index 1fcb7baf874e..b342dc9cf69c 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -172,6 +172,8 @@ struct vc4_vec {
 
struct clk *clock;
 
+   struct drm_property *legacy_tv_mode_property;
+
struct debugfs_regset32 regset;
 };
 
@@ -184,6 +186,12 @@ encoder_to_vc4_vec(struct drm_encoder *encoder)
return container_of(encoder, struct vc4_vec, encoder.base);
 }
 
+static inline struct vc4_vec *
+connector_to_vc4_vec(struct drm_connector *connector)
+{
+   return container_of(connector, struct vc4_vec, connector);
+}
+
 enum vc4_vec_tv_mode_id {
VC4_VEC_TV_MODE_NTSC,
VC4_VEC_TV_MODE_NTSC_J,
@@ -192,7 +200,7 @@ enum vc4_vec_tv_mode_id {
 };
 
 struct vc4_vec_tv_mode {
-   const struct drm_display_mode *mode;
+   unsigned int mode;
u32 config0;
u32 config1;
u32 custom_freq;
@@ -225,43 +233,51 @@ static const struct debugfs_reg32 vec_regs[] = {
VC4_REG32(VEC_DAC_MISC),
 };
 
-static const struct drm_display_mode ntsc_mode = {
-   DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 13500,
-720, 720 + 14, 720 + 14 + 64, 720 + 14 + 64 + 60, 0,
-480, 480 + 7, 480 + 7 + 6, 525, 0,
-DRM_MODE_FLAG_INTERLACE)
-};
-
-static const struct drm_display_mode pal_mode = {
-   DRM_MODE("720x576", DRM_MODE_TYPE_DRIVER, 13500,
-720, 720 + 20, 720 + 20 + 64, 720 + 20 + 64 + 60, 0,
-576, 576 + 4, 576 + 4 + 6, 625, 0,
-DRM_MODE_FLAG_INTERLACE)
-};
-
 static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
-   [VC4_VEC_TV_MODE_NTSC] = {
-   .mode = _mode,
+   {
+   .mode = DRM_MODE_TV_MODE_NTSC,
.config0 = VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
-   [VC4_VEC_TV_MODE_NTSC_J] = {
-   .mode = _mode,
+   {
+   .mode = DRM_MODE_TV_MODE_NTSC_J,
.config0 = VEC_CONFIG0_NTSC_STD,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
-   [VC4_VEC_TV_MODE_PAL] = {
-   .mode = _mode,
+   {
+   .mode = DRM_MODE_TV_MODE_PAL,
.config0 = VEC_CONFIG0_PAL_BDGHI_STD,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
-   [VC4_VEC_TV_MODE_PAL_M] = {
-   .mode = _mode,
+   {
+   .mode = DRM_MODE_TV_MODE_PAL_M,
.config0 = VEC_CONFIG0_PAL_M_STD,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
 };
 
+static inline const struct vc4_vec_tv_mode *
+vc4_vec_tv_mode_lookup(unsigned int mode)
+{
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(vc4_vec_tv_modes); i++) {
+   const struct vc4_vec_tv_mode *tv_mode = _vec_tv_modes[i];
+
+   if (tv_mode->mode == mode)
+   return tv_mode;
+   }
+
+   return NULL;
+}
+
+static const struct drm_prop_enum_list tv_mode_names[] = {
+   { VC4_VEC_TV_MODE_NTSC, "NTSC", },
+   { VC4_VEC_TV_MODE_NTSC_J, "NTSC-J", },
+   { VC4_VEC_TV_MODE_PAL, "PAL", },
+   { VC4_VEC_TV_MODE_PAL_M, "PAL-M", },
+};
+
 static enum drm_connector_status
 vc4_vec_connector_detect(struct drm_connector *connector, bool force)
 {
@@ -276,19 +292,96 @@ static void vc4_vec_connector_reset(struct drm_connector 
*connector)
 
 static int vc4_vec_connector_get_modes(struct drm_connector *connector)
 {
-   struct drm_connector_state *state = connector->state;
struct drm_display_mode *mode;
 
-   mode = drm_mode_duplicate(connector->dev,
- vc4_vec_tv_modes[state->tv.legacy_mode].mode);
+   mode = drm_mode_analog_ntsc_480i(connector->dev);
if (!mode) {
DRM_ERROR("Failed to create a new display mode\n");
return -ENOMEM;
}
 
+   mode->type |= DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
 
-   return 1;
+   mode = drm_mode_analog_pal_576i(connector->dev);
+   if (!mode) {
+   DRM_ERROR("Failed to create a new display mode\n");
+   return -ENOMEM;
+   }
+
+   drm_mode_probed_add(connector, mode);
+
+   return 2;
+}
+

[Intel-gfx] [PATCH v4 19/30] drm/connector: Add a function to lookup a TV mode by its name

2022-09-29 Thread Maxime Ripard

As part of the command line parsing rework coming in the next patches,
we'll need to lookup drm_connector_tv_mode values by their name, already
defined in drm_tv_mode_enum_list.

In order to avoid any code duplication, let's do a function that will
perform a lookup of a TV mode name and return its value.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_connector.c | 24 
 include/drm/drm_connector.h |  2 ++
 2 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 8edc347ef664..ead5b30c193c 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -991,6 +991,30 @@ static const struct drm_prop_enum_list 
drm_tv_mode_enum_list[] = {
 };
 DRM_ENUM_NAME_FN(drm_get_tv_mode_name, drm_tv_mode_enum_list)
 
+/**
+ * drm_get_tv_mode_from_name - Translates a TV mode name into its enum value
+ * @name: TV Mode name we want to convert
+ * @len: Length of @name
+ *
+ * Translates @name into an enum drm_connector_tv_mode.
+ *
+ * Returns: the enum value on success, a negative errno otherwise.
+ */
+int drm_get_tv_mode_from_name(const char *name, size_t len)
+{
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(drm_tv_mode_enum_list); i++) {
+   const struct drm_prop_enum_list *item = 
_tv_mode_enum_list[i];
+
+   if (strlen(item->name) == len && !strncmp(item->name, name, 
len))
+   return item->type;
+   }
+
+   return -EINVAL;
+}
+EXPORT_SYMBOL(drm_get_tv_mode_from_name);
+
 static const struct drm_prop_enum_list drm_tv_select_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index a501db7d..a33f24a76738 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1864,6 +1864,8 @@ const char *drm_get_dp_subconnector_name(int val);
 const char *drm_get_content_protection_name(int val);
 const char *drm_get_hdcp_content_type_name(int val);
 
+int drm_get_tv_mode_from_name(const char *name, size_t len);
+
 int drm_mode_create_dvi_i_properties(struct drm_device *dev);
 void drm_connector_attach_dp_subconnector_property(struct drm_connector 
*connector);
 

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 26/30] drm/vc4: vec: Use TV Reset implementation

2022-09-29 Thread Maxime Ripard

The analog TV properties created by the drm_mode_create_tv_properties() are
not properly initialised at reset. Let's switch our implementation to call
drm_atomic_helper_connector_tv_reset().

Reviewed-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_vec.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index adc9bf99e3fd..90e375a8a8f9 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -268,6 +268,12 @@ vc4_vec_connector_detect(struct drm_connector *connector, 
bool force)
return connector_status_unknown;
 }
 
+static void vc4_vec_connector_reset(struct drm_connector *connector)
+{
+   drm_atomic_helper_connector_reset(connector);
+   drm_atomic_helper_connector_tv_reset(connector);
+}
+
 static int vc4_vec_connector_get_modes(struct drm_connector *connector)
 {
struct drm_connector_state *state = connector->state;
@@ -288,7 +294,7 @@ static int vc4_vec_connector_get_modes(struct drm_connector 
*connector)
 static const struct drm_connector_funcs vc4_vec_connector_funcs = {
.detect = vc4_vec_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
-   .reset = drm_atomic_helper_connector_reset,
+   .reset = vc4_vec_connector_reset,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 25/30] drm/vc4: vec: Fix definition of PAL-M mode

2022-09-29 Thread Maxime Ripard

From: Mateusz Kwiatkowski 

PAL-M is a Brazilian analog TV standard that uses a PAL-style chroma
subcarrier at 3.575611[888111] MHz on top of 525-line (480i60) timings.
This commit makes the driver actually use the proper VEC preset for this
mode instead of just changing PAL subcarrier frequency.

Acked-by: Noralf Trønnes 
Signed-off-by: Mateusz Kwiatkowski 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_vec.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index 4d82ad30449b..adc9bf99e3fd 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -69,6 +69,7 @@
 #define VEC_CONFIG0_STD_MASK   GENMASK(1, 0)
 #define VEC_CONFIG0_NTSC_STD   0
 #define VEC_CONFIG0_PAL_BDGHI_STD  1
+#define VEC_CONFIG0_PAL_M_STD  2
 #define VEC_CONFIG0_PAL_N_STD  3
 
 #define VEC_SCHPH  0x108
@@ -255,10 +256,9 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
[VC4_VEC_TV_MODE_PAL_M] = {
-   .mode = _mode,
-   .config0 = VEC_CONFIG0_PAL_BDGHI_STD,
-   .config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
-   .custom_freq = 0x223b61d1,
+   .mode = _mode,
+   .config0 = VEC_CONFIG0_PAL_M_STD,
+   .config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
 };
 

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 16/30] drm/modes: Switch to named mode descriptors

2022-09-29 Thread Maxime Ripard

The current named mode parsing relies only the mode name, and doesn't allow
to specify any other parameter.

Let's convert that string list to an array of a custom structure that will
hold the name and some additional parameters in the future.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_modes.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 2f020ef2ddf2..7ed3fb839db7 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2224,9 +2224,13 @@ static int drm_mode_parse_cmdline_options(const char 
*str,
return 0;
 }
 
-static const char * const drm_named_modes_whitelist[] = {
-   "NTSC",
-   "PAL",
+struct drm_named_mode {
+   const char *name;
+};
+
+static const struct drm_named_mode drm_named_modes[] = {
+   { "NTSC", },
+   { "PAL", },
 };
 
 static int drm_mode_parse_cmdline_named_mode(const char *name,
@@ -2262,14 +2266,15 @@ static int drm_mode_parse_cmdline_named_mode(const char 
*name,
 * We're sure we're a named mode at that point, iterate over the
 * list of modes we're aware of.
 */
-   for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
+   for (i = 0; i < ARRAY_SIZE(drm_named_modes); i++) {
+   const struct drm_named_mode *mode = _named_modes[i];
int ret;
 
-   ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
+   ret = str_has_prefix(name, mode->name);
if (ret != name_end)
continue;
 
-   strcpy(cmdline_mode->name, drm_named_modes_whitelist[i]);
+   strcpy(cmdline_mode->name, mode->name);
cmdline_mode->specified = true;
 
return 1;

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 15/30] drm/modes: Move named modes parsing to a separate function

2022-09-29 Thread Maxime Ripard

The current construction of the named mode parsing doesn't allow to extend
it easily. Let's move it to a separate function so we can add more
parameters and modes.

In order for the tests to still pass, some extra checks are needed, so
it's not a 1:1 move.

Signed-off-by: Maxime Ripard 

---
Changes in v4:
- Fold down all the named mode patches that were split into a single
  patch again to maintain bisectability
---
 drivers/gpu/drm/drm_modes.c | 73 ++---
 1 file changed, 62 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index c0dceff51cac..2f020ef2ddf2 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2229,6 +2229,55 @@ static const char * const drm_named_modes_whitelist[] = {
"PAL",
 };
 
+static int drm_mode_parse_cmdline_named_mode(const char *name,
+unsigned int name_end,
+struct drm_cmdline_mode 
*cmdline_mode)
+{
+   unsigned int i;
+
+   if (!name_end)
+   return 0;
+
+   /* If the name starts with a digit, it's not a named mode */
+   if (isdigit(name[0]))
+   return 0;
+
+   /*
+* If there's an equal sign in the name, the command-line
+* contains only an option and no mode.
+*/
+   if (strnchr(name, name_end, '='))
+   return 0;
+
+#define STR_STRICT_EQ(str, len, cmp) \
+   (str_has_prefix(str, cmp) == len)
+
+   /* The connection status extras can be set without a mode. */
+   if (STR_STRICT_EQ(name, name_end, "d") ||
+   STR_STRICT_EQ(name, name_end, "D") ||
+   STR_STRICT_EQ(name, name_end, "e"))
+   return 0;
+
+   /*
+* We're sure we're a named mode at that point, iterate over the
+* list of modes we're aware of.
+*/
+   for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
+   int ret;
+
+   ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
+   if (ret != name_end)
+   continue;
+
+   strcpy(cmdline_mode->name, drm_named_modes_whitelist[i]);
+   cmdline_mode->specified = true;
+
+   return 1;
+   }
+
+   return -EINVAL;
+}
+
 /**
  * drm_mode_parse_command_line_for_connector - parse command line modeline for 
connector
  * @mode_option: optional per connector mode option
@@ -2265,7 +2314,7 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
const char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
const char *options_ptr = NULL;
char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
-   int i, len, ret;
+   int len, ret;
 
memset(mode, 0, sizeof(*mode));
mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
@@ -2306,17 +2355,19 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
parse_extras = true;
}
 
-   /* First check for a named mode */
-   for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
-   ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
-   if (ret == mode_end) {
-   if (refresh_ptr)
-   return false; /* named + refresh is invalid */
 
-   strcpy(mode->name, drm_named_modes_whitelist[i]);
-   mode->specified = true;
-   break;
-   }
+   if (mode_end) {
+   ret = drm_mode_parse_cmdline_named_mode(name, mode_end, mode);
+   if (ret < 0)
+   return false;
+
+   /*
+* Having a mode that starts by a letter (and thus is named)
+* and an at-sign (used to specify a refresh rate) is
+* disallowed.
+*/
+   if (ret && refresh_ptr)
+   return false;
}
 
/* No named mode? Check for a normal mode argument, e.g. 1024x768 */

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 18/30] drm/connector: Add pixel clock to cmdline mode

2022-09-29 Thread Maxime Ripard

We'll need to get the pixel clock to generate proper display modes for
all the current named modes. Let's add it to struct drm_cmdline_mode and
fill it when parsing the named mode.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_modes.c | 9 ++---
 include/drm/drm_connector.h | 7 +++
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 99453aca9a83..068c78d54db2 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2226,22 +2226,24 @@ static int drm_mode_parse_cmdline_options(const char 
*str,
 
 struct drm_named_mode {
const char *name;
+   unsigned int pixel_clock_khz;
unsigned int xres;
unsigned int yres;
unsigned int flags;
 };
 
-#define NAMED_MODE(_name, _x, _y, _flags)  \
+#define NAMED_MODE(_name, _pclk, _x, _y, _flags)   \
{   \
.name = _name,  \
+   .pixel_clock_khz = _pclk,   \
.xres = _x, \
.yres = _y, \
.flags = _flags,\
}
 
 static const struct drm_named_mode drm_named_modes[] = {
-   NAMED_MODE("NTSC", 720, 480, DRM_MODE_FLAG_INTERLACE),
-   NAMED_MODE("PAL", 720, 576, DRM_MODE_FLAG_INTERLACE),
+   NAMED_MODE("NTSC", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE),
+   NAMED_MODE("PAL", 13500, 720, 576, DRM_MODE_FLAG_INTERLACE),
 };
 
 static int drm_mode_parse_cmdline_named_mode(const char *name,
@@ -2286,6 +2288,7 @@ static int drm_mode_parse_cmdline_named_mode(const char 
*name,
continue;
 
strcpy(cmdline_mode->name, mode->name);
+   cmdline_mode->pixel_clock = mode->pixel_clock_khz;
cmdline_mode->xres = mode->xres;
cmdline_mode->yres = mode->yres;
cmdline_mode->interlace = !!(mode->flags & 
DRM_MODE_FLAG_INTERLACE);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ef5f1c779de3..a501db7d 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1273,6 +1273,13 @@ struct drm_cmdline_mode {
 */
bool bpp_specified;
 
+   /**
+* @pixel_clock:
+*
+* Pixel Clock in kHz. Optional.
+*/
+   unsigned int pixel_clock;
+
/**
 * @xres:
 *

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 13/30] drm/modes: parse_cmdline: Add support for named modes containing dashes

2022-09-29 Thread Maxime Ripard

From: Geert Uytterhoeven 

It is fairly common for named video modes to contain dashes (e.g.
"tt-mid" on Atari, "dblntsc-ff" on Amiga).  Currently such mode names
are not recognized, as the dash is considered to be a separator between
mode name and bpp.

Fix this by skipping any dashes that are not followed immediately by a
digit when looking for the separator.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Hans de Goede 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_modes.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 99809ea09ce3..c0dceff51cac 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2284,6 +2284,8 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
 
/* Try to locate the bpp and refresh specifiers, if any */
bpp_ptr = strnchr(name, options_off, '-');
+   while (bpp_ptr && !isdigit(bpp_ptr[1]))
+   bpp_ptr = strnchr(bpp_ptr + 1, options_off, '-');
if (bpp_ptr)
bpp_off = bpp_ptr - name;
 

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 10/30] drm/connector: Add TV standard property

2022-09-29 Thread Maxime Ripard

The TV mode property has been around for a while now to select and get the
current TV mode output on an analog TV connector.

Despite that property name being generic, its content isn't and has been
driver-specific which makes it hard to build any generic behaviour on top
of it, both in kernel and user-space.

Let's create a new enum tv norm property, that can contain any of the
analog TV standards currently supported by kernel drivers. Each driver can
then pass in a bitmask of the modes it supports, and the property
creation function will filter out the modes not supported.

We'll then be able to phase out the older tv mode property.

Signed-off-by: Maxime Ripard 

---
Changes in v4:
- Add property documentation to kms-properties.csv
- Fix documentation
---
 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic_uapi.c|  4 +++
 drivers/gpu/drm/drm_connector.c  | 57 +++-
 include/drm/drm_connector.h  | 64 
 include/drm/drm_mode_config.h|  8 +
 5 files changed, 133 insertions(+), 1 deletion(-)

diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index 45c12e3e82f4..3498bd5d5856 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -91,6 +91,7 @@ omap,Generic,“zorder”,RANGE,"Min=0, Max=3","CRTC, Plane",TBD
 qxl,Generic,"“hotplug_mode_update""",RANGE,"Min=0, Max=1",Connector,TBD
 radeon,DVI-I,“coherent”,RANGE,"Min=0, Max=1",Connector,TBD
 ,DAC enable load detect,“load detection”,RANGE,"Min=0, Max=1",Connector,TBD
+,TV Mode,"""TV Mode""",ENUM,"{ ""NTSC"", ""NTSC-443"", ""NTSC-J"", ""PAL"", 
""PAL-M"", ""PAL-N"", ""SECAM"" }",Connector,TBD
 ,legacy TMDS PLL detect,"""tmds_pll""",ENUM,"{ ""driver"", ""bios"" }",-,TBD
 ,Underscan,"""underscan""",ENUM,"{ ""off"", ""on"", ""auto"" }",Connector,TBD
 ,,"""underscan hborder""",RANGE,"Min=0, Max=128",Connector,TBD
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 7f2b9a07fbdf..d867e7f9f2cd 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -700,6 +700,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->tv.margins.bottom = val;
} else if (property == config->legacy_tv_mode_property) {
state->tv.legacy_mode = val;
+   } else if (property == config->tv_mode_property) {
+   state->tv.mode = val;
} else if (property == config->tv_brightness_property) {
state->tv.brightness = val;
} else if (property == config->tv_contrast_property) {
@@ -810,6 +812,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->tv.margins.bottom;
} else if (property == config->legacy_tv_mode_property) {
*val = state->tv.legacy_mode;
+   } else if (property == config->tv_mode_property) {
+   *val = state->tv.mode;
} else if (property == config->tv_brightness_property) {
*val = state->tv.brightness;
} else if (property == config->tv_contrast_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4e4fbc9e0049..8edc347ef664 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -980,6 +980,17 @@ static const struct drm_prop_enum_list 
drm_dvi_i_subconnector_enum_list[] = {
 DRM_ENUM_NAME_FN(drm_get_dvi_i_subconnector_name,
 drm_dvi_i_subconnector_enum_list)
 
+static const struct drm_prop_enum_list drm_tv_mode_enum_list[] = {
+   { DRM_MODE_TV_MODE_NTSC, "NTSC" },
+   { DRM_MODE_TV_MODE_NTSC_443, "NTSC-443" },
+   { DRM_MODE_TV_MODE_NTSC_J, "NTSC-J" },
+   { DRM_MODE_TV_MODE_PAL, "PAL" },
+   { DRM_MODE_TV_MODE_PAL_M, "PAL-M" },
+   { DRM_MODE_TV_MODE_PAL_N, "PAL-N" },
+   { DRM_MODE_TV_MODE_SECAM, "SECAM" },
+};
+DRM_ENUM_NAME_FN(drm_get_tv_mode_name, drm_tv_mode_enum_list)
+
 static const struct drm_prop_enum_list drm_tv_select_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
@@ -1645,6 +1656,10 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
  * responsible for allocating a list of format names and passing them to
  * this routine.
  *
+ * NOTE: This functions registers the deprecated "mode" connector
+ * property to select the analog TV mode (ie, NTSC, PAL, etc.). New
+ * drivers must use drm_mode_create_tv_properties() instead.
+ *
  * Returns:
  * 0 on success or a negative error code on failure.
  */
@@ -1686,7 +1701,6 @@ int drm_mode_create_tv_properties_legacy(struct 
drm_device *dev,
if (drm_mode_create_tv_margin_properties(dev))
goto nomem;
 
-
if (num_modes) {

[Intel-gfx] [PATCH v4 11/30] drm/modes: Add a function to generate analog display modes

2022-09-29 Thread Maxime Ripard

Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
625-lines modes in their drivers.

Since those modes are fairly standard, and that we'll need to use them
in more places in the future, it makes sense to move their definition
into the core framework.

However, analog display usually have fairly loose timings requirements,
the only discrete parameters being the total number of lines and pixel
clock frequency. Thus, we created a function that will create a display
mode from the standard, the pixel frequency and the active area.

Signed-off-by: Maxime Ripard 

---

Changes in v4:
- Reworded the line length check comment
- Switch to HZ_PER_KHZ in tests
- Use previous timing to fill our mode
- Move the number of lines check earlier
---
 drivers/gpu/drm/drm_modes.c| 474 +
 drivers/gpu/drm/tests/Makefile |   1 +
 drivers/gpu/drm/tests/drm_modes_test.c | 144 ++
 include/drm/drm_modes.h|  17 ++
 4 files changed, 636 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 304004fb80aa..7cf2fe98d7d2 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -116,6 +116,480 @@ void drm_mode_probed_add(struct drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_mode_probed_add);
 
+enum drm_mode_analog {
+   DRM_MODE_ANALOG_NTSC, /* 525 lines, 60Hz */
+   DRM_MODE_ANALOG_PAL, /* 625 lines, 50Hz */
+};
+
+/*
+ * The timings come from:
+ * - 
https://web.archive.org/web/20220406232708/http://www.kolumbus.fi/pami1/video/pal_ntsc.html
+ * - 
https://web.archive.org/web/20220406124914/http://martin.hinner.info/vga/pal.html
+ * - 
https://web.archive.org/web/20220609202433/http://www.batsocks.co.uk/readme/video_timing.htm
+ */
+#define NTSC_LINE_DURATION_NS  63556U
+#define NTSC_LINES_NUMBER  525
+
+#define NTSC_HBLK_DURATION_TYP_NS  10900U
+#define NTSC_HBLK_DURATION_MIN_NS  (NTSC_HBLK_DURATION_TYP_NS - 200)
+#define NTSC_HBLK_DURATION_MAX_NS  (NTSC_HBLK_DURATION_TYP_NS + 200)
+
+#define NTSC_HACT_DURATION_TYP_NS  (NTSC_LINE_DURATION_NS - 
NTSC_HBLK_DURATION_TYP_NS)
+#define NTSC_HACT_DURATION_MIN_NS  (NTSC_LINE_DURATION_NS - 
NTSC_HBLK_DURATION_MAX_NS)
+#define NTSC_HACT_DURATION_MAX_NS  (NTSC_LINE_DURATION_NS - 
NTSC_HBLK_DURATION_MIN_NS)
+
+#define NTSC_HFP_DURATION_TYP_NS   1500
+#define NTSC_HFP_DURATION_MIN_NS   1270
+#define NTSC_HFP_DURATION_MAX_NS   2220
+
+#define NTSC_HSLEN_DURATION_TYP_NS 4700
+#define NTSC_HSLEN_DURATION_MIN_NS (NTSC_HSLEN_DURATION_TYP_NS - 100)
+#define NTSC_HSLEN_DURATION_MAX_NS (NTSC_HSLEN_DURATION_TYP_NS + 100)
+
+#define NTSC_HBP_DURATION_TYP_NS   4700
+
+/*
+ * I couldn't find the actual tolerance for the back porch, so let's
+ * just reuse the sync length ones.
+ */
+#define NTSC_HBP_DURATION_MIN_NS   (NTSC_HBP_DURATION_TYP_NS - 100)
+#define NTSC_HBP_DURATION_MAX_NS   (NTSC_HBP_DURATION_TYP_NS + 100)
+
+#define PAL_LINE_DURATION_NS   64000U
+#define PAL_LINES_NUMBER   625
+
+#define PAL_HACT_DURATION_TYP_NS   51950U
+#define PAL_HACT_DURATION_MIN_NS   (PAL_HACT_DURATION_TYP_NS - 100)
+#define PAL_HACT_DURATION_MAX_NS   (PAL_HACT_DURATION_TYP_NS + 400)
+
+#define PAL_HBLK_DURATION_TYP_NS   (PAL_LINE_DURATION_NS - 
PAL_HACT_DURATION_TYP_NS)
+#define PAL_HBLK_DURATION_MIN_NS   (PAL_LINE_DURATION_NS - 
PAL_HACT_DURATION_MAX_NS)
+#define PAL_HBLK_DURATION_MAX_NS   (PAL_LINE_DURATION_NS - 
PAL_HACT_DURATION_MIN_NS)
+
+#define PAL_HFP_DURATION_TYP_NS1650
+#define PAL_HFP_DURATION_MIN_NS(PAL_HFP_DURATION_TYP_NS - 100)
+#define PAL_HFP_DURATION_MAX_NS(PAL_HFP_DURATION_TYP_NS + 400)
+
+#define PAL_HSLEN_DURATION_TYP_NS  4700
+#define PAL_HSLEN_DURATION_MIN_NS  (PAL_HSLEN_DURATION_TYP_NS - 200)
+#define PAL_HSLEN_DURATION_MAX_NS  (PAL_HSLEN_DURATION_TYP_NS + 200)
+
+#define PAL_HBP_DURATION_TYP_NS5700
+#define PAL_HBP_DURATION_MIN_NS(PAL_HBP_DURATION_TYP_NS - 200)
+#define PAL_HBP_DURATION_MAX_NS(PAL_HBP_DURATION_TYP_NS + 200)
+
+struct analog_param_field {
+   unsigned int even, odd;
+};
+
+#define PARAM_FIELD(_odd, _even)   \
+   { .even = _even, .odd = _odd }
+
+struct analog_param_range {
+   unsigned intmin, typ, max;
+};
+
+#define PARAM_RANGE(_min, _typ, _max)  \
+   { .min = _min, .typ = _typ, .max = _max }
+
+struct analog_parameters {
+   unsigned intnum_lines;
+   unsigned intline_duration_ns;
+
+   struct analog_param_range   hact_ns;
+   struct analog_param_range   hfp_ns;
+   struct analog_param_range   hslen_ns;
+   struct analog_param_range   hbp_ns;
+   struct analog_param_range   hblk_ns;
+
+   unsigned intbt601_hfp;
+
+   struct analog_param_field

[Intel-gfx] [PATCH v4 09/30] drm/connector: Rename drm_mode_create_tv_properties

2022-09-29 Thread Maxime Ripard

drm_mode_create_tv_properties(), among other things, will create the
"mode" property that stores the analog TV mode that connector is
supposed to output.

However, that property is getting deprecated, so let's rename that
function to mention it's deprecated. We'll introduce a new variant of
that function creating the property superseeding it in a later patch.

Reviewed-by: Lyude Paul  # nouveau
Reviewed-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_connector.c   | 12 ++--
 drivers/gpu/drm/gud/gud_connector.c   |  4 ++--
 drivers/gpu/drm/i2c/ch7006_drv.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_tv.c   |  2 +-
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c |  2 +-
 drivers/gpu/drm/vc4/vc4_vec.c |  5 +++--
 include/drm/drm_connector.h   |  6 +++---
 7 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 17a5913cefe3..4e4fbc9e0049 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1600,7 +1600,7 @@ EXPORT_SYMBOL(drm_connector_attach_tv_margin_properties);
  * Called by a driver's HDMI connector initialization routine, this function
  * creates the TV margin properties for a given device. No need to call this
  * function for an SDTV connector, it's already called from
- * drm_mode_create_tv_properties().
+ * drm_mode_create_tv_properties_legacy().
  *
  * Returns:
  * 0 on success or a negative error code on failure.
@@ -1635,7 +1635,7 @@ int drm_mode_create_tv_margin_properties(struct 
drm_device *dev)
 EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
 
 /**
- * drm_mode_create_tv_properties - create TV specific connector properties
+ * drm_mode_create_tv_properties_legacy - create TV specific connector 
properties
  * @dev: DRM device
  * @num_modes: number of different TV formats (modes) supported
  * @modes: array of pointers to strings containing name of each format
@@ -1648,9 +1648,9 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
  * Returns:
  * 0 on success or a negative error code on failure.
  */
-int drm_mode_create_tv_properties(struct drm_device *dev,
- unsigned int num_modes,
- const char * const modes[])
+int drm_mode_create_tv_properties_legacy(struct drm_device *dev,
+unsigned int num_modes,
+const char * const modes[])
 {
struct drm_property *tv_selector;
struct drm_property *tv_subconnector;
@@ -1733,7 +1733,7 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
 nomem:
return -ENOMEM;
 }
-EXPORT_SYMBOL(drm_mode_create_tv_properties);
+EXPORT_SYMBOL(drm_mode_create_tv_properties_legacy);
 
 /**
  * drm_mode_create_scaling_mode_property - create scaling mode property
diff --git a/drivers/gpu/drm/gud/gud_connector.c 
b/drivers/gpu/drm/gud/gud_connector.c
index 86e992b2108b..034e78360d4f 100644
--- a/drivers/gpu/drm/gud/gud_connector.c
+++ b/drivers/gpu/drm/gud/gud_connector.c
@@ -400,7 +400,7 @@ static int gud_connector_add_tv_mode(struct gud_device 
*gdrm, struct drm_connect
for (i = 0; i < num_modes; i++)
modes[i] = [i * GUD_CONNECTOR_TV_MODE_NAME_LEN];
 
-   ret = drm_mode_create_tv_properties(connector->dev, num_modes, modes);
+   ret = drm_mode_create_tv_properties_legacy(connector->dev, num_modes, 
modes);
 free:
kfree(buf);
if (ret < 0)
@@ -539,7 +539,7 @@ static int gud_connector_add_properties(struct gud_device 
*gdrm, struct gud_conn
fallthrough;
case GUD_PROPERTY_TV_HUE:
/* This is a no-op if already added. */
-   ret = drm_mode_create_tv_properties(drm, 0, NULL);
+   ret = drm_mode_create_tv_properties_legacy(drm, 0, 
NULL);
if (ret)
goto out;
break;
diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c
index d29b63fd6178..506f6f932518 100644
--- a/drivers/gpu/drm/i2c/ch7006_drv.c
+++ b/drivers/gpu/drm/i2c/ch7006_drv.c
@@ -250,7 +250,7 @@ static int ch7006_encoder_create_resources(struct 
drm_encoder *encoder,
struct drm_device *dev = encoder->dev;
struct drm_mode_config *conf = >mode_config;
 
-   drm_mode_create_tv_properties(dev, NUM_TV_NORMS, ch7006_tv_norm_names);
+   drm_mode_create_tv_properties_legacy(dev, NUM_TV_NORMS, 
ch7006_tv_norm_names);
 
priv->scale_property = drm_property_create_range(dev, 0, "scale", 0, 2);
if (!priv->scale_property)
diff --git a/drivers/gpu/drm/i915/display/intel_tv.c 
b/drivers/gpu/drm/i915/display/intel_tv.c
index abaf9ded942d..5e88da8185ee 100644
--- a/drivers/gpu/drm/i915/display/intel_tv.c
+++ b/drivers/gpu/drm/i915/display/intel_tv.c
@@ -1984,7 +1984,7 @@

[Intel-gfx] [PATCH v4 14/30] drm/client: Add some tests for drm_connector_pick_cmdline_mode()

2022-09-29 Thread Maxime Ripard

drm_connector_pick_cmdline_mode() is in charge of finding a proper
drm_display_mode from the definition we got in the video= command line
argument.

Let's add some unit tests to make sure we're not getting any regressions
there.

Signed-off-by: Maxime Ripard 

---
Changes in v4:
- Removed MODULE macros
---
 drivers/gpu/drm/drm_client_modeset.c|   4 +
 drivers/gpu/drm/tests/drm_client_modeset_test.c | 105 
 2 files changed, 109 insertions(+)

diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index bbc535cc50dd..d553e793e673 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -1237,3 +1237,7 @@ int drm_client_modeset_dpms(struct drm_client_dev 
*client, int mode)
return ret;
 }
 EXPORT_SYMBOL(drm_client_modeset_dpms);
+
+#ifdef CONFIG_DRM_KUNIT_TEST
+#include "tests/drm_client_modeset_test.c"
+#endif
diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c 
b/drivers/gpu/drm/tests/drm_client_modeset_test.c
new file mode 100644
index ..09dc5acbbc42
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2022 Maxime Ripard 
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "drm_kunit_helpers.h"
+
+struct drm_client_modeset_test_priv {
+   struct drm_device *drm;
+   struct drm_connector connector;
+};
+
+static int drm_client_modeset_connector_get_modes(struct drm_connector 
*connector)
+{
+   struct drm_display_mode *mode;
+   int count;
+
+   count = drm_add_modes_noedid(connector, 1920, 1200);
+
+   return count;
+}
+
+static const struct drm_connector_helper_funcs 
drm_client_modeset_connector_helper_funcs = {
+   .get_modes = drm_client_modeset_connector_get_modes,
+};
+
+static const struct drm_connector_funcs drm_client_modeset_connector_funcs = {
+};
+
+static int drm_client_modeset_test_init(struct kunit *test)
+{
+   struct drm_client_modeset_test_priv *priv;
+   int ret;
+
+   priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+   test->priv = priv;
+
+   priv->drm = drm_kunit_device_init(test, "drm-client-modeset-test");
+   if (IS_ERR(priv->drm))
+   return PTR_ERR(priv->drm);
+
+   ret = drmm_connector_init(priv->drm, >connector,
+ _client_modeset_connector_funcs,
+ DRM_MODE_CONNECTOR_Unknown,
+ NULL);
+   if (ret)
+   return ret;
+   drm_connector_helper_add(>connector, 
_client_modeset_connector_helper_funcs);
+
+   return 0;
+
+}
+
+static void drm_pick_cmdline_res_1920_1080_60(struct kunit *test)
+{
+   struct drm_client_modeset_test_priv *priv = test->priv;
+   struct drm_device *drm = priv->drm;
+   struct drm_connector *connector = >connector;
+   struct drm_cmdline_mode *cmdline_mode = >cmdline_mode;
+   struct drm_display_mode *expected_mode, *mode;
+   const char *cmdline = "1920x1080@60";
+   int ret;
+
+   expected_mode = drm_mode_find_dmt(priv->drm, 1920, 1080, 60, false);
+   KUNIT_ASSERT_PTR_NE(test, expected_mode, NULL);
+
+   KUNIT_ASSERT_TRUE(test,
+ drm_mode_parse_command_line_for_connector(cmdline,
+   connector,
+   
cmdline_mode));
+
+   mutex_lock(>mode_config.mutex);
+   ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+   mutex_unlock(>mode_config.mutex);
+   KUNIT_ASSERT_GT(test, ret, 0);
+
+   mode = drm_connector_pick_cmdline_mode(connector);
+   KUNIT_ASSERT_PTR_NE(test, mode, NULL);
+
+   KUNIT_EXPECT_TRUE(test, drm_mode_equal(expected_mode, mode));
+}
+
+static struct kunit_case drm_pick_cmdline_tests[] = {
+   KUNIT_CASE(drm_pick_cmdline_res_1920_1080_60),
+   {}
+};
+
+static struct kunit_suite drm_pick_cmdline_test_suite = {
+   .name = "drm_pick_cmdline",
+   .init = drm_client_modeset_test_init,
+   .test_cases = drm_pick_cmdline_tests
+};
+
+kunit_test_suite(drm_pick_cmdline_test_suite);

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 08/30] drm/connector: Only register TV mode property if present

2022-09-29 Thread Maxime Ripard

The drm_create_tv_properties() will create the TV mode property
unconditionally.

However, since we'll gradually phase it out, let's register it only if we
have a list passed as an argument. This will make the transition easier.

Acked-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_connector.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index ede6025638d7..17a5913cefe3 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1686,15 +1686,18 @@ int drm_mode_create_tv_properties(struct drm_device 
*dev,
if (drm_mode_create_tv_margin_properties(dev))
goto nomem;
 
-   dev->mode_config.legacy_tv_mode_property =
-   drm_property_create(dev, DRM_MODE_PROP_ENUM,
-   "mode", num_modes);
-   if (!dev->mode_config.legacy_tv_mode_property)
-   goto nomem;
 
-   for (i = 0; i < num_modes; i++)
-   drm_property_add_enum(dev->mode_config.legacy_tv_mode_property,
- i, modes[i]);
+   if (num_modes) {
+   dev->mode_config.legacy_tv_mode_property =
+   drm_property_create(dev, DRM_MODE_PROP_ENUM,
+   "mode", num_modes);
+   if (!dev->mode_config.legacy_tv_mode_property)
+   goto nomem;
+
+   for (i = 0; i < num_modes; i++)
+   
drm_property_add_enum(dev->mode_config.legacy_tv_mode_property,
+ i, modes[i]);
+   }
 
dev->mode_config.tv_brightness_property =
drm_property_create_range(dev, 0, "brightness", 0, 100);

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 12/30] drm/modes: Only consider bpp and refresh before options

2022-09-29 Thread Maxime Ripard

Some video= options might have a value that contains a dash. However, the
command line parsing mode considers all dashes as the separator between the
mode and the bpp count.

Let's rework the parsing code a bit to only consider a dash as the bpp
separator if it before a comma, the options separator.

A follow-up patch will add a unit-test for this once such an option is
introduced.

Reviewed-by: Geert Uytterhoeven 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_modes.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 7cf2fe98d7d2..99809ea09ce3 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2275,20 +2275,22 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
 
name = mode_option;
 
+   /* Locate the start of named options */
+   options_ptr = strchr(name, ',');
+   if (options_ptr)
+   options_off = options_ptr - name;
+   else
+   options_off = strlen(name);
+
/* Try to locate the bpp and refresh specifiers, if any */
-   bpp_ptr = strchr(name, '-');
+   bpp_ptr = strnchr(name, options_off, '-');
if (bpp_ptr)
bpp_off = bpp_ptr - name;
 
-   refresh_ptr = strchr(name, '@');
+   refresh_ptr = strnchr(name, options_off, '@');
if (refresh_ptr)
refresh_off = refresh_ptr - name;
 
-   /* Locate the start of named options */
-   options_ptr = strchr(name, ',');
-   if (options_ptr)
-   options_off = options_ptr - name;
-
/* Locate the end of the name / resolution, and parse it */
if (bpp_ptr) {
mode_end = bpp_off;

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 07/30] drm/connector: Rename legacy TV property

2022-09-29 Thread Maxime Ripard

The current tv_mode has driver-specific values that don't allow to
easily share code using it, either at the userspace or kernel level.

Since we're going to introduce a new, generic, property that fit the
same purpose, let's rename this one to legacy_tv_mode to make it
obvious we should move away from it.

Acked-by: Thomas Zimmermann 
Reviewed-by: Lyude Paul  # nouveau
Reviewed-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_atomic_uapi.c | 8 
 drivers/gpu/drm/drm_connector.c   | 6 +++---
 drivers/gpu/drm/gud/gud_connector.c   | 6 +++---
 drivers/gpu/drm/i2c/ch7006_drv.c  | 4 ++--
 drivers/gpu/drm/i915/display/intel_tv.c   | 3 ++-
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 ++--
 drivers/gpu/drm/vc4/vc4_vec.c | 8 
 include/drm/drm_connector.h   | 4 ++--
 include/drm/drm_mode_config.h | 6 --
 9 files changed, 26 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index c06d0639d552..7f2b9a07fbdf 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -698,8 +698,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->tv.margins.top = val;
} else if (property == config->tv_bottom_margin_property) {
state->tv.margins.bottom = val;
-   } else if (property == config->tv_mode_property) {
-   state->tv.mode = val;
+   } else if (property == config->legacy_tv_mode_property) {
+   state->tv.legacy_mode = val;
} else if (property == config->tv_brightness_property) {
state->tv.brightness = val;
} else if (property == config->tv_contrast_property) {
@@ -808,8 +808,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->tv.margins.top;
} else if (property == config->tv_bottom_margin_property) {
*val = state->tv.margins.bottom;
-   } else if (property == config->tv_mode_property) {
-   *val = state->tv.mode;
+   } else if (property == config->legacy_tv_mode_property) {
+   *val = state->tv.legacy_mode;
} else if (property == config->tv_brightness_property) {
*val = state->tv.brightness;
} else if (property == config->tv_contrast_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index e3142c8142b3..ede6025638d7 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1686,14 +1686,14 @@ int drm_mode_create_tv_properties(struct drm_device 
*dev,
if (drm_mode_create_tv_margin_properties(dev))
goto nomem;
 
-   dev->mode_config.tv_mode_property =
+   dev->mode_config.legacy_tv_mode_property =
drm_property_create(dev, DRM_MODE_PROP_ENUM,
"mode", num_modes);
-   if (!dev->mode_config.tv_mode_property)
+   if (!dev->mode_config.legacy_tv_mode_property)
goto nomem;
 
for (i = 0; i < num_modes; i++)
-   drm_property_add_enum(dev->mode_config.tv_mode_property,
+   drm_property_add_enum(dev->mode_config.legacy_tv_mode_property,
  i, modes[i]);
 
dev->mode_config.tv_brightness_property =
diff --git a/drivers/gpu/drm/gud/gud_connector.c 
b/drivers/gpu/drm/gud/gud_connector.c
index fa636206f232..86e992b2108b 100644
--- a/drivers/gpu/drm/gud/gud_connector.c
+++ b/drivers/gpu/drm/gud/gud_connector.c
@@ -303,7 +303,7 @@ static int gud_connector_atomic_check(struct drm_connector 
*connector,
old_state->tv.margins.right != new_state->tv.margins.right ||
old_state->tv.margins.top != new_state->tv.margins.top ||
old_state->tv.margins.bottom != new_state->tv.margins.bottom ||
-   old_state->tv.mode != new_state->tv.mode ||
+   old_state->tv.legacy_mode != new_state->tv.legacy_mode ||
old_state->tv.brightness != new_state->tv.brightness ||
old_state->tv.contrast != new_state->tv.contrast ||
old_state->tv.flicker_reduction != new_state->tv.flicker_reduction 
||
@@ -424,7 +424,7 @@ gud_connector_property_lookup(struct drm_connector 
*connector, u16 prop)
case GUD_PROPERTY_TV_BOTTOM_MARGIN:
return config->tv_bottom_margin_property;
case GUD_PROPERTY_TV_MODE:
-   return config->tv_mode_property;
+   return config->legacy_tv_mode_property;
case GUD_PROPERTY_TV_BRIGHTNESS:
return config->tv_brightness_property;
case GUD_PROPERTY_TV_CONTRAST:
@@ -454,7 +454,7 @@ static unsigned int *gud_connector_tv_state_val(u16 prop, 
struct drm_tv_connecto
case GUD_PROPERTY_TV_BOTTOM_MARGIN:
return >margins.bottom;
case

[Intel-gfx] [PATCH v4 06/30] drm/atomic: Add TV subconnector property to get/set_property

2022-09-29 Thread Maxime Ripard

The subconnector property was created by drm_mode_create_tv_properties(),
but wasn't exposed to the userspace through the generic
atomic_get/set_property implementation, and wasn't stored in any generic
state structure.

Let's solve this.

Reviewed-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_atomic_uapi.c | 4 
 include/drm/drm_connector.h   | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index c74c78a28171..c06d0639d552 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -688,6 +688,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
return -EINVAL;
} else if (property == config->tv_select_subconnector_property) {
state->tv.select_subconnector = val;
+   } else if (property == config->tv_subconnector_property) {
+   state->tv.subconnector = val;
} else if (property == config->tv_left_margin_property) {
state->tv.margins.left = val;
} else if (property == config->tv_right_margin_property) {
@@ -796,6 +798,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = connector->dpms;
} else if (property == config->tv_select_subconnector_property) {
*val = state->tv.select_subconnector;
+   } else if (property == config->tv_subconnector_property) {
+   *val = state->tv.subconnector;
} else if (property == config->tv_left_margin_property) {
*val = state->tv.margins.left;
} else if (property == config->tv_right_margin_property) {
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 60b5662dec7c..1d5e3cccb9e3 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -693,6 +693,7 @@ struct drm_connector_tv_margins {
 /**
  * struct drm_tv_connector_state - TV connector related states
  * @select_subconnector: selected subconnector
+ * @subconnector: detected subconnector
  * @margins: TV margins
  * @mode: TV mode
  * @brightness: brightness in percent
@@ -704,6 +705,7 @@ struct drm_connector_tv_margins {
  */
 struct drm_tv_connector_state {
enum drm_mode_subconnector select_subconnector;
+   enum drm_mode_subconnector subconnector;
struct drm_connector_tv_margins margins;
unsigned int mode;
unsigned int brightness;

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 05/30] drm/connector: Rename subconnector state variable

2022-09-29 Thread Maxime Ripard

There is two TV subconnector related properties registered by
drm_mode_create_tv_properties(): subconnector and select subconnector.

While the select subconnector property is stored in the kernel by the
drm_tv_connector_state structure, the subconnector property isn't stored
anywhere.

Worse, the select subconnector property is stored in a field called
subconnector, creating some ambiguity about which property content we're
accessing.

Let's rename that field to one called select_subconnector to make it move
obvious what it's about.

Acked-by: Thomas Zimmermann 
Reviewed-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 

---
Changes in v4:
- Added the documentation name update
---
 drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
 include/drm/drm_connector.h   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 79730fa1dd8e..c74c78a28171 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -687,7 +687,7 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
 */
return -EINVAL;
} else if (property == config->tv_select_subconnector_property) {
-   state->tv.subconnector = val;
+   state->tv.select_subconnector = val;
} else if (property == config->tv_left_margin_property) {
state->tv.margins.left = val;
} else if (property == config->tv_right_margin_property) {
@@ -795,7 +795,7 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
else
*val = connector->dpms;
} else if (property == config->tv_select_subconnector_property) {
-   *val = state->tv.subconnector;
+   *val = state->tv.select_subconnector;
} else if (property == config->tv_left_margin_property) {
*val = state->tv.margins.left;
} else if (property == config->tv_right_margin_property) {
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 248206bbd975..60b5662dec7c 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -692,7 +692,7 @@ struct drm_connector_tv_margins {
 
 /**
  * struct drm_tv_connector_state - TV connector related states
- * @subconnector: selected subconnector
+ * @select_subconnector: selected subconnector
  * @margins: TV margins
  * @mode: TV mode
  * @brightness: brightness in percent
@@ -703,7 +703,7 @@ struct drm_connector_tv_margins {
  * @hue: hue in percent
  */
 struct drm_tv_connector_state {
-   enum drm_mode_subconnector subconnector;
+   enum drm_mode_subconnector select_subconnector;
struct drm_connector_tv_margins margins;
unsigned int mode;
unsigned int brightness;

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 04/30] drm/atomic-helper: Rename drm_atomic_helper_connector_tv_reset to avoid ambiguity

2022-09-29 Thread Maxime Ripard

We currently have two sets of TV properties.

The first one is there to deal with analog TV properties, creating
properties such as the TV mode, subconnectors, saturation, hue and so on.
It's created by calling the drm_mode_create_tv_properties() function.

The second one is there to deal with properties that might be useful on a
TV, creating the overscan margins for example. It's created by calling the
drm_mode_create_tv_margin_properties().

However, we also have a drm_atomic_helper_connector_tv_reset() function
that will reset the TV margin properties to their default values, and thus
is supposed to be called for the latter set. This creates an ambiguity due
to the inconsistent naming.

We can thus rename the drm_atomic_helper_connector_tv_reset() function to
drm_atomic_helper_connector_tv_margins_reset() to remove that ambiguity
and hopefully make it more obvious.

Acked-by: Thomas Zimmermann 
Reviewed-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 

---
Changes in v4:
- Removed the unrelated subconnector documentation name change
---
 drivers/gpu/drm/drm_atomic_state_helper.c | 6 +++---
 drivers/gpu/drm/gud/gud_connector.c   | 2 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +-
 include/drm/drm_atomic_state_helper.h | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
b/drivers/gpu/drm/drm_atomic_state_helper.c
index bf31b9d92094..dfb57217253b 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -464,12 +464,12 @@ void drm_atomic_helper_connector_reset(struct 
drm_connector *connector)
 EXPORT_SYMBOL(drm_atomic_helper_connector_reset);
 
 /**
- * drm_atomic_helper_connector_tv_reset - Resets TV connector properties
+ * drm_atomic_helper_connector_tv_margins_reset - Resets TV connector 
properties
  * @connector: DRM connector
  *
  * Resets the TV-related properties attached to a connector.
  */
-void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector)
+void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector 
*connector)
 {
struct drm_cmdline_mode *cmdline = >cmdline_mode;
struct drm_connector_state *state = connector->state;
@@ -479,7 +479,7 @@ void drm_atomic_helper_connector_tv_reset(struct 
drm_connector *connector)
state->tv.margins.top = cmdline->tv_margins.top;
state->tv.margins.bottom = cmdline->tv_margins.bottom;
 }
-EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
+EXPORT_SYMBOL(drm_atomic_helper_connector_tv_margins_reset);
 
 /**
  * __drm_atomic_helper_connector_duplicate_state - copy atomic connector state
diff --git a/drivers/gpu/drm/gud/gud_connector.c 
b/drivers/gpu/drm/gud/gud_connector.c
index d0addd478815..fa636206f232 100644
--- a/drivers/gpu/drm/gud/gud_connector.c
+++ b/drivers/gpu/drm/gud/gud_connector.c
@@ -355,7 +355,7 @@ static void gud_connector_reset(struct drm_connector 
*connector)
drm_atomic_helper_connector_reset(connector);
connector->state->tv = gconn->initial_tv_state;
/* Set margins from command line */
-   drm_atomic_helper_connector_tv_reset(connector);
+   drm_atomic_helper_connector_tv_margins_reset(connector);
if (gconn->initial_brightness >= 0)
connector->state->tv.brightness = gconn->initial_brightness;
 }
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 64f9feabf43e..99908137dbe7 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -542,7 +542,7 @@ static void vc4_hdmi_connector_reset(struct drm_connector 
*connector)
new_state->base.max_bpc = 8;
new_state->base.max_requested_bpc = 8;
new_state->output_format = VC4_HDMI_OUTPUT_RGB;
-   drm_atomic_helper_connector_tv_reset(connector);
+   drm_atomic_helper_connector_tv_margins_reset(connector);
 }
 
 static struct drm_connector_state *
diff --git a/include/drm/drm_atomic_state_helper.h 
b/include/drm/drm_atomic_state_helper.h
index 3f8f1d627f7c..192766656b88 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -70,7 +70,7 @@ void __drm_atomic_helper_connector_state_reset(struct 
drm_connector_state *conn_
 void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
 struct drm_connector_state 
*conn_state);
 void drm_atomic_helper_connector_reset(struct drm_connector *connector);
-void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
+void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector 
*connector);
 void
 __drm_atomic_helper_connector_duplicate_state(struct drm_connector *connector,
   struct drm_connector_state *state);

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 03/30] drm/tests: Add Kunit Helpers

2022-09-29 Thread Maxime Ripard

As the number of kunit tests in KMS grows further, we start to have
multiple test suites that, for example, need to register a mock DRM
driver to interact with the KMS function they are supposed to test.

Let's add a file meant to provide those kind of helpers to avoid
duplication.

Signed-off-by: Maxime Ripard 

---
Changes in v4:
- Simplified the DRM device cleanup patch using devm_drm_dev_alloc()
---
 drivers/gpu/drm/tests/Makefile|  1 +
 drivers/gpu/drm/tests/drm_kunit_helpers.c | 61 +++
 drivers/gpu/drm/tests/drm_kunit_helpers.h |  9 +
 3 files changed, 71 insertions(+)

diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
index 2d9f49b62ecb..b29ef1085cad 100644
--- a/drivers/gpu/drm/tests/Makefile
+++ b/drivers/gpu/drm/tests/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_KUNIT_TEST) += \
drm_format_helper_test.o \
drm_format_test.o \
drm_framebuffer_test.o \
+   drm_kunit_helpers.o \
drm_mm_test.o \
drm_plane_helper_test.o \
drm_rect_test.o
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c 
b/drivers/gpu/drm/tests/drm_kunit_helpers.c
new file mode 100644
index ..3524d6a1fa9a
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -0,0 +1,61 @@
+#include 
+#include 
+
+#include 
+
+#include 
+
+struct kunit_dev {
+   struct drm_device base;
+};
+
+static const struct drm_mode_config_funcs drm_mode_config_funcs = {
+};
+
+static const struct drm_driver drm_mode_driver = {
+};
+
+static int dev_init(struct kunit_resource *res, void *ptr)
+{
+   char *name = ptr;
+   struct device *dev;
+
+   dev = root_device_register(name);
+   if (IS_ERR(dev))
+   return PTR_ERR(dev);
+
+   res->data = dev;
+   return 0;
+}
+
+static void dev_free(struct kunit_resource *res)
+{
+   struct device *dev = res->data;
+
+   root_device_unregister(dev);
+}
+
+struct drm_device *drm_kunit_device_init(struct kunit *test, char *name)
+{
+   struct kunit_dev *kdev;
+   struct drm_device *drm;
+   struct device *dev;
+   int ret;
+
+   dev = kunit_alloc_resource(test, dev_init, dev_free, GFP_KERNEL, name);
+   if (!dev)
+   return ERR_PTR(-ENOMEM);
+
+   kdev = devm_drm_dev_alloc(dev, _mode_driver, struct kunit_dev, 
base);
+   if (IS_ERR(kdev))
+   return ERR_CAST(kdev);
+
+   drm = >base;
+   drm->mode_config.funcs = _mode_config_funcs;
+
+   ret = drmm_mode_config_init(drm);
+   if (ret)
+   return ERR_PTR(ret);
+
+   return drm;
+}
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.h 
b/drivers/gpu/drm/tests/drm_kunit_helpers.h
new file mode 100644
index ..a9354f9bda4e
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.h
@@ -0,0 +1,9 @@
+#ifndef DRM_KUNIT_HELPERS_H_
+#define DRM_KUNIT_HELPERS_H_
+
+struct drm_device;
+struct kunit;
+
+struct drm_device *drm_kunit_device_init(struct kunit *test, char *name);
+
+#endif // DRM_KUNIT_HELPERS_H_

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 02/30] drm/tests: Order Kunit tests in Makefile

2022-09-29 Thread Maxime Ripard

Since we've recently added a ton of tests, the list starts to be a bit
of a mess and creates unneeded conflicts.

Let's order it alphabetically.

Acked-by: Thomas Zimmermann 
Reviewed-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/tests/Makefile | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
index 91b70f7d2769..2d9f49b62ecb 100644
--- a/drivers/gpu/drm/tests/Makefile
+++ b/drivers/gpu/drm/tests/Makefile
@@ -1,5 +1,13 @@
 # SPDX-License-Identifier: GPL-2.0
 
-obj-$(CONFIG_DRM_KUNIT_TEST) += drm_format_helper_test.o 
drm_damage_helper_test.o \
-   drm_cmdline_parser_test.o drm_rect_test.o drm_format_test.o 
drm_plane_helper_test.o \
-   drm_dp_mst_helper_test.o drm_framebuffer_test.o drm_buddy_test.o 
drm_mm_test.o
+obj-$(CONFIG_DRM_KUNIT_TEST) += \
+   drm_buddy_test.o \
+   drm_cmdline_parser_test.o \
+   drm_damage_helper_test.o \
+   drm_dp_mst_helper_test.o \
+   drm_format_helper_test.o \
+   drm_format_test.o \
+   drm_framebuffer_test.o \
+   drm_mm_test.o \
+   drm_plane_helper_test.o \
+   drm_rect_test.o

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 01/30] drm/docs: Remove unused TV Standard property

2022-09-29 Thread Maxime Ripard

That property is not used or exposed by any driver in the kernel. Remove
it from the documentation.

Signed-off-by: Maxime Ripard 

---
Changes in v4:
- New patch
---
 Documentation/gpu/kms-properties.csv | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index 07ed22ea3bd6..45c12e3e82f4 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -91,7 +91,6 @@ omap,Generic,“zorder”,RANGE,"Min=0, Max=3","CRTC, Plane",TBD
 qxl,Generic,"“hotplug_mode_update""",RANGE,"Min=0, Max=1",Connector,TBD
 radeon,DVI-I,“coherent”,RANGE,"Min=0, Max=1",Connector,TBD
 ,DAC enable load detect,“load detection”,RANGE,"Min=0, Max=1",Connector,TBD
-,TV Standard,"""tv standard""",ENUM,"{ ""ntsc"", ""pal"", ""pal-m"", 
""pal-60"", ""ntsc-j"" , ""scart-pal"", ""pal-cn"", ""secam"" }",Connector,TBD
 ,legacy TMDS PLL detect,"""tmds_pll""",ENUM,"{ ""driver"", ""bios"" }",-,TBD
 ,Underscan,"""underscan""",ENUM,"{ ""off"", ""on"", ""auto"" }",Connector,TBD
 ,,"""underscan hborder""",RANGE,"Min=0, Max=128",Connector,TBD

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 00/30] drm: Analog TV Improvements

2022-09-29 Thread Maxime Ripard

Hi,

Here's a series aiming at improving the command line named modes support,
and more importantly how we deal with all the analog TV variants.

The named modes support were initially introduced to allow to specify the
analog TV mode to be used.

However, this was causing multiple issues:

  * The mode name parsed on the command line was passed directly to the
driver, which had to figure out which mode it was suppose to match;

  * Figuring that out wasn't really easy, since the video= argument or what
the userspace might not even have a name in the first place, but
instead could have passed a mode with the same timings;

  * The fallback to matching on the timings was mostly working as long as
we were supporting one 525 lines (most likely NSTC) and one 625 lines
(PAL), but couldn't differentiate between two modes with the same
timings (NTSC vs PAL-M vs NSTC-J for example);

  * There was also some overlap with the tv mode property registered by
drm_mode_create_tv_properties(), but named modes weren't interacting
with that property at all.

  * Even though that property was generic, its possible values were
specific to each drivers, which made some generic support difficult.

Thus, I chose to tackle in multiple steps:

  * A new TV mode property was introduced, with generic values, each driver
reporting through a bitmask what standard it supports to the userspace;

  * This option was added to the command line parsing code to be able to
specify it on the kernel command line, and new atomic_check and reset
helpers were created to integrate properly into atomic KMS;

  * The named mode parsing code is now creating a proper display mode for
the given named mode, and the TV standard will thus be part of the
connector state;

  * Two drivers were converted and tested for now (vc4 and sun4i), with
some backward compatibility code to translate the old TV mode to the
new TV mode;

Unit tests were created along the way.

One can switch from NTSC to PAL now using (on vc4)

modetest -M vc4  -s 53:720x480i -w 53:'TV mode':1 # NTSC
modetest -M vc4  -s 53:720x576i -w 53:'TV mode':4 # PAL

Let me know what you think,
Maxime

To: David Airlie 
To: Daniel Vetter 
To: Maarten Lankhorst 
To: Maxime Ripard 
To: Thomas Zimmermann 
To: Emma Anholt 
To: Jani Nikula 
To: Joonas Lahtinen 
To: Rodrigo Vivi 
To: Tvrtko Ursulin 
To: Ben Skeggs 
To: Karol Herbst 
To: Lyude Paul 
To: Chen-Yu Tsai 
To: Jernej Skrabec 
To: Samuel Holland 
Cc: Geert Uytterhoeven 
Cc: Mateusz Kwiatkowski 
Cc: "Noralf Trønnes" 
Cc: Dave Stevenson 
Cc: Dom Cobley 
Cc: Phil Elwell 
Cc: 
Cc: linux-ker...@vger.kernel.org
Cc: intel-gfx@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-su...@lists.linux.dev
Cc: Hans de Goede 
Signed-off-by: Maxime Ripard 

---
Changes in v4:
- Removed the unused TV Standard property documentation
- Added the TV Mode property documentation to kms-properties.csv
- Fixed the documentation of drm_mode_create_tv_properties()
- Removed DRM_MODE_TV_MODE_NONE
- Reworded the line length check comment in drm_mode_analog_tv tests
- Switched to HZ_PER_KHZ in drm_mode_analog_tv tests
- Reworked drm_mode_analog_tv to fill our mode using the previously computed
  timings
- Added the command-line option documentation to modedb.rst
- Improved the Kunit helpers cleanup
- Moved the subconnector documentation renaming to the proper patch
- Added the various review tags
- Removed the count variable in vc4_vec_connector_get_modes
- Rebased on drm-misc-next-2022-09-23 and fixed a merge conflict
- Folded all the named mode parsing improvements in a single patch
- Link to v3: 
https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v2-0-f733a0ed9...@cerno.tech

Changes in v3:
- Applied some of the fixes to vc4 and sun4i
- Renamed the old TV mode property to legacy_mode
- Fixed a bunch of bisection errors
- Removed most of the redundant TV modes
- Added a new None TV mode to not fall back on NTSC by mistake
- Fixed the mode generation function to match better what is expected
- Added some logging to the mode generation function
- Split the improvements to the named mode parsing logic into separate patches
- Added more checks to the TV atomic_check helper
- Link to v2: 
https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-properties-v2-0-459522d65...@cerno.tech/

Changes in v2:
- Kept the older TV mode property as legacy so we can keep the old drivers 
functional
- Renamed the tv_norm property to tv_mode
- Added a function to create PAL and NTSC compatible display modes
- Added some helpers to instantiate a mock DRM device in Kunit
- More Kunit tests
- Removed the HD analog TV modes
- Renamed some of the tests
- Renamed some of the named modes
- Fixed typos in commit logs
- Added the various tags
- Link to v1: 
https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-properties-v1-0-3d53ae722...@cerno.tech/

---
Geert

Re: [Intel-gfx] [PATCH v4 3/4] drm/i915: Make the heartbeat play nice with long pre-emption timeouts

2022-09-29 Thread John Harrison


On 9/29/2022 00:42, Tvrtko Ursulin wrote:

On 29/09/2022 03:18, john.c.harri...@intel.com wrote:

From: John Harrison 

Compute workloads are inherently not pre-emptible for long periods on
current hardware. As a workaround for this, the pre-emption timeout
for compute capable engines was disabled. This is undesirable with GuC
submission as it prevents per engine reset of hung contexts. Hence the
next patch will re-enable the timeout but bumped up by an order of
magnitude.

However, the heartbeat might not respect that. Depending upon current
activity, a pre-emption to the heartbeat pulse might not even be
attempted until the last heartbeat period. Which means that only one
period is granted for the pre-emption to occur. With the aforesaid
bump, the pre-emption timeout could be significantly larger than this
heartbeat period.

So adjust the heartbeat code to take the pre-emption timeout into
account. When it reaches the final (high priority) period, it now
ensures the delay before hitting reset is bigger than the pre-emption
timeout.

v2: Fix for selftests which adjust the heartbeat period manually.

Signed-off-by: John Harrison 
---
  .../gpu/drm/i915/gt/intel_engine_heartbeat.c  | 19 +++
  1 file changed, 19 insertions(+)

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

index a3698f611f457..823a790a0e2ae 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -22,9 +22,28 @@
    static bool next_heartbeat(struct intel_engine_cs *engine)
  {
+    struct i915_request *rq;
  long delay;
    delay = READ_ONCE(engine->props.heartbeat_interval_ms);
+
+    rq = engine->heartbeat.systole;
+
+    if (rq && rq->sched.attr.priority >= I915_PRIORITY_BARRIER &&
+    delay == engine->defaults.heartbeat_interval_ms) {


Maybe I forgot but what is the reason for the check against the 
default heartbeat interval?
That's the 'v2: fix for selftests that manually adjust the heartbeat'. 
If something (or someone) has explicitly set an override of the 
heartbeat then it has to be assumed that they know what they are doing, 
and if things don't work any more that's their problem. But if we don't 
respect their override then they won't get the timings they expect and 
the selftest will fail.


John.



Regards,

Tvrtko


+    long longer;
+
+    /*
+ * The final try is at the highest priority possible. Up 
until now
+ * a pre-emption might not even have been attempted. So make 
sure
+ * this last attempt allows enough time for a pre-emption to 
occur.

+ */
+    longer = READ_ONCE(engine->props.preempt_timeout_ms) * 2;
+    longer = intel_clamp_heartbeat_interval_ms(engine, longer);
+    if (longer > delay)
+    delay = longer;
+    }
+
  if (!delay)
  return false;

Re: [Intel-gfx] [PATCH 12/16] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl

2022-09-29 Thread Niranjana Vishwanathapura


On Thu, Sep 29, 2022 at 04:00:47PM +0100, Matthew Auld wrote:

On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:

Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.

The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects binding would have been requested by the
userspace before submitting the execbuf3.

Legacy features like relocations etc are not supported by execbuf3.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 571 ++
 drivers/gpu/drm/i915/gem/i915_gem_ioctls.h|   2 +
 drivers/gpu/drm/i915/i915_driver.c|   1 +
 include/uapi/drm/i915_drm.h   |  61 ++
 5 files changed, 636 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index bf952f478555..3473ee5825bb 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -150,6 +150,7 @@ gem-y += \
gem/i915_gem_domain.o \
gem/i915_gem_execbuffer_common.o \
gem/i915_gem_execbuffer.o \
+   gem/i915_gem_execbuffer3.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
gem/i915_gem_lmem.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
new file mode 100644
index ..92af88bc8deb
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -0,0 +1,571 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "gt/intel_context.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+
+#include "i915_drv.h"
+#include "i915_gem_context.h"
+#include "i915_gem_execbuffer_common.h"
+#include "i915_gem_ioctls.h"
+#include "i915_gem_vm_bind.h"
+#include "i915_trace.h"
+
+#define __EXEC3_ENGINE_PINNED  BIT_ULL(32)
+#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
+
+/* Catch emission of unexpected errors for CI! */
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+#undef EINVAL
+#define EINVAL ({ \
+   DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \
+   22; \
+})
+#endif
+
+/**
+ * DOC: User command execution with execbuf3 ioctl
+ *
+ * A VM in VM_BIND mode will not support older execbuf mode of binding.
+ * The execbuf ioctl handling in VM_BIND mode differs significantly from the
+ * older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
+ * Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
+ * struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
+ * execlist. Hence, no support for implicit sync.
+ *
+ * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
+ * works with execbuf3 ioctl for submission.
+ *
+ * The execbuf3 ioctl directly specifies the batch addresses instead of as
+ * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
+ * support many of the older features like in/out/submit fences, fence array,
+ * default gem context etc. (See struct drm_i915_gem_execbuffer3).
+ *
+ * In VM_BIND mode, VA allocation is completely managed by the user instead of
+ * the i915 driver. Hence all VA assignment, eviction are not applicable in
+ * VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
+ * be using the i915_vma active reference tracking. It will instead check the
+ * dma-resv object's fence list for that.
+ *
+ * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
+ * vma lookup table, implicit sync, vma active reference tracking etc., are not
+ * applicable for execbuf3 ioctl.
+ */
+
+/**
+ * struct i915_execbuffer - execbuf struct for execbuf3
+ * @i915: reference to the i915 instance we run on
+ * @file: drm file reference
+ * args: execbuf3 ioctl structure
+ * @gt: reference to the gt instance ioctl submitted for
+ * @context: logical state for the request
+ * @gem_context: callers context
+ * @requests: requests to be build
+ * @composite_fence: used for excl fence in dma_resv objects when > 1 BB 
submitted
+ * @ww: i915_gem_ww_ctx instance
+ * @num_batches: number of batches submitted
+ * @batch_addresses: addresses corresponds to the submitted batches
+ * @batches: references to the i915_vmas corresponding to the batches
+ */
+struct i915_execbuffer {
+   struct drm_i915_private *i915;
+   struct drm_file *file;
+   struct drm_i915_gem_execbuffer3 *args;
+
+   struct intel_gt *gt;
+   struct intel_context *context;
+   struct i915_gem_context *gem_context;
+
+   struct i915_request *requests[MAX_ENGINE_INSTANCE + 1];
+   struct dma_fence *composite_fence;
+
+   struct i915_gem_ww_ctx ww;
+
+

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

2022-09-29 Thread Rodrigo Vivi

Hi Dave and Daniel,

Here goes drm-intel-fixes-2022-09-29:

- Restrict forced preemption to the active context (Chris)
- Restrict perf_limit_reasons to the supported platforms - gen11+ (Ashutosh)

Thanks,
Rodrigo.

The following changes since commit f76349cf41451c5c42a99f18a9163377e4b364ff:

  Linux 6.0-rc7 (2022-09-25 14:01:02 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-09-29

for you to fetch changes up to 7738be973fc4e2ba22154fafd3a5d7b9666f9abf:

  drm/i915/gt: Perf_limit_reasons are only available for Gen11+ (2022-09-28 
16:39:26 -0400)


- Restrict forced preemption to the active context (Chris)
- Restrict perf_limit_reasons to the supported platforms - gen11+ (Ashutosh)


Ashutosh Dixit (1):
  drm/i915/gt: Perf_limit_reasons are only available for Gen11+

Chris Wilson (1):
  drm/i915/gt: Restrict forced preemption to the active context

 drivers/gpu/drm/i915/gt/intel_engine_types.h| 15 +++
 .../gpu/drm/i915/gt/intel_execlists_submission.c| 21 -
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 15 +++
 3 files changed, 46 insertions(+), 5 deletions(-)

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/mtl: Define engine context layouts

2022-09-29 Thread Patchwork

== Series Details ==

Series: drm/i915/mtl: Define engine context layouts
URL   : https://patchwork.freedesktop.org/series/109190/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_109190v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 11)
--

  Additional (2): shard-dg1 shard-tglu 
  Missing(1): shard-rkl 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * {igt@gem_mmap_offset@ptrace@lmem0-fixed} (NEW):
- {shard-dg1}:NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109190v1/shard-dg1-19/igt@gem_mmap_offset@ptr...@lmem0-fixed.html

  
New tests
-

  New tests have been introduced between CI_DRM_12193_full and 
Patchwork_109190v1_full:

### New IGT tests (35) ###

  * igt@gem_mmap_offset@ptrace@lmem0-fixed:
- Statuses : 1 fail(s)
- Exec time: [0.02] s

  * igt@gem_mmap_offset@ptrace@smem0-fixed:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_color@ctm-max@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.44] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.41] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.25] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.23] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.24] s

  * igt@kms_lease@empty_lease@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * igt@kms_lease@empty_lease@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@empty_lease@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@empty_lease@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@lease_invalid_connector@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@lease_invalid_connector@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_connector@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_connector@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.15] s

  * igt@kms_lease@lease_invalid_crtc@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_plane@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@lease_invalid_plane@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_plane@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_plane@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_revoke@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.25] s

  * igt@kms_lease@lease_revoke@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.11] s

  * igt@kms_lease@lease_revoke@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.11] s

  * igt@kms_lease@lease_revoke@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.11] s

  * igt@kms_lease@lessee_list@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * igt@kms_lease@lessee_list@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@lessee_list@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@lessee_list@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@simple_lease@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.46] s

  * igt@kms_lease@simple_lease@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.26] s

  * igt@kms_lease@simple_lease@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.28] s

  * igt@kms_lease@simple_lease@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.25] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_exec@basic-nohangcheck:
- shard-tglb:

Re: [Intel-gfx] [PATCH 12/16] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl

2022-09-29 Thread Matthew Auld


On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:

Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.

The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects binding would have been requested by the
userspace before submitting the execbuf3.

Legacy features like relocations etc are not supported by execbuf3.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
  drivers/gpu/drm/i915/Makefile |   1 +
  .../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 571 ++
  drivers/gpu/drm/i915/gem/i915_gem_ioctls.h|   2 +
  drivers/gpu/drm/i915/i915_driver.c|   1 +
  include/uapi/drm/i915_drm.h   |  61 ++
  5 files changed, 636 insertions(+)
  create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index bf952f478555..3473ee5825bb 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -150,6 +150,7 @@ gem-y += \
gem/i915_gem_domain.o \
gem/i915_gem_execbuffer_common.o \
gem/i915_gem_execbuffer.o \
+   gem/i915_gem_execbuffer3.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
gem/i915_gem_lmem.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
new file mode 100644
index ..92af88bc8deb
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -0,0 +1,571 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "gt/intel_context.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+
+#include "i915_drv.h"
+#include "i915_gem_context.h"
+#include "i915_gem_execbuffer_common.h"
+#include "i915_gem_ioctls.h"
+#include "i915_gem_vm_bind.h"
+#include "i915_trace.h"
+
+#define __EXEC3_ENGINE_PINNED  BIT_ULL(32)
+#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
+
+/* Catch emission of unexpected errors for CI! */
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+#undef EINVAL
+#define EINVAL ({ \
+   DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \
+   22; \
+})
+#endif
+
+/**
+ * DOC: User command execution with execbuf3 ioctl
+ *
+ * A VM in VM_BIND mode will not support older execbuf mode of binding.
+ * The execbuf ioctl handling in VM_BIND mode differs significantly from the
+ * older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
+ * Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
+ * struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
+ * execlist. Hence, no support for implicit sync.
+ *
+ * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
+ * works with execbuf3 ioctl for submission.
+ *
+ * The execbuf3 ioctl directly specifies the batch addresses instead of as
+ * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
+ * support many of the older features like in/out/submit fences, fence array,
+ * default gem context etc. (See struct drm_i915_gem_execbuffer3).
+ *
+ * In VM_BIND mode, VA allocation is completely managed by the user instead of
+ * the i915 driver. Hence all VA assignment, eviction are not applicable in
+ * VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
+ * be using the i915_vma active reference tracking. It will instead check the
+ * dma-resv object's fence list for that.
+ *
+ * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
+ * vma lookup table, implicit sync, vma active reference tracking etc., are not
+ * applicable for execbuf3 ioctl.
+ */
+
+/**
+ * struct i915_execbuffer - execbuf struct for execbuf3
+ * @i915: reference to the i915 instance we run on
+ * @file: drm file reference
+ * args: execbuf3 ioctl structure
+ * @gt: reference to the gt instance ioctl submitted for
+ * @context: logical state for the request
+ * @gem_context: callers context
+ * @requests: requests to be build
+ * @composite_fence: used for excl fence in dma_resv objects when > 1 BB 
submitted
+ * @ww: i915_gem_ww_ctx instance
+ * @num_batches: number of batches submitted
+ * @batch_addresses: addresses corresponds to the submitted batches
+ * @batches: references to the i915_vmas corresponding to the batches
+ */
+struct i915_execbuffer {
+   struct drm_i915_private *i915;
+   struct drm_file *file;
+   struct drm_i915_gem_execbuffer3 *args;
+
+   struct intel_gt *gt;
+   struct intel_context *context;
+   struct i915_gem_context *gem_context;
+
+   struct i915_request *requests[MAX_ENGINE_INSTANCE + 1];
+   struct dma_fence *composite_fence;
+
+   struct i915_gem_ww_ctx ww;
+
+   unsigned int num_batches;
+   u64

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

2022-09-29 Thread Thomas Zimmermann

Hi Dave and Daniel,

this is the PR for drm-misc-fixes for this week.

Best regards
Thomas

drm-misc-fixes-2022-09-29:
Short summary of fixes pull:

 * bridge/analogix: Revert earlier suspend fix
 * bridge/lt8912b: Fix corrupt display output
The following changes since commit d8a79c03054911c375a2252627a429c9bc4615b6:

  drm/hisilicon: Add depends on MMU (2022-09-20 11:15:09 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2022-09-29

for you to fetch changes up to cc62d98bd56d45de4531844ca23913a15136c05b:

  Revert "drm: bridge: analogix/dp: add panel prepare/unprepare in 
suspend/resume time" (2022-09-23 07:15:18 -0700)


Short summary of fixes pull:

 * bridge/analogix: Revert earlier suspend fix
 * bridge/lt8912b: Fix corrupt display output


Brian Norris (1):
  Revert "drm: bridge: analogix/dp: add panel prepare/unprepare in 
suspend/resume time"

Francesco Dolcini (1):
  drm/bridge: lt8912b: fix corrupted image output

Philippe Schenker (2):
  drm/bridge: lt8912b: add vsync hsync
  drm/bridge: lt8912b: set hdmi or dvi mode

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 13 -
 drivers/gpu/drm/bridge/lontium-lt8912b.c   | 13 +++--
 2 files changed, 11 insertions(+), 15 deletions(-)

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer

Re: [Intel-gfx] [PATCH 06/16] drm/i915/vm_bind: Support for VM private BOs

2022-09-29 Thread Niranjana Vishwanathapura


On Wed, Sep 28, 2022 at 06:54:27PM +0100, Matthew Auld wrote:

On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:

Each VM creates a root_obj and shares it with all of its private objects
to use it as dma_resv object. This has a performance advantage as it
requires a single dma_resv object update for all private BOs vs list of
dma_resv objects update for shared BOs, in the execbuf path.

VM private BOs can be only mapped on specified VM and cannot be dmabuf
exported. Also, they are supported only in vm_bind mode.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gem/i915_gem_create.c| 41 ++-
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c|  6 +++
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  4 ++
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  3 ++
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  3 ++
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  3 ++
 .../drm/i915/gem/i915_gem_vm_bind_object.c|  9 
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  4 ++
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  2 +
 drivers/gpu/drm/i915/i915_vma.c   |  1 +
 drivers/gpu/drm/i915/i915_vma_types.h |  2 +
 include/uapi/drm/i915_drm.h   | 30 ++
 12 files changed, 106 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 4aa7b5582b8e..692d95ef5d3e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -11,6 +11,7 @@
 #include "pxp/intel_pxp.h"
 #include "i915_drv.h"
+#include "i915_gem_context.h"
 #include "i915_gem_create.h"
 #include "i915_trace.h"
 #include "i915_user_extensions.h"
@@ -252,6 +253,7 @@ struct create_ext {
unsigned int n_placements;
unsigned int placement_mask;
unsigned long flags;
+   u32 vm_id;
 };
 static void repr_placements(char *buf, size_t size,
@@ -401,9 +403,24 @@ static int ext_set_protected(struct i915_user_extension 
__user *base, void *data
return 0;
 }
+static int ext_set_vm_private(struct i915_user_extension __user *base,
+ void *data)
+{
+   struct drm_i915_gem_create_ext_vm_private ext;
+   struct create_ext *ext_data = data;
+
+   if (copy_from_user(, base, sizeof(ext)))
+   return -EFAULT;
+
+   ext_data->vm_id = ext.vm_id;
+
+   return 0;
+}
+
 static const i915_user_extension_fn create_extensions[] = {
[I915_GEM_CREATE_EXT_MEMORY_REGIONS] = ext_set_placements,
[I915_GEM_CREATE_EXT_PROTECTED_CONTENT] = ext_set_protected,
+   [I915_GEM_CREATE_EXT_VM_PRIVATE] = ext_set_vm_private,
 };
 /**
@@ -419,6 +436,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_gem_create_ext *args = data;
struct create_ext ext_data = { .i915 = i915 };
+   struct i915_address_space *vm = NULL;
struct drm_i915_gem_object *obj;
int ret;
@@ -432,6 +450,12 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
if (ret)
return ret;
+   if (ext_data.vm_id) {
+   vm = i915_gem_vm_lookup(file->driver_priv, ext_data.vm_id);
+   if (unlikely(!vm))
+   return -ENOENT;
+   }
+
if (!ext_data.n_placements) {
ext_data.placements[0] =
intel_memory_region_by_type(i915, INTEL_MEMORY_SYSTEM);
@@ -458,8 +482,21 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
ext_data.placements,
ext_data.n_placements,
ext_data.flags);
-   if (IS_ERR(obj))
-   return PTR_ERR(obj);
+   if (IS_ERR(obj)) {
+   ret = PTR_ERR(obj);
+   goto vm_put;
+   }
+
+   if (vm) {
+   obj->base.resv = vm->root_obj->base.resv;
+   obj->priv_root = i915_gem_object_get(vm->root_obj);
+   i915_vm_put(vm);
+   }
return i915_gem_publish(obj, file, >size, >handle);
+vm_put:
+   if (vm)
+   i915_vm_put(vm);
+
+   return ret;
 }
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index f5062d0c6333..6433173c3e84 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -218,6 +218,12 @@ struct dma_buf *i915_gem_prime_export(struct 
drm_gem_object *gem_obj, int flags)
struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+   if (obj->priv_root) {
+   drm_dbg(obj->base.dev,
+   "Exporting VM private objects is not allowed\n");
+   return ERR_PTR(-EINVAL);
+

Re: [Intel-gfx] [PATCH] drm/i915/guc: do not capture error state on exiting context

2022-09-29 Thread Ceraolo Spurio, Daniele





On 9/29/2022 3:40 AM, Tvrtko Ursulin wrote:


On 29/09/2022 10:49, Andrzej Hajda wrote:

On 29.09.2022 10:22, Tvrtko Ursulin wrote:

On 28/09/2022 19:27, John Harrison wrote:

On 9/28/2022 00:19, Tvrtko Ursulin wrote:

On 27/09/2022 22:36, Ceraolo Spurio, Daniele wrote:

On 9/27/2022 12:45 AM, Tvrtko Ursulin wrote:

On 27/09/2022 07:49, Andrzej Hajda wrote:

On 27.09.2022 01:34, Ceraolo Spurio, Daniele wrote:

On 9/26/2022 3:44 PM, Andi Shyti wrote:

Hi Andrzej,

On Mon, Sep 26, 2022 at 11:54:09PM +0200, Andrzej Hajda wrote:
Capturing error state is time consuming (up to 350ms on 
DG2), so it should
be avoided if possible. Context reset triggered by context 
removal is a

good example.
With this patch multiple igt tests will not timeout and 
should run faster.


Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1551
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3952
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5891
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6268
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6281
Signed-off-by: Andrzej Hajda 

fine for me:

Reviewed-by: Andi Shyti 

Just to be on the safe side, can we also have the ack from 
any of

the GuC folks? Daniele, John?

Andi



---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c

index 22ba66e48a9b01..cb58029208afe1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4425,7 +4425,8 @@ static void 
guc_handle_context_reset(struct intel_guc *guc,

  trace_intel_context_reset(ce);
    if (likely(!intel_context_is_banned(ce))) {
-    capture_error_state(guc, ce);
+    if (!intel_context_is_exiting(ce))
+    capture_error_state(guc, ce);


I am not sure here - if we have a persistent context which 
caused a GPU hang I'd expect we'd still want error capture.


What causes the reset in the affected IGTs? Always preemption 
timeout?



guc_context_replay(ce);


You definitely don't want to replay requests of a context that 
is going away.


My intention was to just avoid error capture, but that's even 
better, only condition change:

-        if (likely(!intel_context_is_banned(ce))) {
+       if (likely(intel_context_is_schedulable(ce)))  {


Yes that helper was intended to be used for contexts which 
should not be scheduled post exit or ban.


Daniele - you say there are some misses in the GuC backend. 
Should most, or even all in intel_guc_submission.c be converted 
to use intel_context_is_schedulable? My idea indeed was that 
"ban" should be a level up from the backends. Backend should 
only distinguish between "should I run this or not", and not the 
reason.


I think that all of them should be updated, but I'd like Matt B 
to confirm as he's more familiar with the code than me.


Right, that sounds plausible to me as well.

One thing I forgot to mention - the only place where backend can 
care between "schedulable" and "banned" is when it picks the 
preempt timeout for non-schedulable contexts. This is to only 
apply the strict 1ms to banned (so bad or naught contexts), while 
the ones which are exiting cleanly get the full preempt timeout as 
otherwise configured. This solves the ugly user experience quirk 
where GPU resets/errors were logged upon exit/Ctrl-C of a well 
behaving application (using non-persistent contexts). Hopefully 
GuC can match that behaviour so customers stay happy.


Regards,

Tvrtko


The whole revoke vs ban thing seems broken to me.

First of all, if the user hits Ctrl+C we need to kill the context 
off immediately. That is a fundamental customer requirement. Render 
and compute engines have a 7.5s pre-emption timeout. The user 
should not have to wait 7.5s for a context to be removed from the 
system when they have explicitly killed it themselves. Even the 
regular timeout of 640ms is borderline a long time to wait. And 
note that there is an ongoing request/requirement to increase that 
to 1900ms.


Under what circumstances would a user expect anything sensible to 
happen after a Ctrl+C in terms of things finishing their rendering 
and display nice pretty images? They killed the app. They want it 
dead. We should be getting it off the hardware as quickly as 
possible. If you are really concerned about resets causing 
collateral damage then maybe bump the termination timeout from 1ms 
up to 10ms, maybe at most 100ms. If an app is 'well behaved' then 
it should cleanly exit within 10ms. But if it is bad (which is 
almost certainly the case if the user is manually and explicitly 
killing it) then it needs to be killed because it is not going to 
gracefully exit.


Right.. I had it like that initially (lower timeout - I think 20ms 
or so, patch history on the mailing list would know for sure),

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

2022-09-29 Thread Tvrtko Ursulin

Hi Dave, Daniel,

A few fixes for the upcoming merge window. Not many but most are pretty
important.

Another rather important one is missing due being too conflicty, but will
arrive via drm-intel-fixes (7738be973fc4 ("drm/i915/gt: Perf_limit_reasons
are only available for Gen11+")).

Regards,

Tvrtko

drm-intel-next-fixes-2022-09-29:
- Fix release build bug in 'remove GuC log size module parameters' (John 
Harrison)
- Remove ipc_enabled from struct drm_i915_private (Jani Nikula)
- Do not cleanup obj with NULL bo->resource (Nirmoy Das)
- Fix device info for devices without display (Jani Nikula)
- Force DPLL calculation for TC ports after readout (Ville Syrjälä)
- Use i915_vm_put on ppgtt_create error paths (Chris Wilson)
The following changes since commit 320305923c88258ce50c75bf721e9bf2e420ab27:

  Merge tag 'du-next-20220907' of git://linuxtv.org/pinchartl/media into 
drm-next (2022-09-23 03:52:08 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2022-09-29

for you to fetch changes up to 20e377e7b2e7c327039f10db80ba5bcc1f6c882d:

  drm/i915/gt: Use i915_vm_put on ppgtt_create error paths (2022-09-27 11:05:33 
+0100)


- Fix release build bug in 'remove GuC log size module parameters' (John 
Harrison)
- Remove ipc_enabled from struct drm_i915_private (Jani Nikula)
- Do not cleanup obj with NULL bo->resource (Nirmoy Das)
- Fix device info for devices without display (Jani Nikula)
- Force DPLL calculation for TC ports after readout (Ville Syrjälä)
- Use i915_vm_put on ppgtt_create error paths (Chris Wilson)


Chris Wilson (1):
  drm/i915/gt: Use i915_vm_put on ppgtt_create error paths

Jani Nikula (2):
  drm/i915/display: remove ipc_enabled from struct drm_i915_private
  drm/i915: fix device info for devices without display

John Harrison (1):
  drm/i915/guc: Fix release build bug in 'remove log size module parameters'

Nirmoy Das (1):
  drm/i915: Do not cleanup obj with NULL bo->resource

Ville Syrjälä (1):
  drm/i915: Force DPLL calculation for TC ports after readout

 drivers/gpu/drm/i915/display/intel_ddi.c   | 18 --
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c|  2 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c   | 16 -
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c   | 58 +++---
 drivers/gpu/drm/i915/gt/intel_gtt.c|  3 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 25 +
 drivers/gpu/drm/i915/i915_drv.h|  2 --
 drivers/gpu/drm/i915/i915_pci.c| 11 +++---
 drivers/gpu/drm/i915/intel_device_info.c   |  6 
 9 files changed, 70 insertions(+), 71 deletions(-)

Re: [Intel-gfx] [PATCH 05/16] drm/i915/vm_bind: Implement bind and unbind of object

2022-09-29 Thread Niranjana Vishwanathapura


On Thu, Sep 29, 2022 at 11:51:51AM +0100, Matthew Auld wrote:

On 29/09/2022 10:03, Matthew Auld wrote:

On 29/09/2022 06:24, Niranjana Vishwanathapura wrote:

On Wed, Sep 28, 2022 at 06:52:21PM +0100, Matthew Auld wrote:

On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:

Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.

The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be supported only in the newer execbuf3 ioctl.

Signed-off-by: Niranjana Vishwanathapura 


Signed-off-by: Prathap Kumar Valsan 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c    |   5 +
 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |  26 ++
 .../drm/i915/gem/i915_gem_vm_bind_object.c    | 306 ++
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  10 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  17 +
 drivers/gpu/drm/i915/i915_driver.c    |   3 +
 drivers/gpu/drm/i915/i915_vma.c   |   1 +
 drivers/gpu/drm/i915/i915_vma_types.h |  14 +
 include/uapi/drm/i915_drm.h   | 112 +++
 10 files changed, 495 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

diff --git a/drivers/gpu/drm/i915/Makefile 
b/drivers/gpu/drm/i915/Makefile

index a26edcdadc21..9bf939ef18ea 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -166,6 +166,7 @@ gem-y += \
 gem/i915_gem_ttm_move.o \
 gem/i915_gem_ttm_pm.o \
 gem/i915_gem_userptr.o \
+    gem/i915_gem_vm_bind_object.o \
 gem/i915_gem_wait.o \
 gem/i915_gemfs.o
 i915-y += \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c

index cd75b0ca2555..f85f10cf9c34 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -781,6 +781,11 @@ static int eb_select_context(struct 
i915_execbuffer *eb)

 if (unlikely(IS_ERR(ctx)))
 return PTR_ERR(ctx);
+    if (ctx->vm->vm_bind_mode) {
+    i915_gem_context_put(ctx);
+    return -EOPNOTSUPP;
+    }
+
 eb->gem_context = ctx;
 if (i915_gem_context_has_full_ppgtt(ctx))
 eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h

new file mode 100644
index ..36262a6357b5
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __I915_GEM_VM_BIND_H
+#define __I915_GEM_VM_BIND_H
+
+#include 
+
+struct drm_device;
+struct drm_file;
+struct i915_address_space;
+struct i915_vma;
+
+struct i915_vma *
+i915_gem_vm_bind_lookup_vma(struct i915_address_space *vm, u64 va);
+
+int i915_gem_vm_bind_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *file);
+int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file);
+
+void i915_gem_vm_unbind_all(struct i915_address_space *vm);
+
+#endif /* __I915_GEM_VM_BIND_H */
diff --git 
a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

new file mode 100644
index ..e529162abd2c
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+
+#include 
+
+#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_vm_bind.h"
+
+#include "gt/intel_gpu_commands.h"
+
+#define START(node) ((node)->start)
+#define LAST(node) ((node)->last)
+
+INTERVAL_TREE_DEFINE(struct i915_vma, rb, u64, __subtree_last,
+ START, LAST, static inline, i915_vm_bind_it)
+
+#undef START
+#undef LAST
+
+/**
+ * DOC: VM_BIND/UNBIND ioctls
+ *
+ * DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to 
bind/unbind GEM buffer
+ * objects (BOs) or sections of a BOs at specified GPU 
virtual addresses on a
+ * specified address space (VM). Multiple mappings can map to 
the same physical
+ * pages of an object (aliasing). These mappings (also 
referred to as persistent
+ * mappings) will be persistent across multiple GPU 
submissions (execbuf calls)
+ * issued by the UMD, without user having to provide a list 
of all required
+ * mappings during each submission (as required by older 
execbuf mode).

+ *
+ * The VM_BIND/UNBIND calls allow UMDs to request a timeline 
out fence for

+ * signaling the completion of bind/unbind operation.
+ *
+ * VM_BIND feature is advertised to user via 
I915_PARAM_VM_BIND_VERSION.
+ * User has to opt-in for VM_BIND mode of binding for an 
address space (VM)
+ * during VM creation time via 
I915_VM_CREATE_FLAGS_USE_VM_BIND extension.

+ *
+ * VM_BIND/UNBIND

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Reject excessive dotclocks early (rev2)

2022-09-29 Thread Patchwork

== Series Details ==

Series: drm/i915: Reject excessive dotclocks early (rev2)
URL   : https://patchwork.freedesktop.org/series/109141/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_109141v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 11)
--

  Additional (2): shard-dg1 shard-tglu 
  Missing(1): shard-rkl 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * {igt@gem_mmap_offset@ptrace@lmem0-fixed} (NEW):
- {shard-dg1}:NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109141v2/shard-dg1-17/igt@gem_mmap_offset@ptr...@lmem0-fixed.html

  
New tests
-

  New tests have been introduced between CI_DRM_12193_full and 
Patchwork_109141v2_full:

### New IGT tests (42) ###

  * igt@gem_mmap_offset@ptrace@lmem0-fixed:
- Statuses : 1 fail(s)
- Exec time: [0.02] s

  * igt@gem_mmap_offset@ptrace@smem0-fixed:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_color@legacy-gamma-reset@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.41] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.25] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.23] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.24] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@empty_lease@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * igt@kms_lease@empty_lease@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@empty_lease@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@empty_lease@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@lease_invalid_connector@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * igt@kms_lease@lease_invalid_connector@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_connector@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_connector@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@lease_invalid_crtc@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_revoke@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.26] s

  * igt@kms_lease@lease_revoke@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.11] s

  * igt@kms_lease@lease_revoke@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.10] s

  * igt@kms_lease@lease_revoke@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.11] s

  * igt@kms_lease@lessee_list@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * igt@kms_lease@lessee_list@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lessee_list@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@lessee_list@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@page_flip_implicit_plane@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.34] s

  * igt@kms_lease@page_flip_implicit_plane@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.16] s

  * igt@kms_lease@page_flip_implicit_plane@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.17] s

  * igt@kms_lease@page_flip_implicit_plane@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.16] s

  * igt@kms_lease@simple_lease@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.47] s

  * igt@kms_lease@simple_lease@pipe-b-hdmi-a-4:
- Statuses :

Re: [Intel-gfx] [PATCH] drm/i915/gt: Flush to global observation point before breadcrumb write

2022-09-29 Thread Andi Shyti

Hi Nirmoy,

> From: Prathap Kumar Valsan 
> 
> Add flag to pipecontrol instruction to ensure in-flight writes are
> flushed to global observation point. Also split the pipecontrol
> instruction like we have in gen8.
> 
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/5886
> Signed-off-by: Prathap Kumar Valsan 
> Signed-off-by: Nirmoy Das 

pushed in drm-intel-gt-next.

Thanks,
Andi

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

2022-09-29 Thread Mika Kahola

From: Radhakrishna Sripada 

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

Bspec: 65449

Cc: Imre Deak 
Cc: Mika Kahola 
Cc: Uma Shankar 
Signed-off-by: Clint Taylor 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 157 +++---
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  |   8 +
 drivers/gpu/drm/i915/display/intel_ddi.c  |   4 +-
 .../drm/i915/display/intel_ddi_buf_trans.c|  36 +++-
 .../drm/i915/display/intel_ddi_buf_trans.h|   6 +
 .../i915/display/intel_display_power_map.c|   1 +
 drivers/gpu/drm/i915/i915_reg.h   |   1 +
 7 files changed, 187 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index a08788d2a3bc..bba3c4579cfa 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -4,12 +4,24 @@
  */
 
 #include "intel_cx0_phy.h"
+#include "intel_ddi.h"
+#include "intel_ddi_buf_trans.h"
 #include "intel_de.h"
 #include "intel_display_types.h"
 #include "intel_dp.h"
 #include "intel_panel.h"
+#include "intel_psr.h"
 #include "intel_uncore.h"
 
+static void
+assert_dc_off(struct drm_i915_private *i915)
+{
+   bool enabled;
+
+   enabled = intel_display_power_is_enabled(i915, POWER_DOMAIN_DC_OFF);
+   drm_WARN_ON(>drm, !enabled);
+}
+
 static void intel_cx0_bus_reset(struct drm_i915_private *i915, enum port port, 
int lane)
 {
enum phy phy = intel_port_to_phy(i915, port);
@@ -37,6 +49,8 @@ static u8 intel_cx0_read(struct drm_i915_private *i915, enum 
port port,
u32 val = 0;
int attempts = 0;
 
+   assert_dc_off(i915);
+
 retry:
if (attempts == 3) {
drm_err_once(>drm, "PHY %c Read %04x failed after %d 
retries. Status: 0x%x\n", phy_name(phy), addr, attempts, val ?: 0);
@@ -126,6 +140,8 @@ static void __intel_cx0_write(struct drm_i915_private 
*i915, enum port port,
enum phy phy = intel_port_to_phy(i915, port);
int attempts = 0;
 
+   assert_dc_off(i915);
+
 retry:
if (attempts == 3) {
drm_err_once(>drm, "PHY %c Write %04x failed after %d 
retries.\n", phy_name(phy), addr, attempts);
@@ -204,6 +220,76 @@ static void intel_cx0_rmw(struct drm_i915_private *i915, 
enum port port,
}
 }
 
+/*
+ * Prepare HW for CX0 phy transactions.
+ *
+ * It is required that PSR and DC5/6 are disabled before any CX0 message
+ * bus transaction is executed.
+ */
+static intel_wakeref_t intel_cx0_phy_transaction_begin(struct intel_encoder 
*encoder)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+   intel_psr_pause(intel_dp);
+   return intel_display_power_get(i915, POWER_DOMAIN_DC_OFF);
+}
+
+static void intel_cx0_phy_transaction_end(struct intel_encoder *encoder, 
intel_wakeref_t wakeref)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+   intel_psr_resume(intel_dp);
+   intel_display_power_put(i915, POWER_DOMAIN_DC_OFF, wakeref);
+}
+
+void intel_cx0_phy_set_signal_levels(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+   bool lane_reversal = dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
+   enum intel_cx0_lanes master_lane = lane_reversal ? INTEL_CX0_LANE1 :
+INTEL_CX0_LANE0;
+   const struct intel_ddi_buf_trans *trans;
+   intel_wakeref_t wakeref;
+   int n_entries, ln;
+
+   wakeref = intel_cx0_phy_transaction_begin(encoder);
+
+   trans = encoder->get_buf_trans(encoder, crtc_state, _entries);
+   if (drm_WARN_ON_ONCE(>drm, !trans))
+   return;
+
+   intel_cx0_rmw(i915, encoder->port, INTEL_CX0_BOTH_LANES, 
PHY_C10_VDR_CONTROL(1),
+ 0, C10_VDR_CTRL_MSGBUS_ACCESS, MB_WRITE_COMMITTED);
+
+   for (ln = 0; ln < 4; ln++) {
+   int level = intel_ddi_level(encoder, crtc_state, ln);
+   int lane, tx;
+
+   lane = ln / 2;
+   tx = ln % 2 + 1;
+
+   intel_cx0_rmw(i915, encoder->port, lane, PHY_CX0_TX_CONTROL(tx, 
2),
+ C10_PHY_VSWING_PREEMPH_MASK,
+ 
C10_PHY_VSWING_PREEMPH(trans->entries[level].direct.preemph),
+ MB_WRITE_COMMITTED);
+   intel_cx0_rmw(i915, encoder->port, lane, PHY_CX0_TX_CONTROL(tx, 
8),
+ C10_PHY_VSWING_LEVEL_MASK,
+ 
C10_PHY_VSWING_LEVEL(trans->entries[level].direct.level),
+

[Intel-gfx] [PATCH 1/5] drm/i915/mtl: Add Support for C10, C20 PHY Message Bus

2022-09-29 Thread Mika Kahola

From: Radhakrishna Sripada 

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

Bspec: 64599, 65100, 65101, 67610, 67636

Cc: Mika Kahola 
Cc: Imre Deak 
Cc: Uma Shankar 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Mika Kahola  (v4)
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 179 +++
 1 file changed, 179 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.c

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
new file mode 100644
index ..7930b0255cfa
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -0,0 +1,179 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include "intel_de.h"
+#include "intel_uncore.h"
+
+static void intel_cx0_bus_reset(struct drm_i915_private *i915, enum port port, 
int lane)
+{
+   enum phy phy = intel_port_to_phy(i915, port);
+
+   /* Bring the phy to idle. */
+   intel_de_write(i915, XELPDP_PORT_M2P_MSGBUS_CTL(port, lane),
+  XELPDP_PORT_M2P_TRANSACTION_RESET);
+
+   /* Wait for Idle Clear. */
+   if (intel_de_wait_for_clear(i915, XELPDP_PORT_M2P_MSGBUS_CTL(port, 
lane),
+   XELPDP_PORT_M2P_TRANSACTION_RESET,
+   XELPDP_MSGBUS_TIMEOUT_SLOW)) {
+   drm_err_once(>drm, "Failed to bring PHY %c to idle. \n", 
phy_name(phy));
+   return;
+   }
+
+   intel_de_write(i915, XELPDP_PORT_P2M_MSGBUS_STATUS(port, lane), ~0);
+   return;
+}
+
+__maybe_unused static u8 intel_cx0_read(struct drm_i915_private *i915, enum 
port port,
+int lane, u16 addr)
+{
+   enum phy phy = intel_port_to_phy(i915, port);
+   u32 val = 0;
+   int attempts = 0;
+
+retry:
+   if (attempts == 3) {
+   drm_err_once(>drm, "PHY %c Read %04x failed after %d 
retries. Status: 0x%x\n", phy_name(phy), addr, attempts, val ?: 0);
+   return 0;
+   }
+
+   /* Wait for pending transactions.*/
+   if (intel_de_wait_for_clear(i915, XELPDP_PORT_M2P_MSGBUS_CTL(port, 
lane),
+   XELPDP_PORT_M2P_TRANSACTION_PENDING,
+   XELPDP_MSGBUS_TIMEOUT_SLOW)) {
+   drm_dbg(>drm, "PHY %c Timeout waiting for previous 
transaction to complete. Reset the bus and retry.\n", phy_name(phy));
+   attempts++;
+   intel_cx0_bus_reset(i915, port, lane);
+   goto retry;
+   }
+
+   /* Issue the read command. */
+   intel_de_write(i915, XELPDP_PORT_M2P_MSGBUS_CTL(port, lane),
+  XELPDP_PORT_M2P_TRANSACTION_PENDING |
+  XELPDP_PORT_M2P_COMMAND_READ |
+  XELPDP_PORT_M2P_ADDRESS(addr));
+
+   /* Wait for response ready. And read response.*/
+   if (__intel_wait_for_register(>uncore,
+ XELPDP_PORT_P2M_MSGBUS_STATUS(port, lane),
+ XELPDP_PORT_P2M_RESPONSE_READY,
+ XELPDP_PORT_P2M_RESPONSE_READY,
+ XELPDP_MSGBUS_TIMEOUT_FAST_US,
+ XELPDP_MSGBUS_TIMEOUT_SLOW, )) {
+   drm_dbg(>drm, "PHY %c Timeout waiting for Read response 
ACK. Status: 0x%x\n", phy_name(phy), val);
+   attempts++;
+   intel_cx0_bus_reset(i915, port, lane);
+   goto retry;
+   }
+
+   /* Check for error. */
+   if (val & XELPDP_PORT_P2M_ERROR_SET) {
+   drm_dbg(>drm, "PHY %c Error occurred during read command. 
Status: 0x%x\n", phy_name(phy), val);
+   attempts++;
+   intel_cx0_bus_reset(i915, port, lane);
+   goto retry;
+   }
+
+   /* Check for Read Ack. */
+   if (REG_FIELD_GET(XELPDP_PORT_P2M_COMMAND_TYPE_MASK, val) !=
+   XELPDP_PORT_P2M_COMMAND_READ_ACK) {
+   drm_dbg(>drm, "PHY %c Not a Read response. MSGBUS Status: 
0x%x.\n", phy_name(phy), val);
+   attempts++;
+   intel_cx0_bus_reset(i915, port, lane);
+   goto retry;
+   }
+
+   /* Clear Response Ready flag.*/
+   intel_de_write(i915, XELPDP_PORT_P2M_MSGBUS_STATUS(port, lane), ~0);
+   return (u8)REG_FIELD_GET(XELPDP_PORT_P2M_DATA_MASK, val);
+}
+
+static int intel_cx0_wait_cwrite_ack(struct drm_i915_private *i915,
+ enum port port, int lane)
+{
+   enum phy phy = intel_port_to_phy(i915, port);
+   u32 val;
+
+   /* Check for write ack. */
+   if (__intel_wait_for_register(>uncore,
+ XELPDP_PORT_P2M_MSGBUS_STATUS(port, lane),
+

[Intel-gfx] [PATCH 4/5] drm/i915/mtl: Add C10 phy programming for HDMI

2022-09-29 Thread Mika Kahola

From: Radhakrishna Sripada 

Like DG2, we still don't have a proper algorithm that can be used
for calculating PHY settings, but we do have tables of register
values for a handful of the more common link rates. Some support is
better than none, so let's go ahead and add/use these tables when we
can, and also add some logic to hdmi_port_clock_valid() to filter the
modelist to just the modes we can actually support with these link
rates.

Hopefully we'll have a proper / non-encumbered algorithm to calculate
these registers by the time we upstream and we'll be able to replace
this patch with something more general purpose.

Bspec: 64568

Cc: Imre Deak 
Cc: Mika Kahola 
Cc: Uma Shankar 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 168 ++-
 drivers/gpu/drm/i915/display/intel_cx0_phy.h |   2 +
 drivers/gpu/drm/i915/display/intel_hdmi.c|   5 +-
 3 files changed, 170 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 6ba11cd7cd75..a08788d2a3bc 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -448,6 +448,152 @@ static const struct intel_c10mpllb_state * const 
mtl_c10_edp_tables[] = {
NULL,
 };
 
+/*
+ * HDMI link rates with 38.4 MHz reference clock.
+ */
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_25_175 = {
+   .clock = 25175,
+   .pll[0] = 0x4,
+   .pll[1] = 0,
+   .pll[2] = 0xB2,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0xD,
+   .pll[16] = 0x6,
+   .pll[17] = 0x8F,
+   .pll[18] = 0x84,
+   .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_27_0 = {
+   .clock = 27000,
+   .pll[0] = 0x34,
+   .pll[1] = 0,
+   .pll[2] = 0xC0,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0x80,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0xD,
+   .pll[16] = 0x6,
+   .pll[17] = 0xCF,
+   .pll[18] = 0x84,
+   .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_74_25 = {
+   .clock = 74250,
+   .pll[0] = 0xF4,
+   .pll[1] = 0,
+   .pll[2] = 0x7A,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0x58,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0xB,
+   .pll[16] = 0x6,
+   .pll[17] = 0xF,
+   .pll[18] = 0x85,
+   .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_148_5 = {
+   .clock = 148500,
+   .pll[0] = 0xF4,
+   .pll[1] = 0,
+   .pll[2] = 0x7A,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0x58,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0xA,
+   .pll[16] = 0x6,
+   .pll[17] = 0xF,
+   .pll[18] = 0x85,
+   .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_594 = {
+   .clock = 594000,
+   .pll[0] = 0xF4,
+   .pll[1] = 0,
+   .pll[2] = 0x7A,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0x58,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0x8,
+   .pll[16] = 0x6,
+   .pll[17] = 0xF,
+   .pll[18] = 0x85,
+   .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state * const mtl_c10_hdmi_tables[] = {
+   _c10_hdmi_25_175,
+   _c10_hdmi_27_0,
+   _c10_hdmi_74_25,
+   _c10_hdmi_148_5,
+   _c10_hdmi_594,
+   NULL,
+};
+
+int intel_c10_phy_check_hdmi_link_rate(int clock)
+{
+   const struct intel_c10mpllb_state * const *tables = mtl_c10_hdmi_tables;
+   int i;
+
+   for (i = 0; tables[i]; i++) {
+   if (clock == tables[i]->clock)
+   return MODE_OK;
+   }
+
+   return MODE_CLOCK_RANGE;
+}
+
 static const struct intel_c10mpllb_state * const *
 intel_c10_mpllb_tables_get(struct intel_crtc_state *crtc_state,
   struct intel_encoder *encoder)
@@ -457,9 +603,10 @@ intel_c10_mpllb_tables_get(struct intel_crtc_state 
*crtc_state,
return

[Intel-gfx] [PATCH 2/5] drm/i915/mtl: Add PLL programming support for C10 phy

2022-09-29 Thread Mika Kahola

From: Radhakrishna Sripada 

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

Bspec: 64568, 64539, 67636

Cc: Mika Kahola 
Cc: Imre Deak 
Cc: Uma Shankar 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 516 +-
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  | 128 +
 drivers/gpu/drm/i915/display/intel_ddi.c  |  20 +-
 drivers/gpu/drm/i915/display/intel_display.c  |   1 +
 .../drm/i915/display/intel_display_power.c|   3 +-
 .../i915/display/intel_display_power_well.c   |   2 +-
 .../drm/i915/display/intel_display_types.h|   6 +
 drivers/gpu/drm/i915/display/intel_dpll.c |  20 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c |   2 +-
 .../drm/i915/display/intel_modeset_verify.c   |   2 +
 10 files changed, 690 insertions(+), 10 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.h

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 7930b0255cfa..2f401116d1d0 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -3,7 +3,11 @@
  * Copyright © 2021 Intel Corporation
  */
 
+#include "intel_cx0_phy.h"
 #include "intel_de.h"
+#include "intel_display_types.h"
+#include "intel_dp.h"
+#include "intel_panel.h"
 #include "intel_uncore.h"
 
 static void intel_cx0_bus_reset(struct drm_i915_private *i915, enum port port, 
int lane)
@@ -26,7 +30,7 @@ static void intel_cx0_bus_reset(struct drm_i915_private 
*i915, enum port port, i
return;
 }
 
-__maybe_unused static u8 intel_cx0_read(struct drm_i915_private *i915, enum 
port port,
+static u8 intel_cx0_read(struct drm_i915_private *i915, enum port port,
 int lane, u16 addr)
 {
enum phy phy = intel_port_to_phy(i915, port);
@@ -116,8 +120,8 @@ static int intel_cx0_wait_cwrite_ack(struct 
drm_i915_private *i915,
return 0;
 }
 
-__maybe_unused static void intel_cx0_write(struct drm_i915_private *i915, enum 
port port,
-   int lane, u16 addr, u8 data, bool committed)
+static void __intel_cx0_write(struct drm_i915_private *i915, enum port port,
+ int lane, u16 addr, u8 data, bool committed)
 {
enum phy phy = intel_port_to_phy(i915, port);
int attempts = 0;
@@ -166,8 +170,19 @@ __maybe_unused static void intel_cx0_write(struct 
drm_i915_private *i915, enum p
return;
 }
 
-__maybe_unused static void intel_cx0_rmw(struct drm_i915_private *i915, enum 
port port,
- int lane, u16 addr, u8 clear, u8 set, bool committed)
+static void intel_cx0_write(struct drm_i915_private *i915, enum port port,
+   int lane, u16 addr, u8 data, bool committed)
+{
+   if (lane == INTEL_CX0_BOTH_LANES) {
+   __intel_cx0_write(i915, port, INTEL_CX0_LANE0, addr, data, 
committed);
+   __intel_cx0_write(i915, port, INTEL_CX0_LANE1, addr, data, 
committed);
+   } else {
+   __intel_cx0_write(i915, port, lane, addr, data, committed);
+   }
+}
+
+static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
+   int lane, u16 addr, u8 clear, u8 set, bool 
committed)
 {
u8 old, val;
 
@@ -177,3 +192,494 @@ __maybe_unused static void intel_cx0_rmw(struct 
drm_i915_private *i915, enum por
if (val != old)
intel_cx0_write(i915, port, lane, addr, val, committed);
 }
+
+static void intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
+ int lane, u16 addr, u8 clear, u8 set, bool committed)
+{
+   if (lane == INTEL_CX0_BOTH_LANES) {
+   __intel_cx0_rmw(i915, port, INTEL_CX0_LANE0, addr, clear, set, 
committed);
+   __intel_cx0_rmw(i915, port, INTEL_CX0_LANE1, addr, clear, set, 
committed);
+   } else {
+   __intel_cx0_rmw(i915, port, lane, addr, clear, set, committed);
+   }
+}
+
+/*
+ * Basic DP link rates with 38.4 MHz reference clock.
+ * Note: The tables below are with SSC. In non-ssc
+ * registers 0xC04 to 0xC08(pll[4] to pll[8]) will be
+ * programmed 0.
+ */
+
+static const struct intel_c10mpllb_state mtl_c10_dp_rbr = {
+   .clock = 162000,
+   .pll[0] = 0xB4,
+   .pll[1] = 0,
+   .pll[2] = 0x30,
+   .pll[3] = 0x1,
+   .pll[4] = 0x26,
+   .pll[5] = 0x0C,
+   .pll[6] = 0x98,
+   .pll[7] = 0x46,
+   .pll[8] = 0x1,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0xC0,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0x2,
+   .pll[16] = 0x84,
+   .pll[17] = 0x4F,

[Intel-gfx] [PATCH 3/5] drm/i915/mtl: Add support for C10 phy programming

2022-09-29 Thread Mika Kahola

From: Radhakrishna Sripada 

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

Bspec: 64539, 67636, 65451, 65450, 64568

Cc: Imre Deak 
Cc: Mika Kahola 
Cc: Uma Shankar 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Mika Kahola  (v9)
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 352 ++-
 drivers/gpu/drm/i915/display/intel_cx0_phy.h |  17 +
 drivers/gpu/drm/i915/display/intel_ddi.c |   2 +
 drivers/gpu/drm/i915/display/intel_dp.c  |  15 +-
 drivers/gpu/drm/i915/display/intel_dpll.c|   2 +
 drivers/gpu/drm/i915/i915_reg.h  | 141 
 7 files changed, 526 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a26edcdadc21..994f87a12782 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -279,6 +279,7 @@ i915-y += \
display/icl_dsi.o \
display/intel_backlight.o \
display/intel_crt.o \
+   display/intel_cx0_phy.o \
display/intel_ddi.o \
display/intel_ddi_buf_trans.o \
display/intel_display_trace.o \
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 2f401116d1d0..6ba11cd7cd75 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -526,9 +526,9 @@ void intel_c10mpllb_readout_hw_state(struct intel_encoder 
*encoder,
 tx0, cmn, phy_name(phy));
 }
 
-__maybe_unused static void intel_c10_pll_program(struct drm_i915_private *i915,
-const struct intel_crtc_state 
*crtc_state,
-struct intel_encoder *encoder)
+static void intel_c10_pll_program(struct drm_i915_private *i915,
+ const struct intel_crtc_state *crtc_state,
+ struct intel_encoder *encoder)
 {
const struct intel_c10mpllb_state *pll_state = 
_state->c10mpllb_state;
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
@@ -633,6 +633,352 @@ int intel_c10mpllb_calc_port_clock(struct intel_encoder 
*encoder,
 10 << (tx_clk_div + 16));
 }
 
+#define PHY_LANES_VAL_ARG(FIELD, lanes, arg)   ({u32 __val; switch(lanes) {\
+ case INTEL_CX0_BOTH_LANES:
\
+   __val = 
((XELPDP_LANE0_##FIELD(arg)) |\
+   
(XELPDP_LANE1_##FIELD(arg))); \
+   break;  
\
+ case INTEL_CX0_LANE0: 
\
+   __val = 
(XELPDP_LANE0_##FIELD(arg));\
+   break;  
\
+ case INTEL_CX0_LANE1: 
\
+   __val = 
(XELPDP_LANE1_##FIELD(arg));\
+   break;  \
+}; __val; })
+
+#define PHY_LANES_VAL(FIELD, lanes)({u32 __val; switch(lanes) {\
+ case INTEL_CX0_BOTH_LANES:
\
+   __val = 
(XELPDP_LANE0_##FIELD | \
+   
XELPDP_LANE1_##FIELD); \
+   break;  
\
+ case INTEL_CX0_LANE0: 
\
+   __val = 
(XELPDP_LANE0_##FIELD);  \
+   break;  
\
+ case INTEL_CX0_LANE1: 
\
+   __val = 
(XELPDP_LANE1_##FIELD);\
+   break;  \
+}; __val; })
+
+static void intel_program_port_clock_ctl(struct intel_encoder *encoder,
+const struct intel_crtc_state 
*crtc_state,
+bool lane_reversal)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_dp *intel_dp;
+   bool ssc_enabled;
+   u32 val = 0;
+
+   intel_de_rmw(i915, XELPDP_PORT_BUF_CTL1(encoder->port), 
XELPDP_PORT_REVERSAL,
+lane_reversal ? XELPDP_PORT_REVERSAL : 0);
+
+   if (lane_reversal)
+   val |=

[Intel-gfx] [PATCH 0/5] drm/i915/mtl: Add C10 phy support

2022-09-29 Thread Mika Kahola

PHY programming support for message bus and phy programming.
Updates for HDMI programming and vswing tables.

Radhakrishna Sripada (5):
  drm/i915/mtl: Add Support for C10,C20 PHY Message Bus
  drm/i915/mtl: Add PLL programming support for C10 phy
  drm/i915/mtl: Add support for C10 phy programming
  drm/i915/mtl: Add C10 phy programming for HDMI
  drm/i915/mtl: Add vswing programming for C10 phys

 drivers/gpu/drm/i915/Makefile |1 +
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 1300 +
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  |  155 ++
 drivers/gpu/drm/i915/display/intel_ddi.c  |   26 +-
 .../drm/i915/display/intel_ddi_buf_trans.c|   36 +-
 .../drm/i915/display/intel_ddi_buf_trans.h|6 +
 drivers/gpu/drm/i915/display/intel_display.c  |1 +
 .../drm/i915/display/intel_display_power.c|3 +-
 .../i915/display/intel_display_power_map.c|1 +
 .../i915/display/intel_display_power_well.c   |2 +-
 .../drm/i915/display/intel_display_types.h|6 +
 drivers/gpu/drm/i915/display/intel_dp.c   |   15 +-
 drivers/gpu/drm/i915/display/intel_dpll.c |   22 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c |2 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |5 +-
 .../drm/i915/display/intel_modeset_verify.c   |2 +
 drivers/gpu/drm/i915/i915_reg.h   |  142 ++
 17 files changed, 1716 insertions(+), 9 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.h

-- 
2.34.1

Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Fix PSR_IMR/IIR field handling

2022-09-29 Thread Souza, Jose

On Thu, 2022-09-29 at 06:16 -0700, José Roberto de Souza wrote:
> On Tue, 2022-09-27 at 14:09 +0300, Jouni Högander wrote:
> > Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for
> > bits in PSR_IMR/IIR registers:
> > 
> > /*
> >  * gen12+ has registers relative to transcoder and one per transcoder
> >  * using the same bit definition: handle it as TRANSCODER_EDP to force
> >  * 0 shift in bit definition
> >  */
> > 
> > At the time of writing the code assumption "TRANSCODER_EDP == 0" was made.
> > This is not the case and all fields in PSR_IMR and PSR_IIR are shifted
> > incorrectly if DISPLAY_VER >= 12.
> > 
> > Fix this by adding separate register field defines for >=12 and add bit
> > getter functions to keep code readability.
> > 
> > v3:
> >  - Add separate register field defines (José)
> >  - Add bit getter functions (José)
> > v2:
> >  - Improve commit message (José)

Also missing the Fixes tag, so this gets backported to stable kernels.

> > 
> > Signed-off-by: Jouni Högander 
> > ---
> >  drivers/gpu/drm/i915/display/intel_psr.c | 84 ++--
> >  drivers/gpu/drm/i915/i915_reg.h  | 16 +++--
> >  2 files changed, 62 insertions(+), 38 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 9def8d9fade6..d7b08a7da9e9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -116,34 +116,56 @@ static bool psr2_global_enabled(struct intel_dp 
> > *intel_dp)
> > }
> >  }
> >  
> > +static u32 psr_irq_psr_error_bit_get(struct intel_dp *intel_dp)
> > +{
> > +   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +
> > +   return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_ERROR :
> > +   EDP_PSR_ERROR(intel_dp->psr.transcoder);
> 
> Drop the "_EDP", just go with TGL_PSR_ERROR... there is no reference to EDP 
> or any transcoder in TGL+ it is one register per transcoder.
> 
> > +}
> > +
> > +static u32 psr_irq_post_exit_bit_get(struct intel_dp *intel_dp)
> > +{
> > +   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +
> > +   return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_POST_EXIT :
> > +   EDP_PSR_POST_EXIT(intel_dp->psr.transcoder);
> > +}
> > +
> > +static u32 psr_irq_pre_entry_bit_get(struct intel_dp *intel_dp)
> > +{
> > +   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +
> > +   return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_PRE_ENTRY :
> > +   EDP_PSR_PRE_ENTRY(intel_dp->psr.transcoder);
> > +}
> > +
> > +static u32 psr_irq_mask_get(struct intel_dp *intel_dp)
> > +{
> > +   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +
> > +   return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_MASK :
> > +   EDP_PSR_MASK(intel_dp->psr.transcoder);
> > +}
> > +
> >  static void psr_irq_control(struct intel_dp *intel_dp)
> >  {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > -   enum transcoder trans_shift;
> > i915_reg_t imr_reg;
> > u32 mask, val;
> >  
> > -   /*
> > -* gen12+ has registers relative to transcoder and one per transcoder
> > -* using the same bit definition: handle it as TRANSCODER_EDP to force
> > -* 0 shift in bit definition
> > -*/
> > -   if (DISPLAY_VER(dev_priv) >= 12) {
> > -   trans_shift = 0;
> > +   if (DISPLAY_VER(dev_priv) >= 12)
> > imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
> > -   } else {
> > -   trans_shift = intel_dp->psr.transcoder;
> > +   else
> > imr_reg = EDP_PSR_IMR;
> > -   }
> >  
> > -   mask = EDP_PSR_ERROR(trans_shift);
> > +   mask = psr_irq_psr_error_bit_get(intel_dp);
> > if (intel_dp->psr.debug & I915_PSR_DEBUG_IRQ)
> > -   mask |= EDP_PSR_POST_EXIT(trans_shift) |
> > -   EDP_PSR_PRE_ENTRY(trans_shift);
> > +   mask |= psr_irq_post_exit_bit_get(intel_dp) |
> > +   psr_irq_pre_entry_bit_get(intel_dp);
> >  
> > -   /* Warning: it is masking/setting reserved bits too */
> > val = intel_de_read(dev_priv, imr_reg);
> > -   val &= ~EDP_PSR_TRANS_MASK(trans_shift);
> > +   val &= ~psr_irq_mask_get(intel_dp);
> > val |= ~mask;
> > intel_de_write(dev_priv, imr_reg, val);
> >  }
> > @@ -191,25 +213,21 @@ void intel_psr_irq_handler(struct intel_dp *intel_dp, 
> > u32 psr_iir)
> > enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > ktime_t time_ns =  ktime_get();
> > -   enum transcoder trans_shift;
> > i915_reg_t imr_reg;
> >  
> > -   if (DISPLAY_VER(dev_priv) >= 12) {
> > -   trans_shift = 0;
> > +   if (DISPLAY_VER(dev_priv) >= 12)
> > imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
> > -   } else {
> > -   trans_shift = intel_dp->psr.transcoder;
> > +   else
> > imr_reg = EDP_PSR_IMR;
> > -   }
> >  
> > -   if

Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Fix PSR_IMR/IIR field handling

2022-09-29 Thread Souza, Jose

On Tue, 2022-09-27 at 14:09 +0300, Jouni Högander wrote:
> Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for
> bits in PSR_IMR/IIR registers:
> 
> /*
>  * gen12+ has registers relative to transcoder and one per transcoder
>  * using the same bit definition: handle it as TRANSCODER_EDP to force
>  * 0 shift in bit definition
>  */
> 
> At the time of writing the code assumption "TRANSCODER_EDP == 0" was made.
> This is not the case and all fields in PSR_IMR and PSR_IIR are shifted
> incorrectly if DISPLAY_VER >= 12.
> 
> Fix this by adding separate register field defines for >=12 and add bit
> getter functions to keep code readability.
> 
> v3:
>  - Add separate register field defines (José)
>  - Add bit getter functions (José)
> v2:
>  - Improve commit message (José)
> 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 84 ++--
>  drivers/gpu/drm/i915/i915_reg.h  | 16 +++--
>  2 files changed, 62 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 9def8d9fade6..d7b08a7da9e9 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -116,34 +116,56 @@ static bool psr2_global_enabled(struct intel_dp 
> *intel_dp)
>   }
>  }
>  
> +static u32 psr_irq_psr_error_bit_get(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_ERROR :
> + EDP_PSR_ERROR(intel_dp->psr.transcoder);

Drop the "_EDP", just go with TGL_PSR_ERROR... there is no reference to EDP or 
any transcoder in TGL+ it is one register per transcoder.

> +}
> +
> +static u32 psr_irq_post_exit_bit_get(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_POST_EXIT :
> + EDP_PSR_POST_EXIT(intel_dp->psr.transcoder);
> +}
> +
> +static u32 psr_irq_pre_entry_bit_get(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_PRE_ENTRY :
> + EDP_PSR_PRE_ENTRY(intel_dp->psr.transcoder);
> +}
> +
> +static u32 psr_irq_mask_get(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_MASK :
> + EDP_PSR_MASK(intel_dp->psr.transcoder);
> +}
> +
>  static void psr_irq_control(struct intel_dp *intel_dp)
>  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> - enum transcoder trans_shift;
>   i915_reg_t imr_reg;
>   u32 mask, val;
>  
> - /*
> -  * gen12+ has registers relative to transcoder and one per transcoder
> -  * using the same bit definition: handle it as TRANSCODER_EDP to force
> -  * 0 shift in bit definition
> -  */
> - if (DISPLAY_VER(dev_priv) >= 12) {
> - trans_shift = 0;
> + if (DISPLAY_VER(dev_priv) >= 12)
>   imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
> - } else {
> - trans_shift = intel_dp->psr.transcoder;
> + else
>   imr_reg = EDP_PSR_IMR;
> - }
>  
> - mask = EDP_PSR_ERROR(trans_shift);
> + mask = psr_irq_psr_error_bit_get(intel_dp);
>   if (intel_dp->psr.debug & I915_PSR_DEBUG_IRQ)
> - mask |= EDP_PSR_POST_EXIT(trans_shift) |
> - EDP_PSR_PRE_ENTRY(trans_shift);
> + mask |= psr_irq_post_exit_bit_get(intel_dp) |
> + psr_irq_pre_entry_bit_get(intel_dp);
>  
> - /* Warning: it is masking/setting reserved bits too */
>   val = intel_de_read(dev_priv, imr_reg);
> - val &= ~EDP_PSR_TRANS_MASK(trans_shift);
> + val &= ~psr_irq_mask_get(intel_dp);
>   val |= ~mask;
>   intel_de_write(dev_priv, imr_reg, val);
>  }
> @@ -191,25 +213,21 @@ void intel_psr_irq_handler(struct intel_dp *intel_dp, 
> u32 psr_iir)
>   enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>   ktime_t time_ns =  ktime_get();
> - enum transcoder trans_shift;
>   i915_reg_t imr_reg;
>  
> - if (DISPLAY_VER(dev_priv) >= 12) {
> - trans_shift = 0;
> + if (DISPLAY_VER(dev_priv) >= 12)
>   imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
> - } else {
> - trans_shift = intel_dp->psr.transcoder;
> + else
>   imr_reg = EDP_PSR_IMR;
> - }
>  
> - if (psr_iir & EDP_PSR_PRE_ENTRY(trans_shift)) {
> + if (psr_iir & psr_irq_pre_entry_bit_get(intel_dp)) {
>   intel_dp->psr.last_entry_attempt = time_ns;
>   drm_dbg_kms(_priv->drm,
>   "[transcoder %s] PSR entry attempt in 2 vblanks\n",
>

[Intel-gfx] [PATCH] drm/i915/gvt: fix double free bug in split_2MB_gtt_entry

2022-09-29 Thread Zheng Wang

If intel_gvt_dma_map_guest_page failed, it will call
ppgtt_invalidate_spt, which will finally free the spt.
But the caller does not notice that, it will free spt again in error path.

Fix this by only freeing spt in ppgtt_invalidate_spt in good case.

Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge gtt support")
Reported-by: Zheng Wang 
Signed-off-by: Zheng Wang 
---
 drivers/gpu/drm/i915/gvt/gtt.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index ce0eb03709c3..550519f0acca 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -959,7 +959,7 @@ static inline int ppgtt_put_spt(struct intel_vgpu_ppgtt_spt 
*spt)
return atomic_dec_return(>refcount);
 }
 
-static int ppgtt_invalidate_spt(struct intel_vgpu_ppgtt_spt *spt);
+static int ppgtt_invalidate_spt(struct intel_vgpu_ppgtt_spt *spt, int 
is_error);
 
 static int ppgtt_invalidate_spt_by_shadow_entry(struct intel_vgpu *vgpu,
struct intel_gvt_gtt_entry *e)
@@ -995,7 +995,7 @@ static int ppgtt_invalidate_spt_by_shadow_entry(struct 
intel_vgpu *vgpu,
ops->get_pfn(e));
return -ENXIO;
}
-   return ppgtt_invalidate_spt(s);
+   return ppgtt_invalidate_spt(s, 0);
 }
 
 static inline void ppgtt_invalidate_pte(struct intel_vgpu_ppgtt_spt *spt,
@@ -1016,7 +1016,7 @@ static inline void ppgtt_invalidate_pte(struct 
intel_vgpu_ppgtt_spt *spt,
intel_gvt_dma_unmap_guest_page(vgpu, pfn << PAGE_SHIFT);
 }
 
-static int ppgtt_invalidate_spt(struct intel_vgpu_ppgtt_spt *spt)
+static int ppgtt_invalidate_spt(struct intel_vgpu_ppgtt_spt *spt, int is_error)
 {
struct intel_vgpu *vgpu = spt->vgpu;
struct intel_gvt_gtt_entry e;
@@ -1059,9 +1059,11 @@ static int ppgtt_invalidate_spt(struct 
intel_vgpu_ppgtt_spt *spt)
}
}
 
-   trace_spt_change(spt->vgpu->id, "release", spt,
+   if (!is_error) {
+   trace_spt_change(spt->vgpu->id, "release", spt,
 spt->guest_page.gfn, spt->shadow_page.type);
-   ppgtt_free_spt(spt);
+   ppgtt_free_spt(spt);
+   }
return 0;
 fail:
gvt_vgpu_err("fail: shadow page %p shadow entry 0x%llx type %d\n",
@@ -1215,7 +1217,7 @@ static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
ret = intel_gvt_dma_map_guest_page(vgpu, start_gfn + sub_index,
   PAGE_SIZE, _addr);
if (ret) {
-   ppgtt_invalidate_spt(spt);
+   ppgtt_invalidate_spt(spt, 1);
return ret;
}
sub_se.val64 = se->val64;
@@ -1393,7 +1395,7 @@ static int ppgtt_handle_guest_entry_removal(struct 
intel_vgpu_ppgtt_spt *spt,
ret = -ENXIO;
goto fail;
}
-   ret = ppgtt_invalidate_spt(s);
+   ret = ppgtt_invalidate_spt(s, 0);
if (ret)
goto fail;
} else {
-- 
2.25.1

[Intel-gfx] Information about XDC 2022 - next week!

2022-09-29 Thread Jeremy White


Hi folks,

We are excited to welcome you in person to the 2022 X.Org Developers 
Conference, held in conjunction with WineConf and FOSS XR conference.


The conference will start officially on Tuesday morning, October 4th. 
The program is here:

  https://indico.freedesktop.org/event/2/timetable/#all.detailed
The official events start at 8:30 am, but we will have coffee and 
pastries available from 7:30 on Tuesday and 8 on Wednesday and Thursday.


We expect everyone attending to be vaccinated and to be respectful of 
people that are trying to avoid catching COVID. Masks are mandatory, 
except when presenting or eating.


A small number of us will gather informally at Brit’s Pub, starting at 
around 4:00 pm on Monday, October 3rd.  We’ll try to have a table with 
some sort of a sign, and folks can connect, have a drink, and then 
perhaps group up to explore alternate food.  Note that if the weather is 
nice, we may be up on the roof, so explore far to find us.


We will be on the Minneapolis campus of St. Thomas, which is a mildly 
confusing campus.  We have given instructions and a picture to guide you 
here:


https://indico.freedesktop.org/event/2/page/10-attending-xdc-wineconf-foss-xr
We are working on the remote experience, and expect to have streaming of 
all events available. The above page will have those details just as 
soon as they are finalized.


We have a page of instructions for folks that will be presenting:
  https://indico.freedesktop.org/event/2/page/18-speaker-instructions

We are also excited to announce the happy hour taking place on 
Wednesday, from 6:00 pm until 8:00 pm.  The hope is that all three 
projects can mingle and socialize and enjoy the return of in person 
meetings.


Also, this year we plan to adopt the Wine strategy of using a deliberate 
Matrix chat room just for the conference.  Matrix has a variety of apps, 
and Element, the default one is easy to configure on many devices, 
including mobile phones.  The link to that channel is here:

  https://matrix.to/#/#xdc-wineconf-fossxr-2022:matrix.org
We find the chat channel a good place to learn what restaurants and bars 
are chosen, and just a good way to track the social aspects of the 
conference.


We look forward to seeing you next week!

Cheers,

Jeremy

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/mtl: enable local stolen memory (rev4)

2022-09-29 Thread Patchwork

== Series Details ==

Series: drm/i915/mtl: enable local stolen memory (rev4)
URL   : https://patchwork.freedesktop.org/series/109066/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_109066v4_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 12)
--

  Additional (2): shard-dg1 shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@drm_fdinfo@virtual-busy-hang-all:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-tglb7/igt@drm_fdi...@virtual-busy-hang-all.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109066v4/shard-tglb8/igt@drm_fdi...@virtual-busy-hang-all.html

  * {igt@gem_mmap_offset@ptrace@lmem0-fixed} (NEW):
- {shard-dg1}:NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109066v4/shard-dg1-12/igt@gem_mmap_offset@ptr...@lmem0-fixed.html

  
New tests
-

  New tests have been introduced between CI_DRM_12193_full and 
Patchwork_109066v4_full:

### New IGT tests (39) ###

  * igt@gem_mmap_offset@ptrace@lmem0-fixed:
- Statuses : 1 fail(s)
- Exec time: [0.02] s

  * igt@gem_mmap_offset@ptrace@smem0-fixed:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_color@ctm-0-50@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [1.17] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.39] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.25] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.23] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.24] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@cursor_implicit_plane@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.31] s

  * igt@kms_lease@cursor_implicit_plane@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@cursor_implicit_plane@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * igt@kms_lease@cursor_implicit_plane@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@empty_lease@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * igt@kms_lease@empty_lease@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@empty_lease@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@empty_lease@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@lease_invalid_connector@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@lease_invalid_connector@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_connector@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_connector@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@lease_invalid_crtc@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_revoke@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.25] s

  * igt@kms_lease@lease_revoke@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.11] s

  * igt@kms_lease@lease_revoke@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.11] s

  * igt@kms_lease@lease_revoke@pipe-d-hdmi-a-4:

Re: [Intel-gfx] [PATCH 05/10] drm/i915: Change glk_load_degamma_lut() calling convention

2022-09-29 Thread Jani Nikula

On Thu, 29 Sep 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Make glk_load_degamma_lut() more like most everyone else and
> pass in the LUT explicitly.
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 96687ec30b19..0c73b2ba1283 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -826,13 +826,14 @@ static int glk_degamma_lut_size(struct drm_i915_private 
> *i915)
>   return 35;
>  }
>  
> -static void glk_load_degamma_lut(const struct intel_crtc_state *crtc_state)
> +static void glk_load_degamma_lut(const struct intel_crtc_state *crtc_state,
> +  const struct drm_property_blob *blob)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + const struct drm_color_lut *lut = blob->data;
> + int i, lut_size = drm_color_lut_size(blob);
>   enum pipe pipe = crtc->pipe;
> - int i, lut_size = INTEL_INFO(dev_priv)->display.color.degamma_lut_size;
> - const struct drm_color_lut *lut = crtc_state->hw.degamma_lut->data;
>  
>   /*
>* When setting the auto-increment bit, the hardware seems to
> @@ -899,6 +900,7 @@ static void glk_load_degamma_lut_linear(const struct 
> intel_crtc_state *crtc_stat
>  
>  static void glk_load_luts(const struct intel_crtc_state *crtc_state)
>  {
> + const struct drm_property_blob *degamma_lut = 
> crtc_state->hw.degamma_lut;
>   const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>  
> @@ -910,8 +912,8 @@ static void glk_load_luts(const struct intel_crtc_state 
> *crtc_state)
>* the degama LUT so that we don't have to reload
>* it every time the pipe CSC is being enabled.
>*/
> - if (crtc_state->hw.degamma_lut)
> - glk_load_degamma_lut(crtc_state);
> + if (degamma_lut)
> + glk_load_degamma_lut(crtc_state, degamma_lut);
>   else
>   glk_load_degamma_lut_linear(crtc_state);
>  
> @@ -1043,11 +1045,12 @@ icl_program_gamma_multi_segment(const struct 
> intel_crtc_state *crtc_state)
>  
>  static void icl_load_luts(const struct intel_crtc_state *crtc_state)
>  {
> + const struct drm_property_blob *degamma_lut = 
> crtc_state->hw.degamma_lut;
>   const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>  
> - if (crtc_state->hw.degamma_lut)
> - glk_load_degamma_lut(crtc_state);
> + if (degamma_lut)
> + glk_load_degamma_lut(crtc_state, degamma_lut);
>  
>   switch (crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) {
>   case GAMMA_MODE_MODE_8BIT:

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 04/10] drm/i915: Clean up intel_color_init_hooks()

2022-09-29 Thread Jani Nikula

On Thu, 29 Sep 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Remove a bunch of pointless curly brackets and do
> the s/dev_priv/i915/ while at it.
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 43 +++---
>  1 file changed, 21 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index ce8a4be9b292..96687ec30b19 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -2219,30 +2219,29 @@ void intel_crtc_color_init(struct intel_crtc *crtc)
>  
> INTEL_INFO(dev_priv)->display.color.gamma_lut_size);
>  }
>  
> -void intel_color_init_hooks(struct drm_i915_private *dev_priv)
> +void intel_color_init_hooks(struct drm_i915_private *i915)
>  {
> - if (HAS_GMCH(dev_priv)) {
> - if (IS_CHERRYVIEW(dev_priv)) {
> - dev_priv->display.funcs.color = _color_funcs;
> - } else if (DISPLAY_VER(dev_priv) >= 4) {
> - dev_priv->display.funcs.color = _color_funcs;
> - } else {
> - dev_priv->display.funcs.color = _color_funcs;
> - }
> + if (HAS_GMCH(i915)) {
> + if (IS_CHERRYVIEW(i915))
> + i915->display.funcs.color = _color_funcs;
> + else if (DISPLAY_VER(i915) >= 4)
> + i915->display.funcs.color = _color_funcs;
> + else
> + i915->display.funcs.color = _color_funcs;
>   } else {
> - if (DISPLAY_VER(dev_priv) >= 11)
> - dev_priv->display.funcs.color = _color_funcs;
> - else if (DISPLAY_VER(dev_priv) == 10)
> - dev_priv->display.funcs.color = _color_funcs;
> - else if (DISPLAY_VER(dev_priv) == 9)
> - dev_priv->display.funcs.color = _color_funcs;
> - else if (DISPLAY_VER(dev_priv) == 8)
> - dev_priv->display.funcs.color = _color_funcs;
> - else if (IS_HASWELL(dev_priv))
> - dev_priv->display.funcs.color = _color_funcs;
> - else if (DISPLAY_VER(dev_priv) == 7)
> - dev_priv->display.funcs.color = _color_funcs;
> + if (DISPLAY_VER(i915) >= 11)
> + i915->display.funcs.color = _color_funcs;
> + else if (DISPLAY_VER(i915) == 10)
> + i915->display.funcs.color = _color_funcs;
> + else if (DISPLAY_VER(i915) == 9)
> + i915->display.funcs.color = _color_funcs;
> + else if (DISPLAY_VER(i915) == 8)
> + i915->display.funcs.color = _color_funcs;
> + else if (IS_HASWELL(i915))
> + i915->display.funcs.color = _color_funcs;
> + else if (DISPLAY_VER(i915) == 7)
> + i915->display.funcs.color = _color_funcs;
>   else
> - dev_priv->display.funcs.color = _color_funcs;
> + i915->display.funcs.color = _color_funcs;
>   }
>  }

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 03/10] drm/i915: Simplify the intel_color_init_hooks() if ladder

2022-09-29 Thread Jani Nikula

On Thu, 29 Sep 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Get rid of the funny hsw vs. ivb extra indentation level in
> intel_color_init_hooks().
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index ddfe7c257a72..ce8a4be9b292 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -2238,12 +2238,11 @@ void intel_color_init_hooks(struct drm_i915_private 
> *dev_priv)
>   dev_priv->display.funcs.color = _color_funcs;
>   else if (DISPLAY_VER(dev_priv) == 8)
>   dev_priv->display.funcs.color = _color_funcs;
> - else if (DISPLAY_VER(dev_priv) == 7) {
> - if (IS_HASWELL(dev_priv))
> - dev_priv->display.funcs.color = 
> _color_funcs;
> - else
> - dev_priv->display.funcs.color = 
> _color_funcs;
> - } else
> + else if (IS_HASWELL(dev_priv))
> + dev_priv->display.funcs.color = _color_funcs;
> + else if (DISPLAY_VER(dev_priv) == 7)
> + dev_priv->display.funcs.color = _color_funcs;
> + else
>   dev_priv->display.funcs.color = _color_funcs;
>   }
>  }

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 02/10] drm/i915: Split up intel_color_init()

2022-09-29 Thread Jani Nikula

On Thu, 29 Sep 2022, Jani Nikula  wrote:
> On Thu, 29 Sep 2022, Ville Syrjala  wrote:
>> From: Ville Syrjälä 
>>
>> intel_color_init() does both device level and crtc level stuff.
>> Split it up accordingly.
>>
>> Signed-off-by: Ville Syrjälä 
>> ---
>>  drivers/gpu/drm/i915/display/intel_color.c   | 15 +--
>>  drivers/gpu/drm/i915/display/intel_color.h   |  4 +++-
>>  drivers/gpu/drm/i915/display/intel_crtc.c|  3 +--
>>  drivers/gpu/drm/i915/display/intel_display.c |  1 +
>>  4 files changed, 14 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
>> b/drivers/gpu/drm/i915/display/intel_color.c
>> index bbc56affb3ec..ddfe7c257a72 100644
>> --- a/drivers/gpu/drm/i915/display/intel_color.c
>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
>> @@ -2206,13 +2206,21 @@ static const struct intel_color_funcs 
>> ilk_color_funcs = {
>>  .read_luts = ilk_read_luts,
>>  };
>>  
>> -void intel_color_init(struct intel_crtc *crtc)
>> +void intel_crtc_color_init(struct intel_crtc *crtc)
>>  {
>>  struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>>  bool has_ctm = INTEL_INFO(dev_priv)->display.color.degamma_lut_size != 
>> 0;
>>  
>>  drm_mode_crtc_set_gamma_size(>base, 256);
>>  
>> +drm_crtc_enable_color_mgmt(>base,
>> +   
>> INTEL_INFO(dev_priv)->display.color.degamma_lut_size,
>> +   has_ctm,
>> +   
>> INTEL_INFO(dev_priv)->display.color.gamma_lut_size);
>> +}
>> +
>> +void intel_color_init_hooks(struct drm_i915_private *dev_priv)
>> +{
>>  if (HAS_GMCH(dev_priv)) {
>>  if (IS_CHERRYVIEW(dev_priv)) {
>>  dev_priv->display.funcs.color = _color_funcs;
>> @@ -2238,9 +2246,4 @@ void intel_color_init(struct intel_crtc *crtc)
>>  } else
>>  dev_priv->display.funcs.color = _color_funcs;
>>  }
>> -
>> -drm_crtc_enable_color_mgmt(>base,
>> -   
>> INTEL_INFO(dev_priv)->display.color.degamma_lut_size,
>> -   has_ctm,
>> -   
>> INTEL_INFO(dev_priv)->display.color.gamma_lut_size);
>>  }
>> diff --git a/drivers/gpu/drm/i915/display/intel_color.h 
>> b/drivers/gpu/drm/i915/display/intel_color.h
>> index fd873425e082..67702451e2fd 100644
>> --- a/drivers/gpu/drm/i915/display/intel_color.h
>> +++ b/drivers/gpu/drm/i915/display/intel_color.h
>> @@ -10,9 +10,11 @@
>>  
>>  struct intel_crtc_state;
>>  struct intel_crtc;
>> +struct drm_i915_private;
>>  struct drm_property_blob;
>>  
>> -void intel_color_init(struct intel_crtc *crtc);
>> +void intel_color_init_hooks(struct drm_i915_private *i915);
>> +void intel_crtc_color_init(struct intel_crtc *crtc);
>>  int intel_color_check(struct intel_crtc_state *crtc_state);
>>  void intel_color_commit_noarm(const struct intel_crtc_state *crtc_state);
>>  void intel_color_commit_arm(const struct intel_crtc_state *crtc_state);
>> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
>> b/drivers/gpu/drm/i915/display/intel_crtc.c
>> index 6792a9056f46..2d9fc7383bfc 100644
>> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
>> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
>> @@ -365,8 +365,7 @@ int intel_crtc_init(struct drm_i915_private *dev_priv, 
>> enum pipe pipe)
>>  BIT(DRM_SCALING_FILTER_DEFAULT) 
>> |
>>  
>> BIT(DRM_SCALING_FILTER_NEAREST_NEIGHBOR));
>>  
>> -intel_color_init(crtc);
>> -
>> +intel_crtc_color_init(crtc);
>>  intel_crtc_drrs_init(crtc);
>>  intel_crtc_crc_init(crtc);
>
> I'd name all of these like:
>
>   intel_color_crtc_init();
> intel_drrs_crtc_init();
> intel_crc_crtc_init();
>
> I think in gem side the "name functions based on first/context argument"
> style has lead to serious problems wrt code organization. They still
> stick to it, but I can't make heads or tails where function definitions
> or declarations are supposed to be placed or found.

The patch itself is fine, and follows the precedent set by the above
functions, but I'd *really* like to see all the above functions renamed
afterwards.

Reviewed-by: Jani Nikula 

>
> BR,
> Jani.
>
>
>>  
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> index eb8eaeb19881..a103413cb081 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -8326,6 +8326,7 @@ void intel_init_display_hooks(struct drm_i915_private 
>> *dev_priv)
>>  if (!HAS_DISPLAY(dev_priv))
>>  return;
>>  
>> +intel_color_init_hooks(dev_priv);
>>  intel_init_cdclk_hooks(dev_priv);
>>  intel_audio_hooks_init(dev_priv);

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Remove PLL asserts from .load_luts()

2022-09-29 Thread Jani Nikula

On Thu, 29 Sep 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> .load_luts() potentially runs from the vblank worker, and is
> under a deadline to complete within the vblank. Thus we can't
> do expesive stuff like talk to the Punit, etc.
>
> To that end get rid of the assert_dsi_pll_enabled() call for
> vlv/chv. We'll just have to trust that the PLL is already enabled
> here.
>
> And I don't think the normal assert_pll_enabled() really buys us
> anything useful on gmch platforms either, so nuke that one too.
> We don't have corresponding asserts in the ilk+ codepaths anyway
> despite the hardware (IIRC) still requiring the clock to be
> enabled when we access the LUT.
>
> Signed-off-by: Ville Syrjälä 

Acked-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 11 ---
>  1 file changed, 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 6bda4274eae9..bbc56affb3ec 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -25,9 +25,7 @@
>  #include "intel_color.h"
>  #include "intel_de.h"
>  #include "intel_display_types.h"
> -#include "intel_dpll.h"
>  #include "intel_dsb.h"
> -#include "vlv_dsi_pll.h"
>  
>  struct intel_color_funcs {
>   int (*color_check)(struct intel_crtc_state *crtc_state);
> @@ -580,11 +578,8 @@ static void i9xx_load_lut_8(struct intel_crtc *crtc,
>  static void i9xx_load_luts(const struct intel_crtc_state *crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
>  
> - assert_pll_enabled(dev_priv, crtc->pipe);
> -
>   i9xx_load_lut_8(crtc, gamma_lut);
>  }
>  
> @@ -611,14 +606,8 @@ static void i965_load_lut_10p6(struct intel_crtc *crtc,
>  static void i965_load_luts(const struct intel_crtc_state *crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
>  
> - if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI))
> - assert_dsi_pll_enabled(dev_priv);
> - else
> - assert_pll_enabled(dev_priv, crtc->pipe);
> -
>   if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
>   i9xx_load_lut_8(crtc, gamma_lut);
>   else

-- 
Jani Nikula, Intel Open Source Graphics Center

1 2 >

1 - 100 of 138 matches

Mail list logo