[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable HDR on MCA LSPCON based Gen9 devices (rev12)

[Patchwork]

== Series Details ==

Series: Enable HDR on MCA LSPCON based Gen9 devices (rev12)
URL   : https://patchwork.freedesktop.org/series/68081/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_reset.c:1312:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:expected void *in
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20: warning: incorrect type in 
assignment (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:expected void const *src
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46: warning: incorrect type in 
argument 2 (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:expected void *in
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20: warning: incorrect type in 
assignment (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:expected void const *src
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46: warning: incorrect type in 
argument 2 (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:expected unsigned int 
[usertype] *s
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34: warning: incorrect type in 
argument 1 (different address spaces)
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable HDR on MCA LSPCON based Gen9 devices (rev12)

[Patchwork]

== Series Details ==

Series: Enable HDR on MCA LSPCON based Gen9 devices (rev12)
URL   : https://patchwork.freedesktop.org/series/68081/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
07f151724145 drm/i915/display: Add HDR Capability detection for LSPCON
015b28ecdd00 drm/i915/display: Enable HDR on gen9 devices with MCA Lspcon
566633074760 drm/i915/display: Attach HDR property for capable Gen9 devices
-:58: WARNING:LONG_LINE: line length of 108 exceeds 100 columns
#58: FILE: drivers/gpu/drm/i915/display/intel_dp.c:6804:
+  
connector->dev->mode_config.hdr_output_metadata_property,

total: 0 errors, 1 warnings, 0 checks, 45 lines checked
819a38caa76a drm/i915/display: Fixes quantization range for YCbCr output
caa7a05c57aa drm/i915/display: Add a WARN for invalid output range and format
19e480392aa1 drm/i915/display: Attach content type property for LSPCON
5904fa4c5259 drm/i915: Split intel_attach_colorspace_property() into HDMI vs. 
DP variants
9e4c990a2a21 drm/i915/display: Enable colorspace programming for LSPCON devices
589d8106afd0 drm/i915/display: Nuke bogus lspcon check
82c84c1a78fa drm/i915/display: Enable HDR for Parade based lspcon
1a2451b47ea0 drm/i915/lspcon: Create separate infoframe_enabled helper
76e7ab963acd drm/i915/display: Implement infoframes readback for LSPCON
e9838030d807 drm/i915/display: Implement DRM infoframe read for LSPCON
b992e94961f3 drm/i915/lspcon: Do not send DRM infoframes to non-HDMI sinks
1702176c40ec drm/i915/display: [NOT FOR MERGE] Reduce blanking to support 
4k60@10bpp for LSPCON


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

Re: [Intel-gfx] [PATCH v6 00/18] HDCP 2.2 and HDCP 1.4 Gen12 DP MST support

[Karthik B S]

On 11/26/2020 1:07 PM, Anshuman Gupta wrote:

This is v6 version to test with IGT 
https://patchwork.freedesktop.org/series/82987/
This v6 has added a new patch to series to avoid a crash reported on Chrome-OS
and has addressed the few cosmetics review comments from Ram.
It has been also tested manually with above IGT series.

[PATCH v6 12/18] misc/mei/hdcp: Fix AUTH_STREAM_REQ cmd buffer len
has an Ack from Tomas to merge it via drm-intel.

[PATCH v6 13/18] drm/hdcp: Max MST content streams
has an Ack from drm-misc maintainer to merge it via drm-intel.

Test-with: 20201126050320.2434-2-karthik@intel.com


As HDCP over MST set up is not present on CI,

tested this series locally with v4 of the IGT series. 
https://patchwork.freedesktop.org/series/82987/


Tested-by: Karthik B S 



Anshuman Gupta (18):
   drm/i915/hdcp: Update CP property in update_pipe
   drm/i915/hdcp: Get conn while content_type changed
   drm/i915/hotplug: Handle CP_IRQ for DP-MST
   drm/i915/hdcp: No HDCP when encoder is't initialized
   drm/i915/hdcp: DP MST transcoder for link and stream
   drm/i915/hdcp: Move HDCP enc status timeout to header
   drm/i915/hdcp: HDCP stream encryption support
   drm/i915/hdcp: Enable HDCP 1.4 stream encryption
   drm/i915/hdcp: Enable Gen12 HDCP 1.4 DP MST support
   drm/i915/hdcp: Pass dig_port to intel_hdcp_init
   drm/i915/hdcp: Encapsulate hdcp_port_data to dig_port
   misc/mei/hdcp: Fix AUTH_STREAM_REQ cmd buffer len
   drm/hdcp: Max MST content streams
   drm/i915/hdcp: MST streams support in hdcp port_data
   drm/i915/hdcp: Pass connector to check_2_2_link
   drm/i915/hdcp: Add HDCP 2.2 stream register
   drm/i915/hdcp: Support for HDCP 2.2 MST shim callbacks
   drm/i915/hdcp: Enable HDCP 2.2 MST support

  drivers/gpu/drm/i915/display/intel_ddi.c  |  14 +-
  drivers/gpu/drm/i915/display/intel_ddi.h  |   6 +-
  .../drm/i915/display/intel_display_types.h|  20 +-
  drivers/gpu/drm/i915/display/intel_dp.c   |  14 +-
  drivers/gpu/drm/i915/display/intel_dp_hdcp.c  | 186 +--
  drivers/gpu/drm/i915/display/intel_dp_mst.c   |   8 +-
  drivers/gpu/drm/i915/display/intel_hdcp.c | 303 ++
  drivers/gpu/drm/i915/display/intel_hdcp.h |   8 +-
  drivers/gpu/drm/i915/display/intel_hdmi.c |  19 +-
  drivers/gpu/drm/i915/i915_reg.h   |  31 ++
  drivers/misc/mei/hdcp/mei_hdcp.c  |   3 +-
  include/drm/drm_hdcp.h|   8 +-
  12 files changed, 500 insertions(+), 120 deletions(-)



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

Re: [Intel-gfx] [drm/i915/gem] 59dd13ad31: phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second -54.0% regression

[Xing Zhengjun]

On 11/27/2020 5:34 AM, Chris Wilson wrote:

Quoting Xing Zhengjun (2020-11-26 01:44:55)



On 11/25/2020 4:47 AM, Chris Wilson wrote:

Quoting Oliver Sang (2020-11-19 07:20:18)

On Fri, Nov 13, 2020 at 04:27:13PM +0200, Joonas Lahtinen wrote:

Hi,

Could you add intel-gfx@lists.freedesktop.org into reports going
forward.

Quoting kernel test robot (2020-11-11 17:58:11)


Greeting,

FYI, we noticed a -54.0% regression of 
phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second
 due to commit:


How many runs are there on the bad version to ensure the bisect is
repeatable?


test 4 times.
zxing@inn:/result/phoronix-test-suite/performance-true-Radial_Gradient_Paint-1024x1024-jxrendermark-1.2.4-ucode=0xd6-monitor=da39a3ee/lkp-cfl-d1/debian-x86_64-phoronix/x86_64-rhel-8.3/gcc-9/59dd13ad310793757e34afa489dd6fc8544fc3da$
 grep -r "operations_per_second" */stats.json
0/stats.json: 
"phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
 4133.487932,
1/stats.json: 
"phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
 4120.421503,
2/stats.json: 
"phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
 4188.414835,
3/stats.json: 
"phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
 4068.549514,


a w/o revert (drm-tip)
b w/ revert
+mB+
| ..b  |
| ..b.aa   |
| a.a  |
| a.a  |
|  b  b  a |
|   b  b  b b. a   |
|   b  bb bbb...   |
|b   ab bbab.bb.bba b a aab   a|
| |__A__|  |
| |MA_||
+--+
  NMin   MaxMedian   Avg
Stddev
a 120  3621.8761 7356.4442 4606.7895 4607.9132 156.17693
b 120  2664.0563 6359.9686 4519.5036 4534.4463 95.471121

The patch is not expected to have any impact on the machine you are testing on.
-Chris



What's your code base?
For my side:
1) sync the code to the head of Linux mainline
2) git reset --hard 59dd13ad31
3) git revert 59dd13ad3107
We compare the test result of commit 59dd13ad3107 (step 2) and
2052847b06f8 (step 3, revert 59dd13ad3107), the regression should
related with 59dd13ad3107. Each test case we run 5 times.


a 59dd13ad31
b revert
+mB+
|a |
|   aa |
| .bba |
| .bbaab   |
| .b . b   b   |
|a   b.. ..bb  bb  |
|  b a   b.b.a bb  |
|aa  b..aaa..b.b..bab   b a   .|
|  |__A__| |
|  |___A_| |
+--+
 NMin   MaxMedian   Avg
Stddev
a 120  3658.3435 6363.7812 4527.4406  4536.612 86.095459
b 120  3928.9643  6375.829 4576.0482 4585.4224  157.284



Could you share with me your test commands and the hardware info, then I 
can reproduce it on my side? Thanks.

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

Re: [Intel-gfx] [PATCH] drm/i915/display: Record the plane update times for debugging

[kernel test robot]

Hi Chris,

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.10-rc5 next-20201126]
[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/0day-ci/linux/commits/Chris-Wilson/drm-i915-display-Record-the-plane-update-times-for-debugging/20201127-052128
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-a004-20201127 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/7507dad86ddaa800a17665609a0171e9b958b451
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Chris-Wilson/drm-i915-display-Record-the-plane-update-times-for-debugging/20201127-052128
git checkout 7507dad86ddaa800a17665609a0171e9b958b451
# save the attached .config to linux build tree
make W=1 ARCH=i386 

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

All errors (new ones prefixed by >>):

   In file included from include/drm/drm_mm.h:49,
from include/drm/drm_vma_manager.h:26,
from include/drm/drm_gem.h:40,
from drivers/gpu/drm/i915/i915_drv.h:55,
from drivers/gpu/drm/i915/display/intel_sprite.c:42:
   drivers/gpu/drm/i915/display/intel_sprite.c: In function 'dbg_vblank_evade':
   include/drm/drm_print.h:450:19: error: request for member 'dev' in something 
not a structure or union
 450 |  drm_dev_dbg((drm)->dev, DRM_UT_KMS, fmt, ##__VA_ARGS__)
 |   ^~
   drivers/gpu/drm/i915/display/intel_sprite.c:201:3: note: in expansion of 
macro 'drm_dbg_kms'
 201 |   drm_dbg_kms("Atomic update on pipe (%c) took %lld us, max time 
under evasion is %u us\n",
 |   ^~~
>> drivers/gpu/drm/i915/display/intel_display.h:96:27: error: passing argument 
>> 3 of 'drm_dev_dbg' makes pointer from integer without a cast 
>> [-Werror=int-conversion]
  96 | #define pipe_name(p) ((p) + 'A')
 |  ~^~
 |   |
 |   int
   include/drm/drm_print.h:450:38: note: in definition of macro 'drm_dbg_kms'
 450 |  drm_dev_dbg((drm)->dev, DRM_UT_KMS, fmt, ##__VA_ARGS__)
 |  ^~~
   drivers/gpu/drm/i915/display/intel_sprite.c:202:8: note: in expansion of 
macro 'pipe_name'
 202 |pipe_name(crtc->pipe),
 |^
   include/drm/drm_print.h:338:16: note: expected 'const char *' but argument 
is of type 'int'
 338 |const char *format, ...);
 |^~
   cc1: all warnings being treated as errors

vim +/drm_dev_dbg +96 drivers/gpu/drm/i915/display/intel_display.h

09a28bd9e8024d drivers/gpu/drm/i915/intel_display.h Michal Wajdeczko 2017-12-21 
 95  
09a28bd9e8024d drivers/gpu/drm/i915/intel_display.h Michal Wajdeczko 2017-12-21 
@96  #define pipe_name(p) ((p) + 'A')
09a28bd9e8024d drivers/gpu/drm/i915/intel_display.h Michal Wajdeczko 2017-12-21 
 97  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/display: Record the plane update times for debugging

[kernel test robot]

Hi Chris,

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.10-rc5 next-20201126]
[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/0day-ci/linux/commits/Chris-Wilson/drm-i915-display-Record-the-plane-update-times-for-debugging/20201127-052128
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/7507dad86ddaa800a17665609a0171e9b958b451
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Chris-Wilson/drm-i915-display-Record-the-plane-update-times-for-debugging/20201127-052128
git checkout 7507dad86ddaa800a17665609a0171e9b958b451
# save the attached .config to linux build tree
make W=1 ARCH=x86_64 

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

All warnings (new ones prefixed by >>):

   In file included from include/drm/drm_mm.h:49,
from include/drm/drm_vma_manager.h:26,
from include/drm/drm_gem.h:40,
from drivers/gpu/drm/i915/i915_drv.h:55,
from drivers/gpu/drm/i915/display/intel_sprite.c:42:
   drivers/gpu/drm/i915/display/intel_sprite.c: In function 'dbg_vblank_evade':
   include/drm/drm_print.h:450:19: error: request for member 'dev' in something 
not a structure or union
 450 |  drm_dev_dbg((drm)->dev, DRM_UT_KMS, fmt, ##__VA_ARGS__)
 |   ^~
   drivers/gpu/drm/i915/display/intel_sprite.c:201:3: note: in expansion of 
macro 'drm_dbg_kms'
 201 |   drm_dbg_kms("Atomic update on pipe (%c) took %lld us, max time 
under evasion is %u us\n",
 |   ^~~
>> drivers/gpu/drm/i915/display/intel_display.h:96:27: warning: passing 
>> argument 3 of 'drm_dev_dbg' makes pointer from integer without a cast 
>> [-Wint-conversion]
  96 | #define pipe_name(p) ((p) + 'A')
 |  ~^~
 |   |
 |   int
   include/drm/drm_print.h:450:38: note: in definition of macro 'drm_dbg_kms'
 450 |  drm_dev_dbg((drm)->dev, DRM_UT_KMS, fmt, ##__VA_ARGS__)
 |  ^~~
   drivers/gpu/drm/i915/display/intel_sprite.c:202:8: note: in expansion of 
macro 'pipe_name'
 202 |pipe_name(crtc->pipe),
 |^
   include/drm/drm_print.h:338:16: note: expected 'const char *' but argument 
is of type 'int'
 338 |const char *format, ...);
 |^~

vim +/drm_dev_dbg +96 drivers/gpu/drm/i915/display/intel_display.h

09a28bd9e8024d1 drivers/gpu/drm/i915/intel_display.h Michal Wajdeczko 
2017-12-21  95  
09a28bd9e8024d1 drivers/gpu/drm/i915/intel_display.h Michal Wajdeczko 
2017-12-21 @96  #define pipe_name(p) ((p) + 'A')
09a28bd9e8024d1 drivers/gpu/drm/i915/intel_display.h Michal Wajdeczko 
2017-12-21  97  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [drm/i915/gem] 59dd13ad31: phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second -54.0% regression

[Chris Wilson]

Quoting Xing Zhengjun (2020-11-26 01:44:55)
> 
> 
> On 11/25/2020 4:47 AM, Chris Wilson wrote:
> > Quoting Oliver Sang (2020-11-19 07:20:18)
> >> On Fri, Nov 13, 2020 at 04:27:13PM +0200, Joonas Lahtinen wrote:
> >>> Hi,
> >>>
> >>> Could you add intel-gfx@lists.freedesktop.org into reports going
> >>> forward.
> >>>
> >>> Quoting kernel test robot (2020-11-11 17:58:11)
> 
>  Greeting,
> 
>  FYI, we noticed a -54.0% regression of 
>  phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second
>   due to commit:
> >>>
> >>> How many runs are there on the bad version to ensure the bisect is
> >>> repeatable?
> >>
> >> test 4 times.
> >> zxing@inn:/result/phoronix-test-suite/performance-true-Radial_Gradient_Paint-1024x1024-jxrendermark-1.2.4-ucode=0xd6-monitor=da39a3ee/lkp-cfl-d1/debian-x86_64-phoronix/x86_64-rhel-8.3/gcc-9/59dd13ad310793757e34afa489dd6fc8544fc3da$
> >>  grep -r "operations_per_second" */stats.json
> >> 0/stats.json: 
> >> "phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
> >>  4133.487932,
> >> 1/stats.json: 
> >> "phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
> >>  4120.421503,
> >> 2/stats.json: 
> >> "phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
> >>  4188.414835,
> >> 3/stats.json: 
> >> "phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
> >>  4068.549514,
> > 
> > a w/o revert (drm-tip)
> > b w/ revert
> > +mB+
> > | ..b   
> >|
> > | ..b.aa
> >|
> > | a.a   
> >|
> > | a.a   
> >|
> > |  b  b  a  
> >|
> > |   b  b  b b. a
> >|
> > |   b  bb bbb...
> >|
> > |b   ab bbab.bb.bba b a aab 
> >   a|
> > | |__A__|   
> >|
> > | |MA_| 
> >|
> > +--+
> >  NMin   MaxMedian   Avg
> > Stddev
> > a 120  3621.8761 7356.4442 4606.7895 4607.9132 
> > 156.17693
> > b 120  2664.0563 6359.9686 4519.5036 4534.4463 
> > 95.471121
> > 
> > The patch is not expected to have any impact on the machine you are testing 
> > on.
> > -Chris
> > 
> 
> What's your code base?
> For my side:
> 1) sync the code to the head of Linux mainline
> 2) git reset --hard 59dd13ad31
> 3) git revert 59dd13ad3107
> We compare the test result of commit 59dd13ad3107 (step 2) and 
> 2052847b06f8 (step 3, revert 59dd13ad3107), the regression should 
> related with 59dd13ad3107. Each test case we run 5 times.

a 59dd13ad31
b revert
+mB+
|a |
|   aa |
| .bba |
| .bbaab   |
| .b . b   b   |
|a   b.. ..bb  bb  |
|  b a   b.b.a bb  |
|aa  b..aaa..b.b..bab   b a   .|
|  |__A__| |
|  |___A_| |
+--+
NMin   MaxMedian   AvgStddev
a 120  3658.3435 6363.7812 4527.4406  4536.612 86.095459
b 120  3928.9643  6375.829 4576.0482 4585.4224  157.284
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/display: Record the plane update times for debugging

[Chris Wilson]

Since we try and estimate how long we require to update the registers to
perform a plane update, it is of vital importance that we measure the
distribution of plane updates to better guide our estimate. If we
underestimate how long it takes to perform the plane update, we may
slip into the next scanout frame causing a tear. If we overestimate, we
may unnecessarily delay the update to the next frame, causing visible
jitter.

Replace the warning that we exceed some arbitrary threshold for the
vblank update with a histogram for debugfs.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1982
Signed-off-by: Chris Wilson 
Cc: Jani Nikula 
Cc: Ville Syrjälä 
---
 .../drm/i915/display/intel_display_debugfs.c  | 48 ++
 .../drm/i915/display/intel_display_types.h|  7 +++
 drivers/gpu/drm/i915/display/intel_sprite.c   | 49 ---
 drivers/gpu/drm/i915/display/intel_sprite.h   | 10 
 4 files changed, 97 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index ca41e8c00ad7..fd1a97b9e653 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -18,6 +18,7 @@
 #include "intel_pm.h"
 #include "intel_psr.h"
 #include "intel_sideband.h"
+#include "intel_sprite.h"
 
 static inline struct drm_i915_private *node_to_i915(struct drm_info_node *node)
 {
@@ -865,6 +866,51 @@ static void intel_scaler_info(struct seq_file *m, struct 
intel_crtc *crtc)
}
 }
 
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_VBLANK_EVADE)
+static void crtc_vblank_info(struct seq_file *m, struct intel_crtc *crtc)
+{
+   char buf[ARRAY_SIZE(crtc->debug.vbl_times) + 1] = {};
+   int h, row, max;
+   u64 count;
+
+   max = 0;
+   count = 0;
+   for (h = 0; h < ARRAY_SIZE(crtc->debug.vbl_times); h++) {
+   if (crtc->debug.vbl_times[h] > max)
+   max = crtc->debug.vbl_times[h];
+   count += crtc->debug.vbl_times[h];
+   }
+   seq_printf(m, "\tUpdates: %llu\n", count);
+   if (!count)
+   return;
+
+   memset(buf, '-', sizeof(buf) - 1);
+   seq_printf(m, "\t  |%s|\n", buf);
+
+   for (row = ilog2(max) - 1; row; row--) {
+   memset(buf, ' ', sizeof(buf) - 1);
+   for (h = 0; h < ARRAY_SIZE(crtc->debug.vbl_times); h++) {
+   if (ilog2(crtc->debug.vbl_times[h]) >= row)
+   buf[h] = '*';
+   }
+   seq_printf(m, "\t  |%s|\n", buf);
+   }
+
+   memset(buf, '-', sizeof(buf) - 1);
+   seq_printf(m, "\t  |%s|\n", buf);
+   seq_printf(m, "\t1us (log)  1ms\n");
+
+   seq_printf(m, "\tMin update: %lluns\n", crtc->debug.min_vbl_time);
+   seq_printf(m, "\tMax update: %lluns\n", crtc->debug.max_vbl_time);
+   seq_printf(m, "\tAverage update: %lluns\n",
+  div64_u64(crtc->debug.sum_vbl_time,  count));
+   seq_printf(m, "\tOverruns > %uus: %lu\n",
+  VBLANK_EVASION_TIME_US, crtc->debug.over_vbl_time);
+}
+#else
+static void crtc_vblank_info(struct seq_file *m, struct intel_crtc *crtc) {}
+#endif
+
 static void intel_crtc_info(struct seq_file *m, struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -907,6 +953,8 @@ static void intel_crtc_info(struct seq_file *m, struct 
intel_crtc *crtc)
seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s\n",
   yesno(!crtc->cpu_fifo_underrun_disabled),
   yesno(!crtc->pch_fifo_underrun_disabled));
+
+   crtc_vblank_info(m, crtc);
 }
 
 static int i915_display_info(struct seq_file *m, void *unused)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ce82d654d0f2..eef3b1fa7e92 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1186,6 +1186,13 @@ struct intel_crtc {
ktime_t start_vbl_time;
int min_vbl, max_vbl;
int scanline_start;
+#ifdef CONFIG_DRM_I915_DEBUG_VBLANK_EVADE
+   u64 min_vbl_time;
+   u64 max_vbl_time;
+   u64 sum_vbl_time;
+   unsigned long over_vbl_time;
+   unsigned int vbl_times[21]; /* [1us, 1ms] */
+#endif
} debug;
 
/* scalers available on this crtc */
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 019a2d6d807a..f6e1861f3c31 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -61,14 +61,6 @@ int intel_usecs_to_scanlines(const struct drm_display_mode 
*adjusted_mode,
1000 * adjusted_mode->crtc_htotal);
 }
 
-/* FIXME: We should instead only 

[Intel-gfx] [PATCH] drm/i915/display: Record the plane update times for debugging

[Chris Wilson]

Since we try and estimate how long we require to update the registers to
perform a plane update, it is of vital importance that we measure the
distribution of plane updates to better guide our estimate. If we
underestimate how long it takes to perform the plane update, we may
slip into the next scanout frame causing a tear. If we overestimate, we
may unnecessarily delay the update to the next frame, causing visible
jitter.

Replace the warning that we exceed some arbitrary threshold for the
vblank update with a histogram for debugfs.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1982
Signed-off-by: Chris Wilson 
Cc: Jani Nikula 
Cc: Ville Syrjälä 
---
 .../drm/i915/display/intel_display_debugfs.c  | 48 +++
 .../drm/i915/display/intel_display_types.h|  7 +++
 drivers/gpu/drm/i915/display/intel_sprite.c   | 44 ++---
 drivers/gpu/drm/i915/display/intel_sprite.h   | 10 
 4 files changed, 92 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index ca41e8c00ad7..fd1a97b9e653 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -18,6 +18,7 @@
 #include "intel_pm.h"
 #include "intel_psr.h"
 #include "intel_sideband.h"
+#include "intel_sprite.h"
 
 static inline struct drm_i915_private *node_to_i915(struct drm_info_node *node)
 {
@@ -865,6 +866,51 @@ static void intel_scaler_info(struct seq_file *m, struct 
intel_crtc *crtc)
}
 }
 
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_VBLANK_EVADE)
+static void crtc_vblank_info(struct seq_file *m, struct intel_crtc *crtc)
+{
+   char buf[ARRAY_SIZE(crtc->debug.vbl_times) + 1] = {};
+   int h, row, max;
+   u64 count;
+
+   max = 0;
+   count = 0;
+   for (h = 0; h < ARRAY_SIZE(crtc->debug.vbl_times); h++) {
+   if (crtc->debug.vbl_times[h] > max)
+   max = crtc->debug.vbl_times[h];
+   count += crtc->debug.vbl_times[h];
+   }
+   seq_printf(m, "\tUpdates: %llu\n", count);
+   if (!count)
+   return;
+
+   memset(buf, '-', sizeof(buf) - 1);
+   seq_printf(m, "\t  |%s|\n", buf);
+
+   for (row = ilog2(max) - 1; row; row--) {
+   memset(buf, ' ', sizeof(buf) - 1);
+   for (h = 0; h < ARRAY_SIZE(crtc->debug.vbl_times); h++) {
+   if (ilog2(crtc->debug.vbl_times[h]) >= row)
+   buf[h] = '*';
+   }
+   seq_printf(m, "\t  |%s|\n", buf);
+   }
+
+   memset(buf, '-', sizeof(buf) - 1);
+   seq_printf(m, "\t  |%s|\n", buf);
+   seq_printf(m, "\t1us (log)  1ms\n");
+
+   seq_printf(m, "\tMin update: %lluns\n", crtc->debug.min_vbl_time);
+   seq_printf(m, "\tMax update: %lluns\n", crtc->debug.max_vbl_time);
+   seq_printf(m, "\tAverage update: %lluns\n",
+  div64_u64(crtc->debug.sum_vbl_time,  count));
+   seq_printf(m, "\tOverruns > %uus: %lu\n",
+  VBLANK_EVASION_TIME_US, crtc->debug.over_vbl_time);
+}
+#else
+static void crtc_vblank_info(struct seq_file *m, struct intel_crtc *crtc) {}
+#endif
+
 static void intel_crtc_info(struct seq_file *m, struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -907,6 +953,8 @@ static void intel_crtc_info(struct seq_file *m, struct 
intel_crtc *crtc)
seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s\n",
   yesno(!crtc->cpu_fifo_underrun_disabled),
   yesno(!crtc->pch_fifo_underrun_disabled));
+
+   crtc_vblank_info(m, crtc);
 }
 
 static int i915_display_info(struct seq_file *m, void *unused)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ce82d654d0f2..eef3b1fa7e92 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1186,6 +1186,13 @@ struct intel_crtc {
ktime_t start_vbl_time;
int min_vbl, max_vbl;
int scanline_start;
+#ifdef CONFIG_DRM_I915_DEBUG_VBLANK_EVADE
+   u64 min_vbl_time;
+   u64 max_vbl_time;
+   u64 sum_vbl_time;
+   unsigned long over_vbl_time;
+   unsigned int vbl_times[21]; /* [1us, 1ms] */
+#endif
} debug;
 
/* scalers available on this crtc */
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 019a2d6d807a..7c6d95167e56 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -61,14 +61,6 @@ int intel_usecs_to_scanlines(const struct drm_display_mode 
*adjusted_mode,
1000 * adjusted_mode->crtc_htotal);
 }
 
-/* FIXME: We should instead only 

[Intel-gfx] [v12 12/15] drm/i915/display: Implement infoframes readback for LSPCON

[Uma Shankar]

Implemented Infoframes enabled readback for LSPCON devices.
This will help align the implementation with state readback
infrastructure.

v2: Added proper bitmask of enabled infoframes as per Ville's
recommendation.

v3: Added pcon specific infoframe types instead of using the HSW
one's, as recommended by Ville.

v4: Addressed Ville's review comment by adding HDMI infoframe
versions directly instead of DIP wrappers.

v5: Re-ordered the patches to avoid potential break in usage,
as suggested by Ville.

Signed-off-by: Uma Shankar 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_lspcon.c | 57 -
 1 file changed, 55 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index 303f23d35020..7768cf34f4e9 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -560,11 +560,64 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
  buf, ret);
 }
 
+static bool _lspcon_read_avi_infoframe_enabled_mca(struct drm_dp_aux *aux)
+{
+   int ret;
+   u32 val = 0;
+   u16 reg = LSPCON_MCA_AVI_IF_CTRL;
+
+   ret = drm_dp_dpcd_read(aux, reg, , 1);
+   if (ret < 0) {
+   DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
+   return false;
+   }
+
+   return val & LSPCON_MCA_AVI_IF_KICKOFF;
+}
+
+static bool _lspcon_read_avi_infoframe_enabled_parade(struct drm_dp_aux *aux)
+{
+   int ret;
+   u32 val = 0;
+   u16 reg = LSPCON_PARADE_AVI_IF_CTRL;
+
+   ret = drm_dp_dpcd_read(aux, reg, , 1);
+   if (ret < 0) {
+   DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
+   return false;
+   }
+
+   return val & LSPCON_PARADE_AVI_IF_KICKOFF;
+}
+
 u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
  const struct intel_crtc_state *pipe_config)
 {
-   /* FIXME actually read this from the hw */
-   return 0;
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   bool infoframes_enabled;
+   u32 val = 0;
+   u32 mask, tmp;
+
+   if (lspcon->vendor == LSPCON_VENDOR_MCA)
+   infoframes_enabled = 
_lspcon_read_avi_infoframe_enabled_mca(_dp->aux);
+   else
+   infoframes_enabled = 
_lspcon_read_avi_infoframe_enabled_parade(_dp->aux);
+
+   if (infoframes_enabled)
+   val |= intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_AVI);
+
+   if (lspcon->hdr_supported) {
+   tmp = intel_de_read(dev_priv,
+   
HSW_TVIDEO_DIP_CTL(pipe_config->cpu_transcoder));
+   mask = VIDEO_DIP_ENABLE_GMP_HSW;
+
+   if (tmp & mask)
+   val |= 
intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_METADATA);
+   }
+
+   return val;
 }
 
 void lspcon_wait_pcon_mode(struct intel_lspcon *lspcon)
-- 
2.26.2

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

[Intel-gfx] [v12 04/15] drm/i915/display: Fixes quantization range for YCbCr output

[Uma Shankar]

This patch fixes the quantization range for YCbCr output on
Lspcon based devices.

v2: Re-phrased the description and added Ville's Rb.

