Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions

[Lucas De Marchi]

On Tue, Apr 26, 2022 at 05:35:09PM -0700, Anusha Srivatsa wrote:

Bspec has added some steps that check forDMC MMIO range before
programming them

v2: Fix for CI
v3: move register defines to .h (Anusha)
- Check MMIO restrictions per pipe
- Add MMIO restricton for v1 dmc header as well (Lucas)

BSpec: 49193

Cc: 
Cc: Lucas De Marchi 
Signed-off-by: Anusha Srivatsa 
---
drivers/gpu/drm/i915/display/intel_dmc.c  | 48 ---
drivers/gpu/drm/i915/display/intel_dmc_regs.h | 31 
2 files changed, 72 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 257cf662f9f4..ac7896835bfa 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -97,13 +97,6 @@ MODULE_FIRMWARE(SKL_DMC_PATH);
#define BXT_DMC_MAX_FW_SIZE 0x3000
MODULE_FIRMWARE(BXT_DMC_PATH);

-#define DMC_DEFAULT_FW_OFFSET  0x
-#define PACKAGE_MAX_FW_INFO_ENTRIES20
-#define PACKAGE_V2_MAX_FW_INFO_ENTRIES 32
-#define DMC_V1_MAX_MMIO_COUNT  8
-#define DMC_V3_MAX_MMIO_COUNT  20
-#define DMC_V1_MMIO_START_RANGE0x8
-
struct intel_css_header {
/* 0x09 for DMC */
u32 module_type;
@@ -374,6 +367,43 @@ static void dmc_set_fw_offset(struct intel_dmc *dmc,
}
}

+static bool dmc_mmio_addr_sanity_check(struct intel_dmc *dmc, const u32 
*mmioaddr,
+  u32 mmio_count, int header_ver, u8 
dmc_id)
+{
+   struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc);
+   int i;
+
+   if (header_ver == 1) {
+   for (i = 0; i < mmio_count; i++) {
+   if (mmioaddr[i] < DMC_MMIO_START_RANGE || mmioaddr[i] > 
DMC_MMIO_END_RANGE)
+   return false;
+   }


return missing here


+   }
+
+   /* Main DMC MMIO check */
+   if (dmc_id == DMC_FW_MAIN) {
+   for (i = 0; i < mmio_count; i++) {
+   if (mmioaddr[i] < TGL_DMC_MMIO_START(dmc_id) || 
mmioaddr[i] > TGL_DMC_MMIO_END(dmc_id))
+   return false;
+   }
+   }
+
+   /* Pipe DMC MMIO check */
+   if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
+   for (i = 0; i < mmio_count; i++) {
+   if (mmioaddr[i] < ADLP_PIPE_MMIO_START && mmioaddr[i] > 
ADLP_PIPE_MMIO_END)
+   return false;
+   }


for DG2, main should use TGL_DMC_MMIO_START? and then fail here because
of another missing return above?


+   } else if (IS_TIGERLAKE(i915) || IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
+   for (i = 0; i < mmio_count; i++) {
+   if (mmioaddr[i] < TGL_DMC_MMIO_START(dmc_id) || 
mmioaddr[i] > TGL_DMC_MMIO_END(dmc_id))
+   return false;


this is handling DMC_FW_MAIN twice.


Maybe something like this:

u32 start, end;

if (header_ver == 1) {
start = DMC_MMIO_START_RANGE;
end = DMC_MMIO_END_RANGE;
} else if (dmc_id == DMC_FW_MAIN || IS_TIGERLAKE(i915) || IS_DG1(i915) 
|| IS_ALDERLAKE_S(i915)) {
start = TGL_DMC_MMIO_START(dmc_id);
end = TGL_DMC_MMIO_END(dmc_id);
} else if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
start = ADLP_PIPE_MMIO_START;
end = ADLP_PIPE_MMIO_END;
} else {
drm_warn(>drm, "Unknown mmio range for sanity check");
return false;
}

for (i = 0; i < mmio_count; i++)
if (mmioaddr[i] < start || mmioaddr[i] > end)
return false;

return true;


... untested, and may need tweaks depending on the answer to the
question above on what range to use for ADL-P/DG2 on main DMC.


+   }
+   }
+
+   return true;
+}
+
static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
   const struct intel_dmc_header_base *dmc_header,
   size_t rem_size, u8 dmc_id)
@@ -443,6 +473,10 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
return 0;
}

+   if (!dmc_mmio_addr_sanity_check(dmc, mmioaddr, mmio_count, 
dmc_header->header_ver, dmc_id))
+   drm_err(>drm, "DMC firmware has Wrong MMIO Addresses\n");
+   return 0;


you don't like DMC and decided to fail it for all platforms?


+
for (i = 0; i < mmio_count; i++) {
dmc_info->mmioaddr[i] = _MMIO(mmioaddr[i]);
dmc_info->mmiodata[i] = mmiodata[i];
diff --git a/drivers/gpu/drm/i915/display/intel_dmc_regs.h 
b/drivers/gpu/drm/i915/display/intel_dmc_regs.h
index d65e698832eb..235d1b721334 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc_regs.h
+++ b/drivers/gpu/drm/i915/display/intel_dmc_regs.h
@@ -11,12 +11,43 @@
#define DMC_PROGRAM(addr, 

Re: [Intel-gfx] False-positive of CI issue w/ AMDGPU patch set

[Vudum, Lakshminarayana]

Both are known failures, so I have re-reported.

Thanks,
Lakshmi.

From: Zhang, Dingchen (David) 
Sent: Tuesday, April 26, 2022 10:48 AM
To: Vudum, Lakshminarayana ; 
intel-gfx@lists.freedesktop.org; Latvala, Petri 
Cc: Siqueira, Rodrigo ; Pillai, Aurabindo 

Subject: Re: False-positive of CI issue w/ AMDGPU patch set


[AMD Official Use Only]

Hi Lakshmi,

Thanks for the clarification and now the rev5 CI build reports issue again 
which is false-positive (as below)
https://patchwork.freedesktop.org/series/102886/
[cid:image003.png@01D859BA.7EDAB080]
[cid:image004.png@01D859BA.7EDAB080]

Could you help clear it?

Thanks
David

From: Vudum, Lakshminarayana 
mailto:lakshminarayana.vu...@intel.com>>
Sent: Tuesday, April 26, 2022 11:25 AM
To: Zhang, Dingchen (David) 
mailto:dingchen.zh...@amd.com>>; 
intel-gfx@lists.freedesktop.org 
mailto:intel-gfx@lists.freedesktop.org>>; 
Latvala, Petri mailto:petri.latv...@intel.com>>
Cc: Siqueira, Rodrigo 
mailto:rodrigo.sique...@amd.com>>; Pillai, Aurabindo 
mailto:aurabindo.pil...@amd.com>>
Subject: RE: False-positive of CI issue w/ AMDGPU patch set


[AMD Official Use Only]


I have re-opened 
https://gitlab.freedesktop.org/drm/intel/-/issues/5302

igt@i915_module_load@reload-with-fault-injection - dmesg-warn - WARNING: .* at 
drivers/gpu/drm/i915/i915_vma.c:\d+ i915_ggtt_pin



Other sounds is not totally new, I have seen similar signature few months ago 
on a different test but to me this sounds like a sporadic issue. So filed a new 
issue

https://gitlab.freedesktop.org/drm/intel/-/issues/5844

igt@kms_fbcon_fbt@psr-suspend - incomplete - pstore logs - is trying to acquire 
lock at: down_trylock, but task is already holding lock at: 
raw_spin_rq_lock_nested



Anyways, re-reporting doesn't really help as we will get results from rev5.



Lakshmi.

From: Zhang, Dingchen (David) 
mailto:dingchen.zh...@amd.com>>
Sent: Tuesday, April 26, 2022 6:38 AM
To: Vudum, Lakshminarayana 
mailto:lakshminarayana.vu...@intel.com>>; 
intel-gfx@lists.freedesktop.org; 
Latvala, Petri mailto:petri.latv...@intel.com>>
Cc: Siqueira, Rodrigo 
mailto:rodrigo.sique...@amd.com>>; Pillai, Aurabindo 
mailto:aurabindo.pil...@amd.com>>
Subject: Re: False-positive of CI issue w/ AMDGPU patch set



[AMD Official Use Only]



Hi Lakshmi,



Thanks for your reply and could you please clear another false-positive CI 
issue below? (link 
https://patchwork.freedesktop.org/series/102886/).
 The possible regression is not correlated to the amdgpu patch set.

[cid:image005.png@01D859BA.7EDAB080]



regards

David



From: Vudum, Lakshminarayana 
mailto:lakshminarayana.vu...@intel.com>>
Sent: Monday, April 25, 2022 5:25 PM
To: Zhang, Dingchen (David) 
mailto:dingchen.zh...@amd.com>>; 
intel-gfx@lists.freedesktop.org 
mailto:intel-gfx@lists.freedesktop.org>>; 
Latvala, Petri mailto:petri.latv...@intel.com>>
Cc: Siqueira, Rodrigo 
mailto:rodrigo.sique...@amd.com>>; Pillai, Aurabindo 
mailto:aurabindo.pil...@amd.com>>
Subject: RE: False-positive of CI issue w/ AMDGPU patch set



[AMD Official Use Only]



I am not sure if I can take any action here. @Latvala, 
Petri Any inputs?



Lakshmi.



From: Zhang, Dingchen (David) 
mailto:dingchen.zh...@amd.com>>
Sent: Monday, April 25, 2022 1:16 PM
To: Vudum, Lakshminarayana 
mailto:lakshminarayana.vu...@intel.com>>
Cc: Siqueira, Rodrigo 
mailto:rodrigo.sique...@amd.com>>; Pillai, Aurabindo 
mailto:aurabindo.pil...@amd.com>>
Subject: False-positive of CI issue w/ AMDGPU patch set



[AMD Official Use Only]



Hi Lakshminarayana,



Could 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for i915: Upstream initial DG2 PCI IDs

[Vudum, Lakshminarayana]

Yes, I have filed a new issue and re-reported.
https://gitlab.freedesktop.org/drm/intel/-/issues/5846
igt@kms_vblank@pipe-d-wait-idle-hang - incomplete - general protection fault, 
probably for non-canonical address 0x380015ffd0003c, RIP: 
0010:acpi_ns_search_one_scope

Thanks,
Lakshmi
-Original Message-
From: Roper, Matthew D  
Sent: Tuesday, April 26, 2022 10:06 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vudum, Lakshminarayana 
Subject: Re: ✗ Fi.CI.IGT: failure for i915: Upstream initial DG2 PCI IDs

On Tue, Apr 26, 2022 at 12:17:24AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: i915: Upstream initial DG2 PCI IDs
> URL   : https://patchwork.freedesktop.org/series/103098/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103098v1_full 
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_103098v1_full absolutely need 
> to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_103098v1_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 -> 13)
> --
> 
>   Additional (3): shard-rkl shard-dg1 shard-tglu
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_103098v1_full:
> 
> ### CI changes ###
> 
>  Suppressed 
> 
>   The following results come from untrusted machines, tests, or statuses.
>   They do not affect the overall result.
> 
>   * boot:
> - {shard-rkl}:NOTRUN -> ([PASS][1], [PASS][2], [PASS][3], 
> [PASS][4], [PASS][5], [PASS][6], [PASS][7], [FAIL][8], [PASS][9], [PASS][10], 
> [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], 
> [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21])
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-6/boot.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-3/boot.html
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-3/boot.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-4/boot.html
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-5/boot.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-
> 5/boot.html

THere doesn't seem to be a log output for the failure.  But updating DG2 device 
IDs shouldn't have any impact on RKL.

>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-5/boot.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-6/boot.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-6/boot.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
>[19]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
>[20]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
>[21]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-
> 2/boot.html
> 
>   
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@kms_vblank@pipe-d-wait-idle-hang:
> - shard-tglb: [PASS][22] -> [INCOMPLETE][23]
>[22]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-tglb6/igt@kms_vbl...@pipe-d-wait-idle-hang.html
>[23]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-tglb
> 3/igt@kms_vbl...@pipe-d-wait-idle-hang.html

GPF outside of i915:

<4> [358.240067] general protection fault, probably for non-canonical address 
0x380015ffd0003c:  [#1] PREEMPT SMP NOPTI
<4> [358.240074] CPU: 0 PID: 175 Comm: kworker/0:1H Tainted: G U
5.18.0-rc4-Patchwork_103098v1-g56b089ae03ef+ #1
<4> [358.240076] Hardware name: Intel Corporation Tiger Lake Client 
Platform/TigerLake U DDR4 SODIMM RVP, BIOS 

[Intel-gfx] ✓ Fi.CI.IGT: success for i915: Upstream initial DG2 PCI IDs

[Patchwork]

== Series Details ==

Series: i915: Upstream initial DG2 PCI IDs
URL   : https://patchwork.freedesktop.org/series/103098/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103098v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 13)
--

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

Possible new issues
---

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

### CI changes ###

 Suppressed 

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

  * boot:
- {shard-rkl}:NOTRUN -> ([PASS][1], [PASS][2], [PASS][3], 
[PASS][4], [FAIL][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], 
[PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], 
[PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-6/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-6/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-6/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-5/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-5/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-5/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-4/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-3/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-3/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html

  

### IGT changes ###

 Suppressed 

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

  * {igt@kms_concurrent@pipe-d@hdmi-a-1}:
- {shard-dg1}:NOTRUN -> [CRASH][22]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-dg1-16/igt@kms_concurrent@pip...@hdmi-a-1.html

  
New tests
-

  New tests have been introduced between CI_DRM_11550_full and 
Patchwork_103098v1_full:

### New IGT tests (1) ###

  * igt@kms_sequence@get-forked-busy@hdmi-a-1-pipe-d:
- Statuses : 1 pass(s)
- Exec time: [1.24] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@in-flight-1us:
- shard-skl:  [PASS][23] -> [TIMEOUT][24] ([i915#3063])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/igt@gem_...@in-flight-1us.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-skl4/igt@gem_...@in-flight-1us.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][25] ([fdo#109271]) +155 similar 
issues
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-skl10/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: NOTRUN -> [FAIL][26] ([i915#2842])
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-iclb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][27] -> [FAIL][28] ([i915#2842]) +1 similar 
issue
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-kbl4/igt@gem_exec_fair@basic-p...@vecs0.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_flush@basic-wb-ro-default:
- shard-snb:  [PASS][29] -> [SKIP][30] 

[Intel-gfx] ✓ Fi.CI.IGT: success for i915: Upstream initial DG2 PCI IDs

[Patchwork]

== Series Details ==

Series: i915: Upstream initial DG2 PCI IDs
URL   : https://patchwork.freedesktop.org/series/103098/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103098v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 13)
--

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

Possible new issues
---

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

### CI changes ###

 Suppressed 

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

  * boot:
- {shard-rkl}:NOTRUN -> ([PASS][1], [PASS][2], [PASS][3], 
[PASS][4], [FAIL][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], 
[PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], 
[PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-6/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-6/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-6/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-5/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-5/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-5/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-4/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-3/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-3/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html

  

### IGT changes ###

 Suppressed 

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

  * {igt@kms_concurrent@pipe-d@hdmi-a-1}:
- {shard-dg1}:NOTRUN -> [CRASH][22]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-dg1-16/igt@kms_concurrent@pip...@hdmi-a-1.html

  
New tests
-

  New tests have been introduced between CI_DRM_11550_full and 
Patchwork_103098v1_full:

### New IGT tests (1) ###

  * igt@kms_sequence@get-forked-busy@hdmi-a-1-pipe-d:
- Statuses : 1 pass(s)
- Exec time: [1.24] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@in-flight-1us:
- shard-skl:  [PASS][23] -> [TIMEOUT][24] ([i915#3063])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/igt@gem_...@in-flight-1us.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-skl4/igt@gem_...@in-flight-1us.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][25] ([fdo#109271]) +155 similar 
issues
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-skl10/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: NOTRUN -> [FAIL][26] ([i915#2842])
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-iclb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][27] -> [FAIL][28] ([i915#2842]) +1 similar 
issue
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-kbl4/igt@gem_exec_fair@basic-p...@vecs0.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_flush@basic-wb-ro-default:
- shard-snb:  [PASS][29] -> [SKIP][30] 

Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions

[kernel test robot]

Hi Anusha,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip next-20220426]
[cannot apply to v5.18-rc4]
[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]

url:
https://github.com/intel-lab-lkp/linux/commits/Anusha-Srivatsa/drm-i915-dmc-Add-MMIO-range-restrictions/20220427-084021
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-a012-20220425 
(https://download.01.org/0day-ci/archive/20220427/202204271216.6t3ewj4f-...@intel.com/config)
compiler: gcc-11 (Debian 11.2.0-20) 11.2.0
reproduce (this is a W=1 build):
# 
https://github.com/intel-lab-lkp/linux/commit/f79241ea04e8815b3c1b0ab6b9d6136efc8646d3
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Anusha-Srivatsa/drm-i915-dmc-Add-MMIO-range-restrictions/20220427-084021
git checkout f79241ea04e8815b3c1b0ab6b9d6136efc8646d3
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/display/intel_dmc.c: In function 'parse_dmc_fw_header':
>> drivers/gpu/drm/i915/display/intel_dmc.c:476:9: warning: this 'if' clause 
>> does not guard... [-Wmisleading-indentation]
 476 | if (!dmc_mmio_addr_sanity_check(dmc, mmioaddr, mmio_count, 
dmc_header->header_ver, dmc_id))
 | ^~
   drivers/gpu/drm/i915/display/intel_dmc.c:478:17: note: ...this statement, 
but the latter is misleadingly indented as if it were guarded by the 'if'
 478 | return 0;
 | ^~


vim +/if +476 drivers/gpu/drm/i915/display/intel_dmc.c

   406  
   407  static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
   408 const struct intel_dmc_header_base 
*dmc_header,
   409 size_t rem_size, u8 dmc_id)
   410  {
   411  struct drm_i915_private *i915 = container_of(dmc, 
typeof(*i915), dmc);
   412  struct dmc_fw_info *dmc_info = >dmc_info[dmc_id];
   413  unsigned int header_len_bytes, dmc_header_size, payload_size, i;
   414  const u32 *mmioaddr, *mmiodata;
   415  u32 mmio_count, mmio_count_max, start_mmioaddr;
   416  u8 *payload;
   417  
   418  BUILD_BUG_ON(ARRAY_SIZE(dmc_info->mmioaddr) < 
DMC_V3_MAX_MMIO_COUNT ||
   419   ARRAY_SIZE(dmc_info->mmioaddr) < 
DMC_V1_MAX_MMIO_COUNT);
   420  
   421  /*
   422   * Check if we can access common fields, we will checkc again 
below
   423   * after we have read the version
   424   */
   425  if (rem_size < sizeof(struct intel_dmc_header_base))
   426  goto error_truncated;
   427  
   428  /* Cope with small differences between v1 and v3 */
   429  if (dmc_header->header_ver == 3) {
   430  const struct intel_dmc_header_v3 *v3 =
   431  (const struct intel_dmc_header_v3 *)dmc_header;
   432  
   433  if (rem_size < sizeof(struct intel_dmc_header_v3))
   434  goto error_truncated;
   435  
   436  mmioaddr = v3->mmioaddr;
   437  mmiodata = v3->mmiodata;
   438  mmio_count = v3->mmio_count;
   439  mmio_count_max = DMC_V3_MAX_MMIO_COUNT;
   440  /* header_len is in dwords */
   441  header_len_bytes = dmc_header->header_len * 4;
   442  start_mmioaddr = v3->start_mmioaddr;
   443  dmc_header_size = sizeof(*v3);
   444  } else if (dmc_header->header_ver == 1) {
   445  const struct intel_dmc_header_v1 *v1 =
   446  (const struct intel_dmc_header_v1 *)dmc_header;
   447  
   448  if (rem_size < sizeof(struct intel_dmc_header_v1))
   449  goto error_truncated;
   450  
   451  mmioaddr = v1->mmioaddr;
   452  mmiodata = v1->mmiodata;
   453  mmio_count = v1->mmio_count;
   454  mmio_count_max = DMC_V1_MAX_MMIO_COUNT;
   455  header_len_bytes = dmc_header->header_len;
   456  start_mmioaddr = DMC_V1_MMIO_START_RANGE;
   457  dmc_header_size = sizeof(*v1);
   458  } else {
   459  drm_err(>drm, "Unknown DMC fw header version: 
%u\n"

Re: [Intel-gfx] [PATCH] drm/i915: Support Async Flip on Linear buffers

[kernel test robot]

Hi Arun,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip v5.18-rc4 next-20220426]
[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]

url:
https://github.com/intel-lab-lkp/linux/commits/Arun-R-Murthy/drm-i915-Support-Async-Flip-on-Linear-buffers/20220426-200801
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-a005 
(https://download.01.org/0day-ci/archive/20220427/202204271058.ofyrnpzv-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 
1cddcfdc3c683b393df1a5c9063252eb60e52818)
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/a31035350521698f7d7656a54a3b7e163257bf70
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Arun-R-Murthy/drm-i915-Support-Async-Flip-on-Linear-buffers/20220426-200801
git checkout a31035350521698f7d7656a54a3b7e163257bf70
# 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 as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/i915/display/intel_display.c:7532:3: warning: unannotated 
>> fall-through between switch labels [-Wimplicit-fallthrough]
   case I915_FORMAT_MOD_X_TILED:
   ^
   drivers/gpu/drm/i915/display/intel_display.c:7532:3: note: insert 'break;' 
to avoid fall-through
   case I915_FORMAT_MOD_X_TILED:
   ^
   break; 
   1 warning generated.


vim +7532 drivers/gpu/drm/i915/display/intel_display.c

b0b2bed2a1305c Ville Syrjälä 2022-02-14  7458  
b0b2bed2a1305c Ville Syrjälä 2022-02-14  7459  static int 
intel_async_flip_check_hw(struct intel_atomic_state *state, struct intel_crtc 
*crtc)
30ff93af9e19db Karthik B S   2020-09-21  7460  {
30ff93af9e19db Karthik B S   2020-09-21  7461   struct drm_i915_private 
*i915 = to_i915(state->base.dev);
30ff93af9e19db Karthik B S   2020-09-21  7462   const struct 
intel_crtc_state *old_crtc_state, *new_crtc_state;
30ff93af9e19db Karthik B S   2020-09-21  7463   const struct 
intel_plane_state *new_plane_state, *old_plane_state;
30ff93af9e19db Karthik B S   2020-09-21  7464   struct intel_plane 
*plane;
30ff93af9e19db Karthik B S   2020-09-21  7465   int i;
30ff93af9e19db Karthik B S   2020-09-21  7466  
0826edb6a5e5b3 José Roberto de Souza 2021-10-29  7467   old_crtc_state = 
intel_atomic_get_old_crtc_state(state, crtc);
0826edb6a5e5b3 José Roberto de Souza 2021-10-29  7468   new_crtc_state = 
intel_atomic_get_new_crtc_state(state, crtc);
0826edb6a5e5b3 José Roberto de Souza 2021-10-29  7469  
b0b2bed2a1305c Ville Syrjälä 2022-02-14  7470   if 
(!new_crtc_state->uapi.async_flip)
b0b2bed2a1305c Ville Syrjälä 2022-02-14  7471   return 0;
b0b2bed2a1305c Ville Syrjälä 2022-02-14  7472  
6b4e414ce8dab7 Ville Syrjälä 2022-02-14  7473   if 
(!new_crtc_state->hw.active) {
6b4e414ce8dab7 Ville Syrjälä 2022-02-14  7474   
drm_dbg_kms(>drm,
6b4e414ce8dab7 Ville Syrjälä 2022-02-14  7475   
"[CRTC:%d:%s] not active\n",
6b4e414ce8dab7 Ville Syrjälä 2022-02-14  7476   
crtc->base.base.id, crtc->base.name);
30ff93af9e19db Karthik B S   2020-09-21  7477   return -EINVAL;
30ff93af9e19db Karthik B S   2020-09-21  7478   }
30ff93af9e19db Karthik B S   2020-09-21  7479  
6b4e414ce8dab7 Ville Syrjälä 2022-02-14  7480   if 
(intel_crtc_needs_modeset(new_crtc_state)) {
6b4e414ce8dab7 Ville Syrjälä 2022-02-14  7481   
drm_dbg_kms(>drm,
6b4e414ce8dab7 Ville Syrjälä 2022-02-14  7482   
"[CRTC:%d:%s] modeset required\n",
6b4e414ce8dab7 Ville Syrjälä 2022-02-14  7483   
crtc->base.base.id, crtc->base.name);
30ff93af9e19db Karthik B S   2020-09-21  7484   return -EINVAL;
30ff93af9e19db Karthik B S   2020-09-21  7485   }
6b4e414ce8dab7 Ville Syrjälä 2022-02-14  7486  
30ff93af9e19db Karthik B S   2020-09-21  7487   if 
(old_crtc_state->active_planes != new_crtc_state->active_planes) {
30ff93af9e19db Karthik B S   2020-09-21  7488

Re: [Intel-gfx] [PATCH] drm/i915: Support Async Flip on Linear buffers

[Murthy, Arun R]

> On Tue, Apr 26, 2022 at 05:34:07PM +0530, Arun R Murthy wrote:
> > Starting from Gen12 Async Flip is supported on linear buffers.
> 
> It's supported earlier than that. But IIRC there was some kind of GTT
> alignment vs. async flip vs. FBC restriction that we weren't handling.
> 
Should I enable it for earlier Gen also, or is it fine to keep it with starting 
Gen 12.
The only restriction that I see in Bspec is that during async flip changes
to stride, pixel format, compression, FBC etc is not allowed and I see
this is already taken care of. Am I missing anything?

Thanks and Regards,
Arun R Murthy

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pmu: Use existing uncore helper to read gpm_timestamp

[Patchwork]

== Series Details ==

Series: drm/i915/pmu: Use existing uncore helper to read gpm_timestamp
URL   : https://patchwork.freedesktop.org/series/103189/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103189v1_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_103189v1_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_103189v1_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 -> 13)
--

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@busy-flip@b-edp1:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/igt@kms_flip@busy-f...@b-edp1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103189v1/shard-skl2/igt@kms_flip@busy-f...@b-edp1.html

  
 Suppressed 

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

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][3] +3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103189v1/shard-dg1-12/igt@gem_ctx_isolation@preservation...@rcs0.html

  * {igt@kms_concurrent@pipe-d@hdmi-a-1}:
- {shard-dg1}:NOTRUN -> [CRASH][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103189v1/shard-dg1-19/igt@kms_concurrent@pip...@hdmi-a-1.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-glk:  ([PASS][5], [PASS][6], [PASS][7], [PASS][8], 
[PASS][9], [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]) -> ([FAIL][30], [PASS][31], [PASS][32], 
[PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], 
[PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], 
[PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], 
[PASS][51], [PASS][52], [PASS][53], [PASS][54]) ([i915#4392])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk1/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk1/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk2/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk2/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk2/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk3/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk3/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk4/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk4/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk4/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk5/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk5/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk5/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk6/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk6/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk6/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk7/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk7/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk7/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk8/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk8/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk8/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk9/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk9/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-glk9/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103189v1/shard-glk9/boot.html
   [31]: 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dmc: Add MMIO range restrictions (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/dmc: Add MMIO range restrictions (rev3)
URL   : https://patchwork.freedesktop.org/series/102168/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11550 -> Patchwork_102168v3


Summary
---

  **FAILURE**

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

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

Participating hosts (43 -> 44)
--

  Additional (2): fi-kbl-x1275 bat-dg1-6 
  Missing(1): fi-bsw-cyan 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s0@smem:
- fi-kbl-guc: [PASS][1] -> [DMESG-WARN][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-kbl-guc/igt@gem_exec_suspend@basic...@smem.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102168v3/fi-kbl-guc/igt@gem_exec_suspend@basic...@smem.html
- fi-glk-j4005:   [PASS][3] -> [DMESG-WARN][4] +2 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-glk-j4005/igt@gem_exec_suspend@basic...@smem.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102168v3/fi-glk-j4005/igt@gem_exec_suspend@basic...@smem.html
- fi-kbl-x1275:   NOTRUN -> [DMESG-WARN][5] +2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102168v3/fi-kbl-x1275/igt@gem_exec_suspend@basic...@smem.html
- fi-skl-6700k2:  [PASS][6] -> [DMESG-WARN][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-skl-6700k2/igt@gem_exec_suspend@basic...@smem.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102168v3/fi-skl-6700k2/igt@gem_exec_suspend@basic...@smem.html
- fi-kbl-7567u:   [PASS][8] -> [DMESG-WARN][9] +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-kbl-7567u/igt@gem_exec_suspend@basic...@smem.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102168v3/fi-kbl-7567u/igt@gem_exec_suspend@basic...@smem.html
- fi-rkl-11600:   [PASS][10] -> [DMESG-WARN][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102168v3/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-skl-guc: [PASS][12] -> [DMESG-WARN][13] +2 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-skl-guc/igt@gem_exec_suspend@basic...@smem.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102168v3/fi-skl-guc/igt@gem_exec_suspend@basic...@smem.html
- fi-cfl-guc: [PASS][14] -> [DMESG-WARN][15] +2 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-guc/igt@gem_exec_suspend@basic...@smem.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102168v3/fi-cfl-guc/igt@gem_exec_suspend@basic...@smem.html
- fi-bxt-dsi: [PASS][16] -> [DMESG-WARN][17] +2 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bxt-dsi/igt@gem_exec_suspend@basic...@smem.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102168v3/fi-bxt-dsi/igt@gem_exec_suspend@basic...@smem.html
- fi-rkl-guc: [PASS][18] -> [DMESG-WARN][19] +2 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-rkl-guc/igt@gem_exec_suspend@basic...@smem.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102168v3/fi-rkl-guc/igt@gem_exec_suspend@basic...@smem.html
- fi-adl-ddr5:[PASS][20] -> [DMESG-WARN][21] +2 similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-adl-ddr5/igt@gem_exec_suspend@basic...@smem.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102168v3/fi-adl-ddr5/igt@gem_exec_suspend@basic...@smem.html
- fi-tgl-1115g4:  [PASS][22] -> [DMESG-WARN][23] +2 similar issues
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-tgl-1115g4/igt@gem_exec_suspend@basic...@smem.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102168v3/fi-tgl-1115g4/igt@gem_exec_suspend@basic...@smem.html
- fi-kbl-7500u:   [PASS][24] -> [DMESG-WARN][25] +2 similar issues
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-kbl-7500u/igt@gem_exec_suspend@basic...@smem.html
   [25]: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dmc: Add MMIO range restrictions (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/dmc: Add MMIO range restrictions (rev3)
URL   : https://patchwork.freedesktop.org/series/102168/
State : warning

== Summary ==

Error: dim checkpatch failed
f6bceb457fc4 drm/i915/dmc: Add MMIO range restrictions
-:58: WARNING:LONG_LINE: line length of 111 exceeds 100 columns
#58: FILE: drivers/gpu/drm/i915/display/intel_dmc.c:386:
+   if (mmioaddr[i] < TGL_DMC_MMIO_START(dmc_id) || 
mmioaddr[i] > TGL_DMC_MMIO_END(dmc_id))

-:71: WARNING:LONG_LINE: line length of 111 exceeds 100 columns
#71: FILE: drivers/gpu/drm/i915/display/intel_dmc.c:399:
+   if (mmioaddr[i] < TGL_DMC_MMIO_START(dmc_id) || 
mmioaddr[i] > TGL_DMC_MMIO_END(dmc_id))

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Use existing uncore helper to read gpm_timestamp

[Patchwork]

== Series Details ==

Series: drm/i915/pmu: Use existing uncore helper to read gpm_timestamp
URL   : https://patchwork.freedesktop.org/series/103189/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103189v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 44)
--

  Additional (3): fi-kbl-x1275 bat-adlm-1 bat-dg1-6 
  Missing(2): fi-hsw-4770 fi-bsw-cyan 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6:  NOTRUN -> [INCOMPLETE][1] ([i915#5827])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103189v1/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u:   [PASS][2] -> [INCOMPLETE][3] ([i915#146])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103189v1/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-x1275:   NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103189v1/fi-kbl-x1275/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@verify-random:
- fi-kbl-x1275:   NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103189v1/fi-kbl-x1275/igt@gem_lmem_swapp...@verify-random.html

  * igt@i915_module_load@reload:
- fi-kbl-soraka:  [PASS][6] -> [DMESG-WARN][7] ([i915#1982])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-kbl-soraka/igt@i915_module_l...@reload.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103189v1/fi-kbl-soraka/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [PASS][8] -> [INCOMPLETE][9] ([i915#4983])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103189v1/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@gt_pm:
- fi-tgl-1115g4:  [PASS][10] -> [DMESG-FAIL][11] ([i915#3987])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-tgl-1115g4/igt@i915_selftest@live@gt_pm.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103189v1/fi-tgl-1115g4/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-kbl-x1275:   NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103189v1/fi-kbl-x1275/igt@kms_chamel...@hdmi-crc-fast.html

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

  * igt@kms_psr@primary_page_flip:
- fi-kbl-x1275:   NOTRUN -> [SKIP][14] ([fdo#109271]) +12 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103189v1/fi-kbl-x1275/igt@kms_psr@primary_page_flip.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-guc: [DMESG-FAIL][15] ([i915#5334]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103189v1/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][17] ([i915#3921]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103189v1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@hugepages:
- {bat-rpls-1}:   [DMESG-WARN][19] ([i915#5278]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-1/igt@i915_selftest@l...@hugepages.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103189v1/bat-rpls-1/igt@i915_selftest@l...@hugepages.html

  * igt@i915_selftest@live@reset:
- {bat-rpls-1}:   [DMESG-FAIL][21] ([i915#4983]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-1/igt@i915_selftest@l...@reset.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103189v1/bat-rpls-1/igt@i915_selftest@l...@reset.html

  
 Warnings 

  * 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Prepare for GSC-loaded HuC

[Patchwork]

== Series Details ==

Series: drm/i915: Prepare for GSC-loaded HuC
URL   : https://patchwork.freedesktop.org/series/103186/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103186v1


Summary
---

  **FAILURE**

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

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

Participating hosts (43 -> 44)
--

  Additional (2): fi-kbl-x1275 bat-dg1-6 
  Missing(1): fi-bsw-cyan 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s0@smem:
- fi-skl-guc: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-skl-guc/igt@gem_exec_suspend@basic...@smem.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103186v1/fi-skl-guc/igt@gem_exec_suspend@basic...@smem.html

  
 Warnings 

  * igt@debugfs_test@read_all_entries:
- fi-apl-guc: [DMESG-WARN][3] ([i915#5595]) -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-apl-guc/igt@debugfs_test@read_all_entries.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103186v1/fi-apl-guc/igt@debugfs_test@read_all_entries.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0@smem:
- fi-kbl-guc: [PASS][5] -> [INCOMPLETE][6] ([i915#4831])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-kbl-guc/igt@gem_exec_suspend@basic...@smem.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103186v1/fi-kbl-guc/igt@gem_exec_suspend@basic...@smem.html
- bat-dg1-6:  NOTRUN -> [INCOMPLETE][7] ([i915#5827])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103186v1/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html
- fi-cfl-guc: [PASS][8] -> [INCOMPLETE][9] ([i915#4831])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-guc/igt@gem_exec_suspend@basic...@smem.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103186v1/fi-cfl-guc/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-x1275:   NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#2190])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103186v1/fi-kbl-x1275/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@verify-random:
- fi-kbl-x1275:   NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103186v1/fi-kbl-x1275/igt@gem_lmem_swapp...@verify-random.html

  * igt@i915_selftest@live@mman:
- fi-bdw-5557u:   NOTRUN -> [INCOMPLETE][12] ([i915#5704])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103186v1/fi-bdw-5557u/igt@i915_selftest@l...@mman.html

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

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-kbl-x1275:   NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103186v1/fi-kbl-x1275/igt@kms_chamel...@hdmi-crc-fast.html

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

  * igt@kms_psr@primary_page_flip:
- fi-kbl-x1275:   NOTRUN -> [SKIP][16] ([fdo#109271]) +12 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103186v1/fi-kbl-x1275/igt@kms_psr@primary_page_flip.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-bdw-5557u:   NOTRUN -> [SKIP][17] ([fdo#109271]) +14 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103186v1/fi-bdw-5557u/igt@kms_setm...@basic-clone-single-crtc.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][18] ([i915#3921]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [19]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Prepare for GSC-loaded HuC

[Patchwork]

== Series Details ==

Series: drm/i915: Prepare for GSC-loaded HuC
URL   : https://patchwork.freedesktop.org/series/103186/
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: Prepare for GSC-loaded HuC

[Patchwork]

== Series Details ==

Series: drm/i915: Prepare for GSC-loaded HuC
URL   : https://patchwork.freedesktop.org/series/103186/
State : warning

== Summary ==

Error: dim checkpatch failed
8916eb4e3081 drm/i915/huc: check HW directly for HuC auth status
0cbbd92e569f drm/i915/huc: Add fetch support for gsc-loaded HuC binary
f17e836d85dc drm/i915/huc: Prepare for GSC-loaded HuC
-:22: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#22: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h:99:
+#define   GSC_LOADS_HUC(1<<30)
  ^

total: 0 errors, 0 warnings, 1 checks, 177 lines checked
120b114272a8 drm/i915/huc: Don't fail the probe if HuC init fails

[Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions

[Anusha Srivatsa]

Bspec has added some steps that check forDMC MMIO range before
programming them

v2: Fix for CI
v3: move register defines to .h (Anusha)
- Check MMIO restrictions per pipe
- Add MMIO restricton for v1 dmc header as well (Lucas)

BSpec: 49193

Cc: 
Cc: Lucas De Marchi 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_dmc.c  | 48 ---
 drivers/gpu/drm/i915/display/intel_dmc_regs.h | 31 
 2 files changed, 72 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 257cf662f9f4..ac7896835bfa 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -97,13 +97,6 @@ MODULE_FIRMWARE(SKL_DMC_PATH);
 #define BXT_DMC_MAX_FW_SIZE0x3000
 MODULE_FIRMWARE(BXT_DMC_PATH);
 
-#define DMC_DEFAULT_FW_OFFSET  0x
-#define PACKAGE_MAX_FW_INFO_ENTRIES20
-#define PACKAGE_V2_MAX_FW_INFO_ENTRIES 32
-#define DMC_V1_MAX_MMIO_COUNT  8
-#define DMC_V3_MAX_MMIO_COUNT  20
-#define DMC_V1_MMIO_START_RANGE0x8
-
 struct intel_css_header {
/* 0x09 for DMC */
u32 module_type;
@@ -374,6 +367,43 @@ static void dmc_set_fw_offset(struct intel_dmc *dmc,
}
 }
 
+static bool dmc_mmio_addr_sanity_check(struct intel_dmc *dmc, const u32 
*mmioaddr,
+  u32 mmio_count, int header_ver, u8 
dmc_id)
+{
+   struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc);
+   int i;
+
+   if (header_ver == 1) {
+   for (i = 0; i < mmio_count; i++) {
+   if (mmioaddr[i] < DMC_MMIO_START_RANGE || mmioaddr[i] > 
DMC_MMIO_END_RANGE)
+   return false;
+   }
+   }
+
+   /* Main DMC MMIO check */
+   if (dmc_id == DMC_FW_MAIN) {
+   for (i = 0; i < mmio_count; i++) {
+   if (mmioaddr[i] < TGL_DMC_MMIO_START(dmc_id) || 
mmioaddr[i] > TGL_DMC_MMIO_END(dmc_id))
+   return false;
+   }
+   }
+
+   /* Pipe DMC MMIO check */
+   if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
+   for (i = 0; i < mmio_count; i++) {
+   if (mmioaddr[i] < ADLP_PIPE_MMIO_START && mmioaddr[i] > 
ADLP_PIPE_MMIO_END)
+   return false;
+   }
+   } else if (IS_TIGERLAKE(i915) || IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
+   for (i = 0; i < mmio_count; i++) {
+   if (mmioaddr[i] < TGL_DMC_MMIO_START(dmc_id) || 
mmioaddr[i] > TGL_DMC_MMIO_END(dmc_id))
+   return false;
+   }
+   }
+
+   return true;
+}
+
 static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
   const struct intel_dmc_header_base *dmc_header,
   size_t rem_size, u8 dmc_id)
@@ -443,6 +473,10 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
return 0;
}
 
+   if (!dmc_mmio_addr_sanity_check(dmc, mmioaddr, mmio_count, 
dmc_header->header_ver, dmc_id))
+   drm_err(>drm, "DMC firmware has Wrong MMIO Addresses\n");
+   return 0;
+
for (i = 0; i < mmio_count; i++) {
dmc_info->mmioaddr[i] = _MMIO(mmioaddr[i]);
dmc_info->mmiodata[i] = mmiodata[i];
diff --git a/drivers/gpu/drm/i915/display/intel_dmc_regs.h 
b/drivers/gpu/drm/i915/display/intel_dmc_regs.h
index d65e698832eb..235d1b721334 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc_regs.h
+++ b/drivers/gpu/drm/i915/display/intel_dmc_regs.h
@@ -11,12 +11,43 @@
 #define DMC_PROGRAM(addr, i)   _MMIO((addr) + (i) * 4)
 #define DMC_SSP_BASE_ADDR_GEN9 0x2FC0
 #define DMC_HTP_ADDR_SKL   0x00500034
+#define DMC_DEFAULT_FW_OFFSET  0x
 #define DMC_SSP_BASE   _MMIO(0x8F074)
 #define DMC_HTP_SKL_MMIO(0x8F004)
 #define DMC_LAST_WRITE _MMIO(0x8F034)
 #define DMC_LAST_WRITE_VALUE   0xc003b400
 #define DMC_MMIO_START_RANGE   0x8
 #define DMC_MMIO_END_RANGE 0x8
+#define PACKAGE_MAX_FW_INFO_ENTRIES20
+#define PACKAGE_V2_MAX_FW_INFO_ENTRIES 32
+#define DMC_V1_MAX_MMIO_COUNT  8
+#define DMC_V3_MAX_MMIO_COUNT  20
+#define DMC_V1_MMIO_START_RANGE0x8
+#define _TGL_MAIN_MMIO_START   0x8F000
+#define _TGL_MAIN_MMIO_END 0x8
+#define _TGL_PIPEA_MMIO_START  0x92000
+#define _TGL_PIPEA_MMIO_END0x93FFF
+#define _TGL_PIPEB_MMIO_START  0x96000
+#define _TGL_PIPEB_MMIO_END0x97FFF
+#define _TGL_PIPEC_MMIO_START  0x9A000
+#define _TGL_PIPEC_MMIO_END0x9BFFF
+#define _TGL_PIPED_MMIO_START  0x9E000
+#define _TGL_PIPED_MMIO_END0x9
+#define ADLP_PIPE_MMIO_START   0x5F000
+#define ADLP_PIPE_MMIO_END 0x5
+
+#define 

[Intel-gfx] [PATCH] drm/i915/pmu: Use existing uncore helper to read gpm_timestamp

[Umesh Nerlige Ramappa]

Use intel_uncore_read64_2x32 to read upper and lower fields of the GPM
timestamp.

v2: Fix compile error

Signed-off-by: Umesh Nerlige Ramappa 
---
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c   | 17 ++---
 1 file changed, 2 insertions(+), 15 deletions(-)

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 61a6f2424e24..33e695adfd6a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1200,20 +1200,6 @@ static u32 gpm_timestamp_shift(struct intel_gt *gt)
return 3 - shift;
 }
 
-static u64 gpm_timestamp(struct intel_gt *gt)
-{
-   u32 lo, hi, old_hi, loop = 0;
-
-   hi = intel_uncore_read(gt->uncore, MISC_STATUS1);
-   do {
-   lo = intel_uncore_read(gt->uncore, MISC_STATUS0);
-   old_hi = hi;
-   hi = intel_uncore_read(gt->uncore, MISC_STATUS1);
-   } while (old_hi != hi && loop++ < 2);
-
-   return ((u64)hi << 32) | lo;
-}
-
 static void guc_update_pm_timestamp(struct intel_guc *guc, ktime_t *now)
 {
struct intel_gt *gt = guc_to_gt(guc);
@@ -1223,7 +1209,8 @@ static void guc_update_pm_timestamp(struct intel_guc 
*guc, ktime_t *now)
lockdep_assert_held(>timestamp.lock);
 
gt_stamp_hi = upper_32_bits(guc->timestamp.gt_stamp);
-   gpm_ts = gpm_timestamp(gt) >> guc->timestamp.shift;
+   gpm_ts = intel_uncore_read64_2x32(gt->uncore, MISC_STATUS0,
+ MISC_STATUS1) >> guc->timestamp.shift;
gt_stamp_lo = lower_32_bits(gpm_ts);
*now = ktime_get();
 
-- 
2.35.1

[Intel-gfx] [PATCH 2/4] drm/i915/huc: Add fetch support for gsc-loaded HuC binary

[Daniele Ceraolo Spurio]

On newer platforms (starting DG2 G10 B-step and G11 A-step), ownership of
HuC loading has been moved from the GuC to the GSC. As part of the
change, the header format of the HuC binary has been updated and does not
match the GuC anymore. The GSC will perform all the required checks on
the binary size, so we only need to check that the version matches.

Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 99 
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |  2 +
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h |  9 ++
 3 files changed, 72 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index cb5dd16421d0d..8d602d87a7295 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -301,45 +301,31 @@ static void __force_fw_fetch_failures(struct intel_uc_fw 
*uc_fw, int e)
}
 }
 
-/**
- * intel_uc_fw_fetch - fetch uC firmware
- * @uc_fw: uC firmware
- *
- * Fetch uC firmware into GEM obj.
- *
- * Return: 0 on success, a negative errno code on failure.
- */
-int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
+static int check_gsc_manifest(const struct firmware *fw,
+ struct intel_uc_fw *uc_fw)
 {
-   struct drm_i915_private *i915 = __uc_fw_to_gt(uc_fw)->i915;
-   struct device *dev = i915->drm.dev;
-   struct drm_i915_gem_object *obj;
-   const struct firmware *fw = NULL;
-   struct uc_css_header *css;
-   size_t size;
-   int err;
+   u32 *dw = (u32 *)fw->data;
+   u32 version = dw[HUC_GSC_VERSION_DW];
 
-   GEM_BUG_ON(!i915->wopcm.size);
-   GEM_BUG_ON(!intel_uc_fw_is_enabled(uc_fw));
-
-   err = i915_inject_probe_error(i915, -ENXIO);
-   if (err)
-   goto fail;
+   uc_fw->major_ver_found = FIELD_GET(HUC_GSC_MAJOR_VER_MASK, version);
+   uc_fw->minor_ver_found = FIELD_GET(HUC_GSC_MINOR_VER_MASK, version);
 
-   __force_fw_fetch_failures(uc_fw, -EINVAL);
-   __force_fw_fetch_failures(uc_fw, -ESTALE);
+   return 0;
+}
 
-   err = request_firmware(, uc_fw->path, dev);
-   if (err)
-   goto fail;
+static int check_ccs_header(struct drm_i915_private *i915,
+   const struct firmware *fw,
+   struct intel_uc_fw *uc_fw)
+{
+   struct uc_css_header *css;
+   size_t size;
 
/* Check the size of the blob before examining buffer contents */
if (unlikely(fw->size < sizeof(struct uc_css_header))) {
drm_warn(>drm, "%s firmware %s: invalid size: %zu < 
%zu\n",
 intel_uc_fw_type_repr(uc_fw->type), uc_fw->path,
 fw->size, sizeof(struct uc_css_header));
-   err = -ENODATA;
-   goto fail;
+   return -ENODATA;
}
 
css = (struct uc_css_header *)fw->data;
@@ -352,8 +338,7 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
 "%s firmware %s: unexpected header size: %zu != %zu\n",
 intel_uc_fw_type_repr(uc_fw->type), uc_fw->path,
 fw->size, sizeof(struct uc_css_header));
-   err = -EPROTO;
-   goto fail;
+   return -EPROTO;
}
 
/* uCode size must calculated from other sizes */
@@ -368,8 +353,7 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
drm_warn(>drm, "%s firmware %s: invalid size: %zu < 
%zu\n",
 intel_uc_fw_type_repr(uc_fw->type), uc_fw->path,
 fw->size, size);
-   err = -ENOEXEC;
-   goto fail;
+   return -ENOEXEC;
}
 
/* Sanity check whether this fw is not larger than whole WOPCM memory */
@@ -378,8 +362,7 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
drm_warn(>drm, "%s firmware %s: invalid size: %zu > 
%zu\n",
 intel_uc_fw_type_repr(uc_fw->type), uc_fw->path,
 size, (size_t)i915->wopcm.size);
-   err = -E2BIG;
-   goto fail;
+   return -E2BIG;
}
 
/* Get version numbers from the CSS header */
@@ -388,6 +371,49 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
uc_fw->minor_ver_found = FIELD_GET(CSS_SW_VERSION_UC_MINOR,
   css->sw_version);
 
+   if (uc_fw->type == INTEL_UC_FW_TYPE_GUC)
+   uc_fw->private_data_size = css->private_data_size;
+
+   return 0;
+}
+
+/**
+ * intel_uc_fw_fetch - fetch uC firmware
+ * @uc_fw: uC firmware
+ *
+ * Fetch uC firmware into GEM obj.
+ *
+ * Return: 0 on success, a negative errno code on failure.
+ */
+int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
+{
+   struct drm_i915_private *i915 = __uc_fw_to_gt(uc_fw)->i915;
+   struct device *dev = i915->drm.dev;
+   

[Intel-gfx] [PATCH 1/4] drm/i915/huc: check HW directly for HuC auth status

[Daniele Ceraolo Spurio]

The huc_is_authenticated function return is based on our SW tracking of
the HuC auth status. However, around suspend/resume and reset this can
go out of sync with the actual HW state, which is why we use
huc_check_state() to look at the actual HW state. Instead of having this
duality, just make huc_is_authenticated() return the HW state and use it
everywhere we need to know if HuC is running.

Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/uc/intel_huc.c | 23 ++-
 drivers/gpu/drm/i915/gt/uc/intel_huc.h |  5 -
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 556829de9c172..773020e69589a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -80,6 +80,18 @@ void intel_huc_fini(struct intel_huc *huc)
intel_uc_fw_fini(>fw);
 }
 
+static bool huc_is_authenticated(struct intel_huc *huc)
+{
+   struct intel_gt *gt = huc_to_gt(huc);
+   intel_wakeref_t wakeref;
+   u32 status = 0;
+
+   with_intel_runtime_pm(gt->uncore->rpm, wakeref)
+   status = intel_uncore_read(gt->uncore, huc->status.reg);
+
+   return (status & huc->status.mask) == huc->status.value;
+}
+
 /**
  * intel_huc_auth() - Authenticate HuC uCode
  * @huc: intel_huc structure
@@ -96,7 +108,7 @@ int intel_huc_auth(struct intel_huc *huc)
struct intel_guc *guc = >uc.guc;
int ret;
 
-   GEM_BUG_ON(intel_huc_is_authenticated(huc));
+   GEM_BUG_ON(huc_is_authenticated(huc));
 
if (!intel_uc_fw_is_loaded(>fw))
return -ENOEXEC;
@@ -150,10 +162,6 @@ int intel_huc_auth(struct intel_huc *huc)
  */
 int intel_huc_check_status(struct intel_huc *huc)
 {
-   struct intel_gt *gt = huc_to_gt(huc);
-   intel_wakeref_t wakeref;
-   u32 status = 0;
-
switch (__intel_uc_fw_status(>fw)) {
case INTEL_UC_FIRMWARE_NOT_SUPPORTED:
return -ENODEV;
@@ -167,10 +175,7 @@ int intel_huc_check_status(struct intel_huc *huc)
break;
}
 
-   with_intel_runtime_pm(gt->uncore->rpm, wakeref)
-   status = intel_uncore_read(gt->uncore, huc->status.reg);
-
-   return (status & huc->status.mask) == huc->status.value;
+   return huc_is_authenticated(huc);
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index 73ec670800f2b..77d813840d76c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
@@ -50,11 +50,6 @@ static inline bool intel_huc_is_used(struct intel_huc *huc)
return intel_uc_fw_is_available(>fw);
 }
 
-static inline bool intel_huc_is_authenticated(struct intel_huc *huc)
-{
-   return intel_uc_fw_is_running(>fw);
-}
-
 void intel_huc_load_status(struct intel_huc *huc, struct drm_printer *p);
 
 #endif
-- 
2.25.1

[Intel-gfx] [PATCH 3/4] drm/i915/huc: Prepare for GSC-loaded HuC

[Daniele Ceraolo Spurio]

HuC loading via GSC is performed via a PXP command sent through the mei
modules, so we need both MEI_GSC and MEI_PXP to be available. Given that
the GSC will do both the transfer and the authentication, the legacy HuC
loading paths can be safely skipped.
Also note that the GSC-loaded HuC survives GT reset.

Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h |  1 +
 drivers/gpu/drm/i915/gt/uc/intel_huc.c | 76 +++---
 drivers/gpu/drm/i915/gt/uc/intel_huc.h |  6 ++
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c  |  5 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc.c  | 11 +++-
 5 files changed, 88 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
index 66027a42cda9e..2516705b9f365 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
@@ -96,6 +96,7 @@
 
 #define GUC_SHIM_CONTROL2  _MMIO(0xc068)
 #define   GUC_IS_PRIVILEGED(1<<29)
+#define   GSC_LOADS_HUC(1<<30)
 
 #define GUC_SEND_INTERRUPT _MMIO(0xc4c8)
 #define   GUC_SEND_TRIGGER   (1<<0)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 773020e69589a..76a7df7f136fc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -6,6 +6,7 @@
 #include 
 
 #include "gt/intel_gt.h"
+#include "intel_guc_reg.h"
 #include "intel_huc.h"
 #include "i915_drv.h"
 
@@ -17,11 +18,15 @@
  * capabilities by adding HuC specific commands to batch buffers.
  *
  * The kernel driver is only responsible for loading the HuC firmware and
- * triggering its security authentication, which is performed by the GuC. For
- * The GuC to correctly perform the authentication, the HuC binary must be
- * loaded before the GuC one. Loading the HuC is optional; however, not using
- * the HuC might negatively impact power usage and/or performance of media
- * workloads, depending on the use-cases.
+ * triggering its security authentication, which is performed by the GuC on
+ * older platforms and by the GSC on newer ones. For the GuC to correctly
+ * perform the authentication, the HuC binary must be loaded before the GuC 
one.
+ * Loading the HuC is optional; however, not using the HuC might negatively
+ * impact power usage and/or performance of media workloads, depending on the
+ * use-cases.
+ * HuC must be reloaded on events that cause the WOPCM to lose its contents
+ * (S3/S4, FLR); GuC-authenticated HuC must also be reloaded on GuC/GT reset,
+ * while GSC-managed HuC will survive that.
  *
  * See https://github.com/intel/media-driver for the latest details on HuC
  * functionality.
@@ -54,11 +59,51 @@ void intel_huc_init_early(struct intel_huc *huc)
}
 }
 
+#define HUC_LOAD_MODE_STRING(x) (x ? "GSC" : "legacy")
+static int check_huc_loading_mode(struct intel_huc *huc)
+{
+   struct intel_gt *gt = huc_to_gt(huc);
+   bool fw_needs_gsc = intel_huc_is_loaded_by_gsc(huc);
+   bool hw_uses_gsc = false;
+
+   /*
+* The fuse for HuC load via GSC is only valid on platforms that have
+* GuC deprivilege.
+*/
+   if (HAS_GUC_DEPRIVILEGE(gt->i915))
+   hw_uses_gsc = intel_uncore_read(gt->uncore, GUC_SHIM_CONTROL2) &
+ GSC_LOADS_HUC;
+
+   if (fw_needs_gsc != hw_uses_gsc) {
+   drm_err(>i915->drm,
+   "mismatch between HuC FW (%s) and HW (%s) load modes\n",
+   HUC_LOAD_MODE_STRING(fw_needs_gsc),
+   HUC_LOAD_MODE_STRING(hw_uses_gsc));
+   return -ENOEXEC;
+   }
+
+   /* make sure we can access the GSC via the mei driver if we need it */
+   if (!(IS_ENABLED(CONFIG_INTEL_MEI_PXP) && 
IS_ENABLED(CONFIG_INTEL_MEI_GSC)) &&
+   fw_needs_gsc) {
+   drm_info(>i915->drm,
+"Can't load HuC due to missing MEI modules\n");
+   return -EIO;
+   }
+
+   drm_dbg(>i915->drm, "GSC loads huc=%s\n", str_yes_no(fw_needs_gsc));
+
+   return 0;
+}
+
 int intel_huc_init(struct intel_huc *huc)
 {
struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
int err;
 
+   err = check_huc_loading_mode(huc);
+   if (err)
+   goto out;
+
err = intel_uc_fw_init(>fw);
if (err)
goto out;
@@ -108,17 +153,20 @@ int intel_huc_auth(struct intel_huc *huc)
struct intel_guc *guc = >uc.guc;
int ret;
 
-   GEM_BUG_ON(huc_is_authenticated(huc));
-
if (!intel_uc_fw_is_loaded(>fw))
return -ENOEXEC;
 
+   /* GSC will do the auth */
+   if (intel_huc_is_loaded_by_gsc(huc))
+   return -ENODEV;
+
ret = i915_inject_probe_error(gt->i915, -ENXIO);
if (ret)
goto fail;
 
-   ret = 

[Intel-gfx] [PATCH 4/4] drm/i915/huc: Don't fail the probe if HuC init fails

[Daniele Ceraolo Spurio]

The previous patch introduced new failure cases in the HuC init flow
that can be hit by simply changing the config, so we want to avoid
failing the probe in those scenarios. HuC load failure is already
considered a non-fatal error and we have a way to report to userspace
if the HuC is not available via a dedicated getparam, so no changes
in expectation there.
The error message in the HuC init code has also been lowered to info to
avoid throwing error message for an expected behavior.

Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/uc/intel_huc.c |  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc.c  | 11 ++-
 2 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 76a7df7f136fc..3d2e7a6d7c1b7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -113,7 +113,7 @@ int intel_huc_init(struct intel_huc *huc)
return 0;
 
 out:
-   i915_probe_error(i915, "failed with %d\n", err);
+   drm_info(>drm, "HuC init failed with %d\n", err);
return err;
 }
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 0dce94f896a8c..ecf149c5fdb02 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -323,17 +323,10 @@ static int __uc_init(struct intel_uc *uc)
if (ret)
return ret;
 
-   if (intel_uc_uses_huc(uc)) {
-   ret = intel_huc_init(huc);
-   if (ret)
-   goto out_guc;
-   }
+   if (intel_uc_uses_huc(uc))
+   intel_huc_init(huc);
 
return 0;
-
-out_guc:
-   intel_guc_fini(guc);
-   return ret;
 }
 
 static void __uc_fini(struct intel_uc *uc)
-- 
2.25.1

[Intel-gfx] [PATCH 0/4] drm/i915: Prepare for GSC-loaded HuC

[Daniele Ceraolo Spurio]

On newer platforms (starting DG2 G10 B-step and G11 A-step), ownership of
HuC loading and authentication has been moved from the GuC to the GSC, with
both actions being performed via a single PXP command.
Given that the mei code has not fully landed yet (see [1]), we can't
implement the new load mechanism, but we can start getting ready for it
by taking care of the changes required for the existing code:

- The HuC header is now different from the GuC one. This also means that
  if the FW is for GSC-loading and the HW fuse is set to legacy load (or
  vice-versa) we can't load the HuC.

- To send a PXP message to the GSC we need both MEI_GSC and MEI_PXP.

- All legacy HuC loading paths can be skipped.

Note that the HuC fw version for DG2 is still not defined, so the HuC
code will be skipped until the define is added.

[1] https://patchwork.freedesktop.org/series/102339/

Cc: Alan Previn 
Cc: John Harrison 

Daniele Ceraolo Spurio (4):
  drm/i915/huc: check HW directly for HuC auth status
  drm/i915/huc: Add fetch support for gsc-loaded HuC binary
  drm/i915/huc: Prepare for GSC-loaded HuC
  drm/i915/huc: Don't fail the probe if HuC init fails

 drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h   |  1 +
 drivers/gpu/drm/i915/gt/uc/intel_huc.c   | 97 +++
 drivers/gpu/drm/i915/gt/uc/intel_huc.h   |  5 +-
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c|  5 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc.c| 22 +++--
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 99 
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |  2 +
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h |  9 ++
 8 files changed, 172 insertions(+), 68 deletions(-)

-- 
2.25.1

Re: [Intel-gfx] [PATCH] drm/i915: Support Async Flip on Linear buffers

[kernel test robot]

Hi Arun,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip v5.18-rc4 next-20220426]
[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]

url:
https://github.com/intel-lab-lkp/linux/commits/Arun-R-Murthy/drm-i915-Support-Async-Flip-on-Linear-buffers/20220426-200801
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-a002-20220425 
(https://download.01.org/0day-ci/archive/20220427/202204270658.1ytrplya-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 
1cddcfdc3c683b393df1a5c9063252eb60e52818)
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/a31035350521698f7d7656a54a3b7e163257bf70
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Arun-R-Murthy/drm-i915-Support-Async-Flip-on-Linear-buffers/20220426-200801
git checkout a31035350521698f7d7656a54a3b7e163257bf70
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=i386 SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/i915/display/intel_display.c:7532:3: error: unannotated 
>> fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
   case I915_FORMAT_MOD_X_TILED:
   ^
   drivers/gpu/drm/i915/display/intel_display.c:7532:3: note: insert 'break;' 
to avoid fall-through
   case I915_FORMAT_MOD_X_TILED:
   ^
   break; 
   1 error generated.


vim +7532 drivers/gpu/drm/i915/display/intel_display.c

b0b2bed2a1305c Ville Syrjälä 2022-02-14  7458  
b0b2bed2a1305c Ville Syrjälä 2022-02-14  7459  static int 
intel_async_flip_check_hw(struct intel_atomic_state *state, struct intel_crtc 
*crtc)
30ff93af9e19db Karthik B S   2020-09-21  7460  {
30ff93af9e19db Karthik B S   2020-09-21  7461   struct drm_i915_private 
*i915 = to_i915(state->base.dev);
30ff93af9e19db Karthik B S   2020-09-21  7462   const struct 
intel_crtc_state *old_crtc_state, *new_crtc_state;
30ff93af9e19db Karthik B S   2020-09-21  7463   const struct 
intel_plane_state *new_plane_state, *old_plane_state;
30ff93af9e19db Karthik B S   2020-09-21  7464   struct intel_plane 
*plane;
30ff93af9e19db Karthik B S   2020-09-21  7465   int i;
30ff93af9e19db Karthik B S   2020-09-21  7466  
0826edb6a5e5b3 José Roberto de Souza 2021-10-29  7467   old_crtc_state = 
intel_atomic_get_old_crtc_state(state, crtc);
0826edb6a5e5b3 José Roberto de Souza 2021-10-29  7468   new_crtc_state = 
intel_atomic_get_new_crtc_state(state, crtc);
0826edb6a5e5b3 José Roberto de Souza 2021-10-29  7469  
b0b2bed2a1305c Ville Syrjälä 2022-02-14  7470   if 
(!new_crtc_state->uapi.async_flip)
b0b2bed2a1305c Ville Syrjälä 2022-02-14  7471   return 0;
b0b2bed2a1305c Ville Syrjälä 2022-02-14  7472  
6b4e414ce8dab7 Ville Syrjälä 2022-02-14  7473   if 
(!new_crtc_state->hw.active) {
6b4e414ce8dab7 Ville Syrjälä 2022-02-14  7474   
drm_dbg_kms(>drm,
6b4e414ce8dab7 Ville Syrjälä 2022-02-14  7475   
"[CRTC:%d:%s] not active\n",
6b4e414ce8dab7 Ville Syrjälä 2022-02-14  7476   
crtc->base.base.id, crtc->base.name);
30ff93af9e19db Karthik B S   2020-09-21  7477   return -EINVAL;
30ff93af9e19db Karthik B S   2020-09-21  7478   }
30ff93af9e19db Karthik B S   2020-09-21  7479  
6b4e414ce8dab7 Ville Syrjälä 2022-02-14  7480   if 
(intel_crtc_needs_modeset(new_crtc_state)) {
6b4e414ce8dab7 Ville Syrjälä 2022-02-14  7481   
drm_dbg_kms(>drm,
6b4e414ce8dab7 Ville Syrjälä 2022-02-14  7482   
"[CRTC:%d:%s] modeset required\n",
6b4e414ce8dab7 Ville Syrjälä 2022-02-14  7483   
crtc->base.base.id, crtc->base.name);
30ff93af9e19db Karthik B S   2020-09-21  7484   return -EINVAL;
30ff93af9e19db Karthik B S   2020-09-21  7485   }
6b4e414ce8dab7 Ville Syrjälä 2022-02-14  7486  
30ff93af9e19db Karthik B S   2020-09-21  7487   if 
(old_crtc_state->active_planes != new_crtc_state->active_planes) {
30ff93af9e19db Karthik B S   2020-09-21  7488

Re: [Intel-gfx] [RFC v2 1/2] drm/vrr: Attach vrr_enabled property to the drm crtc

[Navare, Manasi]

On Mon, Apr 25, 2022 at 12:16:11PM +0530, Bhanuprakash Modem wrote:
> Modern display hardware is capable of supporting variable refresh rates.
> This patch introduces helpers to attach and set "vrr_enabled" property
> on the crtc to allow userspace to query VRR enabled status on that crtc.
> 
> Atomic drivers should attach this property to crtcs those are capable of
> driving variable refresh rates using
> drm_mode_crtc_attach_vrr_enabled_property().
> 
> The value should be updated based on driver and hardware capability
> by using drm_mode_crtc_set_vrr_enabled_property().
> 
> V2: Use property flag as atomic

We already have userspace making us of the CRTC vrr_enabled property to
enable VRR for the CRTC like in case of full screen gaming.

This can already be done through:
drm_atomic_crtc_set_property call. Why do we need additonal helpers
for setting the same per CRTC property?

This is a default CRTC property so it will be created annd attached for
CRTC as per the DRM doc:
"VRR_ENABLED":
 *  Default _crtc boolean property that notifies the driver that the
 *  content on the CRTC is suitable for variable refresh rate presentation.
 *  The driver will take this property as a hint to enable variable
 *  refresh rate support if the receiver supports it, ie. if the
 *  "vrr_capable" property is true on the _connector object. The
 *  vertical front porch duration will be extended until page-flip or
 *  timeout when enabled.

Then we can use the atomic_crtc_set/get_property helpers to set it
Am I missing some other use case here?

Manasi

> 
> Cc: Ville Syrjälä 
> Cc: Nicholas Kazlauskas 
> Cc: Manasi Navare 
> Cc: Harry Wentland 
> Signed-off-by: Bhanuprakash Modem 
> ---
>  drivers/gpu/drm/drm_crtc.c| 44 +++
>  drivers/gpu/drm/drm_mode_config.c |  2 +-
>  include/drm/drm_crtc.h|  4 +++
>  3 files changed, 49 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 26a77a735905..95b4a0c7ecb3 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -883,3 +883,47 @@ int drm_crtc_create_scaling_filter_property(struct 
> drm_crtc *crtc,
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_crtc_create_scaling_filter_property);
> +
> +/**
> + * drm_mode_crtc_attach_vrr_enabled_property - attaches the vrr_enabled 
> property
> + * @crtc: drm CRTC to attach the vrr_enabled property on.
> + *
> + * This is used by atomic drivers to add support for querying
> + * VRR enabled status for a crtc.
> + */
> +void drm_mode_crtc_attach_vrr_enabled_property(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_mode_config *config = >mode_config;
> +
> + if (!config->prop_vrr_enabled)
> + return;
> +
> + drm_object_attach_property(>base,
> +config->prop_vrr_enabled,
> +0);
> +}
> +EXPORT_SYMBOL(drm_mode_crtc_attach_vrr_enabled_property);
> +
> +/**
> + * drm_mode_crtc_set_vrr_enabled_property - sets the vrr enabled property for
> + * a crtc.
> + * @crtc: drm CRTC
> + * @vrr_enabled: True to enable the VRR on CRTC
> + *
> + * Should be used by atomic drivers to update the VRR enabled status on a 
> CRTC
> + */
> +void drm_mode_crtc_set_vrr_enabled_property(struct drm_crtc *crtc,
> + bool vrr_enabled)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_mode_config *config = >mode_config;
> +
> + if (!config->prop_vrr_enabled)
> + return;
> +
> + drm_object_property_set_value(>base,
> +   config->prop_vrr_enabled,
> +   vrr_enabled);
> +}
> +EXPORT_SYMBOL(drm_mode_crtc_set_vrr_enabled_property);
> diff --git a/drivers/gpu/drm/drm_mode_config.c 
> b/drivers/gpu/drm/drm_mode_config.c
> index 37b4b9f0e468..b7cde73d5586 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -323,7 +323,7 @@ static int drm_mode_create_standard_properties(struct 
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.prop_mode_id = prop;
>  
> - prop = drm_property_create_bool(dev, 0,
> + prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC,
>   "VRR_ENABLED");
>   if (!prop)
>   return -ENOMEM;
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index a70baea0636c..bde657cb0f9e 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1333,4 +1333,8 @@ static inline struct drm_crtc *drm_crtc_find(struct 
> drm_device *dev,
>  int drm_crtc_create_scaling_filter_property(struct drm_crtc *crtc,
>   unsigned int supported_filters);
>  
> +void drm_mode_crtc_attach_vrr_enabled_property(struct drm_crtc *crtc);
> +void drm_mode_crtc_set_vrr_enabled_property(struct drm_crtc *crtc,

[Intel-gfx] [CI] PR for new GuC v70.1.2 for DG2

[John . C . Harrison]

The following changes since commit ac21ab5d1de0de34201c90d32eee436f873d1e5b:

  Mellanox: Add lc_ini_bundle for xx.2010.1006 (2022-04-25 07:36:16 -0400)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-firmware guc_v70.1.2_dg2

for you to fetch changes up to 89ae5eb20f65752db6a3e38b9a69144f19540567:

  i915: Add GuC v70.1.2 for DG2 (2022-04-26 13:27:47 -0700)


John Harrison (1):
  i915: Add GuC v70.1.2 for DG2

 WHENCE  |   3 +++
 i915/dg2_guc_70.1.2.bin | Bin 0 -> 365568 bytes
 2 files changed, 3 insertions(+)
 create mode 100644 i915/dg2_guc_70.1.2.bin

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bios: Rework BDB block handling and PNPID->panel_type matching (rev7)

[Patchwork]

== Series Details ==

Series: drm/i915/bios: Rework BDB block handling and PNPID->panel_type matching 
(rev7)
URL   : https://patchwork.freedesktop.org/series/102213/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11550 -> Patchwork_102213v7


Summary
---

  **FAILURE**

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

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

Participating hosts (43 -> 45)
--

  Additional (3): bat-dg2-8 fi-kbl-x1275 bat-dg1-6 
  Missing(1): fi-bsw-cyan 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@runner@aborted:
- fi-bxt-dsi: NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102213v7/fi-bxt-dsi/igt@run...@aborted.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6:  NOTRUN -> [INCOMPLETE][2] ([i915#5827])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102213v7/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html

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

  * igt@gem_lmem_swapping@verify-random:
- fi-kbl-x1275:   NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102213v7/fi-kbl-x1275/igt@gem_lmem_swapp...@verify-random.html

  * igt@i915_module_load@reload:
- fi-kbl-soraka:  [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-kbl-soraka/igt@i915_module_l...@reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102213v7/fi-kbl-soraka/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live@hangcheck:
- fi-bdw-5557u:   NOTRUN -> [INCOMPLETE][7] ([i915#3921])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102213v7/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@requests:
- fi-pnv-d510:[PASS][8] -> [DMESG-FAIL][9] ([i915#4528])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-pnv-d510/igt@i915_selftest@l...@requests.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102213v7/fi-pnv-d510/igt@i915_selftest@l...@requests.html

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

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-kbl-x1275:   NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102213v7/fi-kbl-x1275/igt@kms_chamel...@hdmi-crc-fast.html

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

  * igt@kms_psr@primary_page_flip:
- fi-kbl-x1275:   NOTRUN -> [SKIP][13] ([fdo#109271]) +12 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102213v7/fi-kbl-x1275/igt@kms_psr@primary_page_flip.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-bdw-5557u:   NOTRUN -> [SKIP][14] ([fdo#109271]) +14 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102213v7/fi-bdw-5557u/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@runner@aborted:
- fi-pnv-d510:NOTRUN -> [FAIL][15] ([fdo#109271] / [i915#2403] / 
[i915#4312])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102213v7/fi-pnv-d510/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_module_load@reload:
- {bat-rpls-2}:   [DMESG-WARN][16] ([i915#5537]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-2/igt@i915_module_l...@reload.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102213v7/bat-rpls-2/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-guc: [DMESG-FAIL][18] ([i915#5334]) -> [PASS][19]
   [18]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/bios: Rework BDB block handling and PNPID->panel_type matching (rev7)

[Patchwork]

== Series Details ==

Series: drm/i915/bios: Rework BDB block handling and PNPID->panel_type matching 
(rev7)
URL   : https://patchwork.freedesktop.org/series/102213/
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/bios: Rework BDB block handling and PNPID->panel_type matching (rev7)

[Patchwork]

== Series Details ==

Series: drm/i915/bios: Rework BDB block handling and PNPID->panel_type matching 
(rev7)
URL   : https://patchwork.freedesktop.org/series/102213/
State : warning

== Summary ==

Error: dim checkpatch failed
491bd4fb1142 drm/i915/bios: Reorder panel DTD parsing
3e5577a49b4e drm/i915/bios: Generate LFP data table pointers if the VBT lacks 
them
-:45: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV)
#45: FILE: drivers/gpu/drm/i915/display/intel_bios.c:319:
+   if (data[i] == 0xff && data[i+1] == 0xff)
 ^

-:133: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#133: FILE: drivers/gpu/drm/i915/display/intel_bios.c:407:
+   next_lfp_data_ptr(>ptr[i].fp_timing, 
>ptr[i-1].fp_timing, size);
   ^

-:134: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#134: FILE: drivers/gpu/drm/i915/display/intel_bios.c:408:
+   next_lfp_data_ptr(>ptr[i].dvo_timing, 
>ptr[i-1].dvo_timing, size);
^

-:135: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#135: FILE: drivers/gpu/drm/i915/display/intel_bios.c:409:
+   next_lfp_data_ptr(>ptr[i].panel_pnp_id, 
>ptr[i-1].panel_pnp_id, size);
  ^

total: 0 errors, 0 warnings, 4 checks, 161 lines checked
d02c73ad126c drm/i915/bios: Get access to the tail end of the LFP data block
6b3b6e4acbf8 drm/i915/bios: Document the mess around the LFP data tables
bef6358a873c drm/i915/bios: Assume panel_type==0 if the VBT has bogus data
55aa04b4813c drm/i915/bios: Split parse_driver_features() into two parts
355758b700e7 drm/i915/bios: Split VBT parsing to global vs. panel specific parts
0a3861823b81 drm/i915/bios: Don't parse some panel specific data multiple times
7f3945c331d1 drm/i915/pps: Split PPS init+sanitize in two
fadd34ff2d65 drm/i915/pps: Reinit PPS delays after VBT has been fully parsed
57cbe6d0960c drm/i915/bios: Do panel specific VBT parsing later
8937acb7f6b4 drm/i915/bios: Extract get_panel_type()
441eb3fefed5 drm/i915/bios: Refactor panel_type code
ffa25c5869c3 drm/i915/bios: Determine panel type via PNPID match
a09890b58ae8 drm/i915/bios: Parse the seamless DRRS min refresh rate
ead9d32254a0 drm/i915: Respect VBT seamless DRRS min refresh rate
5ed1d76cf5dc drm/edid: Extract drm_edid_decode_mfg_id()
a9d0aa16d284 drm/i915/bios: Dump PNPID and panel name

Re: [Intel-gfx] [PATCH 7/9] drm/i915/gt: Fix memory leaks in per-gt sysfs

[Dixit, Ashutosh]

On Sun, 24 Apr 2022 15:30:59 -0700, Andi Shyti wrote:
>
> Hi Ashutosh,
>

Hi Andi,

> [...]
>
> > -static struct kobj_type kobj_gt_type = {
> > -   .release = kobj_gt_release,
> > +static struct kobj_type kobj_gtn_type = {
>
> what does it mean GTN? Or is it GTn? Please use just GT, gtn is
> confusing.
>
> Same for all the rest of the gtn's you have used below.

I didn't like gtn either. But a sysfs_gt kobject is already part of 'struct
drm_i915_private' so I thought I'll put sysfs_gtn (for gt/gtN) in 'struct
intel_gt'. Otherwise browsing the code etc. gets confusing.

So that was the reason, but I think I'll change the name to 'kobj_gt' (from
the current 'sysfs_gtn') in the next rev. That seems better. Thoughts?

Will respond to your other comments after posting the next rev patches (now
need some rework because Jani doesn't want a dependence between gt and
display code in pcode functions).

Thanks.
--
Ashutosh

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use the memcpy_from_wc function from drm (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Use the memcpy_from_wc function from drm (rev4)
URL   : https://patchwork.freedesktop.org/series/100581/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_100581v4_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 12)
--

  Additional (2): shard-rkl shard-tglu 

Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-skl:  ([PASS][1], [PASS][2], [PASS][3], [PASS][4], 
[PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], 
[PASS][12], [FAIL][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], 
[PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], 
[PASS][24]) ([i915#5032]) -> ([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], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], 
[PASS][47], [PASS][48])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/shard-skl9/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/shard-skl9/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/shard-skl9/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/shard-skl8/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/shard-skl8/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/shard-skl8/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/shard-skl8/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/shard-skl7/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/shard-skl7/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/shard-skl7/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/shard-skl6/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/shard-skl6/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/shard-skl6/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/shard-skl4/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/shard-skl4/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/shard-skl4/boot.html
   [41]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/shard-skl2/boot.html
   [42]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/shard-skl2/boot.html
   [43]: 

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Start reordering modeset clock calculations (rev6)

[Patchwork]

== Series Details ==

Series: drm/i915: Start reordering modeset clock calculations (rev6)
URL   : https://patchwork.freedesktop.org/series/101789/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/101789/revisions/6/mbox/ not 
applied
Applying: drm/i915: Split shared dpll .get_dplls() into compute and get phases
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/display/intel_dpll.c
M   drivers/gpu/drm/i915/display/intel_dpll_mgr.c
M   drivers/gpu/drm/i915/display/intel_dpll_mgr.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/display/intel_dpll_mgr.h
CONFLICT (content): Merge conflict in 
drivers/gpu/drm/i915/display/intel_dpll_mgr.h
Auto-merging drivers/gpu/drm/i915/display/intel_dpll_mgr.c
CONFLICT (content): Merge conflict in 
drivers/gpu/drm/i915/display/intel_dpll_mgr.c
Auto-merging drivers/gpu/drm/i915/display/intel_dpll.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/display/intel_dpll.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: Split shared dpll .get_dplls() into compute and 
get phases
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".

Re: [Intel-gfx] [PATCH 3/9] drm/i915/pcode: Extend pcode functions for multiple gt's

[Dixit, Ashutosh]

On Tue, 26 Apr 2022 00:55:26 -0700, Jani Nikula wrote:
>
> On Tue, 19 Apr 2022, Ashutosh Dixit  wrote:
> > Each gt contains an independent instance of pcode. Extend pcode functions
> > to interface with pcode on different gt's. Previous (GT0) pcode read/write
> > interfaces are preserved.
>
> Replying here as well. I'd prefer it if a dependency on gt wasn't
> introduced here. You could just pass the uncore.

This seems like a good solution, I will rework the patches. Thanks.

[Intel-gfx] [PATCH v3 15/18] drm/i915/bios: Parse the seamless DRRS min refresh rate

[Ville Syrjala]

From: Ville Syrjälä 

Extract the seamless DRRS min refresh rate from the VBT.

v2: Do a version check

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 9 -
 drivers/gpu/drm/i915/i915_drv.h   | 1 +
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 1b84c0e55497..f1afc267b5f9 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -833,6 +833,7 @@ parse_lfp_data(struct drm_i915_private *i915)
const struct bdb_lvds_lfp_data *data;
const struct bdb_lvds_lfp_data_tail *tail;
const struct bdb_lvds_lfp_data_ptrs *ptrs;
+   int panel_type = i915->vbt.panel_type;
 
ptrs = find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
if (!ptrs)
@@ -849,7 +850,13 @@ parse_lfp_data(struct drm_i915_private *i915)
if (!tail)
return;
 
-   (void)tail;
+   if (i915->vbt.version >= 188) {
+   i915->vbt.seamless_drrs_min_refresh_rate =
+   tail->seamless_drrs_min_refresh_rate[panel_type];
+   drm_dbg_kms(>drm,
+   "Seamless DRRS min refresh rate: %d Hz\n",
+   i915->vbt.seamless_drrs_min_refresh_rate);
+   }
 }
 
 static void
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 24111bf42ce0..c2a31ca56232 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -327,6 +327,7 @@ struct intel_vbt_data {
bool override_afc_startup;
u8 override_afc_startup_val;
 
+   u8 seamless_drrs_min_refresh_rate;
enum drrs_type drrs_type;
 
struct {
-- 
2.35.1

[Intel-gfx] [PATCH v3 18/18] drm/i915/bios: Dump PNPID and panel name

[Ville Syrjala]

From: Ville Syrjälä 

Dump the panel PNPID and name from the VBT.

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 24 +++
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index f1afc267b5f9..1b08553b22d0 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -25,6 +25,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 
@@ -603,6 +604,19 @@ get_lfp_data_tail(const struct bdb_lvds_lfp_data *data,
return NULL;
 }
 
+static void dump_pnp_id(struct drm_i915_private *i915,
+   const struct lvds_pnp_id *pnp_id,
+   const char *name)
+{
+   u16 mfg_name = be16_to_cpu((__force __be16)pnp_id->mfg_name);
+   char vend[4];
+
+   drm_dbg_kms(>drm, "%s PNPID mfg: %s (0x%x), prod: %u, serial: %u, 
week: %d, year: %d\n",
+   name, drm_edid_decode_mfg_id(mfg_name, vend),
+   pnp_id->mfg_name, pnp_id->product_code, pnp_id->serial,
+   pnp_id->mfg_week, pnp_id->mfg_year + 1990);
+}
+
 static int opregion_get_panel_type(struct drm_i915_private *i915,
   const struct edid *edid)
 {
@@ -646,6 +660,8 @@ static int pnpid_get_panel_type(struct drm_i915_private 
*i915,
edid_id_nodate.mfg_week = 0;
edid_id_nodate.mfg_year = 0;
 
+   dump_pnp_id(i915, edid_id, "EDID");
+
ptrs = find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
if (!ptrs)
return -1;
@@ -833,6 +849,7 @@ parse_lfp_data(struct drm_i915_private *i915)
const struct bdb_lvds_lfp_data *data;
const struct bdb_lvds_lfp_data_tail *tail;
const struct bdb_lvds_lfp_data_ptrs *ptrs;
+   const struct lvds_pnp_id *pnp_id;
int panel_type = i915->vbt.panel_type;
 
ptrs = find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
@@ -846,10 +863,17 @@ parse_lfp_data(struct drm_i915_private *i915)
if (!i915->vbt.lfp_lvds_vbt_mode)
parse_lfp_panel_dtd(i915, data, ptrs);
 
+   pnp_id = get_lvds_pnp_id(data, ptrs, panel_type);
+   dump_pnp_id(i915, pnp_id, "Panel");
+
tail = get_lfp_data_tail(data, ptrs);
if (!tail)
return;
 
+   drm_dbg_kms(>drm, "Panel name: %.*s\n",
+   (int)sizeof(tail->panel_name[0].name),
+   tail->panel_name[panel_type].name);
+
if (i915->vbt.version >= 188) {
i915->vbt.seamless_drrs_min_refresh_rate =
tail->seamless_drrs_min_refresh_rate[panel_type];
-- 
2.35.1

[Intel-gfx] [PATCH v3 17/18] drm/edid: Extract drm_edid_decode_mfg_id()

[Ville Syrjala]

From: Ville Syrjälä 

Make the PNPID decoding available for other users.

Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 include/drm/drm_edid.h | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index c3204a58fb09..e92385a13d2a 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -496,6 +496,22 @@ static inline u8 drm_eld_get_conn_type(const uint8_t *eld)
return eld[DRM_ELD_SAD_COUNT_CONN_TYPE] & DRM_ELD_CONN_TYPE_MASK;
 }
 
+/**
+ * drm_edid_decode_mfg_id - Decode the manufacturer ID
+ * @mfg_id: The manufacturer ID
+ * @vend: A 4-byte buffer to store the 3-letter vendor string plus a '\0'
+ *   termination
+ */
+static inline const char *drm_edid_decode_mfg_id(u16 mfg_id, char vend[4])
+{
+   vend[0] = '@' + ((mfg_id >> 10) & 0x1f);
+   vend[1] = '@' + ((mfg_id >> 5) & 0x1f);
+   vend[2] = '@' + ((mfg_id >> 0) & 0x1f);
+   vend[3] = '\0';
+
+   return vend;
+}
+
 /**
  * drm_edid_encode_panel_id - Encode an ID for matching against 
drm_edid_get_panel_id()
  * @vend_chr_0: First character of the vendor string.
@@ -536,10 +552,7 @@ static inline u8 drm_eld_get_conn_type(const uint8_t *eld)
 static inline void drm_edid_decode_panel_id(u32 panel_id, char vend[4], u16 
*product_id)
 {
*product_id = (u16)(panel_id & 0x);
-   vend[0] = '@' + ((panel_id >> 26) & 0x1f);
-   vend[1] = '@' + ((panel_id >> 21) & 0x1f);
-   vend[2] = '@' + ((panel_id >> 16) & 0x1f);
-   vend[3] = '\0';
+   drm_edid_decode_mfg_id(panel_id >> 16, vend);
 }
 
 bool drm_probe_ddc(struct i2c_adapter *adapter);
-- 
2.35.1

[Intel-gfx] [PATCH v3 16/18] drm/i915: Respect VBT seamless DRRS min refresh rate

[Ville Syrjala]

From: Ville Syrjälä 

Make sure our choice of downclock mode respects the VBT
seameless DRRS min refresh rate limit.

v2: s/vrefesh/vrefresh/ (Jani)

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_panel.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 03398feb6676..d1d1b59102d6 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -75,13 +75,17 @@ const struct drm_display_mode *
 intel_panel_downclock_mode(struct intel_connector *connector,
   const struct drm_display_mode *adjusted_mode)
 {
+   struct drm_i915_private *i915 = to_i915(connector->base.dev);
const struct drm_display_mode *fixed_mode, *best_mode = NULL;
-   int vrefresh = drm_mode_vrefresh(adjusted_mode);
+   int min_vrefresh = i915->vbt.seamless_drrs_min_refresh_rate;
+   int max_vrefresh = drm_mode_vrefresh(adjusted_mode);
 
/* pick the fixed_mode with the lowest refresh rate */
list_for_each_entry(fixed_mode, >panel.fixed_modes, head) {
-   if (drm_mode_vrefresh(fixed_mode) < vrefresh) {
-   vrefresh = drm_mode_vrefresh(fixed_mode);
+   int vrefresh = drm_mode_vrefresh(fixed_mode);
+
+   if (vrefresh >= min_vrefresh && vrefresh < max_vrefresh) {
+   max_vrefresh = vrefresh;
best_mode = fixed_mode;
}
}
-- 
2.35.1

[Intel-gfx] [PATCH v3 13/18] drm/i915/bios: Refactor panel_type code

[Ville Syrjala]

From: Ville Syrjälä 

Make the panel type code a bit more abstract along the
lines of the source of the panel type. For the moment
we have three classes: OpRegion, VBT, fallback.
Well introduce another one shortly.

We can now also print out all the different panel types,
and indicate which one we ultimately selected. Could help
with debugging.

v2: Add .get_panel_type() vfunc (Jani)

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 66 ++-
 1 file changed, 53 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index c68e4d987b81..e4ab637517ba 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -595,6 +595,11 @@ get_lfp_data_tail(const struct bdb_lvds_lfp_data *data,
return NULL;
 }
 
+static int opregion_get_panel_type(struct drm_i915_private *i915)
+{
+   return intel_opregion_get_panel_type(i915);
+}
+
 static int vbt_get_panel_type(struct drm_i915_private *i915)
 {
const struct bdb_lvds_options *lvds_options;
@@ -612,25 +617,60 @@ static int vbt_get_panel_type(struct drm_i915_private 
*i915)
return lvds_options->panel_type;
 }
 
+static int fallback_get_panel_type(struct drm_i915_private *i915)
+{
+   return 0;
+}
+
+enum panel_type {
+   PANEL_TYPE_OPREGION,
+   PANEL_TYPE_VBT,
+   PANEL_TYPE_FALLBACK,
+};
+
 static int get_panel_type(struct drm_i915_private *i915)
 {
-   int ret;
+   struct {
+   const char *name;
+   int (*get_panel_type)(struct drm_i915_private *i915);
+   int panel_type;
+   } panel_types[] = {
+   [PANEL_TYPE_OPREGION] = {
+   .name = "OpRegion",
+   .get_panel_type = opregion_get_panel_type,
+   },
+   [PANEL_TYPE_VBT] = {
+   .name = "VBT",
+   .get_panel_type = vbt_get_panel_type,
+   },
+   [PANEL_TYPE_FALLBACK] = {
+   .name = "fallback",
+   .get_panel_type = fallback_get_panel_type,
+   },
+   };
+   int i;
 
-   ret = intel_opregion_get_panel_type(i915);
-   if (ret >= 0) {
-   drm_WARN_ON(>drm, ret > 0xf);
-   drm_dbg_kms(>drm, "Panel type: %d (OpRegion)\n", ret);
-   return ret;
-   }
+   for (i = 0; i < ARRAY_SIZE(panel_types); i++) {
+   panel_types[i].panel_type = panel_types[i].get_panel_type(i915);
+
+   drm_WARN_ON(>drm, panel_types[i].panel_type > 0xf);
 
-   ret = vbt_get_panel_type(i915);
-   if (ret >= 0) {
-   drm_WARN_ON(>drm, ret > 0xf);
-   drm_dbg_kms(>drm, "Panel type: %d (VBT)\n", ret);
-   return ret;
+   if (panel_types[i].panel_type >= 0)
+   drm_dbg_kms(>drm, "Panel type (%s): %d\n",
+   panel_types[i].name, 
panel_types[i].panel_type);
}
 
-   return 0; /* fallback */
+   if (panel_types[PANEL_TYPE_OPREGION].panel_type >= 0)
+   i = PANEL_TYPE_OPREGION;
+   else if (panel_types[PANEL_TYPE_VBT].panel_type >= 0)
+   i = PANEL_TYPE_VBT;
+   else
+   i = PANEL_TYPE_FALLBACK;
+
+   drm_dbg_kms(>drm, "Selected panel type (%s): %d\n",
+   panel_types[i].name, panel_types[i].panel_type);
+
+   return panel_types[i].panel_type;
 }
 
 /* Parse general panel options */
-- 
2.35.1

[Intel-gfx] [PATCH v3 14/18] drm/i915/bios: Determine panel type via PNPID match

[Ville Syrjala]

From: Ville Syrjälä 

Apparently when the VBT panel_type==0xff we should trawl through
the PNPID table and check for a match against the EDID. If a
match is found the index gives us the panel_type.

Tried to match the Windows behaviour here with first looking
for an exact match, and if one isn't found we fall back to
looking for a match w/o the mfg year/week.

v2: Rebase due to vlv_dsi changes
v3: Adjust to .get_panel_type() vfunc

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5545
Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/icl_dsi.c|  2 +-
 drivers/gpu/drm/i915/display/intel_bios.c | 98 ---
 drivers/gpu/drm/i915/display/intel_bios.h |  4 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_lvds.c |  2 +-
 drivers/gpu/drm/i915/display/intel_sdvo.c |  2 +-
 drivers/gpu/drm/i915/display/vlv_dsi.c|  2 +-
 7 files changed, 93 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index baef44cd137f..ecf2185ca25e 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -2049,7 +2049,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
/* attach connector to encoder */
intel_connector_attach_encoder(intel_connector, encoder);
 
-   intel_bios_init_panel(dev_priv);
+   intel_bios_init_panel(dev_priv, NULL);
 
mutex_lock(>mode_config.mutex);
intel_panel_add_vbt_lfp_fixed_mode(intel_connector);
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index e4ab637517ba..1b84c0e55497 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -585,6 +585,14 @@ get_lvds_fp_timing(const struct bdb_lvds_lfp_data *data,
return (const void *)data + ptrs->ptr[index].fp_timing.offset;
 }
 
+static const struct lvds_pnp_id *
+get_lvds_pnp_id(const struct bdb_lvds_lfp_data *data,
+   const struct bdb_lvds_lfp_data_ptrs *ptrs,
+   int index)
+{
+   return (const void *)data + ptrs->ptr[index].panel_pnp_id.offset;
+}
+
 static const struct bdb_lvds_lfp_data_tail *
 get_lfp_data_tail(const struct bdb_lvds_lfp_data *data,
  const struct bdb_lvds_lfp_data_ptrs *ptrs)
@@ -595,12 +603,14 @@ get_lfp_data_tail(const struct bdb_lvds_lfp_data *data,
return NULL;
 }
 
-static int opregion_get_panel_type(struct drm_i915_private *i915)
+static int opregion_get_panel_type(struct drm_i915_private *i915,
+  const struct edid *edid)
 {
return intel_opregion_get_panel_type(i915);
 }
 
-static int vbt_get_panel_type(struct drm_i915_private *i915)
+static int vbt_get_panel_type(struct drm_i915_private *i915,
+ const struct edid *edid)
 {
const struct bdb_lvds_options *lvds_options;
 
@@ -608,7 +618,8 @@ static int vbt_get_panel_type(struct drm_i915_private *i915)
if (!lvds_options)
return -1;
 
-   if (lvds_options->panel_type > 0xf) {
+   if (lvds_options->panel_type > 0xf &&
+   lvds_options->panel_type != 0xff) {
drm_dbg_kms(>drm, "Invalid VBT panel type 0x%x\n",
lvds_options->panel_type);
return -1;
@@ -617,7 +628,54 @@ static int vbt_get_panel_type(struct drm_i915_private 
*i915)
return lvds_options->panel_type;
 }
 
-static int fallback_get_panel_type(struct drm_i915_private *i915)
+static int pnpid_get_panel_type(struct drm_i915_private *i915,
+   const struct edid *edid)
+{
+   const struct bdb_lvds_lfp_data *data;
+   const struct bdb_lvds_lfp_data_ptrs *ptrs;
+   const struct lvds_pnp_id *edid_id;
+   struct lvds_pnp_id edid_id_nodate;
+   int i, best = -1;
+
+   if (!edid)
+   return -1;
+
+   edid_id = (const void *)>mfg_id[0];
+
+   edid_id_nodate = *edid_id;
+   edid_id_nodate.mfg_week = 0;
+   edid_id_nodate.mfg_year = 0;
+
+   ptrs = find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
+   if (!ptrs)
+   return -1;
+
+   data = find_section(i915, BDB_LVDS_LFP_DATA);
+   if (!data)
+   return -1;
+
+   for (i = 0; i < 16; i++) {
+   const struct lvds_pnp_id *vbt_id =
+   get_lvds_pnp_id(data, ptrs, i);
+
+   /* full match? */
+   if (!memcmp(vbt_id, edid_id, sizeof(*vbt_id)))
+   return i;
+
+   /*
+* Accept a match w/o date if no full match is found,
+* and the VBT entry does not specify a date.
+*/
+   if (best < 0 &&
+   !memcmp(vbt_id, _id_nodate, sizeof(*vbt_id)))
+   best = i;
+   }
+
+   return best;
+}
+

[Intel-gfx] [PATCH v3 11/18] drm/i915/bios: Do panel specific VBT parsing later

[Ville Syrjala]

From: Ville Syrjälä 

Move the panel specific VBT parsing to happen during the
output probing stage. Needs to be done because the VBT
parsing will need to look at the EDID to determine
the correct panel_type on some machines.

v2: Do intel_bios_init_panel() a bit earlier for vlv_dsi

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/icl_dsi.c   | 2 ++
 drivers/gpu/drm/i915/display/intel_display.c | 1 -
 drivers/gpu/drm/i915/display/intel_dp.c  | 2 ++
 drivers/gpu/drm/i915/display/intel_lvds.c| 2 ++
 drivers/gpu/drm/i915/display/intel_sdvo.c| 3 +++
 drivers/gpu/drm/i915/display/vlv_dsi.c   | 2 ++
 6 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 19bf717fd4cb..baef44cd137f 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -2049,6 +2049,8 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
/* attach connector to encoder */
intel_connector_attach_encoder(intel_connector, encoder);
 
+   intel_bios_init_panel(dev_priv);
+
mutex_lock(>mode_config.mutex);
intel_panel_add_vbt_lfp_fixed_mode(intel_connector);
mutex_unlock(>mode_config.mutex);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index e33a70b980dc..0decf3d24237 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9579,7 +9579,6 @@ int intel_modeset_init_noirq(struct drm_i915_private 
*i915)
}
 
intel_bios_init(i915);
-   intel_bios_init_panel(i915);
 
ret = intel_vga_register(i915);
if (ret)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index a83dbbfc914c..5d8f6f233684 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5185,6 +5185,8 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
}
intel_connector->edid = edid;
 
+   intel_bios_init_panel(dev_priv);
+
intel_panel_add_edid_fixed_modes(intel_connector,
 dev_priv->vbt.drrs_type != 
DRRS_TYPE_NONE);
 
diff --git a/drivers/gpu/drm/i915/display/intel_lvds.c 
b/drivers/gpu/drm/i915/display/intel_lvds.c
index e8478161f8b9..554badf041f2 100644
--- a/drivers/gpu/drm/i915/display/intel_lvds.c
+++ b/drivers/gpu/drm/i915/display/intel_lvds.c
@@ -967,6 +967,8 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
}
intel_connector->edid = edid;
 
+   intel_bios_init_panel(dev_priv);
+
/* Try EDID first */
intel_panel_add_edid_fixed_modes(intel_connector,
 dev_priv->vbt.drrs_type != 
DRRS_TYPE_NONE);
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c 
b/drivers/gpu/drm/i915/display/intel_sdvo.c
index d81855d57cdc..84ac0f2162a4 100644
--- a/drivers/gpu/drm/i915/display/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
@@ -2869,6 +2869,7 @@ static bool
 intel_sdvo_lvds_init(struct intel_sdvo *intel_sdvo, int device)
 {
struct drm_encoder *encoder = _sdvo->base.base;
+   struct drm_i915_private *i915 = to_i915(encoder->dev);
struct drm_connector *connector;
struct intel_connector *intel_connector;
struct intel_sdvo_connector *intel_sdvo_connector;
@@ -2900,6 +2901,8 @@ intel_sdvo_lvds_init(struct intel_sdvo *intel_sdvo, int 
device)
if (!intel_sdvo_create_enhance_property(intel_sdvo, 
intel_sdvo_connector))
goto err;
 
+   intel_bios_init_panel(i915);
+
/*
 * Fetch modes from VBT. For SDVO prefer the VBT mode since some
 * SDVO->LVDS transcoders can't cope with the EDID mode.
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index 1954f07f0d3e..08fb554ff7ad 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -1929,6 +1929,8 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
else
intel_dsi->ports = BIT(port);
 
+   intel_bios_init_panel(dev_priv);
+
intel_dsi->dcs_backlight_ports = dev_priv->vbt.dsi.bl_ports;
intel_dsi->dcs_cabc_ports = dev_priv->vbt.dsi.cabc_ports;
 
-- 
2.35.1

[Intel-gfx] [PATCH v3 12/18] drm/i915/bios: Extract get_panel_type()

[Ville Syrjala]

From: Ville Syrjälä 

Pull the code to determine the panel type into its own set of
sane functions.

v2: rebase

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 58 +++
 1 file changed, 39 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 24e3b2f2485e..c68e4d987b81 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -595,6 +595,44 @@ get_lfp_data_tail(const struct bdb_lvds_lfp_data *data,
return NULL;
 }
 
+static int vbt_get_panel_type(struct drm_i915_private *i915)
+{
+   const struct bdb_lvds_options *lvds_options;
+
+   lvds_options = find_section(i915, BDB_LVDS_OPTIONS);
+   if (!lvds_options)
+   return -1;
+
+   if (lvds_options->panel_type > 0xf) {
+   drm_dbg_kms(>drm, "Invalid VBT panel type 0x%x\n",
+   lvds_options->panel_type);
+   return -1;
+   }
+
+   return lvds_options->panel_type;
+}
+
+static int get_panel_type(struct drm_i915_private *i915)
+{
+   int ret;
+
+   ret = intel_opregion_get_panel_type(i915);
+   if (ret >= 0) {
+   drm_WARN_ON(>drm, ret > 0xf);
+   drm_dbg_kms(>drm, "Panel type: %d (OpRegion)\n", ret);
+   return ret;
+   }
+
+   ret = vbt_get_panel_type(i915);
+   if (ret >= 0) {
+   drm_WARN_ON(>drm, ret > 0xf);
+   drm_dbg_kms(>drm, "Panel type: %d (VBT)\n", ret);
+   return ret;
+   }
+
+   return 0; /* fallback */
+}
+
 /* Parse general panel options */
 static void
 parse_panel_options(struct drm_i915_private *i915)
@@ -602,7 +640,6 @@ parse_panel_options(struct drm_i915_private *i915)
const struct bdb_lvds_options *lvds_options;
int panel_type;
int drrs_mode;
-   int ret;
 
lvds_options = find_section(i915, BDB_LVDS_OPTIONS);
if (!lvds_options)
@@ -610,24 +647,7 @@ parse_panel_options(struct drm_i915_private *i915)
 
i915->vbt.lvds_dither = lvds_options->pixel_dither;
 
-   ret = intel_opregion_get_panel_type(i915);
-   if (ret >= 0) {
-   drm_WARN_ON(>drm, ret > 0xf);
-   panel_type = ret;
-   drm_dbg_kms(>drm, "Panel type: %d (OpRegion)\n",
-   panel_type);
-   } else {
-   if (lvds_options->panel_type > 0xf) {
-   drm_dbg_kms(>drm,
-   "Invalid VBT panel type 0x%x, assuming 0\n",
-   lvds_options->panel_type);
-   panel_type = 0;
-   } else {
-   panel_type = lvds_options->panel_type;
-   drm_dbg_kms(>drm, "Panel type: %d (VBT)\n",
-   panel_type);
-   }
-   }
+   panel_type = get_panel_type(i915);
 
i915->vbt.panel_type = panel_type;
 
-- 
2.35.1

[Intel-gfx] [PATCH v3 10/18] drm/i915/pps: Reinit PPS delays after VBT has been fully parsed

[Ville Syrjala]

From: Ville Syrjälä 

During the eDP probe we may not yet know the panel_type used
to index the VBT panel tables. So the initial eDP probe will have
to be done without that, and thus we won't yet have the PPS delays
from the VBT. Once the VBT has been fully parse we should reinit
the PPS delays to make sure it's fully accounted for.

TODO: I wonder if we should do the eDP probe with some super safe
PPS delayes (eg. max of all VBT PPS delays) just to make sure we
don't violate the timings. Though typically the VBIOS/GOP do leave
VDD enabled after boot in which case we don't actually have to care
about the delays at all.

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

diff --git a/drivers/gpu/drm/i915/display/intel_pps.c 
b/drivers/gpu/drm/i915/display/intel_pps.c
index 0ae2be5c5318..15cbdc465a86 100644
--- a/drivers/gpu/drm/i915/display/intel_pps.c
+++ b/drivers/gpu/drm/i915/display/intel_pps.c
@@ -1396,6 +1396,11 @@ void intel_pps_init_late(struct intel_dp *intel_dp)
intel_wakeref_t wakeref;
 
with_intel_pps_lock(intel_dp, wakeref) {
+   /* Reinit delays after per-panel info has been parsed from VBT 
*/
+   memset(_dp->pps.pps_delays, 0, 
sizeof(intel_dp->pps.pps_delays));
+   pps_init_delays(intel_dp);
+   pps_init_registers(intel_dp, false);
+
if (edp_have_panel_vdd(intel_dp))
edp_panel_vdd_schedule_off(intel_dp);
}
-- 
2.35.1

[Intel-gfx] [PATCH v3 09/18] drm/i915/pps: Split PPS init+sanitize in two

[Ville Syrjala]

From: Ville Syrjälä 

Split the PPS init to something we do at the start of the eDP
probe and a second part we do at the end.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dp.c  |  2 ++
 drivers/gpu/drm/i915/display/intel_pps.c | 30 
 drivers/gpu/drm/i915/display/intel_pps.h |  1 +
 3 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index e4a79c11fd25..a83dbbfc914c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5228,6 +5228,8 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
 
intel_edp_add_properties(intel_dp);
 
+   intel_pps_init_late(intel_dp);
+
return true;
 
 out_vdd_off:
diff --git a/drivers/gpu/drm/i915/display/intel_pps.c 
b/drivers/gpu/drm/i915/display/intel_pps.c
index 5a598dd06039..0ae2be5c5318 100644
--- a/drivers/gpu/drm/i915/display/intel_pps.c
+++ b/drivers/gpu/drm/i915/display/intel_pps.c
@@ -1051,7 +1051,7 @@ void vlv_pps_init(struct intel_encoder *encoder,
pps_init_registers(intel_dp, true);
 }
 
-static void intel_pps_vdd_sanitize(struct intel_dp *intel_dp)
+static void pps_vdd_init(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
@@ -1072,8 +1072,6 @@ static void intel_pps_vdd_sanitize(struct intel_dp 
*intel_dp)
drm_WARN_ON(_priv->drm, intel_dp->pps.vdd_wakeref);
intel_dp->pps.vdd_wakeref = intel_display_power_get(dev_priv,

intel_aux_power_domain(dig_port));
-
-   edp_panel_vdd_schedule_off(intel_dp);
 }
 
 bool intel_pps_have_panel_power_or_vdd(struct intel_dp *intel_dp)
@@ -1367,18 +1365,40 @@ void intel_pps_encoder_reset(struct intel_dp *intel_dp)
 
pps_init_delays(intel_dp);
pps_init_registers(intel_dp, false);
+   pps_vdd_init(intel_dp);
 
-   intel_pps_vdd_sanitize(intel_dp);
+   if (edp_have_panel_vdd(intel_dp))
+   edp_panel_vdd_schedule_off(intel_dp);
}
 }
 
 void intel_pps_init(struct intel_dp *intel_dp)
 {
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   intel_wakeref_t wakeref;
+
INIT_DELAYED_WORK(_dp->pps.panel_vdd_work, edp_panel_vdd_work);
 
pps_init_timestamps(intel_dp);
 
-   intel_pps_encoder_reset(intel_dp);
+   with_intel_pps_lock(intel_dp, wakeref) {
+   if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
+   vlv_initial_power_sequencer_setup(intel_dp);
+
+   pps_init_delays(intel_dp);
+   pps_init_registers(intel_dp, false);
+   pps_vdd_init(intel_dp);
+   }
+}
+
+void intel_pps_init_late(struct intel_dp *intel_dp)
+{
+   intel_wakeref_t wakeref;
+
+   with_intel_pps_lock(intel_dp, wakeref) {
+   if (edp_have_panel_vdd(intel_dp))
+   edp_panel_vdd_schedule_off(intel_dp);
+   }
 }
 
 void intel_pps_unlock_regs_wa(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/display/intel_pps.h 
b/drivers/gpu/drm/i915/display/intel_pps.h
index e64144659d31..a3a56f903f26 100644
--- a/drivers/gpu/drm/i915/display/intel_pps.h
+++ b/drivers/gpu/drm/i915/display/intel_pps.h
@@ -41,6 +41,7 @@ bool intel_pps_have_panel_power_or_vdd(struct intel_dp 
*intel_dp);
 void intel_pps_wait_power_cycle(struct intel_dp *intel_dp);
 
 void intel_pps_init(struct intel_dp *intel_dp);
+void intel_pps_init_late(struct intel_dp *intel_dp);
 void intel_pps_encoder_reset(struct intel_dp *intel_dp);
 void intel_pps_reset_all(struct drm_i915_private *i915);
 
-- 
2.35.1

[Intel-gfx] [PATCH v3 08/18] drm/i915/bios: Don't parse some panel specific data multiple times

[Ville Syrjala]

From: Ville Syrjälä 

Make sure we don't cause memory leaks/etc. by parsing panel_type
specific parts multiple times. The real solution would be to stop
stuffing panel specific stuff into i915->vbt, but in the meantime
let's just make sure we don't leak too badly.

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

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index b246a3a649a0..24e3b2f2485e 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -729,6 +729,10 @@ parse_generic_dtd(struct drm_i915_private *i915)
struct drm_display_mode *panel_fixed_mode;
int num_dtd;
 
+   /* FIXME stop using i915->vbt for panel specific data */
+   if (i915->vbt.lfp_lvds_vbt_mode)
+   return;
+
/*
 * Older VBTs provided DTD information for internal displays through
 * the "LFP panel tables" block (42).  As of VBT revision 229 the
@@ -908,6 +912,10 @@ parse_sdvo_panel_data(struct drm_i915_private *i915)
struct drm_display_mode *panel_fixed_mode;
int index;
 
+   /* FIXME stop using i915->vbt for panel specific data */
+   if (i915->vbt.sdvo_lvds_vbt_mode)
+   return;
+
index = i915->params.vbt_sdvo_panel_type;
if (index == -2) {
drm_dbg_kms(>drm,
@@ -1436,6 +1444,10 @@ parse_mipi_config(struct drm_i915_private *i915)
int panel_type = i915->vbt.panel_type;
enum port port;
 
+   /* FIXME stop using i915->vbt for panel specific data */
+   if (i915->vbt.dsi.config)
+   return;
+
/* parse MIPI blocks only if LFP type is MIPI */
if (!intel_bios_is_dsi_present(i915, ))
return;
@@ -1756,6 +1768,10 @@ parse_mipi_sequence(struct drm_i915_private *i915)
u8 *data;
int index = 0;
 
+   /* FIXME stop using i915->vbt for panel specific data */
+   if (i915->vbt.dsi.data)
+   return;
+
/* Only our generic panel driver uses the sequence block. */
if (i915->vbt.dsi.panel_id != MIPI_DSI_GENERIC_PANEL_ID)
return;
-- 
2.35.1

[Intel-gfx] [PATCH v3 07/18] drm/i915/bios: Split VBT parsing to global vs. panel specific parts

[Ville Syrjala]

From: Ville Syrjälä 

Parsing the panel specific data (anything that depends on panel_type)
from VBT is currently happening too early. Split the whole thing
into global vs. panel specific parts so that we can start doing
the panel specific parsing at a later time.

v2: Clarify that this is about panel_type (Jani)
Split out the leak checks (Jani)

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_bios.c| 26 +++-
 drivers/gpu/drm/i915/display/intel_bios.h|  1 +
 drivers/gpu/drm/i915/display/intel_display.c |  1 +
 3 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index f4bcbdd9f37a..b246a3a649a0 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2895,18 +2895,7 @@ void intel_bios_init(struct drm_i915_private *i915)
/* Grab useful general definitions */
parse_general_features(i915);
parse_general_definitions(i915);
-   parse_panel_options(i915);
-   parse_generic_dtd(i915);
-   parse_lfp_data(i915);
-   parse_lfp_backlight(i915);
-   parse_sdvo_panel_data(i915);
parse_driver_features(i915);
-   parse_panel_driver_features(i915);
-   parse_power_conservation_features(i915);
-   parse_edp(i915);
-   parse_psr(i915);
-   parse_mipi_config(i915);
-   parse_mipi_sequence(i915);
 
/* Depends on child device list */
parse_compression_parameters(i915);
@@ -2925,6 +2914,21 @@ void intel_bios_init(struct drm_i915_private *i915)
kfree(oprom_vbt);
 }
 
+void intel_bios_init_panel(struct drm_i915_private *i915)
+{
+   parse_panel_options(i915);
+   parse_generic_dtd(i915);
+   parse_lfp_data(i915);
+   parse_lfp_backlight(i915);
+   parse_sdvo_panel_data(i915);
+   parse_panel_driver_features(i915);
+   parse_power_conservation_features(i915);
+   parse_edp(i915);
+   parse_psr(i915);
+   parse_mipi_config(i915);
+   parse_mipi_sequence(i915);
+}
+
 /**
  * intel_bios_driver_remove - Free any resources allocated by intel_bios_init()
  * @i915: i915 device instance
diff --git a/drivers/gpu/drm/i915/display/intel_bios.h 
b/drivers/gpu/drm/i915/display/intel_bios.h
index 4709c4d29805..c744d75fa435 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.h
+++ b/drivers/gpu/drm/i915/display/intel_bios.h
@@ -230,6 +230,7 @@ struct mipi_pps_data {
 } __packed;
 
 void intel_bios_init(struct drm_i915_private *dev_priv);
+void intel_bios_init_panel(struct drm_i915_private *dev_priv);
 void intel_bios_driver_remove(struct drm_i915_private *dev_priv);
 bool intel_bios_is_valid_vbt(const void *buf, size_t size);
 bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 0decf3d24237..e33a70b980dc 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9579,6 +9579,7 @@ int intel_modeset_init_noirq(struct drm_i915_private 
*i915)
}
 
intel_bios_init(i915);
+   intel_bios_init_panel(i915);
 
ret = intel_vga_register(i915);
if (ret)
-- 
2.35.1

[Intel-gfx] [PATCH v3 06/18] drm/i915/bios: Split parse_driver_features() into two parts

[Ville Syrjala]

From: Ville Syrjälä 

We use the "driver features" block for two different kinds
of data: global data, and per panel data. Split the function
into two parts along that line so that we can start doing the
parsing in two different locations.

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 53a7a16df231..f4bcbdd9f37a 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1114,6 +1114,16 @@ parse_driver_features(struct drm_i915_private *i915)
driver->lvds_config != BDB_DRIVER_FEATURE_INT_SDVO_LVDS)
i915->vbt.int_lvds_support = 0;
}
+}
+
+static void
+parse_panel_driver_features(struct drm_i915_private *i915)
+{
+   const struct bdb_driver_features *driver;
+
+   driver = find_section(i915, BDB_DRIVER_FEATURES);
+   if (!driver)
+   return;
 
if (i915->vbt.version < 228) {
drm_dbg_kms(>drm, "DRRS State Enabled:%d\n",
@@ -2891,6 +2901,7 @@ void intel_bios_init(struct drm_i915_private *i915)
parse_lfp_backlight(i915);
parse_sdvo_panel_data(i915);
parse_driver_features(i915);
+   parse_panel_driver_features(i915);
parse_power_conservation_features(i915);
parse_edp(i915);
parse_psr(i915);
-- 
2.35.1

[Intel-gfx] [PATCH v3 05/18] drm/i915/bios: Assume panel_type==0 if the VBT has bogus data

[Ville Syrjala]

From: Ville Syrjälä 

Just assume panel_type==0 always if the VBT gives us bogus data.
We actually already do this everywhere else except in
parse_panel_options() since we just leave i915->vbt.panel_type
zeroed. This also seems to be what Windows does.

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index ecfce9adfbbb..53a7a16df231 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -619,13 +619,14 @@ parse_panel_options(struct drm_i915_private *i915)
} else {
if (lvds_options->panel_type > 0xf) {
drm_dbg_kms(>drm,
-   "Invalid VBT panel type 0x%x\n",
+   "Invalid VBT panel type 0x%x, assuming 0\n",
lvds_options->panel_type);
-   return;
+   panel_type = 0;
+   } else {
+   panel_type = lvds_options->panel_type;
+   drm_dbg_kms(>drm, "Panel type: %d (VBT)\n",
+   panel_type);
}
-   panel_type = lvds_options->panel_type;
-   drm_dbg_kms(>drm, "Panel type: %d (VBT)\n",
-   panel_type);
}
 
i915->vbt.panel_type = panel_type;
-- 
2.35.1

[Intel-gfx] [PATCH v3 04/18] drm/i915/bios: Document the mess around the LFP data tables

[Ville Syrjala]

From: Ville Syrjälä 

Document the fact that struct lvds_lfp_data_entry can't be used
directly and instead must be accessed via the data table pointers.

Also remove the bogus comment implying that there might be a
variable number of panel entries in the table. There are always
exactly 16.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_vbt_defs.h | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h 
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index 64551d206aeb..294e74c3289d 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -735,7 +735,7 @@ struct lvds_lfp_data_ptr {
 } __packed;
 
 struct bdb_lvds_lfp_data_ptrs {
-   u8 lvds_entries; /* followed by one or more lvds_data_ptr structs */
+   u8 lvds_entries;
struct lvds_lfp_data_ptr ptr[16];
struct lvds_lfp_data_ptr_table panel_name; /* 156-163? */
 } __packed;
@@ -769,6 +769,11 @@ struct lvds_pnp_id {
u8 mfg_year;
 } __packed;
 
+/*
+ * For reference only. fp_timing has variable size so
+ * the data must be accessed using the data table pointers.
+ * Do not use this directly!
+ */
 struct lvds_lfp_data_entry {
struct lvds_fp_timing fp_timing;
struct lvds_dvo_timing dvo_timing;
-- 
2.35.1

[Intel-gfx] [PATCH v3 03/18] drm/i915/bios: Get access to the tail end of the LFP data block

[Ville Syrjala]

From: Ville Syrjälä 

We need to start parsing stuff from the tail end of the LFP data block.
This is made awkward by the fact that the fp_timing table has variable
size. So we must use a bit more finesse to get the tail end, and to
make sure we allocate enough memory for it to make sure our struct
representation fits.

v2: Rebase due to the preallocation of BDB blocks
v3: Rebase due to min_size WARN relocation
v4: Document BDB_LVDS_LFP_DATA vs. BDB_LVDS_LFP_DATA_PTRS order (Jani)

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 43 ++-
 drivers/gpu/drm/i915/display/intel_vbt_defs.h | 17 
 2 files changed, 59 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 7bc3d55b6bb0..ecfce9adfbbb 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -186,10 +186,14 @@ static const struct {
  .min_size = sizeof(struct bdb_edp), },
{ .section_id = BDB_LVDS_OPTIONS,
  .min_size = sizeof(struct bdb_lvds_options), },
+   /*
+* BDB_LVDS_LFP_DATA depends on BDB_LVDS_LFP_DATA_PTRS,
+* so keep the two ordered.
+*/
{ .section_id = BDB_LVDS_LFP_DATA_PTRS,
  .min_size = sizeof(struct bdb_lvds_lfp_data_ptrs), },
{ .section_id = BDB_LVDS_LFP_DATA,
- .min_size = sizeof(struct bdb_lvds_lfp_data), },
+ .min_size = 0, /* special case */ },
{ .section_id = BDB_LVDS_BACKLIGHT,
  .min_size = sizeof(struct bdb_lfp_backlight_data), },
{ .section_id = BDB_LFP_POWER,
@@ -204,6 +208,23 @@ static const struct {
  .min_size = sizeof(struct bdb_generic_dtd), },
 };
 
+static size_t lfp_data_min_size(struct drm_i915_private *i915)
+{
+   const struct bdb_lvds_lfp_data_ptrs *ptrs;
+   size_t size;
+
+   ptrs = find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
+   if (!ptrs)
+   return 0;
+
+   size = sizeof(struct bdb_lvds_lfp_data);
+   if (ptrs->panel_name.table_size)
+   size = max(size, ptrs->panel_name.offset +
+  sizeof(struct bdb_lvds_lfp_data_tail));
+
+   return size;
+}
+
 static bool validate_lfp_data_ptrs(const void *bdb,
   const struct bdb_lvds_lfp_data_ptrs *ptrs)
 {
@@ -491,6 +512,9 @@ static void init_bdb_blocks(struct drm_i915_private *i915,
enum bdb_block_id section_id = bdb_blocks[i].section_id;
size_t min_size = bdb_blocks[i].min_size;
 
+   if (section_id == BDB_LVDS_LFP_DATA)
+   min_size = lfp_data_min_size(i915);
+
init_bdb_block(i915, bdb, section_id, min_size);
}
 }
@@ -561,6 +585,16 @@ get_lvds_fp_timing(const struct bdb_lvds_lfp_data *data,
return (const void *)data + ptrs->ptr[index].fp_timing.offset;
 }
 
+static const struct bdb_lvds_lfp_data_tail *
+get_lfp_data_tail(const struct bdb_lvds_lfp_data *data,
+ const struct bdb_lvds_lfp_data_ptrs *ptrs)
+{
+   if (ptrs->panel_name.table_size)
+   return (const void *)data + ptrs->panel_name.offset;
+   else
+   return NULL;
+}
+
 /* Parse general panel options */
 static void
 parse_panel_options(struct drm_i915_private *i915)
@@ -665,6 +699,7 @@ static void
 parse_lfp_data(struct drm_i915_private *i915)
 {
const struct bdb_lvds_lfp_data *data;
+   const struct bdb_lvds_lfp_data_tail *tail;
const struct bdb_lvds_lfp_data_ptrs *ptrs;
 
ptrs = find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
@@ -677,6 +712,12 @@ parse_lfp_data(struct drm_i915_private *i915)
 
if (!i915->vbt.lfp_lvds_vbt_mode)
parse_lfp_panel_dtd(i915, data, ptrs);
+
+   tail = get_lfp_data_tail(data, ptrs);
+   if (!tail)
+   return;
+
+   (void)tail;
 }
 
 static void
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h 
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index e4a11c3e3f3e..64551d206aeb 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -783,6 +783,23 @@ struct lvds_lfp_panel_name {
u8 name[13];
 } __packed;
 
+struct lvds_lfp_black_border {
+   u8 top; /*  227 */
+   u8 bottom; /*  227 */
+   u8 left; /* 238 */
+   u8 right; /* 238 */
+} __packed;
+
+struct bdb_lvds_lfp_data_tail {
+   struct lvds_lfp_panel_name panel_name[16]; /* 156-163? */
+   u16 scaling_enable; /* 187 */
+   u8 seamless_drrs_min_refresh_rate[16]; /* 188 */
+   u8 pixel_overlap_count[16]; /* 208 */
+   struct lvds_lfp_black_border black_border[16]; /* 227 */
+   u16 dual_lfp_port_sync_enable; /* 231 */
+   u16 gpu_dithering_for_banding_artifacts; /* 245 */
+} __packed;
+
 /*
  * Block 43 - LFP Backlight Control Data Block
  */
-- 
2.35.1

[Intel-gfx] [PATCH v3 02/18] drm/i915/bios: Generate LFP data table pointers if the VBT lacks them

[Ville Syrjala]

From: Ville Syrjälä 

Modern VBTs no longer contain the LFP data table pointers
block (41). We are expecting to have one in order to be able
to parse the LFP data block (42), so let's make one up.

Since the fp_timing table has variable size we must somehow
determine its size. Rather than just hardcode it we look for
the terminator bytes (0x) to figure out where each table
entry starts. dvo_timing, panel_pnp_id, and panel_name are
expected to have fixed size.

This has been observed on various machines, eg. TGL with BDB
version 240, CML with BDB version 231, etc. The most recent
VBT I've observed that still had block 41 had BDB version
228. So presumably the cutoff (if an exact cutoff even exists)
is somewhere around BDB version 229-231.

v2: kfree the thing we allocated, not the thing+3 bytes
v3: Do the debugprint only if we found the LFP data block
v4: Fix t0 null check (Jani)

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

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 8a1086721525..7bc3d55b6bb0 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -311,16 +311,144 @@ static bool fixup_lfp_data_ptrs(const void *bdb, void 
*ptrs_block)
return validate_lfp_data_ptrs(bdb, ptrs);
 }
 
+static const void *find_fp_timing_terminator(const u8 *data, int size)
+{
+   int i;
+
+   for (i = 0; i < size - 1; i++) {
+   if (data[i] == 0xff && data[i+1] == 0xff)
+   return [i];
+   }
+
+   return NULL;
+}
+
+static int make_lfp_data_ptr(struct lvds_lfp_data_ptr_table *table,
+int table_size, int total_size)
+{
+   if (total_size < table_size)
+   return total_size;
+
+   table->table_size = table_size;
+   table->offset = total_size - table_size;
+
+   return total_size - table_size;
+}
+
+static void next_lfp_data_ptr(struct lvds_lfp_data_ptr_table *next,
+ const struct lvds_lfp_data_ptr_table *prev,
+ int size)
+{
+   next->table_size = prev->table_size;
+   next->offset = prev->offset + size;
+}
+
+static void *generate_lfp_data_ptrs(struct drm_i915_private *i915,
+   const void *bdb)
+{
+   int i, size, table_size, block_size, offset;
+   const void *t0, *t1, *block;
+   struct bdb_lvds_lfp_data_ptrs *ptrs;
+   void *ptrs_block;
+
+   block = find_raw_section(bdb, BDB_LVDS_LFP_DATA);
+   if (!block)
+   return NULL;
+
+   drm_dbg_kms(>drm, "Generating LFP data table pointers\n");
+
+   block_size = get_blocksize(block);
+
+   size = block_size;
+   t0 = find_fp_timing_terminator(block, size);
+   if (!t0)
+   return NULL;
+
+   size -= t0 - block - 2;
+   t1 = find_fp_timing_terminator(t0 + 2, size);
+   if (!t1)
+   return NULL;
+
+   size = t1 - t0;
+   if (size * 16 > block_size)
+   return NULL;
+
+   ptrs_block = kzalloc(sizeof(*ptrs) + 3, GFP_KERNEL);
+   if (!ptrs_block)
+   return NULL;
+
+   *(u8 *)(ptrs_block + 0) = BDB_LVDS_LFP_DATA_PTRS;
+   *(u16 *)(ptrs_block + 1) = sizeof(*ptrs);
+   ptrs = ptrs_block + 3;
+
+   table_size = sizeof(struct lvds_pnp_id);
+   size = make_lfp_data_ptr(>ptr[0].panel_pnp_id, table_size, size);
+
+   table_size = sizeof(struct lvds_dvo_timing);
+   size = make_lfp_data_ptr(>ptr[0].dvo_timing, table_size, size);
+
+   table_size = t0 - block + 2;
+   size = make_lfp_data_ptr(>ptr[0].fp_timing, table_size, size);
+
+   if (ptrs->ptr[0].fp_timing.table_size)
+   ptrs->lvds_entries++;
+   if (ptrs->ptr[0].dvo_timing.table_size)
+   ptrs->lvds_entries++;
+   if (ptrs->ptr[0].panel_pnp_id.table_size)
+   ptrs->lvds_entries++;
+
+   if (size != 0 || ptrs->lvds_entries != 3) {
+   kfree(ptrs);
+   return NULL;
+   }
+
+   size = t1 - t0;
+   for (i = 1; i < 16; i++) {
+   next_lfp_data_ptr(>ptr[i].fp_timing, 
>ptr[i-1].fp_timing, size);
+   next_lfp_data_ptr(>ptr[i].dvo_timing, 
>ptr[i-1].dvo_timing, size);
+   next_lfp_data_ptr(>ptr[i].panel_pnp_id, 
>ptr[i-1].panel_pnp_id, size);
+   }
+
+   size = t1 - t0;
+   table_size = sizeof(struct lvds_lfp_panel_name);
+
+   if (16 * (size + table_size) <= block_size) {
+   ptrs->panel_name.table_size = table_size;
+   ptrs->panel_name.offset = size * 16;
+   }
+
+   offset = block - bdb;
+
+   for (i = 0; i < 16; i++) {
+   ptrs->ptr[i].fp_timing.offset += offset;
+   ptrs->ptr[i].dvo_timing.offset += offset;
+   

[Intel-gfx] [PATCH v3 01/18] drm/i915/bios: Reorder panel DTD parsing

[Ville Syrjala]

From: Ville Syrjälä 

Reorder things so that we can parse the entier LFP data block
in one go. For now we just stick to parsing the DTD from it.

Also fix the misleading comment about block 42 being deprecated.
Only the DTD part is deprecated, the rest is still very much needed.

v2: Move the version check+comment into parse_generic_dtd() (Jani)

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 64 ---
 1 file changed, 34 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 81949c36ab96..8a1086721525 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -489,25 +489,16 @@ parse_panel_options(struct drm_i915_private *i915)
}
 }
 
-/* Try to find integrated panel timing data */
 static void
-parse_lfp_panel_dtd(struct drm_i915_private *i915)
+parse_lfp_panel_dtd(struct drm_i915_private *i915,
+   const struct bdb_lvds_lfp_data *lvds_lfp_data,
+   const struct bdb_lvds_lfp_data_ptrs *lvds_lfp_data_ptrs)
 {
-   const struct bdb_lvds_lfp_data *lvds_lfp_data;
-   const struct bdb_lvds_lfp_data_ptrs *lvds_lfp_data_ptrs;
const struct lvds_dvo_timing *panel_dvo_timing;
const struct lvds_fp_timing *fp_timing;
struct drm_display_mode *panel_fixed_mode;
int panel_type = i915->vbt.panel_type;
 
-   lvds_lfp_data = find_section(i915, BDB_LVDS_LFP_DATA);
-   if (!lvds_lfp_data)
-   return;
-
-   lvds_lfp_data_ptrs = find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
-   if (!lvds_lfp_data_ptrs)
-   return;
-
panel_dvo_timing = get_lvds_dvo_timing(lvds_lfp_data,
   lvds_lfp_data_ptrs,
   panel_type);
@@ -538,6 +529,24 @@ parse_lfp_panel_dtd(struct drm_i915_private *i915)
}
 }
 
+static void
+parse_lfp_data(struct drm_i915_private *i915)
+{
+   const struct bdb_lvds_lfp_data *data;
+   const struct bdb_lvds_lfp_data_ptrs *ptrs;
+
+   ptrs = find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
+   if (!ptrs)
+   return;
+
+   data = find_section(i915, BDB_LVDS_LFP_DATA);
+   if (!data)
+   return;
+
+   if (!i915->vbt.lfp_lvds_vbt_mode)
+   parse_lfp_panel_dtd(i915, data, ptrs);
+}
+
 static void
 parse_generic_dtd(struct drm_i915_private *i915)
 {
@@ -546,6 +555,17 @@ parse_generic_dtd(struct drm_i915_private *i915)
struct drm_display_mode *panel_fixed_mode;
int num_dtd;
 
+   /*
+* Older VBTs provided DTD information for internal displays through
+* the "LFP panel tables" block (42).  As of VBT revision 229 the
+* DTD information should be provided via a newer "generic DTD"
+* block (58).  Just to be safe, we'll try the new generic DTD block
+* first on VBT >= 229, but still fall back to trying the old LFP
+* block if that fails.
+*/
+   if (i915->vbt.version < 229)
+   return;
+
generic_dtd = find_section(i915, BDB_GENERIC_DTD);
if (!generic_dtd)
return;
@@ -616,23 +636,6 @@ parse_generic_dtd(struct drm_i915_private *i915)
i915->vbt.lfp_lvds_vbt_mode = panel_fixed_mode;
 }
 
-static void
-parse_panel_dtd(struct drm_i915_private *i915)
-{
-   /*
-* Older VBTs provided provided DTD information for internal displays
-* through the "LFP panel DTD" block (42).  As of VBT revision 229,
-* that block is now deprecated and DTD information should be provided
-* via a newer "generic DTD" block (58).  Just to be safe, we'll
-* try the new generic DTD block first on VBT >= 229, but still fall
-* back to trying the old LFP block if that fails.
-*/
-   if (i915->vbt.version >= 229)
-   parse_generic_dtd(i915);
-   if (!i915->vbt.lfp_lvds_vbt_mode)
-   parse_lfp_panel_dtd(i915);
-}
-
 static void
 parse_lfp_backlight(struct drm_i915_private *i915)
 {
@@ -2709,7 +2712,8 @@ void intel_bios_init(struct drm_i915_private *i915)
parse_general_features(i915);
parse_general_definitions(i915);
parse_panel_options(i915);
-   parse_panel_dtd(i915);
+   parse_generic_dtd(i915);
+   parse_lfp_data(i915);
parse_lfp_backlight(i915);
parse_sdvo_panel_data(i915);
parse_driver_features(i915);
-- 
2.35.1

[Intel-gfx] [PATCH v3 00/18] drm/i915/bios: Rework BDB block handling and PNPID->panel_type matching

[Ville Syrjala]

From: Ville Syrjälä 

Several changes to our BDB block handling:

1)
The current way of trusting the version checks to avoid out of
bounds accesses to the BDB blocks is fragile. We might just get
the version check wrong, or the VBT may be corrupted/malicious.
So instead of doing blind accesses into the original data let's
make a copy of each block with a gauranteed minimum size.

2)
The LFP data table pointer stuff is a horrible mess currently.
Let's make that sensible by verifying the pointers ahead of
time, which allows us to trust them 100% when we acually
parse the actual data block.

3)
There's more stuff at the tail end of the LFP data block we
need to parse. The variable size of the fp_timing table makes
that a bit awkward, but with the pointer validation in place
it's not too horrible.

4)
Modern VBTs (seen it on TGL/ADL-P/CML so far) no longer include
the LFP data table pointers block (41) in the VBT. In order to
keep the rest of the code working as is we must therefore
generate the pointers block from scratch.

New stuff in v2:
- Make all the BDB block copies up front
- Split the VBT parsing into two parts and add the EDID
  PNPID->panel_type matching because many modern machines need it
v3:
- Some stuff already merged
- Split out a few things
- Address a bunch of review comments

Ville Syrjälä (18):
  drm/i915/bios: Reorder panel DTD parsing
  drm/i915/bios: Generate LFP data table pointers if the VBT lacks them
  drm/i915/bios: Get access to the tail end of the LFP data block
  drm/i915/bios: Document the mess around the LFP data tables
  drm/i915/bios: Assume panel_type==0 if the VBT has bogus data
  drm/i915/bios: Split parse_driver_features() into two parts
  drm/i915/bios: Split VBT parsing to global vs. panel specific parts
  drm/i915/bios: Don't parse some panel specific data multiple times
  drm/i915/pps: Split PPS init+sanitize in two
  drm/i915/pps: Reinit PPS delays after VBT has been fully parsed
  drm/i915/bios: Do panel specific VBT parsing later
  drm/i915/bios: Extract get_panel_type()
  drm/i915/bios: Refactor panel_type code
  drm/i915/bios: Determine panel type via PNPID match
  drm/i915/bios: Parse the seamless DRRS min refresh rate
  drm/i915: Respect VBT seamless DRRS min refresh rate
  drm/edid: Extract drm_edid_decode_mfg_id()
  drm/i915/bios: Dump PNPID and panel name

 drivers/gpu/drm/i915/display/icl_dsi.c|   2 +
 drivers/gpu/drm/i915/display/intel_bios.c | 490 +++---
 drivers/gpu/drm/i915/display/intel_bios.h |   3 +
 drivers/gpu/drm/i915/display/intel_dp.c   |   4 +
 drivers/gpu/drm/i915/display/intel_lvds.c |   2 +
 drivers/gpu/drm/i915/display/intel_panel.c|  10 +-
 drivers/gpu/drm/i915/display/intel_pps.c  |  35 +-
 drivers/gpu/drm/i915/display/intel_pps.h  |   1 +
 drivers/gpu/drm/i915/display/intel_sdvo.c |   3 +
 drivers/gpu/drm/i915/display/intel_vbt_defs.h |  24 +-
 drivers/gpu/drm/i915/display/vlv_dsi.c|   2 +
 drivers/gpu/drm/i915/i915_drv.h   |   1 +
 include/drm/drm_edid.h|  21 +-
 13 files changed, 526 insertions(+), 72 deletions(-)

-- 
2.35.1

Re: [Intel-gfx] [PULL] gvt-next

[Robert Beckett]

On 26/04/2022 17:58, Wang, Zhi A wrote:

On 4/26/22 3:53 PM, Jason Gunthorpe wrote:

On Tue, Apr 26, 2022 at 07:58:59AM +, Wang, Zhi A wrote:

Hi folks:

Here is the pull of gvt-next which fixs the compilation error when i915 debug
is open after the GVT-g refactor patches.

Thanks so much for the efforts.

Thanks,
Zhi.

The following changes since commit 2917f53113be3b7a0f374e02cebe6d6b749366b5:

   vfio/mdev: Remove mdev drvdata (2022-04-21 07:36:56 -0400)

are available in the Git repository at:

   https://github.com/intel/gvt-linux tags/gvt-next-2022-04-26

for you to fetch changes up to 2da299cee780ea797b3f72558687868072cf5eb5:

   drm/i915/gvt: Add missing export of symbols. (2022-04-25 18:03:04 -0400)

gvt-next-2022-04-26

- Add two missing exports of symbols when i915 debug is enabled.

Zhi Wang (1):
   drm/i915/gvt: Add missing export of symbols.

  drivers/gpu/drm/i915/intel_gvt.c | 2 ++
  1 file changed, 2 insertions(+)


This still has another compile problem:

ERROR: modpost: "intel_runtime_pm_put" [vmlinux] is a static EXPORT_SYMBOL_GPL

Because:

#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
void intel_runtime_pm_put(struct intel_runtime_pm *rpm, intel_wakeref_t wref);
#else
static inline void
intel_runtime_pm_put(struct intel_runtime_pm *rpm, intel_wakeref_t wref)
{
 intel_runtime_pm_put_unchecked(rpm);
}
#endif

Looks like it happens if CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n

I think you probably want to #ifdef the export in the same way:

--- a/drivers/gpu/drm/i915/intel_gvt.c
+++ b/drivers/gpu/drm/i915/intel_gvt.c
@@ -309,7 +309,9 @@ EXPORT_SYMBOL_NS_GPL(__intel_context_do_pin, I915_GVT);
  EXPORT_SYMBOL_NS_GPL(__intel_context_do_unpin, I915_GVT);
  EXPORT_SYMBOL_NS_GPL(intel_ring_begin, I915_GVT);
  EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_get, I915_GVT);
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
  EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_put, I915_GVT);
+#endif

Sigh. That's tricky. Let me prepare another one.


Also the following compile error:

drivers/gpu/drm/i915/gvt/handlers.c:75:6: error: no previous prototype 
for ‘intel_gvt_match_device’ [-Werror=missing-prototypes]


   75 | bool intel_gvt_match_device(struct intel_gvt *gvt,

  |  ^~


it was removed from a header. The implementation should now be made static


  EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_put_unchecked, I915_GVT);
  EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_for_reg, I915_GVT);
  EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_get, I915_GVT);

Jason

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/rc6: Access RC6 CTRL regs with forcewake

[Patchwork]

== Series Details ==

Series: drm/i915/rc6: Access RC6 CTRL regs with forcewake
URL   : https://patchwork.freedesktop.org/series/103156/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103156v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 12)
--

  Additional (2): shard-rkl shard-tglu 

New tests
-

  New tests have been introduced between CI_DRM_11550_full and 
Patchwork_103156v1_full:

### New IGT tests (1) ###

  * igt@kms_sequence@get-forked-busy@hdmi-a-1-pipe-d:
- Statuses : 1 pass(s)
- Exec time: [1.25] s

  

Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-skl:  ([PASS][1], [PASS][2], [PASS][3], [PASS][4], 
[PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], 
[PASS][12], [FAIL][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], 
[PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], 
[PASS][24]) ([i915#5032]) -> ([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], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], 
[PASS][47], [PASS][48])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/shard-skl9/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/shard-skl9/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/shard-skl9/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/shard-skl8/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/shard-skl8/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/shard-skl8/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/shard-skl7/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/shard-skl7/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/shard-skl7/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/shard-skl6/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/shard-skl6/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/shard-skl6/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/shard-skl4/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/shard-skl4/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/shard-skl4/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/shard-skl2/boot.html
   [41]: 

Re: [Intel-gfx] [PATCH 06/19] drm/edid: clean up cea_db_is_*() functions

[Ville Syrjälä]

On Thu, Apr 14, 2022 at 06:06:49PM +0300, Jani Nikula wrote:
> Abstract helpers for matching vendor data blocks and extended tags, and
> use them to simplify all the cea_db_is_*() functions.
> 
> Take void pointer as parameter to allow transitional use for both u8 *
> and struct cea_db *.
> 
> v2: Remove superfluous parens (Ville)
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_edid.c | 127 -
>  1 file changed, 40 insertions(+), 87 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 43d9e04f8fb9..34897b1417a5 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4360,12 +4360,6 @@ do_hdmi_vsdb_modes(struct drm_connector *connector, 
> const u8 *db, u8 len,
>   return modes;
>  }
>  
> -static int
> -cea_db_extended_tag(const u8 *db)
> -{
> - return db[1];
> -}
> -
>  static int
>  cea_revision(const u8 *cea)
>  {
> @@ -4477,6 +4471,22 @@ static const void *cea_db_data(const struct cea_db *db)
>   return db->data;
>  }
>  
> +static bool cea_db_is_extended_tag(const struct cea_db *db, int tag)
> +{
> + return cea_db_tag(db) == CTA_DB_EXTENDED_TAG &&
> + cea_db_payload_len(db) >= 1 &&
> + db->data[0] == tag;
> +}
> +
> +static bool cea_db_is_vendor(const struct cea_db *db, int vendor_oui)
> +{
> + const u8 *data = cea_db_data(db);
> +
> + return cea_db_tag(db) == CTA_DB_VENDOR &&
> + cea_db_payload_len(db) >= 3 &&
> + oui(data[2], data[1], data[0]) == vendor_oui;
> +}
> +
>  static void cea_db_iter_edid_begin(const struct edid *edid, struct 
> cea_db_iter *iter)
>  {
>   memset(iter, 0, sizeof(*iter));
> @@ -4611,93 +4621,50 @@ static void cea_db_iter_end(struct cea_db_iter *iter)
>   memset(iter, 0, sizeof(*iter));
>  }
>  
> -static bool cea_db_is_hdmi_vsdb(const u8 *db)
> +static bool cea_db_is_hdmi_vsdb(const void *db)
>  {
> - if (cea_db_tag(db) != CTA_DB_VENDOR)
> - return false;
> -
> - if (cea_db_payload_len(db) < 5)
> - return false;
> -
> - return oui(db[3], db[2], db[1]) == HDMI_IEEE_OUI;
> + return cea_db_is_vendor(db, HDMI_IEEE_OUI) &&
> + cea_db_payload_len(db) >= 5;
>  }
>  
> -static bool cea_db_is_hdmi_forum_vsdb(const u8 *db)
> +static bool cea_db_is_hdmi_forum_vsdb(const void *db)
>  {
> - if (cea_db_tag(db) != CTA_DB_VENDOR)
> - return false;
> -
> - if (cea_db_payload_len(db) < 7)
> - return false;
> -
> - return oui(db[3], db[2], db[1]) == HDMI_FORUM_IEEE_OUI;
> + return cea_db_is_vendor(db, HDMI_FORUM_IEEE_OUI) &&
> + cea_db_payload_len(db) >= 7;
>  }
>  
> -static bool cea_db_is_microsoft_vsdb(const u8 *db)
> +static bool cea_db_is_microsoft_vsdb(const void *db)
>  {
> - if (cea_db_tag(db) != CTA_DB_VENDOR)
> - return false;
> -
> - if (cea_db_payload_len(db) != 21)
> - return false;
> -
> - return oui(db[3], db[2], db[1]) == MICROSOFT_IEEE_OUI;
> + return cea_db_is_vendor(db, MICROSOFT_IEEE_OUI) &&
> + cea_db_payload_len(db) == 21;
>  }
>  
> -static bool cea_db_is_vcdb(const u8 *db)
> +static bool cea_db_is_vcdb(const void *db)
>  {
> - if (cea_db_tag(db) != CTA_DB_EXTENDED_TAG)
> - return false;
> -
> - if (cea_db_payload_len(db) != 2)
> - return false;
> -
> - if (cea_db_extended_tag(db) != CTA_EXT_DB_VIDEO_CAP)
> - return false;
> -
> - return true;
> + return cea_db_is_extended_tag(db, CTA_EXT_DB_VIDEO_CAP) &&
> + cea_db_payload_len(db) == 2;
>  }
>  
> -static bool cea_db_is_hdmi_forum_scdb(const u8 *db)
> +static bool cea_db_is_hdmi_forum_scdb(const void *db)
>  {
> - if (cea_db_tag(db) != CTA_DB_EXTENDED_TAG)
> - return false;
> -
> - if (cea_db_payload_len(db) < 7)
> - return false;
> -
> - if (cea_db_extended_tag(db) != CTA_EXT_DB_HF_SCDB)
> - return false;
> -
> - return true;
> + return cea_db_is_extended_tag(db, CTA_EXT_DB_HF_SCDB) &&
> + cea_db_payload_len(db) >= 7;
>  }
>  
> -static bool cea_db_is_y420cmdb(const u8 *db)
> +static bool cea_db_is_y420cmdb(const void *db)
>  {
> - if (cea_db_tag(db) != CTA_DB_EXTENDED_TAG)
> - return false;
> -
> - if (!cea_db_payload_len(db))
> - return false;
> -
> - if (cea_db_extended_tag(db) != CTA_EXT_DB_420_VIDEO_CAP_MAP)
> - return false;
> -
> - return true;
> + return cea_db_is_extended_tag(db, CTA_EXT_DB_420_VIDEO_CAP_MAP);
>  }
>  
> -static bool cea_db_is_y420vdb(const u8 *db)
> +static bool cea_db_is_y420vdb(const void *db)
>  {
> - if (cea_db_tag(db) != CTA_DB_EXTENDED_TAG)
> - return false;
> -
> - if (!cea_db_payload_len(db))
> - return false;
> -
> - if (cea_db_extended_tag(db) != 

Re: [Intel-gfx] [PATCH 02/19] drm/edid: check for HF-SCDB block

[Ville Syrjälä]

On Thu, Apr 14, 2022 at 06:06:45PM +0300, Jani Nikula wrote:
> From: Lee Shawn C 
> 
> Find HF-SCDB information in CEA extensions block. And retrieve
> Max_TMDS_Character_Rate that support by sink device.
> 
> v2: HF-SCDB and HF-VSDBS carry the same SCDS data. Reuse
> drm_parse_hdmi_forum_vsdb() to parse this packet.
> 
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Ankit Nautiyal 
> Cc: intel-gfx 
> Signed-off-by: Lee Shawn C 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 4758e78fad82..32ece9607b94 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3495,6 +3495,7 @@ add_detailed_modes(struct drm_connector *connector, 
> const struct edid *edid,
>  #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
>  #define EXT_VIDEO_DATA_BLOCK_420 0x0E
>  #define EXT_VIDEO_CAP_BLOCK_Y420CMDB 0x0F
> +#define EXT_VIDEO_HF_SCDB_DATA_BLOCK 0x79
>  #define EDID_BASIC_AUDIO (1 << 6)
>  #define EDID_CEA_YCRCB444(1 << 5)
>  #define EDID_CEA_YCRCB422(1 << 4)
> @@ -4426,6 +4427,20 @@ static bool cea_db_is_vcdb(const u8 *db)
>   return true;
>  }
>  
> +static bool cea_db_is_hdmi_forum_scdb(const u8 *db)
> +{
> + if (cea_db_tag(db) != USE_EXTENDED_TAG)
> + return false;
> +
> + if (cea_db_payload_len(db) < 7)
> + return false;
> +
> + if (cea_db_extended_tag(db) != EXT_VIDEO_HF_SCDB_DATA_BLOCK)
> + return false;
> +
> + return true;
> +}
> +
>  static bool cea_db_is_y420cmdb(const u8 *db)
>  {
>   if (cea_db_tag(db) != USE_EXTENDED_TAG)
> @@ -5387,7 +5402,8 @@ static void drm_parse_cea_ext(struct drm_connector 
> *connector,
>  
>   if (cea_db_is_hdmi_vsdb(db))
>   drm_parse_hdmi_vsdb_video(connector, db);
> - if (cea_db_is_hdmi_forum_vsdb(db))
> + if (cea_db_is_hdmi_forum_vsdb(db) ||
> + cea_db_is_hdmi_forum_scdb(db))
>   drm_parse_hdmi_forum_vsdb(connector, db);

I'd do a s/parse_hdmi_forum_vsdb/parse_scds/ to keep up
with the spec terminology.

Reviewed-by: Ville Syrjälä 

>   if (cea_db_is_microsoft_vsdb(db))
>   drm_parse_microsoft_vsdb(connector, db);
> -- 
> 2.30.2

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH 01/19] drm/edid: reset display info in drm_add_edid_modes() for NULL edid

[Ville Syrjälä]

On Thu, Apr 14, 2022 at 06:06:44PM +0300, Jani Nikula wrote:
> If a NULL edid gets passed to drm_add_edid_modes(), we should probably
> also reset the display info.

One concern I had with this is resetting of eg. {width,height}_mm
which might have been populated by intel_panel_add_fixed_mode().
But I think that might already happen anyway through one of the
other codepaths that call drm_reset_display_info() so probably not
something that is made any worse by this patch.

IIRC at one point I tried to startd cleaning up the display_info
mess a bit but the patches got stuck in some silly bikeshed
so I gave up.

Reviewed-by: Ville Syrjälä 

> 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 324ce8467915..4758e78fad82 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5721,6 +5721,7 @@ static int drm_edid_connector_update(struct 
> drm_connector *connector,
>   u32 quirks;
>  
>   if (edid == NULL) {
> + drm_reset_display_info(connector);
>   clear_eld(connector);
>   return 0;
>   }
> -- 
> 2.30.2

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH 1/3] drm: Add infrastructure to allow seamless mode switches

[Ville Syrjälä]

On Tue, Apr 26, 2022 at 06:32:01PM +, Souza, Jose wrote:
> On Tue, 2022-04-26 at 21:08 +0300, Ville Syrjälä wrote:
> > On Thu, Apr 21, 2022 at 12:22:03PM -0700, José Roberto de Souza wrote:
> > > Intel hardware supports change between modes with different refresh
> > > rates without any glitches or visual artifacts, that feature is called
> > > seamless DRRS.
> > > 
> > > So far i915 driver was automatically changing between preferred panel
> > > mode and lower refresh rate mode based on idleness but ChromeOS
> > > compositor team is requesting to be in control of the mode switch.
> > > So for a certain types of content it can switch to mode with a lower
> > > refresh rate without user noticing a thing and saving power.
> > > 
> > > This seamless mode switch will be triggered when user-space dispatch
> > > a atomic commit with the new mode and clears the
> > > DRM_MODE_ATOMIC_ALLOW_MODESET flag.
> > > 
> > > A driver that don't implement atomic_seamless_mode_switch_check
> > > function will continue to fail in the atomic check phase with
> > > "[CRTC:%d:%s] requires full modeset" debug message.
> > > While a driver that implements it and support the seamless change
> > > between old and new mode will return 0 otherwise it should return the
> > > appropried errno.
> > > 
> > > So here adding basic drm infrastructure to that be supported by i915
> > > and other drivers.
> > 
> > I don't see the need for any extra infrastructure for this.
> > 
> > I think we just need:
> > - fix the fastset code to not suck
> 
> How would it know that only mode changed and not all other things that causes 
> mode_changed to be set?
> For example: intel_digital_connector_atomic_check()

That's what the fastset stuff does. It checks if anything changes
that needs a full modeset or not.

> 
> > - reprogram M/N during fastset
> > - calculate eDP link params using panel's highest refresh rate mode
> >   to make sure we get the same link params for all refresh rates
> > 
> > > 
> > > Cc: Vidya Srinivas 
> > > Cc: Sean Paul 
> > > Cc: Ville Syrjälä 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/drm_atomic.c  |  1 +
> > >  drivers/gpu/drm/drm_atomic_helper.c   | 16 +++
> > >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> > >  include/drm/drm_crtc.h| 25 +++
> > >  4 files changed, 43 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index 58c0283fb6b0c..21525f9f4b4c1 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -437,6 +437,7 @@ static void drm_atomic_crtc_print_state(struct 
> > > drm_printer *p,
> > >   drm_printf(p, "\tself_refresh_active=%d\n", state->self_refresh_active);
> > >   drm_printf(p, "\tplanes_changed=%d\n", state->planes_changed);
> > >   drm_printf(p, "\tmode_changed=%d\n", state->mode_changed);
> > > + drm_printf(p, "\tseamless_mode_changed=%d\n", 
> > > state->seamless_mode_changed);
> > >   drm_printf(p, "\tactive_changed=%d\n", state->active_changed);
> > >   drm_printf(p, "\tconnectors_changed=%d\n", state->connectors_changed);
> > >   drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 9603193d2fa13..e6f3a966f7b86 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -631,6 +631,22 @@ drm_atomic_helper_check_modeset(struct drm_device 
> > > *dev,
> > >   drm_dbg_atomic(dev, "[CRTC:%d:%s] mode changed\n",
> > >  crtc->base.id, crtc->name);
> > >   new_crtc_state->mode_changed = true;
> > > +
> > > + if (!state->allow_modeset &&
> > > + crtc->funcs->atomic_seamless_mode_switch_check) {
> > > + ret = 
> > > crtc->funcs->atomic_seamless_mode_switch_check(state, crtc);
> > > + if (ret == -EOPNOTSUPP) {
> > > + drm_dbg_atomic(dev, "[CRTC:%d:%s] 
> > > Seamless mode switch not supported\n",
> > > +crtc->base.id, 
> > > crtc->name);
> > > + return ret;
> > > + }
> > > +
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + new_crtc_state->seamless_mode_changed = true;
> > > + new_crtc_state->mode_changed = false;
> > > + }
> > >   }
> > >  
> > >   if (old_crtc_state->enable != new_crtc_state->enable) {
> > > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
> > > b/drivers/gpu/drm/drm_atomic_state_helper.c
> > > index 3b6d3bdbd0996..c093073ea6e11 100644
> > > --- 

[Intel-gfx] [PATCH v2 3/4] drm/i915: Clean up DPLL related debugs

[Ville Syrjala]

From: Ville Syrjälä 

The debugs in lower level DPLL code don't really provide any
useful extra information AFAICS. Better just streamline the
code and just put the necessary debugs (to identify at which
step the modeset failed) into the higher level code. In
addition we'll get the full state dump as well, which should
hopefully have enough information to figure out what went wrong.

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dpll.c | 75 +++
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 48 +++-
 2 files changed, 35 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c 
b/drivers/gpu/drm/i915/display/intel_dpll.c
index 7f0538ee2b51..2b3f72550e5a 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -954,21 +954,12 @@ static int hsw_crtc_get_shared_dpll(struct 
intel_atomic_state *state,
intel_atomic_get_new_crtc_state(state, crtc);
struct intel_encoder *encoder =
intel_get_crtc_new_encoder(state, crtc_state);
-   int ret;
 
if (DISPLAY_VER(dev_priv) < 11 &&
intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI))
return 0;
 
-   ret = intel_reserve_shared_dplls(state, crtc, encoder);
-   if (ret) {
-   drm_dbg_kms(_priv->drm,
-   "failed to find PLL for pipe %c\n",
-   pipe_name(crtc->pipe));
-   return ret;
-   }
-
-   return 0;
+   return intel_reserve_shared_dplls(state, crtc, encoder);
 }
 
 static int dg2_crtc_compute_clock(struct intel_atomic_state *state,
@@ -1135,11 +1126,8 @@ static int ilk_crtc_compute_clock(struct 
intel_atomic_state *state,
 
if (!crtc_state->clock_set &&
!g4x_find_best_dpll(limit, crtc_state, crtc_state->port_clock,
-   refclk, NULL, _state->dpll)) {
-   drm_err(_priv->drm,
-   "Couldn't find PLL settings for mode!\n");
+   refclk, NULL, _state->dpll))
return -EINVAL;
-   }
 
ilk_compute_dpll(crtc_state, _state->dpll,
 _state->dpll);
@@ -1150,24 +1138,14 @@ static int ilk_crtc_compute_clock(struct 
intel_atomic_state *state,
 static int ilk_crtc_get_shared_dpll(struct intel_atomic_state *state,
struct intel_crtc *crtc)
 {
-   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
-   int ret;
 
/* CPU eDP is the only output that doesn't need a PCH PLL of its own. */
if (!crtc_state->has_pch_encoder)
return 0;
 
-   ret = intel_reserve_shared_dplls(state, crtc, NULL);
-   if (ret) {
-   drm_dbg_kms(_priv->drm,
-   "failed to find PLL for pipe %c\n",
-   pipe_name(crtc->pipe));
-   return ret;
-   }
-
-   return 0;
+   return intel_reserve_shared_dplls(state, crtc, NULL);
 }
 
 void vlv_compute_dpll(struct intel_crtc_state *crtc_state)
@@ -1208,7 +1186,6 @@ void chv_compute_dpll(struct intel_crtc_state *crtc_state)
 static int chv_crtc_compute_clock(struct intel_atomic_state *state,
  struct intel_crtc *crtc)
 {
-   struct drm_i915_private *i915 = to_i915(state->base.dev);
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
const struct intel_limit *limit = _limits_chv;
@@ -1216,10 +1193,8 @@ static int chv_crtc_compute_clock(struct 
intel_atomic_state *state,
 
if (!crtc_state->clock_set &&
!chv_find_best_dpll(limit, crtc_state, crtc_state->port_clock,
-   refclk, NULL, _state->dpll)) {
-   drm_err(>drm, "Couldn't find PLL settings for mode!\n");
+   refclk, NULL, _state->dpll))
return -EINVAL;
-   }
 
chv_compute_dpll(crtc_state);
 
@@ -1229,7 +1204,6 @@ static int chv_crtc_compute_clock(struct 
intel_atomic_state *state,
 static int vlv_crtc_compute_clock(struct intel_atomic_state *state,
  struct intel_crtc *crtc)
 {
-   struct drm_i915_private *i915 = to_i915(state->base.dev);
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
const struct intel_limit *limit = _limits_vlv;
@@ -1238,7 +1212,6 @@ static int vlv_crtc_compute_clock(struct 
intel_atomic_state *state,
if (!crtc_state->clock_set &&
!vlv_find_best_dpll(limit, crtc_state, crtc_state->port_clock,
refclk, NULL, _state->dpll)) {
-   drm_err(>drm,  "Couldn't find PLL settings for 

[Intel-gfx] [PATCH v2 4/4] drm/i915: Reassign DPLLs only for crtcs going throug .compute_config()

[Ville Syrjala]

From: Ville Syrjälä 

Only reassign the pipe's DPLL if it's going through a full
.compute_config() cycle. If OTOH it's just getting modeset
eg. in order to change cdclk there doesn't seem much point in
picking a new DPLL for it.

This should also prevent .get_dplls() from seeing a funky port_clock
for DP even in cases where the readout produces a non-standard
clock and we (for some reason) have decided to not fully recompute
the state to remedy the situation.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 17 +
 drivers/gpu/drm/i915/display/intel_dpll.c|  6 ++
 2 files changed, 3 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 5e50e0d56088..7d488d320762 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6955,20 +6955,6 @@ intel_crtc_update_active_timings(const struct 
intel_crtc_state *crtc_state)
}
 }
 
-static void intel_modeset_clear_plls(struct intel_atomic_state *state)
-{
-   struct intel_crtc_state *new_crtc_state;
-   struct intel_crtc *crtc;
-   int i;
-
-   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
-   if (!intel_crtc_needs_modeset(new_crtc_state))
-   continue;
-
-   intel_release_shared_dplls(state, crtc);
-   }
-}
-
 /*
  * This implements the workaround described in the "notes" section of the mode
  * set sequence documentation. When going from no pipes or single pipe to
@@ -7802,6 +7788,7 @@ static int intel_atomic_check(struct drm_device *dev,
if (ret)
goto fail;
 
+   intel_release_shared_dplls(state, crtc);
continue;
}
 
@@ -7849,8 +7836,6 @@ static int intel_atomic_check(struct drm_device *dev,
ret = intel_modeset_calc_cdclk(state);
if (ret)
return ret;
-
-   intel_modeset_clear_plls(state);
}
 
ret = intel_atomic_check_crtcs(state);
diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c 
b/drivers/gpu/drm/i915/display/intel_dpll.c
index 2b3f72550e5a..afd30c6cc34c 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -1436,11 +1436,9 @@ int intel_dpll_crtc_get_shared_dpll(struct 
intel_atomic_state *state,
int ret;
 
drm_WARN_ON(>drm, !intel_crtc_needs_modeset(crtc_state));
+   drm_WARN_ON(>drm, !crtc_state->hw.enable && 
crtc_state->shared_dpll);
 
-   if (drm_WARN_ON(>drm, crtc_state->shared_dpll))
-   return 0;
-
-   if (!crtc_state->hw.enable)
+   if (!crtc_state->hw.enable || crtc_state->shared_dpll)
return 0;
 
if (!i915->dpll_funcs->crtc_get_shared_dpll)
-- 
2.35.1

[Intel-gfx] [PATCH v2 2/4] drm/i915: Do .crtc_compute_clock() earlier

[Ville Syrjala]

From: Ville Syrjälä 

Currently we calculate a lot of things (pixel rate, watermarks,
cdclk) trusting that the DPLL can generate the exact frequency
we ask it. In practice that is not true and there can be
certain amount of rounding involved.

To allow us to eventually get accurate numbers for all our
DPLL clock derived state we need to move the DPLL calculation
to hapen much earlier. To that end we hoist it up to the just
after the fastset checks. For now we just do the easy code
motion, and the actual back feeding of the final DPLL clock
into the state will come later.

A slight change here is that now .crtc_compute_clock()
can get called while the shared_dpll is still assigned.
But since .crtc_compute_clock() no longer assignes new
shared_dplls this is perfectly fine.

TODO: I'd actually like to do this before the fastset check
so that if the DPLL state should change we actually do the
modeset. Which I think is what the video aficionados want,
but it might not be what the fans of fastboot want. Not yet
sure how to reconcile those conflicting requirements...

v2: s/return/goto/ in error handling

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 9 +
 drivers/gpu/drm/i915/display/intel_dpll.c| 3 ---
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 0decf3d24237..5e50e0d56088 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4905,10 +4905,6 @@ static int intel_crtc_atomic_check(struct 
intel_atomic_state *state,
crtc_state->update_wm_post = true;
 
if (mode_changed) {
-   ret = intel_dpll_crtc_compute_clock(state, crtc);
-   if (ret)
-   return ret;
-
ret = intel_dpll_crtc_get_shared_dpll(state, crtc);
if (ret)
return ret;
@@ -7801,6 +7797,11 @@ static int intel_atomic_check(struct drm_device *dev,
new_crtc_state, i) {
if (intel_crtc_needs_modeset(new_crtc_state)) {
any_ms = true;
+
+   ret = intel_dpll_crtc_compute_clock(state, crtc);
+   if (ret)
+   goto fail;
+
continue;
}
 
diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c 
b/drivers/gpu/drm/i915/display/intel_dpll.c
index c19fb075ee6e..7f0538ee2b51 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -1449,9 +1449,6 @@ int intel_dpll_crtc_compute_clock(struct 
intel_atomic_state *state,
 
drm_WARN_ON(>drm, !intel_crtc_needs_modeset(crtc_state));
 
-   if (drm_WARN_ON(>drm, crtc_state->shared_dpll))
-   return 0;
-
memset(_state->dpll_hw_state, 0,
   sizeof(crtc_state->dpll_hw_state));
 
-- 
2.35.1

[Intel-gfx] [PATCH v2 1/4] drm/i915: Split shared dpll .get_dplls() into compute and get phases

[Ville Syrjala]

From: Ville Syrjälä 

Split the DPLL state computation into a separate function
from the current .get_dplls() which currently serves a dual duty
by also reserving the shared DPLLs.

v2: s/false/-EINVAL/ (Jani)

Cc: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dpll.c |  14 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 291 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.h |   3 +
 3 files changed, 235 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c 
b/drivers/gpu/drm/i915/display/intel_dpll.c
index 6eef0b8a91eb..c19fb075ee6e 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -933,7 +933,17 @@ static void i8xx_compute_dpll(struct intel_crtc_state 
*crtc_state,
 static int hsw_crtc_compute_clock(struct intel_atomic_state *state,
  struct intel_crtc *crtc)
 {
-   return 0;
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   struct intel_crtc_state *crtc_state =
+   intel_atomic_get_new_crtc_state(state, crtc);
+   struct intel_encoder *encoder =
+   intel_get_crtc_new_encoder(state, crtc_state);
+
+   if (DISPLAY_VER(dev_priv) < 11 &&
+   intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI))
+   return 0;
+
+   return intel_compute_shared_dplls(state, crtc, encoder);
 }
 
 static int hsw_crtc_get_shared_dpll(struct intel_atomic_state *state,
@@ -1134,7 +1144,7 @@ static int ilk_crtc_compute_clock(struct 
intel_atomic_state *state,
ilk_compute_dpll(crtc_state, _state->dpll,
 _state->dpll);
 
-   return 0;
+   return intel_compute_shared_dplls(state, crtc, NULL);
 }
 
 static int ilk_crtc_get_shared_dpll(struct intel_atomic_state *state,
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 22f55574a35c..4c5c3439b745 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -90,6 +90,9 @@ struct intel_shared_dpll_funcs {
 struct intel_dpll_mgr {
const struct dpll_info *dpll_info;
 
+   int (*compute_dplls)(struct intel_atomic_state *state,
+struct intel_crtc *crtc,
+struct intel_encoder *encoder);
int (*get_dplls)(struct intel_atomic_state *state,
 struct intel_crtc *crtc,
 struct intel_encoder *encoder);
@@ -514,6 +517,13 @@ static void ibx_pch_dpll_disable(struct drm_i915_private 
*dev_priv,
udelay(200);
 }
 
+static int ibx_compute_dpll(struct intel_atomic_state *state,
+   struct intel_crtc *crtc,
+   struct intel_encoder *encoder)
+{
+   return 0;
+}
+
 static int ibx_get_dpll(struct intel_atomic_state *state,
struct intel_crtc *crtc,
struct intel_encoder *encoder)
@@ -578,6 +588,7 @@ static const struct dpll_info pch_plls[] = {
 
 static const struct intel_dpll_mgr pch_pll_mgr = {
.dpll_info = pch_plls,
+   .compute_dplls = ibx_compute_dpll,
.get_dplls = ibx_get_dpll,
.put_dplls = intel_put_dpll,
.dump_hw_state = ibx_dump_hw_state,
@@ -894,33 +905,35 @@ hsw_ddi_calculate_wrpll(int clock /* in Hz */,
*r2_out = best.r2;
 }
 
-static struct intel_shared_dpll *
-hsw_ddi_wrpll_get_dpll(struct intel_atomic_state *state,
-  struct intel_crtc *crtc)
+static int
+hsw_ddi_wrpll_compute_dpll(struct intel_atomic_state *state,
+  struct intel_crtc *crtc)
 {
struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
-   struct intel_shared_dpll *pll;
-   u32 val;
unsigned int p, n2, r2;
 
hsw_ddi_calculate_wrpll(crtc_state->port_clock * 1000, , , );
 
-   val = WRPLL_PLL_ENABLE | WRPLL_REF_LCPLL |
- WRPLL_DIVIDER_REFERENCE(r2) | WRPLL_DIVIDER_FEEDBACK(n2) |
- WRPLL_DIVIDER_POST(p);
+   crtc_state->dpll_hw_state.wrpll =
+   WRPLL_PLL_ENABLE | WRPLL_REF_LCPLL |
+   WRPLL_DIVIDER_REFERENCE(r2) | WRPLL_DIVIDER_FEEDBACK(n2) |
+   WRPLL_DIVIDER_POST(p);
 
-   crtc_state->dpll_hw_state.wrpll = val;
+   return 0;
+}
 
-   pll = intel_find_shared_dpll(state, crtc,
-_state->dpll_hw_state,
-BIT(DPLL_ID_WRPLL2) |
-BIT(DPLL_ID_WRPLL1));
+static struct intel_shared_dpll *
+hsw_ddi_wrpll_get_dpll(struct intel_atomic_state *state,
+  struct intel_crtc *crtc)
+{
+   struct intel_crtc_state *crtc_state =
+   intel_atomic_get_new_crtc_state(state, crtc);
 
-   if (!pll)
-   return NULL;
-
-   

[Intel-gfx] [PATCH v2 0/4] drm/i915: Start reordering modeset clock calculations

[Ville Syrjala]

From: Ville Syrjälä 

Start reordering when we do the clock/dpll calculations
during the atomic check. The eventual goals are:
- back feed the actually calculated clock into the crtc state
  so that stuff that depends on it (eg. watermarks) will be
  calculated based on the actual hardware state we're going to use
  rather than the semi-fictional state we started with
- fix the fastset/fastboot stuff to actually require exact
  clock matches. Avoids the current mess where the user asks
  to slightly change the refresh rate (eg. to match video frame
  rate) but the kernel decides to ignore it and do a fastset instead.

v2: Repost of the remainder, earlier patches already merged

Ville Syrjälä (4):
  drm/i915: Split shared dpll .get_dplls() into compute and get phases
  drm/i915: Do .crtc_compute_clock() earlier
  drm/i915: Clean up DPLL related debugs
  drm/i915: Reassign DPLLs only for crtcs going throug .compute_config()

 drivers/gpu/drm/i915/display/intel_display.c  |  26 +-
 drivers/gpu/drm/i915/display/intel_dpll.c |  98 +++---
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 333 --
 drivers/gpu/drm/i915/display/intel_dpll_mgr.h |   3 +
 4 files changed, 275 insertions(+), 185 deletions(-)

-- 
2.35.1

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

[Lyude Paul]

Hello everyone!

The X.org board is soliciting proposals to host XDC in 2023. Since
XDC 2022 is being held in North America this year, XDC 2023 is expected
to be in Europe. However, the board is open to other locations,
especially if there's an interesting co-location with another
conference.

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

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

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

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

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

Best regards,
Lyude Paul
On behalf of X.org

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

[Lyude Paul]

Hello!

The 2022 X.Org Developers Conference is being held in conjunction with
the 2022 Wine Developers Conference.  This is a meeting to bring
together developers working on all things open graphics (Linux kernel,
Mesa, DRM, Wayland, X11, etc.) as well as developers for the Wine
Project, a key consumer of open graphics.

Registration & Call for Proposals are now open for both XDC 2022 and
WineConf 2022, which will take place on October 4-6, 2022 in
Minneapolis, Minnesota, USA. 

https://xdc2022.x.org
 
As usual, the conference is free of charge and open to the general
public. If you plan on attending, please make sure to register as early
as possible!
 
In order to register as attendee, you will therefore need to do it via
the XDC website:
 
https://indico.freedesktop.org/event/2/registrations/2/
 
In addition to registration, the CfP is now open for talks, workshops
and demos at XDC 2022. While any serious proposal will be gratefully
considered, topics of interest to X.Org and freedesktop.org developers
are encouraged. The program focus is on new development, ongoing
challenges and anything else that will spark discussions among
attendees in the hallway track.
 
We are open to talks across all layers of the graphics stack, from the
kernel to desktop environments / graphical applications and about how
to make things better for the developers who build them. Head to the
CfP page to learn more: 
 
https://indico.freedesktop.org/event/2/abstracts/
 
The deadline for submissions is Monday July 4th, 2022.
 
Check out our Reimbursement Policy to accept speaker
expenses for X.Org events like XDC 2022:
 
https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/

If you have any questions, please send me an email to
x...@codeweavers.com, adding on CC the X.org board (board
at foundation.x.org).
 
And don't forget, you can follow us on Twitter for all the latest
updates and to stay connected:
 
https://twitter.com/XOrgDevConf

Best regards,
Lyude Paul, on behalf of X.org

Re: [Intel-gfx] [PATCH 1/3] drm: Add infrastructure to allow seamless mode switches

[Souza, Jose]

On Tue, 2022-04-26 at 21:08 +0300, Ville Syrjälä wrote:
> On Thu, Apr 21, 2022 at 12:22:03PM -0700, José Roberto de Souza wrote:
> > Intel hardware supports change between modes with different refresh
> > rates without any glitches or visual artifacts, that feature is called
> > seamless DRRS.
> > 
> > So far i915 driver was automatically changing between preferred panel
> > mode and lower refresh rate mode based on idleness but ChromeOS
> > compositor team is requesting to be in control of the mode switch.
> > So for a certain types of content it can switch to mode with a lower
> > refresh rate without user noticing a thing and saving power.
> > 
> > This seamless mode switch will be triggered when user-space dispatch
> > a atomic commit with the new mode and clears the
> > DRM_MODE_ATOMIC_ALLOW_MODESET flag.
> > 
> > A driver that don't implement atomic_seamless_mode_switch_check
> > function will continue to fail in the atomic check phase with
> > "[CRTC:%d:%s] requires full modeset" debug message.
> > While a driver that implements it and support the seamless change
> > between old and new mode will return 0 otherwise it should return the
> > appropried errno.
> > 
> > So here adding basic drm infrastructure to that be supported by i915
> > and other drivers.
> 
> I don't see the need for any extra infrastructure for this.
> 
> I think we just need:
> - fix the fastset code to not suck

How would it know that only mode changed and not all other things that causes 
mode_changed to be set?
For example: intel_digital_connector_atomic_check()

> - reprogram M/N during fastset
> - calculate eDP link params using panel's highest refresh rate mode
>   to make sure we get the same link params for all refresh rates
> 
> > 
> > Cc: Vidya Srinivas 
> > Cc: Sean Paul 
> > Cc: Ville Syrjälä 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/drm_atomic.c  |  1 +
> >  drivers/gpu/drm/drm_atomic_helper.c   | 16 +++
> >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> >  include/drm/drm_crtc.h| 25 +++
> >  4 files changed, 43 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 58c0283fb6b0c..21525f9f4b4c1 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -437,6 +437,7 @@ static void drm_atomic_crtc_print_state(struct 
> > drm_printer *p,
> > drm_printf(p, "\tself_refresh_active=%d\n", state->self_refresh_active);
> > drm_printf(p, "\tplanes_changed=%d\n", state->planes_changed);
> > drm_printf(p, "\tmode_changed=%d\n", state->mode_changed);
> > +   drm_printf(p, "\tseamless_mode_changed=%d\n", 
> > state->seamless_mode_changed);
> > drm_printf(p, "\tactive_changed=%d\n", state->active_changed);
> > drm_printf(p, "\tconnectors_changed=%d\n", state->connectors_changed);
> > drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 9603193d2fa13..e6f3a966f7b86 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -631,6 +631,22 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > drm_dbg_atomic(dev, "[CRTC:%d:%s] mode changed\n",
> >crtc->base.id, crtc->name);
> > new_crtc_state->mode_changed = true;
> > +
> > +   if (!state->allow_modeset &&
> > +   crtc->funcs->atomic_seamless_mode_switch_check) {
> > +   ret = 
> > crtc->funcs->atomic_seamless_mode_switch_check(state, crtc);
> > +   if (ret == -EOPNOTSUPP) {
> > +   drm_dbg_atomic(dev, "[CRTC:%d:%s] 
> > Seamless mode switch not supported\n",
> > +  crtc->base.id, 
> > crtc->name);
> > +   return ret;
> > +   }
> > +
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   new_crtc_state->seamless_mode_changed = true;
> > +   new_crtc_state->mode_changed = false;
> > +   }
> > }
> >  
> > if (old_crtc_state->enable != new_crtc_state->enable) {
> > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
> > b/drivers/gpu/drm/drm_atomic_state_helper.c
> > index 3b6d3bdbd0996..c093073ea6e11 100644
> > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> > @@ -142,6 +142,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct 
> > drm_crtc *crtc,
> > if (state->gamma_lut)
> > drm_property_blob_get(state->gamma_lut);
> > state->mode_changed = false;
> > +   state->seamless_mode_changed = 

Re: [Intel-gfx] [PATCH] drm/i915: Support Async Flip on Linear buffers

[Ville Syrjälä]

On Tue, Apr 26, 2022 at 05:34:07PM +0530, Arun R Murthy wrote:
> Starting from Gen12 Async Flip is supported on linear buffers.

It's supported earlier than that. But IIRC there was some kind of
GTT alignment vs. async flip vs. FBC restriction that we weren't
handling.

> This patch enables support for async on linear buffer.
> 
> Signed-off-by: Arun R Murthy 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 0decf3d24237..e3bf250b85e4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7522,6 +7522,13 @@ static int intel_async_flip_check_hw(struct 
> intel_atomic_state *state, struct in
>* this selectively if required.
>*/
>   switch (new_plane_state->hw.fb->modifier) {
> + case DRM_FORMAT_MOD_LINEAR:
> + if (DISPLAY_VER(i915) < 12) {
> + drm_dbg_kms(>drm,
> + "[PLANE:%d:%s] Modifier does not 
> support async flips\n",
> + plane->base.base.id, plane->base.name);
> + return -EINVAL;
> + }
>   case I915_FORMAT_MOD_X_TILED:
>   case I915_FORMAT_MOD_Y_TILED:
>   case I915_FORMAT_MOD_Yf_TILED:
> -- 
> 2.25.1

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Replace crtc_state's has_drrs by drrs_downclock_mode

[Souza, Jose]

On Mon, 2022-04-25 at 14:55 +0300, Jani Nikula wrote:
> On Thu, 21 Apr 2022, José Roberto de Souza  wrote:
> > Will be adding some additional control options to DRRS that will
> > require to have the DRRS downclock mode stored in the crtc_state.
> > 
> > So to optimize memory usage a bit here using it to replace has_drrs
> > as we can check if the drrs_downclock_mode pointer is different than
> > null to have the same behavior has has_drrs.
> > 
> > Cc: Vidya Srinivas 
> > Cc: Sean Paul 
> > Cc: Ville Syrjälä 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
> >  drivers/gpu/drm/i915/display/intel_display_debugfs.c | 4 ++--
> >  drivers/gpu/drm/i915/display/intel_display_types.h   | 4 +++-
> >  drivers/gpu/drm/i915/display/intel_dp.c  | 2 +-
> >  drivers/gpu/drm/i915/display/intel_drrs.c| 4 ++--
> >  5 files changed, 10 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 0ddfce21a828d..a5f5caeced9a0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -5360,7 +5360,7 @@ static void intel_dump_pipe_config(const struct 
> > intel_crtc_state *pipe_config,
> >  
> > drm_dbg_kms(_priv->drm, "ips: %i, double wide: %i, drrs: %i\n",
> > pipe_config->ips_enabled, pipe_config->double_wide,
> > -   pipe_config->has_drrs);
> > +   CRTC_STATE_HAS_DRRS(pipe_config));
> 
> I'll mostly let Ville comment on the series, but that macro is an
> eyesore and also just out of place in intel_display_types.h. Please make
> it a proper function intel_drrs_something_something() in
> intel_drrs.[ch].

Okay in making this a function but I don't have a good name for it neither.
intel_crtc_state_has_drrs() is worst than current name of the macro.

> 
> BR,
> Jani.
> 
> >  
> > intel_dpll_dump_hw_state(dev_priv, _config->dpll_hw_state);
> >  
> > @@ -7088,7 +7088,7 @@ static void intel_crtc_copy_fastset(const struct 
> > intel_crtc_state *old_crtc_stat
> > new_crtc_state->fdi_m_n = old_crtc_state->fdi_m_n;
> > new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
> > new_crtc_state->dp_m2_n2 = old_crtc_state->dp_m2_n2;
> > -   new_crtc_state->has_drrs = old_crtc_state->has_drrs;
> > +   new_crtc_state->drrs_downclock_mode = 
> > old_crtc_state->drrs_downclock_mode;
> >  }
> >  
> >  static int intel_crtc_add_planes_to_state(struct intel_atomic_state *state,
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > index 452d773fd4e34..f9720562336da 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > @@ -1096,7 +1096,7 @@ static int i915_drrs_status(struct seq_file *m, void 
> > *unused)
> >  
> > /* DRRS Supported */
> > seq_printf(m, "\tDRRS Enabled: %s\n",
> > -  str_yes_no(crtc_state->has_drrs));
> > +  str_yes_no(CRTC_STATE_HAS_DRRS(crtc_state)));
> >  
> > seq_printf(m, "\tDRRS Active: %s\n",
> >str_yes_no(intel_drrs_is_active(crtc)));
> > @@ -1786,7 +1786,7 @@ static int i915_drrs_ctl_set(void *data, u64 val)
> > crtc_state = to_intel_crtc_state(crtc->base.state);
> >  
> > if (!crtc_state->hw.active ||
> > -   !crtc_state->has_drrs)
> > +   !CRTC_STATE_HAS_DRRS(crtc_state))
> > goto out;
> >  
> > commit = crtc_state->uapi.commit;
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index cfd042117b109..f0b3cfd3138ce 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1056,7 +1056,7 @@ struct intel_crtc_state {
> >  
> > /* m2_n2 for eDP downclock */
> > struct intel_link_m_n dp_m2_n2;
> > -   bool has_drrs;
> > +   const struct drm_display_mode *drrs_downclock_mode;
> >  
> > /* PSR is supported but might not be enabled due the lack of enabled 
> > planes */
> > bool has_psr;
> > @@ -1264,6 +1264,8 @@ enum drrs_refresh_rate {
> > DRRS_REFRESH_RATE_LOW,
> >  };
> >  
> > +#define CRTC_STATE_HAS_DRRS(crtc_state) 
> > (!!((crtc_state)->drrs_downclock_mode))
> > +
> >  #define INTEL_PIPE_CRC_ENTRIES_NR  128
> >  struct intel_pipe_crc {
> > spinlock_t lock;
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index d55acc4a028a8..feea172dd2753 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -1881,7 +1881,7 @@ intel_dp_drrs_compute_config(struct intel_connector 
> > *connector,
> 

Re: [Intel-gfx] [PATCH 1/3] drm: Add infrastructure to allow seamless mode switches

[Ville Syrjälä]

On Thu, Apr 21, 2022 at 12:22:03PM -0700, José Roberto de Souza wrote:
> Intel hardware supports change between modes with different refresh
> rates without any glitches or visual artifacts, that feature is called
> seamless DRRS.
> 
> So far i915 driver was automatically changing between preferred panel
> mode and lower refresh rate mode based on idleness but ChromeOS
> compositor team is requesting to be in control of the mode switch.
> So for a certain types of content it can switch to mode with a lower
> refresh rate without user noticing a thing and saving power.
> 
> This seamless mode switch will be triggered when user-space dispatch
> a atomic commit with the new mode and clears the
> DRM_MODE_ATOMIC_ALLOW_MODESET flag.
> 
> A driver that don't implement atomic_seamless_mode_switch_check
> function will continue to fail in the atomic check phase with
> "[CRTC:%d:%s] requires full modeset" debug message.
> While a driver that implements it and support the seamless change
> between old and new mode will return 0 otherwise it should return the
> appropried errno.
> 
> So here adding basic drm infrastructure to that be supported by i915
> and other drivers.

I don't see the need for any extra infrastructure for this.

I think we just need:
- fix the fastset code to not suck
- reprogram M/N during fastset
- calculate eDP link params using panel's highest refresh rate mode
  to make sure we get the same link params for all refresh rates

> 
> Cc: Vidya Srinivas 
> Cc: Sean Paul 
> Cc: Ville Syrjälä 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/drm_atomic.c  |  1 +
>  drivers/gpu/drm/drm_atomic_helper.c   | 16 +++
>  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
>  include/drm/drm_crtc.h| 25 +++
>  4 files changed, 43 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 58c0283fb6b0c..21525f9f4b4c1 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -437,6 +437,7 @@ static void drm_atomic_crtc_print_state(struct 
> drm_printer *p,
>   drm_printf(p, "\tself_refresh_active=%d\n", state->self_refresh_active);
>   drm_printf(p, "\tplanes_changed=%d\n", state->planes_changed);
>   drm_printf(p, "\tmode_changed=%d\n", state->mode_changed);
> + drm_printf(p, "\tseamless_mode_changed=%d\n", 
> state->seamless_mode_changed);
>   drm_printf(p, "\tactive_changed=%d\n", state->active_changed);
>   drm_printf(p, "\tconnectors_changed=%d\n", state->connectors_changed);
>   drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 9603193d2fa13..e6f3a966f7b86 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -631,6 +631,22 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>   drm_dbg_atomic(dev, "[CRTC:%d:%s] mode changed\n",
>  crtc->base.id, crtc->name);
>   new_crtc_state->mode_changed = true;
> +
> + if (!state->allow_modeset &&
> + crtc->funcs->atomic_seamless_mode_switch_check) {
> + ret = 
> crtc->funcs->atomic_seamless_mode_switch_check(state, crtc);
> + if (ret == -EOPNOTSUPP) {
> + drm_dbg_atomic(dev, "[CRTC:%d:%s] 
> Seamless mode switch not supported\n",
> +crtc->base.id, 
> crtc->name);
> + return ret;
> + }
> +
> + if (ret < 0)
> + return ret;
> +
> + new_crtc_state->seamless_mode_changed = true;
> + new_crtc_state->mode_changed = false;
> + }
>   }
>  
>   if (old_crtc_state->enable != new_crtc_state->enable) {
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 3b6d3bdbd0996..c093073ea6e11 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -142,6 +142,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct 
> drm_crtc *crtc,
>   if (state->gamma_lut)
>   drm_property_blob_get(state->gamma_lut);
>   state->mode_changed = false;
> + state->seamless_mode_changed = false;
>   state->active_changed = false;
>   state->planes_changed = false;
>   state->connectors_changed = false;
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index a70baea0636ca..b7ce378d679d3 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -140,6 +140,16 @@ struct drm_crtc_state {
>*/
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use the memcpy_from_wc function from drm (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Use the memcpy_from_wc function from drm (rev4)
URL   : https://patchwork.freedesktop.org/series/100581/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11550 -> Patchwork_100581v4


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 45)
--

  Additional (3): bat-dg2-8 fi-kbl-x1275 bat-dg1-6 
  Missing(1): fi-bsw-cyan 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@client:
- {bat-rpls-1}:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-1/igt@i915_selftest@l...@client.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/bat-rpls-1/igt@i915_selftest@l...@client.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- {bat-dg2-8}:NOTRUN -> [SKIP][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/bat-dg2-8/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6:  NOTRUN -> [INCOMPLETE][4] ([i915#5827])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u:   [PASS][5] -> [INCOMPLETE][6] ([i915#146])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-x1275:   NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/fi-kbl-x1275/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@verify-random:
- fi-kbl-x1275:   NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/fi-kbl-x1275/igt@gem_lmem_swapp...@verify-random.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-kbl-x1275:   NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/fi-kbl-x1275/igt@kms_chamel...@hdmi-crc-fast.html

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

  * igt@kms_psr@primary_page_flip:
- fi-kbl-x1275:   NOTRUN -> [SKIP][11] ([fdo#109271]) +12 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/fi-kbl-x1275/igt@kms_psr@primary_page_flip.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-guc: [DMESG-FAIL][12] ([i915#5334]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html

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

  * igt@i915_selftest@live@hugepages:
- {bat-rpls-1}:   [DMESG-WARN][16] ([i915#5278]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-1/igt@i915_selftest@l...@hugepages.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/bat-rpls-1/igt@i915_selftest@l...@hugepages.html

  * igt@kms_busy@basic@modeset:
- {bat-adlp-6}:   [DMESG-WARN][18] ([i915#3576]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-adlp-6/igt@kms_busy@ba...@modeset.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100581v4/bat-adlp-6/igt@kms_busy@ba...@modeset.html

  
 Warnings 

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-7567u:   [SKIP][20] ([fdo#109271] / [i915#5341]) -> [SKIP][21] 
([fdo#109271])
   [20]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/rc6: Access RC6 CTRL regs with forcewake

[Patchwork]

== Series Details ==

Series: drm/i915/rc6: Access RC6 CTRL regs with forcewake
URL   : https://patchwork.freedesktop.org/series/103156/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103156v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 43)
--

  Additional (2): fi-kbl-x1275 bat-dg1-6 
  Missing(2): fi-hsw-4770 fi-bsw-cyan 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6:  NOTRUN -> [INCOMPLETE][1] ([i915#5827])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u:   [PASS][2] -> [INCOMPLETE][3] ([i915#146])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-x1275:   NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/fi-kbl-x1275/igt@gem_huc_c...@huc-copy.html
- fi-rkl-11600:   NOTRUN -> [SKIP][5] ([i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@verify-random:
- fi-kbl-x1275:   NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/fi-kbl-x1275/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([i915#3282])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][9] ([i915#3012])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([fdo#111827]) +8 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/fi-rkl-11600/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-kbl-x1275:   NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/fi-kbl-x1275/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([i915#4070] / [i915#4103]) +1 
similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][13] ([fdo#109285] / [i915#4098])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([i915#4070] / [i915#533])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-kbl-x1275:   NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#533])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/fi-kbl-x1275/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([i915#1072]) +3 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/fi-rkl-11600/igt@kms_psr@primary_mmap_gtt.html

  * igt@kms_psr@primary_page_flip:
- fi-kbl-x1275:   NOTRUN -> [SKIP][17] ([fdo#109271]) +12 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/fi-kbl-x1275/igt@kms_psr@primary_page_flip.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][18] ([i915#3555] / [i915#4098])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103156v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][19] ([i915#3301] / [i915#3708])
   

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for i915: Upstream initial DG2 PCI IDs

[Matt Roper]

On Tue, Apr 26, 2022 at 12:17:24AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: i915: Upstream initial DG2 PCI IDs
> URL   : https://patchwork.freedesktop.org/series/103098/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103098v1_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_103098v1_full absolutely need 
> to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_103098v1_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 -> 13)
> --
> 
>   Additional (3): shard-rkl shard-dg1 shard-tglu 
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_103098v1_full:
> 
> ### CI changes ###
> 
>  Suppressed 
> 
>   The following results come from untrusted machines, tests, or statuses.
>   They do not affect the overall result.
> 
>   * boot:
> - {shard-rkl}:NOTRUN -> ([PASS][1], [PASS][2], [PASS][3], 
> [PASS][4], [PASS][5], [PASS][6], [PASS][7], [FAIL][8], [PASS][9], [PASS][10], 
> [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], 
> [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21])
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-6/boot.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-3/boot.html
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-3/boot.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-4/boot.html
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-5/boot.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-5/boot.html

THere doesn't seem to be a log output for the failure.  But updating DG2
device IDs shouldn't have any impact on RKL.

>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-5/boot.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-6/boot.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-6/boot.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
>[19]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
>[20]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
>[21]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
> 
>   
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@kms_vblank@pipe-d-wait-idle-hang:
> - shard-tglb: [PASS][22] -> [INCOMPLETE][23]
>[22]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-tglb6/igt@kms_vbl...@pipe-d-wait-idle-hang.html
>[23]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-tglb3/igt@kms_vbl...@pipe-d-wait-idle-hang.html

GPF outside of i915:

<4> [358.240067] general protection fault, probably for non-canonical address 
0x380015ffd0003c:  [#1] PREEMPT SMP NOPTI
<4> [358.240074] CPU: 0 PID: 175 Comm: kworker/0:1H Tainted: G U
5.18.0-rc4-Patchwork_103098v1-g56b089ae03ef+ #1
<4> [358.240076] Hardware name: Intel Corporation Tiger Lake Client 
Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.3197.A00.2005110542 
05/11/2020
<4> [358.240078] Workqueue: acpi_thermal_pm acpi_thermal_check_fn
<4> [358.240086] RIP: 0010:acpi_ns_search_one_scope+0xb/0x39
<4> [358.240091] Code: 8b 48 08 4d 85 c9 74 0e 41 8b 10 39 56 0c 74 07 49 83 c0 
10 eb e9 c3 48 89 ce 41 ff e1 66 90 55 53 48 8b 5e 18 48 85 db 74 26 <39> 7b 0c 
75 1b 48 89 df 48 89 cd e8 83 02 00 00 83 f8 16 75 03 48
<4> [358.240093] RSP: 0018:c938fa08 EFLAGS: 00010206
<4> [358.240095] RAX:  RBX: 00380015ffd00030 RCX: 
c938fab0
<4> 

Re: [Intel-gfx] [PULL] gvt-next

[Wang, Zhi A]

On 4/26/22 3:53 PM, Jason Gunthorpe wrote:
> On Tue, Apr 26, 2022 at 07:58:59AM +, Wang, Zhi A wrote:
>> Hi folks:
>>
>> Here is the pull of gvt-next which fixs the compilation error when i915 debug
>> is open after the GVT-g refactor patches.
>>
>> Thanks so much for the efforts.
>>
>> Thanks,
>> Zhi.
>>
>> The following changes since commit 2917f53113be3b7a0f374e02cebe6d6b749366b5:
>>
>>   vfio/mdev: Remove mdev drvdata (2022-04-21 07:36:56 -0400)
>>
>> are available in the Git repository at:
>>
>>   https://github.com/intel/gvt-linux tags/gvt-next-2022-04-26
>>
>> for you to fetch changes up to 2da299cee780ea797b3f72558687868072cf5eb5:
>>
>>   drm/i915/gvt: Add missing export of symbols. (2022-04-25 18:03:04 -0400)
>>
>> gvt-next-2022-04-26
>>
>> - Add two missing exports of symbols when i915 debug is enabled.
>>
>> Zhi Wang (1):
>>   drm/i915/gvt: Add missing export of symbols.
>>
>>  drivers/gpu/drm/i915/intel_gvt.c | 2 ++
>>  1 file changed, 2 insertions(+)
> 
> This still has another compile problem:
> 
> ERROR: modpost: "intel_runtime_pm_put" [vmlinux] is a static EXPORT_SYMBOL_GPL
> 
> Because:
> 
> #if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> void intel_runtime_pm_put(struct intel_runtime_pm *rpm, intel_wakeref_t wref);
> #else
> static inline void
> intel_runtime_pm_put(struct intel_runtime_pm *rpm, intel_wakeref_t wref)
> {
> intel_runtime_pm_put_unchecked(rpm);
> }
> #endif
> 
> Looks like it happens if CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n
> 
> I think you probably want to #ifdef the export in the same way:
> 
> --- a/drivers/gpu/drm/i915/intel_gvt.c
> +++ b/drivers/gpu/drm/i915/intel_gvt.c
> @@ -309,7 +309,9 @@ EXPORT_SYMBOL_NS_GPL(__intel_context_do_pin, I915_GVT);
>  EXPORT_SYMBOL_NS_GPL(__intel_context_do_unpin, I915_GVT);
>  EXPORT_SYMBOL_NS_GPL(intel_ring_begin, I915_GVT);
>  EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_get, I915_GVT);
> +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
>  EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_put, I915_GVT);
> +#endif
Sigh. That's tricky. Let me prepare another one. 
>  EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_put_unchecked, I915_GVT);
>  EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_for_reg, I915_GVT);
>  EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_get, I915_GVT);
> 
> Jason
> 

Re: [Intel-gfx] [PATCH 1/3] drm: Add infrastructure to allow seamless mode switches

[Srinivas, Vidya]

Hello Jose,

Thanks much for the patch. I tested it on chrome system and the patch works.
Adding my Tested-by.
Tested-by: Vidya Srinivas 

Regards
Vidya

> -Original Message-
> From: Souza, Jose 
> Sent: Friday, April 22, 2022 12:52 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Srinivas, Vidya ; Sean Paul
> ; Ville Syrjälä ;
> Souza, Jose 
> Subject: [PATCH 1/3] drm: Add infrastructure to allow seamless mode
> switches
> 
> Intel hardware supports change between modes with different refresh rates
> without any glitches or visual artifacts, that feature is called seamless 
> DRRS.
> 
> So far i915 driver was automatically changing between preferred panel mode
> and lower refresh rate mode based on idleness but ChromeOS compositor
> team is requesting to be in control of the mode switch.
> So for a certain types of content it can switch to mode with a lower refresh
> rate without user noticing a thing and saving power.
> 
> This seamless mode switch will be triggered when user-space dispatch a
> atomic commit with the new mode and clears the
> DRM_MODE_ATOMIC_ALLOW_MODESET flag.
> 
> A driver that don't implement atomic_seamless_mode_switch_check
> function will continue to fail in the atomic check phase with "[CRTC:%d:%s]
> requires full modeset" debug message.
> While a driver that implements it and support the seamless change between
> old and new mode will return 0 otherwise it should return the appropried
> errno.
> 
> So here adding basic drm infrastructure to that be supported by i915 and
> other drivers.
> 
> Cc: Vidya Srinivas 
> Cc: Sean Paul 
> Cc: Ville Syrjälä 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/drm_atomic.c  |  1 +
>  drivers/gpu/drm/drm_atomic_helper.c   | 16 +++
>  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
>  include/drm/drm_crtc.h| 25 +++
>  4 files changed, 43 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 58c0283fb6b0c..21525f9f4b4c1 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -437,6 +437,7 @@ static void drm_atomic_crtc_print_state(struct
> drm_printer *p,
>   drm_printf(p, "\tself_refresh_active=%d\n", state-
> >self_refresh_active);
>   drm_printf(p, "\tplanes_changed=%d\n", state->planes_changed);
>   drm_printf(p, "\tmode_changed=%d\n", state->mode_changed);
> + drm_printf(p, "\tseamless_mode_changed=%d\n",
> +state->seamless_mode_changed);
>   drm_printf(p, "\tactive_changed=%d\n", state->active_changed);
>   drm_printf(p, "\tconnectors_changed=%d\n", state-
> >connectors_changed);
>   drm_printf(p, "\tcolor_mgmt_changed=%d\n", state-
> >color_mgmt_changed); diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 9603193d2fa13..e6f3a966f7b86 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -631,6 +631,22 @@ drm_atomic_helper_check_modeset(struct
> drm_device *dev,
>   drm_dbg_atomic(dev, "[CRTC:%d:%s] mode
> changed\n",
>  crtc->base.id, crtc->name);
>   new_crtc_state->mode_changed = true;
> +
> + if (!state->allow_modeset &&
> + crtc->funcs-
> >atomic_seamless_mode_switch_check) {
> + ret = crtc->funcs-
> >atomic_seamless_mode_switch_check(state, crtc);
> + if (ret == -EOPNOTSUPP) {
> + drm_dbg_atomic(dev, "[CRTC:%d:%s]
> Seamless mode switch not supported\n",
> +crtc->base.id, crtc-
> >name);
> + return ret;
> + }
> +
> + if (ret < 0)
> + return ret;
> +
> + new_crtc_state->seamless_mode_changed =
> true;
> + new_crtc_state->mode_changed = false;
> + }
>   }
> 
>   if (old_crtc_state->enable != new_crtc_state->enable) { diff --
> git a/drivers/gpu/drm/drm_atomic_state_helper.c
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 3b6d3bdbd0996..c093073ea6e11 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -142,6 +142,7 @@ void
> __drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc,
>   if (state->gamma_lut)
>   drm_property_blob_get(state->gamma_lut);
>   state->mode_changed = false;
> + state->seamless_mode_changed = false;
>   state->active_changed = false;
>   state->planes_changed = false;
>   state->connectors_changed = false;
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index
> a70baea0636ca..b7ce378d679d3 

[Intel-gfx] [PATCH v3 7/7] drm/i915: Avoid dereferencing io mapped memory

[Balasubramani Vivekanandan]

Pointer passed to zlib_deflate() for compression could point to io
mapped memory and might end up in direct derefencing.
io mapped memory is copied to a temporary buffer, which is then shared
to zlib_deflate(), only for the case where platform supports fast copy
using non-temporal instructions. If the platform lacks support,
then io mapped memory is directly used.

Direct dereferencing of io memory makes driver not portable outside
x86 and should be avoided.

With this patch, io memory is always copied to a temporary buffer
irrespective of platform support for fast copy. The
i915_has_memcpy_from_wc() check is removed. And
drm_memcpy_from_wc_vaddr() is now used for copying instead of
i915_memcpy_from_wc() for 2 reasons.
- i915_memcpy_from_wc() will be deprecated.
- drm_memcpy_from_wc_vaddr() will not fail if the fast copy is not
supported instead continues copying using memcpy_fromio as fallback.

Signed-off-by: Balasubramani Vivekanandan 
Acked-by: Nirmoy Das 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 45 +++
 1 file changed, 25 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 0512c66fa4f3..9cafacb4ceb6 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -262,9 +262,12 @@ static bool compress_init(struct i915_vma_compress *c)
return false;
}
 
-   c->tmp = NULL;
-   if (i915_has_memcpy_from_wc())
-   c->tmp = pool_alloc(>pool, ALLOW_FAIL);
+   c->tmp = pool_alloc(>pool, ALLOW_FAIL);
+   if (!c->tmp) {
+   kfree(zstream->workspace);
+   pool_fini(>pool);
+   return false;
+   }
 
return true;
 }
@@ -296,15 +299,17 @@ static void *compress_next_page(struct i915_vma_compress 
*c,
 }
 
 static int compress_page(struct i915_vma_compress *c,
-void *src,
-struct i915_vma_coredump *dst,
-bool wc)
+struct iosys_map *src,
+struct i915_vma_coredump *dst)
 {
struct z_stream_s *zstream = >zstream;
 
-   zstream->next_in = src;
-   if (wc && c->tmp && i915_memcpy_from_wc(c->tmp, src, PAGE_SIZE))
+   if (src->is_iomem) {
+   drm_memcpy_from_wc_vaddr(c->tmp, src, 0, PAGE_SIZE);
zstream->next_in = c->tmp;
+   } else {
+   zstream->next_in = src->vaddr;
+   }
zstream->avail_in = PAGE_SIZE;
 
do {
@@ -393,9 +398,8 @@ static bool compress_start(struct i915_vma_compress *c)
 }
 
 static int compress_page(struct i915_vma_compress *c,
-void *src,
-struct i915_vma_coredump *dst,
-bool wc)
+struct iosys_map *src,
+struct i915_vma_coredump *dst)
 {
void *ptr;
 
@@ -403,8 +407,7 @@ static int compress_page(struct i915_vma_compress *c,
if (!ptr)
return -ENOMEM;
 
-   if (!(wc && i915_memcpy_from_wc(ptr, src, PAGE_SIZE)))
-   memcpy(ptr, src, PAGE_SIZE);
+   drm_memcpy_from_wc_vaddr(ptr, src, 0, PAGE_SIZE);
list_add_tail(_to_page(ptr)->lru, >page_list);
cond_resched();
 
@@ -1092,6 +1095,7 @@ i915_vma_coredump_create(const struct intel_gt *gt,
if (drm_mm_node_allocated(>error_capture)) {
void __iomem *s;
dma_addr_t dma;
+   struct iosys_map src;
 
for_each_sgt_daddr(dma, iter, vma_res->bi.pages) {
mutex_lock(>error_mutex);
@@ -1100,9 +1104,8 @@ i915_vma_coredump_create(const struct intel_gt *gt,
mb();
 
s = io_mapping_map_wc(>iomap, slot, PAGE_SIZE);
-   ret = compress_page(compress,
-   (void  __force *)s, dst,
-   true);
+   iosys_map_set_vaddr_iomem(, s);
+   ret = compress_page(compress, , dst);
io_mapping_unmap(s);
 
mb();
@@ -1114,6 +1117,7 @@ i915_vma_coredump_create(const struct intel_gt *gt,
} else if (vma_res->bi.lmem) {
struct intel_memory_region *mem = vma_res->mr;
dma_addr_t dma;
+   struct iosys_map src;
 
for_each_sgt_daddr(dma, iter, vma_res->bi.pages) {
void __iomem *s;
@@ -1121,15 +1125,15 @@ i915_vma_coredump_create(const struct intel_gt *gt,
s = io_mapping_map_wc(>iomap,
  dma - mem->region.start,
  PAGE_SIZE);
-   ret = compress_page(compress,
-   (void __force *)s, dst,
- 

[Intel-gfx] [PATCH v3 3/7] drm/i915: use the memcpy_from_wc call from the drm

[Balasubramani Vivekanandan]

memcpy_from_wc functions in i915_memcpy.c will be removed and replaced
by the implementation in drm_cache.c.
Updated to use the functions provided by drm_cache.c.

v2: Pass newly added src offset argument to the modified
drm_memcpy_from_wc_vaddr() function.

Signed-off-by: Balasubramani Vivekanandan 
Reviewed-by: Lucas De Marchi 
Reviewed-by: Nirmoy Das 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 06b1b188ce5a..c1ff0a591a24 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -438,16 +438,16 @@ static void
 i915_gem_object_read_from_page_iomap(struct drm_i915_gem_object *obj, u64 
offset, void *dst, int size)
 {
void __iomem *src_map;
-   void __iomem *src_ptr;
+   struct iosys_map src;
+
dma_addr_t dma = i915_gem_object_get_dma_address(obj, offset >> 
PAGE_SHIFT);
 
src_map = io_mapping_map_wc(>mm.region->iomap,
dma - obj->mm.region->region.start,
PAGE_SIZE);
 
-   src_ptr = src_map + offset_in_page(offset);
-   if (!i915_memcpy_from_wc(dst, (void __force *)src_ptr, size))
-   memcpy_fromio(dst, src_ptr, size);
+   iosys_map_set_vaddr_iomem(, src_map);
+   drm_memcpy_from_wc_vaddr(dst, , offset_in_page(offset), size);
 
io_mapping_unmap(src_map);
 }
-- 
2.25.1

[Intel-gfx] [PATCH v3 5/7] drm/i915/selftests: use the memcpy_from_wc call from the drm

[Balasubramani Vivekanandan]

memcpy_from_wc functions in i915_memcpy.c will be removed and replaced
by the implementation in drm_cache.c.
Updated to use the functions provided by drm_cache.c.

v2: check if the source and destination memory address is from local
memory or system memory and initialize the iosys_map accordingly
(Lucas)

Cc: Lucas De Marchi 
Cc: Matthew Auld 
Cc: Thomas Hellstr_m 
Cc: Thomas Zimmermann 
Cc: Daniel Vetter 

Signed-off-by: Balasubramani Vivekanandan 
Acked-by: Nirmoy Das 
---
 .../drm/i915/selftests/intel_memory_region.c  | 41 +--
 1 file changed, 28 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c 
b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
index 73eb53edb8de..420210c20ad5 100644
--- a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
@@ -7,6 +7,7 @@
 #include 
 
 #include 
+#include 
 
 #include "../i915_selftest.h"
 
@@ -1141,7 +1142,7 @@ static const char *repr_type(u32 type)
 
 static struct drm_i915_gem_object *
 create_region_for_mapping(struct intel_memory_region *mr, u64 size, u32 type,
- void **out_addr)
+ struct iosys_map *out_addr)
 {
struct drm_i915_gem_object *obj;
void *addr;
@@ -1161,7 +1162,11 @@ create_region_for_mapping(struct intel_memory_region 
*mr, u64 size, u32 type,
return addr;
}
 
-   *out_addr = addr;
+   if (i915_gem_object_is_lmem(obj))
+   iosys_map_set_vaddr_iomem(out_addr, (void __iomem *)addr);
+   else
+   iosys_map_set_vaddr(out_addr, addr);
+
return obj;
 }
 
@@ -1172,24 +1177,33 @@ static int wrap_ktime_compare(const void *A, const void 
*B)
return ktime_compare(*a, *b);
 }
 
-static void igt_memcpy_long(void *dst, const void *src, size_t size)
+static void igt_memcpy_long(struct iosys_map *dst, struct iosys_map *src,
+   size_t size)
 {
-   unsigned long *tmp = dst;
-   const unsigned long *s = src;
+   unsigned long *tmp = dst->is_iomem ?
+   (unsigned long __force *)dst->vaddr_iomem :
+   dst->vaddr;
+   const unsigned long *s = src->is_iomem ?
+   (unsigned long __force *)src->vaddr_iomem :
+   src->vaddr;
 
size = size / sizeof(unsigned long);
while (size--)
*tmp++ = *s++;
 }
 
-static inline void igt_memcpy(void *dst, const void *src, size_t size)
+static inline void igt_memcpy(struct iosys_map *dst, struct iosys_map *src,
+ size_t size)
 {
-   memcpy(dst, src, size);
+   memcpy(dst->is_iomem ? (void __force *)dst->vaddr_iomem : dst->vaddr,
+  src->is_iomem ? (void __force *)src->vaddr_iomem : src->vaddr,
+  size);
 }
 
-static inline void igt_memcpy_from_wc(void *dst, const void *src, size_t size)
+static inline void igt_memcpy_from_wc(struct iosys_map *dst, struct iosys_map 
*src,
+ size_t size)
 {
-   i915_memcpy_from_wc(dst, src, size);
+   drm_memcpy_from_wc(dst, src, size);
 }
 
 static int _perf_memcpy(struct intel_memory_region *src_mr,
@@ -1199,7 +1213,8 @@ static int _perf_memcpy(struct intel_memory_region 
*src_mr,
struct drm_i915_private *i915 = src_mr->i915;
const struct {
const char *name;
-   void (*copy)(void *dst, const void *src, size_t size);
+   void (*copy)(struct iosys_map *dst, struct iosys_map *src,
+size_t size);
bool skip;
} tests[] = {
{
@@ -1213,11 +1228,11 @@ static int _perf_memcpy(struct intel_memory_region 
*src_mr,
{
"memcpy_from_wc",
igt_memcpy_from_wc,
-   !i915_has_memcpy_from_wc(),
+   !drm_memcpy_fastcopy_supported(),
},
};
struct drm_i915_gem_object *src, *dst;
-   void *src_addr, *dst_addr;
+   struct iosys_map src_addr, dst_addr;
int ret = 0;
int i;
 
@@ -1245,7 +1260,7 @@ static int _perf_memcpy(struct intel_memory_region 
*src_mr,
 
t0 = ktime_get();
 
-   tests[i].copy(dst_addr, src_addr, size);
+   tests[i].copy(_addr, _addr, size);
 
t1 = ktime_get();
t[pass] = ktime_sub(t1, t0);
-- 
2.25.1

[Intel-gfx] [PATCH v3 6/7] drm/i915/gt: Avoid direct dereferencing of io memory

[Balasubramani Vivekanandan]

io mapped memory should not be directly dereferenced to ensure
portability. io memory should be read/written/copied using helper
functions.
i915_memcpy_from_wc() function was used to copy the data from io memory to
a temporary buffer and pointer to the temporary buffer was passed to CRC
calculation function.
But i915_memcpy_from_wc() only does a copy if the platform supports fast
copy using non-temporal instructions. Otherwise the pointer to io memory
was passed for CRC calculation. CRC function will directly dereference
io memory and would not work properly on non-x86 platforms.
To make it portable, it should be ensured always temporary buffer is
used for CRC and not io memory.
drm_memcpy_from_wc_vaddr() is now used for copying instead of
i915_memcpy_from_wc() for 2 reasons.
- i915_memcpy_from_wc() will be deprecated.
- drm_memcpy_from_wc_vaddr() will not fail if the fast copy is not
supported but uses memcpy_fromio as fallback for copying.

Cc: Matthew Brost 
Cc: Michał Winiarski 

Signed-off-by: Balasubramani Vivekanandan 
Acked-by: Nirmoy Das 
---
 drivers/gpu/drm/i915/gt/selftest_reset.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_reset.c 
b/drivers/gpu/drm/i915/gt/selftest_reset.c
index 37c38bdd5f47..7a455583c687 100644
--- a/drivers/gpu/drm/i915/gt/selftest_reset.c
+++ b/drivers/gpu/drm/i915/gt/selftest_reset.c
@@ -3,6 +3,7 @@
  * Copyright © 2018 Intel Corporation
  */
 
+#include 
 #include 
 
 #include "gem/i915_gem_stolen.h"
@@ -82,7 +83,7 @@ __igt_reset_stolen(struct intel_gt *gt,
for (page = 0; page < num_pages; page++) {
dma_addr_t dma = (dma_addr_t)dsm->start + (page << PAGE_SHIFT);
void __iomem *s;
-   void *in;
+   struct iosys_map src_map;
 
ggtt->vm.insert_page(>vm, dma,
 ggtt->error_capture.start,
@@ -98,10 +99,9 @@ __igt_reset_stolen(struct intel_gt *gt,
 ((page + 1) << PAGE_SHIFT) - 1))
memset_io(s, STACK_MAGIC, PAGE_SIZE);
 
-   in = (void __force *)s;
-   if (i915_memcpy_from_wc(tmp, in, PAGE_SIZE))
-   in = tmp;
-   crc[page] = crc32_le(0, in, PAGE_SIZE);
+   iosys_map_set_vaddr_iomem(_map, s);
+   drm_memcpy_from_wc_vaddr(tmp, _map, 0, PAGE_SIZE);
+   crc[page] = crc32_le(0, tmp, PAGE_SIZE);
 
io_mapping_unmap(s);
}
@@ -122,7 +122,7 @@ __igt_reset_stolen(struct intel_gt *gt,
for (page = 0; page < num_pages; page++) {
dma_addr_t dma = (dma_addr_t)dsm->start + (page << PAGE_SHIFT);
void __iomem *s;
-   void *in;
+   struct iosys_map src_map;
u32 x;
 
ggtt->vm.insert_page(>vm, dma,
@@ -134,10 +134,9 @@ __igt_reset_stolen(struct intel_gt *gt,
  ggtt->error_capture.start,
  PAGE_SIZE);
 
-   in = (void __force *)s;
-   if (i915_memcpy_from_wc(tmp, in, PAGE_SIZE))
-   in = tmp;
-   x = crc32_le(0, in, PAGE_SIZE);
+   iosys_map_set_vaddr_iomem(_map, s);
+   drm_memcpy_from_wc_vaddr(tmp, _map, 0, PAGE_SIZE);
+   x = crc32_le(0, tmp, PAGE_SIZE);
 
if (x != crc[page] &&
!__drm_mm_interval_first(>i915->mm.stolen,
@@ -146,7 +145,7 @@ __igt_reset_stolen(struct intel_gt *gt,
pr_debug("unused stolen page %pa modified by GPU 
reset\n",
 );
if (count++ == 0)
-   igt_hexdump(in, PAGE_SIZE);
+   igt_hexdump(tmp, PAGE_SIZE);
max = page;
}
 
-- 
2.25.1

[Intel-gfx] [PATCH v3 4/7] drm/i915/guc: use iosys_map abstraction to access GuC log

[Balasubramani Vivekanandan]

Pointer to the GuC log may be pointing to system memory or device memory
based on if the GuC log is backed by system memory or GPU local memory.
If the GuC log is on the local memory, we need to use memcpy_[from/to]io
APIs to access the logs to support i915 on non-x86 architectures.
iosys_map family of APIs provide the needed abstraction to access such
address pointers. There is parallel work ongoing to move all such memory
access in i915 to iosys_map APIs. Pointer to GuC log ported to iosys_map
in this patch as it provides a good base when changing to
drm_memcpy_from_wc.

Cc: Lucas De Marchi 
Cc: Daniele Ceraolo Spurio 

Signed-off-by: Balasubramani Vivekanandan 
---
 drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h |  2 +-
 .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 52 +
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 77 ++-
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.h|  3 +-
 4 files changed, 98 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
index 3624abfd22d1..47bed2a0c409 100644
--- a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
@@ -21,7 +21,7 @@ struct file;
  */
 struct __guc_capture_bufstate {
u32 size;
-   void *data;
+   struct iosys_map *data_map;
u32 rd;
u32 wr;
 };
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 c4e25966d3e9..c4f7a28956b8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -5,6 +5,7 @@
 
 #include 
 
+#include 
 #include 
 
 #include "gt/intel_engine_regs.h"
@@ -826,7 +827,6 @@ guc_capture_log_remove_dw(struct intel_guc *guc, struct 
__guc_capture_bufstate *
struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
int tries = 2;
int avail = 0;
-   u32 *src_data;
 
if (!guc_capture_buf_cnt(buf))
return 0;
@@ -834,8 +834,7 @@ guc_capture_log_remove_dw(struct intel_guc *guc, struct 
__guc_capture_bufstate *
while (tries--) {
avail = guc_capture_buf_cnt_to_end(buf);
if (avail >= sizeof(u32)) {
-   src_data = (u32 *)(buf->data + buf->rd);
-   *dw = *src_data;
+   *dw = iosys_map_rd(buf->data_map, buf->rd, u32);
buf->rd += 4;
return 4;
}
@@ -852,7 +851,7 @@ guc_capture_data_extracted(struct __guc_capture_bufstate *b,
   int size, void *dest)
 {
if (guc_capture_buf_cnt_to_end(b) >= size) {
-   memcpy(dest, (b->data + b->rd), size);
+   drm_memcpy_from_wc_vaddr(dest, b->data_map, b->rd, size);
b->rd += size;
return true;
}
@@ -1343,22 +1342,24 @@ static void __guc_capture_process_output(struct 
intel_guc *guc)
struct intel_uc *uc = container_of(guc, typeof(*uc), guc);
struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
struct guc_log_buffer_state log_buf_state_local;
-   struct guc_log_buffer_state *log_buf_state;
+   unsigned int capture_offset;
struct __guc_capture_bufstate buf;
-   void *src_data = NULL;
+   struct iosys_map src_map;
bool new_overflow;
int ret;
 
-   log_buf_state = guc->log.buf_addr +
-   (sizeof(struct guc_log_buffer_state) * 
GUC_CAPTURE_LOG_BUFFER);
-   src_data = guc->log.buf_addr + 
intel_guc_get_log_buffer_offset(GUC_CAPTURE_LOG_BUFFER);
+   src_map = IOSYS_MAP_INIT_OFFSET(>log.buf_map,
+   
intel_guc_get_log_buffer_offset(GUC_CAPTURE_LOG_BUFFER));
 
/*
 * Make a copy of the state structure, inside GuC log buffer
 * (which is uncached mapped), on the stack to avoid reading
 * from it multiple times.
 */
-   memcpy(_buf_state_local, log_buf_state, sizeof(struct 
guc_log_buffer_state));
+   capture_offset = sizeof(struct guc_log_buffer_state) * 
GUC_CAPTURE_LOG_BUFFER;
+   drm_memcpy_from_wc_vaddr(_buf_state_local, >log.buf_map,
+capture_offset,
+sizeof(struct guc_log_buffer_state));
buffer_size = intel_guc_get_log_buffer_size(GUC_CAPTURE_LOG_BUFFER);
read_offset = log_buf_state_local.read_ptr;
write_offset = log_buf_state_local.sampled_write_ptr;
@@ -1385,7 +1386,7 @@ static void __guc_capture_process_output(struct intel_guc 
*guc)
buf.size = buffer_size;
buf.rd = read_offset;
buf.wr = write_offset;
-   buf.data = src_data;
+   buf.data_map = _map;
 
if (!uc->reset_in_progress) {
do {
@@ -1394,8 +1395,33 @@ static void __guc_capture_process_output(struct 
intel_guc *guc)
}
 
/* 

[Intel-gfx] [PATCH v3 1/7] drm: Relax alignment constraint for destination address

[Balasubramani Vivekanandan]

There is no need for the destination address to be aligned to 16 byte
boundary to be able to use the non-temporal instructions while copying.
Non-temporal instructions are used only for loading from the source
address which has alignment constraints.
We only need to take care of using the right instructions, based on
whether destination address is aligned or not, while storing the data to
the destination address.

__memcpy_ntdqu is copied from i915/i915_memcpy.c

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Chris Wilson 

Signed-off-by: Balasubramani Vivekanandan 
Reviewed-by: Lucas De Marchi 
Reviewed-by: Nirmoy Das 
---
 drivers/gpu/drm/drm_cache.c | 44 -
 1 file changed, 38 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 7051c9c909c2..2e2545df3310 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -278,18 +278,50 @@ static void __memcpy_ntdqa(void *dst, const void *src, 
unsigned long len)
kernel_fpu_end();
 }
 
+static void __memcpy_ntdqu(void *dst, const void *src, unsigned long len)
+{
+   kernel_fpu_begin();
+
+   while (len >= 4) {
+   asm("movntdqa   (%0), %%xmm0\n"
+   "movntdqa 16(%0), %%xmm1\n"
+   "movntdqa 32(%0), %%xmm2\n"
+   "movntdqa 48(%0), %%xmm3\n"
+   "movups %%xmm0,   (%1)\n"
+   "movups %%xmm1, 16(%1)\n"
+   "movups %%xmm2, 32(%1)\n"
+   "movups %%xmm3, 48(%1)\n"
+   :: "r" (src), "r" (dst) : "memory");
+   src += 64;
+   dst += 64;
+   len -= 4;
+   }
+   while (len--) {
+   asm("movntdqa (%0), %%xmm0\n"
+   "movups %%xmm0, (%1)\n"
+   :: "r" (src), "r" (dst) : "memory");
+   src += 16;
+   dst += 16;
+   }
+
+   kernel_fpu_end();
+}
+
 /*
  * __drm_memcpy_from_wc copies @len bytes from @src to @dst using
- * non-temporal instructions where available. Note that all arguments
- * (@src, @dst) must be aligned to 16 bytes and @len must be a multiple
- * of 16.
+ * non-temporal instructions where available. Note that @src must be aligned to
+ * 16 bytes and @len must be a multiple of 16.
  */
 static void __drm_memcpy_from_wc(void *dst, const void *src, unsigned long len)
 {
-   if (unlikely(((unsigned long)dst | (unsigned long)src | len) & 15))
+   if (unlikely(((unsigned long)src | len) & 15)) {
memcpy(dst, src, len);
-   else if (likely(len))
-   __memcpy_ntdqa(dst, src, len >> 4);
+   } else if (likely(len)) {
+   if (IS_ALIGNED((unsigned long)dst, 16))
+   __memcpy_ntdqa(dst, src, len >> 4);
+   else
+   __memcpy_ntdqu(dst, src, len >> 4);
+   }
 }
 
 /**
-- 
2.25.1

[Intel-gfx] [PATCH v3 2/7] drm: Add drm_memcpy_from_wc() variant which accepts destination address

[Balasubramani Vivekanandan]

Fast copy using non-temporal instructions for x86 currently exists at two
locations. One is implemented in i915 driver at i915/i915_memcpy.c and
another copy at drm_cache.c. The plan is to remove the duplicate
implementation in i915 driver and use the functions from drm_cache.c.

A variant of drm_memcpy_from_wc() is added in drm_cache.c which accepts
address as argument instead of iosys_map for destination. It is a very
common scenario in i915 to copy from a WC memory type, which may be an
io memory or a system memory to a destination address pointing to system
memory. To avoid the overhead of creating iosys_map type for the
destination, new variant is created to accept the address directly.

Also a new function is exported in drm_cache.c to find if the fast copy
is supported by the platform or not. It is required for i915.

v2: Added a new argument to drm_memcpy_from_wc_vaddr() which provides
the offset into the src address to start copy from.

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Thomas Hellstr_m 

Signed-off-by: Balasubramani Vivekanandan 
Reviewed-by: Lucas De Marchi 
Reviewed-by: Nirmoy Das 
---
 drivers/gpu/drm/drm_cache.c | 55 +
 include/drm/drm_cache.h |  3 ++
 2 files changed, 58 insertions(+)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 2e2545df3310..8c7af755f7bc 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -358,6 +358,55 @@ void drm_memcpy_from_wc(struct iosys_map *dst,
 }
 EXPORT_SYMBOL(drm_memcpy_from_wc);
 
+/**
+ * drm_memcpy_from_wc_vaddr - Perform the fastest available memcpy from a 
source
+ * that may be WC to a destination in system memory.
+ * @dst: The destination pointer
+ * @src: The source pointer
+ * @src_offset: The offset from which to copy
+ * @len: The size of the area to transfer in bytes
+ *
+ * Same as drm_memcpy_from_wc except destination is accepted as system memory
+ * address. Useful in situations where passing destination address as iosys_map
+ * is simply an overhead and can be avoided.
+ */
+void drm_memcpy_from_wc_vaddr(void *dst, const struct iosys_map *src,
+ size_t src_offset, unsigned long len)
+{
+   const void *src_addr = src->is_iomem ?
+   (void const __force *)src->vaddr_iomem :
+   src->vaddr;
+
+   if (WARN_ON(in_interrupt())) {
+   iosys_map_memcpy_from(dst, src, src_offset, len);
+   return;
+   }
+
+   if (static_branch_likely(_movntdqa)) {
+   __drm_memcpy_from_wc(dst, src_addr + src_offset, len);
+   return;
+   }
+
+   iosys_map_memcpy_from(dst, src, src_offset, len);
+}
+EXPORT_SYMBOL(drm_memcpy_from_wc_vaddr);
+
+/*
+ * drm_memcpy_fastcopy_supported - Returns if fast copy using non-temporal
+ * instructions is supported
+ *
+ * Returns true if platform has support for fast copying from wc memory type
+ * using non-temporal instructions. Else false.
+ */
+bool drm_memcpy_fastcopy_supported(void)
+{
+   if (static_branch_likely(_movntdqa))
+   return true;
+
+   return false;
+}
+EXPORT_SYMBOL(drm_memcpy_fastcopy_supported);
+
 /*
  * drm_memcpy_init_early - One time initialization of the WC memcpy code
  */
@@ -382,6 +431,12 @@ void drm_memcpy_from_wc(struct iosys_map *dst,
 }
 EXPORT_SYMBOL(drm_memcpy_from_wc);
 
+bool drm_memcpy_fastcopy_supported(void)
+{
+   return false;
+}
+EXPORT_SYMBOL(drm_memcpy_fastcopy_supported);
+
 void drm_memcpy_init_early(void)
 {
 }
diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index 22deb216b59c..d1b57c84a659 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -77,4 +77,7 @@ void drm_memcpy_init_early(void);
 void drm_memcpy_from_wc(struct iosys_map *dst,
const struct iosys_map *src,
unsigned long len);
+bool drm_memcpy_fastcopy_supported(void);
+void drm_memcpy_from_wc_vaddr(void *dst, const struct iosys_map *src,
+ size_t src_offset, unsigned long len);
 #endif
-- 
2.25.1

[Intel-gfx] [PATCH v3 0/7] drm/i915: Use the memcpy_from_wc function from drm

[Balasubramani Vivekanandan]

drm_memcpy_from_wc() performs fast copy from WC memory type using
non-temporal instructions. Now there are two similar implementations of
this function. One exists in drm_cache.c as drm_memcpy_from_wc() and
another implementation in i915/i915_memcpy.c as i915_memcpy_from_wc().
drm_memcpy_from_wc() was the recent addition through the series
https://patchwork.freedesktop.org/patch/436276/?series=90681=6

The goal of this patch series is to change all users of
i915_memcpy_from_wc() to drm_memcpy_from_wc() and a have common
implementation in drm and eventually remove the copy from i915.

Another benefit of using memcpy functions from drm is that
drm_memcpy_from_wc() is available for non-x86 architectures.
i915_memcpy_from_wc() is implemented only for x86 and prevents building
i915 for ARM64.
drm_memcpy_from_wc() does fast copy using non-temporal instructions for
x86 and for other architectures makes use of memcpy() family of
functions as fallback.

Another major difference is unlike i915_memcpy_from_wc(),
drm_memcpy_from_wc() will not fail if the passed address argument is not
alignment to be used with non-temporal load instructions or if the
platform lacks support for those instructions (non-temporal load
instructions are provided through SSE4.1 instruction set extension).
Instead drm_memcpy_from_wc() continues with fallback functions to
complete the copy.
This relieves the caller from checking the return value of
i915_memcpy_from_wc() and explicitly using a fallback.

Follow up series will be created to remove the memcpy_from_wc functions
from i915 once the dependency is completely removed.

v2: Fixed missing check to find if the address is from system memory or
io memory and use the right initialization function to construct the
iosys_map structure (Review feedback from Lucas)

v3: "drm/i915/guc: use the memcpy_from_wc call from the drm" replaced by
patch "drm/i915/guc: use iosys_map abstraction to access GuC log".
New patch does a wider change compared to the old patch. It
completely changes the access to GuC log using iosys_map
abstraction, in addition to using drm_memcpy_from_wc.

Cc: Jani Nikula 
Cc: Lucas De Marchi 
Cc: David Airlie  
Cc: Daniel Vetter 
Cc: Chris Wilson 
Cc: Thomas Hellstr_m 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: Nirmoy Das 

Balasubramani Vivekanandan (7):
  drm: Relax alignment constraint for destination address
  drm: Add drm_memcpy_from_wc() variant which accepts destination
address
  drm/i915: use the memcpy_from_wc call from the drm
  drm/i915/guc: use iosys_map abstraction to access GuC log
  drm/i915/selftests: use the memcpy_from_wc call from the drm
  drm/i915/gt: Avoid direct dereferencing of io memory
  drm/i915: Avoid dereferencing io mapped memory

 drivers/gpu/drm/drm_cache.c   | 99 +--
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  8 +-
 drivers/gpu/drm/i915/gt/selftest_reset.c  | 21 ++--
 drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h |  2 +-
 .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 52 +++---
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 77 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.h|  3 +-
 drivers/gpu/drm/i915/i915_gpu_error.c | 45 +
 .../drm/i915/selftests/intel_memory_region.c  | 41 +---
 include/drm/drm_cache.h   |  3 +
 10 files changed, 261 insertions(+), 90 deletions(-)

-- 
2.25.1

[Intel-gfx] [PATCH] drm/i915/rc6: Access RC6 CTRL regs with forcewake

[Badal Nilawar]

Use forcewake to access RC6 CTRL regs

Signed-off-by: Badal Nilawar 
---
 drivers/gpu/drm/i915/gt/intel_rc6.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c 
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index b4770690e794..acc26b7d2562 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -635,7 +635,7 @@ void intel_rc6_unpark(struct intel_rc6 *rc6)
return;
 
/* Restore HW timers for automatic RC6 entry while busy */
-   set(uncore, GEN6_RC_CONTROL, rc6->ctl_enable);
+   intel_uncore_write(uncore, GEN6_RC_CONTROL, rc6->ctl_enable);
 }
 
 void intel_rc6_park(struct intel_rc6 *rc6)
@@ -655,7 +655,7 @@ void intel_rc6_park(struct intel_rc6 *rc6)
return;
 
/* Turn off the HW timers and go directly to rc6 */
-   set(uncore, GEN6_RC_CONTROL, GEN6_RC_CTL_RC6_ENABLE);
+   intel_uncore_write(uncore, GEN6_RC_CONTROL, GEN6_RC_CTL_RC6_ENABLE);
 
if (HAS_RC6pp(rc6_to_i915(rc6)))
target = 0x6; /* deepest rc6 */
@@ -663,7 +663,7 @@ void intel_rc6_park(struct intel_rc6 *rc6)
target = 0x5; /* deep rc6 */
else
target = 0x4; /* normal rc6 */
-   set(uncore, GEN6_RC_STATE, target << RC_SW_TARGET_STATE_SHIFT);
+   intel_uncore_write(uncore, GEN6_RC_STATE, target << 
RC_SW_TARGET_STATE_SHIFT);
 }
 
 void intel_rc6_disable(struct intel_rc6 *rc6)
-- 
2.25.1

[Intel-gfx] ✗ Fi.CI.BUILD: failure for gvt-next (rev2)

[Patchwork]

== Series Details ==

Series: gvt-next (rev2)
URL   : https://patchwork.freedesktop.org/series/102952/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/102952/revisions/2/mbox/ not 
applied
Applying: gvt-next
error: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/intel_gvt.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 gvt-next
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".

Re: [Intel-gfx] [PATCH v12] drm/amdgpu: add drm buddy support to amdgpu

[Mike Lothian]

Hi

I'm having issues with this patch on my PRIME system and vulkan workloads

https://gitlab.freedesktop.org/drm/amd/-/issues/1992

Is there any chance you could take a look?

Cheers

Mike

Re: [Intel-gfx] False-positive of CI issue w/ AMDGPU patch set

[Vudum, Lakshminarayana]

I have re-opened https://gitlab.freedesktop.org/drm/intel/-/issues/5302
igt@i915_module_load@reload-with-fault-injection - dmesg-warn - WARNING: .* at 
drivers/gpu/drm/i915/i915_vma.c:\d+ i915_ggtt_pin

Other sounds is not totally new, I have seen similar signature few months ago 
on a different test but to me this sounds like a sporadic issue. So filed a new 
issue
https://gitlab.freedesktop.org/drm/intel/-/issues/5844
igt@kms_fbcon_fbt@psr-suspend - incomplete - pstore logs - is trying to acquire 
lock at: down_trylock, but task is already holding lock at: 
raw_spin_rq_lock_nested

Anyways, re-reporting doesn't really help as we will get results from rev5.

Lakshmi.
From: Zhang, Dingchen (David) 
Sent: Tuesday, April 26, 2022 6:38 AM
To: Vudum, Lakshminarayana ; 
intel-gfx@lists.freedesktop.org; Latvala, Petri 
Cc: Siqueira, Rodrigo ; Pillai, Aurabindo 

Subject: Re: False-positive of CI issue w/ AMDGPU patch set


[AMD Official Use Only]

Hi Lakshmi,

Thanks for your reply and could you please clear another false-positive CI 
issue below? (link https://patchwork.freedesktop.org/series/102886/). The 
possible regression is not correlated to the amdgpu patch set.

[cid:image001.png@01D85947.3E2D5CE0]

regards
David

From: Vudum, Lakshminarayana 
mailto:lakshminarayana.vu...@intel.com>>
Sent: Monday, April 25, 2022 5:25 PM
To: Zhang, Dingchen (David) 
mailto:dingchen.zh...@amd.com>>; 
intel-gfx@lists.freedesktop.org 
mailto:intel-gfx@lists.freedesktop.org>>; 
Latvala, Petri mailto:petri.latv...@intel.com>>
Cc: Siqueira, Rodrigo 
mailto:rodrigo.sique...@amd.com>>; Pillai, Aurabindo 
mailto:aurabindo.pil...@amd.com>>
Subject: RE: False-positive of CI issue w/ AMDGPU patch set


[AMD Official Use Only]


I am not sure if I can take any action here. @Latvala, 
Petri Any inputs?



Lakshmi.



From: Zhang, Dingchen (David) 
mailto:dingchen.zh...@amd.com>>
Sent: Monday, April 25, 2022 1:16 PM
To: Vudum, Lakshminarayana 
mailto:lakshminarayana.vu...@intel.com>>
Cc: Siqueira, Rodrigo 
mailto:rodrigo.sique...@amd.com>>; Pillai, Aurabindo 
mailto:aurabindo.pil...@amd.com>>
Subject: False-positive of CI issue w/ AMDGPU patch set



[AMD Official Use Only]



Hi Lakshminarayana,



Could you help clear the CI pipeline issue of below patch w/ the ARMHF failure, 
which is a false-positive that is uncorrelated to the amdgpu patch set?

https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/-/pipelines/569071

[Image removed by 
sender.]


Pipeline * gfx-ci / 
igt-ci-tags

CI tags for IGT GPU tools. WARNING: This repo's master branch will not be 
updated. Use https://gitlab.freedesktop.org/drm/igt-gpu-tools for this purpose.

gitlab.freedesktop.org




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



Thanks

David

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Support Async Flip on Linear buffers

[Patchwork]

== Series Details ==

Series: drm/i915: Support Async Flip on Linear buffers
URL   : https://patchwork.freedesktop.org/series/103137/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103137v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 13)
--

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][1] +4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/shard-dg1-12/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@i915_pm_dc@dc6-psr:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][2] +1 similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/shard-rkl-5/igt@i915_pm...@dc6-psr.html

  * {igt@kms_concurrent@pipe-d@hdmi-a-1}:
- {shard-dg1}:NOTRUN -> [CRASH][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/shard-dg1-16/igt@kms_concurrent@pip...@hdmi-a-1.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-skl:  ([PASS][4], [PASS][5], [PASS][6], [PASS][7], 
[PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], 
[PASS][14], [PASS][15], [FAIL][16], [PASS][17], [PASS][18], [PASS][19], 
[PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], 
[PASS][26], [PASS][27]) ([i915#5032]) -> ([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], [PASS][42], 
[PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], 
[PASS][49], [PASS][50], [PASS][51])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/shard-skl6/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/shard-skl8/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/shard-skl8/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/shard-skl8/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/shard-skl7/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/shard-skl7/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/shard-skl10/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/shard-skl10/boot.html
   [36]: 

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/dp: Add workaround for spurious AUX timeouts/hotplugs on LTTPR links

[Jani Nikula]

On Tue, 26 Apr 2022, Imre Deak  wrote:
> On Tue, Apr 26, 2022 at 02:31:07PM +0300, Jani Nikula wrote:
>> On Tue, 26 Apr 2022, Imre Deak  wrote:
>> > On Thu, Apr 14, 2022 at 01:49:54PM +0300, Jani Nikula wrote:
>> >> On Sat, 09 Apr 2022, Imre Deak  wrote:
>> >> > Some ADLP DP link configuration at least with multiple LTTPRs expects
>> >> > the first DPCD access during the LTTPR/DPCD detection after hotplug to
>> >> > be a read from the LTTPR range starting with
>> >> > DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV. The side effect of
>> >> > this read is to put each LTTPR into the LTTPR transparent or LTTPR
>> >> > non-transparent mode.
>> >> >
>> >> > The lack of the above read may leave some of the LTTPRs in non-LTTPR
>> >> > mode, while other LTTPRs in LTTPR transparent or LTTPR non-transparent
>> >> > mode (for instance LTTPRs after system suspend/resume that kept their
>> >> > mode from before suspend). Due to the different AUX timeouts the
>> >> > different modes imply, the DPCD access from a non-LTTPR range will
>> >> > timeout and lead to an LTTPR generated hotplug towards the source (which
>> >> > the LTTPR firmware uses to account for buggy TypeC adapters with a long
>> >> > wake-up delay).
>> >> >
>> >> > To avoid the above AUX timeout and subsequent hotplug interrupt, make
>> >> > sure that the first DPCD access during detection is a read from an
>> >> > LTTPR register.
>> >> >
>> >> > VLK: SYSCROS-72939
>> >> >
>> >> > v2: Keep DPCD read-out working on non-LTTPR platforms.
>> >> >
>> >> > Signed-off-by: Imre Deak 
>> >> 
>> >> I kinda dislike how complicated this looks for a diff so small. *shrug*.
>> >> Seems to do what it says on the box,
>> >
>> > I can have a better summary of what the patch does and why at the
>> > beginning of the commit message. Imo the details for the related LTTPR
>> > behavior are still useful for later reference; it's not too intuitive
>> > with the read side-effects for instance, neither it is well documented
>> > by the DP standard.
>> >
>> >> Reviewed-by: Jani Nikula 
>> >
>> > Thanks.
>> >
>> > I pushed the dependent
>> > d8bb92e70a43 ("drm/dp: Factor out a function to probe a DPCD address")
>> > patch to drm-misc-next. Could you help back merging it to
>> > drm-intel-next?
>> 
>> So this is going to need drm-misc-next -> drm-next pull request before I
>> can backmerge drm-next to drm-intel-next.
>
> Ok. AFAICS drm-next includes already the above commit.

Did the backmerge.

BR,
Jani.

>
>> BR,
>> Jani.
>> 
>> 
>> 
>> >
>> >> > ---
>> >> >  .../drm/i915/display/intel_dp_link_training.c | 33 ++-
>> >> >  1 file changed, 17 insertions(+), 16 deletions(-)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
>> >> > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> >> > index 26f9e2b748e40..9feaf1a589f38 100644
>> >> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> >> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> >> > @@ -82,19 +82,8 @@ static bool intel_dp_read_lttpr_common_caps(struct 
>> >> > intel_dp *intel_dp,
>> >> > const u8 
>> >> > dpcd[DP_RECEIVER_CAP_SIZE])
>> >> >  {
>> >> > struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
>> >> > -   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
>> >> > int ret;
>> >> >  
>> >> > -   if (intel_dp_is_edp(intel_dp))
>> >> > -   return false;
>> >> > -
>> >> > -   /*
>> >> > -* Detecting LTTPRs must be avoided on platforms with an AUX 
>> >> > timeout
>> >> > -* period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
>> >> > -*/
>> >> > -   if (DISPLAY_VER(i915) < 10 || IS_GEMINILAKE(i915))
>> >> > -   return false;
>> >> > -
>> >> > ret = drm_dp_read_lttpr_common_caps(_dp->aux, dpcd,
>> >> > 
>> >> > intel_dp->lttpr_common_caps);
>> >> > if (ret < 0)
>> >> > @@ -197,13 +186,25 @@ static int intel_dp_init_lttpr(struct intel_dp 
>> >> > *intel_dp, const u8 dpcd[DP_RECEI
>> >> >   */
>> >> >  int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp)
>> >> >  {
>> >> > -   u8 dpcd[DP_RECEIVER_CAP_SIZE];
>> >> > -   int lttpr_count;
>> >> > +   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>> >> > +   int lttpr_count = 0;
>> >> >  
>> >> > -   if (drm_dp_read_dpcd_caps(_dp->aux, dpcd))
>> >> > -   return -EIO;
>> >> > +   /*
>> >> > +* Detecting LTTPRs must be avoided on platforms with an AUX 
>> >> > timeout
>> >> > +* period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
>> >> > +*/
>> >> > +   if (!intel_dp_is_edp(intel_dp) &&
>> >> > +   (DISPLAY_VER(i915) >= 10 && !IS_GEMINILAKE(i915))) {
>> >> > +   u8 dpcd[DP_RECEIVER_CAP_SIZE];
>> >> >  
>> >> > -   lttpr_count = intel_dp_init_lttpr(intel_dp, dpcd);
>> >> > +

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Media freq factor

[Dixit, Ashutosh]

On Mon, 25 Apr 2022 20:13:09 -0700, Patchwork wrote:
>
> Possible new issues
>
> Here are the unknown changes that may have been introduced in 
> Patchwork_103110v1_full:
>
> IGT changes
>
> Possible regressions
>
> * {igt@i915_pm_disag_freq@media-freq@gt0} (NEW):
>
>  * shard-iclb: NOTRUN -> SKIP +1 similar issue
>
>  * shard-tglb: NOTRUN -> SKIP

These skips are as expected. These new IGT tests for this feature (media
freq factor) when introduced will skip on platforms which don't have
support for this feature. The feature is only supported on DG2 and XEHPSDV
at this point.

>
> New tests
>
> New tests have been introduced between CI_DRM_11550_full and 
> Patchwork_103110v1_full:
>
> New IGT tests (1)
>
> * igt@i915_pm_disag_freq@media-freq@gt0:
>
>  * Statuses : 7 skip(s)
>  * Exec time: [0.0] s

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Support Async Flip on Linear buffers

[Patchwork]

== Series Details ==

Series: drm/i915: Support Async Flip on Linear buffers
URL   : https://patchwork.freedesktop.org/series/103137/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103137v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 44)
--

  Additional (4): bat-dg2-8 fi-kbl-x1275 bat-dg1-6 bat-adlp-4 
  Missing(3): fi-kbl-soraka fi-bsw-cyan fi-bdw-5557u 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@gtt:
- {bat-rpls-1}:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-1/igt@i915_selftest@l...@gtt.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/bat-rpls-1/igt@i915_selftest@l...@gtt.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- {bat-dg2-8}:NOTRUN -> [SKIP][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/bat-dg2-8/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6:  NOTRUN -> [INCOMPLETE][4] ([i915#5827])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-x1275:   NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/fi-kbl-x1275/igt@gem_huc_c...@huc-copy.html
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][7] ([i915#4613]) +3 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html
- bat-adlp-4: NOTRUN -> [SKIP][8] ([i915#4613]) +3 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/bat-adlp-4/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@verify-random:
- fi-kbl-x1275:   NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/fi-kbl-x1275/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_tiled_pread_basic:
- bat-adlp-4: NOTRUN -> [SKIP][10] ([i915#3282])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/bat-adlp-4/igt@gem_tiled_pread_basic.html
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#3282])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([i915#3012])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rpm@module-reload:
- bat-adlp-4: NOTRUN -> [DMESG-WARN][13] ([i915#3576]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/bat-adlp-4/igt@i915_pm_...@module-reload.html

  * igt@kms_chamelium@dp-crc-fast:
- bat-adlp-4: NOTRUN -> [SKIP][14] ([fdo#111827]) +8 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/bat-adlp-4/igt@kms_chamel...@dp-crc-fast.html
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([fdo#111827]) +8 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/fi-rkl-11600/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-kbl-x1275:   NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/fi-kbl-x1275/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([i915#4070] / [i915#4103]) +1 
similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103137v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-4: NOTRUN -> [SKIP][18] ([i915#4103]) +1 similar issue
   [18]: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Support Async Flip on Linear buffers

[Patchwork]

== Series Details ==

Series: drm/i915: Support Async Flip on Linear buffers
URL   : https://patchwork.freedesktop.org/series/103137/
State : warning

== Summary ==

Error: dim checkpatch failed
4d312fea73b4 drm/i915: Support Async Flip on Linear buffers
-:22: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#22: FILE: drivers/gpu/drm/i915/display/intel_display.c:7529:
+   drm_dbg_kms(>drm,
+   "[PLANE:%d:%s] Modifier does not 
support async flips\n",

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

[Intel-gfx] [PATCH] drm/i915: Support Async Flip on Linear buffers

[Arun R Murthy]

Starting from Gen12 Async Flip is supported on linear buffers.
This patch enables support for async on linear buffer.

Signed-off-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/intel_display.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 0decf3d24237..e3bf250b85e4 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7522,6 +7522,13 @@ static int intel_async_flip_check_hw(struct 
intel_atomic_state *state, struct in
 * this selectively if required.
 */
switch (new_plane_state->hw.fb->modifier) {
+   case DRM_FORMAT_MOD_LINEAR:
+   if (DISPLAY_VER(i915) < 12) {
+   drm_dbg_kms(>drm,
+   "[PLANE:%d:%s] Modifier does not 
support async flips\n",
+   plane->base.base.id, plane->base.name);
+   return -EINVAL;
+   }
case I915_FORMAT_MOD_X_TILED:
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Yf_TILED:
-- 
2.25.1

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/dp: Add workaround for spurious AUX timeouts/hotplugs on LTTPR links

[Imre Deak]

On Tue, Apr 26, 2022 at 02:31:07PM +0300, Jani Nikula wrote:
> On Tue, 26 Apr 2022, Imre Deak  wrote:
> > On Thu, Apr 14, 2022 at 01:49:54PM +0300, Jani Nikula wrote:
> >> On Sat, 09 Apr 2022, Imre Deak  wrote:
> >> > Some ADLP DP link configuration at least with multiple LTTPRs expects
> >> > the first DPCD access during the LTTPR/DPCD detection after hotplug to
> >> > be a read from the LTTPR range starting with
> >> > DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV. The side effect of
> >> > this read is to put each LTTPR into the LTTPR transparent or LTTPR
> >> > non-transparent mode.
> >> >
> >> > The lack of the above read may leave some of the LTTPRs in non-LTTPR
> >> > mode, while other LTTPRs in LTTPR transparent or LTTPR non-transparent
> >> > mode (for instance LTTPRs after system suspend/resume that kept their
> >> > mode from before suspend). Due to the different AUX timeouts the
> >> > different modes imply, the DPCD access from a non-LTTPR range will
> >> > timeout and lead to an LTTPR generated hotplug towards the source (which
> >> > the LTTPR firmware uses to account for buggy TypeC adapters with a long
> >> > wake-up delay).
> >> >
> >> > To avoid the above AUX timeout and subsequent hotplug interrupt, make
> >> > sure that the first DPCD access during detection is a read from an
> >> > LTTPR register.
> >> >
> >> > VLK: SYSCROS-72939
> >> >
> >> > v2: Keep DPCD read-out working on non-LTTPR platforms.
> >> >
> >> > Signed-off-by: Imre Deak 
> >> 
> >> I kinda dislike how complicated this looks for a diff so small. *shrug*.
> >> Seems to do what it says on the box,
> >
> > I can have a better summary of what the patch does and why at the
> > beginning of the commit message. Imo the details for the related LTTPR
> > behavior are still useful for later reference; it's not too intuitive
> > with the read side-effects for instance, neither it is well documented
> > by the DP standard.
> >
> >> Reviewed-by: Jani Nikula 
> >
> > Thanks.
> >
> > I pushed the dependent
> > d8bb92e70a43 ("drm/dp: Factor out a function to probe a DPCD address")
> > patch to drm-misc-next. Could you help back merging it to
> > drm-intel-next?
> 
> So this is going to need drm-misc-next -> drm-next pull request before I
> can backmerge drm-next to drm-intel-next.

Ok. AFAICS drm-next includes already the above commit.

> BR,
> Jani.
> 
> 
> 
> >
> >> > ---
> >> >  .../drm/i915/display/intel_dp_link_training.c | 33 ++-
> >> >  1 file changed, 17 insertions(+), 16 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
> >> > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> > index 26f9e2b748e40..9feaf1a589f38 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> > @@ -82,19 +82,8 @@ static bool intel_dp_read_lttpr_common_caps(struct 
> >> > intel_dp *intel_dp,
> >> >  const u8 
> >> > dpcd[DP_RECEIVER_CAP_SIZE])
> >> >  {
> >> >  struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
> >> > -struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> >> >  int ret;
> >> >  
> >> > -if (intel_dp_is_edp(intel_dp))
> >> > -return false;
> >> > -
> >> > -/*
> >> > - * Detecting LTTPRs must be avoided on platforms with an AUX 
> >> > timeout
> >> > - * period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
> >> > - */
> >> > -if (DISPLAY_VER(i915) < 10 || IS_GEMINILAKE(i915))
> >> > -return false;
> >> > -
> >> >  ret = drm_dp_read_lttpr_common_caps(_dp->aux, dpcd,
> >> >  
> >> > intel_dp->lttpr_common_caps);
> >> >  if (ret < 0)
> >> > @@ -197,13 +186,25 @@ static int intel_dp_init_lttpr(struct intel_dp 
> >> > *intel_dp, const u8 dpcd[DP_RECEI
> >> >   */
> >> >  int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp)
> >> >  {
> >> > -u8 dpcd[DP_RECEIVER_CAP_SIZE];
> >> > -int lttpr_count;
> >> > +struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> >> > +int lttpr_count = 0;
> >> >  
> >> > -if (drm_dp_read_dpcd_caps(_dp->aux, dpcd))
> >> > -return -EIO;
> >> > +/*
> >> > + * Detecting LTTPRs must be avoided on platforms with an AUX 
> >> > timeout
> >> > + * period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
> >> > + */
> >> > +if (!intel_dp_is_edp(intel_dp) &&
> >> > +(DISPLAY_VER(i915) >= 10 && !IS_GEMINILAKE(i915))) {
> >> > +u8 dpcd[DP_RECEIVER_CAP_SIZE];
> >> >  
> >> > -lttpr_count = intel_dp_init_lttpr(intel_dp, dpcd);
> >> > +if (drm_dp_dpcd_probe(_dp->aux, 
> >> > DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV))
> >> > +return -EIO;
> >> > 

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/dp: Add workaround for spurious AUX timeouts/hotplugs on LTTPR links

[Jani Nikula]

On Tue, 26 Apr 2022, Imre Deak  wrote:
> On Thu, Apr 14, 2022 at 01:49:54PM +0300, Jani Nikula wrote:
>> On Sat, 09 Apr 2022, Imre Deak  wrote:
>> > Some ADLP DP link configuration at least with multiple LTTPRs expects
>> > the first DPCD access during the LTTPR/DPCD detection after hotplug to
>> > be a read from the LTTPR range starting with
>> > DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV. The side effect of
>> > this read is to put each LTTPR into the LTTPR transparent or LTTPR
>> > non-transparent mode.
>> >
>> > The lack of the above read may leave some of the LTTPRs in non-LTTPR
>> > mode, while other LTTPRs in LTTPR transparent or LTTPR non-transparent
>> > mode (for instance LTTPRs after system suspend/resume that kept their
>> > mode from before suspend). Due to the different AUX timeouts the
>> > different modes imply, the DPCD access from a non-LTTPR range will
>> > timeout and lead to an LTTPR generated hotplug towards the source (which
>> > the LTTPR firmware uses to account for buggy TypeC adapters with a long
>> > wake-up delay).
>> >
>> > To avoid the above AUX timeout and subsequent hotplug interrupt, make
>> > sure that the first DPCD access during detection is a read from an
>> > LTTPR register.
>> >
>> > VLK: SYSCROS-72939
>> >
>> > v2: Keep DPCD read-out working on non-LTTPR platforms.
>> >
>> > Signed-off-by: Imre Deak 
>> 
>> I kinda dislike how complicated this looks for a diff so small. *shrug*.
>> Seems to do what it says on the box,
>
> I can have a better summary of what the patch does and why at the
> beginning of the commit message. Imo the details for the related LTTPR
> behavior are still useful for later reference; it's not too intuitive
> with the read side-effects for instance, neither it is well documented
> by the DP standard.
>
>> Reviewed-by: Jani Nikula 
>
> Thanks.
>
> I pushed the dependent
> d8bb92e70a43 ("drm/dp: Factor out a function to probe a DPCD address")
> patch to drm-misc-next. Could you help back merging it to
> drm-intel-next?

So this is going to need drm-misc-next -> drm-next pull request before I
can backmerge drm-next to drm-intel-next.

BR,
Jani.



>
>> > ---
>> >  .../drm/i915/display/intel_dp_link_training.c | 33 ++-
>> >  1 file changed, 17 insertions(+), 16 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
>> > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> > index 26f9e2b748e40..9feaf1a589f38 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> > @@ -82,19 +82,8 @@ static bool intel_dp_read_lttpr_common_caps(struct 
>> > intel_dp *intel_dp,
>> >const u8 dpcd[DP_RECEIVER_CAP_SIZE])
>> >  {
>> >struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
>> > -  struct drm_i915_private *i915 = to_i915(encoder->base.dev);
>> >int ret;
>> >  
>> > -  if (intel_dp_is_edp(intel_dp))
>> > -  return false;
>> > -
>> > -  /*
>> > -   * Detecting LTTPRs must be avoided on platforms with an AUX timeout
>> > -   * period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
>> > -   */
>> > -  if (DISPLAY_VER(i915) < 10 || IS_GEMINILAKE(i915))
>> > -  return false;
>> > -
>> >ret = drm_dp_read_lttpr_common_caps(_dp->aux, dpcd,
>> >intel_dp->lttpr_common_caps);
>> >if (ret < 0)
>> > @@ -197,13 +186,25 @@ static int intel_dp_init_lttpr(struct intel_dp 
>> > *intel_dp, const u8 dpcd[DP_RECEI
>> >   */
>> >  int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp)
>> >  {
>> > -  u8 dpcd[DP_RECEIVER_CAP_SIZE];
>> > -  int lttpr_count;
>> > +  struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>> > +  int lttpr_count = 0;
>> >  
>> > -  if (drm_dp_read_dpcd_caps(_dp->aux, dpcd))
>> > -  return -EIO;
>> > +  /*
>> > +   * Detecting LTTPRs must be avoided on platforms with an AUX timeout
>> > +   * period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
>> > +   */
>> > +  if (!intel_dp_is_edp(intel_dp) &&
>> > +  (DISPLAY_VER(i915) >= 10 && !IS_GEMINILAKE(i915))) {
>> > +  u8 dpcd[DP_RECEIVER_CAP_SIZE];
>> >  
>> > -  lttpr_count = intel_dp_init_lttpr(intel_dp, dpcd);
>> > +  if (drm_dp_dpcd_probe(_dp->aux, 
>> > DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV))
>> > +  return -EIO;
>> > +
>> > +  if (drm_dp_read_dpcd_caps(_dp->aux, dpcd))
>> > +  return -EIO;
>> > +
>> > +  lttpr_count = intel_dp_init_lttpr(intel_dp, dpcd);
>> > +  }
>> >  
>> >/*
>> > * The DPTX shall read the DPRX caps after LTTPR detection, so re-read
>> 
>> -- 
>> Jani Nikula, Intel Open Source Graphics Center

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/edid: fix kernel-doc parameter name mismatches

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/edid: fix kernel-doc parameter name 
mismatches
URL   : https://patchwork.freedesktop.org/series/103131/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103131v1_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_103131v1_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_103131v1_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 -> 13)
--

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_suspend@forcewake:
- shard-kbl:  [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-kbl6/igt@i915_susp...@forcewake.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103131v1/shard-kbl6/igt@i915_susp...@forcewake.html

  
 Suppressed 

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

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][3] +3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103131v1/shard-dg1-19/igt@gem_ctx_isolation@preservation...@rcs0.html

  * {igt@kms_concurrent@pipe-d@hdmi-a-1}:
- {shard-dg1}:NOTRUN -> [CRASH][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103131v1/shard-dg1-12/igt@kms_concurrent@pip...@hdmi-a-1.html

  * igt@kms_flip@flip-vs-wf_vblank-interruptible:
- {shard-rkl}:NOTRUN -> [SKIP][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103131v1/shard-rkl-3/igt@kms_flip@flip-vs-wf_vblank-interruptible.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-skl:  ([PASS][6], [PASS][7], [PASS][8], [PASS][9], 
[PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], 
[PASS][16], [PASS][17], [FAIL][18], [PASS][19], [PASS][20], [PASS][21], 
[PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], 
[PASS][28], [PASS][29]) ([i915#5032]) -> ([PASS][30], [PASS][31], [PASS][32], 
[PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], 
[PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], 
[PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], 
[PASS][51], [PASS][52], [PASS][53])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/boot.html
   [30]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/edid: fix kernel-doc parameter name mismatches

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/edid: fix kernel-doc parameter name 
mismatches
URL   : https://patchwork.freedesktop.org/series/103131/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103131v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 42)
--

  Additional (2): bat-dg1-6 bat-adlp-4 
  Missing(3): fi-kbl-soraka bat-rpls-1 fi-bsw-cyan 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6:  NOTRUN -> [INCOMPLETE][1] ([i915#5827])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103131v1/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_lmem_swapping@basic:
- bat-adlp-4: NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103131v1/bat-adlp-4/igt@gem_lmem_swapp...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-adlp-4: NOTRUN -> [SKIP][3] ([i915#3282])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103131v1/bat-adlp-4/igt@gem_tiled_pread_basic.html

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][4] -> [DMESG-FAIL][5] ([i915#4528])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103131v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@kms_busy@basic@modeset:
- bat-adlp-4: NOTRUN -> [DMESG-WARN][6] ([i915#3576]) +2 similar 
issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103131v1/bat-adlp-4/igt@kms_busy@ba...@modeset.html

  * igt@kms_chamelium@dp-crc-fast:
- bat-adlp-4: NOTRUN -> [SKIP][7] ([fdo#111827]) +8 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103131v1/bat-adlp-4/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-4: NOTRUN -> [SKIP][8] ([i915#4103]) +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103131v1/bat-adlp-4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@prune-stale-modes:
- bat-adlp-4: NOTRUN -> [SKIP][9] ([i915#4093]) +3 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103131v1/bat-adlp-4/igt@kms_force_connector_ba...@prune-stale-modes.html

  * igt@kms_setmode@basic-clone-single-crtc:
- bat-adlp-4: NOTRUN -> [SKIP][10] ([i915#3555])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103131v1/bat-adlp-4/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-fence-read:
- bat-adlp-4: NOTRUN -> [SKIP][11] ([i915#3291] / [i915#3708]) +2 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103131v1/bat-adlp-4/igt@prime_v...@basic-fence-read.html

  * igt@prime_vgem@basic-userptr:
- bat-adlp-4: NOTRUN -> [SKIP][12] ([i915#3301] / [i915#3708])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103131v1/bat-adlp-4/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-blb-e6850:   NOTRUN -> [FAIL][13] ([fdo#109271] / [i915#2403] / 
[i915#4312])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103131v1/fi-blb-e6850/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-guc: [DMESG-FAIL][14] ([i915#5334]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103131v1/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][16] ([i915#4785]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103131v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_busy@basic@modeset:
- {bat-adlp-6}:   [DMESG-WARN][18] ([i915#3576]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-adlp-6/igt@kms_busy@ba...@modeset.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103131v1/bat-adlp-6/igt@kms_busy@ba...@modeset.html

  
 Warnings 

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-7567u:   [SKIP][20] ([fdo#109271] / [i915#5341]) -> [SKIP][21] 
([fdo#109271])
   [20]: 

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/dp: Add workaround for spurious AUX timeouts/hotplugs on LTTPR links

[Imre Deak]

On Thu, Apr 14, 2022 at 01:49:54PM +0300, Jani Nikula wrote:
> On Sat, 09 Apr 2022, Imre Deak  wrote:
> > Some ADLP DP link configuration at least with multiple LTTPRs expects
> > the first DPCD access during the LTTPR/DPCD detection after hotplug to
> > be a read from the LTTPR range starting with
> > DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV. The side effect of
> > this read is to put each LTTPR into the LTTPR transparent or LTTPR
> > non-transparent mode.
> >
> > The lack of the above read may leave some of the LTTPRs in non-LTTPR
> > mode, while other LTTPRs in LTTPR transparent or LTTPR non-transparent
> > mode (for instance LTTPRs after system suspend/resume that kept their
> > mode from before suspend). Due to the different AUX timeouts the
> > different modes imply, the DPCD access from a non-LTTPR range will
> > timeout and lead to an LTTPR generated hotplug towards the source (which
> > the LTTPR firmware uses to account for buggy TypeC adapters with a long
> > wake-up delay).
> >
> > To avoid the above AUX timeout and subsequent hotplug interrupt, make
> > sure that the first DPCD access during detection is a read from an
> > LTTPR register.
> >
> > VLK: SYSCROS-72939
> >
> > v2: Keep DPCD read-out working on non-LTTPR platforms.
> >
> > Signed-off-by: Imre Deak 
> 
> I kinda dislike how complicated this looks for a diff so small. *shrug*.
> Seems to do what it says on the box,

I can have a better summary of what the patch does and why at the
beginning of the commit message. Imo the details for the related LTTPR
behavior are still useful for later reference; it's not too intuitive
with the read side-effects for instance, neither it is well documented
by the DP standard.

> Reviewed-by: Jani Nikula 

Thanks.

I pushed the dependent
d8bb92e70a43 ("drm/dp: Factor out a function to probe a DPCD address")
patch to drm-misc-next. Could you help back merging it to
drm-intel-next?

> > ---
> >  .../drm/i915/display/intel_dp_link_training.c | 33 ++-
> >  1 file changed, 17 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
> > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > index 26f9e2b748e40..9feaf1a589f38 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > @@ -82,19 +82,8 @@ static bool intel_dp_read_lttpr_common_caps(struct 
> > intel_dp *intel_dp,
> > const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> >  {
> > struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
> > -   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > int ret;
> >  
> > -   if (intel_dp_is_edp(intel_dp))
> > -   return false;
> > -
> > -   /*
> > -* Detecting LTTPRs must be avoided on platforms with an AUX timeout
> > -* period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
> > -*/
> > -   if (DISPLAY_VER(i915) < 10 || IS_GEMINILAKE(i915))
> > -   return false;
> > -
> > ret = drm_dp_read_lttpr_common_caps(_dp->aux, dpcd,
> > intel_dp->lttpr_common_caps);
> > if (ret < 0)
> > @@ -197,13 +186,25 @@ static int intel_dp_init_lttpr(struct intel_dp 
> > *intel_dp, const u8 dpcd[DP_RECEI
> >   */
> >  int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp)
> >  {
> > -   u8 dpcd[DP_RECEIVER_CAP_SIZE];
> > -   int lttpr_count;
> > +   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > +   int lttpr_count = 0;
> >  
> > -   if (drm_dp_read_dpcd_caps(_dp->aux, dpcd))
> > -   return -EIO;
> > +   /*
> > +* Detecting LTTPRs must be avoided on platforms with an AUX timeout
> > +* period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
> > +*/
> > +   if (!intel_dp_is_edp(intel_dp) &&
> > +   (DISPLAY_VER(i915) >= 10 && !IS_GEMINILAKE(i915))) {
> > +   u8 dpcd[DP_RECEIVER_CAP_SIZE];
> >  
> > -   lttpr_count = intel_dp_init_lttpr(intel_dp, dpcd);
> > +   if (drm_dp_dpcd_probe(_dp->aux, 
> > DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV))
> > +   return -EIO;
> > +
> > +   if (drm_dp_read_dpcd_caps(_dp->aux, dpcd))
> > +   return -EIO;
> > +
> > +   lttpr_count = intel_dp_init_lttpr(intel_dp, dpcd);
> > +   }
> >  
> > /*
> >  * The DPTX shall read the DPRX caps after LTTPR detection, so re-read
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/edid: fix kernel-doc parameter name mismatches

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/edid: fix kernel-doc parameter name 
mismatches
URL   : https://patchwork.freedesktop.org/series/103131/
State : warning

== Summary ==

Error: dim checkpatch failed
a94bb9f72a7c drm/edid: fix kernel-doc parameter name mismatches
-:18: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#18: 
References: https://lore.kernel.org/r/20220406154431.56741...@canb.auug.org.au

total: 0 errors, 1 warnings, 0 checks, 26 lines checked
b687d8d839a7 drm/edid: drop kernel-doc for static functions

[Intel-gfx] [PATCH 2/2] drm/edid: drop kernel-doc for static functions

[Jani Nikula]

Drop the kernel-doc for static functions, it's excessive, but retain the
info in plain comments.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid.c | 57 --
 1 file changed, 17 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6446f5d3944b..bc43e1b32092 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2384,13 +2384,9 @@ static u32 edid_get_quirks(const struct edid *edid)
 #define MODE_SIZE(m) ((m)->hdisplay * (m)->vdisplay)
 #define MODE_REFRESH_DIFF(c,t) (abs((c) - (t)))
 
-/**
- * edid_fixup_preferred - set preferred modes based on quirk list
- * @connector: has mode list to fix up
- * @quirks: quirks list
- *
- * Walk the mode list for @connector, clearing the preferred status
- * on existing modes and setting it anew for the right mode ala @quirks.
+/*
+ * Walk the mode list for connector, clearing the preferred status on existing
+ * modes and setting it anew for the right mode ala quirks.
  */
 static void edid_fixup_preferred(struct drm_connector *connector,
 u32 quirks)
@@ -2659,10 +2655,7 @@ drm_gtf2_2j(const struct edid *edid)
return descriptor ? 
descriptor->data.other_data.data.range.formula.gtf2.j : 0;
 }
 
-/**
- * standard_timing_level - get std. timing level(CVT/GTF/DMT)
- * @edid: EDID block to scan
- */
+/* Get standard timing level (CVT/GTF/DMT). */
 static int standard_timing_level(const struct edid *edid)
 {
if (edid->revision >= 2) {
@@ -2696,12 +2689,7 @@ static int drm_mode_hsync(const struct drm_display_mode 
*mode)
return DIV_ROUND_CLOSEST(mode->clock, mode->htotal);
 }
 
-/**
- * drm_mode_std - convert standard mode info (width, height, refresh) into mode
- * @connector: connector of for the EDID block
- * @edid: EDID block to scan
- * @t: standard timing params
- *
+/*
  * Take the standard timing params (in this case width, aspect, and refresh)
  * and convert them into a real mode using CVT/GTF/DMT.
  */
@@ -2857,15 +2845,10 @@ drm_mode_do_interlace_quirk(struct drm_display_mode 
*mode,
mode->flags |= DRM_MODE_FLAG_INTERLACE;
 }
 
-/**
- * drm_mode_detailed - create a new mode from an EDID detailed timing section
- * @dev: DRM device (needed to create new mode)
- * @edid: EDID block
- * @timing: EDID detailed timing info
- * @quirks: quirks to apply
- *
- * An EDID detailed timing block contains enough info for us to create and
- * return a new struct drm_display_mode.
+/*
+ * Create a new mode from an EDID detailed timing section. An EDID detailed
+ * timing block contains enough info for us to create and return a new struct
+ * drm_display_mode.
  */
 static struct drm_display_mode *drm_mode_detailed(struct drm_device *dev,
  const struct edid *edid,
@@ -3247,13 +3230,10 @@ do_established_modes(const struct detailed_timing 
*timing, void *c)
closure->modes += drm_est3_modes(closure->connector, timing);
 }
 
-/**
- * add_established_modes - get est. modes from EDID and add them
- * @connector: connector to add mode(s) to
- * @edid: EDID block to scan
- *
- * Each EDID block contains a bitmap of the supported "established modes" list
- * (defined above).  Tease them out and add them to the global modes list.
+/*
+ * Get established modes from EDID and add them. Each EDID block contains a
+ * bitmap of the supported "established modes" list (defined above). Tease them
+ * out and add them to the global modes list.
  */
 static int
 add_established_modes(struct drm_connector *connector, const struct edid *edid)
@@ -3311,13 +3291,10 @@ do_standard_modes(const struct detailed_timing *timing, 
void *c)
}
 }
 
-/**
- * add_standard_modes - get std. modes from EDID and add them
- * @connector: connector to add mode(s) to
- * @edid: EDID block to scan
- *
- * Standard modes can be calculated using the appropriate standard (DMT,
- * GTF or CVT. Grab them from @edid and add them to the list.
+/*
+ * Get standard modes from EDID and add them. Standard modes can be calculated
+ * using the appropriate standard (DMT, GTF, or CVT). Grab them from EDID and
+ * add them to the list.
  */
 static int
 add_standard_modes(struct drm_connector *connector, const struct edid *edid)
-- 
2.30.2

[Intel-gfx] [PATCH 1/2] drm/edid: fix kernel-doc parameter name mismatches

[Jani Nikula]

Fix the below drm/edid kernel-doc warnings:

drivers/gpu/drm/drm_edid.c:1589: warning: Function parameter or member '_edid' 
not described in 'drm_edid_header_is_valid'
drivers/gpu/drm/drm_edid.c:1589: warning: Excess function parameter 'raw_edid' 
description in 'drm_edid_header_is_valid'
drivers/gpu/drm/drm_edid.c:1737: warning: Function parameter or member '_block' 
not described in 'drm_edid_block_valid'
drivers/gpu/drm/drm_edid.c:1737: warning: Excess function parameter 'raw_edid' 
description in 'drm_edid_block_valid'
drivers/gpu/drm/drm_edid.c:2136: warning: Function parameter or member 
'read_block' not described in 'drm_do_get_edid'
drivers/gpu/drm/drm_edid.c:2136: warning: Function parameter or member 
'context' not described in 'drm_do_get_edid'
drivers/gpu/drm/drm_edid.c:2136: warning: Excess function parameter 
'get_edid_block' description in 'drm_do_get_edid'
drivers/gpu/drm/drm_edid.c:2136: warning: Excess function parameter 'data' 
description in 'drm_do_get_edid'

Reported-by: Stephen Rothwell 
References: https://lore.kernel.org/r/20220406154431.56741...@canb.auug.org.au
References: https://lore.kernel.org/r/20220420162431.2b28d...@canb.auug.org.au
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7a8482b75071..6446f5d3944b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1610,7 +1610,7 @@ static void edid_header_fix(void *edid)
 
 /**
  * drm_edid_header_is_valid - sanity check the header of the base EDID block
- * @raw_edid: pointer to raw base EDID block
+ * @_edid: pointer to raw base EDID block
  *
  * Sanity check the header of the base EDID block.
  *
@@ -1827,7 +1827,7 @@ static void edid_block_dump(const char *level, const void 
*block, int block_num)
 
 /**
  * drm_edid_block_valid - Sanity check the EDID block (base or extension)
- * @raw_edid: pointer to raw EDID block
+ * @_block: pointer to raw EDID block
  * @block_num: type of block to validate (0 for base, extension otherwise)
  * @print_bad_edid: if true, dump bad EDID blocks to the console
  * @edid_corrupt: if true, the header or checksum is invalid
@@ -2112,8 +2112,8 @@ static enum edid_block_status edid_block_read(void 
*block, unsigned int block_nu
 /**
  * drm_do_get_edid - get EDID data using a custom EDID block read function
  * @connector: connector we're probing
- * @get_edid_block: EDID block read function
- * @data: private data passed to the block read function
+ * @read_block: EDID block read function
+ * @context: private data passed to the block read function
  *
  * When the I2C adapter connected to the DDC bus is hidden behind a device that
  * exposes a different interface to read EDID blocks this function can be used
-- 
2.30.2

Re: [Intel-gfx] False-positive of CI issue w/ AMDGPU patch set

[Latvala, Petri]

No action can be taken, and the pipeline issue can be ignored.

https://patchwork.freedesktop.org/series/102992/ is looking for review / acks 
for this issue btw...

Petri


From: Vudum, Lakshminarayana 
Sent: Tuesday, 26 April 2022 0.25
To: Zhang, Dingchen (David) ; 
intel-gfx@lists.freedesktop.org; Latvala, Petri 
Cc: Siqueira, Rodrigo ; Pillai, Aurabindo 

Subject: RE: False-positive of CI issue w/ AMDGPU patch set

I am not sure if I can take any action here. @Latvala, 
Petri Any inputs?

Lakshmi.

From: Zhang, Dingchen (David) 
mailto:dingchen.zh...@amd.com>>
Sent: Monday, April 25, 2022 1:16 PM
To: Vudum, Lakshminarayana 
mailto:lakshminarayana.vu...@intel.com>>
Cc: Siqueira, Rodrigo 
mailto:rodrigo.sique...@amd.com>>; Pillai, Aurabindo 
mailto:aurabindo.pil...@amd.com>>
Subject: False-positive of CI issue w/ AMDGPU patch set


[AMD Official Use Only]

Hi Lakshminarayana,

Could you help clear the CI pipeline issue of below patch w/ the ARMHF failure, 
which is a false-positive that is uncorrelated to the amdgpu patch set?
https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/-/pipelines/569071
[Image removed by 
sender.]

Pipeline * gfx-ci / 
igt-ci-tags
CI tags for IGT GPU tools. WARNING: This repo's master branch will not be 
updated. Use https://gitlab.freedesktop.org/drm/igt-gpu-tools for this purpose.
gitlab.freedesktop.org


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

Thanks
David