Signed-off-by: Uma Shankar 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_lspcon.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index f98891f058da..7cb65e0f241e 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -523,12 +523,17 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
else
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
-   drm_hdmi_avi_infoframe_quant_range(,
-  conn_state->connector,
-  adjusted_mode,
-  crtc_state->limited_color_range ?
-  HDMI_QUANTIZATION_RANGE_LIMITED :
-  HDMI_QUANTIZATION_RANGE_FULL);
+   if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB) {
+   drm_hdmi_avi_infoframe_quant_range(,
+  conn_state->connector,
+  adjusted_mode,
+  
crtc_state->limited_color_range ?
+  
HDMI_QUANTIZATION_RANGE_LIMITED :
+  
HDMI_QUANTIZATION_RANGE_FULL);
+   } else {
+   frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
+   frame.avi.ycc_quantization_range = 
HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
+   }
 
ret = hdmi_infoframe_pack(, buf, sizeof(buf));
if (ret < 0) {
-- 
2.26.2

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

[Intel-gfx] [v12 13/15] drm/i915/display: Implement DRM infoframe read for LSPCON

[Uma Shankar]

Implement Read back of HDR metadata infoframes i.e Dynamic Range
and Mastering Infoframe for LSPCON devices.

v2: Added proper bitmask of enabled infoframes as per Ville's
recommendation.

v3: Dropped a redundant wrapper as per Ville's comment.

v4: Dropped a redundant print, added Ville's RB.

Signed-off-by: Uma Shankar 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_hdmi.c   | 7 +++
 drivers/gpu/drm/i915/display/intel_lspcon.c | 5 -
 drivers/gpu/drm/i915/display/intel_lspcon.h | 4 
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 88c153407a7d..e10fdb369daa 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -555,10 +555,9 @@ void hsw_write_infoframe(struct intel_encoder *encoder,
intel_de_posting_read(dev_priv, ctl_reg);
 }
 
-static void hsw_read_infoframe(struct intel_encoder *encoder,
-  const struct intel_crtc_state *crtc_state,
-  unsigned int type,
-  void *frame, ssize_t len)
+void hsw_read_infoframe(struct intel_encoder *encoder,
+   const struct intel_crtc_state *crtc_state,
+   unsigned int type, void *frame, ssize_t len)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index 7768cf34f4e9..e4ff533e3a69 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -484,7 +484,10 @@ void lspcon_read_infoframe(struct intel_encoder *encoder,
   unsigned int type,
   void *frame, ssize_t len)
 {
-   /* FIXME implement this */
+   /* FIXME implement for AVI Infoframe as well */
+   if (type == HDMI_PACKET_TYPE_GAMUT_METADATA)
+   hsw_read_infoframe(encoder, crtc_state, type,
+  frame, len);
 }
 
 void lspcon_set_infoframes(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.h 
b/drivers/gpu/drm/i915/display/intel_lspcon.h
index 44aa6bc38512..e19e10492b05 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.h
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.h
@@ -39,5 +39,9 @@ void hsw_write_infoframe(struct intel_encoder *encoder,
 const struct intel_crtc_state *crtc_state,
 unsigned int type,
 const void *frame, ssize_t len);
+void hsw_read_infoframe(struct intel_encoder *encoder,
+   const struct intel_crtc_state *crtc_state,
+   unsigned int type,
+   void *frame, ssize_t len);
 
 #endif /* __INTEL_LSPCON_H__ */
-- 
2.26.2

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

[Intel-gfx] [v12 15/15] drm/i915/display: [NOT FOR MERGE] Reduce blanking to support 4k60@10bpp for LSPCON

[Uma Shankar]

Blanking needs to be reduced to incorporate DP and HDMI timing/link
bandwidth limitations for CEA modes (4k@60 at 10 bpp). DP can drive
17.28Gbs while 4k modes (VIC97 etc) at 10 bpp required 17.8 Gbps.
This will cause mode to blank out. Reduced Htotal by shortening the
back porch and front porch within permissible limits.

Note: This is for reference for userspace, not to be merged in kernel.

v2: This is marked as Not for merge and the responsibilty to program
these custom timings will be on userspace. This patch is just for
reference purposes. This is based on Ville's recommendation.

v3: updated commit message.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0f89dbfa958a..f6f66033176b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -741,8 +741,10 @@ intel_dp_mode_valid(struct drm_connector *connector,
 {
struct intel_dp *intel_dp = 
intel_attached_dp(to_intel_connector(connector));
struct intel_connector *intel_connector = to_intel_connector(connector);
+   struct intel_encoder *intel_encoder = 
intel_attached_encoder(intel_connector);
struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
struct drm_i915_private *dev_priv = to_i915(connector->dev);
+   struct intel_lspcon *lspcon = enc_to_intel_lspcon(intel_encoder);
int target_clock = mode->clock;
int max_rate, mode_rate, max_lanes, max_link_clock;
int max_dotclk = dev_priv->max_dotclk_freq;
@@ -778,6 +780,21 @@ intel_dp_mode_valid(struct drm_connector *connector,
if (target_clock > max_dotclk)
return MODE_CLOCK_HIGH;
 
+   /*
+* Reducing Blanking to incorporate DP and HDMI timing/link bandwidth
+* limitations for CEA modes (4k@60 at 10 bpp). DP can drive 17.28Gbs
+* while 4k modes (VIC97 etc) at 10 bpp required 17.8 Gbps. This will
+* cause mode to blank out. Reduced Htotal by shortening the back porch
+* and front porch within permissible limits.
+*/
+   if (lspcon->active && lspcon->hdr_supported &&
+   mode->clock > 57) {
+   mode->clock = 57;
+   mode->htotal -= 180;
+   mode->hsync_start -= 72;
+   mode->hsync_end -= 72;
+   }
+
max_link_clock = intel_dp_max_link_rate(intel_dp);
max_lanes = intel_dp_max_lane_count(intel_dp);
 
-- 
2.26.2

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

[Intel-gfx] [v12 14/15] drm/i915/lspcon: Do not send DRM infoframes to non-HDMI sinks

[Uma Shankar]

Non-HDMI sinks shouldn't be sent Dynamic Range and Mastering infoframes.
Check for that when using LSPCON.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 48da5dc59939..07bef90e149e 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4118,6 +4118,7 @@ static void intel_enable_ddi_dp(struct intel_atomic_state 
*state,
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
enum port port = encoder->port;
 
if (port == PORT_A && INTEL_GEN(dev_priv) < 9)
@@ -4125,7 +4126,14 @@ static void intel_enable_ddi_dp(struct 
intel_atomic_state *state,
 
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state, conn_state);
-   intel_dp_set_infoframes(encoder, true, crtc_state, conn_state);
+
+   if (dig_port->lspcon.active) {
+   if (dig_port->dp.has_hdmi_sink)
+   intel_dp_set_infoframes(encoder, true, crtc_state, 
conn_state);
+   } else {
+   intel_dp_set_infoframes(encoder, true, crtc_state, conn_state);
+   }
+
intel_edp_drrs_enable(intel_dp, crtc_state);
 
if (crtc_state->has_audio)
-- 
2.26.2

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

[Intel-gfx] [v12 11/15] drm/i915/lspcon: Create separate infoframe_enabled helper

[Uma Shankar]

Lspcon has Infoframes as well as DIP for HDR metadata(DRM Infoframe).
Create a separate mechanism for lspcon compared to HDMI in order to
address the same and ensure future scalability.

v2: Streamlined this as per Ville's suggestions, making sure that
HDMI infoframe versions are directly returned instead of a redundant
and confusing DIP overhead.

Suggested-by: Ville Syrjälä 
Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_ddi.c| 10 +++---
 drivers/gpu/drm/i915/display/intel_lspcon.c |  9 +
 drivers/gpu/drm/i915/display/intel_lspcon.h |  2 ++
 3 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 92940a0c5ef8..48da5dc59939 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4583,6 +4583,7 @@ static void intel_ddi_read_func_ctl(struct intel_encoder 
*encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->uapi.crtc);
enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
+   struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
u32 temp, flags = 0;
 
temp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
@@ -4657,9 +4658,12 @@ static void intel_ddi_read_func_ctl(struct intel_encoder 
*encoder,
pipe_config->fec_enable);
}
 
-   pipe_config->infoframes.enable |=
-   intel_hdmi_infoframes_enabled(encoder, pipe_config);
-
+   if (dig_port->lspcon.active && dig_port->dp.has_hdmi_sink)
+   pipe_config->infoframes.enable |=
+   intel_lspcon_infoframes_enabled(encoder, 
pipe_config);
+   else
+   pipe_config->infoframes.enable |=
+   intel_hdmi_infoframes_enabled(encoder, 
pipe_config);
break;
case TRANS_DDI_MODE_SELECT_DP_MST:
pipe_config->output_types |= BIT(INTEL_OUTPUT_DP_MST);
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index 592c19deba00..303f23d35020 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -30,6 +30,7 @@
 #include "intel_display_types.h"
 #include "intel_dp.h"
 #include "intel_lspcon.h"
+#include "intel_hdmi.h"
 
 /* LSPCON OUI Vendor ID(signatures) */
 #define LSPCON_VENDOR_PARADE_OUI 0x001CF8
@@ -601,6 +602,14 @@ bool lspcon_init(struct intel_digital_port *dig_port)
return true;
 }
 
+u32 intel_lspcon_infoframes_enabled(struct intel_encoder *encoder,
+   const struct intel_crtc_state *pipe_config)
+{
+   struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+
+   return dig_port->infoframes_enabled(encoder, pipe_config);
+}
+
 void lspcon_resume(struct intel_digital_port *dig_port)
 {
struct intel_lspcon *lspcon = _port->lspcon;
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.h 
b/drivers/gpu/drm/i915/display/intel_lspcon.h
index 42ccb21c908f..44aa6bc38512 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.h
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.h
@@ -33,6 +33,8 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
   const struct drm_connector_state *conn_state);
 u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
  const struct intel_crtc_state *pipe_config);
+u32 intel_lspcon_infoframes_enabled(struct intel_encoder *encoder,
+   const struct intel_crtc_state *pipe_config);
 void hsw_write_infoframe(struct intel_encoder *encoder,
 const struct intel_crtc_state *crtc_state,
 unsigned int type,
-- 
2.26.2

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

[Intel-gfx] [v12 10/15] drm/i915/display: Enable HDR for Parade based lspcon

[Uma Shankar]

Enable HDR for LSPCON based on Parade along with MCA.

v2: Added a helper for status reg as suggested by Ville.

v3: Removed a redundant variable, added Ville's RB.

Signed-off-by: Uma Shankar 
Signed-off-by: Vipin Anand 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_lspcon.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index cb768a1ae4c9..592c19deba00 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -36,6 +36,7 @@
 #define LSPCON_VENDOR_MCA_OUI 0x0060AD
 
 #define DPCD_MCA_LSPCON_HDR_STATUS 0x70003
+#define DPCD_PARADE_LSPCON_HDR_STATUS  0x00511
 
 /* AUX addresses to write MCA AVI IF */
 #define LSPCON_MCA_AVI_IF_WRITE_OFFSET 0x5C0
@@ -106,6 +107,14 @@ static bool lspcon_detect_vendor(struct intel_lspcon 
*lspcon)
return true;
 }
 
+static u32 get_hdr_status_reg(struct intel_lspcon *lspcon)
+{
+   if (lspcon->vendor == LSPCON_VENDOR_MCA)
+   return DPCD_MCA_LSPCON_HDR_STATUS;
+   else
+   return DPCD_PARADE_LSPCON_HDR_STATUS;
+}
+
 void lspcon_detect_hdr_capability(struct intel_lspcon *lspcon)
 {
struct intel_digital_port *dig_port =
@@ -115,12 +124,8 @@ void lspcon_detect_hdr_capability(struct intel_lspcon 
*lspcon)
u8 hdr_caps;
int ret;
 
-   /* Enable HDR for MCA based LSPCON devices */
-   if (lspcon->vendor == LSPCON_VENDOR_MCA)
-   ret = drm_dp_dpcd_read(>aux, DPCD_MCA_LSPCON_HDR_STATUS,
-  _caps, 1);
-   else
-   return;
+   ret = drm_dp_dpcd_read(>aux, get_hdr_status_reg(lspcon),
+  _caps, 1);
 
if (ret < 0) {
drm_dbg_kms(dev, "HDR capability detection failed\n");
-- 
2.26.2

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

[Intel-gfx] [v12 09/15] drm/i915/display: Nuke bogus lspcon check

[Uma Shankar]

Dropped a irrelevant lspcon check from intel_hdmi_add_properties
function.

Suggested-by: Ville Syrjälä 
Signed-off-by: Uma Shankar 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_hdmi.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 0dcf6cd5a253..88c153407a7d 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2950,21 +2950,12 @@ static void
 intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector 
*connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->dev);
-   struct intel_digital_port *dig_port =
-   hdmi_to_dig_port(intel_hdmi);
 
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
 
-   /*
-* Attach Colorspace property for Non LSPCON based device
-* ToDo: This needs to be extended for LSPCON implementation
-* as well. Will be implemented separately.
-*/
-   if (!dig_port->lspcon.active)
-   intel_attach_hdmi_colorspace_property(connector);
-
+   intel_attach_hdmi_colorspace_property(connector);
drm_connector_attach_content_type_property(connector);
 
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
-- 
2.26.2

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

[Intel-gfx] [v12 08/15] drm/i915/display: Enable colorspace programming for LSPCON devices

[Uma Shankar]

Enable HDMI Colorspace for LSPCON based devices. Sending Colorimetry
data for HDR using AVI infoframe. LSPCON firmware expects this and though
SOC drives DP, for HDMI panel AVI infoframe is sent to the LSPCON device
which transfers the same to HDMI sink.

v2: Dropped state managed in drm core as per Jani Nikula's suggestion.

v3: Aligned colorimetry handling for lspcon as per compute_avi_infoframes,
as suggested by Ville.

v4: Finally fixed this with Ville's help, re-phrased the commit header
and description.

Credits-to: Ville Syrjälä 
Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_lspcon.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index 0a4c05d67108..cb768a1ae4c9 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -523,6 +523,9 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
else
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
+   /* Set the Colorspace as per the HDMI spec */
+   drm_hdmi_avi_infoframe_colorspace(, conn_state);
+
/* nonsense combination */
drm_WARN_ON(encoder->base.dev, crtc_state->limited_color_range &&
crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB);
-- 
2.26.2

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

[Intel-gfx] [v12 07/15] drm/i915: Split intel_attach_colorspace_property() into HDMI vs. DP variants

[Uma Shankar]

From: Ville Syrjälä 

With LSPCON we use the AVI infoframe to convey the colorimetry
information (as opposed to DP MSA/SDP), so the property we expose
should match the values we can stuff into the infoframe. Ie. we
must use the HDMI variant of the property, even though we drive
LSPCON in PCON mode. To that end just split
intel_attach_colorspace_property() into HDMI and DP variants
and let the caller worry about which one it wants to use.

Cc: Uma Shankar 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Uma Shankar 
---
 .../gpu/drm/i915/display/intel_connector.c| 29 +++
 .../gpu/drm/i915/display/intel_connector.h|  3 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |  2 +-
 4 files changed, 15 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_connector.c 
b/drivers/gpu/drm/i915/display/intel_connector.c
index 406e96785c76..d5ceb7bdc14b 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -279,24 +279,17 @@ intel_attach_aspect_ratio_property(struct drm_connector 
*connector)
 }
 
 void
-intel_attach_colorspace_property(struct drm_connector *connector)
+intel_attach_hdmi_colorspace_property(struct drm_connector *connector)
 {
-   switch (connector->connector_type) {
-   case DRM_MODE_CONNECTOR_HDMIA:
-   case DRM_MODE_CONNECTOR_HDMIB:
-   if (drm_mode_create_hdmi_colorspace_property(connector))
-   return;
-   break;
-   case DRM_MODE_CONNECTOR_DisplayPort:
-   case DRM_MODE_CONNECTOR_eDP:
-   if (drm_mode_create_dp_colorspace_property(connector))
-   return;
-   break;
-   default:
-   MISSING_CASE(connector->connector_type);
-   return;
-   }
+   if (!drm_mode_create_hdmi_colorspace_property(connector))
+   drm_object_attach_property(>base,
+  connector->colorspace_property, 0);
+}
 
-   drm_object_attach_property(>base,
-  connector->colorspace_property, 0);
+void
+intel_attach_dp_colorspace_property(struct drm_connector *connector)
+{
+   if (!drm_mode_create_dp_colorspace_property(connector))
+   drm_object_attach_property(>base,
+  connector->colorspace_property, 0);
 }
diff --git a/drivers/gpu/drm/i915/display/intel_connector.h 
b/drivers/gpu/drm/i915/display/intel_connector.h
index 93a7375c8196..661a37a3c6d8 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.h
+++ b/drivers/gpu/drm/i915/display/intel_connector.h
@@ -30,6 +30,7 @@ int intel_ddc_get_modes(struct drm_connector *c, struct 
i2c_adapter *adapter);
 void intel_attach_force_audio_property(struct drm_connector *connector);
 void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
 void intel_attach_aspect_ratio_property(struct drm_connector *connector);
-void intel_attach_colorspace_property(struct drm_connector *connector);
+void intel_attach_hdmi_colorspace_property(struct drm_connector *connector);
+void intel_attach_dp_colorspace_property(struct drm_connector *connector);
 
 #endif /* __INTEL_CONNECTOR_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index c4bbebc8c23d..0f89dbfa958a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -7194,7 +7194,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct 
drm_connector *connect
else if (INTEL_GEN(dev_priv) >= 5)
drm_connector_attach_max_bpc_property(connector, 6, 12);
 
-   intel_attach_colorspace_property(connector);
+   intel_attach_dp_colorspace_property(connector);
 
if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11)
drm_object_attach_property(>base,
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 0f2cc40cc792..0dcf6cd5a253 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2963,7 +2963,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
 * as well. Will be implemented separately.
 */
if (!dig_port->lspcon.active)
-   intel_attach_colorspace_property(connector);
+   intel_attach_hdmi_colorspace_property(connector);
 
drm_connector_attach_content_type_property(connector);
 
-- 
2.26.2

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

[Intel-gfx] [v12 05/15] drm/i915/display: Add a WARN for invalid output range and format

[Uma Shankar]

Add a WARN to rule out an invalid output range and format
combination. This is to align the lspcon code with
compute_avi_infoframes.

Signed-off-by: Uma Shankar 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_lspcon.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index 7cb65e0f241e..9552dfc55e20 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -523,6 +523,10 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
else
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
+   /* nonsense combination */
+   drm_WARN_ON(encoder->base.dev, crtc_state->limited_color_range &&
+   crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB);
+
if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB) {
drm_hdmi_avi_infoframe_quant_range(,
   conn_state->connector,
-- 
2.26.2

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

[Intel-gfx] [v12 06/15] drm/i915/display: Attach content type property for LSPCON

[Uma Shankar]

Content type is supported on HDMI sink devices. Attached the
property for the same for LSPCON based devices.

v2: Added the content type programming when we are attaching
the property to connector, as suggested by Ville.

Signed-off-by: Uma Shankar 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 1 +
 drivers/gpu/drm/i915/display/intel_lspcon.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5aaa06d73609..c4bbebc8c23d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6803,6 +6803,7 @@ intel_dp_connector_register(struct drm_connector 
*connector)
drm_object_attach_property(>base,
   
connector->dev->mode_config.hdr_output_metadata_property,
   0);
+   drm_connector_attach_content_type_property(connector);
}
 
return ret;
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index 9552dfc55e20..0a4c05d67108 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -539,6 +539,8 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
frame.avi.ycc_quantization_range = 
HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
}
 
+   drm_hdmi_avi_infoframe_content_type(, conn_state);
+
ret = hdmi_infoframe_pack(, buf, sizeof(buf));
if (ret < 0) {
DRM_ERROR("Failed to pack AVI IF\n");
-- 
2.26.2

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

[Intel-gfx] [v12 02/15] drm/i915/display: Enable HDR on gen9 devices with MCA Lspcon

[Uma Shankar]

Gen9 hardware supports HDMI2.0 through LSPCON chips.
Extending HDR support for MCA LSPCON based GEN9 devices.

SOC will drive LSPCON as DP and send HDR metadata as standard
DP SDP packets. LSPCON will be set to operate in PCON mode,
will receive the metadata and create Dynamic Range and
Mastering Infoframe (DRM packets) and send it to HDR capable
HDMI sink devices.

v2: Re-used hsw infoframe write implementation for HDR metadata
for LSPCON as per Ville's suggestion.

v3: Addressed Jani Nikula's review comments.

v4: Addressed Ville's review comments, removed redundant wrapper
and checks, passed arguments instead of hardcodings.

Signed-off-by: Uma Shankar 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_hdmi.c   |  8 +++---
 drivers/gpu/drm/i915/display/intel_lspcon.c | 31 -
 drivers/gpu/drm/i915/display/intel_lspcon.h |  4 +++
 3 files changed, 26 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 82674a8853c6..0f2cc40cc792 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -518,10 +518,10 @@ static u32 vlv_infoframes_enabled(struct intel_encoder 
*encoder,
  VIDEO_DIP_ENABLE_SPD | VIDEO_DIP_ENABLE_GCP);
 }
 
-static void hsw_write_infoframe(struct intel_encoder *encoder,
-   const struct intel_crtc_state *crtc_state,
-   unsigned int type,
-   const void *frame, ssize_t len)
+void hsw_write_infoframe(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state,
+unsigned int type,
+const void *frame, ssize_t len)
 {
const u32 *data = frame;
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index 3065727015a7..641025f00286 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -445,27 +445,32 @@ void lspcon_write_infoframe(struct intel_encoder *encoder,
unsigned int type,
const void *frame, ssize_t len)
 {
-   bool ret;
+   bool ret = true;
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
 
-   /* LSPCON only needs AVI IF */
-   if (type != HDMI_INFOFRAME_TYPE_AVI)
+   switch (type) {
+   case HDMI_INFOFRAME_TYPE_AVI:
+   if (lspcon->vendor == LSPCON_VENDOR_MCA)
+   ret = _lspcon_write_avi_infoframe_mca(_dp->aux,
+ frame, len);
+   else
+   ret = _lspcon_write_avi_infoframe_parade(_dp->aux,
+frame, len);
+   break;
+   case HDMI_PACKET_TYPE_GAMUT_METADATA:
+   drm_dbg_kms(encoder->base.dev, "Update HDR metadata for 
lspcon\n");
+   /* It uses the legacy hsw implementation for the same */
+   hsw_write_infoframe(encoder, crtc_state, type, frame, len);
+   break;
+   default:
return;
-
-   if (lspcon->vendor == LSPCON_VENDOR_MCA)
-   ret = _lspcon_write_avi_infoframe_mca(_dp->aux,
- frame, len);
-   else
-   ret = _lspcon_write_avi_infoframe_parade(_dp->aux,
-frame, len);
+   }
 
if (!ret) {
-   DRM_ERROR("Failed to write AVI infoframes\n");
+   DRM_ERROR("Failed to write infoframes\n");
return;
}
-
-   DRM_DEBUG_DRIVER("AVI infoframes updated successfully\n");
 }
 
 void lspcon_read_infoframe(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.h 
b/drivers/gpu/drm/i915/display/intel_lspcon.h
index a19b3564c635..98043ba50dd4 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.h
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.h
@@ -32,5 +32,9 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
   const struct drm_connector_state *conn_state);
 u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
  const struct intel_crtc_state *pipe_config);
+void hsw_write_infoframe(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state,
+unsigned int type,
+const void *frame, ssize_t len);
 
 #endif /* __INTEL_LSPCON_H__ */
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [v12 03/15] drm/i915/display: Attach HDR property for capable Gen9 devices

[Uma Shankar]

Attach HDR property for Gen9 devices with MCA LSPCON
chips.

v2: Cleaned HDR property attachment logic based on capability
as per Jani Nikula's suggestion.

v3: Fixed the HDR property attachment logic as per the new changes
by Kai-Feng to align with lspcon detection failure on some devices.

v4: Add HDR proprty in late_register to handle lspcon detection,
as suggested by Ville.

v5: Init Lspcon only if advertized from BIOS.

v6: Added a Todo to plan a cleanup later, added Ville's RB.

Signed-off-by: Uma Shankar 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 18 ++
 drivers/gpu/drm/i915/display/intel_lspcon.c |  2 +-
 drivers/gpu/drm/i915/display/intel_lspcon.h |  1 +
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 3896d08c4177..5aaa06d73609 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6774,6 +6774,8 @@ intel_dp_connector_register(struct drm_connector 
*connector)
 {
struct drm_i915_private *i915 = to_i915(connector->dev);
struct intel_dp *intel_dp = 
intel_attached_dp(to_intel_connector(connector));
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct intel_lspcon *lspcon = _port->lspcon;
int ret;
 
ret = intel_connector_register(connector);
@@ -6787,6 +6789,22 @@ intel_dp_connector_register(struct drm_connector 
*connector)
ret = drm_dp_aux_register(_dp->aux);
if (!ret)
drm_dp_cec_register_connector(_dp->aux, connector);
+
+   if (!intel_bios_is_lspcon_present(i915, dig_port->base.port))
+   return ret;
+
+   /*
+* ToDo: Clean this up to handle lspcon init and resume more
+* efficiently and streamlined.
+*/
+   if (lspcon_init(dig_port)) {
+   lspcon_detect_hdr_capability(lspcon);
+   if (lspcon->hdr_supported)
+   drm_object_attach_property(>base,
+  
connector->dev->mode_config.hdr_output_metadata_property,
+  0);
+   }
+
return ret;
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index 641025f00286..f98891f058da 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -552,7 +552,7 @@ void lspcon_wait_pcon_mode(struct intel_lspcon *lspcon)
lspcon_wait_mode(lspcon, DRM_LSPCON_MODE_PCON);
 }
 
-static bool lspcon_init(struct intel_digital_port *dig_port)
+bool lspcon_init(struct intel_digital_port *dig_port)
 {
struct intel_dp *dp = _port->dp;
struct intel_lspcon *lspcon = _port->lspcon;
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.h 
b/drivers/gpu/drm/i915/display/intel_lspcon.h
index 98043ba50dd4..42ccb21c908f 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.h
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.h
@@ -15,6 +15,7 @@ struct intel_digital_port;
 struct intel_encoder;
 struct intel_lspcon;
 
+bool lspcon_init(struct intel_digital_port *dig_port);
 void lspcon_detect_hdr_capability(struct intel_lspcon *lspcon);
 void lspcon_resume(struct intel_digital_port *dig_port);
 void lspcon_wait_pcon_mode(struct intel_lspcon *lspcon);
-- 
2.26.2

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

[Intel-gfx] [v12 00/15] Enable HDR on MCA LSPCON based Gen9 devices

[Uma Shankar]

Gen9 hardware supports HDMI2.0 through LSPCON chips. Extending HDR
support for MCA and Parade LSPCON based GEN9 devices.

SOC will drive LSPCON as DP and send HDR metadata as standard
DP SDP packets. LSPCON will be set to operate in PCON mode,
will receive the metadata and create Dynamic Range and
Mastering Infoframe (DRM packets) and send it to HDR capable
HDMI sink devices.

v2: Fixed Ville's review comments. Suppressed some warnings.
Patch 8 of the series is marked "Not for Merge" and is just for
reference to userspace people to incorporate in order to support
10bit content with 4K@60 resolutions.

v3: Added Infoframe readout support for DRM infoframes.
Addressed Jani Nikula's review comments.

v4: Addressed Ville's review comments and added proper bitmask for
enabled infoframes. Series also incorporates Ville's patch for stopping
infoframes to be sent to DVI sinks. Extended the same for DRM as well.

v5: Created separate helper function for lspcon_infoframes_enabled as per
Ville's suggestion.

v6: Rebase

v7: Addressed Ville's review comments.

v8: Addressed Ville's review comments. Fixed the colorspace handling for
Pcon and property attachment logic based on new lspcon detetction changes.

v9: Rebase

v10: Fixed one patch for detection

v11: Addressed Ville's review comments and added RB in the respective
patches.

v12: Addressed Ville's review comments, re-order the changes. With Ville's
help fixed the lingering colorspace handling for lspcon.

Thanks Ville for all the suggestions and inputs.
Note: Patch 15 of the series is for reference to userspace, not to be
merged to driver.

Uma Shankar (14):
  drm/i915/display: Add HDR Capability detection for LSPCON
  drm/i915/display: Enable HDR on gen9 devices with MCA Lspcon
  drm/i915/display: Attach HDR property for capable Gen9 devices
  drm/i915/display: Fixes quantization range for YCbCr output
  drm/i915/display: Add a WARN for invalid output range and format
  drm/i915/display: Attach content type property for LSPCON
  drm/i915/display: Enable colorspace programming for LSPCON devices
  drm/i915/display: Nuke bogus lspcon check
  drm/i915/display: Enable HDR for Parade based lspcon
  drm/i915/lspcon: Create separate infoframe_enabled helper
  drm/i915/display: Implement infoframes readback for LSPCON
  drm/i915/display: Implement DRM infoframe read for LSPCON
  drm/i915/lspcon: Do not send DRM infoframes to non-HDMI sinks
  drm/i915/display: [NOT FOR MERGE] Reduce blanking to support
4k60@10bpp for LSPCON

Ville Syrjälä (1):
  drm/i915: Split intel_attach_colorspace_property() into HDMI vs. DP
variants

 .../gpu/drm/i915/display/intel_connector.c|  29 ++--
 .../gpu/drm/i915/display/intel_connector.h|   3 +-
 drivers/gpu/drm/i915/display/intel_ddi.c  |  20 ++-
 .../drm/i915/display/intel_display_types.h|   1 +
 drivers/gpu/drm/i915/display/intel_dp.c   |  38 +++-
 drivers/gpu/drm/i915/display/intel_hdmi.c |  26 +--
 drivers/gpu/drm/i915/display/intel_lspcon.c   | 162 +++---
 drivers/gpu/drm/i915/display/intel_lspcon.h   |  12 ++
 8 files changed, 226 insertions(+), 65 deletions(-)

-- 
2.26.2

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

[Intel-gfx] [v12 01/15] drm/i915/display: Add HDR Capability detection for LSPCON

[Uma Shankar]

LSPCON firmware exposes HDR capability through LPCON_CAPABILITIES
DPCD register. LSPCON implementations capable of supporting
HDR set HDR_CAPABILITY bit in LSPCON_CAPABILITIES to 1. This patch
reads the same, detects the HDR capability and adds this to
intel_lspcon struct.

v2: Addressed Jani Nikula's review comment and fixed the HDR
capability detection logic

v3: Deferred HDR detection from lspcon_init (Ville)

v4: Addressed Ville's minor review comments, added his RB.

Signed-off-by: Uma Shankar 
Reviewed-by: Ville Syrjälä 
---
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_lspcon.c   | 27 +++
 drivers/gpu/drm/i915/display/intel_lspcon.h   |  1 +
 3 files changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ce82d654d0f2..5a949218dd3a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1450,6 +1450,7 @@ enum lspcon_vendor {
 
 struct intel_lspcon {
bool active;
+   bool hdr_supported;
enum drm_lspcon_mode mode;
enum lspcon_vendor vendor;
 };
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index e37d45e531df..3065727015a7 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -35,6 +35,8 @@
 #define LSPCON_VENDOR_PARADE_OUI 0x001CF8
 #define LSPCON_VENDOR_MCA_OUI 0x0060AD
 
+#define DPCD_MCA_LSPCON_HDR_STATUS 0x70003
+
 /* AUX addresses to write MCA AVI IF */
 #define LSPCON_MCA_AVI_IF_WRITE_OFFSET 0x5C0
 #define LSPCON_MCA_AVI_IF_CTRL 0x5DF
@@ -104,6 +106,31 @@ static bool lspcon_detect_vendor(struct intel_lspcon 
*lspcon)
return true;
 }
 
+void lspcon_detect_hdr_capability(struct intel_lspcon *lspcon)
+{
+   struct intel_digital_port *dig_port =
+   container_of(lspcon, struct intel_digital_port, lspcon);
+   struct drm_device *dev = dig_port->base.base.dev;
+   struct intel_dp *dp = lspcon_to_intel_dp(lspcon);
+   u8 hdr_caps;
+   int ret;
+
+   /* Enable HDR for MCA based LSPCON devices */
+   if (lspcon->vendor == LSPCON_VENDOR_MCA)
+   ret = drm_dp_dpcd_read(>aux, DPCD_MCA_LSPCON_HDR_STATUS,
+  _caps, 1);
+   else
+   return;
+
+   if (ret < 0) {
+   drm_dbg_kms(dev, "HDR capability detection failed\n");
+   lspcon->hdr_supported = false;
+   } else if (hdr_caps & 0x1) {
+   drm_dbg_kms(dev, "LSPCON capable of HDR\n");
+   lspcon->hdr_supported = true;
+   }
+}
+
 static enum drm_lspcon_mode lspcon_get_current_mode(struct intel_lspcon 
*lspcon)
 {
enum drm_lspcon_mode current_mode;
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.h 
b/drivers/gpu/drm/i915/display/intel_lspcon.h
index b03dcb7076d8..a19b3564c635 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.h
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.h
@@ -15,6 +15,7 @@ struct intel_digital_port;
 struct intel_encoder;
 struct intel_lspcon;
 
+void lspcon_detect_hdr_capability(struct intel_lspcon *lspcon);
 void lspcon_resume(struct intel_digital_port *dig_port);
 void lspcon_wait_pcon_mode(struct intel_lspcon *lspcon);
 void lspcon_write_infoframe(struct intel_encoder *encoder,
-- 
2.26.2

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

Re: [Intel-gfx] [PATCH] drm/i915: Split intel_attach_colorspace_property() into HDMI vs. DP variants

[Shankar, Uma]

> -Original Message-
> From: Ville Syrjala 
> Sent: Thursday, November 26, 2020 10:41 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma 
> Subject: [PATCH] drm/i915: Split intel_attach_colorspace_property() into HDMI
> vs. DP variants
> 
> From: Ville Syrjälä 
> 
> With LSPCON we use the AVI infoframe to convey the colorimetry information (as
> opposed to DP MSA/SDP), so the property we expose should match the values
> we can stuff into the infoframe. Ie. we must use the HDMI variant of the
> property, even though we drive LSPCON in PCON mode. To that end just split
> intel_attach_colorspace_property() into HDMI and DP variants and let the 
> caller
> worry about which one it wants to use.

Thanks Ville for this change. 
Reviewed-by: Uma Shankar 

> Cc: Uma Shankar 
> Signed-off-by: Ville Syrjälä 
> ---
>  .../gpu/drm/i915/display/intel_connector.c| 29 +++
>  .../gpu/drm/i915/display/intel_connector.h|  3 +-
>  drivers/gpu/drm/i915/display/intel_dp.c   |  2 +-
>  drivers/gpu/drm/i915/display/intel_hdmi.c |  2 +-
>  4 files changed, 15 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
> b/drivers/gpu/drm/i915/display/intel_connector.c
> index 406e96785c76..d5ceb7bdc14b 100644
> --- a/drivers/gpu/drm/i915/display/intel_connector.c
> +++ b/drivers/gpu/drm/i915/display/intel_connector.c
> @@ -279,24 +279,17 @@ intel_attach_aspect_ratio_property(struct
> drm_connector *connector)  }
> 
>  void
> -intel_attach_colorspace_property(struct drm_connector *connector)
> +intel_attach_hdmi_colorspace_property(struct drm_connector *connector)
>  {
> - switch (connector->connector_type) {
> - case DRM_MODE_CONNECTOR_HDMIA:
> - case DRM_MODE_CONNECTOR_HDMIB:
> - if (drm_mode_create_hdmi_colorspace_property(connector))
> - return;
> - break;
> - case DRM_MODE_CONNECTOR_DisplayPort:
> - case DRM_MODE_CONNECTOR_eDP:
> - if (drm_mode_create_dp_colorspace_property(connector))
> - return;
> - break;
> - default:
> - MISSING_CASE(connector->connector_type);
> - return;
> - }
> + if (!drm_mode_create_hdmi_colorspace_property(connector))
> + drm_object_attach_property(>base,
> +connector->colorspace_property, 0); }
> 
> - drm_object_attach_property(>base,
> -connector->colorspace_property, 0);
> +void
> +intel_attach_dp_colorspace_property(struct drm_connector *connector) {
> + if (!drm_mode_create_dp_colorspace_property(connector))
> + drm_object_attach_property(>base,
> +connector->colorspace_property, 0);
>  }
> diff --git a/drivers/gpu/drm/i915/display/intel_connector.h
> b/drivers/gpu/drm/i915/display/intel_connector.h
> index 93a7375c8196..661a37a3c6d8 100644
> --- a/drivers/gpu/drm/i915/display/intel_connector.h
> +++ b/drivers/gpu/drm/i915/display/intel_connector.h
> @@ -30,6 +30,7 @@ int intel_ddc_get_modes(struct drm_connector *c, struct
> i2c_adapter *adapter);  void intel_attach_force_audio_property(struct
> drm_connector *connector);  void intel_attach_broadcast_rgb_property(struct
> drm_connector *connector);  void intel_attach_aspect_ratio_property(struct
> drm_connector *connector); -void intel_attach_colorspace_property(struct
> drm_connector *connector);
> +void intel_attach_hdmi_colorspace_property(struct drm_connector
> +*connector); void intel_attach_dp_colorspace_property(struct
> +drm_connector *connector);
> 
>  #endif /* __INTEL_CONNECTOR_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 3896d08c4177..0723246f1b19 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -7175,7 +7175,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
> struct drm_connector *connect
>   else if (INTEL_GEN(dev_priv) >= 5)
>   drm_connector_attach_max_bpc_property(connector, 6, 12);
> 
> - intel_attach_colorspace_property(connector);
> + intel_attach_dp_colorspace_property(connector);
> 
>   if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11)
>   drm_object_attach_property(>base,
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 82674a8853c6..061534e71f14 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2963,7 +2963,7 @@ intel_hdmi_add_properties(struct intel_hdmi
> *intel_hdmi, struct drm_connector *c
>* as well. Will be implemented separately.
>*/
>   if (!dig_port->lspcon.active)
> - intel_attach_colorspace_property(connector);
> + intel_attach_hdmi_colorspace_property(connector);
> 
>   

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pmu: Deprecate I915_PMU_LAST and optimize state tracking

[Patchwork]

== Series Details ==

Series: drm/i915/pmu: Deprecate I915_PMU_LAST and optimize state tracking
URL   : https://patchwork.freedesktop.org/series/84305/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9395_full -> Patchwork_18991_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_whisper@basic-fds-priority-all:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/shard-iclb6/igt@gem_exec_whis...@basic-fds-priority-all.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/shard-iclb1/igt@gem_exec_whis...@basic-fds-priority-all.html

  * igt@kms_flip@flip-vs-suspend-interruptible@b-hdmi-a1:
- shard-hsw:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/shard-hsw4/igt@kms_flip@flip-vs-suspend-interrupti...@b-hdmi-a1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/shard-hsw4/igt@kms_flip@flip-vs-suspend-interrupti...@b-hdmi-a1.html

  * igt@kms_flip@flip-vs-suspend-interruptible@c-edp1:
- shard-skl:  [PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/shard-skl2/igt@kms_flip@flip-vs-suspend-interrupti...@c-edp1.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/shard-skl10/igt@kms_flip@flip-vs-suspend-interrupti...@c-edp1.html

  
New tests
-

  New tests have been introduced between CI_DRM_9395_full and 
Patchwork_18991_full:

### New CI tests (1) ###

  * boot:
- Statuses : 200 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-skl:  [PASS][7] -> [INCOMPLETE][8] ([i915#198]) +2 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/shard-skl10/igt@gem_ctx_isolation@preservation...@vcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/shard-skl6/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_workarounds@suspend-resume-fd:
- shard-apl:  [PASS][9] -> [INCOMPLETE][10] ([i915#2405])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/shard-apl1/igt@gem_workarou...@suspend-resume-fd.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/shard-apl6/igt@gem_workarou...@suspend-resume-fd.html

  * igt@kms_cursor_crc@pipe-c-cursor-64x21-offscreen:
- shard-skl:  [PASS][11] -> [FAIL][12] ([i915#54]) +2 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/shard-skl1/igt@kms_cursor_...@pipe-c-cursor-64x21-offscreen.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/shard-skl1/igt@kms_cursor_...@pipe-c-cursor-64x21-offscreen.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk:  [PASS][13] -> [FAIL][14] ([i915#72])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/shard-glk1/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/shard-glk8/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html

  * igt@kms_cursor_legacy@cursor-vs-flip-legacy:
- shard-skl:  [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +2 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/shard-skl3/igt@kms_cursor_leg...@cursor-vs-flip-legacy.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/shard-skl6/igt@kms_cursor_leg...@cursor-vs-flip-legacy.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-skl:  [PASS][17] -> [FAIL][18] ([i915#2346])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/shard-skl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/shard-skl5/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html

  * igt@kms_cursor_legacy@flip-vs-cursor-crc-legacy:
- shard-tglb: [PASS][19] -> [FAIL][20] ([i915#2346])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/shard-tglb7/igt@kms_cursor_leg...@flip-vs-cursor-crc-legacy.html
   [20]: 

Re: [Intel-gfx] [v11 07/13] i915/display: Enable BT2020 for HDR on LSPCON devices

[Shankar, Uma]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Thursday, November 26, 2020 10:43 PM
> To: Shankar, Uma 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [v11 07/13] i915/display: Enable BT2020 for HDR on LSPCON devices
> 
> On Thu, Nov 26, 2020 at 01:44:39PM +0530, Uma Shankar wrote:
> > Enable Colorspace as BT2020 if driving HDR content.Sending Colorimetry
> > data for HDR using AVI infoframe. LSPCON firmware expects this and
> > though SOC drives DP, for HDMI panel AVI infoframe is sent to the
> > LSPCON device which transfers the same to HDMI sink.
> >
> > v2: Dropped state managed in drm core as per Jani Nikula's suggestion.
> >
> > v3: Aligned colorimetry handling for lspcon as per
> > compute_avi_infoframes, as suggested by Ville.
> >
> > v4: Added BT2020 as default for HDR. Adding the colorspace property
> > interface for pcon will be take up separately. Moved changes of
> > quantization in a separate patch as per Ville's comments.
> >
> > Signed-off-by: Uma Shankar 
> > ---
> >  drivers/gpu/drm/i915/display/intel_lspcon.c | 18 ++
> >  1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> > b/drivers/gpu/drm/i915/display/intel_lspcon.c
> > index 0a4c05d67108..f6f58a991e7a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> > +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> > @@ -481,6 +481,10 @@ void lspcon_read_infoframe(struct intel_encoder
> *encoder,
> > /* FIXME implement this */
> >  }
> >
> > +/* HDMI HDR Colorspace Spec Definitions */
> > +#define NORMAL_COLORIMETRY_MASK0x3
> > +#define EXTENDED_COLORIMETRY_MASK  0x7
> > +#define HDMI_COLORIMETRY_BT2020_YCC((3 << 0) | (6 << 2) | (0 << 5))
> >  void lspcon_set_infoframes(struct intel_encoder *encoder,
> >bool enable,
> >const struct intel_crtc_state *crtc_state, @@ -523,6
> +527,20 @@
> > void lspcon_set_infoframes(struct intel_encoder *encoder,
> > else
> > frame.avi.colorspace = HDMI_COLORSPACE_RGB;
> >
> > +   /*
> > +* Set BT2020 colorspace if driving HDR data
> > +* ToDo: Make this generic and expose all colorspaces for
> > +* lspcon. We need to expose HDMI colorspaces when we detect
> > +* lspcon, this has to happen after connector is registered,
> > +* so need to fix this appropriately
> > +*/
> > +   if (lspcon->active && conn_state->hdr_output_metadata) {
> > +   frame.avi.colorimetry = HDMI_COLORIMETRY_BT2020_YCC &
> > +   NORMAL_COLORIMETRY_MASK;
> > +   frame.avi.extended_colorimetry =
> (HDMI_COLORIMETRY_BT2020_YCC >> 2) &
> > +
> EXTENDED_COLORIMETRY_MASK;
> > +   }
> > +
> 
> I don't understand the point of dancing around this instead of just fixing it.
> 
> There, I did half the work for you
> https://patchwork.freedesktop.org/series/84309/

Somehow was not able to think of right way to handle this.
Thanks Ville for your patience and help. I will add the patch to series and 
build
on top of it.

Regards,
Uma Shankar
> 
> > /* nonsense combination */
> > drm_WARN_ON(encoder->base.dev, crtc_state->limited_color_range &&
> > crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB);
> > --
> > 2.26.2
> 
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v11 09/13] drm/i915/display: Implement infoframes readback for LSPCON

[Shankar, Uma]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Thursday, November 26, 2020 11:14 PM
> To: Shankar, Uma 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [v11 09/13] drm/i915/display: Implement infoframes readback for
> LSPCON
> 
> On Thu, Nov 26, 2020 at 06:32:02PM +0200, Ville Syrjälä wrote:
> > On Thu, Nov 26, 2020 at 01:44:41PM +0530, Uma Shankar wrote:
> > > Implemented Infoframes enabled readback for LSPCON devices.
> > > This will help align the implementation with state readback
> > > infrastructure.
> > >
> > > v2: Added proper bitmask of enabled infoframes as per Ville's
> > > recommendation.
> > >
> > > v3: Added pcon specific infoframe types instead of using the HSW
> > > one's, as recommended by Ville.
> > >
> > > v4: Addressed Ville's review comment by adding HDMI infoframe
> > > versions directly instead of DIP wrappers.
> > >
> > > Signed-off-by: Uma Shankar 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_lspcon.c | 57
> > > -
> > >  1 file changed, 55 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> > > b/drivers/gpu/drm/i915/display/intel_lspcon.c
> > > index 1d3dffade168..4f3c4943e918 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> > > @@ -574,11 +574,64 @@ void lspcon_set_infoframes(struct intel_encoder
> *encoder,
> > > buf, ret);
> > >  }
> > >
> > > +static bool _lspcon_read_avi_infoframe_enabled_mca(struct
> > > +drm_dp_aux *aux) {
> > > + int ret;
> > > + u32 val = 0;
> > > + u16 reg = LSPCON_MCA_AVI_IF_CTRL;
> > > +
> > > + ret = drm_dp_dpcd_read(aux, reg, , 1);
> > > + if (ret < 0) {
> > > + DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
> > > + return false;
> > > + }
> > > +
> > > + return val & LSPCON_MCA_AVI_IF_KICKOFF; }
> > > +
> > > +static bool _lspcon_read_avi_infoframe_enabled_parade(struct
> > > +drm_dp_aux *aux) {
> > > + int ret;
> > > + u32 val = 0;
> > > + u16 reg = LSPCON_PARADE_AVI_IF_CTRL;
> > > +
> > > + ret = drm_dp_dpcd_read(aux, reg, , 1);
> > > + if (ret < 0) {
> > > + DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
> > > + return false;
> > > + }
> > > +
> > > + return val & LSPCON_PARADE_AVI_IF_KICKOFF; }
> > > +
> > >  u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
> > > const struct intel_crtc_state *pipe_config)  {
> > > - /* FIXME actually read this from the hw */
> > > - return 0;
> > > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > + struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
> > > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > > + bool infoframes_enabled;
> > > + u32 val = 0;
> > > + u32 mask, tmp;
> > > +
> > > + if (lspcon->vendor == LSPCON_VENDOR_MCA)
> > > + infoframes_enabled =
> _lspcon_read_avi_infoframe_enabled_mca(_dp->aux);
> > > + else
> > > + infoframes_enabled =
> > > +_lspcon_read_avi_infoframe_enabled_parade(_dp->aux);
> > > +
> > > + if (infoframes_enabled)
> > > + val |=
> intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_AVI);
> > > +
> > > + if (lspcon->hdr_supported) {
> > > + tmp = intel_de_read(dev_priv,
> > > + HSW_TVIDEO_DIP_CTL(pipe_config-
> >cpu_transcoder));
> > > + mask = VIDEO_DIP_ENABLE_GMP_HSW;
> > > +
> > > + if (tmp & mask)
> > > + val |=
> intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_METADATA);
> > > + }
> > > +
> > > + return val;
> > >  }
> >
> > This seem broken until patch 10 which avoids the
> 
> Actually, make that patch 11

Yeah, Sure will re-order the changes.

> > remapping from DIP bits to the index. With some reordering of the
> > patches this seems good.
> >
> > Reviewed-by: Ville Syrjälä 
> > >
> > >  void lspcon_wait_pcon_mode(struct intel_lspcon *lspcon)
> > > --
> > > 2.26.2
> >
> > --
> > Ville Syrjälä
> > Intel
> 
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v11 01/13] drm/i915/display: Add HDR Capability detection for LSPCON

[Shankar, Uma]

> -Original Message-
> From: Ville Syrjälä 
> Sent: Thursday, November 26, 2020 9:56 PM
> To: Shankar, Uma 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [v11 01/13] drm/i915/display: Add HDR Capability detection for
> LSPCON
> 
> On Thu, Nov 26, 2020 at 01:44:33PM +0530, Uma Shankar wrote:
> > LSPCON firmware exposes HDR capability through LPCON_CAPABILITIES DPCD
> > register. LSPCON implementations capable of supporting HDR set
> > HDR_CAPABILITY bit in LSPCON_CAPABILITIES to 1. This patch reads the
> > same, detects the HDR capability and adds this to intel_lspcon struct.
> >
> > v2: Addressed Jani Nikula's review comment and fixed the HDR
> > capability detection logic
> >
> > v3: Deferred HDR detection from lspcon_init (Ville)
> >
> > v4: Addressed Ville's minor review comments, added his RB.
> >
> > Signed-off-by: Uma Shankar 
> > Reviewed-by: Ville Syrjä 
> 
> Wrong name

Oh, somehow editor messed this up. Will fix this.

> > ---
> >  .../drm/i915/display/intel_display_types.h|  1 +
> >  drivers/gpu/drm/i915/display/intel_lspcon.c   | 27 +++
> >  drivers/gpu/drm/i915/display/intel_lspcon.h   |  1 +
> >  3 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index ce82d654d0f2..5a949218dd3a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1450,6 +1450,7 @@ enum lspcon_vendor {
> >
> >  struct intel_lspcon {
> > bool active;
> > +   bool hdr_supported;
> > enum drm_lspcon_mode mode;
> > enum lspcon_vendor vendor;
> >  };
> > diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> > b/drivers/gpu/drm/i915/display/intel_lspcon.c
> > index e37d45e531df..3065727015a7 100644
> > --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> > +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> > @@ -35,6 +35,8 @@
> >  #define LSPCON_VENDOR_PARADE_OUI 0x001CF8  #define
> > LSPCON_VENDOR_MCA_OUI 0x0060AD
> >
> > +#define DPCD_MCA_LSPCON_HDR_STATUS 0x70003
> > +
> >  /* AUX addresses to write MCA AVI IF */  #define
> > LSPCON_MCA_AVI_IF_WRITE_OFFSET 0x5C0  #define
> LSPCON_MCA_AVI_IF_CTRL
> > 0x5DF @@ -104,6 +106,31 @@ static bool lspcon_detect_vendor(struct
> > intel_lspcon *lspcon)
> > return true;
> >  }
> >
> > +void lspcon_detect_hdr_capability(struct intel_lspcon *lspcon) {
> > +   struct intel_digital_port *dig_port =
> > +   container_of(lspcon, struct intel_digital_port, lspcon);
> > +   struct drm_device *dev = dig_port->base.base.dev;
> > +   struct intel_dp *dp = lspcon_to_intel_dp(lspcon);
> > +   u8 hdr_caps;
> > +   int ret;
> > +
> > +   /* Enable HDR for MCA based LSPCON devices */
> > +   if (lspcon->vendor == LSPCON_VENDOR_MCA)
> > +   ret = drm_dp_dpcd_read(>aux,
> DPCD_MCA_LSPCON_HDR_STATUS,
> > +  _caps, 1);
> > +   else
> > +   return;
> > +
> > +   if (ret < 0) {
> > +   drm_dbg_kms(dev, "HDR capability detection failed\n");
> > +   lspcon->hdr_supported = false;
> > +   } else if (hdr_caps & 0x1) {
> > +   drm_dbg_kms(dev, "LSPCON capable of HDR\n");
> > +   lspcon->hdr_supported = true;
> > +   }
> > +}
> > +
> >  static enum drm_lspcon_mode lspcon_get_current_mode(struct
> > intel_lspcon *lspcon)  {
> > enum drm_lspcon_mode current_mode;
> > diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.h
> > b/drivers/gpu/drm/i915/display/intel_lspcon.h
> > index b03dcb7076d8..a19b3564c635 100644
> > --- a/drivers/gpu/drm/i915/display/intel_lspcon.h
> > +++ b/drivers/gpu/drm/i915/display/intel_lspcon.h
> > @@ -15,6 +15,7 @@ struct intel_digital_port;  struct intel_encoder;
> > struct intel_lspcon;
> >
> > +void lspcon_detect_hdr_capability(struct intel_lspcon *lspcon);
> >  void lspcon_resume(struct intel_digital_port *dig_port);  void
> > lspcon_wait_pcon_mode(struct intel_lspcon *lspcon);  void
> > lspcon_write_infoframe(struct intel_encoder *encoder,
> > --
> > 2.26.2
> 
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Deprecate I915_PMU_LAST and optimize state tracking

[Chris Wilson]

Quoting Tvrtko Ursulin (2020-11-26 18:58:20)
> 
> On 26/11/2020 16:56, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-11-26 16:47:03)
> >> -static unsigned int config_enabled_bit(u64 config)
> >> +static unsigned int is_tracked_config(const u64 config)
> >>   {
> >> -   if (is_engine_config(config))
> >> +   unsigned int val;
> > 
> >> +/**
> >> + * Non-engine events that we need to track enabled-disabled transition and
> >> + * current state.
> >> + */
> > 
> > I'm not understanding what is_tracked_config() actually means and how
> > that becomes config_enabled_bit().
> > 
> > These look like the non-engine ones where we interact with HW during the
> > sample.
> > 
> > How do the events we define a bit for here differ from the "untracked"
> > events?
> 
> Tracked means i915 pmu needs to track enabled/disabled transitions and 
> state.
> 
> So far frequency and rc6 needs that, due sampling timer decisions and 
> park/unpark handling respectively.
> 
> Interrupts on the contrary don't need to do any of that. We can just 
> read the count at any given time.
> 
> Is_tracked_config() for convenience returns a "bit + 1", so 0 means 
> untracked.
> 
> Every tracked event needs a slot in pmu->enabled and pmu->enable_count. 
> The rest don't. Before this patch I had too many bits/array elements 
> reserved there.

So my confusion boils down to 'enabled' in config_enabled_bit.
To me that makes it seem like it is a state, as opposed to the bit to be
used to track that state. (I feel enabled <-> tracked is quite clunky.)

config_enable_bit() is better, but I think you can just drop the
'enabled' altogether to leave

static unsigned int config_bit(u64 config)
{
if (is_engine_config(config))
return engine_config_bit(config);

if (is_tracked_config(config))
return tracked_config_bit(config);

return -1;
}

static u64 config_mask(u64 config)
{
return BIT_ULL(config_bit(config));
}

static unsigned int event_bit(struct perf_event *event)
{
return config_bit(event->attr.config);
}

unsigned int bit = event_bit(event);

Or if that is too much,
config_sample_bit()
config_sample_mask()
event_sample_bit()
?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Split intel_attach_colorspace_property() into HDMI vs. DP variants

[Patchwork]

== Series Details ==

Series: drm/i915: Split intel_attach_colorspace_property() into HDMI vs. DP 
variants
URL   : https://patchwork.freedesktop.org/series/84309/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9395 -> Patchwork_18992


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gt_timelines:
- fi-apl-guc: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-apl-guc/igt@i915_selftest@live@gt_timelines.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18992/fi-apl-guc/igt@i915_selftest@live@gt_timelines.html

  
New tests
-

  New tests have been introduced between CI_DRM_9395 and Patchwork_18992:

### New CI tests (1) ###

  * boot:
- Statuses : 40 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@i915_selftest@live@execlists:
- fi-cfl-8109u:   [PASS][7] -> [INCOMPLETE][8] ([i915#1037] / 
[i915#2089])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18992/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
- fi-icl-y:   [PASS][9] -> [INCOMPLETE][10] ([i915#1037] / 
[i915#2276])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-icl-y/igt@i915_selftest@l...@execlists.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18992/fi-icl-y/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka:  [PASS][11] -> [DMESG-FAIL][12] ([i915#541])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18992/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
- fi-bsw-kefka:   [PASS][13] -> [DMESG-FAIL][14] ([i915#2675] / 
[i915#541])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-bsw-kefka/igt@i915_selftest@live@gt_heartbeat.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18992/fi-bsw-kefka/igt@i915_selftest@live@gt_heartbeat.html

  
 Possible fixes 

  * igt@core_hotunplug@unbind-rebind:
- fi-tgl-u2:  [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18992/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html
- fi-kbl-7500u:   [DMESG-WARN][17] -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-kbl-7500u/igt@core_hotunp...@unbind-rebind.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18992/fi-kbl-7500u/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_module_load@reload:
- fi-apl-guc: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-apl-guc/igt@i915_module_l...@reload.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18992/fi-apl-guc/igt@i915_module_l...@reload.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka:   [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18992/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_selftest@live@gt_pm:
- {fi-kbl-7560u}: [DMESG-FAIL][23] ([i915#2524]) -> [PASS][24]
   [23]: 

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Deprecate I915_PMU_LAST and optimize state tracking

[Tvrtko Ursulin]

On 26/11/2020 16:56, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2020-11-26 16:47:03)

-static unsigned int config_enabled_bit(u64 config)
+static unsigned int is_tracked_config(const u64 config)
  {
-   if (is_engine_config(config))
+   unsigned int val;



+/**
+ * Non-engine events that we need to track enabled-disabled transition and
+ * current state.
+ */


I'm not understanding what is_tracked_config() actually means and how
that becomes config_enabled_bit().

These look like the non-engine ones where we interact with HW during the
sample.

How do the events we define a bit for here differ from the "untracked"
events?


Tracked means i915 pmu needs to track enabled/disabled transitions and 
state.


So far frequency and rc6 needs that, due sampling timer decisions and 
park/unpark handling respectively.


Interrupts on the contrary don't need to do any of that. We can just 
read the count at any given time.


Is_tracked_config() for convenience returns a "bit + 1", so 0 means 
untracked.


Every tracked event needs a slot in pmu->enabled and pmu->enable_count. 
The rest don't. Before this patch I had too many bits/array elements 
reserved there.


Old state in terms of bit/slot allocation was:

 0 - 15 engine samplers. (Only 3 used, 12 wasted bits/counts).
16 - 63 other counters. (Interrupts was using a slot for no purpose.)

New state:

 0 -  2 engine samplers.
 3 - 31 other counters. (Only 3 used so far, interrupts has no slot.)

It was a handy 1:1 mapping between non-engine events and bits/slots. 
Apart from wasting bits/slots, if I want to partition the u64 config 
space a bit more then 1:1 becomes a problem.


Note that engine bits/counts in top-level struct pmu are for all/any 
engine - just because a sampling timer decision is easy like that. (Set 
bit for any engine having an active sampler of a type, and respective 
enable_count incremented by each engine instance.)


Regards,

Tvrtko


+
+   switch (config) {
+   case I915_PMU_ACTUAL_FREQUENCY:
+   val =  __I915_PMU_ACTUAL_FREQUENCY_ENABLED;
+   break;
+   case I915_PMU_REQUESTED_FREQUENCY:
+   val = __I915_PMU_REQUESTED_FREQUENCY_ENABLED;
+   break;
+   case I915_PMU_RC6_RESIDENCY:
+   val = __I915_PMU_RC6_RESIDENCY_ENABLED;
+   break;
+   default:
+   return 0;
+   }
+
+   return val + 1;
+}
+
+static unsigned int config_enabled_bit(const u64 config)
+{
+   if (is_engine_config(config)) {
 return engine_config_sample(config);
-   else
-   return ENGINE_SAMPLE_BITS + (config - __I915_PMU_OTHER(0));
+   } else {
+   unsigned int bit = is_tracked_config(config);
+
+   if (bit)
+   return I915_ENGINE_SAMPLE_COUNT + bit - 1;
+   else
+   return -1;
+   }
  }

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Program mocs:63 for cache eviction on gen9 (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Program mocs:63 for cache eviction on gen9 (rev2)
URL   : https://patchwork.freedesktop.org/series/84293/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9394_full -> Patchwork_18990_full


Summary
---

  **SUCCESS**

  No regressions found.

  

New tests
-

  New tests have been introduced between CI_DRM_9394_full and 
Patchwork_18990_full:

### New CI tests (1) ###

  * boot:
- Statuses : 175 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_whisper@basic-queues-all:
- shard-glk:  [PASS][1] -> [DMESG-WARN][2] ([i915#118] / [i915#95]) 
+1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-glk9/igt@gem_exec_whis...@basic-queues-all.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/shard-glk8/igt@gem_exec_whis...@basic-queues-all.html

  * igt@gem_workarounds@suspend-resume-fd:
- shard-apl:  [PASS][3] -> [INCOMPLETE][4] ([i915#2405])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-apl8/igt@gem_workarou...@suspend-resume-fd.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/shard-apl4/igt@gem_workarou...@suspend-resume-fd.html

  * igt@kms_cursor_crc@pipe-b-cursor-256x256-rapid-movement:
- shard-snb:  [PASS][5] -> [SKIP][6] ([fdo#109271])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-snb4/igt@kms_cursor_...@pipe-b-cursor-256x256-rapid-movement.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/shard-snb4/igt@kms_cursor_...@pipe-b-cursor-256x256-rapid-movement.html

  * igt@kms_cursor_legacy@2x-flip-vs-cursor-atomic:
- shard-glk:  [PASS][7] -> [FAIL][8] ([i915#72])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-glk1/igt@kms_cursor_leg...@2x-flip-vs-cursor-atomic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/shard-glk6/igt@kms_cursor_leg...@2x-flip-vs-cursor-atomic.html

  * igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset@ab-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +1 
similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-glk5/igt@kms_flip@2x-flip-vs-dpms-off-vs-mode...@ab-hdmi-a1-hdmi-a2.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/shard-glk3/igt@kms_flip@2x-flip-vs-dpms-off-vs-mode...@ab-hdmi-a1-hdmi-a2.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-dp1:
- shard-apl:  [PASS][11] -> [FAIL][12] ([i915#79])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-apl2/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-dp1.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/shard-apl3/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-dp1.html

  * igt@kms_flip@flip-vs-suspend-interruptible@a-vga1:
- shard-snb:  [PASS][13] -> [DMESG-WARN][14] ([i915#42])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-snb7/igt@kms_flip@flip-vs-suspend-interrupti...@a-vga1.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/shard-snb5/igt@kms_flip@flip-vs-suspend-interrupti...@a-vga1.html

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-move:
- shard-iclb: [PASS][15] -> [DMESG-WARN][16] ([i915#1982])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-iclb3/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-move.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/shard-iclb7/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-move.html

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-wc:
- shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#1982])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-tglb6/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-mmap-wc.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/shard-tglb8/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-mmap-wc.html

  * igt@kms_plane_cursor@pipe-a-primary-size-256:
- shard-apl:  [PASS][19] -> [DMESG-WARN][20] ([i915#1982])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-apl6/igt@kms_plane_cur...@pipe-a-primary-size-256.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/shard-apl1/igt@kms_plane_cur...@pipe-a-primary-size-256.html

  * igt@kms_psr@psr2_cursor_mmap_cpu:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +2 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html
   [22]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Deprecate I915_PMU_LAST and optimize state tracking

[Patchwork]

== Series Details ==

Series: drm/i915/pmu: Deprecate I915_PMU_LAST and optimize state tracking
URL   : https://patchwork.freedesktop.org/series/84305/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9395 -> Patchwork_18991


Summary
---

  **SUCCESS**

  No regressions found.

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

New tests
-

  New tests have been introduced between CI_DRM_9395 and Patchwork_18991:

### New CI tests (1) ###

  * boot:
- Statuses : 39 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [PASS][1] -> [FAIL][2] ([i915#579])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-kbl-guc/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/fi-kbl-guc/igt@i915_pm_...@module-reload.html
- fi-kbl-7500u:   [PASS][3] -> [DMESG-WARN][4] ([i915#203])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-kbl-7500u/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/fi-kbl-7500u/igt@i915_pm_...@module-reload.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-u2:  [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-tgl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/fi-tgl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-icl-u2:  [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-bsw-kefka:   [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@vgem_basic@unload:
- fi-apl-guc: [PASS][11] -> [INCOMPLETE][12] ([i915#337])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-apl-guc/igt@vgem_ba...@unload.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/fi-apl-guc/igt@vgem_ba...@unload.html

  
 Possible fixes 

  * igt@core_hotunplug@unbind-rebind:
- fi-tgl-u2:  [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html
- fi-kbl-7500u:   [DMESG-WARN][15] -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-kbl-7500u/igt@core_hotunp...@unbind-rebind.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/fi-kbl-7500u/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka:   [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_selftest@live@gt_pm:
- {fi-kbl-7560u}: [DMESG-FAIL][19] ([i915#2524]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-kbl-7560u/igt@i915_selftest@live@gt_pm.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/fi-kbl-7560u/igt@i915_selftest@live@gt_pm.html

  * igt@kms_busy@basic@flip:
- fi-kbl-soraka:  [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-kbl-soraka/igt@kms_busy@ba...@flip.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/fi-kbl-soraka/igt@kms_busy@ba...@flip.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-7500u:   [DMESG-FAIL][23] ([i915#165]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9395/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18991/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900:   [DMESG-WARN][25] ([i915#1982]) -> [PASS][26]
   [25]: 

Re: [Intel-gfx] [v11 09/13] drm/i915/display: Implement infoframes readback for LSPCON

[Ville Syrjälä]

On Thu, Nov 26, 2020 at 06:32:02PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 26, 2020 at 01:44:41PM +0530, Uma Shankar wrote:
> > Implemented Infoframes enabled readback for LSPCON devices.
> > This will help align the implementation with state readback
> > infrastructure.
> > 
> > v2: Added proper bitmask of enabled infoframes as per Ville's
> > recommendation.
> > 
> > v3: Added pcon specific infoframe types instead of using the HSW
> > one's, as recommended by Ville.
> > 
> > v4: Addressed Ville's review comment by adding HDMI infoframe
> > versions directly instead of DIP wrappers.
> > 
> > Signed-off-by: Uma Shankar 
> > ---
> >  drivers/gpu/drm/i915/display/intel_lspcon.c | 57 -
> >  1 file changed, 55 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
> > b/drivers/gpu/drm/i915/display/intel_lspcon.c
> > index 1d3dffade168..4f3c4943e918 100644
> > --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> > +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> > @@ -574,11 +574,64 @@ void lspcon_set_infoframes(struct intel_encoder 
> > *encoder,
> >   buf, ret);
> >  }
> >  
> > +static bool _lspcon_read_avi_infoframe_enabled_mca(struct drm_dp_aux *aux)
> > +{
> > +   int ret;
> > +   u32 val = 0;
> > +   u16 reg = LSPCON_MCA_AVI_IF_CTRL;
> > +
> > +   ret = drm_dp_dpcd_read(aux, reg, , 1);
> > +   if (ret < 0) {
> > +   DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
> > +   return false;
> > +   }
> > +
> > +   return val & LSPCON_MCA_AVI_IF_KICKOFF;
> > +}
> > +
> > +static bool _lspcon_read_avi_infoframe_enabled_parade(struct drm_dp_aux 
> > *aux)
> > +{
> > +   int ret;
> > +   u32 val = 0;
> > +   u16 reg = LSPCON_PARADE_AVI_IF_CTRL;
> > +
> > +   ret = drm_dp_dpcd_read(aux, reg, , 1);
> > +   if (ret < 0) {
> > +   DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
> > +   return false;
> > +   }
> > +
> > +   return val & LSPCON_PARADE_AVI_IF_KICKOFF;
> > +}
> > +
> >  u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
> >   const struct intel_crtc_state *pipe_config)
> >  {
> > -   /* FIXME actually read this from the hw */
> > -   return 0;
> > +   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > +   struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
> > +   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +   bool infoframes_enabled;
> > +   u32 val = 0;
> > +   u32 mask, tmp;
> > +
> > +   if (lspcon->vendor == LSPCON_VENDOR_MCA)
> > +   infoframes_enabled = 
> > _lspcon_read_avi_infoframe_enabled_mca(_dp->aux);
> > +   else
> > +   infoframes_enabled = 
> > _lspcon_read_avi_infoframe_enabled_parade(_dp->aux);
> > +
> > +   if (infoframes_enabled)
> > +   val |= intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_AVI);
> > +
> > +   if (lspcon->hdr_supported) {
> > +   tmp = intel_de_read(dev_priv,
> > +   
> > HSW_TVIDEO_DIP_CTL(pipe_config->cpu_transcoder));
> > +   mask = VIDEO_DIP_ENABLE_GMP_HSW;
> > +
> > +   if (tmp & mask)
> > +   val |= 
> > intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_METADATA);
> > +   }
> > +
> > +   return val;
> >  }
> 
> This seem broken until patch 10 which avoids the

Actually, make that patch 11

> remapping from DIP bits to the index. With some reordering
> of the patches this seems good.
> 
> Reviewed-by: Ville Syrjälä 
> >  
> >  void lspcon_wait_pcon_mode(struct intel_lspcon *lspcon)
> > -- 
> > 2.26.2
> 
> -- 
> Ville Syrjälä
> Intel

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/5] drm/i915/gt: Decouple completed requests on unwind

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/5] drm/i915/gt: Decouple completed requests 
on unwind
URL   : https://patchwork.freedesktop.org/series/84301/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9394_full -> Patchwork_18989_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@syncobj_timeline@wait-all-snapshot:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-skl4/igt@syncobj_timel...@wait-all-snapshot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/shard-skl2/igt@syncobj_timel...@wait-all-snapshot.html

  
New tests
-

  New tests have been introduced between CI_DRM_9394_full and 
Patchwork_18989_full:

### New CI tests (1) ###

  * boot:
- Statuses : 200 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@kms:
- shard-snb:  [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-snb2/igt@gem_...@kms.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/shard-snb2/igt@gem_...@kms.html

  * igt@gem_exec_whisper@basic-queues-all:
- shard-glk:  [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-glk9/igt@gem_exec_whis...@basic-queues-all.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/shard-glk4/igt@gem_exec_whis...@basic-queues-all.html

  * igt@kms_cursor_crc@pipe-a-cursor-128x42-offscreen:
- shard-skl:  [PASS][7] -> [FAIL][8] ([i915#54])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-skl10/igt@kms_cursor_...@pipe-a-cursor-128x42-offscreen.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/shard-skl4/igt@kms_cursor_...@pipe-a-cursor-128x42-offscreen.html

  * igt@kms_cursor_legacy@2x-cursor-vs-flip-atomic:
- shard-hsw:  [PASS][9] -> [FAIL][10] ([i915#96])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-hsw2/igt@kms_cursor_leg...@2x-cursor-vs-flip-atomic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/shard-hsw1/igt@kms_cursor_leg...@2x-cursor-vs-flip-atomic.html

  * igt@kms_cursor_legacy@cursor-vs-flip-legacy:
- shard-skl:  [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-skl7/igt@kms_cursor_leg...@cursor-vs-flip-legacy.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/shard-skl9/igt@kms_cursor_leg...@cursor-vs-flip-legacy.html

  * igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset@ab-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-glk5/igt@kms_flip@2x-flip-vs-dpms-off-vs-mode...@ab-hdmi-a1-hdmi-a2.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/shard-glk2/igt@kms_flip@2x-flip-vs-dpms-off-vs-mode...@ab-hdmi-a1-hdmi-a2.html

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ac-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][15] -> [FAIL][16] ([i915#79])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-glk9/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ac-hdmi-a1-hdmi-a2.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/shard-glk4/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ac-hdmi-a1-hdmi-a2.html

  * igt@kms_flip@absolute-wf_vblank-interruptible@a-edp1:
- shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +1 
similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-tglb6/igt@kms_flip@absolute-wf_vblank-interrupti...@a-edp1.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/shard-tglb8/igt@kms_flip@absolute-wf_vblank-interrupti...@a-edp1.html

  * igt@kms_flip@flip-vs-expired-vblank@c-edp1:
- shard-skl:  [PASS][19] -> [FAIL][20] ([i915#79])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/shard-skl4/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/shard-skl10/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html

Re: [Intel-gfx] [v11 07/13] i915/display: Enable BT2020 for HDR on LSPCON devices

[Ville Syrjälä]

On Thu, Nov 26, 2020 at 01:44:39PM +0530, Uma Shankar wrote:
> Enable Colorspace as BT2020 if driving HDR content.Sending Colorimetry
> data for HDR using AVI infoframe. LSPCON firmware expects this and though
> SOC drives DP, for HDMI panel AVI infoframe is sent to the LSPCON device
> which transfers the same to HDMI sink.
> 
> v2: Dropped state managed in drm core as per Jani Nikula's suggestion.
> 
> v3: Aligned colorimetry handling for lspcon as per compute_avi_infoframes,
> as suggested by Ville.
> 
> v4: Added BT2020 as default for HDR. Adding the colorspace property
> interface for pcon will be take up separately. Moved changes of
> quantization in a separate patch as per Ville's comments.
> 
> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/i915/display/intel_lspcon.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index 0a4c05d67108..f6f58a991e7a 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -481,6 +481,10 @@ void lspcon_read_infoframe(struct intel_encoder *encoder,
>   /* FIXME implement this */
>  }
>  
> +/* HDMI HDR Colorspace Spec Definitions */
> +#define NORMAL_COLORIMETRY_MASK  0x3
> +#define EXTENDED_COLORIMETRY_MASK0x7
> +#define HDMI_COLORIMETRY_BT2020_YCC  ((3 << 0) | (6 << 2) | (0 << 5))
>  void lspcon_set_infoframes(struct intel_encoder *encoder,
>  bool enable,
>  const struct intel_crtc_state *crtc_state,
> @@ -523,6 +527,20 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
>   else
>   frame.avi.colorspace = HDMI_COLORSPACE_RGB;
>  
> + /*
> +  * Set BT2020 colorspace if driving HDR data
> +  * ToDo: Make this generic and expose all colorspaces for
> +  * lspcon. We need to expose HDMI colorspaces when we detect
> +  * lspcon, this has to happen after connector is registered,
> +  * so need to fix this appropriately
> +  */
> + if (lspcon->active && conn_state->hdr_output_metadata) {
> + frame.avi.colorimetry = HDMI_COLORIMETRY_BT2020_YCC &
> + NORMAL_COLORIMETRY_MASK;
> + frame.avi.extended_colorimetry = (HDMI_COLORIMETRY_BT2020_YCC 
> >> 2) &
> +   EXTENDED_COLORIMETRY_MASK;
> + }
> +

I don't understand the point of dancing around this instead of just
fixing it.

There, I did half the work for you
https://patchwork.freedesktop.org/series/84309/


>   /* nonsense combination */
>   drm_WARN_ON(encoder->base.dev, crtc_state->limited_color_range &&
>   crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB);
> -- 
> 2.26.2

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

[Intel-gfx] [PATCH] drm/i915: Split intel_attach_colorspace_property() into HDMI vs. DP variants

[Ville Syrjala]

From: Ville Syrjälä 

With LSPCON we use the AVI infoframe to convey the colorimetry
information (as opposed to DP MSA/SDP), so the property we expose
should match the values we can stuff into the infoframe. Ie. we
must use the HDMI variant of the property, even though we drive
LSPCON in PCON mode. To that end just split
intel_attach_colorspace_property() into HDMI and DP variants
and let the caller worry about which one it wants to use.

Cc: Uma Shankar 
Signed-off-by: Ville Syrjälä 
---
 .../gpu/drm/i915/display/intel_connector.c| 29 +++
 .../gpu/drm/i915/display/intel_connector.h|  3 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |  2 +-
 4 files changed, 15 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_connector.c 
b/drivers/gpu/drm/i915/display/intel_connector.c
index 406e96785c76..d5ceb7bdc14b 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -279,24 +279,17 @@ intel_attach_aspect_ratio_property(struct drm_connector 
*connector)
 }
 
 void
-intel_attach_colorspace_property(struct drm_connector *connector)
+intel_attach_hdmi_colorspace_property(struct drm_connector *connector)
 {
-   switch (connector->connector_type) {
-   case DRM_MODE_CONNECTOR_HDMIA:
-   case DRM_MODE_CONNECTOR_HDMIB:
-   if (drm_mode_create_hdmi_colorspace_property(connector))
-   return;
-   break;
-   case DRM_MODE_CONNECTOR_DisplayPort:
-   case DRM_MODE_CONNECTOR_eDP:
-   if (drm_mode_create_dp_colorspace_property(connector))
-   return;
-   break;
-   default:
-   MISSING_CASE(connector->connector_type);
-   return;
-   }
+   if (!drm_mode_create_hdmi_colorspace_property(connector))
+   drm_object_attach_property(>base,
+  connector->colorspace_property, 0);
+}
 
-   drm_object_attach_property(>base,
-  connector->colorspace_property, 0);
+void
+intel_attach_dp_colorspace_property(struct drm_connector *connector)
+{
+   if (!drm_mode_create_dp_colorspace_property(connector))
+   drm_object_attach_property(>base,
+  connector->colorspace_property, 0);
 }
diff --git a/drivers/gpu/drm/i915/display/intel_connector.h 
b/drivers/gpu/drm/i915/display/intel_connector.h
index 93a7375c8196..661a37a3c6d8 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.h
+++ b/drivers/gpu/drm/i915/display/intel_connector.h
@@ -30,6 +30,7 @@ int intel_ddc_get_modes(struct drm_connector *c, struct 
i2c_adapter *adapter);
 void intel_attach_force_audio_property(struct drm_connector *connector);
 void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
 void intel_attach_aspect_ratio_property(struct drm_connector *connector);
-void intel_attach_colorspace_property(struct drm_connector *connector);
+void intel_attach_hdmi_colorspace_property(struct drm_connector *connector);
+void intel_attach_dp_colorspace_property(struct drm_connector *connector);
 
 #endif /* __INTEL_CONNECTOR_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 3896d08c4177..0723246f1b19 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -7175,7 +7175,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct 
drm_connector *connect
else if (INTEL_GEN(dev_priv) >= 5)
drm_connector_attach_max_bpc_property(connector, 6, 12);
 
-   intel_attach_colorspace_property(connector);
+   intel_attach_dp_colorspace_property(connector);
 
if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11)
drm_object_attach_property(>base,
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 82674a8853c6..061534e71f14 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2963,7 +2963,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
 * as well. Will be implemented separately.
 */
if (!dig_port->lspcon.active)
-   intel_attach_colorspace_property(connector);
+   intel_attach_hdmi_colorspace_property(connector);
 
drm_connector_attach_content_type_property(connector);
 
-- 
2.26.2

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

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Deprecate I915_PMU_LAST and optimize state tracking

[Chris Wilson]

Quoting Tvrtko Ursulin (2020-11-26 16:47:03)
> -static unsigned int config_enabled_bit(u64 config)
> +static unsigned int is_tracked_config(const u64 config)
>  {
> -   if (is_engine_config(config))
> +   unsigned int val;

> +/**
> + * Non-engine events that we need to track enabled-disabled transition and
> + * current state.
> + */

I'm not understanding what is_tracked_config() actually means and how
that becomes config_enabled_bit().

These look like the non-engine ones where we interact with HW during the
sample.

How do the events we define a bit for here differ from the "untracked"
events?

> +
> +   switch (config) {
> +   case I915_PMU_ACTUAL_FREQUENCY:
> +   val =  __I915_PMU_ACTUAL_FREQUENCY_ENABLED;
> +   break;
> +   case I915_PMU_REQUESTED_FREQUENCY:
> +   val = __I915_PMU_REQUESTED_FREQUENCY_ENABLED;
> +   break;
> +   case I915_PMU_RC6_RESIDENCY:
> +   val = __I915_PMU_RC6_RESIDENCY_ENABLED;
> +   break;
> +   default:
> +   return 0;
> +   }
> +
> +   return val + 1;
> +}
> +
> +static unsigned int config_enabled_bit(const u64 config)
> +{
> +   if (is_engine_config(config)) {
> return engine_config_sample(config);
> -   else
> -   return ENGINE_SAMPLE_BITS + (config - __I915_PMU_OTHER(0));
> +   } else {
> +   unsigned int bit = is_tracked_config(config);
> +
> +   if (bit)
> +   return I915_ENGINE_SAMPLE_COUNT + bit - 1;
> +   else
> +   return -1;
> +   }
>  }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang

[Karol Herbst]

On Thu, Nov 26, 2020 at 4:28 PM Geert Uytterhoeven  wrote:
>
> Hi Miguel,
>
> On Thu, Nov 26, 2020 at 3:54 PM Miguel Ojeda
>  wrote:
> > On Wed, Nov 25, 2020 at 11:44 PM Edward Cree  wrote:
> > > To make the intent clear, you have to first be certain that you
> > >  understand the intent; otherwise by adding either a break or a
> > >  fallthrough to suppress the warning you are just destroying the
> > >  information that "the intent of this code is unknown".
> >
> > If you don't know what the intent of your own code is, then you
> > *already* have a problem in your hands.
>
> The maintainer is not necessarily the owner/author of the code, and
> thus may not know the intent of the code.
>
> > > or does it flag up code
> > >  that can be mindlessly "fixed" (in which case the warning is
> > >  worthless)?  Proponents in this thread seem to be trying to
> > >  have it both ways.
> >
> > A warning is not worthless just because you can mindlessly fix it.
> > There are many counterexamples, e.g. many
> > checkpatch/lint/lang-format/indentation warnings, functional ones like
> > the `if (a = b)` warning...
>
> BTW, you cannot mindlessly fix the latter, as you cannot know if
> "(a == b)" or "((a = b))" was intended, without understanding the code
> (and the (possibly unavailable) data sheet, and the hardware, ...).
>

to allow assignments in if statements was clearly a mistake and if you
need outside information to understand the code, your code is the
issue already.

> P.S. So far I've stayed out of this thread, as I like it if the compiler
>  flags possible mistakes.  After all I was the one fixing new
>  "may be used uninitialized" warnings thrown up by gcc-4.1, until
>  (a bit later than) support for that compiler was removed...
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

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

[Intel-gfx] [PATCH] drm/i915/pmu: Deprecate I915_PMU_LAST and optimize state tracking

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Adding any kinds of "last" abi markers is usually a mistake which I
repeated when implementing the PMU because it felt convenient at the time.

This patch marks I915_PMU_LAST as deprecated and stops the internal
implementation using it for sizing the event status bitmask and array.

New way of sizing the fields is a bit less elegant, but it omits reserving
slots for tracking events we are not interested in, and as such saves some
runtime space. Adding sampling events is likely to be a special event and
the new plumbing needed will be easily detected in testing. Existing
asserts against the bitfield and array sizes are keeping the code safe.

First event which gets the new treatment in this new scheme are the
interrupts - which neither needs any tracking in i915 pmu nor needs
waking up the GPU to read it.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_pmu.c | 64 +++--
 drivers/gpu/drm/i915/i915_pmu.h | 35 --
 include/uapi/drm/i915_drm.h |  2 +-
 3 files changed, 78 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index cd786ad12be7..cd564c709115 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -27,8 +27,6 @@
 BIT(I915_SAMPLE_WAIT) | \
 BIT(I915_SAMPLE_SEMA))
 
-#define ENGINE_SAMPLE_BITS (1 << I915_PMU_SAMPLE_BITS)
-
 static cpumask_t i915_pmu_cpumask;
 static unsigned int i915_pmu_target_cpu = -1;
 
@@ -57,12 +55,39 @@ static bool is_engine_config(u64 config)
return config < __I915_PMU_OTHER(0);
 }
 
-static unsigned int config_enabled_bit(u64 config)
+static unsigned int is_tracked_config(const u64 config)
 {
-   if (is_engine_config(config))
+   unsigned int val;
+
+   switch (config) {
+   case I915_PMU_ACTUAL_FREQUENCY:
+   val =  __I915_PMU_ACTUAL_FREQUENCY_ENABLED;
+   break;
+   case I915_PMU_REQUESTED_FREQUENCY:
+   val = __I915_PMU_REQUESTED_FREQUENCY_ENABLED;
+   break;
+   case I915_PMU_RC6_RESIDENCY:
+   val = __I915_PMU_RC6_RESIDENCY_ENABLED;
+   break;
+   default:
+   return 0;
+   }
+
+   return val + 1;
+}
+
+static unsigned int config_enabled_bit(const u64 config)
+{
+   if (is_engine_config(config)) {
return engine_config_sample(config);
-   else
-   return ENGINE_SAMPLE_BITS + (config - __I915_PMU_OTHER(0));
+   } else {
+   unsigned int bit = is_tracked_config(config);
+
+   if (bit)
+   return I915_ENGINE_SAMPLE_COUNT + bit - 1;
+   else
+   return -1;
+   }
 }
 
 static u64 config_enabled_mask(u64 config)
@@ -80,10 +105,15 @@ static unsigned int event_enabled_bit(struct perf_event 
*event)
return config_enabled_bit(event->attr.config);
 }
 
+static bool event_read_needs_wakeref(const struct perf_event *event)
+{
+   return event->attr.config == I915_PMU_RC6_RESIDENCY;
+}
+
 static bool pmu_needs_timer(struct i915_pmu *pmu, bool gpu_active)
 {
struct drm_i915_private *i915 = container_of(pmu, typeof(*i915), pmu);
-   u64 enable;
+   u32 enable;
 
/*
 * Only some counters need the sampling timer.
@@ -627,12 +657,19 @@ static void i915_pmu_enable(struct perf_event *event)
 {
struct drm_i915_private *i915 =
container_of(event->pmu, typeof(*i915), pmu.base);
-   unsigned int bit = event_enabled_bit(event);
+   bool need_wakeref = event_read_needs_wakeref(event);
struct i915_pmu *pmu = >pmu;
-   intel_wakeref_t wakeref;
+   intel_wakeref_t wakeref = 0;
unsigned long flags;
+   unsigned int bit;
+
+   if (need_wakeref)
+   wakeref = intel_runtime_pm_get(>runtime_pm);
+
+   bit = event_enabled_bit(event);
+   if (bit == -1)
+   goto update;
 
-   wakeref = intel_runtime_pm_get(>runtime_pm);
spin_lock_irqsave(>lock, flags);
 
/*
@@ -684,6 +721,7 @@ static void i915_pmu_enable(struct perf_event *event)
 
spin_unlock_irqrestore(>lock, flags);
 
+update:
/*
 * Store the current counter value so we can report the correct delta
 * for all listeners. Even when the event was already enabled and has
@@ -691,7 +729,8 @@ static void i915_pmu_enable(struct perf_event *event)
 */
local64_set(>hw.prev_count, __i915_pmu_event_read(event));
 
-   intel_runtime_pm_put(>runtime_pm, wakeref);
+   if (wakeref)
+   intel_runtime_pm_put(>runtime_pm, wakeref);
 }
 
 static void i915_pmu_disable(struct perf_event *event)
@@ -702,6 +741,9 @@ static void i915_pmu_disable(struct perf_event *event)
struct i915_pmu *pmu = >pmu;
unsigned long flags;
 
+   if (bit == -1)
+   return;
+
spin_lock_irqsave(>lock, flags);

Re: [Intel-gfx] [v11 09/13] drm/i915/display: Implement infoframes readback for LSPCON

[Ville Syrjälä]

On Thu, Nov 26, 2020 at 01:44:41PM +0530, Uma Shankar wrote:
> Implemented Infoframes enabled readback for LSPCON devices.
> This will help align the implementation with state readback
> infrastructure.
> 
> v2: Added proper bitmask of enabled infoframes as per Ville's
> recommendation.
> 
> v3: Added pcon specific infoframe types instead of using the HSW
> one's, as recommended by Ville.
> 
> v4: Addressed Ville's review comment by adding HDMI infoframe
> versions directly instead of DIP wrappers.
> 
> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/i915/display/intel_lspcon.c | 57 -
>  1 file changed, 55 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index 1d3dffade168..4f3c4943e918 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -574,11 +574,64 @@ void lspcon_set_infoframes(struct intel_encoder 
> *encoder,
> buf, ret);
>  }
>  
> +static bool _lspcon_read_avi_infoframe_enabled_mca(struct drm_dp_aux *aux)
> +{
> + int ret;
> + u32 val = 0;
> + u16 reg = LSPCON_MCA_AVI_IF_CTRL;
> +
> + ret = drm_dp_dpcd_read(aux, reg, , 1);
> + if (ret < 0) {
> + DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
> + return false;
> + }
> +
> + return val & LSPCON_MCA_AVI_IF_KICKOFF;
> +}
> +
> +static bool _lspcon_read_avi_infoframe_enabled_parade(struct drm_dp_aux *aux)
> +{
> + int ret;
> + u32 val = 0;
> + u16 reg = LSPCON_PARADE_AVI_IF_CTRL;
> +
> + ret = drm_dp_dpcd_read(aux, reg, , 1);
> + if (ret < 0) {
> + DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
> + return false;
> + }
> +
> + return val & LSPCON_PARADE_AVI_IF_KICKOFF;
> +}
> +
>  u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
> const struct intel_crtc_state *pipe_config)
>  {
> - /* FIXME actually read this from the hw */
> - return 0;
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> + struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + bool infoframes_enabled;
> + u32 val = 0;
> + u32 mask, tmp;
> +
> + if (lspcon->vendor == LSPCON_VENDOR_MCA)
> + infoframes_enabled = 
> _lspcon_read_avi_infoframe_enabled_mca(_dp->aux);
> + else
> + infoframes_enabled = 
> _lspcon_read_avi_infoframe_enabled_parade(_dp->aux);
> +
> + if (infoframes_enabled)
> + val |= intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_AVI);
> +
> + if (lspcon->hdr_supported) {
> + tmp = intel_de_read(dev_priv,
> + 
> HSW_TVIDEO_DIP_CTL(pipe_config->cpu_transcoder));
> + mask = VIDEO_DIP_ENABLE_GMP_HSW;
> +
> + if (tmp & mask)
> + val |= 
> intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_METADATA);
> + }
> +
> + return val;
>  }

This seem broken until patch 10 which avoids the
remapping from DIP bits to the index. With some reordering
of the patches this seems good.

Reviewed-by: Ville Syrjälä 
>  
>  void lspcon_wait_pcon_mode(struct intel_lspcon *lspcon)
> -- 
> 2.26.2

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

Re: [Intel-gfx] [v11 05/13] drm/i915/display: Add a WARN for invalid output range and format

[Ville Syrjälä]

On Thu, Nov 26, 2020 at 01:44:37PM +0530, Uma Shankar wrote:
> Add a WARN to rule out an invalid output range and format
> combination. This is to align the lspcon code with
> compute_avi_infoframes.
> 
> Signed-off-by: Uma Shankar 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/display/intel_lspcon.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index 7cb65e0f241e..9552dfc55e20 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -523,6 +523,10 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
>   else
>   frame.avi.colorspace = HDMI_COLORSPACE_RGB;
>  
> + /* nonsense combination */
> + drm_WARN_ON(encoder->base.dev, crtc_state->limited_color_range &&
> + crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB);
> +
>   if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB) {
>   drm_hdmi_avi_infoframe_quant_range(,
>  conn_state->connector,
> -- 
> 2.26.2

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

Re: [Intel-gfx] [v11 06/13] drm/i915/display: Attach content type property for LSPCON

[Ville Syrjälä]

On Thu, Nov 26, 2020 at 01:44:38PM +0530, Uma Shankar wrote:
> Content type is supported on HDMI sink devices. Attached the
> property for the same for LSPCON based devices.
> 
> v2: Added the content type programming when we are attaching
> the property to connector, as suggested by Ville.
> 
> Signed-off-by: Uma Shankar 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 1 +
>  drivers/gpu/drm/i915/display/intel_lspcon.c | 2 ++
>  2 files changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 5aaa06d73609..c4bbebc8c23d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6803,6 +6803,7 @@ intel_dp_connector_register(struct drm_connector 
> *connector)
>   drm_object_attach_property(>base,
>  
> connector->dev->mode_config.hdr_output_metadata_property,
>  0);
> + drm_connector_attach_content_type_property(connector);
>   }
>  
>   return ret;
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index 9552dfc55e20..0a4c05d67108 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -539,6 +539,8 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
>   frame.avi.ycc_quantization_range = 
> HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
>   }
>  
> + drm_hdmi_avi_infoframe_content_type(, conn_state);
> +
>   ret = hdmi_infoframe_pack(, buf, sizeof(buf));
>   if (ret < 0) {
>   DRM_ERROR("Failed to pack AVI IF\n");
> -- 
> 2.26.2

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

Re: [Intel-gfx] [v11 04/13] drm/i915/display: Enable quantization range for HDR on LSPCON devices

[Ville Syrjälä]

On Thu, Nov 26, 2020 at 01:44:36PM +0530, Uma Shankar wrote:
> This patch handles the quantization range for Lspcon.

I would state it as "fixes quantization range for YCbCr output" or
something along those lins.

Reviewed-by: Ville Syrjälä 

> 
> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/i915/display/intel_lspcon.c | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index f98891f058da..7cb65e0f241e 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -523,12 +523,17 @@ void lspcon_set_infoframes(struct intel_encoder 
> *encoder,
>   else
>   frame.avi.colorspace = HDMI_COLORSPACE_RGB;
>  
> - drm_hdmi_avi_infoframe_quant_range(,
> -conn_state->connector,
> -adjusted_mode,
> -crtc_state->limited_color_range ?
> -HDMI_QUANTIZATION_RANGE_LIMITED :
> -HDMI_QUANTIZATION_RANGE_FULL);
> + if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB) {
> + drm_hdmi_avi_infoframe_quant_range(,
> +conn_state->connector,
> +adjusted_mode,
> +
> crtc_state->limited_color_range ?
> +
> HDMI_QUANTIZATION_RANGE_LIMITED :
> +
> HDMI_QUANTIZATION_RANGE_FULL);
> + } else {
> + frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
> + frame.avi.ycc_quantization_range = 
> HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
> + }
>  
>   ret = hdmi_infoframe_pack(, buf, sizeof(buf));
>   if (ret < 0) {
> -- 
> 2.26.2

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

Re: [Intel-gfx] [v11 01/13] drm/i915/display: Add HDR Capability detection for LSPCON

[Ville Syrjälä]

On Thu, Nov 26, 2020 at 01:44:33PM +0530, Uma Shankar wrote:
> LSPCON firmware exposes HDR capability through LPCON_CAPABILITIES
> DPCD register. LSPCON implementations capable of supporting
> HDR set HDR_CAPABILITY bit in LSPCON_CAPABILITIES to 1. This patch
> reads the same, detects the HDR capability and adds this to
> intel_lspcon struct.
> 
> v2: Addressed Jani Nikula's review comment and fixed the HDR
> capability detection logic
> 
> v3: Deferred HDR detection from lspcon_init (Ville)
> 
> v4: Addressed Ville's minor review comments, added his RB.
> 
> Signed-off-by: Uma Shankar 
> Reviewed-by: Ville Syrjä 

Wrong name

> ---
>  .../drm/i915/display/intel_display_types.h|  1 +
>  drivers/gpu/drm/i915/display/intel_lspcon.c   | 27 +++
>  drivers/gpu/drm/i915/display/intel_lspcon.h   |  1 +
>  3 files changed, 29 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index ce82d654d0f2..5a949218dd3a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1450,6 +1450,7 @@ enum lspcon_vendor {
>  
>  struct intel_lspcon {
>   bool active;
> + bool hdr_supported;
>   enum drm_lspcon_mode mode;
>   enum lspcon_vendor vendor;
>  };
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index e37d45e531df..3065727015a7 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -35,6 +35,8 @@
>  #define LSPCON_VENDOR_PARADE_OUI 0x001CF8
>  #define LSPCON_VENDOR_MCA_OUI 0x0060AD
>  
> +#define DPCD_MCA_LSPCON_HDR_STATUS   0x70003
> +
>  /* AUX addresses to write MCA AVI IF */
>  #define LSPCON_MCA_AVI_IF_WRITE_OFFSET 0x5C0
>  #define LSPCON_MCA_AVI_IF_CTRL 0x5DF
> @@ -104,6 +106,31 @@ static bool lspcon_detect_vendor(struct intel_lspcon 
> *lspcon)
>   return true;
>  }
>  
> +void lspcon_detect_hdr_capability(struct intel_lspcon *lspcon)
> +{
> + struct intel_digital_port *dig_port =
> + container_of(lspcon, struct intel_digital_port, lspcon);
> + struct drm_device *dev = dig_port->base.base.dev;
> + struct intel_dp *dp = lspcon_to_intel_dp(lspcon);
> + u8 hdr_caps;
> + int ret;
> +
> + /* Enable HDR for MCA based LSPCON devices */
> + if (lspcon->vendor == LSPCON_VENDOR_MCA)
> + ret = drm_dp_dpcd_read(>aux, DPCD_MCA_LSPCON_HDR_STATUS,
> +_caps, 1);
> + else
> + return;
> +
> + if (ret < 0) {
> + drm_dbg_kms(dev, "HDR capability detection failed\n");
> + lspcon->hdr_supported = false;
> + } else if (hdr_caps & 0x1) {
> + drm_dbg_kms(dev, "LSPCON capable of HDR\n");
> + lspcon->hdr_supported = true;
> + }
> +}
> +
>  static enum drm_lspcon_mode lspcon_get_current_mode(struct intel_lspcon 
> *lspcon)
>  {
>   enum drm_lspcon_mode current_mode;
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.h 
> b/drivers/gpu/drm/i915/display/intel_lspcon.h
> index b03dcb7076d8..a19b3564c635 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.h
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.h
> @@ -15,6 +15,7 @@ struct intel_digital_port;
>  struct intel_encoder;
>  struct intel_lspcon;
>  
> +void lspcon_detect_hdr_capability(struct intel_lspcon *lspcon);
>  void lspcon_resume(struct intel_digital_port *dig_port);
>  void lspcon_wait_pcon_mode(struct intel_lspcon *lspcon);
>  void lspcon_write_infoframe(struct intel_encoder *encoder,
> -- 
> 2.26.2

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

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tools/intel_gpu_top: Fixup imc event parsing

[Tvrtko Ursulin]

On 26/11/2020 15:48, Chris Wilson wrote:

After combining rapl_parse and imc_parse into a single pmu_parse, I left
the "energy-" prefixes used by rapl (but not imc) in place. Lift the
prefix to rapl_open() so that pmu_parse() does work for both rapl and
imc!

Reported-by: Tvrtko Ursulin 
Fixes: d0b71b967ccd ("tools/intel_gpu_top: Consolidate imc to use pmu_counter")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  tools/intel_gpu_top.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 5d42a2fad..3ff9236ed 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -151,13 +151,13 @@ static int pmu_parse(struct pmu_counter *pmu, const char 
*path, const char *str)
  
  	result &= igt_sysfs_scanf(dir, "type", "%"PRIu64, >type) == 1;
  
-	snprintf(buf, sizeof(buf) - 1, "events/energy-%s", str);

+   snprintf(buf, sizeof(buf) - 1, "events/%s", str);
result &= igt_sysfs_scanf(dir, buf, "event=%"PRIx64, >config) == 1;
  
-	snprintf(buf, sizeof(buf) - 1, "events/energy-%s.scale", str);

+   snprintf(buf, sizeof(buf) - 1, "events/%s.scale", str);
result &= igt_sysfs_scanf(dir, buf, "%lf", >scale) == 1;
  
-	snprintf(buf, sizeof(buf) - 1, "events/energy-%s.unit", str);

+   snprintf(buf, sizeof(buf) - 1, "events/%s.unit", str);
result &= igt_sysfs_scanf(dir, buf, "%127s", buf) == 1;
pmu->units = strdup(buf);
  
@@ -217,13 +217,13 @@ rapl_open(struct pmu_counter *pmu,

  static void gpu_power_open(struct pmu_counter *pmu,
   struct engines *engines)
  {
-   rapl_open(pmu, "gpu", engines);
+   rapl_open(pmu, "energy-gpu", engines);
  }
  
  static void pkg_power_open(struct pmu_counter *pmu,

   struct engines *engines)
  {
-   rapl_open(pmu, "pkg", engines);
+   rapl_open(pmu, "energy-pkg", engines);
  }
  
  static uint64_t




Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH] drm/i915/gt: Program mocs:63 for cache eviction on gen9

[Ville Syrjälä]

On Thu, Nov 26, 2020 at 02:08:41PM +, Chris Wilson wrote:
> Ville noticed that the last mocs entry is used unconditionally by the HW
> when it performs cache evictions, and noted that while the value is not
> meant to be writable by the driver, we should program it to a reasonable
> value nevertheless.
> 
> As it turns out, we can change the value of mocs:63 and the value we
> were programming into it would cause hard hangs in conjunction with
> atomic operations.
> 
> v2: Add details from bspec about how it is used by HW
> 
> Suggested-by: Ville Syrjälä 
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2707
> Fixes: 3bbaba0ceaa2 ("drm/i915: Added Programming of the MOCS")
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: Jason Ekstrand 
> Cc:  # v4.3+
> ---
>  drivers/gpu/drm/i915/gt/intel_mocs.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
> b/drivers/gpu/drm/i915/gt/intel_mocs.c
> index 254873e1646e..26cedde80476 100644
> --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> @@ -131,7 +131,19 @@ static const struct drm_i915_mocs_entry skl_mocs_table[] 
> = {
>   GEN9_MOCS_ENTRIES,
>   MOCS_ENTRY(I915_MOCS_CACHED,
>  LE_3_WB | LE_TC_2_LLC_ELLC | LE_LRUM(3),
> -L3_3_WB)
> +L3_3_WB),
> +
> + /*
> +  * mocs:63
> +  * - used by the L3 for all its evictions.
> +  *   Thus it is expected to allow LLC cacheability to enable coherent
> +  *   flows to be maintained.
> +  * - used to force L3 uncachable cycles.
> +  *   Thus it is expected to make the surce L3 uncacheable.

"surce"?

> +  */
> + MOCS_ENTRY(63,
> +LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_1_UC)
>  };
>  
>  /* NOTE: the LE_TGT_CACHE is not used on Broxton */
> -- 
> 2.20.1

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

[Intel-gfx] [PATCH i-g-t] tools/intel_gpu_top: Fixup imc event parsing

[Chris Wilson]

After combining rapl_parse and imc_parse into a single pmu_parse, I left
the "energy-" prefixes used by rapl (but not imc) in place. Lift the
prefix to rapl_open() so that pmu_parse() does work for both rapl and
imc!

Reported-by: Tvrtko Ursulin 
Fixes: d0b71b967ccd ("tools/intel_gpu_top: Consolidate imc to use pmu_counter")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 tools/intel_gpu_top.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 5d42a2fad..3ff9236ed 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -151,13 +151,13 @@ static int pmu_parse(struct pmu_counter *pmu, const char 
*path, const char *str)
 
result &= igt_sysfs_scanf(dir, "type", "%"PRIu64, >type) == 1;
 
-   snprintf(buf, sizeof(buf) - 1, "events/energy-%s", str);
+   snprintf(buf, sizeof(buf) - 1, "events/%s", str);
result &= igt_sysfs_scanf(dir, buf, "event=%"PRIx64, >config) == 1;
 
-   snprintf(buf, sizeof(buf) - 1, "events/energy-%s.scale", str);
+   snprintf(buf, sizeof(buf) - 1, "events/%s.scale", str);
result &= igt_sysfs_scanf(dir, buf, "%lf", >scale) == 1;
 
-   snprintf(buf, sizeof(buf) - 1, "events/energy-%s.unit", str);
+   snprintf(buf, sizeof(buf) - 1, "events/%s.unit", str);
result &= igt_sysfs_scanf(dir, buf, "%127s", buf) == 1;
pmu->units = strdup(buf);
 
@@ -217,13 +217,13 @@ rapl_open(struct pmu_counter *pmu,
 static void gpu_power_open(struct pmu_counter *pmu,
   struct engines *engines)
 {
-   rapl_open(pmu, "gpu", engines);
+   rapl_open(pmu, "energy-gpu", engines);
 }
 
 static void pkg_power_open(struct pmu_counter *pmu,
   struct engines *engines)
 {
-   rapl_open(pmu, "pkg", engines);
+   rapl_open(pmu, "energy-pkg", engines);
 }
 
 static uint64_t
-- 
2.29.2

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/perf: also include Gen11 in OATAILPTR workaround

[Patchwork]

== Series Details ==

Series: drm/i915/perf: also include Gen11 in OATAILPTR workaround
URL   : https://patchwork.freedesktop.org/series/84292/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9393_full -> Patchwork_18987_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gem_contexts:
- shard-skl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/shard-skl3/igt@i915_selftest@live@gem_contexts.html

  * igt@runner@aborted:
- shard-snb:  NOTRUN -> [FAIL][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/shard-snb5/igt@run...@aborted.html

  
New tests
-

  New tests have been introduced between CI_DRM_9393_full and 
Patchwork_18987_full:

### New CI tests (1) ###

  * boot:
- Statuses : 199 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_params@readonly:
- shard-snb:  [PASS][3] -> [INCOMPLETE][4] ([i915#2377])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/shard-snb6/igt@gem_exec_par...@readonly.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/shard-snb5/igt@gem_exec_par...@readonly.html

  * igt@gem_exec_whisper@basic-fds-forked:
- shard-glk:  [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/shard-glk1/igt@gem_exec_whis...@basic-fds-forked.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/shard-glk9/igt@gem_exec_whis...@basic-fds-forked.html

  * igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen:
- shard-skl:  [PASS][7] -> [FAIL][8] ([i915#54]) +3 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html

  * igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge:
- shard-glk:  [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +2 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/shard-glk8/igt@kms_cursor_edge_w...@pipe-b-128x128-top-edge.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/shard-glk3/igt@kms_cursor_edge_w...@pipe-b-128x128-top-edge.html

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
- shard-hsw:  [PASS][11] -> [FAIL][12] ([i915#96])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/shard-hsw4/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/shard-hsw8/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html

  * igt@kms_cursor_legacy@flip-vs-cursor-crc-legacy:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2346]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/shard-tglb8/igt@kms_cursor_leg...@flip-vs-cursor-crc-legacy.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/shard-tglb5/igt@kms_cursor_leg...@flip-vs-cursor-crc-legacy.html

  * igt@kms_flip@flip-vs-panning-interruptible@a-dp1:
- shard-apl:  [PASS][15] -> [DMESG-WARN][16] ([i915#1982])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/shard-apl4/igt@kms_flip@flip-vs-panning-interrupti...@a-dp1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/shard-apl3/igt@kms_flip@flip-vs-panning-interrupti...@a-dp1.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-kbl:  [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +1 
similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/shard-kbl6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/shard-kbl1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu.html

  * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-blt:
- shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/shard-tglb8/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-blt.html
   [20]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Program mocs:63 for cache eviction on gen9 (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Program mocs:63 for cache eviction on gen9 (rev2)
URL   : https://patchwork.freedesktop.org/series/84293/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9394 -> Patchwork_18990


Summary
---

  **SUCCESS**

  No regressions found.

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

New tests
-

  New tests have been introduced between CI_DRM_9394 and Patchwork_18990:

### New CI tests (1) ###

  * boot:
- Statuses : 40 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-icl-u2:  [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-icl-u2/igt@core_hotunp...@unbind-rebind.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/fi-icl-u2/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_exec_fence@nb-await@vecs0:
- fi-tgl-y:   [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-tgl-y/igt@gem_exec_fence@nb-aw...@vecs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/fi-tgl-y/igt@gem_exec_fence@nb-aw...@vecs0.html

  * igt@i915_hangman@error-state-basic:
- fi-tgl-y:   [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-tgl-y/igt@i915_hang...@error-state-basic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/fi-tgl-y/igt@i915_hang...@error-state-basic.html

  * igt@i915_module_load@reload:
- fi-byt-j1900:   [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-byt-j1900/igt@i915_module_l...@reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/fi-byt-j1900/igt@i915_module_l...@reload.html
- fi-bxt-dsi: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-bxt-dsi/igt@i915_module_l...@reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/fi-bxt-dsi/igt@i915_module_l...@reload.html

  
 Possible fixes 

  * igt@debugfs_test@read_all_entries:
- fi-tgl-y:   [DMESG-WARN][11] ([i915#402]) -> [PASS][12] +2 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-tgl-y/igt@debugfs_test@read_all_entries.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/fi-tgl-y/igt@debugfs_test@read_all_entries.html

  * igt@i915_module_load@reload:
- fi-icl-u2:  [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-icl-u2/igt@i915_module_l...@reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/fi-icl-u2/igt@i915_module_l...@reload.html
- fi-tgl-y:   [DMESG-WARN][15] ([i915#1982] / [k.org#205379]) -> 
[PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-tgl-y/igt@i915_module_l...@reload.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/fi-tgl-y/igt@i915_module_l...@reload.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka:   [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_selftest@live@execlists:
- fi-icl-y:   [INCOMPLETE][19] ([i915#1037] / [i915#2276]) -> 
[PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-icl-y/igt@i915_selftest@l...@execlists.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/fi-icl-y/igt@i915_selftest@l...@execlists.html

  * igt@kms_busy@basic@flip:
- fi-tgl-y:   [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-tgl-y/igt@kms_busy@ba...@flip.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/fi-tgl-y/igt@kms_busy@ba...@flip.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-apl-guc: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18990/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  
 Warnings 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-tgl-y:   [DMESG-WARN][25] ([i915#2411]) -> [DMESG-WARN][26] 

Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang

[Geert Uytterhoeven]

Hi Miguel,

On Thu, Nov 26, 2020 at 3:54 PM Miguel Ojeda
 wrote:
> On Wed, Nov 25, 2020 at 11:44 PM Edward Cree  wrote:
> > To make the intent clear, you have to first be certain that you
> >  understand the intent; otherwise by adding either a break or a
> >  fallthrough to suppress the warning you are just destroying the
> >  information that "the intent of this code is unknown".
>
> If you don't know what the intent of your own code is, then you
> *already* have a problem in your hands.

The maintainer is not necessarily the owner/author of the code, and
thus may not know the intent of the code.

> > or does it flag up code
> >  that can be mindlessly "fixed" (in which case the warning is
> >  worthless)?  Proponents in this thread seem to be trying to
> >  have it both ways.
>
> A warning is not worthless just because you can mindlessly fix it.
> There are many counterexamples, e.g. many
> checkpatch/lint/lang-format/indentation warnings, functional ones like
> the `if (a = b)` warning...

BTW, you cannot mindlessly fix the latter, as you cannot know if
"(a == b)" or "((a = b))" was intended, without understanding the code
(and the (possibly unavailable) data sheet, and the hardware, ...).

P.S. So far I've stayed out of this thread, as I like it if the compiler
 flags possible mistakes.  After all I was the one fixing new
 "may be used uninitialized" warnings thrown up by gcc-4.1, until
 (a bit later than) support for that compiler was removed...

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Program mocs:63 for cache eviction on gen9 (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Program mocs:63 for cache eviction on gen9 (rev2)
URL   : https://patchwork.freedesktop.org/series/84293/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
2eb485b74704 drm/i915/gt: Program mocs:63 for cache eviction on gen9
-:26: WARNING:BAD_SIGN_OFF: email address ' # v4.3+' 
might be better as 'sta...@vger.kernel.org# v4.3+'
#26: 
Cc:  # v4.3+

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


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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/5] drm/i915/gt: Decouple completed requests on unwind

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/5] drm/i915/gt: Decouple completed requests 
on unwind
URL   : https://patchwork.freedesktop.org/series/84301/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9394 -> Patchwork_18989


Summary
---

  **SUCCESS**

  No regressions found.

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

New tests
-

  New tests have been introduced between CI_DRM_9394 and Patchwork_18989:

### New CI tests (1) ###

  * boot:
- Statuses : 40 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-icl-u2:  [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) +1 similar 
issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-icl-u2/igt@core_hotunp...@unbind-rebind.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/fi-icl-u2/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-apl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-apl-guc/igt@i915_pm_...@basic-pci-d3-state.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/fi-apl-guc/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
- fi-byt-j1900:   [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-byt-j1900/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/fi-byt-j1900/igt@i915_pm_...@module-reload.html

  * igt@kms_busy@basic@flip:
- fi-kbl-soraka:  [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-kbl-soraka/igt@kms_busy@ba...@flip.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/fi-kbl-soraka/igt@kms_busy@ba...@flip.html

  * igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y:   [PASS][9] -> [DMESG-WARN][10] ([i915#402]) +1 similar 
issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html

  
 Possible fixes 

  * igt@debugfs_test@read_all_entries:
- fi-tgl-y:   [DMESG-WARN][11] ([i915#402]) -> [PASS][12] +2 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-tgl-y/igt@debugfs_test@read_all_entries.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/fi-tgl-y/igt@debugfs_test@read_all_entries.html

  * igt@i915_module_load@reload:
- fi-icl-u2:  [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-icl-u2/igt@i915_module_l...@reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/fi-icl-u2/igt@i915_module_l...@reload.html
- fi-tgl-y:   [DMESG-WARN][15] ([i915#1982] / [k.org#205379]) -> 
[PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-tgl-y/igt@i915_module_l...@reload.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/fi-tgl-y/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live@execlists:
- fi-icl-y:   [INCOMPLETE][17] ([i915#1037] / [i915#2276]) -> 
[PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-icl-y/igt@i915_selftest@l...@execlists.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/fi-icl-y/igt@i915_selftest@l...@execlists.html

  * igt@kms_busy@basic@flip:
- fi-tgl-y:   [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9394/fi-tgl-y/igt@kms_busy@ba...@flip.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18989/fi-tgl-y/igt@kms_busy@ba...@flip.html

  
  [i915#1037]: https://gitlab.freedesktop.org/drm/intel/issues/1037
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2276]: https://gitlab.freedesktop.org/drm/intel/issues/2276
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379


Participating hosts (42 -> 40)
--

  Additional (1): fi-tgl-u2 
  Missing(3): fi-ilk-m540 fi-bsw-cyan fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_9394 -> Patchwork_18989

  CI-20190529: 20190529
  CI_DRM_9394: 1c4f359416d7422f56914d6a8edb5272e3385c0e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5871: ff519fd84618558c550bec07e7cc4b2c682f86ff @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/5] drm/i915/gt: Decouple completed requests on unwind

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/5] drm/i915/gt: Decouple completed requests 
on unwind
URL   : https://patchwork.freedesktop.org/series/84301/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_reset.c:1312:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:expected void *in
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20: warning: incorrect type in 
assignment (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:expected void const *src
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46: warning: incorrect type in 
argument 2 (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:expected void *in
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20: warning: incorrect type in 
assignment (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:expected void const *src
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46: warning: incorrect type in 
argument 2 (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:expected unsigned int 
[usertype] *s
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34: warning: incorrect type in 
argument 1 (different address spaces)
+drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 
279040
+drivers/gpu/drm/i915/i915_perf.c:1447:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1501:15: warning: memset with byte count of 
16777216
+./include/linux/seqlock.h:838:24: warning: trying to copy expression type 31
+./include/linux/seqlock.h:838:24: warning: trying to copy expression type 31
+./include/linux/seqlock.h:864:16: warning: trying to copy expression type 31
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/5] drm/i915/gt: Decouple completed requests on unwind

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/5] drm/i915/gt: Decouple completed requests 
on unwind
URL   : https://patchwork.freedesktop.org/series/84301/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
61722d006160 drm/i915/gt: Decouple completed requests on unwind
347dcdf689fe drm/i915/gt: Check for a completed last request once
5d71f4a49b1d drm/i915/gt: Protect context lifetime with RCU
5cbf6ad8c103 drm/i915/gt: Split the breadcrumb spinlock between global and 
contexts
-:21: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#21: 
<4>[  416.208555] list_add corruption. prev->next should be next 
(8881951d5910), but was dead0100. (prev=8882781bb870).

total: 0 errors, 1 warnings, 0 checks, 354 lines checked
7a2445d258b4 drm/i915/gt: Move the breadcrumb to the signaler if completed upon 
cancel


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

Re: [Intel-gfx] [PATCH] drm/i915/gt: Program mocs:63 for cache eviction on gen9

[Chris Wilson]

Quoting Ville Syrjälä (2020-11-26 14:08:24)
> On Thu, Nov 26, 2020 at 10:55:39AM +, Chris Wilson wrote:
> > Ville noticed that the last mocs entry is used unconditionally by the HW
> > when it performs cache evictions, and noted that while the value is not
> > meant to be writable by the driver, we should program it to a reasonable
> > value nevertheless.
> > 
> > As it turns out, we can change the value of mocs:63 and the value we
> > were programming into it would cause hard hangs in conjunction with
> > atomic operations.
> > 
> > Suggested-by: Ville Syrjälä 
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2707
> > Fixes: 3bbaba0ceaa2 ("drm/i915: Added Programming of the MOCS")
> > Signed-off-by: Chris Wilson 
> > Cc: Ville Syrjälä 
> > Cc: Jason Ekstrand 
> > Cc:  # v4.3+
> > ---
> >  drivers/gpu/drm/i915/gt/intel_mocs.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
> > b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > index 254873e1646e..6ae512847f64 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > @@ -131,7 +131,10 @@ static const struct drm_i915_mocs_entry 
> > skl_mocs_table[] = {
> >   GEN9_MOCS_ENTRIES,
> >   MOCS_ENTRY(I915_MOCS_CACHED,
> >  LE_3_WB | LE_TC_2_LLC_ELLC | LE_LRUM(3),
> > -L3_3_WB)
> > +L3_3_WB),
> > + MOCS_ENTRY(63,
> 
> Wonder if we should give these magic MOCS entries actual names?

For a one-off entry that doesn't have a special name in the spec, seems
like overkill. I added the comments from the spec that tell us about how
the HW is using it.

That page has a lot of hidden gems about MOCS on skl. Tons of magic
we've missed out on. Ugh.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/display: Warn about types of backlight not handled

[Jani Nikula]

On Wed, 25 Nov 2020, Imre Deak  wrote:
> On Fri, Nov 20, 2020 at 11:57:48AM -0800, José Roberto de Souza wrote:
>> Right now we are only explicitly handling the backlight of types
>> INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE, INTEL_BACKLIGHT_DSI_DCS and
>> INTEL_BACKLIGHT_DISPLAY_DDI all others are being handled as
>> INTEL_BACKLIGHT_DISPLAY_DDI(south display engine PWM) but that
>> might not be the intended HW usage, so lets warn to identify those
>> systems and implement it properly if needed.
>> 
>> Cc: Imre Deak 
>> Signed-off-by: José Roberto de Souza 
>> ---
>>  drivers/gpu/drm/i915/display/intel_panel.c | 15 +++
>>  1 file changed, 15 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
>> b/drivers/gpu/drm/i915/display/intel_panel.c
>> index 9f23bac0d792..368722536462 100644
>> --- a/drivers/gpu/drm/i915/display/intel_panel.c
>> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
>> @@ -2023,6 +2023,21 @@ intel_panel_init_backlight_funcs(struct intel_panel 
>> *panel)
>>  struct intel_connector *connector =
>>  container_of(panel, struct intel_connector, panel);
>>  struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>> +enum intel_backlight_type type = dev_priv->vbt.backlight.type;
>> +
>> +if (dev_priv->params.enable_dpcd_backlight)
>> +type = INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE;

The default is -1, so this might screw up the init.

>> +
>> +drm_dbg_kms(_priv->drm,
>> +"Connector %s backlight type %u controller %u\n",
>> +connector->base.name, type,
>> +dev_priv->vbt.backlight.controller);
>> +
>> +if (type != INTEL_BACKLIGHT_DISPLAY_DDI &&
>> +type != INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
>> +type != INTEL_BACKLIGHT_DSI_DCS)
>> +drm_warn(_priv->drm, "Backlight type %i not properly 
>> handled\n",
>> + type);
>
> Not sure about the history/current state of VBT errors wrt. the
> backlight type and so this may generate a lot of bug reports without an
> actual problem. A backlight problem would be anyway visible, so
> we'd get a report and then we could just use the previous debug print
> you added. It could be added to the relevant debug print in 
> intel_panel_setup_backlight().

I think I'd settle for a debug print too.

BR,
Jani.

>
> +Jani.
>
>>  
>>  if (connector->base.connector_type == DRM_MODE_CONNECTOR_eDP &&
>>  intel_dp_aux_init_backlight_funcs(connector) == 0)
>> -- 
>> 2.29.2
>> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] [PATCH] drm/i915/gt: Program mocs:63 for cache eviction on gen9

[Chris Wilson]

Ville noticed that the last mocs entry is used unconditionally by the HW
when it performs cache evictions, and noted that while the value is not
meant to be writable by the driver, we should program it to a reasonable
value nevertheless.

As it turns out, we can change the value of mocs:63 and the value we
were programming into it would cause hard hangs in conjunction with
atomic operations.

v2: Add details from bspec about how it is used by HW

Suggested-by: Ville Syrjälä 
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2707
Fixes: 3bbaba0ceaa2 ("drm/i915: Added Programming of the MOCS")
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Jason Ekstrand 
Cc:  # v4.3+
---
 drivers/gpu/drm/i915/gt/intel_mocs.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 254873e1646e..26cedde80476 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -131,7 +131,19 @@ static const struct drm_i915_mocs_entry skl_mocs_table[] = 
{
GEN9_MOCS_ENTRIES,
MOCS_ENTRY(I915_MOCS_CACHED,
   LE_3_WB | LE_TC_2_LLC_ELLC | LE_LRUM(3),
-  L3_3_WB)
+  L3_3_WB),
+
+   /*
+* mocs:63
+* - used by the L3 for all its evictions.
+*   Thus it is expected to allow LLC cacheability to enable coherent
+*   flows to be maintained.
+* - used to force L3 uncachable cycles.
+*   Thus it is expected to make the surce L3 uncacheable.
+*/
+   MOCS_ENTRY(63,
+  LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+  L3_1_UC)
 };
 
 /* NOTE: the LE_TGT_CACHE is not used on Broxton */
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH] drm/i915/gt: Program mocs:63 for cache eviction on gen9

[Ville Syrjälä]

On Thu, Nov 26, 2020 at 10:55:39AM +, Chris Wilson wrote:
> Ville noticed that the last mocs entry is used unconditionally by the HW
> when it performs cache evictions, and noted that while the value is not
> meant to be writable by the driver, we should program it to a reasonable
> value nevertheless.
> 
> As it turns out, we can change the value of mocs:63 and the value we
> were programming into it would cause hard hangs in conjunction with
> atomic operations.
> 
> Suggested-by: Ville Syrjälä 
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2707
> Fixes: 3bbaba0ceaa2 ("drm/i915: Added Programming of the MOCS")
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: Jason Ekstrand 
> Cc:  # v4.3+
> ---
>  drivers/gpu/drm/i915/gt/intel_mocs.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
> b/drivers/gpu/drm/i915/gt/intel_mocs.c
> index 254873e1646e..6ae512847f64 100644
> --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> @@ -131,7 +131,10 @@ static const struct drm_i915_mocs_entry skl_mocs_table[] 
> = {
>   GEN9_MOCS_ENTRIES,
>   MOCS_ENTRY(I915_MOCS_CACHED,
>  LE_3_WB | LE_TC_2_LLC_ELLC | LE_LRUM(3),
> -L3_3_WB)
> +L3_3_WB),
> + MOCS_ENTRY(63,

Wonder if we should give these magic MOCS entries actual names?

Anyways, matches my reading of the spec
Reviewed-by: Ville Syrjälä 

> +LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
> +L3_1_UC)
>  };
>  
>  /* NOTE: the LE_TGT_CACHE is not used on Broxton */
> -- 
> 2.20.1

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

[Intel-gfx] [CI 1/5] drm/i915/gt: Decouple completed requests on unwind

[Chris Wilson]

Since the introduction of preempt-to-busy, requests can complete in the
background, even while they are not on the engine->active.requests list.
As such, the engine->active.request list itself is not in strict
retirement order, and we have to scan the entire list while unwinding to
not miss any. However, if the request is completed we currently leave it
on the list [until retirement], but we could just as simply remove it
and stop treating it as active. We would only have to then traverse it
once while unwinding in quick succession.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_lrc.c | 6 --
 drivers/gpu/drm/i915/i915_request.c | 3 ++-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 30aa59fb7271..cf11cbac241b 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1116,8 +1116,10 @@ __unwind_incomplete_requests(struct intel_engine_cs 
*engine)
list_for_each_entry_safe_reverse(rq, rn,
 >active.requests,
 sched.link) {
-   if (i915_request_completed(rq))
-   continue; /* XXX */
+   if (i915_request_completed(rq)) {
+   list_del_init(>sched.link);
+   continue;
+   }
 
__i915_request_unsubmit(rq);
 
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 8d7d29c9e375..a9db1376b996 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -321,7 +321,8 @@ bool i915_request_retire(struct i915_request *rq)
 * after removing the breadcrumb and signaling it, so that we do not
 * inadvertently attach the breadcrumb to a completed request.
 */
-   remove_from_engine(rq);
+   if (!list_empty(>sched.link))
+   remove_from_engine(rq);
GEM_BUG_ON(!llist_empty(>execute_cb));
 
__list_del_entry(>link); /* poison neither prev/next (RCU walks) */
-- 
2.20.1

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

[Intel-gfx] [CI 3/5] drm/i915/gt: Protect context lifetime with RCU

[Chris Wilson]

Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with the caveat that individual
structs may be reused from the freelist within an RCU grace period. To
handle that, we have to avoid clearing members of the zombie struct.

This is required for a later patch to handle locking around virtual
requests in the signaler, as those requests may want to move between
engines and be destroyed while we are holding b->irq_lock on a physical
engine.

v2: Drop mutex_reinit(), if we never mark the mutex as destroyed we
don't need to reset the debug code, at the loss of having the mutex
debug code spot us attempting to destroy a locked mutex.
v3: As the intended use will remain strongly referenced counted, with
very little inflight access across reuse, drop the ctor.
v4: Drop the unrequired change to remove the temporary reference around
dropping the active context, and add back some more missing ctor
operations.
v5: The ctor is back. Tvrtko spotted that ce->signal_lock [introduced
later] maybe accessed under RCU and so needs special care not to be
reinitialised.
v6: Don't mix SLAB_TYPESAFE_BY_RCU and RCU list iteration.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_context.c   | 12 +---
 drivers/gpu/drm/i915/gt/intel_context_types.h | 11 ++-
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 92a3f25c4006..d3a835212167 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -25,11 +25,18 @@ static struct intel_context *intel_context_alloc(void)
return kmem_cache_zalloc(global.slab_ce, GFP_KERNEL);
 }
 
-void intel_context_free(struct intel_context *ce)
+static void rcu_context_free(struct rcu_head *rcu)
 {
+   struct intel_context *ce = container_of(rcu, typeof(*ce), rcu);
+
kmem_cache_free(global.slab_ce, ce);
 }
 
+void intel_context_free(struct intel_context *ce)
+{
+   call_rcu(>rcu, rcu_context_free);
+}
+
 struct intel_context *
 intel_context_create(struct intel_engine_cs *engine)
 {
@@ -356,8 +363,7 @@ static int __intel_context_active(struct i915_active 
*active)
 }
 
 void
-intel_context_init(struct intel_context *ce,
-  struct intel_engine_cs *engine)
+intel_context_init(struct intel_context *ce, struct intel_engine_cs *engine)
 {
GEM_BUG_ON(!engine->cops);
GEM_BUG_ON(!engine->gt->vm);
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 552cb57a2e8c..20cb5835d1c3 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -44,7 +44,16 @@ struct intel_context_ops {
 };
 
 struct intel_context {
-   struct kref ref;
+   /*
+* Note: Some fields may be accessed under RCU.
+*
+* Unless otherwise noted a field can safely be assumed to be protected
+* by strong reference counting.
+*/
+   union {
+   struct kref ref; /* no kref_get_unless_zero()! */
+   struct rcu_head rcu;
+   };
 
struct intel_engine_cs *engine;
struct intel_engine_cs *inflight;
-- 
2.20.1

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

[Intel-gfx] [CI 5/5] drm/i915/gt: Move the breadcrumb to the signaler if completed upon cancel

[Chris Wilson]

If while we are cancelling the breadcrumb signaling, we find that the
request is already completed, move it to the irq signaler and let it be
signaled.

v2: Tweak reference counting so that we only acquire a new reference on
adding to a signal list, as opposed to a hidden i915_request_put of the
caller's reference.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 41 +++--
 1 file changed, 22 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index a24cc1ff08a0..00918300f53f 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -192,18 +192,6 @@ static void add_retire(struct intel_breadcrumbs *b, struct 
intel_timeline *tl)
intel_engine_add_retire(b->irq_engine, tl);
 }
 
-static bool __signal_request(struct i915_request *rq)
-{
-   GEM_BUG_ON(test_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags));
-
-   if (!__dma_fence_signal(>fence)) {
-   i915_request_put(rq);
-   return false;
-   }
-
-   return true;
-}
-
 static struct llist_node *
 slist_add(struct llist_node *node, struct llist_node *head)
 {
@@ -274,9 +262,11 @@ static void signal_irq_work(struct irq_work *work)
release = remove_signaling_context(b, ce);
spin_unlock(>signal_lock);
 
-   if (__signal_request(rq))
+   if (__dma_fence_signal(>fence))
/* We own signal_node now, xfer to local list */
signal = slist_add(>signal_node, signal);
+   else
+   i915_request_put(rq);
 
if (release) {
add_retire(b, ce->timeline);
@@ -363,6 +353,17 @@ void intel_breadcrumbs_free(struct intel_breadcrumbs *b)
kfree(b);
 }
 
+static void irq_signal_request(struct i915_request *rq,
+  struct intel_breadcrumbs *b)
+{
+   if (!__dma_fence_signal(>fence))
+   return;
+
+   i915_request_get(rq);
+   if (llist_add(>signal_node, >signaled_requests))
+   irq_work_queue(>irq_work);
+}
+
 static void insert_breadcrumb(struct i915_request *rq)
 {
struct intel_breadcrumbs *b = READ_ONCE(rq->engine)->breadcrumbs;
@@ -372,17 +373,13 @@ static void insert_breadcrumb(struct i915_request *rq)
if (test_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags))
return;
 
-   i915_request_get(rq);
-
/*
 * If the request is already completed, we can transfer it
 * straight onto a signaled list, and queue the irq worker for
 * its signal completion.
 */
if (__request_completed(rq)) {
-   if (__signal_request(rq) &&
-   llist_add(>signal_node, >signaled_requests))
-   irq_work_queue(>irq_work);
+   irq_signal_request(rq, b);
return;
}
 
@@ -413,6 +410,8 @@ static void insert_breadcrumb(struct i915_request *rq)
break;
}
}
+
+   i915_request_get(rq);
list_add_rcu(>signal_link, pos);
GEM_BUG_ON(!check_signal_order(ce, rq));
GEM_BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags));
@@ -453,6 +452,7 @@ bool i915_request_enable_breadcrumb(struct i915_request *rq)
 
 void i915_request_cancel_breadcrumb(struct i915_request *rq)
 {
+   struct intel_breadcrumbs *b = READ_ONCE(rq->engine)->breadcrumbs;
struct intel_context *ce = rq->context;
bool release;
 
@@ -461,11 +461,14 @@ void i915_request_cancel_breadcrumb(struct i915_request 
*rq)
 
spin_lock(>signal_lock);
list_del_rcu(>signal_link);
-   release = remove_signaling_context(rq->engine->breadcrumbs, ce);
+   release = remove_signaling_context(b, ce);
spin_unlock(>signal_lock);
if (release)
intel_context_put(ce);
 
+   if (__request_completed(rq))
+   irq_signal_request(rq, b);
+
i915_request_put(rq);
 }
 
-- 
2.20.1

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

[Intel-gfx] [CI 4/5] drm/i915/gt: Split the breadcrumb spinlock between global and contexts

[Chris Wilson]

As we funnel more and more contexts into the breadcrumbs on an engine,
the hold time of b->irq_lock grows. As we may then contend with the
b->irq_lock during request submission, this increases the burden upon
the engine->active.lock and so directly impacts both our execution
latency and client latency. If we split the b->irq_lock by introducing a
per-context spinlock to manage the signalers within a context, we then
only need the b->irq_lock for enabling/disabling the interrupt and can
avoid taking the lock for walking the list of contexts within the signal
worker. Even with the current setup, this greatly reduces the number of
times we have to take and fight for b->irq_lock.

Furthermore, this closes the race between enabling the signaling context
while it is in the process of being signaled and removed:

<4>[  416.208555] list_add corruption. prev->next should be next 
(8881951d5910), but was dead0100. (prev=8882781bb870).
<4>[  416.208573] WARNING: CPU: 7 PID: 0 at lib/list_debug.c:28 
__list_add_valid+0x4d/0x70
<4>[  416.208575] Modules linked in: i915(+) vgem snd_hda_codec_hdmi 
snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio mei_hdcp 
x86_pkg_temp_thermal coretemp ax88179_178a usbnet mii crct10dif_pclmul 
snd_intel_dspcfg crc32_pclmul snd_hda_codec snd_hwdep ghash_clmulni_intel 
snd_hda_core e1000e snd_pcm ptp pps_core mei_me mei prime_numbers 
intel_lpss_pci [last unloaded: i915]
<4>[  416.208611] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G U
5.8.0-CI-CI_DRM_8852+ #1
<4>[  416.208614] Hardware name: Intel Corporation Ice Lake Client 
Platform/IceLake Y LPDDR4x T4 RVP TLC, BIOS ICLSFWR1.R00.3212.A00.1905212112 
05/21/2019
<4>[  416.208627] RIP: 0010:__list_add_valid+0x4d/0x70
<4>[  416.208631] Code: c3 48 89 d1 48 c7 c7 60 18 33 82 48 89 c2 e8 ea e0 b6 
ff 0f 0b 31 c0 c3 48 89 c1 4c 89 c6 48 c7 c7 b0 18 33 82 e8 d3 e0 b6 ff <0f> 0b 
31 c0 c3 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 00 19 33 82 e8
<4>[  416.208633] RSP: 0018:c9280e18 EFLAGS: 00010086
<4>[  416.208636] RAX:  RBX: 888250a44880 RCX: 
0105
<4>[  416.208639] RDX: 0105 RSI: 82320c5b RDI: 

<4>[  416.208641] RBP: 8882781bb870 R08:  R09: 
0001
<4>[  416.208643] R10: 054d2957 R11: 6abbd991 R12: 
8881951d58c8
<4>[  416.208646] R13: 888286073880 R14: 888286073848 R15: 
8881951d5910
<4>[  416.208669] FS:  () GS:88829c18() 
knlGS:
<4>[  416.208671] CS:  0010 DS:  ES:  CR0: 80050033
<4>[  416.208673] CR2: 556231326c48 CR3: 05610001 CR4: 
00760ee0
<4>[  416.208675] PKRU: 5554
<4>[  416.208677] Call Trace:
<4>[  416.208679]  
<4>[  416.208751]  i915_request_enable_breadcrumb+0x278/0x400 [i915]
<4>[  416.208839]  __i915_request_submit+0xca/0x2a0 [i915]
<4>[  416.208892]  __execlists_submission_tasklet+0x480/0x1830 [i915]
<4>[  416.208942]  execlists_submission_tasklet+0xc4/0x130 [i915]
<4>[  416.208947]  tasklet_action_common.isra.17+0x6c/0x1c0
<4>[  416.208954]  __do_softirq+0xdf/0x498
<4>[  416.208960]  ? handle_fasteoi_irq+0x150/0x150
<4>[  416.208964]  asm_call_on_stack+0xf/0x20
<4>[  416.208966]  
<4>[  416.208969]  do_softirq_own_stack+0xa1/0xc0
<4>[  416.208972]  irq_exit_rcu+0xb5/0xc0
<4>[  416.208976]  common_interrupt+0xf7/0x260
<4>[  416.208980]  asm_common_interrupt+0x1e/0x40
<4>[  416.208985] RIP: 0010:cpuidle_enter_state+0xb6/0x410
<4>[  416.208987] Code: 00 31 ff e8 9c 3e 89 ff 80 7c 24 0b 00 74 12 9c 58 f6 
c4 02 0f 85 31 03 00 00 31 ff e8 e3 6c 90 ff e8 fe a4 94 ff fb 45 85 ed <0f> 88 
c7 02 00 00 49 63 c5 4c 2b 24 24 48 8d 14 40 48 8d 14 90 48
<4>[  416.208989] RSP: 0018:c9143e70 EFLAGS: 0206
<4>[  416.208991] RAX: 0007 RBX: e8da8070 RCX: 

<4>[  416.208993] RDX:  RSI: 8238b4ee RDI: 
8233184f
<4>[  416.208995] RBP: 826b4e00 R08:  R09: 

<4>[  416.208997] R10: 0001 R11:  R12: 
0060e7f24a8f
<4>[  416.208998] R13: 0003 R14: 0003 R15: 
0003
<4>[  416.209012]  cpuidle_enter+0x24/0x40
<4>[  416.209016]  do_idle+0x22f/0x2d0
<4>[  416.209022]  cpu_startup_entry+0x14/0x20
<4>[  416.209025]  start_secondary+0x158/0x1a0
<4>[  416.209030]  secondary_startup_64+0xa4/0xb0
<4>[  416.209039] irq event stamp: 10186977
<4>[  416.209042] hardirqs last  enabled at (10186976): [] 
tasklet_action_common.isra.17+0xe3/0x1c0
<4>[  416.209044] hardirqs last disabled at (10186977): [] 
_raw_spin_lock_irqsave+0xd/0x50
<4>[  416.209047] softirqs last  enabled at (10186968): [] 
irq_enter_rcu+0x6a/0x70
<4>[  416.209049] softirqs last disabled at (10186969): [] 
asm_call_on_stack+0xf/0x20

<4>[  416.209317] list_del corruption, 8882781bb870->next is LIST_POISON1 
(dead0100)
<4>[  416.209317] WARNING: CPU: 7 

[Intel-gfx] [CI 2/5] drm/i915/gt: Check for a completed last request once

[Chris Wilson]

Pull the repeated check for the last active request being completed to a
single spot, when deciding whether or not execlist preemption is
required.

In doing so, we remove the tasklet kick, introduced with the completion
checks in commit 35f3fd8182ba ("drm/i915/execlists: Workaround switching
back to a completed context"), if we find the request was completed but
have not yet seen the corresponding CS event. This was devolving into a
busy spin of the tasklet while we waited for the event as the delivery
was not as instantaneous as expected. Under load this is sufficient to
exhaust the tasklet softirq timeslice, and force ksoftirqd. Quite
noticeable overhead for no apparent improvement in latency.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_lrc.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index cf11cbac241b..43703efb36d1 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2141,12 +2141,9 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
 */
 
if ((last = *active)) {
-   if (need_preempt(engine, last, rb)) {
-   if (i915_request_completed(last)) {
-   tasklet_hi_schedule(>tasklet);
-   return;
-   }
-
+   if (i915_request_completed(last)) {
+   goto check_secondary;
+   } else if (need_preempt(engine, last, rb)) {
ENGINE_TRACE(engine,
 "preempting last=%llx:%lld, prio=%d, 
hint=%d\n",
 last->fence.context,
@@ -2174,11 +2171,6 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
last = NULL;
} else if (need_timeslice(engine, last, rb) &&
   timeslice_expired(execlists, last)) {
-   if (i915_request_completed(last)) {
-   tasklet_hi_schedule(>tasklet);
-   return;
-   }
-
ENGINE_TRACE(engine,
 "expired last=%llx:%lld, prio=%d, hint=%d, 
yield?=%s\n",
 last->fence.context,
@@ -2214,6 +2206,7 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
 * we hopefully coalesce several updates into a single
 * submission.
 */
+check_secondary:
if (!list_is_last(>sched.link,
  >active.requests)) {
/*
-- 
2.20.1

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

Re: [Intel-gfx] [RFC] drm/i915/dp: PPS registers doesn't require AUX power

[Ville Syrjälä]

On Thu, Nov 26, 2020 at 03:09:50PM +0530, Anshuman Gupta wrote:
> On 2020-11-25 at 18:24:44 +0200, Imre Deak wrote:
> > +Ville.
> Hi Ville ,
> Let me provide you some context over the issue which requires your input.
> TGL on chorome OS has observed some display glitches when brightness is being 
> updated
> at very fast rate. This has surfaced out two issue.
> 1. Getting the AUX power when accessing the PPS registers on platform with 
> split PCH.

There can be all kinds of reasons for taking the AUX power
domain. If that somehow causes display glitches then someone
needs to figure out why and fix it. This looks like just duct
tape over one specific case.

> 2. The race between DC3CO disabling delay and flips. (B.Spec says 200us dc3co 
> exit delay)
>I will send a separate RFC patch to fix this issue.
> 
> Current patch is addressing issue1, 
> IMHO it is unnecessary to take AUX power for pps register read for checking
> whether backlight was enabled. This is causing flip to race with
> DC3CO exit delay.
> Could you please provide your input to this . 
> 
> Thanks,
> Anshuman Gupta.   
> > 
> > On Wed, Nov 25, 2020 at 01:16:27PM +0530, Anshuman Gupta wrote:
> > > On 2020-11-24 at 18:44:06 +0200, Imre Deak wrote:
> > > > On Tue, Nov 24, 2020 at 03:28:47PM +0530, Anshuman Gupta wrote:
> > > > > Platforms with South Display Engine on PCH, doesn't
> > > > > require to get/put the AUX power domain in order to
> > > > > access PPS register because PPS registers are always on
> > > > > with South display on PCH.
> > > > > 
> > > > > Cc: Imre Deak 
> > > > > Cc: 
> > > > > Signed-off-by: Anshuman Gupta 
> > > > 
> > > > Could you describe the issue the patch is fixing?
> > >
> > > This fixes the display glitches causes by race between brightness
> > > update thread and flip thread.
> > 
> > Flips should work even with asynchronous DC3co (or any DC state)
> > disabling, at least according to the spec the HW handles this. Only
> > modesetting and AUX transfers have restriction wrt. DC state handling
> > (where DC states need to get disabled).
> > 
> > I think the exact restriction needs to be clarified with HW people: Is
> > only the DC3co disable -> flip or also the opposite sequence
> > problematic? Is it only DC3co or also DC5/6 affected?
> > 
> > > While brightness is being updated it reads pp_ctrl reg to check
> > > whether backlight is enabled and get/put the AUX power domain, this
> > > enables and disable DC Off power well(DC3CO) back and forth.
> > >
> > > IMO there are two work item for above race needed to be addressed.
> > > 1. Don't get AUX power for PPS register access (this patch addressed 
> > > this).
> > > 2. skl_program_plane() should wait for DC3CO exit delay to avoid any race 
> > > with
> > >DC3CO disable sequence. (WIP)  
> > 
> > DC states can be disabled asynchronously with a flip modeset, not only
> > for panel brightness setting, but also AUX transfers for instance. So I
> > think we'd need to add locking against DC state changes to
> > intel_pipe_update_start()/end(). Probably the easiest would be to use
> > the power_domains->lock for this.
> > 
> > --Imre

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Program mocs:63 for cache eviction on gen9

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Program mocs:63 for cache eviction on gen9
URL   : https://patchwork.freedesktop.org/series/84293/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9393 -> Patchwork_18988


Summary
---

  **SUCCESS**

  No regressions found.

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

New tests
-

  New tests have been introduced between CI_DRM_9393 and Patchwork_18988:

### New CI tests (1) ###

  * boot:
- Statuses : 39 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload:
- fi-byt-j1900:   [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-byt-j1900/igt@i915_module_l...@reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18988/fi-byt-j1900/igt@i915_module_l...@reload.html
- fi-tgl-y:   [PASS][3] -> [DMESG-WARN][4] ([i915#1982] / 
[k.org#205379])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-tgl-y/igt@i915_module_l...@reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18988/fi-tgl-y/igt@i915_module_l...@reload.html

  * igt@kms_busy@basic@flip:
- fi-tgl-y:   [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-tgl-y/igt@kms_busy@ba...@flip.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18988/fi-tgl-y/igt@kms_busy@ba...@flip.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka:   [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18988/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2:  [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +1 
similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18988/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html

  * igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y:   [PASS][11] -> [DMESG-WARN][12] ([i915#402]) +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18988/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html

  
 Possible fixes 

  * igt@i915_module_load@reload:
- fi-icl-u2:  [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-icl-u2/igt@i915_module_l...@reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18988/fi-icl-u2/igt@i915_module_l...@reload.html

  * igt@i915_pm_rpm@module-reload:
- fi-byt-j1900:   [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-byt-j1900/igt@i915_pm_...@module-reload.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18988/fi-byt-j1900/igt@i915_pm_...@module-reload.html

  * igt@prime_vgem@basic-gtt:
- fi-tgl-y:   [DMESG-WARN][17] ([i915#402]) -> [PASS][18] +1 
similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-tgl-y/igt@prime_v...@basic-gtt.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18988/fi-tgl-y/igt@prime_v...@basic-gtt.html

  
 Warnings 

  * igt@runner@aborted:
- fi-kbl-8809g:   [FAIL][19] ([i915#1186] / [i915#2426]) -> [FAIL][20] 
([i915#1569] / [i915#192] / [i915#193] / [i915#194] / [i915#2295])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-kbl-8809g/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18988/fi-kbl-8809g/igt@run...@aborted.html

  
  [i915#1186]: https://gitlab.freedesktop.org/drm/intel/issues/1186
  [i915#1569]: https://gitlab.freedesktop.org/drm/intel/issues/1569
  [i915#192]: https://gitlab.freedesktop.org/drm/intel/issues/192
  [i915#193]: https://gitlab.freedesktop.org/drm/intel/issues/193
  [i915#194]: https://gitlab.freedesktop.org/drm/intel/issues/194
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2295]: https://gitlab.freedesktop.org/drm/intel/issues/2295
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [k.org#205379]: 

[Intel-gfx] ✗ Fi.CI.IGT: failure for HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (rev5)

[Patchwork]

== Series Details ==

Series: HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (rev5)
URL   : https://patchwork.freedesktop.org/series/82998/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9392_full -> Patchwork_18986_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * {igt@kms_content_protection@dp-mst-lic-type-1} (NEW):
- shard-iclb: NOTRUN -> [SKIP][1] +3 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/shard-iclb7/igt@kms_content_protect...@dp-mst-lic-type-1.html

  * {igt@kms_content_protection@dp-mst-type-0} (NEW):
- shard-tglb: NOTRUN -> [SKIP][2] +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/shard-tglb3/igt@kms_content_protect...@dp-mst-type-0.html

  * igt@sysfs_timeslice_duration@timeout@vecs0:
- shard-apl:  [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/shard-apl7/igt@sysfs_timeslice_duration@time...@vecs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/shard-apl6/igt@sysfs_timeslice_duration@time...@vecs0.html

  
 Warnings 

  * igt@kms_content_protection@srm:
- shard-skl:  [SKIP][5] ([fdo#109271]) -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/shard-skl3/igt@kms_content_protect...@srm.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/shard-skl8/igt@kms_content_protect...@srm.html

  
New tests
-

  New tests have been introduced between CI_DRM_9392_full and 
Patchwork_18986_full:

### New CI tests (1) ###

  * boot:
- Statuses : 199 pass(s)
- Exec time: [0.0] s

  


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

  * igt@kms_content_protection@dp-mst-lic-type-0:
- Statuses : 7 skip(s)
- Exec time: [0.0, 0.00] s

  * igt@kms_content_protection@dp-mst-lic-type-1:
- Statuses : 8 skip(s)
- Exec time: [0.0, 0.00] s

  * igt@kms_content_protection@dp-mst-type-0:
- Statuses : 8 skip(s)
- Exec time: [0.0, 0.00] s

  * igt@kms_content_protection@dp-mst-type-1:
- Statuses : 8 skip(s)
- Exec time: [0.0, 0.00] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_whisper@basic-contexts-forked:
- shard-glk:  [PASS][7] -> [DMESG-WARN][8] ([i915#118] / [i915#95]) 
+1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/shard-glk6/igt@gem_exec_whis...@basic-contexts-forked.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/shard-glk4/igt@gem_exec_whis...@basic-contexts-forked.html

  * igt@i915_pm_dc@dc6-psr:
- shard-skl:  [PASS][9] -> [FAIL][10] ([i915#454])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/shard-skl6/igt@i915_pm...@dc6-psr.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/shard-skl7/igt@i915_pm...@dc6-psr.html

  * igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait:
- shard-kbl:  [PASS][11] -> [SKIP][12] ([fdo#109271]) +1 similar 
issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/shard-kbl1/igt@i915_pm_...@modeset-non-lpsp-stress-no-wait.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/shard-kbl1/igt@i915_pm_...@modeset-non-lpsp-stress-no-wait.html
- shard-glk:  [PASS][13] -> [SKIP][14] ([fdo#109271]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/shard-glk9/igt@i915_pm_...@modeset-non-lpsp-stress-no-wait.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/shard-glk4/igt@i915_pm_...@modeset-non-lpsp-stress-no-wait.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-apl:  [PASS][15] -> [INCOMPLETE][16] ([i915#2635])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/shard-apl2/igt@i915_susp...@fence-restore-tiled2untiled.html
- shard-iclb: [PASS][17] -> [INCOMPLETE][18] ([i915#1185])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/shard-iclb7/igt@i915_susp...@fence-restore-tiled2untiled.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/shard-iclb4/igt@i915_susp...@fence-restore-tiled2untiled.html
- shard-kbl: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Program mocs:63 for cache eviction on gen9

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Program mocs:63 for cache eviction on gen9
URL   : https://patchwork.freedesktop.org/series/84293/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
eb703e13ad7c drm/i915/gt: Program mocs:63 for cache eviction on gen9
-:24: WARNING:BAD_SIGN_OFF: email address ' # v4.3+' 
might be better as 'sta...@vger.kernel.org# v4.3+'
#24: 
Cc:  # v4.3+

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


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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: also include Gen11 in OATAILPTR workaround

[Patchwork]

== Series Details ==

Series: drm/i915/perf: also include Gen11 in OATAILPTR workaround
URL   : https://patchwork.freedesktop.org/series/84292/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9393 -> Patchwork_18987


Summary
---

  **SUCCESS**

  No regressions found.

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

New tests
-

  New tests have been introduced between CI_DRM_9393 and Patchwork_18987:

### New CI tests (1) ###

  * boot:
- Statuses : 40 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-tgl-y:   [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) +1 similar 
issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-tgl-y/igt@core_hotunp...@unbind-rebind.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/fi-tgl-y/igt@core_hotunp...@unbind-rebind.html

  * igt@debugfs_test@read_all_entries:
- fi-tgl-y:   [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +2 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-tgl-y/igt@debugfs_test@read_all_entries.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/fi-tgl-y/igt@debugfs_test@read_all_entries.html

  * igt@i915_module_load@reload:
- fi-byt-j1900:   [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-byt-j1900/igt@i915_module_l...@reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/fi-byt-j1900/igt@i915_module_l...@reload.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-n3050:   [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka:   [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-icl-u2:  [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html

  
 Possible fixes 

  * igt@i915_module_load@reload:
- fi-icl-u2:  [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-icl-u2/igt@i915_module_l...@reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/fi-icl-u2/igt@i915_module_l...@reload.html

  * igt@i915_pm_rpm@module-reload:
- fi-byt-j1900:   [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-byt-j1900/igt@i915_pm_...@module-reload.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/fi-byt-j1900/igt@i915_pm_...@module-reload.html

  * igt@kms_busy@basic@flip:
- fi-kbl-soraka:  [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-kbl-soraka/igt@kms_busy@ba...@flip.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/fi-kbl-soraka/igt@kms_busy@ba...@flip.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@prime_vgem@basic-gtt:
- fi-tgl-y:   [DMESG-WARN][21] ([i915#402]) -> [PASS][22] +1 
similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9393/fi-tgl-y/igt@prime_v...@basic-gtt.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18987/fi-tgl-y/igt@prime_v...@basic-gtt.html

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

  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#402]: 

Re: [Intel-gfx] [RFC v2 6/8] drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)

[Jani Nikula]

On Wed, 16 Sep 2020, Lyude Paul  wrote:
> So-recently a bunch of laptops on the market have started using DPCD
> backlight controls instead of the traditional DDI backlight controls.
> Originally we thought we had this handled by adding VESA backlight
> control support to i915, but the story ended up being a lot more
> complicated then that.
>
> Simply put-there's two main backlight interfaces Intel can see in the
> wild. Intel's proprietary HDR backlight interface, and the standard VESA
> backlight interface. Note that many panels have been observed to report
> support for both backlight interfaces, but testing has shown far more
> panels work with the Intel HDR backlight interface at the moment.
> Additionally, the VBT appears to be capable of reporting support for the
> VESA backlight interface but not the Intel HDR interface which needs to
> be probed by setting the right magic OUI.
>
> On top of that however, there's also actually two different variants of
> the Intel HDR backlight interface. The first uses the AUX channel for
> controlling the brightness of the screen in both SDR and HDR mode, and
> the second only uses the AUX channel for setting the brightness level in
> HDR mode - relying on PWM for setting the brightness level in SDR mode.
>
> For the time being we've been using EDIDs to maintain a list of quirks
> for panels that safely do support the VESA backlight interface. Adding
> support for Intel's HDR backlight interface in addition however, should
> finally allow us to auto-detect eDP backlight controls properly so long
> as we probe like so:
>
> * If the panel's VBT reports VESA backlight support, assume it really
>   does support it
> * If the panel's VBT reports DDI backlight controls:
>   * First probe for Intel's HDR backlight interface
>   * If that fails, probe for VESA's backlight interface
>   * If that fails, assume no DPCD backlight control
> * If the panel's VBT reports any other backlight type: just assume it
>   doesn't have DPCD backlight controls
>
> Signed-off-by: Lyude Paul 
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick 
> ---
>  .../drm/i915/display/intel_display_types.h|   9 +-
>  .../drm/i915/display/intel_dp_aux_backlight.c | 253 --
>  drivers/gpu/drm/i915/display/intel_panel.c|  34 ++-
>  drivers/gpu/drm/i915/display/intel_panel.h|   4 +
>  4 files changed, 268 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 52a6543df842a..9d540368bac89 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -230,7 +230,14 @@ struct intel_panel {
>   struct pwm_state pwm_state;
>  
>   /* DPCD backlight */
> - u8 pwmgen_bit_count;
> + union {
> + struct {
> + u8 pwmgen_bit_count;
> + } vesa;
> + struct {
> + bool sdr_uses_aux;
> + } intel;
> + } edp;
>  
>   struct {
>   int (*setup)(struct intel_connector *connector, enum 
> pipe pipe);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index c1e8e8b166267..376419ea3ae52 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -22,8 +22,26 @@
>   *
>   */
>  
> +/*
> + * Laptops with Intel GPUs which have panels that support controlling the
> + * backlight through DP AUX can actually use two different interfaces: 
> Intel's
> + * proprietary DP AUX backlight interface, and the standard VESA backlight
> + * interface. Unfortunately, at the time of writing this a lot of laptops 
> will
> + * advertise support for the standard VESA backlight interface when they
> + * don't properly support it. However, on these systems the Intel backlight
> + * interface generally does work properly. Additionally, these systems will
> + * usually just indicate that they use PWM backlight controls in their VBIOS
> + * for some reason.
> + */
> +
>  #include "intel_display_types.h"
>  #include "intel_dp_aux_backlight.h"
> +#include "intel_panel.h"
> +
> +/* TODO:
> + * Implement HDR, right now we just implement the bare minimum to bring us 
> back into SDR mode so we
> + * can make people's backlights work in the mean time
> + */
>  
>  /*
>   * DP AUX registers for Intel's proprietary HDR backlight interface. We 
> define
> @@ -77,6 +95,176 @@
>  
>  #define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_10x359
>  
> +/* Intel EDP backlight callbacks */
> +static bool
> +intel_dp_aux_supports_hdr_backlight(struct intel_connector *connector)
> +{
> + struct drm_device *dev = connector->base.dev;
> + struct intel_dp *intel_dp = 

[Intel-gfx] ✗ Fi.CI.IGT: failure for Enable HDR on MCA LSPCON based Gen9 devices (rev11)

[Patchwork]

== Series Details ==

Series: Enable HDR on MCA LSPCON based Gen9 devices (rev11)
URL   : https://patchwork.freedesktop.org/series/68081/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9392_full -> Patchwork_18985_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@api_intel_bb@blit-noreloc-purge-cache:
- shard-hsw:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/shard-hsw1/igt@api_intel...@blit-noreloc-purge-cache.html

  * igt@i915_selftest@live@gem_contexts:
- shard-skl:  NOTRUN -> [INCOMPLETE][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/shard-skl6/igt@i915_selftest@live@gem_contexts.html

  
 Warnings 

  * igt@i915_pm_backlight@fade_with_suspend:
- shard-iclb: [INCOMPLETE][3] ([i915#1185] / [i915#2369]) -> 
[DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/shard-iclb6/igt@i915_pm_backlight@fade_with_suspend.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/shard-iclb3/igt@i915_pm_backlight@fade_with_suspend.html

  
New tests
-

  New tests have been introduced between CI_DRM_9392_full and 
Patchwork_18985_full:

### New CI tests (1) ###

  * boot:
- Statuses : 200 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_whisper@basic-fds-all:
- shard-kbl:  [PASS][5] -> [INCOMPLETE][6] ([i915#794])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/shard-kbl1/igt@gem_exec_whis...@basic-fds-all.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/shard-kbl1/igt@gem_exec_whis...@basic-fds-all.html

  * igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk:  [PASS][7] -> [FAIL][8] ([i915#644])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/shard-glk3/igt@gem_pp...@flink-and-close-vma-leak.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/shard-glk8/igt@gem_pp...@flink-and-close-vma-leak.html

  * igt@kms_cursor_crc@pipe-c-cursor-64x21-random:
- shard-skl:  [PASS][9] -> [FAIL][10] ([i915#54]) +2 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/shard-skl10/igt@kms_cursor_...@pipe-c-cursor-64x21-random.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/shard-skl1/igt@kms_cursor_...@pipe-c-cursor-64x21-random.html

  * igt@kms_cursor_legacy@flip-vs-cursor-varying-size:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2346])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/shard-tglb5/igt@kms_cursor_leg...@flip-vs-cursor-varying-size.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/shard-tglb1/igt@kms_cursor_leg...@flip-vs-cursor-varying-size.html

  * igt@kms_flip@2x-flip-vs-fences-interruptible@ab-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/shard-glk3/igt@kms_flip@2x-flip-vs-fences-interrupti...@ab-hdmi-a1-hdmi-a2.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/shard-glk7/igt@kms_flip@2x-flip-vs-fences-interrupti...@ab-hdmi-a1-hdmi-a2.html

  * igt@kms_flip@2x-plain-flip-ts-check-interruptible@ab-vga1-hdmi-a1:
- shard-hsw:  [PASS][15] -> [DMESG-WARN][16] ([i915#1982])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/shard-hsw8/igt@kms_flip@2x-plain-flip-ts-check-interrupti...@ab-vga1-hdmi-a1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/shard-hsw6/igt@kms_flip@2x-plain-flip-ts-check-interrupti...@ab-vga1-hdmi-a1.html

  * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite:
- shard-kbl:  [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +1 
similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/shard-kbl2/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/shard-kbl4/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-rte:
- shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982])
   [19]: 

Re: [Intel-gfx] [RFC v2 3/8] drm/i915: Keep track of pwm-related backlight hooks separately

[Jani Nikula]

On Thu, 26 Nov 2020, Dave Airlie  wrote:
> On Thu, 17 Sept 2020 at 03:19, Lyude Paul  wrote:
>>
>> Currently, every different type of backlight hook that i915 supports is
>> pretty straight forward - you have a backlight, probably through PWM
>> (but maybe DPCD), with a single set of platform-specific hooks that are
>> used for controlling it.
>>
>> HDR backlights, in particular VESA and Intel's HDR backlight
>> implementations, can end up being more complicated. With Intel's
>> proprietary interface, HDR backlight controls always run through the
>> DPCD. When the backlight is in SDR backlight mode however, the driver
>> may need to bypass the TCON and control the backlight directly through
>> PWM.
>>
>> So, in order to support this we'll need to split our backlight callbacks
>> into two groups: a set of high-level backlight control callbacks in
>> intel_panel, and an additional set of pwm-specific backlight control
>> callbacks. This also implies a functional changes for how these
>> callbacks are used:
>>
>> * We now keep track of two separate backlight level ranges, one for the
>>   high-level backlight, and one for the pwm backlight range
>> * We also keep track of backlight enablement and PWM backlight
>>   enablement separately
>> * Since the currently set backlight level might not be the same as the
>>   currently programmed PWM backlight level, we stop setting
>>   panel->backlight.level with the currently programmed PWM backlight
>>   level in panel->backlight.pwm_funcs.setup(). Instead, we rely
>>   on the higher level backlight control functions to retrieve the
>>   current PWM backlight level (in this case, intel_pwm_get_backlight()).
>>   Note that there are still a few PWM backlight setup callbacks that
>>   do actually need to retrieve the current PWM backlight level, although
>>   we no longer save this value in panel->backlight.level like before.
>> * panel->backlight.pwm_funcs.enable()/disable() both accept a PWM
>>   brightness level, unlike their siblings
>>   panel->backlight.enable()/disable(). This is so we can calculate the
>>   actual PWM brightness level we want to set on disable/enable in the
>>   higher level backlight enable()/disable() functions, since this value
>>   might be scaled from a brightness level that doesn't come from PWM.
>
> Oh this patch is a handful, I can see why people stall out here.
>
> I'm going to be annoying maintainer and see if you can clean this up a
> bit in advance of this patch.

Agreed. And not looking into and requesting this earlier is on me.

The thing that still keeps bugging me about the DPCD brightness control
in general is that it's a historical mistake to put all of this under
i915. (Again, mea culpa.) The standard DPCD brightness control should
really be under drm core, in one form or another.

I'm not asking to fix that here. But I *am* wondering if the series
makes that harder. What would it look like if we did have that unicorn
of a brightness connector property? How would that tie into the hooks we
have?

Maybe the answer is that the DPCD backlight functions should just be
library code in drm core that the drivers could call. In the long run,
i915 really can't be the only one needing this stuff.

We haven't implemented the mixed modes of DPCD and eDP PWM pin
brightness control. But the point is, the library code can't call into
i915 specific eDP PWM pin control code. The proprietary HDR brightness
code will still be i915 specific, but does it make sense to have a mixed
mode there that will be completely different from what a mixed mode with
the standard VESA DPCD brightness could be?

I.e. what should be the entry points for the hooks, and who calls what?

BR,
Jani.

>
> 1) move the callbacks out of struct intel_panel.backlight into a separate 
> struct
> and use const static object tables, having fn ptrs and data co-located
> in a struct
> isn't great.
>
> strcut intel_panel_backlight_funcs {
>
> };
> struct intel_panel {
> struct {
> struct intel_panel_backlight_funcs *funcs;
> };
> };
>
> type of thing.
>
> I think you could reuse the backlight funcs struct for the pwm stuff
> as well. (maybe with an assert on hz_to_pwm for the old hooks).
>
> 2) change the apis to pass 0 down in a separate patch, this modifies a
> bunch of apis to pass in an extra level parameter, do that
> first in a separate patch that doesn't change anything but hands 0
> down the chain. Then switch over in another patch.
>
> 3) One comment in passing below.
>>
>>
>> -   if (cpu_mode)
>> -   val = pch_get_backlight(connector);
>> -   else
>> -   val = lpt_get_backlight(connector);
>> -   val = intel_panel_compute_brightness(connector, val);
>> -   panel->backlight.level = clamp(val, panel->backlight.min,
>> -  panel->backlight.max);
>>
>> if (cpu_mode) {
>> +   val = intel_panel_sanitize_pwm_level(connector, 
>> pch_get_backlight(connector));
>> +
>> 

Re: [Intel-gfx] [PATCH v2] drm/i915/gt: Move the breadcrumb to the signaler if completed upon cancel

[Tvrtko Ursulin]

On 25/11/2020 19:56, Chris Wilson wrote:

If while we are cancelling the breadcrumb signaling, we find that the
request is already completed, move it to the irq signaler and let it be
signaled.

v2: Tweak reference counting so that we only acquire a new reference on
adding to a signal list, as opposed to a hidden i915_request_put of the
caller's reference.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 41 +++--
  1 file changed, 22 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index a24cc1ff08a0..00918300f53f 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -192,18 +192,6 @@ static void add_retire(struct intel_breadcrumbs *b, struct 
intel_timeline *tl)
intel_engine_add_retire(b->irq_engine, tl);
  }
  
-static bool __signal_request(struct i915_request *rq)

-{
-   GEM_BUG_ON(test_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags));
-
-   if (!__dma_fence_signal(>fence)) {
-   i915_request_put(rq);
-   return false;
-   }
-
-   return true;
-}
-
  static struct llist_node *
  slist_add(struct llist_node *node, struct llist_node *head)
  {
@@ -274,9 +262,11 @@ static void signal_irq_work(struct irq_work *work)
release = remove_signaling_context(b, ce);
spin_unlock(>signal_lock);
  
-			if (__signal_request(rq))

+   if (__dma_fence_signal(>fence))
/* We own signal_node now, xfer to local list */
signal = slist_add(>signal_node, signal);
+   else
+   i915_request_put(rq);
  
  			if (release) {

add_retire(b, ce->timeline);
@@ -363,6 +353,17 @@ void intel_breadcrumbs_free(struct intel_breadcrumbs *b)
kfree(b);
  }
  
+static void irq_signal_request(struct i915_request *rq,

+  struct intel_breadcrumbs *b)
+{
+   if (!__dma_fence_signal(>fence))
+   return;
+
+   i915_request_get(rq);
+   if (llist_add(>signal_node, >signaled_requests))
+   irq_work_queue(>irq_work);
+}
+
  static void insert_breadcrumb(struct i915_request *rq)
  {
struct intel_breadcrumbs *b = READ_ONCE(rq->engine)->breadcrumbs;
@@ -372,17 +373,13 @@ static void insert_breadcrumb(struct i915_request *rq)
if (test_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags))
return;
  
-	i915_request_get(rq);

-
/*
 * If the request is already completed, we can transfer it
 * straight onto a signaled list, and queue the irq worker for
 * its signal completion.
 */
if (__request_completed(rq)) {
-   if (__signal_request(rq) &&
-   llist_add(>signal_node, >signaled_requests))
-   irq_work_queue(>irq_work);
+   irq_signal_request(rq, b);
return;
}
  
@@ -413,6 +410,8 @@ static void insert_breadcrumb(struct i915_request *rq)

break;
}
}
+
+   i915_request_get(rq);
list_add_rcu(>signal_link, pos);
GEM_BUG_ON(!check_signal_order(ce, rq));
GEM_BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags));
@@ -453,6 +452,7 @@ bool i915_request_enable_breadcrumb(struct i915_request *rq)
  
  void i915_request_cancel_breadcrumb(struct i915_request *rq)

  {
+   struct intel_breadcrumbs *b = READ_ONCE(rq->engine)->breadcrumbs;
struct intel_context *ce = rq->context;
bool release;
  
@@ -461,11 +461,14 @@ void i915_request_cancel_breadcrumb(struct i915_request *rq)
  
  	spin_lock(>signal_lock);

list_del_rcu(>signal_link);
-   release = remove_signaling_context(rq->engine->breadcrumbs, ce);
+   release = remove_signaling_context(b, ce);
spin_unlock(>signal_lock);
if (release)
intel_context_put(ce);
  
+	if (__request_completed(rq))

+   irq_signal_request(rq, b);
+
i915_request_put(rq);
  }
  



I can follow this more easily, thanks!

Reviewed-by: Tvrtko Ursulin 

Regards,

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

[Intel-gfx] [PATCH i-g-t v2] i915/gem_exec_schedule: Try to spot unfairness

[Chris Wilson]

An important property for multi-client systems is that each client gets
a 'fair' allotment of system time. (Where fairness is at the whim of the
context properties, such as priorities.) This test forks N independent
clients (albeit they happen to share a single vm), and does an equal
amount of work in client and asserts that they take an equal amount of
time.

Though we have never claimed to have a completely fair scheduler, that
is what is expected.

v2: igt_assert_f and more commentary; exclude vip from client stats,
include range of frame intervals from each individual client

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Ramalingam C 
---
 tests/i915/gem_exec_schedule.c | 911 +
 1 file changed, 911 insertions(+)

diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index f23d63ac3..e69771299 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2516,6 +2517,883 @@ static void measure_semaphore_power(int i915)
rapl_close();
 }
 
+static int read_timestamp_frequency(int i915)
+{
+   int value = 0;
+   drm_i915_getparam_t gp = {
+   .value = ,
+   .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
+   };
+   ioctl(i915, DRM_IOCTL_I915_GETPARAM, );
+   return value;
+}
+
+static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
+{
+   return (x + y - 1) / y;
+}
+
+static uint64_t ns_to_ctx_ticks(int i915, uint64_t ns)
+{
+   int f = read_timestamp_frequency(i915);
+   if (intel_gen(intel_get_drm_devid(i915)) == 11)
+   f = 1250; /* icl!!! are you feeling alright? CTX vs CS */
+   return div64_u64_round_up(ns * f, NSEC_PER_SEC);
+}
+
+static uint64_t ticks_to_ns(int i915, uint64_t ticks)
+{
+   return div64_u64_round_up(ticks * NSEC_PER_SEC,
+ read_timestamp_frequency(i915));
+}
+
+#define MI_INSTR(opcode, flags) (((opcode) << 23) | (flags))
+
+#define MI_MATH(x)  MI_INSTR(0x1a, (x) - 1)
+#define MI_MATH_INSTR(opcode, op1, op2) ((opcode) << 20 | (op1) << 10 | (op2))
+/* Opcodes for MI_MATH_INSTR */
+#define   MI_MATH_NOOP  MI_MATH_INSTR(0x000, 0x0, 0x0)
+#define   MI_MATH_LOAD(op1, op2)MI_MATH_INSTR(0x080, op1, op2)
+#define   MI_MATH_LOADINV(op1, op2) MI_MATH_INSTR(0x480, op1, op2)
+#define   MI_MATH_LOAD0(op1)MI_MATH_INSTR(0x081, op1)
+#define   MI_MATH_LOAD1(op1)MI_MATH_INSTR(0x481, op1)
+#define   MI_MATH_ADD   MI_MATH_INSTR(0x100, 0x0, 0x0)
+#define   MI_MATH_SUB   MI_MATH_INSTR(0x101, 0x0, 0x0)
+#define   MI_MATH_AND   MI_MATH_INSTR(0x102, 0x0, 0x0)
+#define   MI_MATH_ORMI_MATH_INSTR(0x103, 0x0, 0x0)
+#define   MI_MATH_XOR   MI_MATH_INSTR(0x104, 0x0, 0x0)
+#define   MI_MATH_STORE(op1, op2)   MI_MATH_INSTR(0x180, op1, op2)
+#define   MI_MATH_STOREINV(op1, op2)MI_MATH_INSTR(0x580, op1, op2)
+/* Registers used as operands in MI_MATH_INSTR */
+#define   MI_MATH_REG(x)(x)
+#define   MI_MATH_REG_SRCA  0x20
+#define   MI_MATH_REG_SRCB  0x21
+#define   MI_MATH_REG_ACCU  0x31
+#define   MI_MATH_REG_ZF0x32
+#define   MI_MATH_REG_CF0x33
+
+#define MI_LOAD_REGISTER_REGMI_INSTR(0x2A, 1)
+
+static void delay(int i915,
+ const struct intel_execution_engine2 *e,
+ uint32_t handle,
+ uint64_t addr,
+ uint64_t ns)
+{
+   const int use_64b = intel_gen(intel_get_drm_devid(i915)) >= 8;
+   const uint32_t base = gem_engine_mmio_base(i915, e->name);
+#define CS_GPR(x) (base + 0x600 + 8 * (x))
+#define RUNTIME (base + 0x3a8)
+   enum { START_TS, NOW_TS };
+   uint32_t *map, *cs, *jmp;
+
+   igt_require(base);
+
+   /* Loop until CTX_TIMESTAMP - initial > @ns */
+
+   cs = map = gem_mmap__device_coherent(i915, handle, 0, 4096, PROT_WRITE);
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(START_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = RUNTIME;
+   *cs++ = CS_GPR(START_TS);
+
+   while (offset_in_page(cs) & 63)
+   *cs++ = 0;
+   jmp = cs;
+
+   *cs++ = 0x5 << 23; /* MI_ARB_CHECK */
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(NOW_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = RUNTIME;
+   *cs++ = CS_GPR(NOW_TS);
+
+   /* delta = now - start; inverted to match COND_BBE */
+   *cs++ = MI_MATH(4);
+   *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCA, MI_MATH_REG(NOW_TS));
+   *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCB, MI_MATH_REG(START_TS));
+   *cs++ = MI_MATH_SUB;
+   *cs++ = MI_MATH_STOREINV(MI_MATH_REG(NOW_TS), MI_MATH_REG_ACCU);
+
+   /* 

[Intel-gfx] [PATCH] drm/i915/gt: Program mocs:63 for cache eviction on gen9

[Chris Wilson]

Ville noticed that the last mocs entry is used unconditionally by the HW
when it performs cache evictions, and noted that while the value is not
meant to be writable by the driver, we should program it to a reasonable
value nevertheless.

As it turns out, we can change the value of mocs:63 and the value we
were programming into it would cause hard hangs in conjunction with
atomic operations.

Suggested-by: Ville Syrjälä 
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2707
Fixes: 3bbaba0ceaa2 ("drm/i915: Added Programming of the MOCS")
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Jason Ekstrand 
Cc:  # v4.3+
---
 drivers/gpu/drm/i915/gt/intel_mocs.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 254873e1646e..6ae512847f64 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -131,7 +131,10 @@ static const struct drm_i915_mocs_entry skl_mocs_table[] = 
{
GEN9_MOCS_ENTRIES,
MOCS_ENTRY(I915_MOCS_CACHED,
   LE_3_WB | LE_TC_2_LLC_ELLC | LE_LRUM(3),
-  L3_3_WB)
+  L3_3_WB),
+   MOCS_ENTRY(63,
+  LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+  L3_1_UC)
 };
 
 /* NOTE: the LE_TGT_CACHE is not used on Broxton */
-- 
2.20.1

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

Re: [Intel-gfx] [RFC v2 2/8] drm/i915: Rename pwm_* backlight callbacks to ext_pwm_*

[Jani Nikula]

On Wed, 16 Sep 2020, Lyude Paul  wrote:
> Since we're going to need to add a set of lower-level PWM backlight
> control hooks to be shared by normal backlight controls and HDR
> backlight controls in SDR mode, let's add a prefix to the external PWM
> backlight functions so that the difference between them and the high
> level PWM-only backlight functions is a bit more obvious.
>
> This introduces no functional changes.
>
> Signed-off-by: Lyude Paul 
> Reviewed-by: Rodrigo Vivi 
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_panel.c | 24 +++---
>  1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index 9f23bac0d7924..c0e36244bb07d 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -589,7 +589,7 @@ static u32 bxt_get_backlight(struct intel_connector 
> *connector)
>BXT_BLC_PWM_DUTY(panel->backlight.controller));
>  }
>  
> -static u32 pwm_get_backlight(struct intel_connector *connector)
> +static u32 ext_pwm_get_backlight(struct intel_connector *connector)
>  {
>   struct intel_panel *panel = >panel;
>   struct pwm_state state;
> @@ -666,7 +666,7 @@ static void bxt_set_backlight(const struct 
> drm_connector_state *conn_state, u32
>  BXT_BLC_PWM_DUTY(panel->backlight.controller), level);
>  }
>  
> -static void pwm_set_backlight(const struct drm_connector_state *conn_state, 
> u32 level)
> +static void ext_pwm_set_backlight(const struct drm_connector_state 
> *conn_state, u32 level)
>  {
>   struct intel_panel *panel = 
> _intel_connector(conn_state->connector)->panel;
>  
> @@ -835,7 +835,7 @@ static void cnp_disable_backlight(const struct 
> drm_connector_state *old_conn_sta
>  tmp & ~BXT_BLC_PWM_ENABLE);
>  }
>  
> -static void pwm_disable_backlight(const struct drm_connector_state 
> *old_conn_state)
> +static void ext_pwm_disable_backlight(const struct drm_connector_state 
> *old_conn_state)
>  {
>   struct intel_connector *connector = 
> to_intel_connector(old_conn_state->connector);
>   struct intel_panel *panel = >panel;
> @@ -1168,8 +1168,8 @@ static void cnp_enable_backlight(const struct 
> intel_crtc_state *crtc_state,
>  pwm_ctl | BXT_BLC_PWM_ENABLE);
>  }
>  
> -static void pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
> -  const struct drm_connector_state *conn_state)
> +static void ext_pwm_enable_backlight(const struct intel_crtc_state 
> *crtc_state,
> +  const struct drm_connector_state 
> *conn_state)
>  {
>   struct intel_connector *connector = 
> to_intel_connector(conn_state->connector);
>   struct intel_panel *panel = >panel;
> @@ -1890,8 +1890,8 @@ cnp_setup_backlight(struct intel_connector *connector, 
> enum pipe unused)
>   return 0;
>  }
>  
> -static int pwm_setup_backlight(struct intel_connector *connector,
> -enum pipe pipe)
> +static int ext_pwm_setup_backlight(struct intel_connector *connector,
> +enum pipe pipe)
>  {
>   struct drm_device *dev = connector->base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -2065,11 +2065,11 @@ intel_panel_init_backlight_funcs(struct intel_panel 
> *panel)
>   panel->backlight.hz_to_pwm = pch_hz_to_pwm;
>   } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
>   if (connector->base.connector_type == DRM_MODE_CONNECTOR_DSI) {
> - panel->backlight.setup = pwm_setup_backlight;
> - panel->backlight.enable = pwm_enable_backlight;
> - panel->backlight.disable = pwm_disable_backlight;
> - panel->backlight.set = pwm_set_backlight;
> - panel->backlight.get = pwm_get_backlight;
> + panel->backlight.setup = ext_pwm_setup_backlight;
> + panel->backlight.enable = ext_pwm_enable_backlight;
> + panel->backlight.disable = ext_pwm_disable_backlight;
> + panel->backlight.set = ext_pwm_set_backlight;
> + panel->backlight.get = ext_pwm_get_backlight;
>   } else {
>   panel->backlight.setup = vlv_setup_backlight;
>   panel->backlight.enable = vlv_enable_backlight;

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

[Intel-gfx] [PATCH] drm/i915/perf: also include Gen11 in OATAILPTR workaround

[Lionel Landwerlin]

CI shows this workaround is also needed on Gen11.

Signed-off-by: Lionel Landwerlin 
Fixes: 059a0beb486344 ("drm/i915/perf: workaround register corruption in 
OATAILPTR")
---
 drivers/gpu/drm/i915/i915_perf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 3640d0e229d2..acdfbe5344a4 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -913,7 +913,7 @@ static int gen8_oa_read(struct i915_perf_stream *stream,
intel_uncore_rmw(uncore, oastatus_reg,
 GEN8_OASTATUS_COUNTER_OVERFLOW |
 GEN8_OASTATUS_REPORT_LOST,
-IS_GEN_RANGE(uncore->i915, 8, 10) ?
+IS_GEN_RANGE(uncore->i915, 8, 11) ?
 (GEN8_OASTATUS_HEAD_POINTER_WRAP |
  GEN8_OASTATUS_TAIL_POINTER_WRAP) : 0);
}
-- 
2.29.2

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

Re: [Intel-gfx] [RFC v2 1/8] drm/i915/dp: Program source OUI on eDP panels

[Jani Nikula]

On Wed, 16 Sep 2020, Lyude Paul  wrote:
> Since we're about to start adding support for Intel's magic HDR
> backlight interface over DPCD, we need to ensure we're properly
> programming this field so that Intel specific sink services are exposed.
> Otherwise, 0x300-0x3ff will just read zeroes.
>
> We also take care not to reprogram the source OUI if it already matches
> what we expect. This is just to be careful so that we don't accidentally
> take the panel out of any backlight control modes we found it in.
>
> v2:
> * Add careful parameter to intel_edp_init_source_oui() to avoid
>   re-writing the source OUI if it's already been set during driver
>   initialization
>
> Signed-off-by: Lyude Paul 
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 33 +
>  1 file changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4bd10456ad188..7db2b6a3cd52e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3424,6 +3424,29 @@ void intel_dp_sink_set_decompression_state(struct 
> intel_dp *intel_dp,
>   enable ? "enable" : "disable");
>  }
>  
> +static void
> +intel_edp_init_source_oui(struct intel_dp *intel_dp, bool careful)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + u8 oui[] = { 0x00, 0xaa, 0x01 };

Nitpick, could be static const.

> + u8 buf[3] = { 0 };
> +
> + /*
> +  * During driver init, we want to be careful and avoid changing the 
> source OUI if it's
> +  * already set to what we want, so as to avoid clearing any state by 
> accident
> +  */

Did you actually observe any ill behaviour with unconditionally writing
the source OUI?

I mean it's easy to add the "careful" mode afterwards if there are
concrete issues, but it'll be hard to remove because it'll be a
functional change potentially causing regressions.

> + if (careful) {
> + if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf, 
> sizeof(buf)) < 0)
> + drm_err(>drm, "Failed to read source OUI\n");
> +
> + if (memcmp(oui, buf, sizeof(oui)) == 0)
> + return;
> + }
> +
> + if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) 
> < 0)
> + drm_err(>drm, "Failed to write source OUI\n");
> +}
> +
>  /* If the sink supports it, try to set the power state appropriately */
>  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
>  {
> @@ -3443,6 +3466,10 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int 
> mode)
>   } else {
>   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
>  
> + /* Write the source OUI as early as possible */
> + if (intel_dp_is_edp(intel_dp))
> + intel_edp_init_source_oui(intel_dp, false);
> +

This hunk conflicts, will need a rebase.

BR,
Jani.


>   /*
>* When turning on, we need to retry for 1ms to give the sink
>* time to wake up.
> @@ -4607,6 +4634,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
>   intel_dp_get_dsc_sink_cap(intel_dp);
>  
> + /*
> +  * If needed, program our source OUI so we can make various 
> Intel-specific AUX services
> +  * available (such as HDR backlight controls)
> +  */
> + intel_edp_init_source_oui(intel_dp, true);
> +
>   return true;
>  }

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

[Intel-gfx] ✓ Fi.CI.BAT: success for HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (rev5)

[Patchwork]

== Series Details ==

Series: HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (rev5)
URL   : https://patchwork.freedesktop.org/series/82998/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9392 -> Patchwork_18986


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * {igt@kms_content_protection@dp-mst-lic-type-0} (NEW):
- fi-tgl-u2:  NOTRUN -> [SKIP][1] +3 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/fi-tgl-u2/igt@kms_content_protect...@dp-mst-lic-type-0.html
- {fi-ehl-1}: NOTRUN -> [SKIP][2] +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/fi-ehl-1/igt@kms_content_protect...@dp-mst-lic-type-0.html
- fi-tgl-y:   NOTRUN -> [SKIP][3] +3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/fi-tgl-y/igt@kms_content_protect...@dp-mst-lic-type-0.html

  * {igt@kms_content_protection@dp-mst-lic-type-1} (NEW):
- fi-cml-u2:  NOTRUN -> [SKIP][4] +3 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/fi-cml-u2/igt@kms_content_protect...@dp-mst-lic-type-1.html
- fi-icl-y:   NOTRUN -> [SKIP][5] +3 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/fi-icl-y/igt@kms_content_protect...@dp-mst-lic-type-1.html
- fi-cml-s:   NOTRUN -> [SKIP][6] +3 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/fi-cml-s/igt@kms_content_protect...@dp-mst-lic-type-1.html

  * {igt@kms_content_protection@dp-mst-type-0} (NEW):
- fi-kbl-guc: NOTRUN -> [FAIL][7] +3 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/fi-kbl-guc/igt@kms_content_protect...@dp-mst-type-0.html
- fi-bsw-nick:NOTRUN -> [FAIL][8] +3 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/fi-bsw-nick/igt@kms_content_protect...@dp-mst-type-0.html

  * {igt@kms_content_protection@dp-mst-type-1} (NEW):
- fi-icl-u2:  NOTRUN -> [SKIP][9] +3 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/fi-icl-u2/igt@kms_content_protect...@dp-mst-type-1.html

  
New tests
-

  New tests have been introduced between CI_DRM_9392 and Patchwork_18986:

### New CI tests (1) ###

  * boot:
- Statuses : 40 pass(s)
- Exec time: [0.0] s

  


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

  * igt@kms_content_protection@dp-mst-lic-type-0:
- Statuses : 2 fail(s) 35 skip(s)
- Exec time: [0.0, 0.00] s

  * igt@kms_content_protection@dp-mst-lic-type-1:
- Statuses : 2 fail(s) 35 skip(s)
- Exec time: [0.0, 0.01] s

  * igt@kms_content_protection@dp-mst-type-0:
- Statuses : 2 fail(s) 35 skip(s)
- Exec time: [0.0, 0.00] s

  * igt@kms_content_protection@dp-mst-type-1:
- Statuses : 2 fail(s) 35 skip(s)
- Exec time: [0.0, 0.00] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload:
- fi-tgl-y:   [PASS][10] -> [DMESG-WARN][11] ([i915#1982] / 
[k.org#205379])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/fi-tgl-y/igt@i915_module_l...@reload.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/fi-tgl-y/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka:  [PASS][12] -> [DMESG-FAIL][13] ([i915#541])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
- fi-cfl-8109u:   [PASS][14] -> [DMESG-FAIL][15] ([i915#541])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_busy@basic@flip:
- fi-kbl-soraka:  [PASS][16] -> [DMESG-WARN][17] ([i915#1982])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/fi-kbl-soraka/igt@kms_busy@ba...@flip.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18986/fi-kbl-soraka/igt@kms_busy@ba...@flip.html

  * igt@kms_chamelium@dp-edid-read:
- fi-kbl-7500u:   [PASS][18] -> [DMESG-WARN][19] ([i915#165])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
   [19]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (rev5)

[Patchwork]

== Series Details ==

Series: HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (rev5)
URL   : https://patchwork.freedesktop.org/series/82998/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static 
assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+drivers/gpu/drm/i915/gt/intel_reset.c:1312:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:expected void *in
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20: warning: incorrect type in 
assignment (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:expected void const *src
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46: warning: incorrect type in 
argument 2 (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:expected void *in
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20: warning: incorrect type in 
assignment (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:expected void const *src
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46: warning: incorrect type in 
argument 2 (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:expected unsigned int 
[usertype] *s
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34: warning: incorrect type in 
argument 1 (different address spaces)
+drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 
279040
+drivers/gpu/drm/i915/i915_perf.c:1447:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1501:15: warning: memset with byte count of 
16777216
+./include/linux/seqlock.h:838:24: warning: trying to copy expression type 31
+./include/linux/seqlock.h:838:24: warning: trying to copy expression type 31
+./include/linux/seqlock.h:864:16: warning: trying to copy expression type 31
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (rev5)

[Patchwork]

== Series Details ==

Series: HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (rev5)
URL   : https://patchwork.freedesktop.org/series/82998/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
fede738db387 drm/i915/hdcp: Update CP property in update_pipe
-:24: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#24: 
- Fix WARN_ON(connector->base.registration_state == DRM_CONNECTOR_REGISTERED)

total: 0 errors, 1 warnings, 0 checks, 14 lines checked
cae9bce2e99c drm/i915/hdcp: Get conn while content_type changed
a1399e34cc6b drm/i915/hotplug: Handle CP_IRQ for DP-MST
e0378ed7d400 drm/i915/hdcp: No HDCP when encoder is't initialized
9ebb17cb5dd1 drm/i915/hdcp: DP MST transcoder for link and stream
2410d90472dd drm/i915/hdcp: Move HDCP enc status timeout to header
de0fc99eeb69 drm/i915/hdcp: HDCP stream encryption support
3b08477e804e drm/i915/hdcp: Enable HDCP 1.4 stream encryption
364abd7a10e7 drm/i915/hdcp: Enable Gen12 HDCP 1.4 DP MST support
f2f428fd437a drm/i915/hdcp: Pass dig_port to intel_hdcp_init
7b2287859815 drm/i915/hdcp: Encapsulate hdcp_port_data to dig_port
809b35f4f68e misc/mei/hdcp: Fix AUTH_STREAM_REQ cmd buffer len
194192a51d06 drm/hdcp: Max MST content streams
3062c90f915d drm/i915/hdcp: MST streams support in hdcp port_data
cdef9be4dbfb drm/i915/hdcp: Pass connector to check_2_2_link
40ebf781db7c drm/i915/hdcp: Add HDCP 2.2 stream register
b27e53406aa5 drm/i915/hdcp: Support for HDCP 2.2 MST shim callbacks
28e8195e636b drm/i915/hdcp: Enable HDCP 2.2 MST support


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

[Intel-gfx] ✓ Fi.CI.BAT: success for Enable HDR on MCA LSPCON based Gen9 devices (rev11)

[Patchwork]

== Series Details ==

Series: Enable HDR on MCA LSPCON based Gen9 devices (rev11)
URL   : https://patchwork.freedesktop.org/series/68081/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9392 -> Patchwork_18985


Summary
---

  **SUCCESS**

  No regressions found.

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

New tests
-

  New tests have been introduced between CI_DRM_9392 and Patchwork_18985:

### New CI tests (1) ###

  * boot:
- Statuses : 40 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_create@basic:
- fi-tgl-y:   [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +2 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/fi-tgl-y/igt@gem_exec_cre...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/fi-tgl-y/igt@gem_exec_cre...@basic.html

  * igt@i915_module_load@reload:
- fi-tgl-y:   [PASS][3] -> [DMESG-WARN][4] ([i915#1982] / 
[k.org#205379])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/fi-tgl-y/igt@i915_module_l...@reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/fi-tgl-y/igt@i915_module_l...@reload.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900:   [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-kbl-soraka:  [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/fi-kbl-soraka/igt@kms_frontbuffer_track...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/fi-kbl-soraka/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-tgl-y:   [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/fi-tgl-y/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/fi-tgl-y/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@debugfs_test@read_all_entries:
- {fi-kbl-7560u}: [INCOMPLETE][11] ([i915#2417]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/fi-kbl-7560u/igt@debugfs_test@read_all_entries.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/fi-kbl-7560u/igt@debugfs_test@read_all_entries.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka:   [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2:  [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html

  * igt@prime_self_import@basic-with_one_bo:
- fi-tgl-y:   [DMESG-WARN][17] ([i915#402]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/fi-tgl-y/igt@prime_self_import@basic-with_one_bo.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/fi-tgl-y/igt@prime_self_import@basic-with_one_bo.html

  
 Warnings 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-tgl-y:   [DMESG-FAIL][19] ([i915#2601] / [i915#541]) -> 
[DMESG-FAIL][20] ([i915#2601])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9392/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18985/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html

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

  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2417]: https://gitlab.freedesktop.org/drm/intel/issues/2417
  [i915#2601]: https://gitlab.freedesktop.org/drm/intel/issues/2601
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541
  [k.org#205379]: 

Re: [Intel-gfx] [PATCH] drm/i915/display: Defer initial modeset until after GGTT is initialised

[Matthew Auld]

On Wed, 25 Nov 2020 at 19:30, Chris Wilson  wrote:
>
> Prior to sanitizing the GGTT, the only operations around in
> intel_display_init_nogem() are those to reserve the preallocated (and
> active) regions in the GGTT leftover from the BIOS. Trying to allocate a
> GGTT vma (such as intel_pin_and_fence_fb_obj during the initial modeset)
> may then conflict with other preallocated regions that have not yet been
> protected.
>
> Move the initial modesetting from the end of init_nogem to the beginning
> of init so that any vma pinning (either framebuffers or DSB, for example),
> is after the GGTT is ready to handle it.
>
> This will prevent the DSB object from being destroyed too early:
>
> [   53.448973] 
> ==
> [   53.449241] BUG: KASAN: use-after-free in i915_init_ggtt+0x324/0x9e0 [i915]
> [   53.449309] Read of size 8 at addr 88811b1e8070 by task 
> systemd-udevd/345
>
> [   53.449399] CPU: 1 PID: 345 Comm: systemd-udevd Tainted: GW
>  5.10.0-rc5+ #12
> [   53.449409] Call Trace:
> [   53.449418]  dump_stack+0x9a/0xcc
> [   53.449558]  ? i915_init_ggtt+0x324/0x9e0 [i915]
> [   53.449565]  print_address_description.constprop.0+0x3e/0x60
> [   53.449577]  ? _raw_spin_lock_irqsave+0x4e/0x50
> [   53.449718]  ? i915_init_ggtt+0x324/0x9e0 [i915]
> [   53.449849]  ? i915_init_ggtt+0x324/0x9e0 [i915]
> [   53.449857]  kasan_report.cold+0x1f/0x37
> [   53.449993]  ? i915_init_ggtt+0x324/0x9e0 [i915]
> [   53.450130]  i915_init_ggtt+0x324/0x9e0 [i915]
> [   53.450273]  ? i915_ggtt_suspend+0x1f0/0x1f0 [i915]
> [   53.450281]  ? static_obj+0x69/0x80
> [   53.450289]  ? lockdep_init_map_waits+0xa9/0x310
> [   53.450431]  ? intel_wopcm_init+0x96/0x3d0 [i915]
> [   53.450581]  ? i915_gem_init+0x75/0x2d0 [i915]
> [   53.450720]  i915_gem_init+0x75/0x2d0 [i915]
> [   53.450852]  i915_driver_probe+0x8c2/0x1210 [i915]
> [   53.450993]  ? i915_pm_prepare+0x630/0x630 [i915]
> [   53.451006]  ? check_chain_key+0x1e7/0x2e0
> [   53.451025]  ? __pm_runtime_resume+0x58/0xb0
> [   53.451157]  i915_pci_probe+0xa6/0x2b0 [i915]
> [   53.451285]  ? i915_pci_remove+0x40/0x40 [i915]
> [   53.451295]  ? lockdep_hardirqs_on_prepare+0x124/0x230
> [   53.451302]  ? _raw_spin_unlock_irqrestore+0x42/0x50
> [   53.451309]  ? lockdep_hardirqs_on+0xbf/0x130
> [   53.451315]  ? preempt_count_sub+0xf/0xb0
> [   53.451321]  ? _raw_spin_unlock_irqrestore+0x2f/0x50
> [   53.451335]  pci_device_probe+0xf9/0x190
> [   53.451350]  really_probe+0x17f/0x5b0
> [   53.451365]  driver_probe_device+0x13a/0x1c0
> [   53.451376]  device_driver_attach+0x82/0x90
> [   53.451386]  ? device_driver_attach+0x90/0x90
> [   53.451391]  __driver_attach+0xab/0x190
> [   53.451401]  ? device_driver_attach+0x90/0x90
> [   53.451407]  bus_for_each_dev+0xe4/0x140
> [   53.451414]  ? subsys_dev_iter_exit+0x10/0x10
> [   53.451423]  ? __list_add_valid+0x2b/0xa0
> [   53.451440]  bus_add_driver+0x227/0x2e0
> [   53.451454]  driver_register+0xd3/0x150
> [   53.451585]  i915_init+0x92/0xac [i915]
> [   53.451592]  ? 0xa0a2
> [   53.451598]  do_one_initcall+0xb6/0x3b0
> [   53.451606]  ? trace_event_raw_event_initcall_finish+0x150/0x150
> [   53.451614]  ? __kasan_kmalloc.constprop.0+0xc2/0xd0
> [   53.451627]  ? kmem_cache_alloc_trace+0x4a4/0x8e0
> [   53.451634]  ? kasan_unpoison_shadow+0x33/0x40
> [   53.451649]  do_init_module+0xf8/0x350
> [   53.451662]  load_module+0x43de/0x47f0
> [   53.451716]  ? module_frob_arch_sections+0x20/0x20
> [   53.451731]  ? rw_verify_area+0x5f/0x130
> [   53.451780]  ? __do_sys_finit_module+0x10d/0x1a0
> [   53.451785]  __do_sys_finit_module+0x10d/0x1a0
> [   53.451792]  ? __ia32_sys_init_module+0x40/0x40
> [   53.451800]  ? seccomp_do_user_notification.isra.0+0x5c0/0x5c0
> [   53.451829]  ? rcu_read_lock_bh_held+0xb0/0xb0
> [   53.451835]  ? mark_held_locks+0x24/0x90
> [   53.451856]  do_syscall_64+0x33/0x80
> [   53.451863]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [   53.451868] RIP: 0033:0x7fde09b4470d
> [   53.451875] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 
> f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 
> 01 f0 ff ff 73 01 c3 48 8b 0d 53 f7 0c 00 f7 d8 64 89 01 48
> [   53.451880] RSP: 002b:7ffd6abc1718 EFLAGS: 0246 ORIG_RAX: 
> 0139
> [   53.451890] RAX: ffda RBX: 56444e528150 RCX: 
> 7fde09b4470d
> [   53.451895] RDX:  RSI: 7fde09a21ded RDI: 
> 000f
> [   53.451899] RBP: 0002 R08:  R09: 
> 
> [   53.451904] R10: 000f R11: 0246 R12: 
> 7fde09a21ded
> [   53.451909] R13:  R14: 56444e329200 R15: 
> 56444e528150
>
> [   53.451957] Allocated by task 345:
> [   53.451995]  kasan_save_stack+0x1b/0x40
> [   53.452001]  __kasan_kmalloc.constprop.0+0xc2/0xd0
> [   53.452006]  kmem_cache_alloc+0x1cd/0x8d0
> [   53.452146]  

Re: [Intel-gfx] [RFC] drm/i915/dp: PPS registers doesn't require AUX power

[Anshuman Gupta]

On 2020-11-25 at 18:24:44 +0200, Imre Deak wrote:
> +Ville.
Hi Ville ,
Let me provide you some context over the issue which requires your input.
TGL on chorome OS has observed some display glitches when brightness is being 
updated
at very fast rate. This has surfaced out two issue.
1. Getting the AUX power when accessing the PPS registers on platform with 
split PCH.
2. The race between DC3CO disabling delay and flips. (B.Spec says 200us dc3co 
exit delay)
   I will send a separate RFC patch to fix this issue.

Current patch is addressing issue1, 
IMHO it is unnecessary to take AUX power for pps register read for checking
whether backlight was enabled. This is causing flip to race with
DC3CO exit delay.
Could you please provide your input to this . 

Thanks,
Anshuman Gupta.   
> 
> On Wed, Nov 25, 2020 at 01:16:27PM +0530, Anshuman Gupta wrote:
> > On 2020-11-24 at 18:44:06 +0200, Imre Deak wrote:
> > > On Tue, Nov 24, 2020 at 03:28:47PM +0530, Anshuman Gupta wrote:
> > > > Platforms with South Display Engine on PCH, doesn't
> > > > require to get/put the AUX power domain in order to
> > > > access PPS register because PPS registers are always on
> > > > with South display on PCH.
> > > > 
> > > > Cc: Imre Deak 
> > > > Cc: 
> > > > Signed-off-by: Anshuman Gupta 
> > > 
> > > Could you describe the issue the patch is fixing?
> >
> > This fixes the display glitches causes by race between brightness
> > update thread and flip thread.
> 
> Flips should work even with asynchronous DC3co (or any DC state)
> disabling, at least according to the spec the HW handles this. Only
> modesetting and AUX transfers have restriction wrt. DC state handling
> (where DC states need to get disabled).
> 
> I think the exact restriction needs to be clarified with HW people: Is
> only the DC3co disable -> flip or also the opposite sequence
> problematic? Is it only DC3co or also DC5/6 affected?
> 
> > While brightness is being updated it reads pp_ctrl reg to check
> > whether backlight is enabled and get/put the AUX power domain, this
> > enables and disable DC Off power well(DC3CO) back and forth.
> >
> > IMO there are two work item for above race needed to be addressed.
> > 1. Don't get AUX power for PPS register access (this patch addressed this).
> > 2. skl_program_plane() should wait for DC3CO exit delay to avoid any race 
> > with
> >DC3CO disable sequence. (WIP)  
> 
> DC states can be disabled asynchronously with a flip modeset, not only
> for panel brightness setting, but also AUX transfers for instance. So I
> think we'd need to add locking against DC state changes to
> intel_pipe_update_start()/end(). Probably the easiest would be to use
> the power_domains->lock for this.
> 
> --Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable HDR on MCA LSPCON based Gen9 devices (rev11)

[Patchwork]

== Series Details ==

Series: Enable HDR on MCA LSPCON based Gen9 devices (rev11)
URL   : https://patchwork.freedesktop.org/series/68081/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_reset.c:1312:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:expected void *in
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20: warning: incorrect type in 
assignment (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:expected void const *src
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46: warning: incorrect type in 
argument 2 (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:expected void *in
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20: warning: incorrect type in 
assignment (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:expected void const *src
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46: warning: incorrect type in 
argument 2 (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:expected unsigned int 
[usertype] *s
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34: warning: incorrect type in 
argument 1 (different address spaces)
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable HDR on MCA LSPCON based Gen9 devices (rev11)

[Patchwork]

== Series Details ==

Series: Enable HDR on MCA LSPCON based Gen9 devices (rev11)
URL   : https://patchwork.freedesktop.org/series/68081/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
e7d69665cf73 drm/i915/display: Add HDR Capability detection for LSPCON
b5fa510007a1 drm/i915/display: Enable HDR on gen9 devices with MCA Lspcon
94da9b381802 drm/i915/display: Attach HDR property for capable Gen9 devices
-:58: WARNING:LONG_LINE: line length of 108 exceeds 100 columns
#58: FILE: drivers/gpu/drm/i915/display/intel_dp.c:6804:
+  
connector->dev->mode_config.hdr_output_metadata_property,

total: 0 errors, 1 warnings, 0 checks, 45 lines checked
37af9241ac63 drm/i915/display: Enable quantization range for HDR on LSPCON 
devices
90a45305d915 drm/i915/display: Add a WARN for invalid output range and format
99311bb61d69 drm/i915/display: Attach content type property for LSPCON
78f2b24a1ff7 i915/display: Enable BT2020 for HDR on LSPCON devices
05833c4d31da drm/i915/display: Enable HDR for Parade based lspcon
9e5f135c0a29 drm/i915/display: Implement infoframes readback for LSPCON
ae81dd3d5f06 drm/i915/display: Implement DRM infoframe read for LSPCON
9cad91480b72 drm/i915/lspcon: Create separate infoframe_enabled helper
fd7bd8dacdb0 drm/i915/lspcon: Do not send DRM infoframes to non-HDMI sinks
35f0ce30d872 drm/i915/display: [NOT FOR MERGE] Reduce blanking to support 
4k60@10bpp for LSPCON


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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/tgl: Fix REVID macros for TGL to 
fetch correct stepping
URL   : https://patchwork.freedesktop.org/series/84285/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9390_full -> Patchwork_18984_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gem_contexts:
- shard-skl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18984/shard-skl10/igt@i915_selftest@live@gem_contexts.html

  
New tests
-

  New tests have been introduced between CI_DRM_9390_full and 
Patchwork_18984_full:

### New CI tests (1) ###

  * boot:
- Statuses : 200 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-skl:  [PASS][2] -> [INCOMPLETE][3] ([i915#198])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9390/shard-skl2/igt@gem_ctx_isolation@preservation...@vcs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18984/shard-skl4/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_exec_reloc@basic-many-active@rcs0:
- shard-glk:  [PASS][4] -> [FAIL][5] ([i915#2389])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9390/shard-glk7/igt@gem_exec_reloc@basic-many-act...@rcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18984/shard-glk2/igt@gem_exec_reloc@basic-many-act...@rcs0.html

  * igt@i915_pm_rpm@system-suspend-modeset:
- shard-skl:  [PASS][6] -> [INCOMPLETE][7] ([i915#151])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9390/shard-skl1/igt@i915_pm_...@system-suspend-modeset.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18984/shard-skl3/igt@i915_pm_...@system-suspend-modeset.html

  * igt@kms_cursor_crc@pipe-b-cursor-256x256-sliding:
- shard-skl:  [PASS][8] -> [FAIL][9] ([i915#54]) +2 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9390/shard-skl5/igt@kms_cursor_...@pipe-b-cursor-256x256-sliding.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18984/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-256x256-sliding.html

  * igt@kms_cursor_legacy@flip-vs-cursor-crc-legacy:
- shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2346]) +1 similar 
issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9390/shard-tglb6/igt@kms_cursor_leg...@flip-vs-cursor-crc-legacy.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18984/shard-tglb2/igt@kms_cursor_leg...@flip-vs-cursor-crc-legacy.html

  * igt@kms_cursor_legacy@short-flip-before-cursor-toggle:
- shard-hsw:  [PASS][12] -> [DMESG-WARN][13] ([i915#1982]) +1 
similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9390/shard-hsw6/igt@kms_cursor_leg...@short-flip-before-cursor-toggle.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18984/shard-hsw7/igt@kms_cursor_leg...@short-flip-before-cursor-toggle.html

  * igt@kms_fbcon_fbt@fbc-suspend:
- shard-kbl:  [PASS][14] -> [DMESG-WARN][15] ([i915#180])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9390/shard-kbl1/igt@kms_fbcon_...@fbc-suspend.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18984/shard-kbl3/igt@kms_fbcon_...@fbc-suspend.html

  * igt@kms_flip@2x-flip-vs-fences-interruptible@ab-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][16] -> [DMESG-WARN][17] ([i915#1982]) +1 
similar issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9390/shard-glk6/igt@kms_flip@2x-flip-vs-fences-interrupti...@ab-hdmi-a1-hdmi-a2.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18984/shard-glk4/igt@kms_flip@2x-flip-vs-fences-interrupti...@ab-hdmi-a1-hdmi-a2.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1:
- shard-skl:  [PASS][18] -> [FAIL][19] ([i915#79])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9390/shard-skl1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18984/shard-skl5/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html

  * igt@kms_flip@flip-vs-suspend-interruptible@c-hdmi-a1:
- shard-hsw:  

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

[Maxime Ripard]

Hi Dave, Daniel,

Here's this week round of fixes for drm-misc

Maxime

drm-misc-fixes-2020-11-26:
A bunch of fixes for vc4 fixing some coexistence issue between wifi and
HDMI, unsupported modes, and vblank timeouts, a fix for ast to reload
the gamma LUT after changing the plane format and a double-free fix for
nouveau
The following changes since commit cdf117d6d38a127026e74114d63f32972f620c06:

  Merge tag 'drm/sun4i-dma-fix-pull-request' of 
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mripard/linux into 
drm-misc-fixes (2020-11-19 09:26:07 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2020-11-26

for you to fetch changes up to 2be65641642ef423f82162c3a5f28c754d1637d2:

  drm/nouveau: fix relocations applying logic and a double-free (2020-11-26 
08:04:19 +0100)


A bunch of fixes for vc4 fixing some coexistence issue between wifi and
HDMI, unsupported modes, and vblank timeouts, a fix for ast to reload
the gamma LUT after changing the plane format and a double-free fix for
nouveau


Matti Hamalainen (1):
  drm/nouveau: fix relocations applying logic and a double-free

Maxime Ripard (11):
  drm/vc4: hdmi: Make sure our clock rate is within limits
  drm/vc4: hdmi: Block odd horizontal timings
  drm/vc4: kms: Switch to drmm_add_action_or_reset
  drm/vc4: kms: Remove useless define
  drm/vc4: kms: Rename NUM_CHANNELS
  drm/vc4: kms: Split the HVS muxing check in a separate function
  drm/vc4: kms: Document the muxing corner cases
  dt-bindings: display: Add a property to deal with WiFi coexistence
  drm/vc4: hdmi: Disable Wifi Frequencies
  drm/vc4: kms: Store the unassigned channel list in the state
  drm/vc4: kms: Don't disable the muxing of an active CRTC

Thomas Zimmermann (1):
  drm/ast: Reload gamma LUT after changing primary plane's color format

 .../bindings/display/brcm,bcm2711-hdmi.yaml|   6 +
 drivers/gpu/drm/ast/ast_mode.c |  17 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c  |   8 +-
 drivers/gpu/drm/vc4/vc4_drv.h  |   4 +
 drivers/gpu/drm/vc4/vc4_hdmi.c |  48 
 drivers/gpu/drm/vc4/vc4_hdmi.h |  11 +
 drivers/gpu/drm/vc4/vc4_kms.c  | 246 +++--
 7 files changed, 272 insertions(+), 68 deletions(-)


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

Re: [Intel-gfx] [PATCH 1/2] drm/framebuffer: Format modifier for Intel Gen 12 render compression with Clear Color

[Kahola, Mika]

> -Original Message-
> From: Intel-gfx  On Behalf Of Imre
> Deak
> Sent: Monday, November 23, 2020 8:27 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chery, Nanley G ; Rafael Antognolli
> ; Pandiyan, Dhinakaran
> ; Kondapally, Kalyan
> 
> Subject: [Intel-gfx] [PATCH 1/2] drm/framebuffer: Format modifier for Intel
> Gen 12 render compression with Clear Color
> 
> From: Radhakrishna Sripada 
> 
> Gen12 display can decompress surfaces compressed by render engine with
> Clear Color, add a new modifier as the driver needs to know the surface was
> compressed by render engine.
> 
> V2: Description changes as suggested by Rafael.
> V3: Mention the Clear Color size of 64 bits in the comments(DK)
> v4: Fix trailing whitespaces
> v5: Explain Clear Color in the documentation.
> v6: Documentation Nitpicks(Nanley)
> 
> Cc: Ville Syrjala 
> Cc: Dhinakaran Pandiyan 
> Cc: Kalyan Kondapally 
> Cc: Rafael Antognolli 
> Cc: Nanley Chery 
> Signed-off-by: Radhakrishna Sripada 
> Signed-off-by: Imre Deak 

Reviewed-by: Mika Kahola 

> ---
>  include/uapi/drm/drm_fourcc.h | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/include/uapi/drm/drm_fourcc.h
> b/include/uapi/drm/drm_fourcc.h index ca48ed0e6bc1..0a1b2c4c4bee
> 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -527,6 +527,25 @@ extern "C" {
>   */
>  #define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS
> fourcc_mod_code(INTEL, 7)
> 
> +/*
> + * Intel Color Control Surface with Clear Color (CCS) for Gen-12 render
> + * compression.
> + *
> + * The main surface is Y-tiled and is at plane index 0 whereas CCS is
> +linear
> + * and at index 1. The clear color is stored at index 2, and the pitch
> +should
> + * be ignored. The clear color structure is 256 bits. The first 128
> +bits
> + * represents Raw Clear Color Red, Green, Blue and Alpha color each
> +represented
> + * by 32 bits. The raw clear color is consumed by the 3d engine and
> +generates
> + * the converted clear color of size 64 bits. The first 32 bits store
> +the Lower
> + * Converted Clear Color value and the next 32 bits store the Higher
> +Converted
> + * Clear Color value when applicable. The Converted Clear Color values
> +are
> + * consumed by the DE. The last 64 bits are used to store Color Discard
> +Enable
> + * and Depth Clear Value Valid which are ignored by the DE. A CCS cache
> +line
> + * corresponds to an area of 4x1 tiles in the main surface. The main
> +surface
> + * pitch is required to be a multiple of 4 tile widths.
> + */
> +#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC
> fourcc_mod_code(INTEL,
> +8)
> +
>  /*
>   * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
>   *
> --
> 2.25.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx